Cursor花3年堆了5层工具栈，用户发现第6层才是命门

AI编程工具圈最近有个诡异现象：团队把提示词工程、模型微调卷到极致，agent（智能体）该犯的错一个没少。

Cursor、Windsurf、Devin这些头部产品，过去18个月疯狂堆叠repo规则、记忆系统、测试套件、监控层。投入算力涨了340%，agent引发的线上事故却只降了12%。

问题出在哪？不是agent不够聪明，是它根本看不懂你在做什么生意。

五层工具栈，漏了最关键的一层

现在的AI agent技术栈已经相当完整。repo instructions（仓库指令）减少流程错误，memory（记忆）避免重复探索，harnesses（任务框架）支撑长周期任务，evals（评估）和monitors（监控）拦截坏输出。

这套组合拳确实让代码生成更可靠。但有个盲区：agent可以完美执行所有规则，照样把产品搞崩。

不是写出烂代码，而是改了一个从代码角度看完全合理的东西。

比如把"免费试用到期后自动降级"改成"到期后弹窗引导付费"。代码层面没问题，测试能过，但商业模式被颠覆了。agent看不到这条线背后的收入占比、用户承诺、法务风险。

这类事故在AI-native团队里反复上演。复盘时大家说的同一句话是：代码看起来对，但违背了我们早就定好的事。

产品真相不是PRD，是行为契约

很多人第一反应是"PRD（产品需求文档）写清楚就行"。但PRD是动态的、临时的、充满妥协的。它告诉团队这周做什么，不告诉agent哪些行为是已经被验证的、受保护的、可以安全依赖的。

真正缺的东西，作者称之为"Product Behavior Contract"（产品行为契约）。它回答一个更窄但更持久的问题：这个产品当下实际承诺做什么，哪些行为已被确认到足以让agent视为保护对象？

这需要捕获的东西很具体：

哪些用户状态转换已经对外承诺？（比如"7天无理由退款"不是功能，是合同条款）

哪些数据流涉及合规红线？（GDPR删除请求的处理路径，agent不能"优化"掉日志环节）

哪些交互模式承载着品牌信任？（密码重置流程的邮件文案，改一个字可能触发钓鱼警告）

没有这层，agent只能从实现细节反推产品意图。有时候蒙对，有时候悄无声息地引入产品漂移。

为什么现有工具都在回避这个问题

技术栈的五层工具都有明确的技术owner。repo规则归平台团队，evals归ML工程师，监控归SRE。产品行为契约该归谁？产品经理不会写代码，工程师觉得这是"业务逻辑"不想碰。

更深层的原因是，这东西很难量化。测试覆盖率可以跑百分比，产品意图的"保护度"怎么度量？

但回避的代价正在显现。某头部AI代码助手公司内部数据显示，agent引发的P0事故中，67%属于"产品意图违背"而非"代码质量缺陷"。修复平均耗时4.7天，是传统bug的2.3倍——因为需要跨部门对齐"我们当初到底承诺了什么"。

有个细节很说明问题。当作者和不同团队聊这个缺失层时，得到的反应分两种：没踩过坑的觉得"我们PRD挺清楚的"，踩过坑的立刻能说出三个具体场景。

这种认知分裂本身，就是产品行为契约难以落地的缩影。

可能的解法：从文档到契约

作者没有给出完整方案，但提了一个方向。产品行为契约需要满足几个条件：机器可读（agent能直接消费）、版本化（和产品代码一起演进）、可验证（有自动化检查点）。

这听起来像测试，但测试验证的是"代码是否符合预期"，契约声明的是"哪些预期本身不可动摇"。

现有技术栈的每一层都在告诉agent"怎么做"。产品行为契约要告诉它"什么不能碰"——不是通过否定列表，而是通过正面声明哪些行为已被确认、受保护、可依赖。

这个区分很微妙，但决定了agent是"在约束下自由发挥"还是"在黑暗中摸索边界"。

有个类比可能帮助理解。现在的agent技术栈像是给司机配备了高精度地图、实时路况、自动驾驶算法，但没说清楚"这辆车是救护车还是私家车"。两种车都能开，但闯红灯的后果完全不同。产品行为契约，就是那张贴在仪表盘上的车辆性质声明。

当Cursor的agent在下个版本开始支持"产品意图感知"时，第一个吃螃蟹的团队会发现，他们过去三年写的PRD、wiki、会议纪要，有多少能直接翻译成机器可消费的契约条款？