很多开发者最近会有一种很明显的感觉：

现在的AI，已经越来越不像“代码补全工具”。

它可以理解项目结构。

可以读多个文件。

可以分析调用链。

可以修改代码。

可以跑测试。

甚至可以自己发现一些潜在问题。

有时候你看Codex完成一个任务，会产生一种感觉：

它已经很像一个真正的开发者了。

但真正把AI放进真实项目以后，你又会发现另外一种情况。

AI写出来的代码：

没错。

测试：

也通过。

结构：

甚至比原来的更漂亮。

可你看完以后还是会觉得：

“这里不太对。”

不是语法不对。

也不是功能不对。

而是你隐约知道：

这个抽象以后会麻烦。

这个地方现在不应该重构。

这个依赖虽然能加，但未来大概率会变成负担。

这个设计今天很漂亮，半年以后可能很难维护。

这种判断往往很难直接写成一条规则。

却是有经验的开发者经常会做出的判断。

这就是AI Coding进入真实工程以后，一个越来越值得关注的问题：

AI越来越会“开发”，但它仍然不等于拥有完整的工程直觉。

---

一、真实场景：AI给出的方案都对，但资深开发者还是会说“别这么做”

假设你正在维护一个已经运行很多年的订单系统。

里面有三段很相似的逻辑。

从代码角度看：

重复。

不优雅。

明显可以抽象。

于是你让Codex优化这个模块。

AI很快发现重复逻辑，提出：

抽取公共Service。

统一数据结构。

把几个接口改成统一调用方式。

从代码质量上看，这个方案甚至非常漂亮。

重复减少了。

职责更清楚。

测试也通过。

但项目里的老开发者看完以后，可能说：

“这三个地方先不要合并。”

为什么？

因为他知道：

这三段代码虽然现在长得很像，但分别属于三个业务方向。

接下来半年：

一个可能继续增加风控。

一个可能迁移到新系统。

另一个可能彻底下线。

今天强行抽象到一起，短期看代码更漂亮，长期反而会让几个本应独立变化的模块绑在一起。

AI看到的是：

重复代码。

资深开发者看到的是：

未来变化方向不同。

两个人都没有“看错”。

只是他们优化的目标不同。

---

二、为什么会发生？因为工程不是只判断“现在对不对”

AI非常擅长处理当前状态。

它可以分析：

现在代码是什么。

现在测试结果是什么。

现在模块之间怎么调用。

现在有哪些重复逻辑。

于是它可以回答：

这段代码能不能简化？

这个模块能不能抽象？

这个函数能不能优化？

但工程里的很多关键判断，其实不是：

现在能不能。

而是：

现在值不值得。

例如：

现在增加一个缓存层，性能可能提升。

但数据一致性成本是否值得？

现在把两个模块合并，结构可能更优雅。

但未来变化方向是否一致？

现在引入一个新框架，开发速度可能更快。

但团队是否有维护能力？

所以工程判断里存在一个非常重要的区别：

Technical Correctness ≠ Engineering Fitness

技术上正确。

不代表工程上合适。

---

三、工程机制：AI看到的是“当前状态”，工程师还在估计“未来变化”

可以把软件工程中的判断拆成两个层次。

第一层：

Current-State Optimization

针对当前系统进行优化。

比如：

减少重复。

提高性能。

简化结构。

增加测试。

降低复杂度。

AI很擅长这一层。

因为大量证据都存在于：

代码。

文档。

测试。

日志。

第二层：

Future-Change Estimation

判断系统未来会怎么变化。

比如：

这个模块未来会不会频繁改？

这个接口是不是快要废弃？

这个业务方向未来是不是会独立出去？

团队是否愿意长期维护这个抽象？

这类信息往往没有完整写进Repository。

甚至没有人能百分之百确定。

它来自：

业务历史。

团队经验。

过去踩坑。

组织习惯。

产品路线。

长期维护经验。

这些东西共同组成了我们经常说的：

工程直觉。

---

四、工程直觉真正是什么？它不是“凭感觉写代码”

“直觉”这个词很容易让人误解。

好像资深工程师只是：

“我觉得这里不应该这样。”

