过去一年，大家谈“上下文工程”时，很多人脑子里想的还是另一种提示词技巧：怎么写 system prompt，怎么塞背景，怎么让模型少跑偏。这个方向当然没错，但我越来越觉得，它已经不够了。

真正重要的变化是：上下文开始从聊天窗口里的临时文本，变成仓库里的长期资产。这不是一个措辞变化，而是开发工作流正在发生迁移。

Google 在 2025 年底介绍 Gemini CLI 的 Conductor 时，核心思路就很明确：不要把项目知识只留在对话历史里，而是把产品目标、技术栈约束、工作流偏好、具体功能计划写进仓库里的 Markdown 文档，让 Agent 在这些文档之上工作。OpenAI 这边 2026 年也在持续强调 AGENTS.md、skills 和状态化上下文的价值。两边路线不同，但指向同一个现实：可复用的上下文，必须脱离聊天本身。

为什么“聊天记忆”不适合承担项目级上下文

因为聊天记录天生不是工程资产。它有四个问题。

第一，不稳定。换个会话、换台机器、换个成员，很多上下文就丢了。第二，不可审阅。你很难像 review 代码一样 review 一段历史对话。第三，不可协作。团队成员共享 prompt 片段远不如共享结构化文档。第四，不可演进。聊天内容会不断堆积，但项目知识需要被重写、折叠和澄清，而不是无限追加。

这也是为什么很多人会有一种错觉：某次 Agent 用得特别顺，下一次却像失忆。原因往往不是模型突然变笨，而是关键背景只存在于上一次对话里，从来没有沉淀成项目资产。

把上下文写进仓库，真正改变的是什么

改变的是协作边界。以前你和模型协作，靠的是你当场补充背景；现在更好的做法是，让仓库先说话。

一旦产品目标、约束条件、架构约定、代码风格、测试策略、功能计划这些内容被写进仓库，Agent 的工作方式就会稳定很多。你不再需要每次重新解释“这个项目为什么不用某个框架”“这里为什么先保守改造”“上线前必须跑哪些检查”。模型不是突然懂业务了，而是你终于把业务和工程约束变成了它每次都能读到的东西。

这件事对棕地项目尤其重要。新项目当然适合 AI，但真正难的是已有代码库。老仓库里充满历史包袱、隐性约定和局部例外，单靠一次对话根本装不下。Conductor 这类工具之所以值得看，不是因为它“更智能”，而是因为它试图把项目理解拆成一组长期存在的文档，这比纯聊天靠谱得多。

但我不建议把文档化上下文神化

这里也要泼一点冷水。把上下文写进仓库，不等于问题自动解决。很多团队一听到这个思路，第一反应就是疯狂加文档，结果很快把 Agent 喂到信息过载。

仓库内上下文的价值，不在于多，而在于有层次、有边界、能维护。哪些规则是全局永久的，哪些是功能级暂时的，哪些是执行前必读，哪些只是补充参考，都要区分。否则你只是把聊天噪音从会话窗口挪进了仓库。

我更看好的做法，是把上下文拆成几层：稳定规则放在仓库根部；项目目标和技术约束单独管理；每个功能再有自己的 spec 和 plan；执行过程产生的状态文件只服务于当前任务。这样做的好处是，Agent 读取什么、忽略什么，开发者能控制，团队也能逐步形成共识。

个人开发者该不该现在跟进

我的结论是：应该跟，而且收益很实际。

独立开发者最缺的不是模型，而是稳定复用自己的判断。你今天能把一个功能讲清楚，不代表下周你还愿意重新讲一遍。把常用约束写进仓库，本质上是在把自己的经验产品化。它可以减少重复解释，降低上下文切换成本，也能让不同工具之间共享同一套项目背景。

这件事暂时不一定直接帮你“多写十倍代码”，但它会明显减少 AI 协作里的随机性。对个人开发者来说，这种稳定性往往比一两次惊艳输出更值钱。

结论

提示词没有过时，但它正在从主角变成接口。真正越来越值钱的，是那些能被版本控制、能被团队共享、能被不同 Agent 重复利用的上下文资产。

所以别再把上下文工程理解成“会不会写提示词模板”了。下一阶段的竞争，不是谁更会聊天，而是谁更会把项目知识沉淀成机器和人都能持续使用的工作基建。