Skip to content

user-guide_zh.md

Latest commit

 

History

History
934 lines (641 loc) · 35.2 KB

user-guide_zh.md

File metadata and controls

934 lines (641 loc) · 35.2 KB

devpace 用户指南

使用 devpace 管理 Claude Code 项目的完整参考。

快速概览见 README.md。动手体验见端到端演示。

目录

快速开始

安装

# Marketplace 安装（推荐）
/plugin marketplace add arch-team/devpace-marketplace   # 仅需一次
/plugin install devpace@devpace

# 或从源码加载
claude --plugin-dir /path/to/devpace

首次使用（2 步完成）

/pace-init my-project

Claude 只问一个问题："用一句话描述这个项目做什么？"

然后自动生成最小 .devpace/（state.md + project.md + backlog/ + rules/）。

接下来说"帮我实现 X"就可以开始工作——功能树、迭代计划等随工作自动出现。

项目随工作生长

devpace 不要求你预先规划所有内容。初始化只创建最小骨架，其他文件按需出现：

你做的事 devpace 自动创建的
说"帮我实现 X" 功能树（project.md 中自动出现）
/pace-plan 迭代计划（iterations/current.md）
/pace-retro 度量仪表盘（metrics/dashboard.md）
/pace-release create 发布记录（releases/）

你也可以用 /pace-init full 一次性完成完整配置（业务目标、功能列表、迭代计划等）。

已有项目怎么办？

/pace-init 可在已有项目中运行。它会在你的代码旁创建 .devpace/，不会修改任何已有文件。如果不想将状态文件纳入版本管理，将 .devpace/ 添加到 .gitignore 即可。

核心概念

追溯链

devpace 把工作组织成 6 层可追溯的链条：

机会 → 专题 → 需求 → 功能 → 任务 → 代码
你发现机会   你规划专题   一起分解    一起规划    Claude 自动创建    Claude 写代码
  • 你定义机会、专题和功能（用自然语言）
  • Claude 自动创建任务，并在工作过程中维护追溯关系
  • 双向追溯：从业务机会追到代码，从代码追回目标

内部术语参考（你不需要记这些，Claude 对话中也不会使用）： 机会 = OPP、专题 = EPIC、需求 = BR（Business Requirement）、功能 = PF（Product Feature）、任务 = CR（Change Request）

你不需要学任何术语

devpace 内部使用精确的概念模型，但对话中一切都是自然语言：

你说 devpace 做的事
"帮我实现用户认证" 自动创建任务并开始工作
"做到哪了" 展示当前进度
"准备好了吗" 检查质量门状态
"加一个导出功能" 识别为需求变更，执行影响分析

BizDevOps 覆盖度

devpace 覆盖完整的 BizDevOps 全域六大维度：

维度 评分 关键能力
Biz（业务规划） 8/10 /pace-biz 8 子命令：opportunity、epic、decompose、align、view、discover、import、infer
Product（产品管理） 9/10 /pace-plan adjust/health、/pace-change 全生命周期、/pace-next 智能推荐
Dev（开发） 9.5/10 /pace-dev 自主编码、ADR 管理、技术债务追踪、OWASP 安全扫描、语义漂移检测
Ops（运维） 7.5/10 /pace-release 完整编排、/pace-sync 外部工具桥接、CI/CD 感知
Observe（观测） 9.5/10 /pace-retro DORA 度量 + 预测、/pace-pulse 节奏监控、/pace-guard 风险织网
Knowledge（知识管理） 8.5/10 /pace-learn 跨项目经验、/pace-theory 方法论参考、经验自动沉淀

命令参考

核心命令（日常使用）：/pace-init、/pace-dev、/pace-status、/pace-review、/pace-next 业务命令（上游规划）：/pace-biz 进阶命令（需要时用）：/pace-change、/pace-plan、/pace-retro、/pace-guard 专项命令（可选）：/pace-test、/pace-release、/pace-sync、/pace-feedback、/pace-role、/pace-theory、/pace-trace

/pace-init [name] [full]

何时使用：首次在项目中设置 devpace。

