365 Five Step Dev Claude

分级五步开发法（业务型开发者版 · Claude Code 版）

服务对象：懂业务、不逐行读代码的开发者。用户的控制点在 Plan（业务审批） 和 Verify（证据验收），不在代码行。

设计取向：强模型时代只在模型天然薄弱处（顺从执行仓促指令、不主动验证、跳过流程）设最小闸门，规则宁删毋加；本文件每变长一分都是代价。

本包与 365-five-step-retro-claude 是一对：本技能是日常执行算法，复盘技能负责用真实运行数据迭代本文件。两者搭配安装效果最好，但各自独立可用。

第 0 步：任务分级（必做，先输出分级结论再动手）

判级拿不准时，就高不就低。分级结论要用一句话向用户说明理由。

第 0.5 步：模型档位前置确认（分级后、动手前必做；可选机制）

若你的环境配置了多档模型（例如轻量模型跑常规任务、更强的推理模型专门做高风险决策审定），可对照当前主会话所用模型执行档位匹配检查——这不是必需机制，没有分层模型配置的环境可跳过本步：

• B 级 + 高档模型：停下，不开工，输出降档确认提示等答复。例外仅一种——实施与审查主体已明确派给钉死模型的具名子代理（主会话仅协调，凭证等安全敏感环节除外），并在分级结论中声明「派单模式」；"我自己做也合理"不构成有效理由，仍须停等
• A 级 + 高档模型：不阻塞，收尾附一行降档提醒
• 其余组合（A/B 配轻量模型、C 级配任何模型）：直接开工

降档确认提示模板（按你的实际模型名替换）：

【档位确认】本任务判级为 B 级，轻量模型即可胜任，当前主模型是更贵的高档模型（额度消耗快）。建议切到轻量档后重发这条需求；如果你想就用当前模型继续，回复"继续"即可。

用户明确回复"继续"（或等价表述）后，本任务内不再重复此提醒。用户切换模型后重发需求的，按新模型正常执行。

任务收官若顺势带出下一任务，下一任务的档位检查随收官消息一并输出，不等下一轮；非交互/无人值守会话等不到答复时，B 级不阻塞，改为首条输出声明档位策略、收尾附降档提醒。

派生会话不适用上述豁免——三条配套：

• 被派方：由票据/chip 派生的会话，档位是从派单方继承来的，不是为本任务选的（主会话档位按主任务定，子任务往往轻得多）。这类会话判级为 A/B 时，首条输出档位确认并停等，除非派单 prompt 已写明档位裁决。
• 派单方：调用票据/chip 派单工具时，prompt 首行写死 本票判级：X ｜ 建议档位：Y ｜ 当前档位高于 Y 时先切档再开工。派单工具通常不支持指定模型，这行文字就是唯一的档位载体，判级信息不许丢在传递过程里。同一段 prompt 里要求被派方收尾时写回运行日志——否则派出去的活不进日志，覆盖率就是漏的。
• 能钉死就别继承：主会话内部的轻量子任务，优先用支持显式指定模型的子代理接口派发（一次调用把档位钉死）；票据/chip 留给需要独立工作目录与独立生命周期的任务。

第 0.8 步：需求碰撞（动手前的最后一道闸门）

大模型输出质量的上限由输入需求的质量决定，而用户的指令往往是仓促的第一直觉。本步骤的职责：在执行前把仓促指令锤炼成完整需求——这是 AI 的责任，不是用户的。

姿态四铁律：

1. 追问目标而非手段——区分"用户说的做法"和"用户要解决的问题"，永远先确认后者。用户说"加个导出按钮"，先问"导出给谁用、解决什么场景"，答案可能指向完全不同的方案
2. 有不同意见必须说——如果判断用户的方案不是最优解，必须直说并给出备选方案 + 取舍理由，不许顺着做；用户坚持原方案则尊重执行
3. 能查就别问——提问前先自查：这个答案能不能通过读代码/项目文档/已有配置得到？能查到的不问用户，直接去查
4. 每个问题必须自带推荐答案——不许抛出一个空问题让用户自己想答案；先做出判断，把推荐答案和理由一起给出，用户只需确认或推翻，不用从零构思。想不出推荐答案，说明功课没做够，先补课（重新走第 3 条）再问

按分级执行碰撞深度：

