Spec Skills Prompt 模式：规格工作流提示模板

一份 Spec Skills prompt 模式清单，覆盖规格草稿、AC 生成、评审辅助和风险登记簿挖掘这些常见规格工作流，以及我实际在用的 prompt 形态。

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

每一条 Spec Skills Prompt 都共享同一个骨架

我用 Spec Skills 跑规格工作大概有一年了，凡是被我长期留在工具箱里的 prompt，都有同样的五个部分：system role、spec 上下文、单一任务、边界，以及输出形态。只要少掉任何一个，输出就开始漂移，而漂移的方式永远相同——自信的散文、看起来像模像样的小节，但没有一条我能据此做决定的内容。

这个元模式短到可以背下来。我先写 role，这样模型就不会继续假装自己是个中立助手。我把规格或者里面真正相关的片段原样粘贴进去，而不是丢一份总结。我只给它一个任务，绝不给清单。我告诉它什么不能做。我再规定一个格式，通常是模板化的 markdown 或者一段 JSON，因为规格工作最容易死在散文里。

元模式本身的验收标准

我把元模式本身当成一份规格。如果我的 prompt 过不了下面这些条款，那就先重写 prompt，别急着抱怨模型。

- Given a prompt aimed at Spec Skills for spec work
  When I read it back before sending
  Then it contains a role, context, one task, boundaries, and an output shape

- Given a prompt missing any of those five parts
  When I send it anyway
  Then I expect shallow output and I do not complain about the model

- Given the output shape is prose
  When the task is a spec artifact
  Then I rewrite the shape as markdown template or JSON before reuse

模式 1：Feature Spec 草稿

这是我用得最多的一条。prompt 只让模型产出我认为一份 feature spec 必须有的那五个核心小节，别的都不要：problem、scope、non-goals、acceptance、risks。不要架构，不要时间表，不要 rollout，这些都由别的模式负责。

真正的诀窍是：我把原始素材塞进去——通常是一张 ticket 加一段简短的对话记录——并且明确告诉它：不要凭空编造任何不在源材料里的东西。如果某一节的信息不够，就写 UNKNOWN，并列出你还需要什么。UNKNOWN 是我工作流里最有价值的一个 token，因为它把“仍然需要人来想清楚”的地方暴露了出来。

模式 2：Edge-Case 挖掘

拿到规格草稿之后，我再把它喂回去，换一个 role，给一个任务：会在哪里崩。prompt 里会写：你是一个正在为上线评审这份规格的资深工程师，抱有怀疑态度。请列出这份行为描述在真实世界里最可能失败的十种方式。按“周五下午暴雷有多丢脸”排序。

输出形态是一个带编号的列表，每一项一行失败描述加一行缓解措施。十条是刻意的。五条太少，逼不出模型越过那些显而易见的内容；二十条就开始注水。十这个数字是甜点区，最后两条往往正是值得抄走的东西。

模式 3：评审助手

这个模式把规格和 PR diff 配对。任务故意单一、故意无聊：列出 diff 中每一处与规格产生偏差的地方。不是 bug，不是风格问题，只列偏差。对于每一处，引用规格里那一行和 diff 里那一行，然后说是规格错了、代码错了，还是两边都要改。

我不要它下判决，判决还是由人来做。prompt 给我的是一份索引，而这份索引是我在一个十五分钟的评审窗口里绝不会手工做出来的东西。

模式 4：风险登记簿挖掘器

这是每周都能把自己养活的一条。下面就是我团队在用的 prompt 原型，字段名就是我们实际上线用的那些：

ROLE: You are a risk analyst reviewing a feature spec before implementation.

CONTEXT:
<paste the full spec here>

TASK: Surface risks in seven categories. One line per risk, no prose.

CATEGORIES:
1. Data integrity (what could corrupt, leak, or be lost)
2. Access and authorization (who sees what they should not)
3. Availability (what takes the system down)
4. Compatibility (what breaks for existing users or integrations)
5. Compliance (what regulators or contracts care about)
6. Cost (what causes the bill to surprise us)
7. Operational (what on-call has to page someone for)

BOUNDARY: Do not propose mitigations. Do not rank. Do not combine.
If a category has no risk, write "none identified" and stop.

OUTPUT: Markdown with one heading per category and a bullet list beneath.

