同一模型不同人问同一问题效果迥异,根本原因在于 prompt 上下文质量而非模型本身;大上下文窗口反而是惰于筛选的陷阱。
两个工程师向同一个 AI 问同一个问题。一个得到了资深级别的设计评审,另一个得到了一个微笑的自信废话。模型在他们之间没有变。燃料变了。
这就是上下文工程,这是整个游戏。每个人都在忙着争论哪个模型更聪明,同时却在生产环境中发送读起来像是在停车场发现的一张便利贴的提示词。模型是一个推理引擎。推理什么?推理你设法放在它面前的东西。如果你给它氛围,它就会返回氛围。
这里有一个反直觉的部分:大多数团队这个问题恰恰搞反了。他们以为更大的上下文窗口已经解决了问题,于是把整个代码库都塞进提示词里,然后疑惑为什么答案反而更差了。更多的上下文不是更好的上下文。是一堆更大的干草。模型在长输入上的表现会下降,人类也会:注意力变薄,关键细节淹没在你的样板文件和架构决策记录之间,答案就漂移了。200K-token 的窗口不是跳过筛选整理的理由。对于拒绝筛选整理的人来说,这是一个陷阱。
真正的技能不是写巧妙的提示词。是像一个证据管理员——为一个非常快、非常字面的初级员工,他从未见过你的代码库,从未参加过你们的站会,也不会问澄清问题。你的工作是决定什么算作证据。
在你点击发送之前,运行这个。复制粘贴友好:
失败的输入,原文照录。 确切的错误、确切的查询、确切的抱怨。不是你的总结。你的总结已经破坏了信息。
相关代码,不是整个代码库。 最多三个文件。如果你无法说出是哪三个,你对 bug 的理解还不足以委托给它。
你已尝试过的方法。 两行。这阻止了模型重新运行你的死胡同并为此收取你的 token。
约束条件。 一句话定义"完成"。目标延迟时间、支持的浏览器、你不能触碰的 API。这是大多数人忘记的那一行,然后抱怨答案错了。
没有别的了。 再读一遍你的提示词。如果一个段落不能改变答案,删掉它。你刚刚一次节省了金钱并提高了准确性。
点击上面的短视频观看 40 秒版本:Your AI Is Only As Smart As What You Feed It
从 AI 编码工具中获得神奇结果的工程师们并不是在使用一个秘密模型。他们只是更善于喂养它。这是一个可以学习的技能,而且是免费的。你等待的模型升级已经坐在你的提示词框里了。