YunLab.ai CHAPTER 06 · 6.8–6.15
教材版本：v1.0 · 官方资料核验：2026-08-23 · 当前界面与账号可用性以读者实际状态为准。
6.8 形成完整说明版本
为什么
完整说明是负责人查看的版本。它不需要华丽，而要让人一次看清目的、已经整理的内容、未确认事项、截止时间和不能承诺的部分。
在 Codex 桌面端怎样做
在练习册的“完整说明模板”中，先粘贴输出配置和字段映射，再使用下面的请求。唯一输出写入个人练习册的完整说明区域：
请只读“我的第6章练习册.md”的事实底稿、完整说明配置和字段映射。
请生成“给负责人看的完整说明”，只能使用底稿事实，保留两项待确认事项、周四17:00、负责人角色、适用范围和不能作出的承诺。
输出必须标为“草稿，待人工验收，不发送”。唯一写入位置是完整说明区域。
不得新增事实、改变日期、替负责人做决定、发送或发布。
你应该看到什么
下面是一份与固定快照一致的完整说明示例：
负责人完整说明目的：把已经整理过的入职资料说明成便于负责人、团队和同事分别查看的草稿。
本轮已整理的四项资料：
- 入职说明草稿
- 工具清单草稿
- 常见问题草稿
- 第一周安排草稿
尚未确认的两项事项：
- 是否需要为每项资料增加责任角色。
- 是否需要把第一周安排拆成更细步骤。
本轮整理截止：周四17:00。 负责人角色：资料整理负责人。 适用范围：本次虚构练习中的四项共享资料整理，不扩展到其他资料。
不能作出的承诺：不能承诺资料已经最终批准；不能承诺第一周安排一定发生；不能承诺已经发送、发布或获得任何账号权限。
状态：草稿，待人工验收，不发送。
常见坑
- 为了让说明更完整，加入“负责人已经批准”。这不在底稿里，必须删掉并停止检查。
- 把“本轮整理截止”写成“培训开始时间”。两者不是同一字段，发现混用就回到底稿。
6.9 形成一页摘要版本
为什么
一页摘要给团队快速阅读。它可以少写解释，但必须保留四项资料、截止时间、两项待确认事项和草稿状态。
在 Codex 桌面端怎样做
使用同一份底稿和字段映射，不复制上一节的完整说明来删字。请求中明确唯一输出区域：
请只读“我的第6章练习册.md”的事实底稿、一页摘要配置和字段映射。
请生成给团队的一页进度摘要，只压缩表达，不改变任何事实和待确认状态。
必须保留四项资料、周四17:00、两项待确认事项和“草稿，待人工验收，不发送”。
只写入一页摘要区域，不改完整说明。
你应该看到什么
一页进度摘要目的：让团队快速了解本轮四项资料整理的进度，并保留需要人工决定的事项。
已整理：入职说明草稿、工具清单草稿、常见问题草稿、第一周安排草稿。 截止：周四17:00。 待确认：是否为每项资料增加责任角色；是否把第一周安排拆成更细步骤。 范围：只处理本次虚构练习中的四项共享资料。 限制：资料尚未最终批准；第一周安排不保证发生；本稿未发送、未发布，也不代表已经获得任何账号权限。 状态：草稿，待人工验收，不发送。
常见坑
- 为了省字，删掉“待确认”。预警是摘要看起来像最终通知。补救是恢复两项待确认事项。
- 把四项资料合并成“相关材料”。预警是读者无法知道整理了什么。补救是保留四个名称。
6.10 形成短消息草稿
为什么
短消息只是给同事看的请求草稿，不是发送动作。它需要说明来意、截止时间和需要确认的事项，不能把未确认内容说成结论。
在 Codex 桌面端怎样做
请只读“我的第6章练习册.md”的事实底稿、短消息配置和字段映射。
请生成一段给同事的短消息草稿，说明四项资料已经整理、截止为周四17:00，并请对方确认两项待确认事项。
必须写“草稿，待人工验收，不发送”，不要出现新的时间、姓名、地址或承诺。
只写入短消息区域。
你应该看到什么
请查看四项资料草稿：入职说明、工具清单、常见问题和第一周安排。本轮截止周四17:00；请确认是否需补充责任角色、细化第一周安排。范围不扩大，资料未批准，安排不保证发生；草稿待人工验收，不发送。
常见坑
- 自动加上“请今晚回复”。底稿没有这项要求，必须删掉。
- 把短消息直接粘到真实聊天窗口。预警是出现真实联系人或发送界面。补救是回到本地草稿，交付闸门前不发送。
6.11 在所有版本中保留事实、推断和待确认标签
为什么
同一事实在长文、摘要和短消息里都要保持同一种性质。尤其是“待确认”不能在短版本里消失，否则读者会误以为已经决定。
在 Codex 桌面端怎样做
在练习册的一致性表中加三列：信息性质、三个版本的说法、是否保持。要求 Codex 只做比较：
请只读“我的第6章练习册.md”里的底稿和三份草稿。
逐项标出事实、待确认事项和不能作出的承诺在三个版本中的说法是否一致。
只输出差异表，不改任何草稿；发现性质变化时停止。
你应该看到什么
“周四17:00”在三个版本中相同；两项待确认事项始终被标为待确认；不能作出的承诺没有被改写成保证。
常见坑
- 把“待确认”换成“计划”。预警是读者看不出谁还要决定。补救是恢复原标签。
- 把“草稿”只放在长文末尾。预警是短消息没有状态。补救是三个版本都保留草稿状态。
6.12 调整语气和篇幅时怎样防止事实漂移
为什么
调整语气只改变表达方式，不改变事实。负责人版可以完整，团队版可以简洁，同事版可以口语化，但三者仍必须来自同一底稿。
在 Codex 桌面端怎样做
把“允许改变”和“禁止改变”写在请求里：
请只读三份草稿和事实底稿。
允许：调整句子长短、段落顺序和语气，让三份稿分别适合负责人、团队和同事。
禁止：改变四项资料名称、周四17:00、两项待确认事项、负责人角色、适用范围和不能作出的承诺。
请先列出准备调整的句子，再等待人工确认；不要直接覆盖原稿。
你应该看到什么
你会先看到调整清单，而不是旧稿被覆盖。每个调整都能回到一个配置要求，事实字段没有变化。
常见坑
- 追求“更积极”而删除限制。预警是出现“保证”“一定”。补救是撤销这次调整，保留原稿。
- 让三份稿使用不同的截止时间格式并改变含义。补救是统一为“周四17:00”。
6.13 跨版本一致性检查
为什么
一致性检查就是把三个版本放在一起，对照同一组字段。它不负责判断事实是否真实，只负责确认三个版本没有互相矛盾。
在 Codex 桌面端怎样做
使用练习册中的矩阵，至少检查目的、四项资料、两项待确认、截止、负责人角色、适用范围、不能承诺和状态八项：
请只读“我的第6章练习册.md”中的底稿、字段映射和三份草稿。
按目的、资料、待确认、截止、负责人角色、范围、不能承诺、状态八项逐格比较。
输出“相同”“需要人工判断”或“冲突”，并附对应位置。不要修改文件，不要补写事实。
你应该看到什么
检查结果能指出每项字段在三份稿中的位置。若有“冲突”，你能说出是哪一行、哪一份稿，不只是得到一个总分。
常见坑
- 用“看起来差不多”代替逐项检查。预警是没有位置记录。补救是回到映射表逐格核对。
- 把一致性当成真实性。预警是说“大家都写一样，所以一定正确”。补救是保留“底稿仍待人工验收”。
6.14 实际打开与本地预览
为什么
文件能生成，不代表人打开后容易读。预览在本章只指离线地打开文件，或复制到自己的目标文件夹查看排版和内容，不代表已经发送或发布。
在 Codex 桌面端怎样做
先由人打开三份草稿，检查标题、段落、表格和中文换行。需要时把副本复制到自己的本地练习位置，再打开副本比较。可以让 Codex 只给预览检查清单：
请只读三份草稿，不要修改它们。
请列出人工打开或复制到目标位置预览时要检查的项目：标题、段落、表格、截止时间、待确认事项、草稿状态和文件名。
不要声称已经发送或发布。
你应该看到什么
人能打开文件，能找到三种版本，并能看清“周四17:00”“待确认”和“草稿，不发送”。如果文件打不开或内容被截断，应停止交付。
常见坑
- 把 Codex 的文字回复当成预览。预警是没有人打开文件。补救是由人实际打开个人副本。
- 把复制到目标位置当成发送。预警是出现真实渠道。补救是只复制到本地练习文件夹，交付闸门前不外发。
6.15 组装交付包
为什么
交付包是让下一个人知道“看哪些文件、先看什么、现在是什么状态”的小集合。本章的交付包仍是草稿包，不是发布包。
在 Codex 桌面端怎样做
建立一个专用文件夹，把个人练习册、三份草稿、字段映射和检查表放进去。不要把原始输入、聊天记录或真实账号信息放入包中。请求 Codex 做只读目录清单：
请只读本地练习文件夹，列出文件名、用途、版本和当前状态。
不要移动、删除、重命名或新增文件；不要读取练习文件夹之外的内容。
列表中必须区分事实底稿、三份草稿、检查表和人工记录。
你应该看到什么
目录清单短而明确，能找到事实底稿、三份草稿和人工检查材料。没有真实发送凭证，也没有“已发布”文件。
常见坑
- 把交付包做成所有资料的备份。预警是包里出现无关原始文件。补救是按范围清理，但不要自行删除敏感资料，先停止并交给人处理。
- 只给出一个压缩包而不说明内容。补救是保留清楚的文件名和说明，不依赖隐藏结构。