工程判断力：AI编程工具的真正瓶颈

很多人觉得AI编程的短板在模型水平，实际上关键在于判断力。

让AI写个快速排序，它能给出标准的教科书实现。但让它决定这段代码是否需要添加异常处理、模块该在何时拆分、应该重构还是重写——它就陷入困境了。

这并非模型不够智能。production级工程中真正有价值的部分，从来不是敲代码的效率，而是懂得何时该停下来思考。

近日GitHub上的addyosmani/agent-skills项目新增了3009个星标，它所做的本质上就是把资深工程师脑海中"无需思考就知道"的判断经验，转化为可复用的技能库。但这个项目的出现恰恰揭示了一个被忽视的信号：我们已经能让AI生成优质的代码，却还不清楚如何让它像真正在production环境实战过的工程师那样做出判断。

代码生成与工程判断是两码事。前者属于语法问题，后者属于权衡问题。你可以让模型掌握所有编程语言的语法，但要教会它"这个API调用可能在半年内被废弃"这样的判断，需要的是对生态的洞察、对历史的记忆、对风险的敏感。这些无法从代码仓库中习得，它们藏在废弃公告里、踩坑记录里、某次深夜线上故障的复盘中。

为何这种判断力差距如此关键？因为当把AI编程工具放到真实项目中，你会发现它真正受阻的地方从来不是写不出代码，而是生成的代码你不敢使用。它不了解你团队的编码规范，不知道哪些依赖已被内部禁用，不清楚某个看似简单的改动会触发哪些监控告警。这些知识在文档中写不完整，在代码里看不透彻，它们存在于团队的集体记忆里，存在于那些"上次这么做出了问题"的教训中。

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

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

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

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

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

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