AI 编程的真正竞争：哪款工具最能编码工程判断力

要点

• AI 原生工程师本来就有一套个人工作系统，工具应该把这套做法明确下来。

• 动态工作流很有潜力，但智能体更多，不等于工程做得更好。

• 智能体群可能花大价钱产出废话：token 成本、虚假共识、隐藏的复杂性，都值得警惕。

• 真正的问题不只关乎 Claude Code，对 Codex、OpenCode 和任何智能体都适用。

• 胜出的工具会提供更好的方式来编码判断力，而不只是提供更强的模型。

🧭 AI 原生工程师本来就有工作流

我认识的每一位 AI 原生工程师，都有一套个人工作系统。它不一定被写下来，但它确实存在。

做了 20+ 年工程，我不会只是“让它写代码”。我会带着一套工作流：修改前先读懂现有系统，找到最小的安全改动，实施前定义什么叫“完成”，隔离高风险修改，明确安排验证，审查差异时想着“这些代码会不会让我凌晨 2 点被叫醒”，并为下一次运行留下上下文。

AI 智能体不会消除这套流程。它们会让流程质量变得更加重要。工作流薄弱时，智能体只会更快地跑向错误方向。这也是我在《编码后的判断力成为新的护城河》中提出的观点：一旦这些判断被结构化、能够复用，就不再困在个人脑中，而会成为基础设施。这也始终是不再把智能体视为“仅仅是工具”的真正意义。

⚠️ 风险：智能体群可能花大价钱制造废话

我乐观，但不盲目。

Anthropic 提醒，动态工作流使用的 token 可能远多于一次普通 Claude Code 会话，文档也说明了并发数量和智能体总数的限制。这是负责任的产品做法，但也说明：这层抽象并不是免费的。token 成本不是纸上谈兵：我最近追查过一个后台智能体，它从我的每周配额中悄悄烧掉了超过十亿个 token。

更多智能体，也可能意味着更多重复推理、更多可能引入错误假设的环节、虚假共识带来的盲目自信，以及漂亮的最终答案背后更多隐藏的复杂性。输出精致、得分很高，不等于它是对的。我以前就写过：高分不等于好分。

所以，动态工作流不该成为每项任务的默认模式。它适用于那些流程质量足以改变结果的工作。

🛠️ 这不只是 Claude Code 的问题

更好的问题不是“Claude Code 这项功能有没有用”，而是：什么工具能帮助工程师更好地使用 AI 编程智能体，无论是在 Claude Code、Codex、OpenCode，还是其他任何成熟的智能体环境中？

模型会继续进步，但团队仍然需要明确控制机制：任务约定是什么，先收集哪些证据，哪些边界不能碰，什么时候要请求批准，完成前必须运行哪些验证，什么时候需要另一个智能体审查，以及哪些信息应留下来供后续工作使用。

这些问题属于工程流程，并不局限于某个模型。最终胜出的工具，不会只是接入更强的模型，还会提供更好的方式来编码工程判断力。

这是三篇文章中的第二篇。下一篇：我会把动态工作流用到真实项目里，看看哪些做法经得起实战。