前两天用DeepSeek-V3.1重构一个老旧的微服务架构，我发现即使用同样的prompt，不同的上下文环境下效果完全不一样。当我只是简单描述要把单体应用拆分成微服务的时候，它给出的方案都是教科书式的套话，但当我把现有的数据库schema、API接口文档、服务依赖关系图都整理成完整上下文后，它生成的重构方案就很精准。

以前我也是那种疯狂钻研prompt技巧的人，什么角色扮演、思维链、few-shot，各种奇技淫巧都试过。但真正用AI来辅助开发工作的时候发现，光会写prompt根本不够用。

最核心的问题是什么呢？就是信息管理。

你想啊，我们程序员在写代码的时候，脑子里装的是什么？项目的整体架构、业务逻辑、已有的代码库、依赖关系、历史bug修复记录，还有当前要解决的具体问题。这些信息形成了一个完整的上下文环境，我们基于这个环境做决策。

AI也是一样的道理。单纯给它一个prompt，就像你突然把一个陌生人拉过来说帮我写个登录模块，他肯定懵逼。但如果你把项目背景、技术栈、代码规范、已有接口文档都给他，那效果就完全不一样了。

我最近在用AiPy做一些数据处理的项目，感受特别明显。之前用其他AI工具的时候，每次都要重新解释项目背景，上传相关文件，然后还经常出现理解偏差。但AiPy在上下文管理这块确实做得不错，它能维护整个项目的信息脉络，包括数据源、处理逻辑、历史记录等等。

更关键的是，它不是简单地调用预设工具，而是能根据具体需求写代码解决问题。比如我之前遇到一个很恶心的数据清洗任务，需要处理各种异常格式，传统的ETL工具都搞不定。但AiPy直接生成了一段Python脚本，还能根据执行结果自动调整逻辑，最后完美解决了问题。

这种体验让我意识到，Context Engineering确实比单纯的prompt engineering更重要。因为它涉及的是整个信息架构的设计，包括怎么组织信息、如何筛选相关内容、压缩冗余数据、以及隔离不同任务的上下文等等。这些都是系统性的工程问题，不是几个prompt技巧能解决的。

从技术角度来看，上下文工程要解决四个核心问题：写入、筛选、压缩、隔离。说白了就是让AI知道该记住什么、该忘记什么、该关注什么、该忽略什么。这和我们设计软件架构的思路很像，都是在做信息的抽象和管理。

当然，这个领域还有很多挑战。比如长上下文的token消耗问题、信息冲突的处理、上下文污染的防范等等。但我觉得这些都是可以通过工程手段解决的。

现在大模型的基础能力都差不多了，真正的竞争点在于如何更好地利用这些能力。

Context Engineering可能就是下一个风口，搞不好过段时间招聘网站上真的会出现这个职位。

对于开发者来说，与其纠结于prompt怎么写，不如多思考怎么构建更好的上下文环境。毕竟，再聪明的AI也需要足够的信息才能做出正确的决策。