CC端到端开发skill：标准模式、plan-only、quick-dev、batch 多档位设置

前言：这篇文章面向第一次使用 fully-coding 的开发者。它不展开内部规则细节，而是回答一个实际问题：面对不同规模的需求，应该选择标准模式、--plan-only、--quick-dev，还是 fully-coding-batch？

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

背景

fully-coding 的能力很多：9 步标准流程、方案模式、轻量开发模式、断点续跑、阻塞处理、文档同步、batch 串行开发。

这些能力背后有一条主线：用 SDD（Specification-Driven Development，规范驱动开发）把规范作为第一性产物。不同模式的区别，不是要不要规范，而是规范做到什么粒度、覆盖到哪一步。

能力多了以后，第一个问题就是：什么时候用哪个？

如果每个小 bug 都跑完整 9 步，流程会显得重。如果复杂企业功能只用轻量模式，又会丢失方案、评审、测试和知识库闭环。

所以使用 fully-coding 的关键，不是记住所有参数，而是先判断任务类型。

先判断任务规模

可以用下面的规则做第一层判断：

1 个 feature / 1 个 Bug          → fully-coding
2-3 个弱相关 feature             → fully-coding（分多次调用）
2 个 feature 但强相关             → fully-coding-batch
≥3 个 feature 或存在依赖关系      → fully-coding-batch

如果需求里出现“同时实现用户管理、订单系统、支付集成”这种多个模块，就不要硬塞进单次 fully-coding。更合适的是 fully-coding-batch。

如果只是“修复资讯列表排序不生效”，那就不需要完整 batch。

四种常用入口

入口	命令示例	适合场景
标准模式	/fully-coding 帮我实现管理员角色批量导入功能	企业功能、复杂后端、需要完整审计和文档闭环
方案模式	/fully-coding 帮我设计收藏资讯功能 --plan-only	先生成方案，不修改代码
轻量开发模式	/fully-coding 修复登录排序问题 --quick-dev	小 bug、明确小改动，仍需要评审和测试
批量模式	/fully-coding-batch 实现用户管理、订单系统、支付集成三个模块	多功能、强依赖、需要串行拆分

标准模式：适合完整交付

标准模式执行完整 Step 1-9：

需求检索 → 需求生成 → 开发范围 → 开发方案 → 开发实现 → 代码评审 → 测试用例 → 文档更新 → 自主进化

适合这些场景：

• 新增一个完整业务功能。
• 涉及接口、数据库、错误码、权限、文档同步。
• 需要留下完整审计记录。
• 任务可能影响多个服务或模块。
• 你希望 Claude 不只是写代码，还要评审、测试和更新知识库。
• 任务周期较长，需要每一步都可交接、可恢复。

标准模式的优点是稳，缺点是重。

它适合“交付功能”，不适合“临时改一行”。

plan-only：适合先审方案

--plan-only 只执行 Step 1-4。

需求检索 → 需求生成 → 开发范围 → 开发方案

它会生成：

• {ts}-userStory.md
• {ts}-codingLog.md 中的开发范围和开发方案

这两个文件就是方案阶段的规范产物。它们让需求、范围、关键决策和风险先被固定下来，再决定是否进入编码。

但不会修改业务代码，也不会进入评审、测试和文档更新。

典型命令：

/fully-coding 帮我设计用户收藏资讯功能 --plan-only

适合这些场景：

• 需求较复杂，你想先看方案。
• 涉及数据库、幂等性、错误码，需要先评估风险。
• 想把 Claude 当架构师，而不是马上让它写代码。
• 需要和团队讨论后再决定是否实现。

完成后任务状态是：

status=planned

如果要继续实现，需要显式执行：

/fully-coding --start-step 5 --task-id {ts}

这个设计可以防止自动续跑在用户没确认时直接进入开发。

quick-dev：适合小 bug 和明确小改动

--quick-dev 是轻量开发模式。

它执行：

最小需求记录 → Step 3 开发范围 → Step 5 开发实现 → Step 6 代码评审 → Step 7 测试用例

它跳过完整 Step 2、Step 4、Step 8、Step 9，但不是完全无约束开发。

它仍然保留：

• 需求最小记录。
• 开发范围定位。
• 代码实现记录。
• DBA + Reviewer 评审。
• 测试执行与失败修复。

