三周前，我晚上十点半还在看Notion页面。一个客户发来了一份自定义预订平台的简案。那份简案只有四个要点和一个表情符号。就是："像Calendly一样但用于狗狗美容💐"。仅此而已。没有用户流程。没有边界情况。不知道他们想要SaaS还是单租户安装。而他们需要周五之前的规格说明。
我过去害怕那些时刻。现在我几乎期待它们。
因为我建立了一套围绕Claude的工作流程，它能在几小时内把那种混乱转变成结构化、有说服力的规格说明。在过去一年半里，我在Seahawk的大约40个项目中完善了它，它让我避免了至少三次"但我以为它能做X"的重写，这些重写本来会花真金白银。
让我好好为你讲解。
---
为什么模糊的简案其实是很好的起点
关于模糊简案的问题是：它们包含信号。狗狗美容Calendly这个东西告诉你行业、对标产品和隐含的规模（小企业，不是企业级）。这不是小事。
我过去犯的错误是立即尝试自己补充简案。我会做出假设，把它们写进文档，然后客户会签署一份40%是我猜测的东西。这是在等待灾难。
Claude没有这个问题。它会提问。或者说，当你正确地提示它时，它会生成你本应问的问题。
我在任何新项目上的第一步是把原始简案粘贴到Claude中，要求它识别为了构建这个东西我必须做出的每个假设。不是功能。是假设。输出通常是15-25个问题，其中大约三分之一是我本来会忽略的。
对于狗狗美容项目，Claude表面上有一些东西，比如：美容师有多个员工，还是独自经营？预订是否需要考虑宠物大小影响预约时长？在预订时是否需要定金或付款捕获？我根本没想过宠物大小的问题。客户也没想过，事实证明。我们在发现电话中而不是第三冲刺中抓住了这个问题。
---
真正起作用的提示结构
我尝试过很多不同的方式来提示规格说明工作。通用的东西比如"帮我设计一个预订应用"会得到通用垃圾。起作用的是一个结构化的输入，给Claude足够的背景来约束它的输出。
这是我现在使用的粗略模板：
- 角色定义。我告诉Claude它作为一位曾交付过B2B SaaS的资深产品经理，对范围蔓延过敏。
- 原始简案。逐字粘贴，无论多粗糙。
- 约束条件。预算范围、技术栈如果已知（我们对大多数客户网站默认使用WordPress/WooCommerce，对任何更复杂的东西使用自定义Laravel）、时间表、团队规模。
- 输出格式。我要求一份结构化文档，包含具体部分：问题陈述、用户角色、核心用户流程、功能列表（MVP对比发布后）、悬而未决的问题和风险。
约束条件部分是大多数人跳过的。这很重要。"预算：8000英镑，时间表：8周，两个开发人员和一个兼职设计师"产生的规格说明与相同的简案但没有约束条件非常不同。没有它们，Claude会很乐意为一个需要六个月和60000英镑才能构建的产品制定规格说明。这很有趣，但无法交付。
---
用对抗性提示迭代规格说明
获得初稿规格说明书很容易。真正的价值在于迭代。
Claude生成初始文档后,我会进行我称之为"对抗性审查"的步骤。我会直接问它:"现在反驳这份规格说明。范围蔓延最可能发生在哪里?我们低估了什么?这个列表中的哪个功能会在12个月内造成最多的技术债?"
Seahawk在2022年有一个金融科技客户,他们想要一个仪表板来跟踪小额投资组合。最初的规格看起来很可靠。对抗性审查指出,MVP中的"实时价格更新"功能做了很多繁重的工作,可能需要一个我们的时间表和预算都没有考虑到的WebSocket架构。我们发现了。我们把它的范围调整为MVP每60秒轮询一次,将实时功能作为第二阶段。客户同意了。没有对抗性审查我们会发现吗?也许吧。但可能要到有人已经花了三周时间构建时才会发现。
对抗性步骤增加了大约20分钟的流程时间。这总是值得的。
---
将规格说明转化为用户故事
一旦规格说明足够完善,我不为它感到尴尬,我就会转向用户故事的生成。这是Claude真正表现出色的地方,因为编写好的用户故事很乏味,也很容易做得很差。
我把规格说明反馈给Claude,要求以标准格式生成用户故事:"作为[角色],我想要[操作]以便[结果]。"我也要求它为任何非平凡的功能标记验收标准,因为"作为一个预约管理员,我想阻止假期时间"有惊人多的边界情况(循环阻止?时区是什么?它会通知有现有预订的客户吗?)。
有几件事我坚持:
- 故事应该为特定的角色编写,而不是通用的"用户"
- 每个故事都要有粗略的复杂度估计(S/M/L,在这个阶段不需要更细的粒度)
- "L"级别的任何故事在进入Jira前都要标记为需要进一步分解
最后一点很重要。冲刺计划会议中的L级故事基本上就是个炸弹。让Claude提前发现它们意味着我们在有人开始构建前就能进行讨论。
---
我与Claude的界线
我想坦诚地谈论这个,因为我看到很多关于AI现在可以做一切的激烈言论。
Claude不擅长做决定。它擅长列出选项和权衡,但是关于是否要构建自定义通知系统或使用Novu(我们已经在三个项目中使用过,并且会推荐)的实际决定仍然需要了解项目、客户和团队能力的人。
我也发现它在涉及特定库版本或小众API行为的任何事情上都不可靠。对于广泛的架构讨论还可以。对于"这个特定版本的WPGraphQL是否能在负载下处理这个特定的查询模式",我更倾向于测试而不是信任。
老实说?提示词本身需要技能。我团队中的一个初级成员尝试使用相同的工作流程,但得到了平庸的规格说明,因为约束和角色框架不够严格。这个工具会放大使用它的人。这不是批评,只是值得现实一点。
---
将输出整理成活文档
Claude生成的规格说明不是最终产物。它是输入。
我对客户的真正可交付物是一份Notion文档,它从Claude输出构建而来,但重新组织成适合签批的格式。通常包括:
- 执行总结(3-4句话,无行业术语)
- 范围(包括什么,明确排除什么)
- 用户角色(最多2-3个,超过这个数量就是噪音)
- 核心流程（按编号步骤写出，不用散文体）
- 功能表（列：功能、MVP 或第二阶段、大致工作量、负责人）
- 待决问题（任何阻碍决策的事项，并指定负责人回答）
- 风险和缓解措施
我从 2020 年的一个项目开始采用"待决问题"这个做法，那个项目出了岔子，因为大家都以为别人已经确定了数据保留政策。在每个待决问题旁边指定一个人，这样就不会无限期地拖着不解决。
Notion 文档被分享给客户，他们直接在文档中评论，我们再花 45 分钟通话走一遍。直到每个待决问题都有答案，才会交给开发者。
---
The Actual Time Savings, Honestly Stated
在这套工作流之前，一份中等复杂度项目的规格说明（比如会员门户或定制电商系统）要花我一天半的时间。反复推敲、重写。把草稿发给同事征求意见，再整合他们的反馈。
现在 Claude 辅助生成初稿大概两到三小时，再加大约一小时的人工编辑和客户交付打磨。总共三到四小时。
按一年来算，这笔时间节省并不微小。Seahawk 每个月大概交付两到三个项目的规格说明。即使保守估计，也能省下一年 50 到 70 小时我原本要花在从头写初稿的时间。
但说实话，更大的收益是质量。对抗性审查特别能抓住我可能忽略的东西。前期假设浮现意味着发现阶段更高效，因为我们讨论的是真实的决策，而不是我抢着填补我没注意到的空白。
---
FAQ
这套工作流对内部工具和客户项目一样有效吗？
有效，有时对内部项目效果更好，因为你比任何客户简介都更了解用户。我在去年为 Seahawk 自己的内部时间跟踪工具制定规格时用的基本是同样的流程。约束条件很好判断，因为我知道预算（外部支出 0 英镑，一个开发者，三周时间），用户角色就是办公室里的真实的人。
非技术型创始人可以在没有开发者的情况下使用这个流程吗？
到一定程度可以。假设浮现和用户故事这两个步骤不需要技术知识就能做。难的地方在对抗性审查和工作量估计。你需要有经验判断 Claude 什么时候低估了复杂度。如果你不是技术背景，就在这一步和有过软件交付经验的人合作，哪怕只是一小时通话。
使用 Claude 时，怎么处理机密的客户信息？
我把任何敏感内容都在投入提示词前进行匿名化。客户名称变成"[客户]"，任何个人可识别数据都删除。对于真正敏感的内容，我也会通过 API 使用 Claude，这样 Anthropic 企业级数据处理条款就适用了，而不是消费者产品那套。在决定什么对你的场景合适之前，值得先读一下 Anthropic 的使用政策。
规格说明能经受开发者的首次接触吗？
不能。也不应该能。规格说明是一个强制手段，用来尽早进行正确的对话，而不是冻结思维的合同。我跟客户说的是：规格说明是我们今天要构建什么的共同理解。它会改变。它的作用是让那些改变变得可见且有意为之，而不是无意中发生。
---
规格说明不是文件。它是一场论证。你在论证自己充分理解了问题，足以构建值得构建的东西。Claude 不会替你做这个论证。但它作为一个非常有用的论敌，帮助你想清楚自己到底想说什么。
这对任何人来说都值两小时的时间。