周末时，和一个朋友 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岁了，我打算换个活法》所提到的搭建自己的“确定性结构”的精神内核。可以说，这样的挑战正是我“确定性结构”理念的具体实践方式之一。
所以我也在认真考虑，要不要也为自己设一个类似的挑战，比如：
“3 Projects in 3 Months” ，或者“每个月上线一个小产品”。
每个产品不求商业化，不求完美，但至少得能跑起来，能上线，能收集用户反馈。也许会失败，也许会中途放弃，但只要在这个过程中，不断试、不断学、不断迭代，我相信一定会积累出什么。
更重要的是，它可以帮我找回那种节奏感 ——不是“等机会来”，而是主动创造机会的 Builder 状态。
就像 Pieter Levels 的那句话：
“如果你一个人都能做出一个真正跑得起来的产品，那你其实已经自由了。”
我也想试一试。
不为了证明什么，只是想看看，在这个拥有 AI 的时代，我是否也能凭一己之力，慢慢积累起一条属于自己的路径。
下一步的打算
如果说“做挑战”是一种动念，那我决定从一个最小单位开始：在这个月内，完成一个独立项目。
不立大 flag，不追求多项目并行，就先专注一件事：把它做完，跑起来，收一个闭环。
这个项目我想重启的是我曾经做过的「链上 ETF 实战项目」。去年它作为课程上线时，已经有完整的代码和教学结构，但后来发现合约逻辑有 bug，一直没抽出时间去解决，就搁置了。现在回头看，它是一个非常合适的「挑战起点」：
- 技术上已经有基础积累，可以专注优化机制和用户体验；
- 教学上有市场验证，也方便我结合实际经验输出；
- 产品形态清晰，功能边界明确，适合在短时间内收尾上线。
我打算做的是一个优化后的新版本，也就是：
一个可以正常运行的链上 ETF 合约 + 对应前端界面。
这次，我想尝试用 AI 辅助加速整个开发流程，也记录下整个构建过程中，AI 能带来的真实效率提升在哪里，瓶颈又在哪里。
为什么先做这个挑战？
一方面，是为了把“确定性结构”真正落地——从设想、架构、路线图，走到真实的交付结果。
另一方面，也是为了重新建立节奏：
不是等灵感来才做，而是设一个边界，倒逼行动发生。
我不打算把这个项目做得多复杂，不做重运营，不追求精致设计，我只希望它能上线、可交互、能讲清楚背后的逻辑。
如果能做到这一点，我就可以开始记录我自己的“月度项目节奏”。
如果这个挑战能够顺利完成，我会考虑进入第二个项目；如果中途遇到问题，也会认真复盘：是目标设得不对？节奏不适合？还是机制有待优化？
无论结果如何，这都是我重启 Builder 节奏的第一步。与其空想，不如动手；与其等待，不如交付。
如果你也正面临相似的困境，欢迎和我一起试试“一个月一个挑战”的节奏。从第一个项目开始，把节奏找回来，把自己找回来。