参数：

  • name — 可选，项目名称。省略时 Claude 会询问。
  • full — 可选。执行完整设置（业务目标、功能列表、迭代计划、质量检查）。

功能：

  • 默认：创建最小 .devpace/（state + project 存根 + backlog + rules）。只问项目名称和描述。初始化后会预览"接下来会发生什么"，帮助你了解下一步。
  • full：创建完整 .devpace/，包含功能树、迭代计划、度量仪表盘。引导式 6 步设置。

重新初始化：如果 .devpace/ 已存在，Claude 会询问是否重置。

/pace-dev [feature]

何时使用：你想开始或继续写代码。

参数：

  • （空） — Claude 从上次停下的地方继续（读取 state.md）
  • 功能描述 — 开始处理指定功能（自然语言匹配）
  • #N — 按编号直接跳转到指定 CR（如 #3 → CR-003）
  • --last — 恢复上一个操作过的 CR
  • --batch — 连续推进模式：批量推进迭代内多个 S 复杂度 PF，最后统一审批

功能：

  1. 定位或创建一个任务
  2. 加载上下文（当前状态、质量规则、工作流）
  3. 新任务：运行意图检查点（确定工作范围）
  4. 自主编码、测试和验证
  5. 自动运行质量门禁
  6. 在待审批状态停下等你批准

停止时机：

  • 所有质量检查通过 → 进入待审批状态
  • 需要你做技术决策
  • 会话即将结束 → 保存检查点

/pace-status [子命令]

何时使用：你想知道当前进度。

核心参数（自动补全可见）：

参数 输出
（空） 1-3 行概览 + 建议
detail 功能树——当前迭代广度展开
tree 完整价值功能树——L3 全貌
trace <名称> 反向追溯——指定需求的深度下钻（可跨迭代）
metrics [quality|delivery|risk] 核心指标快照 + 趋势箭头；可按类别聚焦
since <时间> 指定时间段内的变更摘要（如 3d、1w、last-session）；可与其他子命令组合
关键词 匹配关键词的特定功能详情

角色视图（由 /pace-role 管理，也可直接作为子命令使用）：biz、pm、dev、tester、ops、chain。通过 /pace-role 设置角色后，概览和 detail 视图自动适配。

输出不包含内部 ID（CR-001）或状态机术语（developing）。一切都是自然语言。每个非概览子命令末尾附带上下文导航提示。

/pace-review [keyword]

何时使用：变更已准备好等你审批。

参数：

  • （空） — 审批所有处于待审批状态的变更
  • 关键词 — 审批指定变更

生成内容：

  • 改了什么（文件和内容）
  • 为什么改（关联的功能 → 业务目标）
  • 影响范围
  • 意图一致性（标准/复杂变更）：代码是否与计划范围一致？
  • 质量检查状态
  • 分支名称

简化审批：当满足所有条件（单个任务、≤3 个文件、质量门禁一次通过、0% 偏移）时，跳过等待，改用行内确认，减少流程开销。

你的回应选项：

你说 发生什么
"批准" / "LGTM" 任务合并，功能树更新，状态推进
"打回" + 原因 任务返回开发，记录原因
具体反馈 Claude 修复问题，重新检查，重新提交

/pace-next [detail]

何时使用：不确定该做什么时。

参数：

  • （空） — 1 条建议（≤3 行）
  • detail — 展开候选列表（≤8 行）
  • why — 展开推理链（2-5 行：信号扫描 + 优先级对比 + 角色影响 + 备选）
  • journey [模板名] — 展示完整工作流路径：从当前状态到目标的分步引导。模板：new-feature（默认）、iteration、hotfix、release、onboarding

功能：综合多维信号（in_review CR、developing CR、未验证部署、迭代完成度、retro 周期、backlog 状态等），按 12 级优先级矩阵推荐下一步行动。

只读：不修改任何状态文件。

/pace-plan [next|close|adjust|health]

何时使用：迭代边界——关闭当前迭代或规划下一轮。也用于迭代中途范围调整和健康度监控。

参数：

  • （空） — 评估当前迭代状态，建议下一步
  • next — 直接开始规划新迭代
  • close — 关闭当前迭代（归档为 iter-N.md）
  • adjust — 迭代中途范围调整（增删 PF、调整优先级）
  • health — 展示迭代健康度指标（完成率 vs 时间、范围稳定性）

