面向产品团队的 Spec Skills Prompt 库

我看过三个产品团队试图用 Slack、Notion 和一份勇气可嘉的 Google Doc 来管理 Spec Skills 的 prompt。没有一种撑过一个季度。prompt library 是基础设施，不是剪贴簿。下面是我自己的做法。

发布于 2026-03-10 · ✓ 已更新 2026-05-06 · 阅读约 7 分钟 · 作者：Spec Coding 编辑部 · 审校：编辑与事实核查政策

为什么 library 胜过随手写 prompt

随手写 prompt 的做法，在头两周看起来一切正常。有人写了一个还算像样的 spec 起草 prompt，在群里一贴，三个人复制走，到了周五其中两个已经把它改得面目全非。月底你手上有五个变体，没有一个是正宗的，新来的同事根本不知道该用哪一个。

library 之所以胜出，原因有三。可复用：上个迭代终于让 AC 写对的那条 prompt，就是这个迭代你还会去找的那条。一致性：两个 PM 为同一块业务起草 spec，产出的文档看起来像出自同一家公司。上手速度：新来的工程师把 library 过一遍，就能跳过一个月的校准期。这就是商业价值。剩下的都是实现细节。

值得留在 library 里的三类 prompt

我只保留三类，而且对这一点非常苛刻。

spec 起草类 prompt：输入一个粗糙的想法加一些上下文，输出一份结构化的初稿，包括 goal、non-goals、open questions、contract impact。这类是主力。多数团队会长期只用其中两三条，顶多小改。

AC 起草类 prompt：输入一段 spec，输出人类真的能审的 Given/When/Then 验收标准。它们能跨团队流转，因为 Given/When/Then 本身是领域无关的。

评审辅助类 prompt：输入一份草稿，让它扮演唱反调的角色——哪里规格不清，哪里藏着风险，哪里漏了发布细节。这类是工程师私下最喜欢的，因为它能捞回你周四下午五点本该漏掉的那个坑。

我以前也在 library 里放代码生成类 prompt，后来放弃了。代码生成类 prompt 和具体代码库、lint 配置、import 习惯绑得太紧。我见过的每一个跨仓库共享这类 prompt 的团队，最后都产出没人愿意合的代码。真要留，就留在当前 repo 本地。

每条 prompt 的元数据

library 里的每条 prompt 都有一个五字段的头部。没头部，不能合入。

• Purpose（用途）。一句话说清楚。写不出这一句话，说明这条 prompt 想干的事情太多了。
• Inputs（输入）。用户应该粘贴什么进去。ticket URL、功能描述、spec 草稿。写明白。
• Expected output shape（期望输出形态）。段落结构、bullet 形式、格式规范。如果输出是 AC，就写"Given/When/Then，每条验收路径一个三元组，不要散文"。
• Owner（负责人）。具体的人名，不是团队。共同负责就是 prompt 腐烂的开始。
• Last reviewed（最近一次审阅）。一个日期。日期超过一个季度的，prompt 就进入观察期，直到有人签字认领为止。

prompt 就是代码，按代码来存

library 就放在 repo 里。不是 Notion，不是 Confluence，也不是某条被置顶的 Slack 消息。就放在 repo 里，紧挨着它产出的 spec，通过 pull request 走评审。这一条没得商量。

prompt 要变，就走 PR。有人审。diff 就是讨论本身。你免费得到了 history、blame、rollback，还能按 branch 做实验。更重要的是，你传递了一个组织层面的信号：prompt 是一等公民，这会直接改变大家对待它的方式。

衰退是真的存在的，每季度剪枝一次

prompt 会老化。模型在不同版本之间行为会变，spec 规范也在演进。一月份能产出干净输出的 prompt，到了六月可能就因为模型变得更啰嗦，或者团队开始写更长的 ticket，而输出出现细微偏差。

每个季度，每个 owner 把自己那条 prompt 在三个近期真实输入上跑一遍，对比输出和团队实际交付的内容。有漂移，就更新或者下线。我用这个办法下线的 prompt 比新增的还多。这个比例才是对的。

80/20 原则要硬性执行

五条 prompt 承担了八成的工作量。在我跑过这套方法的团队里，Top 5 永远是这五条：新功能 spec 起草、endpoint spec 起草、从 spec 生成 AC、草稿评审辅助、发布计划起草。就这些。剩下的都是长尾。

最常见的失败模式，是在 Top 5 还没打磨稳之前就去补长尾。要忍住。五十条平庸 prompt 的 library 比五条优秀 prompt 的 library 更糟，因为那五十条每次都让人花额外时间去搜索该用哪一个。

哪些东西不该进 library

