CC 端到端开发 Skill：全方位的 AI Ready
一个工具从诞生到衍生出五个档位，只用了几周时间。推动它进化的不是"功能不够多"，而是一个逐渐清晰的认知：AI 写的代码越多，信息熵越大，质量越不可控。最终工具的本质从"纯粹的提效"变成了"提效 + 质量保证"。
本博文对应的代码仓库见：(Github)[https://github.com/seedily/claude-coding-skills]
背景
两个月前，fully-coding 只有一种模式：标准 9 步全流程。需求检索 → 需求生成 → 开发范围 → 开发方案 → 开发实现 → 代码评审 → 测试用例 → 文档更新 → 自主进化——一步不落。
在使用过程中，两个反馈同时出现。
一方面是"流程太重了，修个排序 Bug 也要走 9 步，感觉在写论文"。另一方面是"能不能并行跑多个任务？这周要交付多个需求"。
这两个反馈指向同一个根因：单档位无法匹配不同规模的任务。
于是有了第一轮拆分。后面发生的事情超出了预期——拆分本身引发了更多档位的需求，最终形成了一个五档位的工具矩阵，而推动它持续进化的，是信息熵这条隐藏的主线。
第一轮拆分：标准 + plan-only + quick-dev
最直观的维度是任务规模。把任务分三档：
| 档位 | 命令 | 输入特征 | 执行范围 |
|---|---|---|---|
| 方案模式 | --plan-only |
"帮我设计一个收藏功能" | Step 1-4，止于方案 |
| 轻量模式 | --quick-dev |
"修复排序不生效" | 跳过方案和文档，直入编码→评审→测试 |
| 标准模式 | 无参数 | 完整功能交付 | Step 1-9 全流程 |
区分逻辑很简单：任务越小，流程越短；任务越大，审计链越长。
┌─────────────────────────────┐
│ 按规模选择档位 │
└──────────┬──────────────────┘
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────┐
│ plan-only│ │ quick-dev│ │ 标准模式 │
│ 4 步 │ │ 5 步 │ │ 9 步 │
│ 只看方案 │ │ 快速交付 │ │ 完整闭环 │
└─────────┘ └──────────┘ └──────────┘
但这只解决了"单个任务的规模匹配"问题。第二个反馈——"能不能并行跑多个任务"——需要另一条演化主线。
第二轮衍生：batch — 拆分替代并行
严格来说，fully-coding 不允许并行——它设计为单实例串行执行，禁止 spawn 多 Agent。这不是技术限制，是设计约束：并行意味着上下文污染和状态竞争，在 SDD（规范驱动开发）流程里会导致文档冲突和错误码重复。
所以"并行"的需求被重新定义为"串行但拆分"——这就是 batch 的起源。
多功能需求
→ 需求拆分（≥2 个子任务，强制）
→ 共享 git 分支
→ 子任务 1 Step 3-9
→ 子任务 2 Step 3-9
→ ...
→ 批次汇总
batch 的核心设计决策有三个：
必须拆成 ≥2 个子任务。 如果拆出来只有 1 个，说明拆得不够细，或者根本不该用 batch。这条规则堵住了"偷懒降级为单任务"的口子。
子任务按四个维度交叉拆分。 功能边界、端（Admin/Member）、分层（后端→前端→联调）、数据范围（DDL→接口→迁移）。只用单一维度拆，要么粒度太粗，要么依赖关系理不清。
每个子任务独立可交付。 完成即有业务价值，不依赖后续任务才能运行。这条规则保证拆分是有意义的解耦，而不是机械的切分。
batch 的出现，让工具矩阵从"档位选规模"扩展为"档位选规模 + batch 拆复杂度"。
第三轮跃迁：loop — 从"工具"到"自动驾驶"
计划模式解决了"先看方案"，轻量模式解决了"快修小 Bug"，batch 解决了"多任务串行"。但使用中又暴露了一个新场景：
需求文档里列了 10 个功能，每完成一个就要人工启动下一个。有没有办法让它自动读完需求清单，逐个实现？
于是有了 fully-coding-loop：
读取需求文档 → 分析未实现的 P0/P1 功能
→ 逐个调用 fully-coding-batch 开发
→ 完成后标记需求文档
→ 循环判断：还有未实现的功能？→ 继续
loop 的本质不是新能力，而是编排器的再升级。它把"人驱动工具"变成了"工具驱动工具"——人只需要写好需求文档，loop 负责读、判断优先级、调用 batch、更新状态、循环。
这里出现了一个微妙的变化。loop 的设计里有一段话：
读取
{{config.knowledge_dir}}/需求文档中未实现的最紧急 P0/P1 功能
"未实现"是关键词。这意味着 loop 不仅需要开发能力，还需要判断"什么还没做"的能力。这已经超出了传统"代码生成工具"的范畴——它需要理解需求文档的语义、知道哪些功能已经完成、哪些还在规划中。
这正是下一轮演化的伏笔。
第四轮衍生：check-code 和 check-feat — 质量觉醒
loop 时代，一个现象越来越明显：AI 写的代码越多，问题越多。
不是 AI 变差了，而是代码基数的增长导致信息熵自然上升——新增代码和已有代码之间的耦合、命名不一致、规范偏离、Mock 残留，这些不是单个开发任务能发现的，因为它们分布在多个文件、多个服务、多个提交之间。
需要独立的、不参与开发的、只做"检查"的工具，作为事后审查环节。
实现上，我们拆成了两个方向、 skill ：
| 工具 | 职责 | 频率 |
|---|---|---|
check-code |
扫描 Java 服务的 DDD 合规性、编码规范、Mock/空壳、错误码/i18n、TODO | 定时或提交前 |
check-feat |
对照知识文档、需求文档验证功能链路、数据落地、文档一致性、前后端联动 | 阶段性检查 |
拆分的原因很直白：代码质量检查和功能进度检查是两个完全不同的视角。前者看"代码写得好不好"，后者看"功能做完了没有"。合在一起导致报告臃肿——10 个维度的报告没人从头读到尾，而且两者的检查频率也不同。
check-code 的输出是按 P0/P1/P2 排列的问题清单。一个典型的检查结果：
P0: @Transactional 缺 rollbackFor 10处
P0: 枚举值 重复
P1: Controller 返回 DataResponse<Map> 10处
P1: Gateway Fallback 空壳 16个方法
这不是"AI 帮你发现"——AI 本来就应该遵守这些规范。问题的根源是：在开发档位（标准/quick-dev/batch）里，规范是"应该遵守"的；在检查档位（check-code/check-feat）里，规范是"必须通过"的。 从"应该"到"必须"，是从工具到门禁的质变。
信息熵与工具本质的迁移
回顾整个演化路径：
每一步都是由实际痛点驱动的，但背后有一条主线：信息熵递增迫使工具承担质量保证职责。
单档位时代，关注的是"能不能写出来"。多档位时代，关注的是"写出来的对不对"。检查工具时代，关注的是"全部代码的整体健康度"。
这是一个从"提效工具"到"质量基础设施"的转变。转变的标志不是功能变多了，而是工具本身的定位变了：
| 阶段 | 核心命题 | 工具形态 |
|---|---|---|
| 单档位 | 能不能让 AI 按流程写代码 | 开发者助手 |
| 多档位 | 不同规模的任务怎么选流程 | 开发平台 |
| batch | 大任务怎么拆分不混乱 | 编排引擎 |
| loop | 能不能无人值守持续交付 | 自动驾驶 |
| check | 代码基数的健康度怎么维持 | 质量基础设施 |
最后一行是关键的跃迁。前四个阶段都在解决"怎么写"的问题，第五个阶段解决的是"写完之后怎么办"的问题。
这个问题在被提出来之前，很容易被忽略。因为初期的代码量小，一次 Code Review 能覆盖全部变更。但当 AI 辅助开发成为日常，每周产生的代码量可能是以前的 3-5 倍——Code Review 的人力带宽是固定的，质量债会持续累积。
所以 check-code 和 check-feat 不是锦上添花，而是规模化使用 AI 编程的必然产物。它们回答了"谁来 Review AI 写的代码"这个问题——答案不是人，而是另一组 AI 工具。
当前矩阵
全部档位汇总：
| 工具 | 职责 | 适用场景 |
|---|---|---|
fully-coding 标准模式 |
完整 9 步闭环 | 企业功能、复杂后端 |
fully-coding --plan-only |
方案模式 4 步 | 先审方案再决定 |
fully-coding --quick-dev |
轻量模式 5 步 | 小 Bug、明确改动 |
fully-coding-batch |
多任务拆分串行 | ≥2 个功能、强依赖 |
fully-coding-loop |
循环自动驾驶 | 需求清单持续交付 |
check-code |
代码质量检查 | 定时或提交前审计 |
check-feat |
功能实现进度检查 | 阶段性功能验收 |
七个档位，三条职责线。写代码的、管交付的、查质量的——三位一体。
持续演化的方向
矩阵还会扩展。当前能看到的方向：
定时质量巡检。 check-code 和 check-feat 目前是手动触发。如果改为定时自动执行（如每天凌晨全量扫描），就能形成持续的质量趋势图。团队可以看到规范违规数在上升还是下降，而不只是"当前有多少个问题"。
质量趋势与开发效能关联。 如果 check-code 的 P0/P1/P2 趋势和交付速度、线上缺陷率做交叉分析，就能回答"规范遵守程度和交付质量之间的关系"——这个数据对于说服团队接受规范约束比任何文档都有用。
loop 的边界扩展。 目前 loop 只读需求文档。如果能读 check-feat 的输出，就能形成闭环：检查发现功能断裂 → 自动创建修复任务 → 排入 loop → 开发 → 再检查验证。
这些方向都在解决同一个问题：当 AI 成为团队的主要生产力，谁来保证它的输出质量？
总结
fully-coding的演化不是功能堆砌，而是任务复杂性分级的必然结果。不同规模的任务需要不同粒度的流程，单一档位无法匹配。- batch 的起点不是"并行需求"，而是 "拆分替代并行"。串行 + 共享分支 + 依赖分析，比多 Agent 并行更可控。
- loop 的本质是编排器的再升级——从"人驱动工具"到"工具驱动工具"。
check-code和check-feat的出现标志着工具本质的迁移：从"纯粹的提效"到"提效 + 质量保证"。这才是 AI 编程规模化之后的真正挑战。- 信息熵是不可逆的。代码越多，质量越需要系统性保障。未来的方向是让开发、交付、检查形成闭环——不是人在中间协调，而是工具矩阵自驱动。
浙公网安备 33010602011771号