文档驱动AI工作流

要解决的问题

AI 辅助编程真正麻烦的地方，不是模型能不能写代码，而是它每次打开新会话都像第一次见这个项目：没有长期记忆，不懂上次为什么这么改，也分不清哪些是用户手动调过的。结果往往是改动扩散到不该动的文件、风格漂移，或者把人工微调直接覆盖掉。

这个 skill 把跨会话协作压到四份文档上，而不是靠模型临场发挥。

四层文档如何工作

• 规则层 AGENTS.md：放每次会话自动注入的铁律。原文要求控制在 5 条以内，重点覆盖人机冲突规则、改动范围规则、留痕规则。它的作用是限制 AI 的破坏半径，不是把所有项目规范都塞进去。
• 分析层 工作分析.md：回答“改什么”。做需求拆解、新旧对比、改动程度评级。
• 计划层 实施计划.md：回答“怎么改”。分期任务、目标文件、验收标准、风险回退，还要显式写“不在本次范围内”清单。分期粒度按“单次会话能完成 + 出错可单文件 git 回退”设计，第一期最好只动一个文件。
• 记忆层 Memory.md：回答“改了什么”。按日期倒序记录修改流水，包含日期和主题、修改文件列表、逐条修改内容；修 bug 还要写问题原因，这是跨会话避免重蹈覆辙的关键。

工作流分三个阶段：初始化时检查根目录是否已有 AGENTS.md、Memory.md、*工作分析.md、*实施计划.md，缺失就建；每次会话进入单次修改循环，改完必须追加 Memory.md；长期维护时，遇到“改坏→修复→回退”的反复，每一步都要单独记录，不要合并成一条，失败路径本身就是有价值的上下文。

适用边界与注意点

适合从零建项目、功能迭代、UI 改版、样式升级、渐进重构、框架迁移等需要连续推进的任务，也适合多人或多 agent 协作时统一上下文。但它不是银弹：文档不会自动保证代码质量，验收标准写得含糊，AI 照样能“完成”错的东西。

几个明确反对的用法：把 AGENTS.md 写成几百行规范；一次会话跨多期、动多个不相关文件；Memory.md 只写“优化了样式”；跳过分析和计划直接让 AI 动手；看到代码和自己上次产出不一致就改回去——那很可能是用户的手动修改，必须保留。