Working Backwards（逆向工作法）

目的与适用边界

先讲清楚客户体验，再决定做什么，最后解决怎么做。从客户希望获得的结果出发，明确价值与范围，再细化需求、验证体验、确定实现方案和交付安排。成果应帮助实际读者作出决定或完成下一步工作；完整填写模板不等于完成分析。

「需求方」指有权确认业务需求与范围的客户代表或内部负责人；「用户」指实际使用产品的人，两者可能不同。需求方确认不能自动证明用户体验成立，应结合用户反馈或明确的验证证据。

以下 8 步是本 skill 结合需求工程与项目管理实践的团队流程，不是 Amazon 原书的固定步骤。公共方法论及来源见 Amazon 方法说明，需要解释方法来源时再读取。

8 步推进与核心输出

允许按完整业务链、模块或版本滚动推进。上游文档可随验证修订；未获确认的事项不得冒充已确认输入。硬件项目在每个适用研发阶段内循环设计、实现和测试，再作阶段放行。

执行流程

1. 确定本次任务

先识别用户要讨论、评审还是生成/修改成果，以及读者、用途、覆盖范围和已有材料。从当前阶段切入，只补妨碍本次输出的缺口；不为一个局部任务自动生成整套文档。

• 模糊立项：先用 PR/FAQ 澄清客户价值与关键假设；明确需求：可从 PRD 开始。
• UI 软件：默认可点击的静态 HTML 原型；本地安装软件可补充 Figma。原型必须声明为一次性原型，请勿用于生产；原型代码不得直接演变为生产代码。
• 无界面服务/模型：使用服务契约、输入输出示例及能力验证方案。
• 硬件/软硬件混合：按对象划分需求与原型；含 UI 的部分仍需界面原型，物理部分按样机或体验模型表达。

测试内容和方法由项目需求、技术方案与验收标准确定，不在通用流程中预设特定软件领域的平台能力或评估工具。

2. 组织内容与选择模板

读取 流程详解 的当前阶段及 成果质量与交叉检查，再读取所需模板。先整理事实、分类与目录，再写正文；使用者能据此行动，是判断内容是否充分的依据。

模板规定核心内容，不要求照抄所有标题和空表。小项目可合并文档或短小子节，但保留需求规格、功能清单、原型评审、方案、估算、计划、实现证据、测试、发布与复盘等当前阶段所需的核心内容及确认记录。适用性和合并位置说明一次即可。

3. 保持文档关联与证据一致

每个关键输出起草前核对上游与后续用途，提交前核对文内、配套文档及已有下游。发现冲突先修正；无法自行确定的事项记录影响、责任与处理安排。下游尚未形成时，仅检查本输出能否支撑下一步，不虚构关联或核验结果。

需求编号贯通功能、原型、设计、任务及测试；各类信息的主记录与状态口径见流程详解。设计文档持续维护，测试、发布及复盘保留针对具体版本的事实快照。变更应评估范围、进度、成本、质量影响，按已有权限确认后更新关联材料。

区分已确认验收要求、内部工程目标和已验证结果。已确认的量化要求写入需求规格并用于验收；尚不确定的时长、准确率等能力承诺只作内部工程目标，不写入验收承诺或 UI 文案。目标不得写成已经达成的结果。

4. 检查质量与交接条件

交付前按成果质量参考中的标准检查：结论清楚、层次明确、内容具体、依据可查、上下游一致、下一步可执行。删除重复叙述、空表、编写提示和无依据的赞誉；缺失事实用具体待确认项表达。检查结论简述于现有评审记录或交付说明，不另增检查文档。

编写完成、需求确认、技术可行、预算批准、测试通过和交付验收是不同结论。已有有效确认直接引用；缺少确认时，可交付待评审稿并继续不依赖该结论的工作，但暂停需要该确认的下一阶段，不自行判定通过。

关键发布指标未达标时必须阻塞相应范围。若范围或指标确需调整，应有业务理由和授权，更新需求与计划，并对调整后的范围重新验证；不得为放行而事后改写阈值或只记录问题便宣称通过。

5. 输出与命名

优先沿用用户指定目录和项目已有文档约定；确无约定且无法从上下文确定时才询问。文件名采用 <阶段编号>-<成果名称>-<项目关键字>-v<版本>.<扩展名>，模板文件名保持不变。PR/FAQ 的文件名使用 PRFAQ，名称中不得包含路径分隔符或系统禁用字符。

客户有版本规则时沿用；否则首稿 v0.1，确认后 v1.0，小修改递增次版本，范围或设计重大变更递增主版本。文档版本与软件/发布版本分开标注，文件名与正文版本一致。默认 Markdown，按用户要求导出其他格式。

同一项目沿用已确认的目录、格式和命名规则。用户明确要求修改现有文件时直接在授权范围内修改并保留变更依据；新建交付物遇同名文件，按已有归档规则处理，尚无规则时再确认，避免重复询问已有授权。

职责分工

项目经理统筹范围、进度、资源、成本与风险；Business+FDE 负责客户价值及前线约束并协调需求方；需求工程师维护需求与功能范围；架构师牵头技术方案，研发及测试人员提供实现、估算和验证依据。按需纳入设计、部署、运维及外部依赖责任人。

角色可以兼任，但资源预算、商业条件及交付承诺须由相应授权人确认。项目经理组织评审不等于拥有所有审批权限；内部产品同样明确业务、资源及验收责任人。