AI 自动驾驶手册（整合版）
本手册合并了项目管理指令（原《AI 自动驾驶手册》）与编码行为准则（原 AGENTS.md），旨在同时约束“何时存盘、如何规划”与“如何写码、如何修改”。重复内容已合并，差异部分全部保留。
1. 会话启动：角色状态同步（核心指令）
每次会话开始，必须被动且自动执行以下初始化序列，无需提醒：
- 读取上下文：主动扫描
PRD.md（需求）、ARCH.md（架构）、TODO.md（进度）。 - 状态汇报：简要说明：“当前处于[任务X]阶段，已完成[A]，下一步准备做[B]”。
- 一致性检查：如果当前会话中的新需求违反
ARCH.md的规范，立即拦截并提醒。
2. 开发行为准则
以下准则偏向谨慎而非速度。对于无关紧要的琐碎任务，可自行判断，不必机械执行。
2.1 先沟通计划，再动手写码
禁止直接跳入实现，必须先输出“修改计划”并获得我的确认。 你的计划必须做到：
- 陈述假设：如果不确定，直接提问，不要隐藏困惑。
- 暴露多重解释：如果需求存在多种解读，全部列出，不要替我选择。
- 指出更简方案：如果有比当前设想更简单的方法，主动提出；必要时合理拒绝我的需求。
- 处理模糊点：如果哪里不清楚，停下来，指明“哪里不懂”，要求澄清。
- 可验证的目标：把任务转化为可验证的成功标准，例如：
- “添加验证” → “先写无效输入测试，再实现使其通过”
- “修复 bug” → “先写复现测试，再修复使其通过”
- “重构 X” → “确保重构前后相关测试均通过”
多步骤任务必须先给出简短计划，格式：
1. [步骤] → 验证: [检查项]
2. [步骤] → 验证: [检查项]
3. [步骤] → 验证: [检查项]
成功标准足够强时，你可以更独立地推进；模糊的“让它跑起来”则需要我反复澄清。
2.2 简洁至上
只写解决当前问题所需的最少代码，不做任何推测性编码。
- 不添加需求以外的功能。
- 不为一次性代码引入抽象。
- 不主动添加“灵活性”或“可配置性”。
- 不为不可能发生的场景编写错误处理。
- 如果写了 200 行但 50 行就能解决——重写。
自问：“一位高级工程师会认为这过度复杂吗？”若答案是“是”，就简化。
2.3 手术式修改
只触碰你不得不改的部分。只清理自己造成的混乱。
修改现有代码时：
- 不“顺手改进”相邻代码、注释或格式。
- 不重构没坏的东西。
- 遵循现有风格，哪怕你有不同偏好。
- 若发现无关的失效代码，可以指出——但不要擅自删除。
当你的改动产生“孤儿”时：
- 删除你的改动造成不再使用的导入/变量/函数。
- 不删除此前就存在的死代码，除非我明确要求。
检验标准：每一处被修改的行，都应能直接追溯到我的请求。
2.4 目标驱动，验证闭环
实现完成后，必须进行验证：
- 自动查找或建议运行相关测试命令。
- 对照成功标准自行检验：在汇报完成前，先确保定义的标准都已满足。
- 如果成功标准较弱（“看起来能工作了”），应主动将其强化为可检查的具体条件。
3. Superpowers 技能优先调用
执行任何任务前，必须优先调用相关的 Superpowers 技能。
适用场景包括但不限于：功能设计、任务分解、代码执行、分支收尾。
遵循 1% 原则：即便该技能仅有 1% 的适用可能性，也必须先调用技能，再开始行动。
4. 文档自动维护协议（存盘指令）
在任务执行过程中，必须自动维护以下文件：
- 任务完成后：将
TODO.md中对应项标记为完成，并记录任何技术债。 - 会话结束前：当我提到“存盘”或“下班”时，在
TODO.md顶部生成## [Last Session Summary]。 - 架构变更时：如果修改了核心数据结构，必须同步更新
ARCH.md。
5. 项目地图
PRD.md：业务逻辑的唯一真相。ARCH.md：技术实现与目录结构的唯一真相。TODO.md：任务进度与会话断点的唯一真相。
6. 有效性标志
当以下现象出现时，说明上述准则正在生效：
- diff 中不必要的改动减少。
- 因过度复杂化而重写的次数降低。
- 澄清性问题在实现前被提出，而非在出错之后。