实际上成熟的工程直觉，通常来自大量被压缩过的历史经验。

比如一个开发者以前遇到过：

过度抽象导致修改困难。

缓存导致一致性事故。

过早微服务化导致运维成本上升。

公共模块最后变成没人敢动的依赖中心。

于是下一次看到类似结构时，他不需要重新推导完整证明。

会快速意识到：

这里有危险。

所以工程直觉更像一种：

Experience Compression

也就是：

大量历史工程结果，被压缩成快速判断。

AI当然也见过大量代码模式。

但真实项目里的工程判断还有一个特点：

很多风险是：

局部项目特有的。

它可能根本没有写在代码中。

---

五、为什么AI容易把“最佳实践”用在错误的地方？

这是一个很典型的问题。

AI很容易知道：

DRY。

模块解耦。

单一职责。

依赖注入。

缓存。

事件驱动。

微服务。

这些都是合理工程原则。

但工程真正困难的是：

什么时候不要用它。

比如DRY原则：

不要重复自己。

听起来非常合理。

但如果两段代码只是“现在碰巧相同”，未来变化方向不同，提前抽象反而会制造耦合。

再比如微服务：

理论上可以降低模块耦合。

但一个只有两三个人维护的项目，如果拆成十几个服务，运维复杂度可能直接超过收益。

所以最佳实践最大的问题是：

它们通常是条件成立时的最佳实践，而不是无条件正确。

AI越擅长调用模式，越需要有人判断：

当前条件到底是否成立。

---

六、为什么AI越强，这个问题反而越容易被忽略？

因为AI现在给出的方案越来越成熟。

以前AI写出一段明显幼稚的代码。

你会马上警惕。

现在它可能给你：

清晰的模块划分。

完整的设计理由。

漂亮的代码。

测试。

风险说明。

整个方案非常专业。

于是人的心理会发生变化：

“它已经考虑得很全面了。”

但AI方案成熟以后，真正需要Review的可能不再是：

语法。

框架用法。

简单Bug。

而是：

这个设计和我们这个项目到底适不适合。

也就是说：

AI越强，错误越可能从“明显技术错误”转向：

合理但不合适的工程决策。

这类错误更难发现。

---

七、为什么未来这个问题会越来越明显？

因为Agent正在承担越来越大的任务。

以前：

AI改一个函数。

工程直觉影响有限。

未来：

AI可能参与：

模块重构。

数据库迁移。

架构调整。

大型Feature。

技术方案选择。

任务范围越大，就越需要判断：

长期成本。

变化方向。

团队承载能力。

风险收益比。

而这些恰恰不是单纯增加代码生成能力就能完全解决的。

所以未来AI Coding里一个很重要的趋势可能是：

执行越来越自动化，但工程判断越来越集中到关键节点。

人不一定要逐行写代码。

但需要在关键设计点决定：

这里到底应不应该这么做。

---

八、自测指标：你的任务有多少需要“工程直觉”？

这里可以建立一个指标：

工程判断密度

它表示：

一个AI任务里，有多少关键问题无法单纯通过“代码是否正确”判断。

可以观察四种情况。

第一：

任务是否涉及长期架构？

比如：

模块拆分。

公共层设计。

服务边界。

这种判断密度高。

第二：

是否涉及难以量化的Trade-off？

例如：

性能和复杂度。

抽象和可维护性。

短期速度和长期成本。

判断密度高。

第三：

是否需要大量项目历史才能判断？

比如：

“这个旧逻辑为什么一直没人改？”

如果没有历史信息，很容易判断错。

第四：

一个方案即使测试全过，你是否仍然需要人工决定能不能合？

如果经常如此，说明你的工作已经进入高工程判断密度阶段。

---

九、怎么降低AI缺少工程直觉带来的风险？

第一：把“项目历史”变成显性Context

不要只给AI当前代码。

可以补充：

为什么过去采用这个设计。

哪些方案曾经失败。

哪些模块预计未来变化。

哪些地方属于历史兼容。

工程直觉有一部分，其实可以被文档化。

一旦写出来，它就不再只是某个老开发者脑子里的知识。

---

第二：让AI同时回答“为什么现在不要这么做”

