结构压缩不丢操作细节
AI 或 agent 很擅长把长章节、长 runbook、长交接说明压成表格。但“更短”不一定等于“更清楚”：如果压缩后丢掉输入、动作、验收标准、失败回退和证据字段，后续执行者会得到一张好看的摘要，却不知道下一步怎么做。
什么时候需要停下来检查
当一个 diff 同时出现下面信号时，不要直接按“精简成功”合并：
- 多个小节被压成一张表或一段 checklist。
- 示例、脚本、访谈问题、失败判断被删除，但表格只保留概念名。
- 原文有“怎么做”和“做到什么算完成”，新文只剩“做什么”。
- 提交信息使用“整理、压缩、优化结构”等宽泛描述，无法说明内容取舍。
结构压缩的核心风险不是少了字，而是少了执行所需的上下文。
五字段保真检查
压缩前后至少对照这五个字段：
| 字段 | 原文需要找到 | 压缩后需要保留 |
|---|---|---|
| 输入 | 谁提供什么材料、样本、路径或上下文 | 表格里明确输入来源，不只写“准备资料” |
| 动作 | 执行者具体做什么、按什么顺序做 | 动作词可执行，例如访谈、抽样、运行、发布、记录 |
| 验收标准 | 做到什么算通过 | 能回答“是否继续 / 缩小 / 停止” |
| 失败回退 | 条件不满足时下一步是什么 | 明确回到访谈、补证据、切换方向或停止 |
| 证据 | 需要留下什么可复核记录 | 命令输出、用户反馈、样本链接、记录表或 notebook 句子 |
如果任一字段在压缩后消失，这次改动就不是单纯结构优化，而是内容取舍，需要单独审。
路线压缩审查样表
当长路线图被压成表格时，可以先复制这张样表做只读审查。它不要求立刻改正文，而是把“保留了什么、丢了什么、下一步怎么拆”写清楚。
| 阶段 | 原文输入 | 原文动作 | 原文验收 | 原文回退 | 原文证据 | 压缩后状态 | 下一步 |
|---|---|---|---|---|---|---|---|
| 第 1-15 天 | 能力、行业、资产、可触达用户 | 画能力地图并筛 1 个方向 | 能找到 10 个潜在用户，7 天内能手工 MVP | 候选方向过多时只留 1 个 | 能力地图与方向选择记录 | 若表格只保留“选方向”，则缺输入和验收 | 补回能力地图字段或拆成 structure-only |
| 第 16-30 天 | 访谈对象与过去行为样本 | 做访谈并服务 1-3 个用户 | 用户能描述上次真实场景 | 证据不足时继续访谈，不做产品化 | 访谈记录、手工交付反馈 | 若只写“访谈验证”，则缺回退和证据 | 补 Next evidence needed |
| 第 31-45 天 | 手工交付过程 | 整理输入、处理、输出、反馈清单 | 能区分可自动化和必须人工判断 | 不愿付费则重审用户/痛点/表达 | 交付清单和收费反馈 | 若只写“标准化”，则缺判断标准 | 保留收费是否成立的判断 |
| 第 46-60 天 | 已验证的真实样本 | 做最小模板、脚本、工具或服务包 | 通过外部证据闸门 | 无真实人/样本/渠道反馈时停止加功能 | 发布前检查表、试用反馈 | 若只写“做资产”，则缺停止条件 | 把证据闸门留在同一阶段 |
| 第 61-75 天 | 目标用户所在平台 | 写 3-5 篇问题型内容并发布 | 发布到用户聚集处，不只发朋友圈 | 没反馈时换渠道或缩小问题 | 发布链接、评论、私信、报名 | 若只写“公开输出”，则缺渠道证据 | 补渠道与观察字段 |
| 第 76-90 天 | 前 75 天反馈 | 判断付费、持续使用、获客、复用和兴趣 | 大多肯定才加功能/提价/产品化 | 大多否定就换方向 | Continue / Narrow / Stop 记录 | 若只写“复盘”，则缺决策出口 | 补三态决策和下一条命令 |
样表里的内容不是固定答案，而是提醒 reviewer：压缩后的每一行都要至少能回答“输入从哪来、做什么、怎么算过、失败后退到哪里、证据留在哪里”。如果某个阶段只能回答两三项，就不要把这次压缩标成“纯结构优化”。
压缩后字段缺口标注格式
只读审查时不要只写“表格太短”或“细节丢失”。先把每一行压缩结果标成下面这种可复核格式，下一位 agent 才知道该补正文、拆提交，还是接受压缩：
Stage: 第 <N> 天 / <主题>
Kept: input=<yes/no/partial>; action=<yes/no/partial>; acceptance=<yes/no/partial>; fallback=<yes/no/partial>; evidence=<yes/no/partial>
Missing: <具体缺失字段，不写泛泛的“细节”>
Decision: accept compression / split structure-only / restore field / ask for evidence
Next safe command: <只读检查或最小编辑命令>判断规则：
input缺失时，优先补“谁提供什么材料、样本或上下文”，不要先润色动作词。acceptance缺失时，优先补“继续 / 缩小 / 停止”的判断标准，否则路线图会变成愿望清单。fallback缺失时，优先补“证据不足怎么办”，避免读者默认继续产品化。evidence缺失时，优先补记录位置，例如访谈记录、发布链接、命令输出、notebook 或 result log。- 两个以上字段缺失时，不要把压缩和内容删除放在同一提交里；先拆
structure-only，再决定是否恢复正文。
这一段尤其适合接手已有 dirty diff：它不要求修改原文，但能把“每一阶段缺什么”写成下一轮可以直接执行的拆分边界。
压缩表字段缺口示例
下面是把 90 天路线从六个小节压成六行表格时的只读标注示例。它的目的不是替正文做最终决定，而是让下一位 reviewer 先看清哪些行可以接受压缩、哪些行需要补回字段或拆出结构提交。
Stage: 第 1-15 天 / 能力盘点和方向选择
Kept: input=yes; action=yes; acceptance=yes; fallback=no; evidence=partial
Missing: 缺“候选方向过多时如何只留一个”的回退句；能力地图作为证据被压进动作，未明确记录位置。
Decision: restore field
Next safe command: 只读对照原小节的能力地图代码块，决定是否把“能力地图/方向选择记录”作为关键产出补回。
Stage: 第 16-30 天 / 访谈和手工验证
Kept: input=yes; action=yes; acceptance=partial; fallback=no; evidence=yes
Missing: 有访谈记录和手工交付证据，但缺“证据不足时继续访谈，不进入产品化”的回退。
Decision: restore field
Next safe command: 搜索同章外部证据闸门，把停止规则是否覆盖本阶段写成 review 结论。
Stage: 第 31-45 天 / 标准化交付
Kept: input=yes; action=yes; acceptance=yes; fallback=partial; evidence=yes
Missing: 原文“用户只喜欢但不愿付费时重审用户/痛点/表达”的回退被压成“用户愿意付费”，失败路径不够显式。
Decision: restore field
Next safe command: 若接管正文，补一句“不愿付费时先重审目标用户、痛点强度或价值表达”。
Stage: 第 46-60 天 / 第一版可复用资产
Kept: input=partial; action=yes; acceptance=yes; fallback=yes; evidence=partial
Missing: 输入只写“基于验证”，未明确真实样本或用户反馈；证据依赖下方外部证据闸门，表格内没有记录位置。
Decision: split structure-only
Next safe command: 保持“外部证据闸门”与本阶段相邻，避免表格移动后丢失停止条件。
Stage: 第 61-75 天 / 公开输出和找渠道
Kept: input=yes; action=yes; acceptance=yes; fallback=no; evidence=yes
Missing: 缺“没反馈时换渠道或缩小问题”的回退；渠道记录有保留，但观察窗口未写明。
Decision: restore field
Next safe command: 对照发布授权或单渠道发布 preflight，补渠道与观察窗口字段。
Stage: 第 76-90 天 / 复盘和选择
Kept: input=yes; action=yes; acceptance=yes; fallback=yes; evidence=partial
Missing: 有继续/换方向决策，但没有明确把判断写到 Continue / Narrow / Stop 记录或 notebook。
Decision: restore field
Next safe command: 补一个“把五问结论写成 Continue / Narrow / Stop”的证据出口。如果示例里出现三个以上 restore field，说明这次压缩不宜直接作为“审校/精简”提交。更安全的做法是先拆 structure-only，再逐行恢复缺失字段。
推荐拆分方式
1. structure-only: 只移动标题、表格和顺序，不删执行细节。
2. compression: 删除重复解释，但保留五字段保真检查。
3. content decision: 对确实不再需要的段落写明删除理由。不要把三步合成一个大 diff。合在一起时，reviewer 只能凭感觉判断“读起来顺不顺”，很难判断“还能不能执行”。
只读审查句式
Observed: <path> 把 <N> 个小节压成 <M> 行表格。
Kept: 输入 / 动作 / 验收标准 / 失败回退 / 证据 中保留了 <...>。
Missing: 压缩后缺 <...>，所以不能当作纯结构优化提交。
Next safe command: 先补回缺失字段或拆出 structure-only diff，再审内容取舍。这段记录适合写进 agent notebook、PR review 或书稿审校回执。它能把“我觉得删太多了”变成可复核的字段差异。
与 Format Churn 的关系
解决的是标点、空白、换行和表格化遮蔽内容变化的问题；本页解决的是压缩之后还能不能执行的问题。常见顺序是：
- 先隔离 format churn，避免标点和空白噪音盖住真实改写。
- 再检查结构压缩是否保留五字段。
- 最后才判断内容是否更好、更短或更适合发布。
如果前两步没有完成，不要把改动包装成“审校完成”。审校完成必须意味着下一位执行者仍然知道输入是什么、动作是什么、如何验收、失败后退到哪里、证据留在哪里。