作为一名一线做业务、画原型、写 PRD，同时日常高强度调度多个 Coding Agent（Cursor、Claude Code、Codex、Antigravity 等）独立开发工具的 AI 产品经理，我早年最容易犯的一个直觉错误就是：总觉得大模型越聪明，背景信息塞得越多越好。

很多刚开始让 Agent 辅助写代码或改需求的朋友，往往有类似的心态：

“AI 毕竟不了解我们的业务，我得把业务背景、历史沿革、架构大图、前后端规范一股脑都喂给它，它才能理解透彻。”

不久前在调整一个支付结算模块的退款手续费阶梯计费逻辑时，我就亲身交了一笔惨痛的学费。

为了让新开的 Claude Code 窗口“彻底理解业务全貌”，我把模块最初的背景立项说明、上一期架构演进总结、整个结算中心的模块关系图文字版、以及长达 30 多页的通用开发规范，一股脑贴进了提示词和项目规则里。输入框里洋洋洒洒塞了近两万字，我信心满满地敲下回车：

“请根据以上背景，在原有的阶梯费率基础上，新增一档针对老用户的专属优惠区间。”

结果接下来的事情让我哭笑不得：

1. 老旧废弃方案“反客为主”：Agent 翻出了我塞进去的半年前架构讨论草稿，里面曾经有一句临时假设“后续拟取消阶梯计费，改为按月综合对账结算”。AI 看到这句话，居然自作主张把现行代码里已经跑通的阶梯算法全部注释掉，试图帮我“提前落地月度对账”；
2. 核心业务约束被边缘化：我真正要求的新增专属区间，被它草草写成了两行硬编码的 if-else，甚至把临界值的包含关系判断写反了；
3. 响应延迟拉满，会话迅速报废：因为每轮交互都拖着两万 token 的超长背景，Agent 每思考一步在终端都要卡顿十几秒；聊到第 4 轮，上下文窗口就迅速逼近截断阈值，开始出现胡言乱语的遗忘现象。

我盯着 Git diff 里那堆被改歪的代码，关掉终端叹了一口气：为什么我们明明好心给 AI 补充了详尽的背景，到头来它却改得一塌糊涂？

---

一、为什么在严肃工程中，“海量背景”反而成了毒药？

经历了那次翻车后，我复盘了过去半年调度不同 Agent 的近百次任务记录。我发现绝大多数开发者在使用 Coding Agent 时，忽视了一个极其底层的信息论常识——上下文不是垃圾桶，信噪比（Signal-to-Noise Ratio）决定了 Agent 的输出质量。

给 AI 喂入过多非必要的全局背景，会在底层引发三大致命问题：

1. 大模型的注意力稀释（Needle in a Haystack 困境）：
   现代大模型虽然动辄拥有 100K 甚至 1M 的上下文窗口，但注意力的分布是有限且非均匀的。背景文本越冗长，那些真正关乎本次改动的“核心边界约束（例如：费率不得为负数、必须保留历史日志）”被分配到的注意力权重就被稀释得越低。这就好比在一本厚厚的字典里藏了一颗针，模型极易产生漏读与幻觉。
2. 历史废弃逻辑与临时假设“借尸还魂”：
   真实的业务文档里，不可避免地残留着早期的头脑风暴、被否决的备选方案、或者未落地的伪需求。当人类工程师阅读时，能依靠长期的业务直觉过滤掉这些过时信息；但大模型没有“现实世界的锚点”，它只会按语义相似度匹配。你塞给它的背景越多，它捡起过时废弃逻辑来“背刺”你的概率就越高。
3. 上下文腐化与响应成本陡增：
   拖带大量无用背景会快速吃满会话窗口，不仅 token 消耗成倍增加，还会诱发 Agent 产生“多说多错”的过度拟合现象——它总想在代码里体现出你提到的那些宏大背景，最终写出一堆过度设计的垃圾代码。

说到底，AI 需要的是支撑当前判断的“精准依据”，而不是包罗万象的“历史全貌”。

想清楚这件事后，我在开源项目 Context Continuity (v0.1.1) 中，明确确立了上下文信噪比控制与信源分级原则。

---

二、传统做法 vs Context Continuity：海量堆叠 vs 精准信源治理