• 一次性任务的 prompt。只为某一次迁移写的、以后再也不会用的，是笔记，不是 library 条目。
• 依赖内部机密、PII 或凭证的 prompt。如果它必须粘敏感数据才能跑，那它就是一次正在酝酿的安全事故。
• 跟现有 prompt 重复的。两条 prompt 做差不多的事，要么合并，要么砍掉弱的那条。近似重复就是 library 变垃圾堆的原因。
• 那种"通用万能助手"prompt。它永远是被复制最多、最没用的那一条。看到就删。

一个具体例子：新 endpoint 的 spec 起草

有一个团队花了三个月打磨同一条 prompt：new-endpoint spec 起草。第一版是一段含糊其辞的段落。第七版是十一行。下面是它应当满足的 AC，采用的正是这条 prompt 强制输出的 Given/When/Then 格式。

Given a ticket describing a new API endpoint
  And the existing OpenAPI schema pasted as context
When the prompt is run
Then the draft spec contains: goal, non-goals, request/response shape,
     auth requirements, error cases, rollout plan, and open questions
 And no section is left blank
 And invented scope that was not in the ticket is flagged as "assumption"

最后那一行，花了整整三个月才落下来。早期版本乐此不疲地凭空发明 pagination 方案、速率限制和缓存策略，只因为这些"听起来"像是一个 endpoint 该有的东西。最终版本要求所有凭空冒出来的 scope 都必须标记成 assumption，由人类来确认。草稿因此变得更短、更准——两件事是同时发生的。

新人上手、ROI 与跨团队共享

新来的 PM 和工程师在写第一份 spec 之前，先把 library 读一遍。不是当教程读，是当参考读。这就是好东西长什么样，这就是产出它的 prompt，这就是告诉你什么时候该用它的元数据。半小时的阅读，省下一周的来回校准。

关于 ROI，我会跨季度跟三个指标：首份可评审 spec 的时间、首次评审时 AC 的完整度、从草稿到通过的评审周期时长。三个指标在 library 健康时一起上升，在它烂掉时一起回退。这就是你决定是否该剪枝的先行指标。

关于共享：AC 起草类 prompt 几乎可以不改直接跨团队用。spec 起草类 prompt 跨团队时需要小幅改动。任何涉及领域 schema 或团队特定约定的，就留在本地。反模式是那种四页长的 prompt，试图一次性容纳每个团队的上下文。没人认领，砍掉，写两条更短的，各团队各自认领自己的那条。

评审时看什么

这篇文章适合用在产品团队维护 Prompt 库时。别从“原则”聊起，直接拿一条真实改动来对照，看看规格里还缺什么。

• 每条 prompt 是否绑定一个具体产物。
• 输入不足时是否要求输出 UNKNOWN。
• 生成结果是否能回写到 PRD、spec 或验收标准。
• Prompt 更新是否有版本和负责人。

Prompt 库不是收藏夹。它应该减少重复沟通，并暴露哪些产品决策还没想清楚。

Prompt 库里每条 prompt 都要有主人

产品团队的 prompt 库最容易变成杂物间。我的规则是：每条 prompt 必须有 owner、适用场景、输入字段、输出格式和退役条件。没有 owner 的 prompt，三个月后基本没人敢删，也没人敢信。

Prompt library record:
- name: ticket-to-feature-spec
- owner: product-ops
- inputs: ticket, user impact, non-goals, rollout risk
- output: Markdown feature spec with Given/When/Then
- review: PM signs goals, QA signs acceptance criteria
- retire when: generator form replaces this prompt

边界：不要把一次性聊天记录收进库。只有被复用三次以上、产出格式稳定、并且有人愿意维护的 prompt，才值得版本化。

可复制产物：Spec Skills 工作流包

把这段用于真实的 Spec Skills 运行前。它会把输入、边界和人工评审点放在同一处，避免输出看起来完整但责任不清。

Spec Skills 工作流包：面向产品团队的 Spec Skills Prompt 库

本次要做的决策：
- 把这篇文章里的工作流应用到一个真实工单，并确认输入、边界、输出和人工评审点。

责任人检查：
- 产品责任人：
- 工程责任人：
- QA 或运维评审：

范围边界：
- 本次包含：
- 本次不包含：
- 仍需确认的假设：

验收证据：
- 测试或 fixture：
- 日志、指标或截图：
- 人工复核步骤：

工具边界：模型可以起草结构和问题，范围、契约行为、发布风险仍然必须由责任人确认。

评审追问：
- 没参加需求会的人还会误解哪里？
- 哪个证据能证明这次改动足够安全，可以发布？

编辑复核记录

复核日期：2026-04-28。本次补充了可复用产物，按相关主题 Hub 检查了文章定位，并收紧下一步链接，让页面更像可操作参考，而不是孤立长文。