去年Q3，某硅谷团队收到一份AI提交的代码。单元测试全绿，语法零警告，评审流程一路绿灯。上线第二天，监控报警——AI用了团队刚废弃的依赖库，设计模式撞上了架构文档的红线。代码看起来对极了，放在系统里却错得离谱。
这不是Prompt Engineering（提示工程）的偶发事故，而是它的结构性天花板。当AI工具开始批量进入软件工程流程，一个更隐蔽的问题浮出水面：我们教会了模型怎么写代码，却没教会它读懂一个项目。
提示工程的"视力缺陷"
Prompt Engineering擅长处理孤立任务。但软件开发从来不是任务的简单串联，而是被现有代码、团队习惯、业务规则层层约束的决策链条。问题的根源不是提示写得不够好，是模型的视野被锁死在一个小窗口里。
当模型看不到代码库的其余部分，问得更好也无济于事。就像让一位厨师只看菜谱却不准进厨房——他能复述步骤，但不知道盐罐在哪、前任厨师把糖换成了代糖、以及今晚有客人麸质过敏。
用Prompt Engineering搭建任何规模稍大的系统，最终都会滑向脆弱和高维护成本的泥潭。工程师被迫不断调整提示来填补模型的知识缺口，然后在新模型发布或问题复杂度上升时，一切归零。
更麻烦的是调试。输出稍有变化，你就要在成串的提示里大海捞针。模型版本一更新，昨天完美的指令今天可能输出完全不同的格式，或者埋进一个逻辑错误。失败时你甚至分不清是提示问题还是上下文缺失——因为你无法复现模型当时的精确状态。
「当AI系统只依赖提示，系统就变得难以维护、极易损坏。」一位在AI编码工具上踩过坑的工程师这样总结。团队被迫写出 absurdly complex（荒谬复杂）的提示来锁定正确行为，而这些提示本身变成了无法维护的烂摊子，塞满对模型"思考方式"的假设。
Context Engineering（上下文工程）是什么
Context Engineering的核心主张很直接：停止往提示里塞一切，转而设计模型工作的环境。
具体怎么做？把项目的依赖图谱、旧架构决策的推理过程、团队处理异步操作的偏好——这些原本不存在于提示窗口里的信息——结构化地喂给模型。不是让模型猜，是让它看见。
错误处理是个典型场景。没有系统感知时，模型只会生成通用的try/catch块，因为它对结构化日志、错误类型定义、系统的指标埋点模式一无所知。代码能跑，但缺了关键拼图，最终还得人来擦屁股。
Context Engineering试图把"项目常识"变成可检索、可版本控制的基础设施。代码风格指南、架构决策记录（ADR）、最近的PR讨论、甚至某位资深工程师三年前写的技术备忘录——这些不再散落在Slack和Confluence里，而是被索引成模型可调用的上下文。
「我们需要的是awareness（感知），而不只是good instruction（好指令）。」提出这一概念的工程师强调。Prompt Engineering优化的是问题的表述方式，Context Engineering解决的是问题被回答时的信息完备性。
从"怎么问"到"给什么"
两者的分野可以这么理解：Prompt Engineering是面试技巧，Context Engineering是开卷考试允许带多少参考资料。
前者假设模型已经知道一切，考验的是你能不能引导它想起来；后者承认模型的训练数据有边界，关键是把边界外的信息以它理解的方式补进去。
实践中，Context Engineering正在催生新的工具形态。一些团队开始用向量数据库存储代码语义，让模型在生成前先做检索增强（RAG）；另一些团队在CI/CD流程里嵌入"上下文检查"，确保AI提交的代码符合当前架构状态，而不是训练数据里的过时范式。
这也不是说Prompt Engineering要被淘汰。对于一次性任务、探索性编码、或者上下文确实有限的场景，精炼提示依然高效。但一旦进入生产级代码库，缺乏上下文的"正确代码"就是技术债务的自动化生产线。
谷歌DeepMind的一项内部研究曾指出，AI辅助编码的最大瓶颈不是模型能力，而是"上下文窗口的管理成本"。当代码库超过一定规模，人工筛选该给模型看什么，本身就成了繁重的工程问题。
这也是Context Engineering的下一个战场：不是简单地"多给点上下文"，而是智能地决定给什么、什么时候给、以什么格式给。这涉及代码的向量化表示、变更影响的自动追踪、甚至模型对"哪些信息相关"的元推理能力。
回到开头那个硅谷团队的故事。他们在事故后做了一件事：把架构文档和依赖废弃清单接入了AI的上下文管道。三个月后，同类错误下降了87%。但工程师们发现新问题——AI开始过度保守，遇到不确定的设计决策时倾向于回避，把选择权踢回给人类。
这算是进步还是新的麻烦？当你的AI助手终于学会了"看说明书"，它会不会变得太胆小？
热门跟贴