Skip to content
台灯与工作台

实现新功能

实现新功能有一套固定的推进方式:先理解需求、大改动先出方案、分批实施、批间验证、收尾独立审查。流程固定且每次开发都要走,值得打包成一个 skill——构建一次,以后任何功能需求一句话触发。

把流程描述给 Peri,它会生成 skill 文件:

帮我构建一个实现新功能的 skill,命名 implement-feature,
保存到 ~/.claude/skills/implement-feature/。
流程要求:
1. 先复述需求要点;改动范围大(预计超过 3 个文件)时先出方案:
改动文件清单、每个文件的改动内容、改动顺序、验证方式
2. 分批实施:每批 2-3 个文件,批与批之间跑构建和测试,报错当场修复
3. 完成后派 verification 子代理独立验证:跑构建、测试、lint,输出 PASS / FAIL / PARTIAL 结论
4. 每完成一个阶段提示我 git commit 快照

生成的 SKILL.md 内容类似这样:

---
name: implement-feature
description: 实现新功能时使用。用户描述功能需求、要求加参数、加接口或加模块时触发。
---
# 实现新功能
1. **理解需求**:先复述需求要点,确认理解正确
2. **出方案**:改动超过 3 个文件时,先列出改动文件清单、每个文件的改动内容、
改动顺序、验证方式,等用户确认后再动手
3. **分批实施**:每批 2-3 个文件,批与批之间跑构建和测试,报错当场修复;
每完成一个阶段提醒用户 git commit 快照
4. **独立验证**:完成后派 verification 子代理跑构建、测试、lint,
输出 PASS / FAIL / PARTIAL 结论及证据
  • 先出方案:改动大时不确认就动手,方向错了返工成本高;方案阶段发现的问题比实施阶段便宜得多
  • 分批 + 批间验证:问题积压到最后一次性构建,出错时无法定位是哪一批引入的
  • 独立验证:自己改完自己说”好了”不可信。verification 子代理没有实现过程的上下文,能发现实现者视角的盲区
  • git 快照:每阶段一个 commit,出问题随时退回

skill 构建完成后,提功能需求只需要一句话:

用 implement-feature 给 CLI 加一个 --dry-run 参数:只打印将要执行的命令,不真正执行

Peri 加载 skill 后按流程走:理解需求 →(大改动先出方案等你确认)→ 分批实施 → 独立验证。skill 的存放位置、自动加载机制和修改方式,见探索陌生代码库的说明。

上面构建的 implement-feature 是主代理单线执行。功能更大、跨模块多时,可以用 auto-devflow——它把整个开发过程编排成流水线:探索 → 方案 → 编码 → 审查 → 验证,每个阶段由独立子代理接力完成、结果写入手稿文件,主代理只做控制器。子代理各管一段,主会话的上下文始终保持干净,适合大功能。

获取方式:

npx skills add https://github.com/konghayao/peri --skill auto-devflow

安装后,描述任务时提及它即可触发:

/auto-devflow 实现一个插件系统,支持从远程仓库安装插件

auto-devflow 会自己判断任务复杂度:小任务走精简流程;复杂任务(涉及公共 API、数据迁移、并发等)自动加一道方案审查关卡,方案确认后才开始编码。

两个怎么选:功能中等、边界清晰用 implement-feature,单代理流程轻、确认点少;功能大、跨模块多、希望每阶段独立审查用 auto-devflow。

需求模糊、还没想清楚怎么设计时,可以走 mattpocock/skills 的讨论-规划流水线,每一步的产出是下一步的输入:

/grill-me 挑战方案 → /to-prd 整理成 PRD → /to-issues 拆成独立 issue → /implement 逐个实现

获取方式(ask-matt 是入口 skill,可以问它该用哪个):

Terminal window
npx skills add https://github.com/mattpocock/skills --skill ask-matt

用法示例:

/grill-me 用户邀请功能,支持邮箱邀请和链接邀请两种方式,来挑战一下我的方案

讨论清楚后再走 /to-prd/to-issues/implement。完整的流水线说明见 mattpocock/skills