交接文档不是需求原文，接手第一件事是回溯上游 · v1
一句话律：交接文档是转述。转述会丢信息、会掺进转述者的判断，而且读起来和原文一样确定。接手一项任务，第一件事是找到需求原文并与交接文档逐条对齐，而不是照着转述直接执行。
姊妹律：本条讲别人的转述读起来像原文； 约束型结论先复核律_文档写的不可能会过期_v1 讲自己写的结论读起来像事实。 两条的补救动作不同：前者回溯上游找原文，后者复核那句结论本身。
为什么这条容易被跳过
交接文档天生长着一副”权威”的样子：它有版本号、有”已确认的关键决策（封箱，不要再讨论）“这样的措辞、有踩坑清单和理由。它比原始需求文档读起来更像定论——因为原始需求往往只有一行冷冰冰的表格，而交接文档会告诉你”为什么”。
于是接手的人会跳过”找原文”这一步：文档都写得这么细了，还找什么原文。
问题在于，转述者写下”为什么”的那一刻，就已经掺进了自己的推断。而推断可能是错的。
实证
《Codex 保姆级教学》操作部分 26 条分镜，从上一个会话转手。交接文档「三、已确认的关键决策（封箱，不要再讨论）· 决策 3」写着：
332-338 是”输入提示词不发送”系列，每条必须独立展示自己的那一段提示词，不能累积前一段。
措辞是封箱级的，还附了理由（“这是上一轮被跳蛛先生点名的错误”）和知识库引用。我照此录完 7 条，机器校验和人眼抽帧都通过。
之后为了找素材，翻到交付目录里给同事核对用的 对位表.md——这才是需求原文：
3.3 | 镜号 332 | 输入提示词片段 1（不发送，文字累积） 3.10 | 镜号 339 | Codex 输入框缓慢滚动展示完整需求
完全相反。 而且三处证据一致指向”累积”才是原意：
- 对位表是给需求方同事核对用的，措辞就是「文字累积」；
- 逻辑自洽性：只有累积，339 的”滚动展示完整需求”才有东西可滚；
- 作者当天已独立裁定 339/340 要用完整七段——与”累积”自洽，与”每条独立”矛盾。
交接文档那条，大概率是转述者把知识库里另一个项目「05 段内容重复」的教训误套了过来：那次的错误是”上一条废弃 take 的残留混进画面”，和”设计上的逐条累积”根本是两回事，但表面现象都是”画面里出现了不止一段”。
代价：重录 7 条（约 3 分钟，因为脚本已成型，只需去掉”清空”那一步）。如果没翻到对位表，返工的是整集 12 条，而且要等到同事核对时才会发现。
第二个领域案例：前置音频修复（2026-09-07）
旧交接把前置耳机无声锁定为“系统更新破坏 OEM 驱动匹配”，要求继续下载驱动；本轮现场已是 Windows 11、新版且匹配的 Realtek 驱动、已安装控制台。重新检查后发现：输出端点存在，却被判为“未插入”。勾选“禁用前面板插孔检测”后，端点恢复可用，作者确认左右测试音正常。
该案补充了两条边界：
- 需求原文与现场状态分开核验。 前者解决“到底要什么”，后者解决“现在是什么”。即使需求没有变化，系统版本、安装状态与端点也可能变了。
- 功能恢复不倒推出唯一根因。 绕过检测有效，不等于证明系统更新是起因，或检测电路已损坏；“我的判断”即使标了类别，也不能据此封死其他可检验路径。
执行中的权限与目标冲突应向作者澄清；可直接测量的事实偏差则先测量、报告并修正，不必把每个版本差异都变成一次授权询问。旧失败日志继续帮助避免机械重试，但“不要重做失败操作”不等于“不要重新读取当前状态”。详见 2026-09-07_前置音频修复_插孔检测与交接复核复盘_v1。
操作规则
- 接手先问一句”需求原文在哪”，把交接文档和原文逐条对齐再动手。本例的原文就躺在交付目录里（
对位表.md），只是交接文档没提它是原文——它只在”参考文档”里列了知识库路径，没列需求方的核对表。 - 发现冲突时不要自己选一个执行。 把两边原文并列摆给决策人，附上自己的判断和理由，让他一句话定。本例裁决只花一次问答。自己选 = 把转述失真变成执行失真，且更难追溯。
- 带感情色彩的条款优先回溯。 “这是上一轮被点名的错误”、“封箱不要再讨论”、“血泪教训”——这类措辞读起来最像定论，也最可能是转述者的加工。路径、版本、分辨率等事实条款虽然容易核验，也会过期；会影响下一步决策的条目应先实测。
- 冲突暴露得越早越便宜。 对齐成本是分钟级，返工成本是小时级甚至整集级。
- 交接文档里的”事实”也要抽查。 同一份文档写”主屏 2048×1152”，实测是 2560×1440。事实条目会过期，而过期的事实不会自己声明过期。
边界
- 原文不可得时（口头需求、原始文档已丢失、需求方是上游的上游），交接文档是暂时可用的线索。把执行假设显式写出，不能把转述升级为作者授权，也不能用它覆盖现场证据；只有影响目标或权限的关键歧义才需要作者裁定。
- 这条不否定交接文档的价值。转述里的”为什么”和踩坑清单是真正省时间的部分——本例交接文档列的 6 个坑，有 4 个确实存在。要否定的只是”把转述当原文”这一步。
- 判别标准：这条信息是”事实”还是”判断”？ 会影响下一步动作的事实类（路径、版本、坐标、分辨率）先核验；判断类（应该怎么做、为什么这么做、哪条是错的）核对原文，并检验支撑判断的证据。
给交接文档写作侧的反向要求
本条同时是对 交接文档书写规范 的一条补充要求：
- 交接文档必须显式标注”需求原文在哪”，并把自己的条款分成「原文摘录」和「我的判断」两类；
- 转述原文时尽量保留原措辞，不要改写。本例若原样抄”文字累积”四个字，就不会有这次返工。
同族
- 跨阶段决策边界对位核验律_v1 —— 一体两面：那条是复审者视角（拉上一阶段边界，核验当前产物），本条是接手执行者视角（拉需求原文，核验交接文档）。共享同一个根因：跨阶段信息传递会失真，而失真处看起来和真的一样。
- Claude完成报告核查心法 —— 同族的”不能只看当前这一份文档”。
- 任务书制作与学员协作需求收口方法论_v1 —— 上游：任务书写作侧怎么减少歧义。
验证状态
两个领域案例：需求转述失真 + 现场状态过期。新增案例支持“接手需独立核验”的共同原则，不把不同失效机制混作完全相同的重复实验。
-
首验：Codex 教程操作部分 26 段重录（2026-08-13），交接文档「决策 3」与需求对位表完全相反，按转述录完 7 条后才发现
-
补充验证：2026-09-07 前置音频修复，非录屏域；现场复核纠正版本与驱动绑定前提，检测绕过后由作者试听验收。
关联文档
- 2026-09-07_前置音频修复_插孔检测与交接复核复盘_v1（现场状态过期与根因假说未证实的修复案例）
- 2026-08-13_Codex教程操作部分_26段重录复盘（本律来源案例）
- 交接文档书写规范（写作侧规范，本律对它提出补充要求）
- 跨阶段决策边界对位核验律_v1（同族：复审者视角）
- Claude完成报告核查心法（同族：跨文件交叉核验）
- 绿勾只覆盖它自己那张清单_v1 —— 强同构:那条是转述层生成的清单查不出与原文的偏差,本条是实现层生成的清单查不出与意图的缺口
- 破坏性操作先写停止条件律_v1 —— 镜像面:本条是接手方视角(转述不可信,先回溯上游),那条是交出方视角(交出不可逆操作时,停止条件比步骤更重要)
- 04_方法论与洞察索引