舒服了，CabloyJS 的 AI Spec 驱动开发会自动生成甘特图和燃尽图

AI 编程最容易开始的方式，是在对话框里描述一个页面或一个接口。但当项目拥有多个模块、多个使用者和一条不断演进的前后端契约时，真正困难的问题变成了：这次改动属于哪里？哪些边界已经确认？怎样证明它确实完成了？

CabloyJS 内置了两个互补的 Claude Code Skills，把工作拆成两个阶段：先建立仓库内的规格权威，再执行一个有界的交付增量。本文先讲这两个 Skills，再解释它们产生和消费的 Spec 文件，最后用内置套件 a-commerce 的真实图表说明结果。

先认识两个 Skills

两个 Skill 的入口分别是：

• cabloy-spec-generation：创建或维护 repo-specs/<suite>/ 下的套件规划记录，建立产品、技术、交付和验收之间的追溯关系。
• cabloy-spec-execution：在已有规格的基础上，执行一个明确的 WBS-* 项或一个已经明确批准、具有关闭边界的有限阶段，并记录实际验证结果。

可以先用下面的表格记住差异：

维度	cabloy-spec-generation	cabloy-spec-execution
解决的问题	应该做什么，边界和验收如何记录	已批准的这一项如何实现并证明完成
输入	新套件描述，或现有规格的维护需求	一个明确的 WBS-*，或有限且已批准的阶段
主要产物	PRD、SRS、PDP/WBS、ATP、ADR、派生状态和图表	源码变更、测试结果、Evidence、派生 progress 和图表
确认门	写入规划记录前确认 identity、范围、拓扑、站点策略等	实施前确认 execution dossier、依赖、范围、命令和证据要求
不负责的事	不写业务源码，不把规划当作实现	不发明需求，不替代规格生成，不自动扩大到相邻任务

1. 用 generation 建立规格基线

在 Claude Code 中，可以从业务描述开始：

/cabloy-spec-generation 为一个面向维修技师和运营经理的设备维护套件制定规划：包含设备档案、工单、资产历史、基于角色的访问控制和 Admin 仪表盘。

这个 Skill 先做只读发现并询问缺失输入，典型步骤是：

1. 检查仓库根目录、package.json、CLAUDE.md 和 edition marker；
2. 区分新套件、已有套件扩展，检查 repo-specs/<suite>/ 是否已经存在；
3. 分别评估 Web 和 Admin 应该复用现有站点还是使用独立站点；
4. 收集产品目标、角色、范围、模块拓扑、租户/权限、状态、事务、验证和发布约束；
5. 先展示生成确认门，确认后才写入规划记录；
6. 按权威顺序生成文件，进行 exact-ID 追溯检查，并生成两张派生图表。

2. 用 execution 执行一个有界增量

规格准备好并且某个任务的依赖满足后，再调用 execution：

/cabloy-spec-execution WBS-40-03

这里的 WBS-40-03 只是示例；实际项目应使用目标套件中真实存在的 ID。AI将自动执行如下流程：

1. 读取 README.md、PRD、SRS、适用 ADR、完整 WBS、ATP/test plan、progress、证据和派生图表；
2. 检查 edition、当前 revision、工作区状态、依赖、阻塞项、未决 TODO 和旧证据是否仍然有效；
3. 生成 execution dossier，列出目标、范围、排除项、权威 ID、源码所有权、专业 Skill 路由、验证命令和证据格式；
4. 获得明确确认后，才路由到后端、前端或 Contract Loop 专业流程；
5. 先做最窄的有意义检查，再执行 ATP 要求的验证；
6. 保存带 revision、环境、步骤、结果和脱敏产物位置的 Evidence；
7. 更新派生 progress.md，重新生成并检查图表，留下唯一的下一步行动。

/cabloy-spec-execution 执行设备维护套件的后续任务

如果用户不知道下一个增量任务的 WBS ID，可以让 AI 先读取该套件的 progress.md，并结合 WBS、ATP 和已有 Evidence，列出依赖已满足、可供执行的 WBS-* ID 清单；用户再确认下一步具体执行哪一项。

generation 生成什么：一套互相连接的 Spec 文件

对于一个长期演进的业务套件，cabloy-spec-generation 的默认核心输出位于：

repo-specs/<suite>/
├── README.md
├── prd.md
├── srs.md
├── pdp-wbs.md
├── test-plan.md
├── progress.md
├── implementation-gantt.svg
├── implementation-burndown.svg
└── decisions/
    └── 0001-<suite-boundary-slug>.md

