Context Engineering：Prompt Engineering 之后，AI 开发真正重要的是什么？
如果你使用过 Cursor、Claude Code 或其他 AI Coding 工具，应该遇到过这样的情况： 同样一个模型，同样一句需求，在一个项目里表现很好，换到另一个项目却经常答非所问。 你让它修改一个接口，它改错了文件；让它增加一个功能，它没有遵守项目现有的架构；明明项目里已经有一个工具类，它却重新写了一套；甚至你已经告诉它某个规则不能违反，它还是会继续这么做。 很多时候，问题并不是模型不会写代码。 而是它不知道足够多的东西。 这也是 Context Engineering 开始受到关注的原因。 如果说 Prompt Engineering 关注的是「我应该怎么告诉模型」，那么 Context Engineering 更关注：为了让模型完成任务，我到底应该让它知道什么？ 这两个问题看起来很接近，但面对复杂 Agent 时，区别会越来越明显。 1. Prompt Engineering 解决什么问题 Prompt Engineering 并没有过时。 在简单任务中，一个好的 Prompt 仍然非常重要。 例如： 请把下面的 方法重构一下： 要求： 1. 保持接口兼容； 2. 降低数据库查询次数； 3. 增加异常处理； 4. 给出修改后的代码。 这里已经包含了任务、约束和输出要求。 对于一次性的文本生成、代码生成、总结、分类等任务，这样的 Prompt 通常已经足够。 但软件开发中的很多任务并不是一次性的。 例如： 给这个项目增加用户注册功能。 这句话真正包含的信息其实非常少。 Agent 要完成它，至少还需要知道： 项目是什么框架？ 目录结构是什么？ Controller 怎么写？ Service 怎么写？ 数据库表在哪里？ Model 怎么定义？ 验证规则是什么？ 异常怎么处理？ 返回格式是什么？ 认证体系是什么？ 测试怎么写？ 哪些代码不能修改？ 如果这些信息没有进入 Agent 的上下文，那么你即使把 Prompt 写得再漂亮，也很难得到稳定的结果。...