chengmaandClaude Fable 5
795a852aa9
- docs/tasks/README.md: default mode for single and multi agent, drop switch narrative - docs/06-tasks.md: demote to read-only roadmap (phases, milestones, backlog, suggested split list without status) - progress.md: optional archive / project-level event log; execution records live in task files - current-state.md: project-level snapshot; task status authoritative in task frontmatter - sync all referencing docs (start-here, coding-rules, READMEs, adoption/clean-state checklists, method-map, evaluator-rubric) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2.8 KiB
2.8 KiB
方法对照表
把最常见的长时 coding-agent 失败模式，对应到本仓库里最该先补的工件或规则。 出问题时先查这张表，对症补对应工件，不要把更多规则一股脑堆进一个超长入口文件。
失败模式 → 首要修复 → 工件
| 失败模式 | 实际表现 | 首要修复 | 主要工件 |
|---|---|---|---|
| 新会话摸黑 | 新会话花大量时间重新摸索状态和启动方式 | 让仓库成为唯一事实来源 | current-state.md + tasks/ 任务文件的执行记录 |
| 启动脆弱 | 每轮会话都要重新学怎么启动、装依赖、跑测试 | 统一启动与验证路径 | ../init.sh / ../init.ps1 |
| 范围蔓延 | 一次启动多个任务，最后没有一个完整收尾 | 限制当前活跃范围，一轮只做一个任务 | tasks/README.md |
| 提前宣布完成 | 代码改了就说"完成了"，但没有可运行证据 | 把完成绑定到验证证据 | tasks/README.md（passing 需证据）+ clean-state-checklist.md |
| 交接薄弱 | 下一轮看不出哪里可用、哪里坏了、接下来做什么 | 每轮留下明确的当前快照和下一步 | current-state.md |
| 评审主观 | 质量判断靠个人记忆和感觉，agent 容易自我说服通过 | 用固定维度做评分 | evaluator-rubric.md |
| 代码库悄悄退化 | 速度上去了，但几轮会话后代码越来越难审、边界越来越糊 | 定期给代码库健康度打分 | quality-document.md |
| 文档堆叠失控 | 入口文件越来越长，"每次失败加一句" | 渐进披露，入口保持薄 | 00-ai-start-here.md + 拆分到具体文档 |
| 多 agent 抢改任务文件 | 多个 agent 并发时抢改同一个看板/进度文件，出现"读到旧版本"、ID 撞号、合并冲突 | 一任务一文件（默认模式已内建），执行记录进任务文件，不逐任务改共享收尾文件 | tasks/README.md |
使用原则
- 优先补最能直接消除当前失败模式的那一个工件，不要一次铺开全部。
- 工件之间用链接互相引用，让全新 agent 不问人也能从一个文件跳到相关规则。
- 同一个事实只维护一份，避免多个文件互相打架。
- 修复落地的同一轮会话里，就把对应工件更新掉。
评审 vs 健康度：两个不同的问题
evaluator-rubric.md回答："这轮 agent 做得好不好？"（单次输出质量）quality-document.md回答："这个项目在变强还是变弱？"（代码库本身质量）
两者配合：rubric 守住每轮交付，quality document 守住长期趋势。