维度	传统常见做法（一股脑全塞）	依赖外挂向量检索（RAG 盲捞）	Context Continuity（单一信源 + 最小裁剪）
背景提供方式	每次提问贴上万字长文档或全量 README	后台向量数据库按相似度自动切片注入	四层信源刚性分级：根目录仅留最小约束，正文按任务读取
信噪比控制	噪音极多，有效信息占比不足 10%	容易捞出语义相似但早已过期的历史讨论	高信噪比：只传递支撑本次决策的唯一信源与直接依赖
对待废弃假设	历史废案与现行规则混杂，AI 频繁翻车	无法识别某条碎片是否已被新版本覆盖	新决定直接替换旧内容：同一问题持续更新一份正文，旧稿归档
任务跨窗口接力	复制上一个窗口的整屏聊天记录	依赖外部插件黑盒记忆，无法排错	6 要素最小交接契约：10 秒传递目标、依据、源路径与禁区
执行精准度	容易抓偏重点，需要反复 3~4 轮纠偏	经常复活已被否决的默认写法	一次性命中率大幅提升，极少产生无关发散代码

---

三、我是如何在 Context Continuity 里实现上下文裁剪与信噪比控制的？

在 Context Continuity 的项目协作规范中，我们通过极为克制的三套工程纪律，把上下文噪音降到了最低：

1. 四层信源刚性分级：划分单一信源边界

我们坚决反对把几千行的业务规则直接写进 Agent 的全局配置（如 .cursorrules 或顶层 Prompt）。在 Context Continuity 中，项目上下文被严格划分为四层：

• 第一层：顶层约束（AGENTS.md）：
  全篇控制在 100 行以内，只定义全局任务级别、安全红线（如禁止物理删除、禁止越权推送）与最低验证标准。写成“一句原则 + 必要反例”，绝不写具体业务细节；
• 第二层：结构导航（README.md）：
  仅用于告诉 Agent 目录职责与模块入口，严禁将具体业务逻辑写进导航；
• 第三层：具体业务事实（目标源文件与对应 PRD）：
  项目唯一的事实维护源。同一个问题只维护一份正文，新决定直接覆盖旧规则，不留历史草稿；
• 第四层：历史证据（归档目录）：
  明确被替代的文件在提取有效价值后显式移入归档，仅供人工追溯，严禁作为 Agent 的执行依据。

2. 按任务按需裁剪（Just-in-Time Context）

调度 Agent 接手任务时，遵循“按需索取”原则：

• 改动一个前端页面，只读该页面的源码与直接引用的样式/接口定义，绝不加载后端数据库设计；
• 讨论一个业务规则，只读取该业务所在的正式 PRD 章节，绝不加载整份几十页的项目背景；
• 工具 references 仅在遇到特定格式报错或特殊协议时按需查阅对应章节，绝不一次性将所有参考手册打入上下文。

3. 跨会话使用「6 要素最小交接契约」

当长会话开始变慢，或者需要把任务从一个工具（如 Claude Code）换到另一个工具（如 Cursor）继续推进时，绝不复制历史聊天记录，而是传递标准的 6 要素交接包：

【任务接续契约】
1. 当前目标：为客户结算列表增加阶梯退款费率计算支持；
2. 已采纳决定及依据：采用方案 B（按自然月区间阶梯累计），已否决方案 A（方案 A 无法满足跨月退款审计要求）；
3. 实际维护源：src/services/refundFee.ts 与 docs/prd/结算模块.md#费率规则；
4. 当前进度与责任：后端计算核心已完成并通过单测，剩余前端配置抽屉需适配；
5. 验证边界：运行 npm test 测试用例必须全绿，无需启动本地服务；
6. 不可触碰的禁区：严禁修改现有的基础对账日志格式。

接收任务的 Agent 拿到这 6 条信息，能够在一秒内精准定位到目标源文件，完全杜绝了海量聊天记录带来的噪音干扰。

---

四、时间账与总结：克制带来最大的工程确定性

自从在手头几个开源项目和日常工具中严格执行上下文裁剪与信噪比控制后，我和几个 Coding Agent 的协作效率发生了质的飞跃：

• 以前：开新会话随手贴几千字背景，AI 改偏了之后我花 40 分钟反复跟它纠正拉扯，每天至少浪费 1.5~2 小时 在无谓的排错上；
• 现在：依靠清晰的四层信源表和 6 要素交接契约，新窗口 10 秒进入状态，代码一次性生成命中率大幅提升，会话 token 消耗降低了 60% 以上。

大模型不是吃得越多就跑得越快，给得越多往往意味着干扰越多。
在多 Agent 协同的时代，最高级的工程素养不是堆砌了多么宏大的提示词，而是懂得在合适的时候做减法——只给关键判断依据，守住单一维护源，把噪音死死挡在核心业务之外。

Context Continuity 现已开源：

• 开源仓库：在 GitHub 搜索 JasperLin2333/context-continuity 即可查看项目与接入指南
• 一键安装：npx skills add JasperLin2333/context-continuity --skill context-continuity