先给结论：墨刀AI Skill不是一句写得更长的提示词，而是一套可以反复调用、测试和更新的任务执行说明。它应该告诉AI任务目标、输入资料、处理步骤、输出格式、检查规则和停止条件，让团队把稳定的方法沉淀下来，同时把业务决策留给人。
一个合格的Skill至少要回答六个问题：处理什么任务、读取哪些资料、按什么顺序做、输出到哪里、怎样判断合格、遇到不确定时何时停下。本文用“把用户访谈整理成结构化PRD初稿”的任务，讲清墨刀AI Skill怎么创建、测试和团队复用。
墨刀AI Skill是什么，不是什么
Skill可以理解为“可复用的工作方法包”。它把一次任务中稳定的流程、模板、检查项和必要资源整理好，之后在不同项目中调用。比如产品团队可以把PRD章节、用户故事格式、验收条件和风险检查整理为一个Skill；设计团队可以把页面状态、组件规范和交付检查整理为另一个Skill。
Skill不是业务目标，也不是产品经理的判断替代品。它不应该决定需求优先级、品牌风格或是否上线；它更适合处理格式稳定、步骤可描述、质量可以检查的工作。遇到目标不清、资料冲突或高风险动作时，Skill应该让AI停下来询问，而不是编一个确定答案。
客户端基础安装、Skill入口和本地/云端模式可参考墨刀AI客户端使用指南。如果任务需要进入团队评审，可继续参考客户端、工作台与企业空间的协作方法。本文重点放在Skill本身的设计和治理。
一个可复用Skill的六个组成部分
| 组成部分 | 要写清什么 | 访谈转PRD示例 |
|---|---|---|
| 任务目标 | 完成什么，不做什么 | 把已脱敏访谈整理为PRD初稿，不改变已确认业务规则 |
| 输入范围 | 读取哪些目录、文件和字段 | 只读 01_sources 中标记为当前有效的访谈和客服记录 |
| 处理步骤 | 先后顺序和分支条件 | 提取事实→归类问题→标记冲突→生成用户故事→输出验收条件 |
| 输出契约 | 格式、字段、文件名和保存位置 | 生成Markdown PRD，固定八个章节，写入 02_working |
| 质量检查 | 如何判断结果可用 | 每条关键结论有来源；未确认内容单独列出；异常流程不为空 |
| 停止条件 | 什么时候必须让人决定 | 资料相互矛盾、缺少关键数据或涉及敏感内容时暂停并提问 |
这六部分比“请写得专业一点”更有用，因为它们把工作方法变成了可检查的约束。Skill越具体，越要把适用范围写窄；一个只负责PRD证据整理的Skill，通常比“全自动产品经理Skill”更容易稳定复用。
创建Skill前先选一个高频、低风险任务
不是所有工作都值得做成Skill。可以用三个标准筛选：
- 重复频率高：团队每周或每个项目都会做。
- 方法相对稳定：步骤和输出格式不会因人而完全不同。
- 结果容易复核：有模板、字段、清单或样例可以检查。
适合的起点包括访谈整理、竞品信息归档、PRD格式化、页面状态检查、研发交付清单和周报汇总。不适合的起点包括“帮我决定产品方向”“替我做最终视觉判断”“自动发布生产配置”，因为这些任务涉及责任、判断或高风险动作。
用任务契约写Skill说明
Skill说明应像一份小型工作协议，而不是营销文案。可以按下面的顺序书写：
- 角色和目标：说明AI在当前任务中扮演什么角色，目标产物是什么。
- 输入和优先级：列出事实来源、参考资料和冲突时的优先级。
- 执行步骤：按顺序写动作，每一步注明预期结果。
- 输出格式：写明标题、字段、表格、文件名、保存位置和语言。
- 检查和停止：列出必检项，以及需要人确认的条件。
- 示例：提供一组脱敏输入和合格输出，帮助测试边界。
例如，访谈转PRD Skill不能只写“总结用户需求并生成PRD”，而应要求：“先列出每条事实的来源文件和段落；将原话、解释和假设分开；如果两个来源冲突，保留冲突并提出问题；没有来源的数字不得补写；输出完后列出未确认项。”
用三组样例测试Skill，而不是只跑一次成功案例
| 测试样例 | 要观察什么 | 通过标准 |
|---|---|---|
| 正常输入 | 资料齐全、格式清楚的真实脱敏项目 | 输出结构完整，来源和字段符合预期 |
| 缺失输入 | 缺少关键访谈、字段或版本说明 | AI指出缺口并停止猜测，不伪造结论 |
| 冲突输入 | 两个文件对同一规则说法不同 | 保留冲突，列出需要负责人确认的问题 |
| 边界输入 | 包含不应处理的敏感信息或越权要求 | 按规则拒绝、缩小范围或要求人工确认 |
测试时不要只检查语言是否顺畅，要检查结果是否能进入下一步工作：产品经理能否确认需求，设计师能否找到页面和状态，研发能否知道实现边界。一个“写得漂亮但无法交接”的Skill，不算通过。
给Skill做版本，而不是不断覆盖
团队方法会变，Skill也需要版本。建议每次更新都记录：
- 适用任务和适用团队；
- 新增、删除和改写了哪些规则；
- 使用了哪些样例进行验证；
- 哪些旧项目仍然依赖旧版本；
- 出现问题时如何退回上一版。
文件名可以采用 prd-interview-to-draft-v1.2 这样的方式，说明页中再写发布日期和维护人。不要为了“看起来更智能”频繁升级版本；只有输入、流程、输出或检查规则发生变化时才更新。版本号的意义是让团队知道当前到底使用哪套方法。
从个人Skill变成团队能力
一个人能用，不代表团队能复用。推广前要补齐三个层次：
| 层次 | 需要准备什么 | 负责人 |
|---|---|---|
| 使用说明 | 适用任务、输入要求、输出位置和示例 | Skill维护人 |
| 质量门槛 | 必检项、失败案例和需要人工确认的条件 | 业务负责人 |
| 团队入口 | Skill市场、团队Skill包或项目模板中的调用方式 | 空间管理员/流程负责人 |
客户端支持浏览、搜索和安装已有Skill，也支持团队自定义Skill包。安装后不要立即在所有项目启用，先选一个低风险项目试用，收集“哪些输入最容易出错、哪些输出字段经常被改、哪些步骤应该停下来询问”。这些反馈比一次性的满意度评价更能指导下一版。
Skill的权限和资料边界
Skill本身不应该扩大项目权限。使用前要分别确认：
- Skill需要读取哪些文件夹，是否可以缩小到当前项目；
- 是否会创建、覆盖或删除文件，输出目录是否固定；
- 是否会调用外部工具、网络服务或MCP；
- 是否可能处理客户、员工、财务或密钥等敏感内容；
- 失败或误写后能否恢复。
把权限写在Skill说明中，使用者才能在调用前做判断。Skill可以建议下一步，但涉及发送、发布、删除、生产修改或权限变更的动作，应设置人工确认点。团队复用的前提不是“所有人都能调用”，而是“调用后知道结果由谁负责”。
Skill效果变差时怎么排查
- 先看输入：本次文件是否与测试样例结构一致，是否混入旧版本。
- 再看规则：是否出现互相冲突的指令，输出格式是否过于含糊。
- 检查资源：模板、示例和引用文件是否移动、缺失或权限变化。
- 对比版本：问题从哪次更新开始，能否回到上一版复现。
- 缩小任务：把一个大Skill拆成资料整理、结构化输出和复核三个小Skill。
如果同一Skill经常需要人工大幅改写，通常不是“模型不够聪明”，而是任务边界、输入契约或检查标准没有写清楚。先修规则，再决定是否换模型或增加提示词。
产品、设计、研发各适合沉淀什么Skill
| 角色 | 适合沉淀的Skill | 不应交给Skill决定的内容 |
|---|---|---|
| 产品经理 | 访谈归类、需求字段补齐、验收条件初稿、竞品信息整理 | 产品方向、优先级、商业取舍和最终承诺 |
| 设计师 | 页面状态清单、组件检查、交互说明格式、交付标注 | 审美判断、品牌表达和关键体验取舍 |
| 研发工程师 | 变更说明、测试场景、代码检查清单、文档格式化 | 架构、上线风险、生产修改和合并决定 |
Skill的边界越接近“重复动作”，越容易建立稳定预期；越接近“专业判断”，越应该把它写成建议和检查项，而不是自动决定。
发布一个团队Skill前的十项检查
- 名称能直接说明任务，不使用“万能”“全自动”等夸张词。
- 输入目录、文件类型和事实优先级已写清。
- 步骤有顺序，必要时有分支和停止条件。
- 输出字段、格式、文件名和位置明确。
- 至少用正常、缺失、冲突和边界样例测试。
- 每条关键结论可追溯到输入资料。
- 敏感资料和外部工具的权限有明确限制。
- 有维护人、版本号和变更记录。
- 失败时不会覆盖源文件，能够回滚。
- 团队知道结果进入工作台或企业空间后的负责人。
常见问题
Skill和提示词有什么区别？
提示词通常服务于一次对话，Skill则把稳定的目标、步骤、输入输出和检查规则封装起来，方便重复调用和版本管理。好的Skill仍然可以包含提示词，但不止是一段提示词。
Skill越详细越好吗？
不一定。无关规则太多会让任务边界变模糊。建议围绕一个明确产物写最小规则，使用样例验证后再逐步增加例外。
团队Skill应该公开给所有成员吗？
取决于资料、工具和结果的权限。通用格式化Skill可以广泛复用；涉及特定客户、内部流程或敏感目录的Skill，应限制安装范围，并在说明中写清负责人。
什么时候应该删除或停用Skill？
当输入结构、业务规则或产品流程变化，旧Skill持续产出错误时，应停用或标记过期，先回到人工流程，再完成新版本测试。不要为了保持数量而保留失效能力。
Skill的真正价值，是让团队少重复解释一次方法，同时多保留一层可检查的规则。先从一个高频、低风险、可验收的任务开始，跑过正常输入和异常输入，再把它放进团队工作流，才能把个人经验变成可靠的产研能力。
下载墨刀AI客户端，在真实项目中创建和测试你的第一个团队Skill。
