Sun Tzu的13条军规：AI代理把产品经理逼成了考古学家

Claude Code 3分钟写完一个功能，Codex在你睡觉时提交PR，Cursor和Windsurf把IDE变成了聊天窗口。软件开发的成本，已经塌了。

但"知道该做什么"的成本，一分没降。

这个裂缝里，长出了一本奇怪的书。《The Art of Agents》，把《孙子兵法》的13章映射到AI代理系统的工程实践。作者Jacob Verhoeks的观点很直接：当代理能在一个下午搭出全栈应用，问题不再是"能不能做"，而是"该不该做，以及怎么知道它有没有用"。

规格文档是奖杯，不是发令枪

传统流程是写需求、评审、开发、测试。Verhoeks说这套在代理时代会失效，因为"提示词是愿望，规格是契约"。提示词告诉代理你想要什么，规格告诉整个系统"正确行为长什么样"——而且换模型也不该影响它。

AWS的Kiro试过把规格驱动开发（spec-driven development）放在核心。想法没错，但早期用户反馈像穿了紧身衣。OpenSpec换了个思路：规格是活的，跟着代码一起长，不是一道必须跨过去的门。

关键区别在于时机。你不是先写规格再开发，而是先快速搭一个版本，扔给真实用户，收集反馈，再写下你真正学到的东西。规格是跑完比赛赢来的奖杯，不是起跑前的热身操。

Verhoeks的原话是：「The spec is not the starting gun. It's the trophy you earn by running the race.」

设计的第一原则：不信任

代理会即兴发挥，这是它的本性。你的系统不能允许。

"未被允许的即禁止"——Verhoeks列出一串机械约束：工具白名单、schema验证、输出解析、token和迭代次数的硬上限。别指望模型自觉，要定义契约并强制执行。

一个反例是常见的"坏工具"设计：返回5000行JSON，让模型自己找答案。好的工具接受精确参数，在确定性代码里做重活，只返回代理需要推理的那部分。工具对了，代理显得聪明；工具错了，再精致的提示词工程也救不了。

这有点像给自动驾驶汽车装护栏。不是不相信AI的能力，是不相信"能力"在边界情况下的稳定性。

LLM是火，别用来煮开水

Verhoeks的第四条原则很扎心：知道什么时候不该用代理。

大语言模型（LLM，Large Language Model）是火——条件对了威力巨大，条件错了就是烧自己的补给线。一条SQL能解决的，写SQL；规则引擎能搞定的，写规则。在每个代码路径塞LLM的架构师，和纵火焚粮的将军没有区别。

这个判断需要经验。代理适合的是"意图模糊、路径多变、需要权衡"的场景，不是"输入确定、输出确定、有最优解"的场景。区分这两者的能力，正在成为新的技术门槛。

死掉的项目是最肥的土壤

书里最反直觉的观点关于失败。Verhoeks说"学习即产品"——每次实验都在丰富公共知识库，腐烂的实验产生学习，学习喂养下一个想法，循环加速。

代码会消失，但学习留存下来。而且学习和代码不同，它会增值。

这对习惯了"交付即成功"的产品经理来说，需要转个弯。代理时代的开发更像科研：假设、实验、证伪、沉淀。规格文档里写的不是"我们要做什么"，而是"我们试过了什么，学到了什么，现在决定做什么"。

Kiro的紧身衣问题和OpenSpec的灵活路线，本质上是对"学习如何制度化"的不同回答。AWS选择了先约束后释放，OpenSpec选择了边跑边定规矩。哪种更好？可能取决于你的组织消化失败的速度。

Verhoeks把《孙子兵法》搬出来，不是为了装古典，是因为代理系统的工程和战争有相似的结构性：资源有限、信息不全、对手（或环境）会反应、决策必须在迷雾中做出。Sun Tzu的"知己知彼"在这里变成"知模型之能与不能，知用户之需与不需"。

书的结构很工整：每章以一条Sun Tzu原则开头，用真实案例和反模式教概念，以实地报告收尾。13章对应13个工程决策点，从规格定义到工具设计，从错误处理到人机协作。

一个细节值得玩味：Verhoeks把2026年3月作为发文时间，但讨论的是正在发生的工具链变革。Claude Code、Codex、Cursor、Windsurf——这些名字在2024-2025年已经密集出现，到2026年3月，它们的定位可能已经从"辅助编程"滑向"代理协作"。

如果这本书的预测准确，产品经理的工作流会变成什么样？可能是这样：早上用自然语言描述一个想法，中午代理给出可运行的原型，下午扔给5个真实用户，晚上根据反馈写规格文档。第二天重复。

考古学家挖的是别人的遗迹，未来的产品经理挖的是自己的昨天。