上下文工程根因

Bret Taylor 给出两条现在就能落地、不必等模型进步的具体方法:

方法一:让AI互相审查,用"组合概率"弥补单个模型的不可靠性。这是一个简单的数学逻辑:如果一个生成代码的AI agent只有90%的准确率,单独看不算很好;但反过来想,"做一个能抓出另外10%错误的AI",可能是一个远比"直接把生成准确率从90%提到99%"更容易解决的子问题。把"生成"和"审查"两个模型串联起来,理论上就可以把整体准确率从90%推到接近99%——本质上是在用算力去换取认知可靠性(用推理层数换正确率),而不是单纯期待某一个模型自己变得完美。

方法二(更核心):把每一次AI生成错误都当成"上下文缺失"的信号,做根因分析(root cause analysis),而不是发现错误就直接手动改掉。Taylor以Sierra内部真实的做法为例:公司有一位工程师全职负责维护"服务于Cursor实例的MCP(Model Context Protocol)server"。团队的核心原则是——如果Cursor生成了错误的代码,第一反应不是"我把这处bug改掉就完了",而是去追问:Cursor当时缺了什么上下文,才会做出这个错误判断?能不能把这个上下文补上,让它下一次自动生成正确答案? 这个过程本质上就是"context engineering(上下文工程)"——不断给AI补齐它做判断时应该具备、但当时缺失的信息,使同类错误不会反复出现,而不是每次靠人工一次次擦屁股。

Taylor把这一整套方法总结为一句对创业者和团队的直接提醒:"想现在就拿到生产力收益的人,不能干等模型自己变魔术般变好"——你必须把这件事当成一个系统工程去经营:主动做根因分析、主动补充上下文、主动搭建AI互审机制,才能在模型还不够成熟的当下就把收益兑现。他认为这正是"应用层AI公司(applied AI company)存在的意义"——替客户把这套系统工程搭好,而不是简单调用底层模型的API。

Sierra自己的产品实践映证了同一逻辑:不是一次性把AI agent做到完美,而是提供一整套工具帮客户把"自动解决率"从65%持续优化到75%——识别用户不满的具体原因、找出该给agent补充的新能力,本质上都是同一套"根因分析+持续补充上下文"的方法论,只是应用在客服场景而不是编码场景。