功能：

  1. 评估当前迭代的功能完成率
  2. 关闭并归档当前迭代（如果请求）
  3. 展示功能树中可用的功能
  4. 引导你选择新迭代的范围、目标和时间线
  5. 生成 iterations/current.md
  6. 迭代中途：调整范围并重算容量（adjust）
  7. 健康监控：展示完成率 vs 时间进度、范围稳定性、速度趋势（health）

/pace-biz [subcommand] [args]

何时使用：上游业务规划——捕获机会、创建专题、分解需求、发现需求。

参数：

参数 说明
opportunity <描述> 捕获业务机会
epic [OPP-xxx] <描述> 从机会转化或直接创建专题
decompose <EPIC-xxx|BR-xxx> 分解 Epic→BR 或 BR→PF
align 战略对齐健康检查（只读）
view 业务全景视图（只读）
discover <描述> 交互式多轮需求发现，从模糊想法出发
import <路径>... 从文档提取需求（会议纪要、反馈、竞品分析）
infer 从代码库推断未追踪功能和技术债务
（空） 上下文感知推荐

推荐流程：

完整业务路径：  opportunity → epic → decompose → /pace-dev
探索式发现：    discover → decompose → /pace-plan next
多源导入：      import <文档> → align → /pace-plan next
代码库推断：    infer → align → /pace-dev

详见业务规划特性文档。

