昨天下午，我经历了一次堪称经典的「AI 协作翻车事故」。
手头有个复杂模块重构，我先在会话 A 里跟 AI 探讨了整整两小时：对齐了业务边界、排除了方案甲、敲定了方案乙，连状态机的异常回滚逻辑都对好了。
眼看差不多了，由于上下文太长有点卡，我顺手开了个新会话 B，把最初的需求丢进去：「帮我实现一下刚才讨论的用户注销流程。」
然后，精彩的来了。
新会话里的 AI 信心满满地给我吐出了一套极其详尽的代码——赫然采用的是我们在会话 A 里花了一个半小时明确否决掉的「方案甲」！
会话 A 经过推演的结论：「严禁物理删除关联订单，必须采用软删除并脱敏，否则财务审计无法对账。」 会话 B 另起炉灶的实现：「执行
DELETE FROM orders WHERE user_id = ?，一键清理干净，性能最优！」
那一刻我靠在工位椅背上，真的直接自闭。 这不就像你在工位跟同事 A 辛辛苦苦开了一下午方案会，结果第二天来了个同事 B，完全不看任何交接，上来就按最想当然的方式把代码写完了吗？
为什么 AI 换个会话就会「失忆」？
很多人会说：这还不简单，你把会话 A 的聊天记录全拷过去不就行了？或者把 Context Window 搞到 2M、10M。
相信我，作为从底层 Java 牛马一路滚到 AI PM 的过来人，我很清楚这根本不是上下文长度的问题。
- 垃圾信息淹没重点：长对话里充斥着大量的「你这儿写错了」「不是这个意思」「等一下我先看下日志」，把这些流水账硬塞给新会话，AI 会在无效噪点里反复「抽卡」，抓不住核心。
- 决策过程 ≠ 最终事实：会话里讨论过方案 A、B、C，甚至中途推翻过结论。新会话拿到全部讨论记录，极容易把中间被否决的草案当成已采纳的决定。
- 跨工具直接断层：今天你在 Cursor 里写代码，明天要在网页端或者另一个 Agent 里做评审，会话历史压根带不过去。
我们需要传递的不是「聊天的过程」，而是「已经确定的业务事实与约束边界」。
我把所有约定收敛成了 1 个 Markdown 文件
为了解决这种「换个会话就抓瞎」的折磨，我摸索出了一套极简的协作机制：在工作区根目录下，永远维护且只维护一份权威的约定文件（例如 AGENTS.md 或项目约定的上下文基线）。
无论换到哪个新窗口，第一件事不是从头讲故事，而是让新 Agent 先读这个文件。
这个文件的最小结构只有四块骨架，任何人 5 分钟就能写完：
# 项目上下文与约束基线
## 1. 唯一事实信源 (Single Source of Truth)
- 业务事实以当前目录的 PRD、Prompt 或架构规范为准，不凭记忆猜测。
- 讨论稿、过期备份不作为有效信源。
## 2. 已确认的决策 (Decisions Made)
- 【2026-10-17 决议】注销流程严禁物理删除订单数据，必须采用软删除+字段脱敏（财务审计合规硬约束）。
- 【2026-10-16 决议】接口鉴权走网关层 Header 校验，业务服务内不再重复解密 Token。
## 3. 绝对禁区与红线 (Boundaries & Safety)
- 不动未明确授权的文件。
- 不引入外部未审核的第三方 SDK。
## 4. 交付与验证标准 (Done Criteria)
- 修改后必须通过本地自动化测试。
- 给出具体的变更 diff 与受影响入口核对清单。
当有了这份文件后，新会话的第一句指令变成了：
「阅读根目录的上下文约束文件，依据已确认的决议，继续实现注销流程。」
新 Agent 读完后，第一句话就是：
「已确认：依据 10-17 审计决议，采用软删除与字段脱敏方案。以下是数据脱敏与状态流转实现……」
一句话，工作瞬间接上了。没有重复扯皮，没有已否决方案的诈尸。
换个 Agent，工作接得上
顺着这个思路，我把这套上下文跨 Agent、跨会话平滑接续的规范做成了一个开源项目——Context Continuity。
它不依赖任何特定模型的私有存储，也不搞花哨的黑盒向量库，而是基于纯文本和明确的文件契约，规范 Agent 怎么建立上下文、怎么在换会话时做无缝接续、怎么在不同工具间传递已确认结论。
- 核心主张：换个 Agent，工作接得上。
- 开源地址：github.com/JasperLin23…
在 AI 时代，写代码的门槛越来越低，但工程的确定性和连贯性反而成了稀缺品。别让你的心血在每一次关闭窗口时，都变成重新开始的抓瞎。
