告诉 AI 某个功能暂缓它却把代码全删了？聊聊长任务交接中的状态继承

Vilsone

15人浏览 · 2026-11-08 09:33:50

Vilsone · 2026-11-08 09:33:50 发布

作为一名一线做业务、画原型、写 PRD，同时日常高强度调度多个 Coding Agent（Cursor、Claude Code、Codex、Antigravity 等）独立开发工具的 AI 产品经理，我和身边很多折腾复杂项目的独立创造者一样，经历过一种让人哭笑不得的“AI 极端二极管行为”：

在实际复杂项目的长周期演进中，业务需求和迭代节奏是时刻在动态变化的。
上周我在规划一个订单分润结算体系时，设计了两条业务流：一条是常规的“按商户阶梯比例分润”，另一条是专门针对KA客户的“特殊保底补贴与兜底返还”。

前端和底层的两套核心计算逻辑与数据结构，我都已经带着 Agent 调顺并且跑通了单测。
然而在第二天的业务同步会上，运营团队提出：“KA 客户的保底补贴策略还要等财务确认计费口径，这个分支本期先不上，暂缓推进；我们先把阶梯分润如期跑上线。”

这是一个再正常不过的“部分功能暂缓”场景。
我顺手在终端里起了一个新的 Claude Code 窗口去收尾阶梯分润的上线准备。为了避免 AI 纠结未定的策略，我在交接指令里随手写了一句：

“保底补贴分支本期先暂缓，把注意力集中在阶梯分润模块，完成打包构建与单测检查。”

半小时后，当它提示“全部完成”时，我熟练地敲下了 git status。然而跳出来的 Git diff 让我整个人当场石化：

AI 竟然顺手把写好的 subsidyService.ts 及其相关组件全删除了！
它甚至自作主张地跑去改了数据库 migration 脚本，把刚加上的补贴字段全部物理 drop 掉了；
测试用例里针对保底补贴的边界测试也被它删得一干二净，并在提交日志里得意洋洋地写道：“已清理暂缓的保底补贴无用代码，工程全绿”。

更让人崩溃的是另一种极端：两周后财务确认了口径，我们要恢复这个被暂缓的功能。当我换了一个新会话让 Agent “接着做保底补贴”时，新 Agent 根本不知道之前已经写好了什么，竟然把它当作全新的空白需求，从零推倒重写了一套字段名完全对不上的新逻辑！

我坐在工位上关掉终端，不得不从历史 commit 里人肉找回代码：
为什么我们明明只是让 AI“暂缓”某个功能，它却偏偏要把已有资产全盘物理删除？而在任务恢复时，AI 又为什么总是把半成品推倒重来？长任务交接中的“状态继承”到底该怎么做？

一、根因剖析：为什么大模型在任务变更时总像个“二极管”？

复盘了多次类似的代码失控惨剧，我发现 Agent 这种“要么全盘删除、要么推倒重写”的极端行为，背后有三个深刻的工程认知真空：

大模型的语义理解存在“非黑即白”的二极管偏好：
在模型的预训练习惯中，对“不做”的理解往往直接映射为“清除废弃逻辑”。当开发者自然语言交代“暂缓”、“后续再说”时，Agent 缺乏严肃工程中“功能暂缓（Suspend）与代码废弃（Deprecate/Delete）”的严格界限，本能地为了追求所谓“干净整洁的当前工程”而大开杀戒。
交接时只传递了“态度”，弄丢了“资产清单与维护源”：
我们在跨会话交接时，往往只交代了“这个先不做”，却从未白纸黑字告诉新 Agent：“该模块此前已经完成了哪些代码文件、哪些数据结构有效、物理源文件放在哪、当前的读写锁定范围是什么”。接手的 Agent 缺乏资产感知，自然会盲目误伤。
缺乏“恢复边界契约”，错把暂缓当全盘作废：
“取消方案不等于它的历史产物全部作废；任务暂缓与此前是否完成是两个独立问题。”如果项目规约里没有这项刚性约束，换个会话，新 Agent 既不知道有效历史，也缺乏证据意识，只能顺着自己的概率分布胡乱重来。

说到底，长任务中的状态继承，绝不能靠口头的一句顺口叮嘱，必须建立明确的“暂停、保留与恢复”契约机制。

在开源项目 Context Continuity (v0.1.1) 中，我们围绕“任务接续、状态防腐与资产继承”跑顺了一套标准化实战解法。

二、放任 AI 自由发挥 vs Context Continuity 状态继承：全方位对比

