先自己走通一次流程

产品范围确定以后，还要把其中一项能力交给开发者、设计师、内容作者、外部协作者或 AI 完成。很多交付问题从这里开始。

「做一个登录页」「支持批量上传」「把界面做得高级一些」都表达了方向，却无法直接执行。接收任务的人需要自行猜测用户、流程、状态和完成标准。最后出现偏差时，双方只能围绕各自理解争论。

一份可执行的需求，需要让不同执行者面对同一个对象。它要说明任务服务谁、为什么做、输入和输出是什么、用户怎样走完全程、正常和异常状态怎样处理、哪些内容明确不做，以及达到什么条件才算交付。

需求文档不必很长。小任务可以只有一页，复杂任务则需要原型、状态表和验收用例。篇幅由歧义和风险决定，目标始终相同：开始前减少猜测，执行中控制变化，结束时可以验证。

把任务交出去之前，负责人需要先理解完整流程。外部协作案例中，委托方先亲自完成关键词研究、文章写作、截图和发布，后来才把初稿执行交给外部作者。^[1] 这个顺序让他知道一篇可发布内容需要哪些步骤，也知道哪些错误必须返工。

自己走通不等于每项工作都要成为专家。它要求负责人至少能够回答：

• 任务从什么事件开始；
• 需要哪些输入和权限；
• 中间有哪些关键判断；
• 输出进入哪项后续工作；
• 什么结果可以接受；
• 哪些失败会伤害用户或业务；
• 执行者退出后由谁接管。

如果负责人无法分辨合格和不合格结果，增加人手或换用更强模型也很难解决。执行者会按自己的经验补全空白，AI 则会生成一份看起来完整的默认答案。双方可能很努力，产出仍然偏离真实任务。

对于从未做过的新流程，可以先用手工方式完成一轮，或请专业人员做一次付费试作。试作的目标是暴露步骤、依赖和验收难点，随后再决定哪些部分适合标准化。

从一句需求扩展为九个部分

一项功能或交付任务，可以按下面九个部分写清楚。

1. 背景与目标

说明为什么现在做，以及希望改变什么。目标应落在用户行为或业务结果上，例如「让已注册用户完成第一份真实文件处理」，而不是「增加批量模块」。

2. 用户与场景

说明谁在什么情况下使用。他是否首次使用，具备什么资料和能力，在哪种设备或工作环境中完成。

3. 输入

列出需要提供的数据、文件、文字、账号、权限和前置状态。输入还要说明格式、大小、数量、语言和缺失时的处理。

4. 输出

写清最终交付物是什么、包含哪些字段或文件、由谁使用、怎样进入下一步。输出「生成成功」不够，还要说明它能否下载、编辑、复制、发布或被其他系统读取。

5. 完整流程

按用户顺序列出每一步，从进入任务到获得结果。必要时补充系统处理、人工介入和第三方服务。

6. 状态与异常

覆盖首次进入、空状态、处理中、成功、失败、无权限、超限、断网、重复提交和部分完成等情况。

7. 范围与边界

列出本次包含和不包含的内容，说明设备、角色、平台、格式、历史数据和兼容限制。

8. 交付物与版本

约定代码、设计源文件、文案、测试、说明文档、数据迁移、部署方式和版本记录。

9. 验收条件

用可观察结果说明完成标准，包括正常路径、关键异常、界面最低要求、安全检查和人工确认。

九个部分不需要固定成一张大表。简单任务可以放在一页说明里；流程复杂时，文字、原型、状态表和验收用例应互相对应。

输入要做到无歧义

许多任务在输入阶段已经决定了交付质量。执行者收到「参考这个网站」「处理一下这批数据」或「沿用现有风格」，仍要猜测具体对象和优先级。

输入说明可以包含：

参考材料要附上用途。例如，一张页面截图可以用于说明信息层级，不代表要复制视觉；一份旧代码可以用于了解数据结构，不代表继续沿用全部实现；一篇示例文章可以用于说明语气，不代表照搬事实和结构。

冲突顺序也要写明。当原型、文字说明和现有产品行为不一致时，以哪一项为准，执行者需要知道。更稳妥的做法是先消除冲突，并在需求首页写出当前有效版本。

真实数据应遵循最小必要原则。能够用结构相同的脱敏样本验证时，不要直接提供生产数据。必须使用真实账号或文件时，要明确授权范围、保存期限、访问记录和删除方式。

用一个例子看需求怎样变清楚

一句原始需求是：

支持批量上传商品图片，并用 AI 自动处理。

它没有说明谁上传、一次多少张、怎样配对商品、AI 做什么、失败怎么办。扩展后可以写成：

背景

