写 prompt 别再凭感觉！这份 26 万星 Skill 教我把 AI 调教当成 TDD 来做

你的 prompt 写完就发？是不是太草率了。

我最近在 obra/superpowers 这个 26 万星的仓库里翻到一个 skill 名字叫 writing-skills，打开 SKILL.md 看完第一句话就被敲醒——

Writing skills IS Test-Driven Development applied to process documentation.

翻译成人话就是：写一段给 AI 看的指令，跟写代码一样要先写测试、看它跑挂、再写实现、最后 refactor。这不是讲怎么写一段巧妙的 prompt，是讲怎么把「让 AI 干好一件事」的流程当成工程来治理。

为什么这条 Skill 戳中我

大多数人的 prompt 困境长这样：AI 第一次跑出来的结果不能完全用，调几句提示词蒙出来一个能用的版本，存进文件，下次再用类似的还得重调一遍。所谓「玄学调 prompt」，本质上就是没把过程当工程。

writing-skills 这套方法的红绿灯我直接抄给你：

• 写测试（RED）：先让 AI 在没有 skill 的情况下处理一个真实压力场景，记下来它到底哪一句话出了偏差、用了什么借口、漏掉了什么边界。
• 写实现（GREEN）：针对那几条具体偏差，写出 SKILL.md。一次只覆盖那个失败模式，不要贪多。
• Refactor：再跑同样场景，看 AI 现在会不会换一种新的借口绕过去。出现新借口就堵上，反复循环。

它自带一个例子：曾有一个 skill 的 description 写成「code review between tasks」，结果 AI 真的只做 一次 code review 就交差，哪怕 SKILL.md 流程图里画着两阶段评审（spec compliance + code quality）。把 description 改成「Use when executing implementation plans with independent tasks」以后，AI 才老老实实读完整段流程图。

这套思路直接套到日常 prompt 上

不是只有写 skill 才用得上。三个最实用的迁移：

1. 保留失败样本。下次 AI 输出让你不满意，别只删掉，把「prompt + AI 输出 + 你想要的输出」三条一起存进笔记库。这是你的 RED 资产。
2. description 决定 trigger，body 决定执行。一条 Skill 的 YAML description 只写「什么时候用」，不要写「它会做什么」。写明白「做什么」，AI 会偷懒跳过正文。
3. 附属文件按需拆分。原则/概念/小代码放 SKILL.md 一段就够；100+ 行的 API 文档、可复用脚本、模板单独放文件，避免每条 skill 都把 AI 上下文塞爆。

写在最后

这个 Skill 没有花哨的 prompt 模板，没有「七大黄金法则」，但它把 Anthropic 官方那套 anthropic-best-practices.md + 心理学 persuasion-principles.md + testing-skills-with-subagents.md 全部打包在一起，用 TDD 的节奏逼你迭代。它不教你「一招鲜」，它教你把调 prompt 当成长期工程。

仓库里还有 13 个同体系 Skill（brainstorming、systematic-debugging、test-driven-development……），都是同一套工程化思维。268k 星的命名 obra/superpowers 不是白叫的——用上以后，AI 就像真的多了一组超能力。

📦 GitHub：https://github.com/obra/superpowers/tree/main/skills/writing-skills

GitHub: https://github.com/obra/superpowers/tree/main/skills/writing-skills