AI 时代做基础软件：门槛在降，壁垒在重构
最近一段时间，我们在推进 RobustMQ 的规则引擎和 Connector，也在高频使用 AI 协作开发。这个过程中，我脑子里反复出现一个问题：AI 把执行速度提上来之后，基础软件的核心竞争力到底会变成什么？
我会想这个问题，不是抽象讨论，而是被实际工作推着想。以前我们做一个想法，从设计到落地，中间有很多体力活，很多时间不是花在“想清楚问题”，而是花在“把事情做完”。现在 AI 把这部分成本压下来了，节奏明显变快。越是这样，越能感觉到一件事：基础软件并没有因为 AI 变简单，只是难点换了位置。以前的压力在“能不能做出来”，现在更大的压力在“能不能长期做对”。
以前做基础软件，很多时间花在 API 细节、底层调试、重复胶水代码和工程体力活上。现在这些事确实快了，AI 能把大量执行层工作接过去，原型和功能落地速度肉眼可见地提高。这是事实，我自己每天都能感受到这个变化。也正因为提速了，判断失误的代价反而更高了。
难点迁移了，不是消失了
我这段时间最深的体会是，项目真正的成败，越来越不取决于“写得快不快”，而取决于“边界定得准不准”。做不做某个能力，做到哪一层停，错误码怎么设计，规则语义怎么统一，系统演进如何控复杂度，这些判断一旦错了，AI 只会把错误更快放大。
为什么我会这么看？因为我们已经能很快把代码写出来，但真正难的是把系统长期跑稳。一次错误决策，可能不会立刻炸掉，但会在后面以技术债、兼容性负担、运维复杂度的形式慢慢反噬。以前慢，是慢在实现；现在快了，慢点转移到了重构和治理。
所以我现在基本确定一件事：今天的核心竞争力是做产品和做系统决策，而不是单点编码速度。编码当然还是很重要，但它更像底座能力。没有这个底座，你根本无法判断 AI 写得对不对，也无法在关键时刻接管复杂问题。尤其是基础软件，线上行为、边界条件、回归风险都很硬，如果 coding 能力薄弱，项目几乎不可能长期可维护。
为什么资深工程师反而更有杠杆
我以前也担心过，AI 强起来之后，资深开发者会不会被削弱。实际越做越发现，资深工程师反而更有杠杆。因为资深的价值从来不只是“写代码快”，而是问题建模、风险直觉、架构权衡和组织收敛能力。
AI 输出的是候选实现，不是最终答案。谁能高质量地判断这些候选实现、把它们收敛成稳定系统，谁就掌握主导权。经历过“手工打磨阶段”的人，通常更擅长这个过程，因为他知道哪里最容易出错，也知道哪里必须保守。
我自己现在越来越把精力放在三个动作上：先定边界，再做取舍，最后才是推进执行。执行可以很快，但边界和取舍如果错了，快只会更危险。这个节奏看起来慢一点，但长期效率反而高很多。
初级工程师的问题，不是“用不用 AI”，而是“怎么用 AI”
这个问题我其实想得很多，因为它关系到团队未来。AI 工具越顺手，初级工程师越容易跳过基础训练，直接追求“能跑起来”。短期看交付很快，长期看会形成很大的能力断层。
我自己的看法是，AI 可以早用，但不能把思考外包。那些看起来“脏活累活”的过程，比如手动复现、读日志、定位根因、理解协议细节，依然是成长必须经过的阶段。跳过这段，短期会很爽，长期会缺问题模型和工程直觉。
这件事我更倾向于用机制解决，而不是靠口号。比如要求先写自己的判断再看 AI 输出，要求每次修复必须带最小复现和根因说明，要求评审里讲清楚“为什么这么改”。这些动作看起来慢，但长期收益非常大。没有这些机制，团队会出现一种假繁荣：交付很快，但质量和可维护性越来越差。
Rust 在这个阶段的现实优势
再说一个我最近反复思考的点：Rust 在这个阶段会出现一种“非对称优势”。我不是语言信徒，也不想鼓吹任何语言，但工程现实是，Rust 的历史短板主要在学习曲线和人力成本，而 AI 正在显著削弱这些短板。
同时，Rust 在安全性、性能、并发可控性上的先天优势还在。于是就会形成一个结果：短板变浅，长板仍在，长期壁垒反而更清晰。这个判断不是理论推演，而是来自日常开发体验。以前我们会担心“Rust 会不会拖慢团队”，现在这个担忧并没有完全消失，但已经弱了很多。
尤其在基础软件里，长期稳定性和可维护性本来就更值钱，AI 只是把这条路走得更快一些。换句话说，AI 没有改变 Rust 的底层价值，只是降低了获得这个价值的门槛。
基础软件到底能不能用 AI 写？怎么分工
这个问题我们其实讨论过很多次，也是我自己最早的顾虑之一。我的结论是：基础软件当然可以用 AI 写，而且应该用；但不能把它当“全自动开发”，而要当“高吞吐执行器”。
为什么这么说？因为基础软件不是把功能跑通就结束，它的核心是长期稳定、可演进、可维护。AI 在“实现一段代码”这件事上已经很强，但在“承担系统后果”这件事上，责任始终在我们。谁来定边界、谁来做取舍、谁来兜底线上行为，这些都不能外包。
我现在更认可一种分工方式：我负责方向和约束，AI 负责高效执行。比如架构边界、协议语义、错误码策略、关键数据结构，这些必须我来拍板；而样板代码、重复改造、测试补齐、文档整理、重构初稿，这些非常适合交给 AI 去做。这样既能提速，又不会把系统控制权丢掉。
再具体一点，我通常会把任务分成三层。第一层是“不能错”的核心层，比如状态机语义、一致性路径、错误处理边界，这层一定是人工主导。第二层是“可以快”的实现层，比如接口封装、工具函数、常规适配，这层 AI 可以承担大头。第三层是“必须验证”的收敛层，比如回归测试、压测结果、线上可观测性，这层由人来做最终验收。
这种分工看起来没有“全自动”那么酷，但长期效果最好。因为它符合一个现实：AI 负责速度，人负责方向；AI 提供候选，人做最终判断。基础软件能不能走远，最后看的不是一天能生成多少代码，而是十个月后系统还能不能稳定演进。
最后的判断
如果一定要用一句话总结我现在的判断，那就是：AI 时代对基础软件是利好，但这个利好只属于那些能把方向、架构、权衡和执行闭环做扎实的人。代码不会消失，代码只是从“目的”回到“手段”；而真正昂贵的能力，正在变成做对决策、做成产品、并长期维护它。
焦虑当然会有，我自己也会有。尤其是看到“写代码门槛变低”这件事，很容易不自觉地怀疑自己的壁垒。但比焦虑更重要的是每天问自己一个问题：今天我是在做纯执行，还是在提升系统决策质量？只要这个问题的答案越来越偏向后者，竞争力就在上升。
这可能就是我眼里 AI 时代基础软件最真实的变化：门槛确实在降，但壁垒没有消失，它只是从编码本身，迁移到了判断力和系统能力。对我来说，这不是坏消息，反而是一个更清晰的方向：把精力放在做对事、把事做成、并把它长期维护好。