/pace-change [type] [#N|--last|--dry-run] [description]

何时使用：工作进行中需求发生变化。

参数：

参数 说明
add <描述> 插入新功能
pause <功能> 暂停功能（保留工作）
resume <功能> 恢复暂停的功能
reprioritize <描述> 调整工作顺序
modify <功能> <变更> 修改已有功能的范围
batch <描述> 批量变更（合并分析、一次确认）
undo 撤销上次变更（限当前会话）
history [功能|--all|--recent N] 查询聚合的变更历史
apply <模板名> 应用预定义的变更模板
（空） 基于项目上下文的智能引导

快捷引用：#N（按 CR 编号）、--last（最近操作的 CR）、--dry-run（仅预览）。

流程：始终遵循 影响分析 → 方案 → 确认 → 执行。Claude 不会未经你确认就做出变更。影响报告使用三层分级输出（默认 1 行摘要，追问展开）。

详见需求变更章节。

/pace-retro [update|focus|compare|history|mid|accept]

何时使用：迭代结束或想回顾进展时。

参数：

  • （空） — 完整回顾报告（含行动摘要 + 详情两层）
  • update — 仅刷新度量数据，附带变更反馈
  • focus <维度> — 聚焦分析：quality | delivery | dora | defects | value | knowledge
  • compare — 当前与上一迭代的指标差异对比
  • history — 跨迭代趋势概览（需 3+ 迭代数据）
  • mid — 迭代中期轻量检查（不更新仪表盘）
  • accept — 确认上次回顾建议的操作（MoS 更新等）
  • forecast — 交付预测：概率预估、瓶颈识别、风险预警

报告内容：

  • 行动摘要（~10 行）：关键指标 + 趋势 + 关注点 + 亮点 + 建议
  • 交付：计划 vs 实际完成的功能
  • 质量：门禁通过率、打回率
  • 缺陷：严重度分布、根因分析、修复周期
  • 价值：成功指标进展
  • 周期时间：平均任务持续时间
  • DORA 代理指标（有发布记录时）：含 Elite~Low 基准分级
  • 做得好的 / 需要改进的
  • 经验沉淀透明段（提交到知识库的 pattern 列表）
  • 迭代传递清单（供下一迭代规划使用）
  • 报告质量自评（数据充分性、趋势置信度、建议质量）

/pace-theory [topic]

何时使用：你想了解 devpace 的设计方法论。

参数：

主题 内容
（空） 速查卡片 + 分层导航
model 概念模型（对象、空间、规则）
objects 工作对象（BR、PF、CR、发布、缺陷）详解
spaces 作业空间（产品线、交付团队、应用、发布单元）
rules 工作流规则和质量检查
trace 价值链追溯和双向追溯
topic 专题模式与成效指标（MoS）
metrics 度量框架（DIKW 模型 + 三维度量）
loops 三个反馈环（业务、产品、技术）
change 变更管理理论
decisions 关键设计决策及其理论依据（16 条）
mapping 理论 → devpace 实现映射
vs-devops devpace 方法论与 DevOps 的区别
sdd 规格驱动开发参考（Spec Kit 映射）
why 解释设计理由；支持 why <关键词>（如 why gate、why paused）
all 完整知识库（~550 行）
<关键词> 在知识库中搜索匹配内容

只读：不修改任何状态文件。

/pace-test [子命令] （可选）

测试验证专家——不只是"跑测试"，而是基于需求验收标准评估测试覆盖度，AI 驱动逐条验收验证。

何时使用：想知道测试够不够、哪里不够、怎么补。

按场景使用：

日常开发中：

用法 作用
/pace-test 运行所有已配置的测试，输出结构化报告
/pace-test accept AI 逐条比对验收标准——附代码行号证据，三级判定（✅通过 / ⚠️需补充验证 / ❌未通过），审查测试断言实质性

想了解测试全局：

用法 作用
/pace-test strategy 从功能验收标准生成测试策略——每条标准推荐测试类型（含安全/性能辅助类型）和优先级
/pace-test coverage 分析验收标准的测试覆盖度（需求覆盖率为主，代码覆盖率为辅）
/pace-test report 聚合三层数据生成审查报告：测试结果 + 需求覆盖 + AI 验收

需求变更后：

用法 作用
/pace-test impact 分析代码变更影响了哪些功能，按优先级推荐需要重跑的测试
/pace-test impact --run 分析后自动执行"必跑"测试列表

更深入（按需使用）：

用法 作用
generate [--full] 从验收标准生成测试用例（默认骨架，--full 生成完整实现）
flaky 测试健康度分析：不稳定测试、空断言、耗时膨胀、长期未更新测试
dryrun [1|2|4] 模拟 Gate 检查（不触发状态转换，用于预检）
baseline 建立测试基准线（供回顾度量对比）
report REL-xxx Release 级质量报告（聚合所有 CR 的测试数据 + 发布建议）

accept 提升审批质量：

Gate 2 检查"代码是否与计划一致"。accept 在此基础上提供更精细的证据，帮助人类更高效地审批：

  • 逐条验收标准附代码证据（引用具体文件和行号）
  • 三级判定：✅通过 / ⚠️需补充验证 / ❌未通过（Gate 2 只有通过/不通过）
  • 测试预言审查：已有测试是否真的验了它声称覆盖的验收条件
  • 自动降级：发现弱覆盖或虚假覆盖时，自动降级测试策略状态

不做 accept 也能通过 Gate 2——但做了 accept 的变更在人类审批时有更充分的证据支撑。

推荐流程：

  • 首次：strategy → generate → 编写实现 → coverage → 开发 → 运行测试 → accept → report
  • 日常：运行测试 + accept 就够了。变更后用 impact --run 快速回归
  • 发布前：report REL-xxx 生成 Release 级质量报告

/pace-release [action] （可选）

这是可选功能。如果你没有正式的发布流程，可以跳过。任务 merged 就是你的完成点。

何时使用：管理生产发布——从创建 Release 到生成 Changelog、版本 bump、Git Tag 和 GitHub Release。

参数：

日常使用（大多数场景只需这些）：

参数 动作
create 收集已合并的任务创建新发布 + Gate 4 系统级检查
deploy 记录部署已执行（支持多环境晋升）
verify 执行验证清单（支持自动化验证命令）
close 完成发布（自动 changelog + 版本 bump + tag + 连锁更新）
full close 的推荐别名（语义更明确）
status 查看当前发布状态和建议下一步
（空） 引导式发布向导——根据当前状态自动引导（推荐新用户使用）

单独使用（当你只需要其中某个步骤时）：

参数 动作
changelog 仅生成 CHANGELOG.md（close 会自动执行此步骤）
version 仅更新版本文件（close 会自动执行此步骤）
tag 仅创建 Git Tag / GitHub Release（close 会自动执行此步骤）
notes 生成面向最终用户的 Release Notes（按业务需求分组）
branch 管理发布分支（创建 release 分支或 Release PR）
rollback 记录回滚操作（deployed 状态下出现严重问题时）

Changelog vs Release Notes：

Changelog Release Notes
受众 开发者 产品用户
组织 按类型（Features / Bug Fixes） 按业务需求→功能
语言 技术语言 产品语言

发布分支（可选，通过 integrations/config.md 配置）：

  • branch create — 创建 release/v{version} 分支
  • branch pr — 创建 Release PR（含 changelog + version bump），merge PR = 确认发布
  • branch merge — 合并 release 分支回 main

回滚：deployed 状态下发现严重问题时，/pace-release rollback 记录回滚原因并引导创建修复任务。rolled_back 是终态，修复后需创建新 Release。

配置增强：在 .devpace/integrations/config.md 中可配置版本文件路径/格式、验证命令、发布分支模式、CI 检查命令。无配置时所有功能降级到手动模式。多环境时按环境表行序逐步晋升部署（如 staging → canary → production），每个环境独立 deploy + verify。

/pace-guard [action]

这是可选功能。需要 .devpace/risks/ 目录存在（/pace-init 不自动创建，首次使用时自动创建）。L/XL 复杂度 CR 会在意图检查点自动触发 scan。

何时使用：编码前评估风险、开发中跟踪风险状态、跨迭代分析风险趋势。

参数：

参数 动作
scan [CR编号] Pre-flight 风险扫描——5 维评估 + OWASP 安全扫描（历史教训/依赖影响/架构兼容性/范围复杂度/安全：Layer 1 关键词 + Layer 2 OWASP 模式）
monitor [CR编号] 汇总当前 CR 的实时风险状态（已缓解/待处理/新增）
trends [迭代ID] 跨 CR 趋势分析（按类别统计、重复风险识别、改进建议）
report 项目级风险仪表盘（按 PF 分组、按等级排序、总体风险评分）
resolve <RISK编号> <状态> 更新风险状态（mitigated / accepted / closed）
（空） 等同于 scan，对当前 CR 执行风险扫描

风险等级与响应：

等级 行为
Low 静默记录，不打扰
Medium 记录 + 提醒 + 缓解方案建议
High 暂停开发，等待人类确认（铁律）

自动触发（不需手动调用）：

  • L/XL CR 进入开发时自动 scan
  • 推进模式每个 checkpoint 轻量风险检测
  • 脉搏检查发现风险积压时触发 monitor

降级模式：无 .devpace/ 时 scan 仍可用（基于代码库即时评估），trends/report/resolve 需要历史数据不可用。

/pace-feedback [report <描述>] 或 [反馈描述] （可选）

这是可选功能。用于系统化收集上线后反馈和处理生产事件。

何时使用：收到用户反馈、发现 bug、或需要报告生产问题。

参数：

  • report <描述> — 紧急通道：跳过分诊，进入生产事件分支并启用加速路径评估（仅 hotfix/critical）
  • incident open <描述> — 创建事件记录（严重度评估 + 时间线初始化）
  • incident close <INCIDENT-xxx> — 关闭事件 + 生成 postmortem 模板
  • incident timeline <INCIDENT-xxx> — 查看事件时间线
  • incident list — 列出所有事件（支持 --open 筛选）
  • <反馈描述> — 分类后路由（生产事件/缺陷/改进/新需求/记录待定）
  • （空） — 渐进式两轮引导收集（先收集必要信息，严重度 ≥ major 时再补充细节）

功能：

  1. 分类反馈（生产事件/缺陷/改进/新需求）
  2. 生产事件：评估严重度 → 追溯来源 → 创建 defect/hotfix 任务
  3. 缺陷：自动创建修复任务并关联功能
  4. 改进/新需求：记录或引导走变更管理流程

/pace-trace [keyword] （可选）

何时使用：你想了解 Claude 某个决策背后的完整推理过程。

参数：

  • 关键词 — 查询特定决策的推理轨迹（如"为什么打回"、"Gate 2"）
  • arch [标题|ADR-NNN|list|supersede] — 架构决策记录（ADR）管理
  • （空） — 展示最近的决策轨迹

功能：读取任务事件表、checkpoint 标记和溯源标记，重建 Gate/意图/变更等决策的完整推理过程。同时管理跨 CR 的架构决策记录（ADR）。

只读：不修改任何状态文件。

/pace-sync [子命令] [参数] （可选）

将 devpace 状态与外部项目管理工具（GitHub Issues）桥接。v1.5.0 为 push-only MVP。

何时使用：你想让 GitHub Issues 与 devpace CR 状态保持同步。

前置条件：安装 gh CLI（推荐），配置 git remote。

子命令：

子命令 参数 说明
setup [--auto] 引导式同步配置（检测 remote → 生成 sync-mapping.md）
link CR-ID [#外部ID] 关联 CR 与 GitHub Issue（省略 ID 则智能匹配）
push [CR-ID] [--dry-run] 推送 devpace 状态到外部（指定 CR 或全部已关联）
unlink CR-ID 解除 CR 与外部实体的关联
create CR-ID 从 CR 元数据创建外部 Issue 并自动关联
pull CR-ID 检查外部状态并提示更新（轻量 MVP）
ci status — 查看当前分支的 CI/CD 运行状态
ci trigger [workflow] 手动触发 GitHub Actions workflow
ci logs [run-id] 查看指定运行的日志摘要
status — 查看同步状态和外部链接

无参数时默认 status。--dry-run 预览操作但不实际执行。

状态映射（devpace → GitHub 标签）：

devpace 状态 GitHub 标签 方向
created backlog ↔
developing in-progress ↔
verifying needs-review →
in_review awaiting-approval →
approved approved →
merged 关闭 + done ↔
released released →
paused on-hold ↔

快速上手：setup → link CR-003 #42 → push

降级：无 gh CLI → setup 仍可用（配置标注未验证），push/status 不可用。无 sync-mapping.md → 引导 setup。核心 devpace 流程不受影响。

详细场景和开发者指南见外部工具同步。

/pace-role [role] （可选）

切换 Claude 的输出视角。不切换时默认 Dev 视角。

何时使用：你想从不同视角查看项目信息。

参数：

角色 关注点
biz 业务价值、目标达成
pm 交付节奏、优先级、迭代进度
dev 代码质量、技术细节（默认）
tester 缺陷分布、测试覆盖
ops 发布状态、部署健康
（空） 显示当前角色和选项

工作模式

探索模式（默认）

当你在阅读代码、分析问题或讨论方案时，devpace 不会打扰你：

  • 不修改状态文件
  • 不创建任务
  • 不触发质量门禁
  • 不施加工作流约束

触发词："看看..."、"分析..."、"解释..."、"如果..."

推进模式

当你开始修改代码时，devpace 启动：

  • 创建或关联一个任务
  • 通过工作流追踪状态
  • 在状态转换时运行质量门禁
  • 更新状态文件和功能树

触发词：/pace-dev（直接进入），或"实现..."、"修复..."、"开发..."、"继续..."

首次进入确认：会话中首次表达编码意图时（不使用 /pace-dev），Claude 会自然地问："我来帮你管理这次开发——跟踪进度、自动检查质量、记录变更。需要这样做，还是只想快速改个东西？" 确认后本次会话后续自动进入推进模式。选择"快速改"则跳过。

使用 /pace-dev 总是直接进入推进模式，无需确认。

状态机详情

日常使用不需要了解这些。这是推进模式下任务状态流转的完整参考。

created -> developing -> verifying -> in_review -> approved -> merged -> released (optional)
              |               |            ^
              |               |            |
              +-- Gate 1 -----+-- Gate 2 --+-- Gate 3 (human)
              (code quality)  (integration)  (code review)

Any state <-> paused  (preserves all work, change management)
Hotfix fast path: created -> developing -> verifying -> merged (critical only)
状态 用户感知 说明
created "已创建" 任务刚创建，还没开始
developing "在做" Claude 在写代码和测试
verifying "在验证" 集成测试和意图一致性检查
in_review "等你审批" Claude 停下，等你决定
approved "已批准" 你批准了，正在合并
merged "已完成" 代码已合并（默认终态）
released "已发布" Release 关闭后自动标记（可选终态）
paused "暂停中" 需求变更导致暂停，所有工作保留
  • Gate 1/2：Claude 自动执行，自动修复失败，不打扰你
  • Gate 3：人类 Code Review——Claude 生成摘要并停下等你
  • released：可选——不使用发布流程时 merged 就是完成

任务类型

类型 用途 说明
feature 新功能或增强（默认） 正常迭代中的产品功能开发
defect 缺陷修复 已发布功能发现的问题
hotfix 紧急修复 生产环境紧急问题，可走加速路径

需求变更

devpace 把需求变更当作正常操作，而非异常。

插入新需求

/pace-change add 我们需要一个导出 CSV 的功能

Claude：

  1. 在功能树中创建新功能
  2. 创建任务
  3. 评估迭代容量（能放进去吗？）
  4. 提出排期建议（现在做，还是排队？）
  5. 等待你确认

暂停功能

/pace-change pause authentication

Claude：

  1. 在功能树中标记 ⏸️
  2. 保留所有工作（代码、分支、质量检查进度）
  3. 调整依赖关系（解除等待此功能的阻塞）
  4. 更新工作计划

恢复暂停的工作

/pace-change resume authentication

Claude：

  1. 恢复到暂停前的状态
  2. 如果暂停期间代码有变更，重新验证质量检查
  3. 更新工作计划

重排优先级

/pace-change reprioritize 把导出功能排到搜索前面

Claude：

  1. 重新排列工作队列
  2. 更新 state.md 和迭代计划
  3. 记录原因

修改已有需求

/pace-change modify authentication 增加 OAuth2 支持

Claude：

  1. 更新功能范围
  2. 识别哪些已有代码需要返工
  3. 重置受影响的质量检查
  4. 在任务事件日志中记录变更

质量门禁

Gate 1：代码质量（developing → verifying）

在 .devpace/rules/checks.md 中定义的自动检查：

  • Lint / 格式化
  • 测试通过
  • 类型检查（如适用）

Claude 自动运行，修复失败并重试。不会打扰你。

Gate 2：集成检查（verifying → in_review）

  • 集成测试通过
  • 意图一致性检查（代码是否与计划匹配？）
  • 语义一致性评分（代码与验收标准的对齐度——分为高/中/低三级）
  • 无意外副作用

同样自动执行。Claude 在推进前修复问题。

Gate 3：人类审批（in_review → approved）

Claude 生成审批摘要并停下。你来决定：

  • 批准 → 合并
  • 打回 → 返回开发，附带反馈
  • 提出修改 → Claude 修复并重新提交

Gate 4：系统级发布门禁（Release create → deploy）（可选）

Release 级别的检查（依赖 integrations/config.md 配置）：

  • 运行构建/测试命令验证代码可构建
  • 检查 CI pipeline 状态
  • 确认所有纳入任务的 Gate 1/2/3 均已通过

无配置时 Gate 4 静默跳过，不影响发布流程。

跨会话连续性

工作原理

  1. 会话结束：Claude 更新 state.md，记录当前进度和下一步
  2. 新会话开始：devpace Hook 读取 state.md 并注入上下文
  3. Claude 报告：一句话描述当前状况
  4. 你说"继续"：工作从上次停下的地方精确恢复

自适应会话结束：无 .devpace/ 变更时不执行结束协议；简单场景 1 行，标准场景 3 行，复杂场景 5 行——避免不必要的开销。

保留的内容

  • 当前正在处理的功能
  • 任务状态和质量检查进度
  • 下一步建议
  • 阻塞项和依赖关系

不保留的内容

  • 对话历史（那是 Claude 会话，不是 devpace）
  • 工具状态或文件缓冲区

关键洞察：devpace 保留的是项目状态，而非对话状态。这意味着即使 Claude 丢失了对话记忆，项目状态也能告诉它继续工作所需的一切。

项目文件

.devpace/state.md

会话锚点。5-15 行。自动维护。

包含：当前阶段、进行中的工作、下一步、阻塞项。

.devpace/project.md

价值-功能树。展示从业务目标到功能的完整层级。

在功能添加、完成或暂停时自动更新。

.devpace/backlog/CR-NNN.md

每个任务一个文件。包含：标题、状态、关联功能、质量检查状态、事件日志。

开始工作时自动创建。

.devpace/iterations/current.md

当前迭代计划。追踪计划 vs 实际、变更记录。

.devpace/rules/workflow.md 和 checks.md

项目特定的工作流规则和质量检查。在 /pace-init 时设置。

.devpace/metrics/dashboard.md

度量仪表盘。由 /pace-retro 更新。

方法论映射

devpace 基于 BizDevOps 方法论构建——将业务（Biz）、开发（Dev）和运营（Ops）整合为统一的价值交付链。本节展示 devpace 功能与方法论生命周期阶段的对应关系。

生命周期阶段

阶段 做什么 谁主导 devpace 功能 反馈闭环
目标设定 定义业务目标和成功指标 你 /pace-init、project.md 业务闭环
规划 将目标分解为功能、规划迭代 你 + Claude /pace-plan、/pace-change 产品闭环
开发 编码、测试、质量门禁 Claude（你来决策） /pace-dev、/pace-guard 技术闭环
验证 质量检查、需求一致性、人类审批 自动 + 你 /pace-review、/pace-test 技术闭环
发布 Changelog、版本、Tag、部署、验证 Claude（你确认） /pace-release 运维闭环
反馈 收集反馈、追踪缺陷、衡量成果 你 + Claude /pace-feedback、/pace-retro 业务闭环

反馈闭环

devpace 实现四个持续反馈闭环：

闭环 范围 周期 devpace 如何实现
业务闭环 目标 → 成果 项目/季度级 project.md 中的 MoS（成效指标）追踪，/pace-retro 目标达成回顾
产品闭环 功能 → 用户价值 迭代级 /pace-plan 迭代规划，/pace-retro 交付回顾，/pace-change 迭代中调整
技术闭环 代码 → 质量 任务级 自动质量门禁（Gate 1/2/3），/pace-test 需求追溯验证
运维闭环 部署 → 稳定性 发布级 /pace-release 发布编排，/pace-feedback report 生产事件追踪

度量体系

devpace 从三个维度自动采集度量（从工作数据中自动生成，零手动填写）：

维度 度量指标 devpace 功能
交付效能（DORA 代理值） 部署频率、前置时间、变更失败率、MTTR /pace-retro，含 Elite~Low 基准分级
质量保障 门禁一次通过率、人类打回率、缺陷逃逸率 自动质量门禁 + /pace-test
价值对齐 成效指标达成率、价值链完整率、交付周期 project.md 追溯链 + /pace-retro

了解完整理论背景，请在 devpace 中运行 /pace-theory。

使用技巧

让 devpace 处理记账工作

不要手动编辑 .devpace/ 文件。Claude 在你正常工作的过程中自动维护它们。

一切用自然语言

不必使用 /pace-change modify auth Add OAuth2，你可以直接说：

"认证功能还需要支持 OAuth2"

Claude 检测到变更意图并执行相同的流程。

不确定时查看状态

/pace-status 给你一行答案。无需切换上下文、无需翻文件。

在自然检查点审批

当 Claude 说"准备好审批"，用 /pace-review 查看结构化摘要后再批准。

定期做回顾

每轮迭代结束时运行 /pace-retro，积累数据让未来的规划更准确。

常见问题

"没有活跃的 devpace 项目"

运行 /pace-init 在你的项目目录中设置 .devpace/。

Claude 在新会话中没有恢复上下文

检查 .devpace/state.md 是否存在且有内容。SessionStart Hook 自动读取此文件。

质量检查持续失败

检查 .devpace/rules/checks.md——里面的命令必须在你的项目中能运行（如 npm test、pytest）。

功能树看起来不对

运行 /pace-status tree 查看当前状态。如果需要修正，告诉 Claude 哪里不对，它会更新。

变更没有被追踪

确保你在推进模式下（正在写代码）。探索模式不追踪状态。