这个 GitHub 爆火的「编写实施计划」Skill 到底能干嘛?实测来了

1574 字
8 分钟
这个 GitHub 爆火的「编写实施计划」Skill 到底能干嘛?实测来了

为什么需要「先写计划,再写代码」?#

用过 AI 编程工具的开发者大概都经历过这种场景:你丢给它一个需求,它唰唰唰开始写代码,结果写了一堆看似合理但实际上跑不起来的东西。改了半天发现方向从一开始就偏了。

问题的核心在于:AI 没有「停下来想」的习惯。它收到需求就开始编码,而不是先梳理文件结构、任务分解、测试策略。

今天介绍的这个 Skill 就来自 GitHub 上最火的 AI Agent 技能仓库 obra/superpowers(18 万+ Star),它的名字叫 writing-plans——专门解决「先想清楚再动手」这个问题。

原始项目简介#

  • 仓库地址https://github.com/obra/superpowers
  • 当前 Star 数:181,497+(还在持续增长)
  • 描述:An agentic skills framework & software development methodology that works.
  • 许可证:MIT
  • 最近更新:2026 年 5 月(非常活跃)

obra/superpowers 是目前 GitHub 上最流行的 AI Agent 技能框架项目,提供了一套完整的开发方法论。它不只是一些零散的技巧,而是一个系统化的「Superpowers」体系,涵盖了从头脑风暴到代码评审、从 TDD 到并行智能体调度的全流程。

核心功能#

这个 Skill 的核心作用非常明确:在动手写代码之前,生成一份精确到文件路径、代码块和测试命令的实施计划。

具体来说,它要求:

1. 零上下文假设#

计划必须假设执行者(无论是人还是 AI 智能体)对代码库完全不了解。这意味着:

  • 每个任务要标明具体修改哪个文件的哪几行
  • 要提供完整的代码,不能只说「在这里添加逻辑」
  • 要给出运行测试的具体命令和预期输出

2. 小步任务拆分#

每个步骤被限定在大约 25 分钟能完成的工作量内。一个典型的 TDD 流程会被拆成 5 个独立步骤:

  1. 编写失败的测试
  2. 运行确认测试失败
  3. 写最小实现让测试通过
  4. 运行确认测试通过
  5. 提交

这听起来很琐碎,但恰恰是避免 AI「一口气写太多、出错后难以调试」的关键。

3. 禁止占位符#

这是我最喜欢的规则。计划里绝对不允许出现以下模式:

  • TBDTODO稍后实现
  • 添加适当的错误处理(没写具体怎么处理)
  • 为以上内容编写测试(没写测试代码)
  • 与任务 N 类似(执行者可能不按顺序读任务)

每条规则都来自血泪教训——AI 最怕的就是「模糊指令」,它会把模糊解读成「随便做点什么」。

4. 文件结构先行#

在定义任务之前,必须先规划好:

  • 哪些文件会被创建
  • 哪些文件会被修改
  • 每个文件的职责边界

按职责拆分,不按技术层级拆分。一起变化的文件就应该放在一起。

5. 自我审查机制#

写完计划后,必须执行三步自查:

  1. 规范覆盖率:规范的每个需求都能在计划中找到对应任务吗?
  2. 占位符扫描:有没有偷偷写了模糊描述?
  3. 类型一致性:前后任务中用到的函数名、类型名一致吗?

实际使用场景#

假设你要给一个博客系统添加「评论功能」,使用这个 Skill 后,AI 会产出一份这样的计划:

# 评论功能实施计划
目标:为文章添加用户评论功能,支持嵌套回复
架构:新增 Comment 模型和 API 端点,前端使用 React 组件展示评论树
技术栈:Astro, TypeScript, Prisma, React
---
### 任务 1:数据库模型
文件:
- 创建:prisma/schema.prisma(修改)
- 创建:src/db/comment.ts
- [ ] 步骤 1:在 schema.prisma 中添加 Comment 模型
(完整的 Prisma 模型代码...)
- [ ] 步骤 2:运行 prisma migrate
运行:npx prisma migrate dev
预期:Migration created successfully
...

这份计划可以直接交给另一个 AI 智能体(或者你自己)去执行,每个步骤都有明确的输入和输出。

与其他 Skill 的协作#

writing-plans 不是孤立使用的。在 superpowers 体系中,它通常和以下 Skill 配合:

Skill作用关系
brainstorming头脑风暴,确定方案方向writing-plans 的前置步骤
subagent-driven-development子智能体驱动开发writing-plans 的推荐执行方式
executing-plans在当前会话中执行计划writing-plans 的备选执行方式
using-git-worktreesGit worktree 隔离提供干净的执行环境

典型流程是:brainstorming → writing-plans → subagent-driven-development(执行)。

适用场景#

适合使用

  • 多步骤功能开发(5 个以上任务)
  • 涉及多个文件修改的需求
  • 需要精确控制执行顺序的任务
  • 团队协作中的需求交接文档
  • 让 AI 执行复杂编码任务前的规划

不适合使用

  • 单文件的小修改(改个变量名、修个 bug)
  • 纯配置调整
  • 你已经很清楚该怎么做的简单任务

个人评价#

这个 Skill 最大的价值在于约束了 AI 的冲动。AI 编程工具最容易犯的错误就是「看到需求就写代码」,而 writing-plans 强制它先停下来思考:文件结构是什么?任务怎么拆分?测试怎么写?

我给自己的推荐指数是 ⭐⭐⭐⭐⭐。尤其是当你用 AI 做严肃的项目开发时,这个 Skill 能大幅降低「方向跑偏」的概率。而且它产出的计划文档本身就是一个很好的项目记录,回头查看「当时为什么这样设计」非常方便。

唯一的缺点可能是对于小项目来说有点「杀鸡用牛刀」,但对于任何超过 2 天的开发任务,这个 Skill 绝对值得使用。

获取与使用#

这个 Skill 已经搬运到我们的中文仓库 awesome-ai-agent-skills-zh,可以直接使用。

原始 SKILL.md 的用法很简单:当你有一个复杂需求时,告诉 AI「使用 writing-plans 技能先写一份实施计划」,它就会按照上述规范生成一份结构化的计划文档。


本文介绍的 Skill 搬运自 obra/superpowers 项目,原始文件位于 skills/writing-plans/SKILL.md。更多 Skill 搬运请关注 awesome-ai-agent-skills-zh

文章分享

如果这篇文章对你有帮助,欢迎分享给更多人!

这个 GitHub 爆火的「编写实施计划」Skill 到底能干嘛?实测来了
https://boke.hackerdream.xyz/posts/writing-plans-introduction/
作者
晴天
发布于
2025-04-12
许可协议
CC BY-NC-SA 4.0
Profile Image of the Author
晴天
Hello, I'm 晴天.
公告
欢迎来到我的博客!这是一则示例公告。
音乐
封面

音乐

暂未播放

0:00 0:00
暂无歌词
分类
标签
站点统计
文章
125
分类
17
标签
287
总字数
257,955
运行时长
0
最后活动
0 天前

目录