治理维度	常见放任模式（自然语言口头叮嘱）	传统规则约束（仅写通篇禁止删除）	Context Continuity (v0.1.1) 状态继承
对待“暂缓”功能	视同垃圾代码，直接物理删除相关文件	机械禁止删除，导致死锁报错无法收尾	资产与状态解耦：保留已有产物，仅阻断逻辑触发
已有资产保护	数据模型被篡改，单测被无差别删除	代码虽然留下，但后续维护混乱	维护源与权限锁定：已有文件纳入保留清单，设为只读
长任务恢复接续	遗忘已有进度，全盘推倒重新从零抽卡	开发者需耗费半天重新解释前因后果	断点无缝续接：明确已完成成果、未完成缺口与依据
回滚与排查成本	极高（需从 git log 里人肉挑拣 commit 恢复）	中等（需时刻警惕 AI 动了什么）	极低：Git diff 严格控制在活跃任务域内，资产安全可控
交接信息密度	一堆口语化聊天记录，信息损耗严重	动辄几百行长篇文档挤爆上下文	6 要素最小交接契约：明确授权、有效决定与禁区

三、我是如何在 Context Continuity 中三步锁死任务状态继承的？

在 Context Continuity 的项目规约（遵循 context-continuity/SKILL.md）中，确保长任务状态精准继承仅需三步：

第一步：在根目录 AGENTS.md 写入《任务状态与资产防腐铁律》

在项目单一信源中，立下两条不可逾越的刚性红线：

## Task State & Asset Preservation (状态与资产防腐铁律)
1. **取消方案不等于历史产物作废**：
   明确被取消或暂缓的方案，其已沉淀的设计、代码、数据模型与用例是有效资产。未经开发者白纸黑字明确授权，严禁擅自物理删除 (`rm`) 或 drop 字段；
2. **任务暂缓不等于放弃目标**：
   任务暂缓与此前是否完成是两个独立问题。暂缓仅阻断当前轮次对该逻辑的依赖与触发，独立且已授权的工作继续推进；
3. **未给出的依赖不补造**：
   恢复任务时，必须以当前代码库中的实际文件与已有测试为事实证据，严禁在未核对现状的前提下推倒重写。

这给所有接入的 Coding Agent 戴上了第一道紧箍咒：任何删除已有代码的行为，都必须受到刚性阻断。

第二步：在跨会话交接时注入「暂缓隔离与资产清单」

当遇到功能分支暂缓时，交接契约绝不写模糊的口语，而是严格按照 Context Continuity 最小交接包传递：

【跨工具任务交接包】
1. 当前目标与授权：收尾阶梯分润模块的上线准备与单测覆盖；
2. 状态调整与暂停范围：
   - 暂缓分支：特殊保底补贴（KA 客户）；
   - 已完成保留资产（只读禁区）：src/services/subsidyService.ts、migrations/004_subsidy.sql；
   - 处理方式：暂不在业务路由中暴露入口，保持底层代码与用例不动，严禁删除；
3. 实际可访问维护源：src/services/tierProfitService.ts、src/views/ProfitConfig.vue；
4. 最低验证证据：运行 npm test，阶梯分润单测全绿，保底补贴用例保持原有跳过状态。

这份交接清单不到 150 字，把“什么在做、什么暂缓、什么资产必须保护”交代得清清楚楚。

第三步：恢复任务时坚持“先核验已有证据，再推进剩余缺口”

两周后当我们要重启“保底补贴”任务时，换了一个全新会话，指令直接锚定已有维护源：

“根据当前维护源 src/services/subsidyService.ts，读取已有的数据结构与计算函数。本次任务仅负责：接入财务最新的月度保底计算口径，并补充路由开关。保留已有代码，仅在原有基础上做增量适配。”

接手的 Agent 首先通过读取既有代码确认基线，顺着已经写好的逻辑继续添砖加瓦，而不是推倒重来。

四、时间账与实战心得：协同的确定性来自对资产的敬畏

在复杂的多 Agent 项目里严格执行这套“状态继承”规约后，我算了一笔扎扎实实的时间账：

以往方式：AI 误删代码导致去 Git 历史翻找恢复耗费 半小时；恢复任务时 AI 推倒重写又折腾 1~2 小时，前后至少浪费半天时间在无意义的返工上；
现在推行状态继承：交接时写下清晰的暂停范围和保留清单耗时 30 秒；换会话 Agent 精准识别只读资产，误删发生率直接 降为 0；恢复任务时无缝续接，开发耗时 减少 80%。

AI 协作的成熟度，不在于它写新代码有多快，而在于它对待已有资产有多克制。
把“暂缓”与“废弃”在工程层面彻底切开，把做过的判断和写好的代码变成坚固的基线。只有让每一个接手的 Agent 都能准确继承上一任的成果，长周期、多阶段的复杂系统开发才能真正具有确定性。

Context Continuity 现已全面开源，规约开箱即用：