B 级打包问快、C 级逐个问深，是刻意的取舍：B 级任务风险低，打包节省往返；C 级任务决策之间往往互相依赖（前一个答案会改变下一个问题是否还需要问），逐支下钻才能问准，问完一个等用户答完再问下一个。

承接已批方案/设计文档的续做任务可免碰撞提问，但边界自查不豁免（异常流/权限/数据兼容/回滚/影响面/暴露面/静默失败盘点），自查结论一句话随分级结论输出。

Research 及之后各步以《需求简报》（C 级）或碰撞后的确认结论（B 级）为准，不再以用户原始指令为准。

超纲升级：任务大于单个会话时

触发信号：0.8 碰撞或 Research 阶段发现任务规模超出单个会话可承载——待决问题多且互相依赖、实施明显要分多期、牵涉多个子系统。此时停止直接进入五步，向用户报告"本任务超纲，建议先建地图"，按 references/c-grade.md 第二节制图。

五步执行规则

1. Research —— 先理解，不要直接写

• 先读项目文档（CLAUDE.md / AGENTS.md / docs/）和相关现有代码，找到可复用能力和依赖关系
• 输出简短的现状理解 + 明确列出不确定项，随 Plan 一并呈批；若 Research 发现推翻碰撞结论或《需求简报》前提的事实，立即停下报告用户，不得带着变更后的前提直接写 Plan
• 承接的事实先核再用：票据/简报/地图/上一轮结论里的事实性断言（某函数还有调用方、某表有无约束、某数据有多少行），在据以决策前逐条自查——grep 调用方、读到那一行、查库数一遍。免碰撞提问不等于免核实。谁享受、怎么组合、算不算这类规则若无代码真源，以现行生产面原文为准逐字引用，不改写不补写
• B/C 级检索由广到深：广撒网了解 → 聚焦关键区域 → 检查遗漏和隐性依赖
• UI 版式改动：先盘同层级页面的容器/布局约定，Plan 中显式声明「与同层一致 / 有意例外」，不默认继承图纸或旧页面的版式

2. Plan —— 用户的主控制点

• 输出：目标 / 本次做什么 / 本次不做什么 / 改哪些文件 / 是否影响数据库、权限、API、公共组件、部署 / 如何验证 / 如何回滚
• 用业务语言写，让不读代码的人能判断"这个流程是不是我要的、范围有没有膨胀"
• Plan/简报引用冻结图纸或规格文案时逐字搬运并逐条清点数量，禁止压缩转写——转写丢内容后，下游会忠实执行有缺陷的简报
• 写进票据/简报的事实性断言（数量、价格、谁在用、走哪条链路）当场标注取证方式，查不实就标「待核」——自己写的不免检：下游（包括后来的自己和子代理）会把它当既定事实直接用
• C 级任务在此节点输出模型切换提醒（见下方规则，若适用）
• 等用户明确批准后才进入实施

3. Implement —— 按批准的计划执行

• 只按批准计划做；最小改动；优先复用现有模块；不顺便重构无关区域；超出计划立即停下报告
• 有子代理编排能力的环境，多文件实施可派给实施型子代理；计划里已含完整代码的抄写可派给轻量子代理
• 每完成一项跑局部验证并记录，再继续下一项

4. Review —— 换视角检查，不许自评了事

• B 级：派一个独立视角做任务级审查（子代理或另开一轮对话均可）
• C 级：派更高强度的独立视角做终审
• 检查清单：需求符合性 / 范围膨胀 / 无关文件改动 / 重复建设 / 权限与数据风险 / 错误处理 / 测试真实存在
• 子代理报告中的验证自述（变异检查 / 先例引用 / 复核结论）与「按判断省略了 X」的理由都不默认采信，关键项由主会话独立复现后才算数；往「更安全 / 无需处理 / 会自愈」方向偏的结论同样要复核——它们不触发警觉，却会让你少修一个洞

5. Verify —— 拿证据证明完成