每周上新十到三十款商品的小团队，需要逐张处理背景和商城尺寸，重复操作占用较多时间。

用户与触发

已登录的店铺运营者，在新品资料准备完成后，从商品编辑页开始批量处理。

输入

• JPG 或 PNG；
• 单张不超过约定大小；
• 一次最多上传约定数量；
• 每组图片关联一个商品编号；
• 用户拥有图片使用权并确认隐私要求。

正常流程

1. 用户选择或拖入图片；
2. 系统检查格式、大小和数量；
3. 用户确认商品编号与目标尺寸；
4. 系统显示逐张进度；
5. 处理完成后展示预览和失败项目；
6. 用户可重新处理单张图片；
7. 成功结果按商品编号打包下载。

输出

每张原图对应约定尺寸和命名规则的结果文件；处理失败的图片不进入成功包，并保留明确原因。

本次不做

多人审批、素材库、广告投放、任意自定义尺寸和视频处理。

验收

符合条件的测试图片可以完整上传、处理、预览和下载；格式错误、超限、单张失败和网络中断都有可理解的状态；重试不会产生重复扣费或重复任务；移动端至少能够查看状态并下载结果。

这份说明仍需根据真实产品补齐数量、格式和收费规则，但执行者已经不需要猜测主要路径。开发、设计和测试也可以围绕同一组状态工作。

区分交付物、完成定义和验收条件

这三个概念经常混在一起。

交付物回答「最终要收到什么」。它可以是合并后的代码、Figma 源文件、文章初稿、部署环境、测试记录和使用说明。

完成定义回答「执行过程达到哪些共同底线」。例如代码经过评审、测试通过、没有遗留调试信息、文档已更新、已知限制已经记录。

验收条件回答「这项具体任务怎样证明符合需求」。例如用户可以上传五张合法图片，部分失败时成功结果仍可下载，重复提交不会重复扣费。

三者缺一会产生不同问题。只有交付物，容易收到形式完整但无法使用的文件；只有完成定义，无法判断具体业务任务；只有验收用例，可能遗漏源文件、文档和接管材料。

交付任务可以在开头列出三张短清单：

• 交付物：代码、设计、内容、配置、数据和说明；
• 共同完成底线：评审、测试、安全、文档和版本；
• 本任务验收：用户行为、系统状态和输出结果。

这样做也方便按里程碑拆分付款和检查。每个阶段都应产生可以独立查看的结果，避免最后一天才发现前面理解已经偏离。

先写流程，再画界面

原型经常从一个页面框开始，随后补按钮和字段。这样容易遗漏进入页面之前的条件，以及提交以后发生的事情。

Notion Converter 的一次合作中，委托方最初只画了一个框，再用口头解释想法，开发结果与预期差异很大。后续改进包括详细原型、完整任务流程、每种状态和边界、与设计师共同确认界面，以及从核心能力一路检查体验链路。^[2]

流程至少要包含四个视角：

原型负责展示结构和交互，流程说明负责连接页面之外的动作。一个支付成功页无法说明重复回调怎样处理，一张上传界面也无法说明大文件、过期任务和部分失败。两者需要一起存在。

原型、状态表和示例各自负责什么

一个原型很难承载全部要求。把不同材料的职责分开，交接会更清楚。

• 流程图：说明页面和系统动作怎样连接；
• 线框或高保真原型：说明信息层级、交互位置和页面之间的跳转；
• 状态表：列出正常、空、错、处理中和权限情况；
• 数据字典：说明字段、类型、约束和来源；
• 示例输入输出：让双方看见真实粒度和质量；
• 验收用例：说明怎样确认结果；
• 非目标清单：阻止相邻需求在执行中悄悄进入。

Notion Converter 的改进过程之所以同时补充详细原型、完整流程和边界状态，是因为单个框只能表达局部布局，无法形成共同验收对象。^[2] 设计工具中的源文件也应保留结构关系。Auto Layout 等能力可以把分组、间距和响应变化表达出来，比一张静态图片更便于开发理解。^[3]

这些材料之间需要使用相同术语和编号。流程里的「处理任务」、原型里的「生成」、接口里的 job 若指同一个对象，应在文档中说明。名称不一致会让参与者误以为存在三套概念。

正数、零、负数都要写

一句话需求常只描述正常情况。真实产品还会遇到零和负数：没有数据、数量为零、余额不足、金额为负、接口没有返回、权限失效、部分记录失败。

可以按下面的状态表逐项检查：

状态不需要为了追求完整而无限扩张。优先覆盖主要任务中高概率、高损失和不可逆的情况。低概率且可以安全失败的情况可以明确限制；涉及付款、数据删除、隐私和权限时，边界应当更严格。