颠覆AI的用法：直接拆了Claude官方SKILL，学习AI产品怎么写PRD，AI开发怎么写代码，AI测试怎么写用例

推荐语

Claude官方SKILL拆解：揭秘AI产品开发的黄金法则，从PRD到代码再到测试用例一网打尽。

核心内容：
1. SKILL文件结构解析：从身份标识到触发机制
2. 三步走核心战术：结构化协作流程设计
3. 实战应用：如何将方法论迁移到PRD编写、代码开发和测试用例设计

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

话说上回

昨天小树聊了Claude对SKILL的介绍，说它能让你告别对AI的重复唠叨。文章发出后，很多朋友留言问：“道理懂了，但这东西到底怎么用？我能不能自己也做一个？”

今天，我不讲概念，直接带你拆解一个Claude官方自己写的SKILL。小树和大家一起来看看高手是怎么“调教”AI的。

这个SKILL名叫 `doc-coauthoring`（文档协同创作）。它不是什么酷炫功能，就是帮你更好地写文档——但它的做法，藏着让AI真正懂你的秘诀。

一、SKILL的“身份证”：短短几行，决定AI何时出手

每个SKILL文件开头，都有一小段“简历”：

---

name: doc-coauthoring

description: Guide users through a structured workflow for

co-authoring documentation. Use whenuser wants to write 

documentation, proposals, technical specs, decision docs, 

orsimilar structured content...

---

你把它想象成给AI看的一个便签条。`name`就是技能的名字，以后你想用这个技能，就得喊这个名字。而`description`是最关键的部分！它在告诉AI两件事：我是干什么的（引导用户完成结构化的文档协同创作流程），以及你什么时候该把我请出来（当用户提到想写文档、提案、技术规格这些词的时候）。

即写SKILL时，一定要在描述里说清你的技能解决什么问题，以及用什么关键词触发。

二、核心战术：不直接给答案，而是铺设“流水线”

这个技能最聪明的地方在于，它不是一股脑地帮你写文档，而是设计了一套三步走的流水线。

我们看看它是怎么指挥AI的：

Initial offer: Offer the user a structured workflow... Explain the three stages...

1. Context Gathering: User provides all relevant context...

2. Refinement & Structure: Iteratively build each section...

3. Reader Testing: Test the doc with a fresh Claude...

当用户说“我想写个产品方案”时，AI不会马上动笔，而是会像项目经理一样站出来说：“咱们按一个高效流程来怎么样？分三步：① 你先把你所有的想法、背景都倒给我；② 咱们一节一节地精雕细琢；③ 最后找个‘小白’AI读一遍，看看有没有看不懂的地方。”

这才是高级的AI用法：不是把它当打字员，而是把它当有方法的协作者。你把一个复杂任务拆解成固定的步骤，AI就成了一个不知疲倦、严格按流程办事的完美助手。

三、细节见真章：如何把“笨”AI变“机灵”

这套流程里有很多细节点，正是这些点让AI显得特别“懂行”。

1. 怎么“收集背景”？不是傻等，而是主动问

Start by asking the user for meta-context about the document:

 1. What type of document is this?

 2. Who‘s the primary audience?

 3. What’s the desired impact...

 4. Is there a template...

 5. Any other constraints...

AI会主动抛出5个灵魂拷问：这是什么类型的文档？写给谁看？想达到什么效果？有模板吗？还有什么特殊要求？这个很重要，在接受任务时，一定会先把这些关键信息问清楚，而不是拿到标题就开写。

2. 怎么“逐段打磨”？用标准化流水线

For each section:

 1. Clarifying questions will be asked...

 2. 5-20 options will be brainstormed...

 3. User will indicate what to keep/remove/combine...

 4. The section will be drafted...

 5. It will be refined through surgical edits...

对于文档的每一部分，AI都严格走一个“流水线”：先问你这部分还有什么要交代的？然后帮你列出10来条可能写进去的点子。这个过程很像是一个秘书，让你拍板，说留哪几条，删哪几条。它根据你的选择把这一节写出来，最后你再提意见，它做精准修改。

这提供了一个万能的内容创作框架。无论是写周报、做PPT还是策划活动，都可以让AI按“提问→发散→收敛→创作→修改”的步骤来协同。这比每次零散地下指令，效率高太多了。

3. 怎么“模拟读者”？让AI扮演“门外汉”

这是最精彩的一步，也是大多数人不会想到的。

Reader Testing: Test the doc with a fresh Claude (no context) to catch blind spots...

“Open a fresh Claude conversation... Ask Reader Claude the generated questions...”

文档写完后，AI会建议你：新开一个干净的AI聊天窗口，把刚写的文档丢进去，然后假装成读者去提问。因为新窗口里的AI对你之前的讨论一无所知，它如果能看懂，说明你的文档真的写明白了；它要是看懵了，你就知道哪里还需要补充解释。

可以把这个思路用在任何需要交付给他人的工作上：让一个没有背景知识的AI先“踩坑”，提前发现问题。

四、从“官方配方”到“你的秘方”

看了Claude这个官方SKILL，不难发现，制作一个高效SKILL的关键不是炫技，而是把你最擅长、最重复的工作方法，清晰地“翻译”给AI听。

想想你手头有没有这样每次都要“从头交代”的技术文档工作？例如：

- 产品经理撰写产品需求文档（PRD）时，那套固定的框架：从项目背景、用户故事、功能清单到非功能性需求，每次结构类似，但总要重新描述。

- 技术负责人编写架构设计文档时，需要反复强调的决策记录格式、考虑的备选方案以及必须遵循的制图规范。

- 设计师产出交互设计文档时，关于设计决策说明、交互流程描述和与开发对接的标注规范，这些重复的沟通成本。

- 测试工程师设计测试用例时，针对不同功能模块的用例模板、覆盖要点和优先级定义，这些结构化却繁琐的步骤。

这些你依据团队规范或自身经验，已经形成肌肉记忆的创作流程，不正是最值得封装成个人SKILL的“技术资产”吗。

技术的意义，正在于将我们从格式、流程和重复解释的繁琐中解放，让我们能更聚焦于技术决策、创意构思与问题解决本身。

https://github.com/anthropics/skills/blob/main/skills/doc-coauthoring/SKILL.md