# 365 Five Step Dev Claude

> 分级五步开发流程（业务型开发者版，Claude Code 版）。用户说「五步法」即为显式调用本技能；此外当用户提出任何开发需求——新功能、Bug 修复、页面改动、数据库/权限变更、接口、部署——也应触发。姊妹技能 365-five-step-retro-claude 负责本技能自身的运行复盘与迭代。

- Skill: `laojin1900/365-five-step-dev-claude` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add laojin1900/365-five-step-dev-claude`
- Raw SKILL.md: https://api.skillmd.com/api/skills/laojin1900/365-five-step-dev-claude/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: laojin1900 (https://skillmd.com/u/laojin1900)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/laojin1900/365-five-step-dev-claude

---


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

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

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

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

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

| 级别 | 判据 | 流程 |
|------|------|------|
| **A 微小** | 文案/样式/间距/单个明显小 Bug；不碰数据库、接口、权限 | 快速定位 → 最小修改 → 页面验证（不走完整五步） |
| **B 普通** | 新页面/表单/列表/普通接口/模块内功能迭代；不碰核心架构 | 五步全走，Review 派子代理 |
| **C 高危** | 数据库结构、权限体系、支付/订单、公共模块重构、生产部署、多项目共用能力 | 五步全走 + 业务控制点检查 + 独立审查 + 人工批准 |

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

## 第 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 条）再问

按分级执行碰撞深度：

| 分级 | 碰撞深度 | 提问节奏 | 动作 |
|------|---------|---------|------|
| A 级 | 零碰撞 | — | 一句话复述理解，直接干 |
| B 级 | 轻量碰撞 | 打包问，问题少而准 | 输出：我理解的业务目标 + 关键澄清问题（只问影响方案走向的，各附推荐答案）+ 用户可能没考虑到的 1~2 个点；答复后进入 Research |
| C 级 | 完整碰撞 | **逐个问，一次一个** | 按 `references/c-grade.md` 执行，形成《需求简报》并落盘，用户确认简报后才进入 Research |

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/ 并清空回表头。

---
```