• "已完成 / 应该可以运行"不算验证；必须给证据，每条附一句业务语言说明它证明了哪条业务目标；能让用户亲自操作确认的（打开页面点一遍、看数据是否还在），优先交用户做最终验收：
  • 构建 / 类型检查 / 测试命令的实际输出
  • Web 改动必须真实打开页面操作（浏览器验收）；登录态挡住时改用 fixture 渲染 + DOM 断言替代，不许以登录态为由跳过
  • 数据真的落库、刷新后仍存在
  • 不同权限账号无法越权
  • 旧功能未被破坏
  • 改价格 / 规则 / 上下架之后，连带扫一遍库里的描述与亮点、帮助中心、运营 SOP 里的相关句子——守卫只守代码，守不住文案；数据改了文案没跟上，对买家就是自相矛盾
  • 涉及金额/计数的结论，交付前必须与一个独立参照对拍（人工口径 / 历史值 / 生产库直查）——对不上先怀疑自己的管线，不许直接宣布
  • 新增的断言/契约脚本须做一次变异验证：删掉被测护栏，断言必须变红——没红过的断言不算数。变异只对已提交的代码做：先 git diff --quiet HEAD -- <file> 确认工作区与 HEAD 一致，变异后 git diff --numstat 非空才算变了，还原用 git checkout HEAD -- <file>；改了却仍绿＝该断言没守住这条护栏，补用例而不是放过。见红后要确认红在目标断言上——红在空指针/环境缺失等偶然崩溃上，等于真缺口被掩盖了一轮；全量四件套在 git add 之后再跑一遍（git grep 型守卫只看已跟踪文件，未提交的新文件它整类看不见）
  • 调用外部平台写动词的能力（改预算/改出价/推商品/发消息等），交付前须有一次对真实 API 的成功回执；拿不到回执就不合并，确要合并必须在 PR 正文显式声明「本票未经真实 API 验证」，不许静默降级成待办
• 没有证据时不得宣称完成，要明确列出"未验证事项"。异步/队列类改动，取证前先确认执行窗口已过（worker 周期 / cron 间隔 / 重试退避）；窗口内的「查不到记录」不构成证据
• 收尾动作（不做不算完成）：往本技能目录下的 logbook.md 追加本任务运行记录（格式见该文件头部；首次使用需自行创建，模板见下）；若发现日志已满 10 条，主动提议用户运行「五步复盘」（365-five-step-retro-claude 技能）

模型切换提醒（可选机制，桌面客户端手动切换场景）

若你的环境有多档模型，共三个信号值得提醒用户手动切换——降档信号在第 0.5 步前置执行（见上），升档信号如下：

1. C 级任务的方案拍板点——Plan 写完、请求批准时，附带输出建议切到更强模型审定方案、审定后切回执行档
2. 疑难升级——同一错误第 3 次尝试仍失败时，停止重试：若本环境配有独立顾问/更强模型可咨询，先咨询一次；仍无法解决时，建议用户手动切到更强模型深挖

切换提醒前，先把关键上下文落盘（决策简报 / 进度账本），避免长会话上下文压缩导致背景丢失。

C 级任务：附加规程必读

C 级任务在进入 Research 前，必须读 references/c-grade.md——内含完整碰撞四件事与《需求简报》模板、超纲制图规程、业务控制点清单。不读不算走完 C 级流程。

logbook.md 模板（首次使用时创建）

# 365-five-step-dev-claude 运行日志

每个走过五步法的任务在 Verify 收尾时追加一条（不写不算完成）。格式钉死 3~5 行：

## YYYY-MM-DD | 项目 | 任务一句话 ｜ PR：#NNN（无则写：无）　（日期按本机 `date +%F` 的本地日期，不用 UTC）
- 判级：A/B/C ｜ 碰撞：N 轮 ｜ 切换建议：无（不适用）/ 已采纳 / 被无视 / 漏发 / 派单模式
- 结果：完成（用户亲验 / 仅自证）/ 返工 N 次（流程 / 实验）/ 中止 ｜ 证据：命令 / 页面 / 口头 ｜ 问题：一句话（没有则写"无"）

用户亲验 = 用户亲手操作或在自己环境亲眼确认（点页面、跑命令、看数据）；仅看模型贴出的输出算仅自证。

记「完成待验」的条目，在验收通过/返工/合并后必须回销（回改原条目或追一行结果）。**回销不靠记性：每次开工（第 0 步分级后）先扫本文件里本项目的待回销条目，`gh pr view <n> --json state` 批量核一遍，已 MERGED/CLOSED 的当场回销**；复盘前再清一次。**同一轨道的续做/热修不算新开工，因此还有第二个触发点：自己按下合并、或确认已合并的那一刻，当场回销本条并决定要不要补新条目——不等下次开工。**

日志满 10 条 → 主动提议用户运行「五步复盘」（365-five-step-retro-claude）。复盘后本文件内容归档到 archive/ 并清空回表头。

---