候选 Spec 的八维审查
一句话收获：审查的目标不是把文字写漂亮，而是让每个关键边界可执行、可验证。
这个场景在解决什么问题
目标（goal）是用目标、事实、范围、对象、约束、异常、停止、验收这八个维度来检查一份 Spec。观察方式是逐项发现一份"看似完整"的文档里藏着哪些工程缺口。值得单独学，是因为审查这份活的真正价值不在润色文字，而在让每一个关键边界都能被执行、能被验证。
先理清这条判断链（文字版）
先审目标、事实、范围这三样"起点"对不对，再审对象、状态、权限这三样"业务落点"清不清楚，接着审异常与停止这两样"边界"有没有定义，最后审验收证据"完成"由什么来证明。判断链是：
- 检查目标是否被功能替换、事实是否有来源、范围是否被顺手扩大。
- 检查系统处理什么对象、状态由谁提供、谁能执行什么动作。
- 检查缺失、冲突、超时、重复、部分成功、结果未知这些异常怎么处理、何时停止。
- 检查每项关键要求是否映射到可观察证据，完成是否由模型外的机制确认。
逐层详解
第 1 步：目标、事实与范围
原文：检查目标是否被功能替换，事实是否有来源，范围是否被顺手扩大。
白话：审三件事——目标有没有被悄悄换成了"某个功能"，写的事实有没有出处，范围有没有在过程中被不自觉放大。
类比：像审合同时先看三处——当初谈好的目的是不是变了味、对方引用的数据有没有出处、承诺的范围是不是被偷摸加码。
举例：审查一份客服机器人 Spec，发现目标从"提升问题解决率"被换成了"实现智能回复功能"（功能替代了目标）、一条"用户满意度 95%"的事实没有任何来源、范围从"常见问题"被扩成了"所有问题"。
为什么重要：错误起点会让后续计划和测试共同偏离——起点就歪了，后面做的计划和测试都会一起跑偏。
怎么验证（证据点）：
- 原始目标：当初定下的目标是什么，还在不在。
- 事实来源：每条事实的出处可查。
- 非范围清单：明确列出"不在范围内"的事项，防止范围膨胀。
别踩的坑（边界）：章节齐全不证明目标仍正确——文档结构再完整，也不代表目标没被偷换。
落地检查：先确认任务仍是原任务——落地审查第一问就是：我们要做的还是原来那件事吗？
第 2 步：对象、状态与权限
原文：检查系统处理什么对象、当前状态由谁提供、谁能执行什么动作。
白话：审系统到底在操作什么对象（如订单、工单）、每个对象"现在处于什么状态"这个信息由谁权威提供、以及谁能对什么执行什么动作。
类比：像查一个仓库——管的是什么货、库存数字谁说了算、谁有权出库入库，这三样不搞清，账就乱。
举例：审查订单处理 Spec，确认对象是"订单"、订单状态由订单系统（权威源）提供而非 AI 自己猜、只有具备权限的角色才能"取消订单"或"退款"。
为什么重要：对象和状态决定业务规则落点——业务规则到底落在哪个对象、哪个状态上，直接决定系统对不对。
怎么验证（证据点）：
- 对象稳定：系统处理的对象定义稳定、不漂移。
- 状态权威：状态由权威系统提供，不是模型自说自话。
- 权限可强制：谁能做什么动作，能被强制约束。
别踩的坑（边界）：学员不需要手工设计内部 ID——审查时不必纠结内部主键怎么设计，那是实现细节。
落地检查：关注语义稳定和模型外执行边界——落地审查重点是"对象语义是否稳定"和"执行边界是否在模型外被强制"。
第 3 步：异常与停止
原文：检查缺失、冲突、超时、重复、部分成功和结果未知怎样处理。
白话：审异常情况——数据缺失、信息冲突、超时、重复提交、部分成功、结果未知这些烂摊子，系统分别怎么处理。
类比：像规划自驾游，不能只安排"顺利到达"，还得想好"爆胎了怎么办、走错路了怎么办、一半人到一半人没到怎么办"。
举例：审查支付系统 Spec，看它是否写清了——支付请求超时怎么处理、重复点击怎么防重、扣款成功但订单没更新（部分成功）怎么对账、结果未知时怎么查证。
为什么重要：只有正常路径无法定义系统边界——只写"一切顺利时怎么办"，系统的真正边界根本定义不出来。
怎么验证（证据点）：
- 错误可分类：各种异常被分门别类，而不是一锅粥。
- 停止条件存在：有明确的停止条件，不会无限跑下去。
- 接管路径明确：出错后由谁接管、怎么接管写得清楚。
别踩的坑（边界）：所有失败都写成重试会制造重复副作用——把每种失败都简单写成"重试"，会导致重复执行产生重复副作用（比如重复扣款）。
落地检查：错误语义决定恢复路径——落地时先分清错误是哪种语义，再决定是重试、回滚、人工介入还是放弃，不能一刀切。
第 4 步：验收证据
原文：每项关键要求映射测试、工具回执、权威状态或人工判断。
白话：每一项关键要求，都要明确由什么来证明它完成了——是自动化测试、工具执行回执、权威系统的状态、还是人工判断。
类比：像验收装修，不能听包工头说"做好了"，要一项项看——瓷砖贴没贴平（测试）、材料清单对不对（回执）、水电是否已通（权威状态）、美观度合不合格（人工判断）。
举例：审查发货 Spec，把"订单已发出"这项要求映射到物流系统的真实出库状态（权威状态），而不是模型说"我发出去了"；把"接口正确"映射到自动化测试通过。
为什么重要：完成必须由可观察证据确认——"完成"不能靠嘴说，必须由外部可观察的证据坐实。
怎么验证（证据点）：
- 结构验证：结构/格式层面的验证。
- 运行验证：跑起来之后的验证。
- 业务验证：真实业务条件是否成立的验证。
别踩的坑（边界）：模型总结和页面提示不能独立证明完成——模型自己写一句"已完成"、页面上弹个"成功"提示，都不足以独立证明事情真的做成了。
落地检查：验收要位于执行链之外——落地时把验收机制放在执行链外面，由独立的机制确认，不能让"执行者自己给自己打分"。
落地可行性小结
本场景涉及的技术栈：Spec 八维审查（目标、事实、范围、对象、约束、异常、停止、验收），对应真实项目里的需求评审 checklist 和验收机制设计。落地动作：把八维做成一份固定审查清单，逐项过；对每一项关键要求都写明"由什么证据证明"（测试、工具回执、权威状态、人工判断四选一）。常见坑：一是只看文档章节齐不齐就放过；二是把所有失败都写成重试导致重复副作用；三是让模型总结当完成证据。检查点：目标是否还是原任务、异常是否有分类和停止条件、验收是否落在执行链之外。
回顾
- 先审目标、事实、范围，防止起点跑偏。
- 再审对象、状态、权限，明确业务规则落点和模型外执行边界。
- 异常要分类处理并有停止条件，不能一律重试（会制造重复副作用）。
- 验收必须映射到测试、工具回执、权威状态或人工判断，且要位于执行链之外。