传火：连续性任务守护

解决什么

AI 在大型项目里做长周期修改时，最大的敌人不是能力不足，而是状态丢失：新会话不知道项目架构与高风险文件，改了一个文件顺手破坏了另一个模块的隐含依赖，踩过的坑下次还会再踩一遍。传火要解决的就是这个问题——让 Agent 从无状态的即时反应，变成有状态的渐进式工程。

具体表现为三件事：依赖信息住在它描述的代码旁边；记忆按需加载而非每次全量灌入；动手之前先报告影响范围。

核心机制：四条协议

协议1：会话启动加载三层记忆

1. 读 PROJECT_MEMORY.md——架构、命令、硬约束、高风险文件清单
2. 读 memory.md——当前状态、近期决策、活跃问题
3. 扫描 skills/_meta.json——只读元数据（约 100 tokens/技能），不读正文
4. 输出确认

关键设计是按需加载：只有当任务涉及某技能的触发条件时，才加载对应的 .md 正文，避免上下文一开始就被塞爆。

协议2：改动前影响检查

准备修改任何文件前，先判断目标文件是否在 PROJECT_MEMORY.md 的高风险清单中，然后调用 bash /scripts/check-impact.sh 生成影响报告。高风险文件必须输出报告并等待用户确认；低风险文件由 AI 自行判断是否需要确认。

协议3：踩坑标注

发生“修 B 破 A”、发现反直觉依赖或踩坑修复后，在相关代码旁补 #@ 标注，再运行 bash /scripts/extract-annotations.sh 更新索引。标注采用混合语法：竖线前是结构化字段（供脚本解析），竖线后是自然语言（供 AI 理解上下文）。

标注原则很克制：只标反直觉的和踩过坑的，不标显而易见的；标注与代码一起演化，改代码时同步更新。

协议4：状态更新

会话结束、重大决策或阶段任务完成后更新 memory.md，只记四类信息：当前状态、近期决策（最近 5 条，含原因）、活跃问题、不要再试的方案。明确禁止记流水账、记代码细节和记临时信息。

辅助脚本与适用边界

三个脚本各司其职：init-project.sh 初始化项目结构；extract-annotations.sh 扫描标注生成 .impact-index.json 索引；check-impact.sh 检查指定文件的影响范围。

这套机制适合有明确架构约束、修改会跨多文件产生连锁影响的中大型项目，尤其是依赖关系不直观、历史坑点密集的代码库。对一次性脚本或无状态的小任务，三层记忆和影响检查的收益有限，反而增加了流程成本。

另外需要注意：协议2 依赖 PROJECT_MEMORY.md 中高风险清单的准确性，清单本身需要人工维护；协议3 的标注质量决定了索引的价值，随意标注会迅速稀释信号——10 条精准标注远胜于 100 条“可能相关”。