从提示工程到上下文工程：AI 开发者真正需要的技能
来源：dev.to — 2026-09-06
📋 概述
作者提出 LLM 应用最危险的失败不是糟糕的 prompt，而是一个完美 prompt 包裹着错误的上下文：系统仍会自信作答，只因检索到的政策文档已过期、工具 schema 含糊、用户画像过时、或给了三个冲突示例却没定优先级。这正是从 prompt engineering 到 context engineering 的转向——前者问「这句指令该怎么措辞」，后者问「模型该看到什么信息、按什么顺序、受什么约束、来自哪些源、有哪些权限、花多少钱」。而后者在 2026 年做真实产品的开发者身上通常是更难的那个问题。
🔑 核心要点
- 核心洞见：模型只会对你给它的内容做推理，但「给它一切」很少等于「给它对的」——无关上下文会稀释约束、翻出过期政策、让模型以不可预测方式调和冲突信息
- 把上下文窗口当预算而非仓库：每个来源都要有优先级、体积估算与被纳入的理由；预算耗尽先丢低优先级，且必带的必需项若超预算就该压缩/拆分/失败请求而非静默塞入
- 契约要先于知识：把任务契约（角色/目标/允许源/禁止行为/输出格式/信息缺失与升级时的行为）放在检索证据之前，文档就不再是自由漂浮的真相而是受约束使用的输入
- 检索要为决策质量而非仅相似度：embedding 相近的已退休两年前的价格文档照样被捞出来——要按产品版本、地域、status、生效日期、权威度过滤后再进上下文，过滤先于生成通常比让模型忽略坏材料更安全
- 把上下文工程做成系统工程：工具 schema 也是 prompt（用 enum 收紧合法值）、记忆要有 scope/confidence/来源/过期、敏感数据最安全是根本别进上下文、为缺失/过期/冲突/越权源建 eval、给每个请求记上下文清单以便复现诊断
💡 金句
好 prompt 能改进一个答案；好的上下文工程让系统更容易被推理、更安全地运行、出错时也更便宜地被调试。
👍 0
👎 0
← 返回 dev.to 首页