CC端到端开发skill：fully-coding 长周期编程工具

前言：这篇文章梳理 fully-coding skill 的整体架构。它不是一个单点代码生成命令，而是一个由 Orchestrator 串行调度、由文档驱动状态流转、由规则约束交付质量的 Claude Code 开发流水线。

本博文对应的代码仓库见：(Github)[https://github.com/seedily/claude-coding-skills]

背景

很多 Claude Code 工作流一开始都很轻：用户说需求，模型改代码，最后跑一下测试。这个模式在小改动上很高效，但当任务进入企业项目后，问题会变复杂：需求要可追溯，方案要可复盘，代码要评审，测试要闭环，文档还要同步。

fully-coding 的设计思路是把一次自然语言开发请求，拆成一条固定的交付流水线。它用 Orchestrator 负责调度，用 userStory.md 和 codingLog.md 作为步骤之间的接口，用规则文件约束每一步的输入、输出和退出条件。

这背后是一种 SDD（Specification-Driven Development，规范驱动开发）思路：规范不是代码完成后的说明书，而是开发过程中的第一性产物。需求、范围、方案、评审、测试和文档同步都先被写成可读取、可验证、可交接的规范，再由 Orchestrator 按规范推进实现。

这套机制牺牲了一部分轻量感，换来的是过程可审计、任务可恢复、文档可同步。

核心定位

fully-coding 的一句话定位是：

面向企业项目的 Claude Code 规范化交付 Orchestrator。

它覆盖完整 9 步：

用户输入
  → Step 1 需求检索
  → Step 2 需求生成
  → Step 3 开发范围
  → Step 4 开发方案
  → Step 5 开发实现
  → Step 6 代码评审
  → Step 7 测试用例
  → Step 8 文档更新
  → Step 9 自主进化

对应的角色分工如下：

步骤	主导角色	核心产出
Step 1-2	需求分析师	{ts}-userStory.md
Step 3-4	架构师	{ts}-codingLog.md 中的范围与方案
Step 5	开发者	代码变更与实现记录
Step 6	DBA + Reviewer	评审意见与修复结论
Step 7	开发者	测试覆盖与测试结果
Step 8	架构师	知识库同步记录
Step 9	Orchestrator	{ts}-suggestion.md 与完成状态

Orchestrator 如何调度

Orchestrator 是整个流程的中枢。它不负责替代每个角色的专业判断，而是负责保证流程按契约推进。

它做几件事：

1. 解析执行模式。
2. 生成或恢复任务时间戳 {ts}。
3. 按 runtime load map 加载当前步骤最少需要的上下文。
4. 检查 workflow rules 中定义的进入条件和退出条件。
5. 调用当前步骤对应角色完成任务。
6. 将产出写入 .dev-log/ 文档。
7. 根据评审、测试和阻塞规则决定继续、修复或暂停。

可以把它理解为一个“文档驱动状态机”：

flowchart TD A[用户输入需求] --> B[Orchestrator 解析参数] B --> C{选择执行模式} C -->|标准模式| D[Step 1-9] C -->|--plan-only| E[Step 1-4] C -->|--quick-dev| F[最小需求记录 → Step 3/5/6/7] D --> G[写入 userStory / codingLog / suggestion] E --> H[status=planned] F --> I[status=completed] G --> J{是否阻塞} J -->|否| K[继续下一步] J -->|是| L[登记 blockLog 并暂停]

三种执行模式

fully-coding 没有把所有任务都强行放进 9 步。它支持三种模式。

模式	参数	执行范围	适合场景
标准模式	无	Step 1-9	企业功能、复杂后端、需要完整审计和文档闭环
方案模式	--plan-only	Step 1-4	只需要先产出需求、范围和方案，不修改代码
轻量开发模式	--quick-dev	最小需求记录 → Step 3 → Step 5 → Step 6 → Step 7	小 bug、明确小改动、仍希望保留评审和测试

--plan-only 的价值在于先把方案说清楚，再决定是否进入开发。它完成后将任务状态标记为 planned，不会自动进入 Step 5。

--quick-dev 的价值在于减少小任务成本。它跳过完整 Step 2、Step 4、Step 8、Step 9，但仍保留范围定位、开发实现、代码评审和测试用例。

串行执行为什么重要

fully-coding 明确禁止并行 Agent、TeamCreate 和 background subagent。这个限制看起来保守，但它解决的是企业项目里的可控性问题。

如果多个 Agent 同时修改代码、更新文档、生成错误码，很容易出现这些问题：

• 输出顺序不可控。
• .dev-log 状态不一致。
• 错误码或功能文档被重复创建。
• 某个 Agent 基于过期上下文继续开发。
• 代码评审和修复循环无法闭合。

所以 fully-coding 选择了单 Claude 实例串行推进。它把并发吞吐让给了确定性和可恢复性。

备注：本工具虽然声明了每个步骤节点之间做串行流转，但对于单个步骤节点而言，还是可以自行调整为多角色并行协作。例如使用 Agent Teams 做多角色协作，其工作质量会有一定的提升，但消耗的 token 也是线性倍增。

文档即接口

这套架构最关键的设计是“文档即接口”。

下游角色不依赖上游角色的临时记忆，而是读取已经落盘的文档：

文档	作用
{ts}-userStory.md	保存原始提示词、需求检索、需求终稿、验收标准、假设和歧义
{ts}-codingLog.md	保存开发范围、开发方案、代码变更、评审、测试、文档更新、自检结果
{ts}-blockLog.md	只在真正阻塞时创建，记录等待用户确认的事件
{ts}-suggestion.md	Step 9 输出的文档一致性自检和工具改进建议

这种设计的好处是：

• 中断后能恢复。
• 用户能审计每一步。
• 后续角色有稳定输入。
• 任务完成后有完整过程记录。

更重要的是，每份文档都承担了“交接件”的角色。上一步不是把结论留在对话里，而是把结论固化成下游步骤可以直接消费的规范，这也是后续自动化流程能够成立的前提。对于超长周期编程来说，这种可见、可接管、可校验的文档边界，比一次性上下文记忆更可靠。

Runtime Load Map：用懒加载节省 token

完整规则很多，如果每次都全部加载，token 成本会很高。runtime-load-map.md 的作用就是定义每一步的最小上下文。

例如：

步骤	必读	按需读取
Step 3	架构师 Step 3、workflow rules、userStory、codingLog 模板	技术方案、服务设计、错误码、Git 规则
Step 4	架构师 Step 4、功能实现概览、功能实现模板、错误码文档	DDD、编码、持久层、安全、异常规则
Step 6	DBA、Reviewer、review checklist、本次 diff、codingLog Step 5	命中具体风险时读取完整规则
Step 8	架构师 Step 8、workflow rules、codingLog Step 3-7	触发矩阵涉及的知识库文档

这是一种渐进式上下文加载策略。它让流程保留完整规则能力，但不在每一步都支付全部上下文成本。

和普通 Claude Code 工作流的区别

普通工作流更像“即时协作”：

用户说需求 → Claude 修改代码 → 用户看结果

fully-coding 更像“可审计流水线”：

用户说需求 → 需求文档 → 范围文档 → 方案文档 → 代码 → 评审 → 测试 → 知识库 → 自检

两者没有绝对优劣。区别在于目标：

• 如果你只想快速改几行代码，普通工作流更轻。
• 如果你需要交付可追踪、可恢复、可审计的企业功能，fully-coding 更稳。

总结

fully-coding 的架构核心不是“让 Claude 多写代码”，而是“让 Claude 按工程流程交付代码”。

它真正坚持的是 SDD：先把规范做成第一性产物，再让代码、评审、测试和知识库围绕规范流转。文档规范化不是额外负担，而是自动化和超长周期编程的基础设施。

它的三个关键设计是：

1. Orchestrator 串行调度：确保每一步按契约执行。
2. 文档驱动状态流转：让过程可审计、可恢复。
3. runtime-load-map 懒加载：在规则完整性和 token 成本之间取得平衡。

如果把 Claude Code 看作一个强大的开发执行器，那么 fully-coding 做的事情，就是给这个执行器加上项目级流程、质量门禁和恢复机制。