这不是“一份大文档拆成几份”的简单关系，而是分域权威：每份记录负责一种事实，其他记录通过稳定的 ID 和链接引用它。

文件	它负责的事实	它不应该替代什么
README.md	索引、阅读顺序、套件基线、拓扑摘要和权威地图	不替代 PRD、SRS 或 WBS 的详细内容
prd.md	产品目标、角色、范围、旅程、业务规则、产品需求和产品验收	不规定表名、DTO 语法、路由或测试命令
srs.md	技术契约、数据/能力所有权、租户、身份、授权、状态、事务、并发、API/DTO、SSR 和非功能边界	不用一个 UI 布局决定 API 权威或权限
pdp-wbs.md	交付阶段、WBS 任务、依赖、完成检查和交付追溯	不改变上游产品需求和技术契约
test-plan.md	ATP 验收场景、测试级别、夹具、验证程序、Evidence 格式和发布门	不把计划中的命令写成已经通过的结果
progress.md	WBS 状态、阻塞、证据指针、决定事项和下一证明	不重新定义需求、契约或验收规则
decisions/*.md	需要长期保留的范围、架构、安全、所有权或集成决策	不应成为重复的 SRS 或状态日志
implementation-gantt.svg	从 WBS 派生的阶段、任务顺序、依赖和状态视图	不提供规划权威、日期或工期承诺
implementation-burndown.svg	从范围和状态派生的剩余项计数视图	没有历史快照时不代表速度趋势或预测

从业务意图到证据：文件之间如何连接

核心追溯链是：

PRD requirement
      ↓
SRS contract
      ↓
PDP/WBS task
      ↓
ATP scenario
      ↓
observed Evidence

它也可以简写为：

PRD → SRS → WBS → ATP → Evidence

例如，产品要求“授权的操作员可以在当前租户内查看订单”，需要在 SRS 中具体化为身份、租户、授权、数据所有权和 API 契约；然后由 WBS 指定实现边界和依赖；再由 ATP 给出可执行的正常、越权和跨租户场景；最后把实际运行时观察结果保存成脱敏证据。

当执行任务时，文档状态更新顺序是：

上游权威变更
  → 追溯矩阵
  → WBS 依赖与完成检查
  → ATP 程序与预期证据
  → progress / Evidence
  → 两张派生图表

progress.md 和两张 SVG 都是下游派生结果：它们帮助人和 AI 快速了解状态。

两张图如何读

图表由内置脚本依据 pdp-wbs.md、test-plan.md 和 progress.md 自动生成。

Gantt：看交付顺序，不看日历排期

Gantt 图读取正式的 Phase、WBS 任务、依赖和 progress 状态。它适合回答：有哪些交付包？大致先后关系是什么？哪些任务依赖前置阶段？

内置套件 a-commerce 当前图表包含 23 个正式 WBS 任务，显示为 23/23 verified。

Burndown：看范围计数，不看速度预测

Burndown 图在当前 a-commerce 快照中显示：23 个 active WBS、23 个 verified、0 个 remaining、0 个 deferred。

这套方法何时值得

它更适合长期演进、跨模块、多人协作、同时包含 Vona 后端与 Zova Admin/Web/SSR 的企业系统，尤其是租户、授权、事务、并发、审计或外部集成很重要的业务。

对于一次性页面、简单网站或极小工具，轻量的 Prompt-to-Code 流程可能更经济。

从一个小增量开始

可以先选一个边界清楚的能力，而不是尝试一次规划整个系统：

1. 用 generation 规划需求；
   • 记录目标、范围和排除项；
   • 确认技术契约、所有权、依赖和 ATP；
2. 用 execution 执行一个 WBS ID；
   • 运行适用验证，保存脱敏 Evidence；
   • 更新 progress 和派生图表
3. 执行下一步。

创建 Cabloy 项目可以从公开脚手架开始：

npm create cabloy
npm run dev
npm run dev:zova:admin
npm run dev:zova:web

结语

AI Spec 驱动开发在 CabloyJS 中不是“Prompt 变代码”的另一种说法，而是一条更具体的工作路径：

业务意图 → 规格权威 → 有界 WBS → 验收程序 → 观察证据

cabloy-spec-generation 负责把意图整理成可追溯的规划链，cabloy-spec-execution 负责在确认后的边界内推进一个增量。两者共同减少 AI 对业务范围、技术所有权和完成标准的猜测。

延伸阅读

• AI Spec-Driven Development
• Generate a Cabloy Suite Specification
• Execute an Approved Cabloy Specification Increment
• Verification
• Contract Loop Playbook
• Vona + Zova Integration
• Cabloy Fullstack Quick Start Tutorials