很多Prompt只问：

“最佳方案是什么？”

可以增加：

“有哪些看起来更漂亮，但现在不应该采用的方案？”

这样能让AI从单纯优化转向Trade-off分析。

---

第三：高工程判断任务，不要直接让AI从发现问题跳到修改

比如：

AI发现架构问题。

不要马上：

“那就改。”

可以先分成：

现状分析。

未来变化假设。

方案比较。

人工选择。

执行。

把工程判断和代码执行拆开。

---

第四：让AI区分“代码证据”和“工程假设”

例如让它说明：

哪些判断可以从Repository直接确认？

哪些判断依赖对未来的假设？

哪些判断需要业务或团队信息才能确认？

这样你能快速看到：

AI真正“不知道”的地方。

---

十、还有一个很重要的方法：不要要求AI永远“优化”

很多AI任务从一开始就带着一个危险动词：

“优化。”

优化意味着：

系统还有地方可以变得更好。

但“更好”的维度是什么？

性能？

可读性？

抽象程度？

开发速度？

稳定性？

如果没有先定义，AI很容易选择自己能够识别的指标进行优化。

于是：

代码更漂亮了。

工程却未必更好。

更有效的任务是：

“在不增加系统复杂度的前提下，把接口P95降低20%。”

这时候工程目标才真正明确。

---

十一、为什么工程判断密度低时，Plus通常已经够用？

如果你的日常任务主要是：

明确Bug。

常规功能。

工具脚本。

普通测试。

局部代码修改。

这些任务的大部分质量可以通过：

代码正确性。

测试。

明确验收标准。

直接判断。

工程判断密度较低。

这种情况下，Plus通常已经能够覆盖大量实际工作。

因为你需要的主要还是：

更快执行。

---

十二、工程判断密度高，也不代表直接升级Pro

如果你现在经常遇到：

AI方案看起来都对。

但最后还是选错。

架构经常返工。

过度抽象。

技术债增加。

第一反应不应该是：

“需要更强模型。”

因为真正缺少的可能是：

项目历史。

决策标准。

Trade-off框架。

人工Review。

如果这些Context没有进入工作流，更强AI同样可能做出：

更漂亮但不合适的方案。

所以应该先把工程判断机制补起来。

---

十三、什么时候Pro才真正开始匹配？

更接近Pro的状态是：

你的AI工程流程已经比较成熟。

项目约束有文档。

关键架构决策有记录。

高风险设计会单独Review。

AI能够区分事实和工程假设。

人能够判断长期Trade-off。

但你的真实工作里仍然持续存在：

大型Repository。

复杂架构分析。

长时间Agent任务。

大量跨模块工程工作。

多个高价值任务并行。

这时候更高AI能力和容量才更容易真正转化成生产力。

判断逻辑不是：

“AI没有工程直觉，所以我要Pro。”

而是：

“我已经把项目里的工程知识尽可能显性化，现在需要更强AI帮助处理更大规模的工程问题。”

---

最后：AI会越来越像开发者，但真正稀缺的是“知道什么时候不要写”

AI越来越会：

分析代码。

设计方案。

实现功能。

运行测试。

它当然会越来越像开发者。

但真正优秀的工程师，价值从来不只是：

会写。

还包括：

知道什么时候不该抽象。

什么时候不该重构。

什么时候不要引入新技术。

什么时候一个“不漂亮”的方案反而是当前最安全的方案。

这些判断背后不是某一条编码规则。

而是：

项目历史。

未来变化。

风险经验。

业务理解。

长期维护成本。

共同形成的工程判断。

所以未来人和AI真正合理的分工，可能不是：

人负责想，AI负责写。

而是：

AI负责扩大分析和执行能力，人负责在关键工程节点做最终取舍。

如果你的任务大多可以靠明确规则判断：

Plus通常已经够用。

如果你的工程体系已经成熟，而每天仍然需要大量复杂、高判断密度的AI协作：

Pro才真正开始匹配。

AI时代真正稀缺的开发能力，可能不再是：

“我知道怎样把它写出来。”

而是：

“我知道这个东西虽然能写出来，但现在到底该不该写。”

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道！