换句话说，--quick-dev 只是降低规范粒度，不是放弃规范。它仍然保证小任务有基本交接面，避免变成完全依赖对话记忆的一次性修改。

典型命令：

/fully-coding 修复资讯列表按发布时间倒序排序不生效的问题 --quick-dev

适合这些场景：

• 明确 bug 修复。
• 小范围代码调整。
• 不涉及新增功能文档。
• 不涉及菜单、路由、权限入口。
• 不需要完整知识库同步。

如果改动涉及错误码、接口契约、核心业务流程或数据模型，建议不要用 --quick-dev，改用标准模式或 --plan-only 先出方案。

batch：适合多功能串行开发

fully-coding-batch 用于处理超长需求。

它会先拆分子任务，再串行调用 fully-coding：

多功能需求
  → 需求拆分
  → 共享分支
  → 子任务 1 Step 3-9
  → 子任务 2 Step 3-9
  → ...
  → 批次汇总

典型命令：

/fully-coding-batch 实现用户管理、订单系统、支付集成三个模块

batch 的核心规则：

• 子任务严格串行，不并行启动。
• 所有子任务共享同一个 git 分支。
• 每个子任务必须传入 --batch-subtask。
• 阻塞子任务未确认前，不得跳过后续子任务。
• batch 层不重写子任务实现规则，子任务复用 fully-coding Step 3-9。

适合这些场景：

• 一个需求包含 3 个以上独立功能。
• 多个 CRUD 模块要按顺序实现。
• 多个微服务接口需要批量落地。
• 子任务之间存在依赖关系。

不适合这些场景：

• 只改 1-2 个文件。
• 需求高度耦合，无法拆分。
• 时间极紧，不允许走完整流程。

参数速查

参数	作用	常见用法
--plan-only	只执行 Step 1-4，生成方案后停止	先审方案
--quick-dev	轻量开发模式	小 bug 或明确小改动
--start-step N	从第 N 步开始执行	断点续跑或 plan-only 后继续实现
--task-id {ts}	指定任务时间戳	定位某个历史任务
--batch-subtask	标记为批次子任务	batch 自动传入
--git-branch <name>	复用指定分支	batch 模式共享分支
--status	查看当前任务进度	日常查询
--list	列出未完成任务	多任务排查
--auto-resume	自动续跑可接管任务	中断恢复
--new-task	强制启动新任务	忽略恢复扫描

如何看产出

标准模式完成后，.dev-log/ 下通常会有：

文件	内容
{ts}-userStory.md	需求检索、需求生成、验收标准、假设和歧义
{ts}-codingLog.md	开发范围、方案、代码变更、评审、测试、文档更新、自检
{ts}-suggestion.md	Step 9 生成的改进建议
{ts}-blockLog.md	仅阻塞时生成，记录等待用户确认的事件

batch 模式会额外生成：

BATCH-{batch-ts}-progress.md

用于统一监控所有子任务进度。

常见选择误区

误区 1：所有任务都用标准模式

标准模式最完整，但不是最轻。明确小 bug 可以优先用 --quick-dev。

误区 2：所有任务都用 quick-dev

--quick-dev 不执行完整方案和知识库同步。如果任务涉及接口、数据库、错误码、权限或菜单入口，建议使用标准模式。

误区 3：plan-only 后让 auto-resume 自动开发

不会自动开发。planned 状态必须由用户显式执行 --start-step 5 --task-id {ts} 才能继续。

误区 4：多功能需求强行用单任务

如果需求包含多个强相关 feature，用 batch 更安全。它能管理共享分支、子任务顺序和公共资源变更。

总结

选择 fully-coding 模式时，可以记住这张表：

你想要什么	推荐选择
完整企业功能交付	标准模式
只想先看方案	--plan-only
修一个明确小 bug	--quick-dev
多个功能串行交付	fully-coding-batch
中断后恢复	--auto-resume
plan-only 后继续开发	--start-step 5 --task-id {ts}

fully-coding 的关键不是“每次都跑最完整流程”，而是根据任务规模选择合适的执行路径。

无论选择哪种模式，核心都不是简单让 AI 更快写代码，而是让需求、方案、实现、评审和测试以合适粒度沉淀成规范。规范化文档越清晰，自动化流程越稳定，超长周期编程也越容易安全续跑。