Spec Skills 案例：从工单到规格的完整链路

用 Spec Skills 的引导式提问，把一份模糊的支持工单走成可交付的技术规格——真实对话记录与最终产出。

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

那张把一切点燃的工单

我们有一张工单在待办列表里搁了六周。标记为紧急，一共四句话，每一位接手的 PM 都在一个小时之内被它弹回来。下面是从 Linear 里原样粘出来的全部内容：

"用户没法取消订阅——需要加一个带挽留优惠的取消流程。客服被退款请求淹没了。法务也想要一条留痕。这个迭代必须上线。"

整张工单就这么点内容。没有验收标准。没有对"取消"的定义。没有成功指标。没有说明挽留优惠长什么样。没有提到按比例退款、仍在使用的 API key，也没提到一个已失效账户仍会触达的其他功能。我们没有按惯例写那份三天才能出炉的前期调研文档，而是把它直接喂进了 Spec Skills。

Spec Skills 的第一轮：没人愿意问的那些问题

我把工单粘进 Spec Skills，让它直接起草一份规格。它拒绝了。它没有动笔写任何内容，而是先甩回来九个澄清问题。其中有几个我们模糊地想过。大部分是我们一直在刻意回避的：

• "取消"指的是即时中断访问，还是到本计费周期末终止并且不再续费？
• 如果是到周期末，这段时间里他们保留写权限、只读权限，还是 X 天的宽限期？
• 挽留优惠是折扣、暂停、降级，还是三者兼有？谁来维护这份优惠矩阵？
• 即时取消时是否按比例退款？如果是，由谁来审批退款逻辑——财务还是产品？
• 订阅取消时，还在使用的 API key、预定的数据导出任务和团队席位会怎么处理？
• 这是纯自助流程，还是客服仍然需要一条针对边缘情况的手动介入通道？
• 法务要的"留痕"具体长什么样——签字确认、邮件收据、不可篡改的审计日志，还是全都要？
• 成功指标是什么——取消完成率、挽留优惠接受率，还是客服工单数量下降？
• 如果流程在生产环境开始产生错误的退款，回滚预案是什么？

在站会上把这份清单念出来很不舒服。九个问题里有六个我们答不清楚。而这正是它的价值所在。

这些问题逼出来的那场对话

接下来的四十分钟就是我们本该在六周前进行的那场对话。财务否决了超过一定金额的即时退款无需人工审核。产品定下了到周期末访问加七天宽限窗口的方案。挽留优惠收敛成单一的"三个月 30% 折扣"，不是矩阵——我们明确把降级路径排除出范围，因为它会动到 plans 表。法务要的是签字确认加一条不可篡改的审计记录，而不仅仅是一封邮件。

在我们写下任何一行规格之前，每一个决策都有了归属人。这正是会议驱动的版本对我们一直做不对的那一环。我们会达成一个粗略的共识，然后规格作者会悄悄地把它重新解读成自己最容易写的那个版本。这一次 Spec Skills 把每一个问题都钉在一个明确的答案槽位上，我们当着彼此的面把它们填了进去。

Spec Skills 拼出来的规格结构

当我们把答案喂回去之后，Spec Skills 产出了一份包含八个小节的草稿——一份带有明确归属人和清晰边界的结构化文档：

• 目标与非目标——带挽留优惠的取消流程，周期末失效。非目标：套餐降级、席位重分配、重新激活。
• 用户故事——三条主用户故事、一条客服手动介入、一条法务审计。
• 用 Given/When/Then 形式写的验收标准，按触达面分组。
• 数据变更——一张新的 cancellations 表、subscriptions 上两列新字段、一个定时任务。
• API 契约——两个新接口、一个改造的 webhook、显式的幂等键。
• 风险清单——会坏什么、会影响谁、每个风险对应的回滚路径。
• 上线计划——自助流量的 5% 先跑 72 小时，再全量。
• 指标——完成率、挽留优惠接受率、退款错误率、客服工单增量。

它浮出来的验收标准

就是在这一步，草稿不再像一份文档，而开始像一份工程可以直接对齐的契约。从那次会议里摘出的两段 Given/When/Then：

Given an active paying customer clicks "Cancel subscription"
  And they have more than 7 days remaining in their billing cycle
When they confirm cancellation and decline the retention offer
Then access remains active until the billing period end date
  And no further invoices are generated
  And a row is written to the cancellations audit table with the confirmation timestamp
  And a signed confirmation email is dispatched within 60 seconds

Given a customer accepts the retention offer
When the acceptance is confirmed
Then the subscription remains active with a 30% discount applied for the next 3 billing cycles
  And the offer_accepted_at timestamp is recorded
  And the customer cannot be offered another retention discount within 12 months

这些不是我写的。Spec Skills 根据我们的答案起草了它们，我们总共只改了三个词。十二个月的冷却期是它加的——法务一眼扫过去就标记说这是必要的。

它引出来的风险清单

风险小节是我本来没指望会有用、最后却成了最有价值的一页。对于每一个被触达到的面，Spec Skills 都追问了会坏什么、动了哪些数据、会影响到谁。我们最后得到一张短表：如果新事件类型没加到白名单里，webhook 消费方可能会错过取消事件；计费定时任务可能会对同一分钟内取消又续订的订阅重复处理；审计表需要行级锁，否则财务在月末导出时会撞上竞态条件。没有一条是能从原始工单里浮现出来的。其中一条如果没发现就会带着缺陷上线。

Spec Skills 做对了什么、做错了什么

它做对的部分：它在任何人动手写代码、承诺上线日期之前就把那些尴尬的问题先逼了出来。它在未知项没有归属人之前拒绝起草任何内容。它产出的 Given/When/Then 工程不用查术语表就能读懂。它点名了一些我们本会在生产环境才发现的风险。

它做错的部分：它建议加一个挽留邮件跟进序列——两周内发三封带挽回优惠的邮件——这并不在工单里，也不在我们的回答里，而且它把这段当作核心流程给出，不是作为可选扩展。我们把这段退回去删掉了。如果当时没盯着看，这就会悄悄地给一个已经塞满的迭代再加上一块生命周期邮件的范围。它是一个好写手，不是一个好 PM。范围要看紧。

三天变成四小时

这套工作流以前的版本平均要跑三个工作日——分诊、前期调研文档、两轮评审、和财务谈判、法务过审、拍板签字。这一次从头到尾只用了四小时：四十分钟的干系人现场对话、九十分钟的 Spec Skills 起草加我编辑，剩下是各项签字。规格最终落在 1800 字，作为取消流程模板的公开示例放在 spec-coding.dev。我们九天后上线，规格相关的返工工单数量为零——这是我之前从没能写下过的数字。

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

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

Spec Skills 工作流包：Spec Skills 案例：从工单到规格的完整链路

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

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

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

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

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

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

编辑复核记录

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

工单转规格评审清单

当一个粗略产品工单要变成工程可实现、QA 可测试的材料时，用这份清单。目标不是更长的文档，而是在实现前把假设摆到台面上。

下载：ticket-to-spec-field-template.md

• 引用原始工单，让评审人看清哪些是原文，哪些是推断。
• 把目标、非目标、负责人、批准路径和未决问题分开写。
• 把主流程转成 Given/When/Then 验收标准，并至少覆盖一个失败路径。
• 在批准范围前补上数据、账单、客服、API 和回滚影响的风险清单。
• 任何 AI 建议的扩展范围，在负责人确认前都标成假设。

需要追踪的证据

追踪第一轮评审后还剩多少澄清评论、多少验收标准能映射到测试，以及实现阶段是否新增了批准规格之外的范围。这些信号比字数更能说明规格质量。