方法论与洞察

交接文档不是需求原文，接手第一件事是回溯上游 · v1

一句话律：交接文档是转述。转述会丢信息、会掺进转述者的判断，而且读起来和原文一样确定。接手一项任务，第一件事是找到需求原文并与交接文档逐条对齐，而不是照着转述直接执行。

姊妹律：本条讲别人的转述读起来像原文；约束型结论先复核律_文档写的不可能会过期_v1 讲自己写的结论读起来像事实。两条的补救动作不同：前者回溯上游找原文，后者复核那句结论本身。

为什么这条容易被跳过

交接文档天生长着一副”权威”的样子：它有版本号、有”已确认的关键决策（封箱，不要再讨论）“这样的措辞、有踩坑清单和理由。它比原始需求文档读起来更像定论——因为原始需求往往只有一行冷冰冰的表格，而交接文档会告诉你”为什么”。

于是接手的人会跳过”找原文”这一步：文档都写得这么细了，还找什么原文。

问题在于，转述者写下”为什么”的那一刻，就已经掺进了自己的推断。而推断可能是错的。

《Codex 保姆级教学》操作部分 26 条分镜，从上一个会话转手。交接文档「三、已确认的关键决策（封箱，不要再讨论）· 决策 3」写着：

332-338 是”输入提示词不发送”系列，每条必须独立展示自己的那一段提示词，不能累积前一段。

措辞是封箱级的，还附了理由（“这是上一轮被跳蛛先生点名的错误”）和知识库引用。我照此录完 7 条，机器校验和人眼抽帧都通过。

之后为了找素材，翻到交付目录里给同事核对用的 对位表.md——这才是需求原文：

3.3 | 镜号 332 | 输入提示词片段 1（不发送，文字累积） 3.10 | 镜号 339 | Codex 输入框缓慢滚动展示完整需求

完全相反。 而且三处证据一致指向”累积”才是原意：

交接文档那条，大概率是转述者把知识库里另一个项目「05 段内容重复」的教训误套了过来：那次的错误是”上一条废弃 take 的残留混进画面”，和”设计上的逐条累积”根本是两回事，但表面现象都是”画面里出现了不止一段”。

代价：重录 7 条（约 3 分钟，因为脚本已成型，只需去掉”清空”那一步）。如果没翻到对位表，返工的是整集 12 条，而且要等到同事核对时才会发现。

接手先问一句”需求原文在哪”，把交接文档和原文逐条对齐再动手。本例的原文就躺在交付目录里（对位表.md），只是交接文档没提它是原文——它只在”参考文档”里列了知识库路径，没列需求方的核对表。
发现冲突时不要自己选一个执行。 把两边原文并列摆给决策人，附上自己的判断和理由，让他一句话定。本例裁决只花一次问答。自己选 = 把转述失真变成执行失真，且更难追溯。
带感情色彩的条款优先回溯。 “这是上一轮被点名的错误”、“封箱不要再讨论”、“血泪教训”——这类措辞读起来最像定论，也最可能是转述者的加工。中性的事实条款（路径、分辨率、工具版本）反而更可靠。
冲突暴露得越早越便宜。 对齐成本是分钟级，返工成本是小时级甚至整集级。
交接文档里的”事实”也要抽查。 同一份文档写”主屏 2048×1152”，实测是 2560×1440。事实条目会过期，而过期的事实不会自己声明过期。

原文不可得时（口头需求、原始文档已丢失、需求方是上游的上游），交接文档就是最高权威。此时应该反过来做：把自己的执行假设显式写下来，让它成为下一版的原文。
这条不否定交接文档的价值。转述里的”为什么”和踩坑清单是真正省时间的部分——本例交接文档列的 6 个坑，有 4 个确实存在。要否定的只是”把转述当原文”这一步。
判别标准：这条信息是”事实”还是”判断”？ 事实类（路径、版本、坐标、分辨率）可以先信后抽查；判断类（应该怎么做、为什么这么做、哪条是错的）必须回溯原文。

本条同时是对交接文档书写规范的一条补充要求：

跨阶段决策边界对位核验律_v1 —— 一体两面：那条是复审者视角（拉上一阶段边界，核验当前产物），本条是接手执行者视角（拉需求原文，核验交接文档）。共享同一个根因：跨阶段信息传递会失真，而失真处看起来和真的一样。
Claude完成报告核查心法 —— 同族的”不能只看当前这一份文档”。
任务书制作与学员协作需求收口方法论_v1 —— 上游：任务书写作侧怎么减少歧义。

⚠️ 初次发现 · 单案提炼

二次验证应当来自非录屏域的接手场景（例如接手别人的代码库、接手一次未完成的送审流程）。

类型/协作工具链主题/协作主题/交接主题/自动化