# 周末和朋友Catch Up引发的一些思考 By [Keegan小钢](https://paragraph.com/@keeganlee) · 2025-07-07 --- 周末时，和一个朋友 catch up，从各自的近况聊起，一路聊到了我们面临的短板、行业的现状、AI 编程的发展、独立开发者的机会，还有下一步的打算。这些话题也引发了我不少思考，想在这里简单整理一下。 英语是硬伤 ----- 先介绍下背景：我这位朋友去年底加入了现在这家公司，团队成员几乎都是外国人，纯英语沟通环境。但他的英语水平还达不到能无障碍、流利地与母语者交流的程度。 起初，他主要负责技术实现，偶尔和同事一对一沟通，还能应付得来。但最近两个月，他开始频繁参与团队会议，就发现自己明显跟不上了。大家说话节奏快，用词也复杂，他常常听不太懂，有时连上下文都接不上，问题就这样越积越多。每次开会，对他来说简直像是一场“高压听力考试”。 慢慢地，他的最大短板——语言能力，开始在团队中显现出来。 其实他的技术能力很强，也得到了老板认可。但在协作密集的团队中，沟通是无法回避的。如果这个问题短期内难以改善，就算代码写得再好，也未必适合当前的团队节奏。所以他也在重新考虑是否换一份工作。 听他说这些时，我特别有共鸣。因为我也一样，英语沟通是我的硬伤。 说来也惭愧，十年前，老婆就一直劝我学好英语。那时候她就预感到我迟早会遇到语言这道坎，甚至硬是给我报了班，冲刺雅思，希望我能技术移民到加拿大。 那段时间，她比我还上心，而我却始终提不起劲。只考了一次雅思，成绩不太理想，之后就不了了之了。我总觉得“现在用不上”，“以后再说也不迟”，“先把技术搞好才是正事”。 直到这些年，工作中越来越频繁地因为英语吃力，我才意识到：她当年看到的，其实没错。只是这条本可以早点打通的路，被我自己绕了十年，最后还是绕回来了。 更现实的是，我们现在人在新加坡，面向的是一个以英语为主的国际市场。团队来自世界各地，客户、同事、会议、文档，几乎都用英文。这不是一个能“回避语言能力”的环境，反而是一场每天都在考验英文听说读写能力的硬仗。 有时在招聘网站上看到一些岗位，技术栈跟我的背景完全匹配，岗位也很有吸引力。可一看到“全英文沟通”“英语面试”“国际团队”这几个字，就下意识地滑走了。不是不想挑战，而是心里很清楚，自己开不了这个口，也接不住这样的交流节奏。 也正因为如此，\*\*很多英文要求高的职位，我们根本不敢投，或者投了也知道自己撑不住。\*\*而这些机会，恰恰是最多的、薪资最高的、成长空间最大的那一批。 问题不在于技术能力，而是在“沟通层”被挡了下来。很多时候，并不是没有机会，而是我们争取不到，也没法被看见。 而这不只是我朋友一个人的问题，也不只是我自己的问题，而是很多像我们这样的技术人，正在同时面对的一道硬门槛。 行业在变，机会在收缩 ---------- 除了自身能力的短板，行业机会的收缩也是真实存在的。 尤其是在新加坡，最近的政策环境正发生深刻变化，对 Web3 从业者、开发者带来了直接影响。 过去几年，新加坡因政策灵活、税率低、监管友好，一度吸引了大量 Web3 项目落地。从交易所、DeFi 协议，到 Layer1 基础设施、Dapp 团队，很多项目都把这里当作亚洲的桥头堡。但这个趋势正在迅速逆转。 就在上个月，MAS（新加坡金融管理局）正式启动了 **FSMA（金融服务与市场法案）第9部分**的监管条款，要求所有在新加坡提供数字代币服务的团队必须申请 **DTSP（Digital Token Service Provider）牌照**。 这张牌照不仅没有过渡期，而且申请门槛极高，要求包括： * **至少 25 万新币的实缴资本**（某些类型业务门槛更高） * 本地合规团队、反洗钱制度、KYC 体系、内部稽核机制 * 必须是新加坡注册法人，不能“挂名落地” MAS 也明确表态：**“只有极少数机构有机会获批。”** 对个人开发者、小团队来说，哪怕产品做出来了，技术也过硬，也很难继续合法运营。 我们可以非常明显地感受到，**整个 Web3 的创业土壤正在紧缩**。而 MAS 推出的 **FSTI 3.0 计划**，虽然设立了高达 1.5 亿新币的资金池，鼓励机构级的 Web3 创新（如资产代币化、合规 DeFi 等），但这类支持更偏向有资本、有人力、合规体系健全的大型团队——对我们这些草根型 Builder 来说，可参与的空间反而在不断收窄。 前几天和一个前辈聊天时，他也说起，**最近这一个月已经送走了不少 Web3 的朋友。** 项目撑不住、牌照批不下，就只能撤。就连我的前东家 Bybit，在新加坡的团队规模不小，如今也不得不离开了。 而从我们熟悉的技术方向来看，变化也愈加明显。我们过去主要做的是 EVM 智能合约开发，但这一年里，**EVM 相关岗位明显减少**。不少公司更倾向于招聘懂 **Solana、Sui、Tron** 等生态的开发者，对 EVM 的需求不再是主流，甚至在某些场景下被边缘化。 **技能结构已经在悄悄变化**，我们原本赖以立身的能力模型，变得越来越“不可转卖”。 这些变化不是一天发生的，但当你真的回过神来，会突然发现：**原本“靠技术吃饭”的路径，变得不再稳妥了。** 所以我们也开始认真想：如果岗位机会在缩小，那有没有可能，**不靠公司发 offer，而是自己创造机会？** AI 与独立开发者的机会 ------------ 当聊到工作机会收缩、岗位要求越来越高的时候，我们也开始认真思考：还有没有别的路？ 这时候我们聊到了 **AI 编程的发展**，聊到了 **独立开发者的机会窗口**。 从 Copilot，到 Cursor，再到如今最热门的 Claude Code，AI 编程的发展速度真的是日新月异。写代码、改逻辑、生成文档、写测试，几乎都可以部分甚至大部分由 AI 辅助完成。 而对我们这样原本就具备技术能力、但在人力和资源上相对单薄的个体开发者来说，这带来的变化是根本性的： * **从“需要组团队”变成“可以一个人做 MVP”** * **从“写代码耗时”变成“构思逻辑更重要”** * **从“等机会”变成“自己创造产品和市场反馈”** 这几天，也有不止一个前辈朋友极力推荐我从 AI 方向寻找突破口。其实，我去年做链上 ETF 课程项目时，整个前端有 90% 以上的代码也是 AI 帮我完成的。这大半年我也一直有在使用 AI 辅助我进行编码，所以，我也清楚，**AI 真的可以成为一个非常有力的“杠杆”**。 这时候，我不由得想起了一个很有名的案例。 2014 年，一位叫 **Pieter Levels** 的荷兰开发者，发起了一个几乎不可能完成的挑战——**12 Startups in 12 Months**。 他没有团队、没有融资、没有外包，就靠一个人，打算一年做出 12 个可以上线的产品。听上去像是个玩笑，但他真的做到了。而且他做出的几个产品，比如 Nomad List、Remote OK，不仅成功变现，还一直活到现在，甚至成为他的主要收入来源（据说年收入超过百万美金）。 那还是在 **没有 AI 的时代**。 当年的 Pieter，要自己写代码、搭服务器、设计页面、写文案、发推文、维护用户，所有事情全靠一个人。他之所以能成功，一方面是他做得足够小、启动得够快、节奏够紧；另一方面是他放弃了对完美的执念——不是为了做出 12 个成功的公司，而是**逼自己在 12 个月里快速试错、快速成长**。 这让我开始认真想一件事： > 今天的我，技术能力不比当年的 Pieter 差，但现在我拥有了他没有的超级工具——**AI 编程助手**。 我可以用 Cursor 或 Claude Code 来生成基础代码、自动补测试；可以让 GPT 帮我起草项目文档、代写用户 FAQ；甚至可以用 AI 帮我调研同类竞品、生成初步路线图。在很多环节，我甚至可以在没有团队的情况下，把一个小产品的原型从 0 搭建到 1。 **如果 10 年前的他能做到，我是不是也可以做一次属于自己的 Builder 挑战？** 也许不是每个月一个产品，也许我没有 Nomad List 那样的爆款想法，也许我仍然不擅长营销、文案、设计…… 但我知道，只要开始尝试，“能不能做出一个产品”不再是问题，真正的挑战是“能不能持续做下去”。 而且，尝试做这样的挑战，也符合我前几天的文章[《40岁了，我打算换个活法》](https://mp.weixin.qq.com/s/0txTSArGPkk16xjuMfd0Ng)所提到的**搭建自己的“确定性结构”的精神内核**。可以说，这样的挑战**正是我“确定性结构”理念的具体实践方式之一**。 所以我也在认真考虑，要不要也为自己设一个类似的挑战，比如： > **“3 Projects in 3 Months”**，或者“**每个月上线一个小产品**”。 每个产品不求商业化，不求完美，但至少得能跑起来，能上线，能收集用户反馈。也许会失败，也许会中途放弃，但只要在这个过程中，不断试、不断学、不断迭代，我相信一定会积累出什么。 更重要的是，它可以帮我找回那种节奏感 ——不是“等机会来”，而是**主动创造机会的 Builder 状态**。 就像 Pieter Levels 的那句话： > “如果你一个人都能做出一个真正跑得起来的产品，那你其实已经自由了。” 我也想试一试。 不为了证明什么，只是想看看，在这个拥有 AI 的时代，我是否也能凭一己之力，慢慢积累起一条属于自己的路径。 下一步的打算 ------ 如果说“做挑战”是一种动念，那我决定从一个最小单位开始：**在这个月内，完成一个独立项目**。 不立大 flag，不追求多项目并行，就先专注一件事：**把它做完，跑起来，收一个闭环。** 这个项目我想重启的是我曾经做过的「链上 ETF 实战项目」。去年它作为课程上线时，已经有完整的代码和教学结构，但后来发现合约逻辑有 bug，一直没抽出时间去解决，就搁置了。现在回头看，它是一个非常合适的「挑战起点」： * 技术上已经有基础积累，可以专注优化机制和用户体验； * 教学上有市场验证，也方便我结合实际经验输出； * 产品形态清晰，功能边界明确，适合在短时间内收尾上线。 我打算做的是**一个优化后的新版本**，也就是： > 一个可以正常运行的链上 ETF 合约 + 对应前端界面。 这次，我想尝试用 AI 辅助加速整个开发流程，也记录下整个构建过程中，AI 能带来的真实效率提升在哪里，瓶颈又在哪里。 为什么先做这个挑战？ 一方面，是为了把“确定性结构”真正落地——从设想、架构、路线图，走到真实的交付结果。 另一方面，也是为了重新建立节奏： > **不是等灵感来才做，而是设一个边界，倒逼行动发生。** 我不打算把这个项目做得多复杂，不做重运营，不追求精致设计，**我只希望它能上线、可交互、能讲清楚背后的逻辑。** 如果能做到这一点，我就可以开始记录我自己的“月度项目节奏”。 如果这个挑战能够顺利完成，我会考虑进入第二个项目；如果中途遇到问题，也会认真复盘：**是目标设得不对？节奏不适合？还是机制有待优化？** > 无论结果如何，这都是我重启 Builder 节奏的第一步。与其空想，不如动手；与其等待，不如交付。 如果你也正面临相似的困境，欢迎和我一起试试“一个月一个挑战”的节奏。从第一个项目开始，把节奏找回来，把自己找回来。 --- *Originally published on [Keegan小钢](https://paragraph.com/@keeganlee/catch-up)*