AI 编程工具真正卡在什么地方，不是代码生成能力

人们常以为 AI 编程的瓶颈是模型能力，其实是判断力。

你让 AI 写一个快速排序，它能写出教科书级别的实现。但你要它判断这段代码该不该加错误处理、该什么时候拆分模块、什么时候该重构而不是重写——它就卡住了。

这不是模型不够聪明。production-grade engineering 里真正值钱的那部分，从来都不是写代码的速度，而是知道什么时候该停下来思考。

昨天 GitHub 上 addyosmani/agent-skills 项目新增了 3009 个星标，它做的事情本质上就是把资深工程师脑子里"不用想就知道"的判断，显性化成一套可复用的技能库。但这个项目的存在恰恰暴露了一个被忽略的信号：我们已经能让 AI 写出漂亮的代码，但还不知道如何让它像一个真正在 production 环境里摸爬滚打过的工程师那样做判断。

代码生成和 engineering 判断是两回事。前者是语法问题，后者是权衡问题。你可以让模型学会所有编程语言的语法，但教会它"这个 API 调用可能在未来半年内废弃"这种判断，需要的是对生态的理解、对历史的记忆、对风险的敏感度。这些东西没法从代码仓库里学到，它们藏在废弃公告里、藏在踩坑记录里、藏在某次深夜的线上故障复盘里。

为什么这个判断力差距这么重要？因为当你把 AI 编程工具放到真实项目里，你会发现它真正卡壳的地方从来不是写不出代码，而是写出的代码你不敢用。它不知道你团队的代码规范，不知道哪些依赖已经被内部黑名单禁用，不知道某个看似简单的改动会触发什么样的监控告警。这些知识在文档里写不全，在代码里看不透，它们存在于团队的集体记忆里，存在于那些"上次这么干出了问题"的教训里。

我见过太多团队在引入 AI 编程工具后，最终都在同一个地方卡住：工具生成的代码从语法上挑不出毛病，但从工程角度看处处是坑。它会在一个需要考虑缓存一致性的地方直接写个数据库查询，会在一个需要考虑向后兼容的场景里直接改掉公共接口，会在一个需要考虑错误重试的调用链里写个一次性的请求。这些不是模型能力的问题，是它缺乏 production-grade engineering 的判断框架。

agent-skills 试图解决这个问题。它不是在教模型怎么写更好的代码，而是在教模型怎么像一个真正在一线干过的工程师那样思考。你可以把它理解成一份工程判断的检查清单：在提交 PR 之前，先想想安全性、性能、可维护性；在重构之前，先确认测试覆盖率、文档完整性、依赖兼容性。这些东西不是灵感，是纪律。它把那些原本只存在于资深工程师脑子里、难以言说的判断，变成了可以显性传递、可以系统化训练的结构化知识。

但这套方法也有边界。它假设你的工程实践已经相对成熟，假设你有一套可遵循的规范、一套可验证的流程、一套可追溯的决策记录。如果你的团队还在"能跑就行"的阶段，这些技能库反而会显得臃肿。就像你不能给一个刚开始学开车的人讲赛车走线，他需要先学会不撞墙。即使是最完善的技能库，也没法覆盖所有边缘情况——production 环境里的坑，往往藏在那些"从来没出现过"的组合里，而不是那些"经常发生"的模式里。

真正值得注意的变化不是这个项目本身有多牛，而是它标志着 AI 编程工具开始从"代码生成"阶段进入"engineering 判断"阶段。前者是让你写得更快，后者是让你写得更稳。这两者的区别，就像快速打字和快速写作——前者是技能，后者是手艺。一个学会了所有写作技巧的人，仍然可能写不出一篇好文章，因为他不知道该说什么、该对谁说、该在什么时候不说。同样的道理，一个学会了所有编程语法的 AI，仍然可能写出不 production-grade 的代码，因为它不知道该权衡什么、该警惕什么、该在什么时候停下来。

这对普通开发者意味着什么？你需要开始思考：在 AI 能帮你写代码的时代，你真正不可替代的价值在哪里？不是打字速度，不是语法记忆，而是知道在什么时候该问什么样的问题，是知道一个看似简单的改动背后可能牵扯到什么样的系统风险，是知道什么时候该相信工具的建议，什么时候该坚持自己的判断。这些东西没法外包给模型，因为它们不是关于"怎么做"的知识，而是关于"做什么"和"为什么做"的判断。

下次你看到 AI 编程工具又升级了模型能力，多问一句：它能帮我做判断吗，还是只能帮我做体力活？这两者的差距，就是工具和队友的区别。你真正需要的，到底是哪一个？