这些类别不可谈判，boundary 那行才是关键。我第一版写的时候允许模型顺便给出缓解措施，结果 80% 的 token 都被宽心话占掉了。把那一截砍掉，这个模式才变得真正有用。

模式 5：Spec-to-Tests

把验收标准清单塞进去，让它按每条 AC 出一个 Given/When/Then 用例，再外加每条 AC 一个失败变体。输出形态是一整块 pre 代码，里面只有用例，不带任何旁白。我直接把它粘到测试计划文档里，再由人去精简。

我学到的一件事是：如果 AC 列表写的是产品口吻，这个模式就会返回一堆产品口吻的测试用例。Garbage in，garbage out，只是格式自信而已。这个模式就是一面镜子。如果输出看起来空洞，那说明 AC 列表本身就空洞，而那才是真正值得修的 bug。

模式 6：Non-Goals 提取器

这是最难调对、也是一旦调对收益最大的 prompt。我把一份 PRD 或一段很长的 Slack 对话塞进去，然后问：基于源材料里明确的排除或含糊表达，这个项目明摆着不打算做什么？不要推测。每一条 non-goal 都要引用那句暗示它的原文。

大多数情况下，模型会返回两三条过得去的 non-goal，外加一条糟糕的。这没关系。第一天能落袋两条真正的 non-goal，就能在第三十天省下一场 scope 扯皮，这笔交易我每次都做。

没人提醒你的那种失败方式

我见过的最大错误，是团队试图把所有东西塞进一个 prompt：生成规格、生成测试、生成风险、生成 rollout 计划。输出一定是浅的，因为模型把注意力分给了六个任务，上下文窗口在各任务之间的切换上烧 token。

Prompt 就是流水线。先出规格草稿，把草稿交给 edge-case 挖掘模式，再把挖出来的 edge case 回灌到规格修订里，再把修订后的规格交给风险登记簿挖掘器，最后把 AC 列表交给 spec-to-tests。每一段都很窄，上游一变就能便宜地重跑一遍。把整条工作流塞进一个超级大 prompt，在 prompt 工程里相当于写了一个一千行的函数。

这个库怎么存

我把每一条模式都存在一个扁平的 markdown 目录里，一条一个文件，里面包含 prompt 正文、一份示例输入、一份示例输出，以及一份变更日志——我每次改动措辞的时间和原因。这又回到 prompt 库那条规矩：没有版本、没有日期的模式，会在模型悄悄更新时悄悄腐烂掉。

输出格式的重要性远超大多数人愿意承认的程度。结构化 JSON 或者模板化 markdown 永远比散文强，因为结构化输出可以 diff、可以被解析、并且强迫模型明确表态。散文只会让它到处打掩护。这份清单里的每一条模式都规定了格式，那不是装饰。

我会对新来的队友说什么

先挑两条去练熟，再碰别的：feature spec 草稿和风险登记簿挖掘器。光是这两条就已经覆盖了真正重要的规格工作里 60% 的体量，而且能靠重复把元模式练进肌肉记忆里。剩下的一切都不过是同样五个部分——role、context、task、boundary、shape——的变奏。只要这个骨架成了肌肉记忆，为一条新工作流写一条新模式，大概十分钟加一份真实样例用来校准就够了。

先选模式，再写 prompt

很多 prompt 失败不是因为措辞差，而是模式选错了。把“生成 spec”“审查 spec”“找边界”“转测试”混在一个 prompt 里，输出一定会糊。每次只让模型做一种工作。

Prompt pattern selector:
- Need raw draft: ticket -> feature spec
- Need critique: spec -> missing edge cases
- Need QA handoff: acceptance criteria -> test matrix
- Need implementation guardrail: spec -> coding prompt boundaries
- Need release safety: spec -> rollout and rollback checklist

边界：不要让一个 prompt 同时决定范围、写实现计划、生成测试和评审自己。拆开后虽然多一步，但每一步都更容易被人检查。

模式选择也要留下记录

团队如果经常复用 prompt，我会在 PR 里记录本次用了哪种模式：草稿、审查、测试矩阵还是实现边界。这样回头看失败案例时，能分清是输入字段不够、输出格式不对，还是一开始就选错了工作模式。

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

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

Spec Skills 工作流包：Spec Skills Prompt 模式：规格工作流提示模板

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

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

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

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

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

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

编辑复核记录

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