#writing #prose-polish #clarity #logic-review

文案与方案五步精修

对技术方案、宣讲逐字稿、产品设计文档或复盘报告执行五步深度精修：（1）合并电报体短碎句并消除自造词与套路句；（2）去除防御性说明、元说明与多余注脚，砍掉过度设计与非干货啰嗦；（3）排查并消除指代、修饰边界与同名概念歧义；（4）站在零背景读者视角排查并回查真值补齐信息断点；（5）排查前后矛盾、时序倒流、表文不一、算术漏斗死锁等逻辑断点。当用户要求润色方案、检查信息断点与逻辑断点、精简防御性废话、消除短碎句与自造词时使用。

pitechen@worldwonderer

Install

openclaw skills install @worldwonderer/prose-gap-polish

文档与逐字稿五步深度精修（Prose & Gap Polish）

把一份「只有作者自己看得懂、句子碎成电报体、塞满防杠补丁与括号注脚、夹杂内部自造词、存在上下文断档或前后逻辑漏洞」的初稿，打磨成零背景读者也能顺畅读懂、句式自然干练、直奔核心干货、事实与逻辑严密自洽的专业定稿。

核心工作流（五步精修法）

收到待优化文档后，按以下五个维度依次扫描、核查真值并改写：

text

精修进度清单：
- [ ] 第 1 步：合短碎句 + 去自造词与套路句（语言质感）
- [ ] 第 2 步：去防御性说明、元说明与多余注脚（干货提纯）
- [ ] 第 3 步：消歧义句（指代、范围、同名概念、分母口径）
- [ ] 第 4 步：补信息断点（零背景读者视角 + 回查后台/代码真值）
- [ ] 第 5 步：修逻辑断点（时序顺叙、因果衔接、表文一致、漏斗闭环）

第 1 步：合短碎句 + 去自造词与套路句

1.1 治理「电报体」短碎句

初稿常见毛病是「十来个字就断句、两三句独立成段、句与句之间省略主语和逻辑连接词」，读起来一惊一乍、像罗列备忘录。

合并同类项：将属于同一因果链、同一操作步骤或同一对比维度的两到四句短碎句，用自然的因果、递进、条件或转折关系融合成有呼吸感的完整句。
补全主谓宾与动作主体：避免满篇无主句（如「到时保存已确认的标签，未完成的源窗留空」→ 明确写出由谁在什么条件下触发什么动作）。
控制长句边界：合并短碎句不等于堆砌定语从句；每句话围绕一个重心推进，长句内部用分号或破折号自然换气。

1.2 消除自造词、内部缩写与公文黑话

作者常把代码变量名、口头简称或生造的四字复合词直接写进文档，外部读者甚至跨组同事根本猜不出原意。

拆解生造复合词：看到「到龄回收」「源窗储备」「净高光」「正向证据」「负向排他」「母版共用」「二改发布」「热点信号冻结」「关键帧联系图」「跨账号共振度」这类自造词，一律还原成具体动作与事实（如「到龄的 72 小时回收」→「发布满 72 小时后的播放数据回收」；「源窗」→「原片起止时间区间与镜头号」；「热点信号冻结」→「生成本集热点清单」；「关键帧联系图」→「镜头抽帧拼图」；「跨账号共振度」→「多账号重合度」）。
解释内部模块代号：首次出现内部概念（如「反求」「主控」「校准」「避开段」）时，直接用半句话说清它做什么，不让读者猜黑话。
外文原句附中文对照：在中文方案或逐字稿中引用外文标题、外文评论或外文台词时，紧跟括号或换行附上自然准确的中文翻译，避免读者因跨语种阅读中断理解。
禁用生硬套路句式与公文词：
- 严禁机械套用「不是……而是……」「不在……而在……」「讲的不是……」等二元对立句式（直接正面说清楚是什么、怎么做）；
- 删掉「赋能、沉淀、抓手、打法、心智、推成、防御、依据此项」等生硬公文腔或机翻腔。

第 2 步：去除防御性说明、元说明与多余注脚（干货提纯）

AI 生成稿或多人改过的方案极易长出大量「防杠补丁」「作者旁白」与「实现边角料」，把真正有价值的业务主线淹没在细枝末节里。精修时必须大刀阔斧砍掉以下三类赘肉：

2.1 砍掉「防御性说明」（Defensive / CYA Clauses）

特征：为了防止极端边界情况被挑刺，在正文里反复罗列 null 兜底、空值处理、异常分支、幂等细节，或把同一条原则换着花样重复叮嘱三四遍。
典型坏例：
- 「若无有效百分位则记 0；无有效评论则记 0；平台接口未返回的字段记 null；并列取平均名次；同分优先最近出现……」
- 「以临时文件写完后原子重命名的方式写入……若文件损坏则写空信号文件并记录任务事件，绝不阻塞日常生产……」
- 在每一章末尾都重复一遍「社媒评论仅作参考，所有事实必须以本集反求为准」「无需人工手填」「不再另建独立文件」。
改法：同一条核心原则全篇只在一个最关键的位置讲透一次；代码层的常规工程卫生（如原子写文件、字段 null 缺省、并列名次折算、缓存过期清理）属于开发常识，从方案正文中直接删除，只保留真正影响业务决策的主链路规则。

2.2 砍掉「元说明」（Meta-commentary / Self-reference）

特征：作者跳出内容本身，解释「这段文字为什么写在这里、接下来要讲什么、为什么没采用另一套写法」。
典型坏例：
- 「后文反复出现这些词，先说清楚。」
- 「以下表格展示了……」「如前文第 X 节所述……」「注意这里不再另建文件，而是内嵌在……」
- 在方案里花大段篇幅解释「为什么本次删除了旧版的某个字段 / 为什么不叫某个名字」。
改法：直接给结论和设计，删掉一切对文档结构或修改历史的自我解说。方案面向的是当下要落地的架构，读者不需要看作者的改稿心路历程。

2.3 砍掉「多余注脚与括号赘述」（Redundant Footnotes & Parenthetical Clutter）

特征：一句话里塞进两三个括号，括号里又套解释、套代码路径、套例外情况，导致主干句被切得支离破碎；或者在表格/公式下方挂一长串细碎注脚。
典型坏例：
- 「集号、本地视频相对路径与 video_sha256（首次计算后缓存）必须匹配 local_media_asset（工作台本地媒资表）……」
- 为尚未落地的远期设想写一大段复杂的触发阈值、例外豁免和补偿公式（过度设计）。
改法：一句之内最多保留一处真正必要的括号说明；能融进主干句的直接融进主干，属于底层实现细节或过度设计的括号注脚一律删净。

第 3 步：排查并消除歧义句

逐段检查是否存在「作者以为只有一种意思，但读者能读出两种解释」的句子：

代词与省略指代歧义：
- 当一句话前文出现了两个以上人物、系统或数据集时，后半句的「他 / 她 / 它 / 这 / 两者 / 对应项」必须点名具体对象。
并列与修饰边界歧义：
- 检查「A 和 B 的 C」「保留 X 与 Y 混音」这类结构（例如「保留原声对白与配乐混音」会被误读为保留原片配乐，实意是「分离并保留原片演员对白，再与新换的配乐混音」）。
同名概念混用：
- 同一份文档里如果同一个词指代不同层级的东西（如既把 T1/T2 叫模式，又把 music_montage/dialogue 叫模式），必须在同场出现时用不同定语区分。
统计口径与分母切换歧义：
- 同一段里连续出现多个百分比或分子分母时（如先按「打回原因」算占比 84.7%，紧接着按「项目声音处理方式」算打回率 33.4%），必须在切换处点明统计维度与分母基数。

第 4 步：排查并补齐信息断点（Information Gaps）

核心判据：假设读者没看过业务原片、没读过代码仓、没参加过前序讨论，从第一行顺读到最后一行——凡是突然冒出一个未交代来龙去脉的人物、事件、现有系统模块、公式变量或业务规则，就是信息断点。

排查四类高频信息断点

与现有项目/系统的关系断点：
- 新方案是凭空新建一套系统，还是长在现有流水线上？必须先讲清现有项目已经做到哪一步、有哪些现成资产与模块，再点明新方案在哪个节点切入、复用了什么、补齐了哪块短板。
业务背景与跨模块关联断点：
- 为什么在一个讲 A 的方案里同时改起了 B？（点明两者的业务耦合关系，如做外部效果归因前必须先在内部审片台把打回原因拆清）。
上下游数据流断点：
- 方案里提到的输入数据从哪来、长什么样？（如提到「与本集反求对上」，需点明剧本反求已产出带角色名、时间码的分场剧本、多语种官方字幕与逐镜描述）。
人物身份与剧情前情断点（针对案例/逐字稿）：
- 案例中出场的人物是谁、与主角什么关系？提到的事件具体在演什么？为什么选它或淘汰它？

补齐原则

先查真值，绝不瞎编：若文档所在项目有代码仓、数据库、任务产物或历史文档，先用检索工具查清真实逻辑、字段定义或剧情原文，顺带揪出原稿里的事实错标。
嵌入式交代，不喧宾夺主：用简明扼要的架构对位或前置原因句把背景嵌进主线，不堆砌百科式废话。

第 5 步：排查并修复逻辑断点（Logical Gaps）

不仅要看「每句话通不通」，更要审视整条链路和方案设计本身合不合理、前后能不能自洽：

技术方案合理性与现有能力复用审查：
- 检查方案是否放着系统已有的结构化数据（如已有的剧本反求、台词本、镜头表、多语种字幕）或 AI Agent + Skill 能力不用，反而设计了繁琐低效的纯人工环节（如人工拉进度条标注时间码）；若有，主动用自动化/Agent 链路替代人工瓶颈。
过度设计砍除与轻量化审查：
- 检查方案是否在一期还没跑通前，就设计了复杂的动态阈值状态机、多层缓存淘汰、繁琐的异常对账表或用不上的冗余字段；把超前设计果断收敛为简单直接的规则。
漏斗算术与门槛自洽审查：
- 用算术验算上下游数字是否对得上：上游每天采集/处理多少条？经过过滤后剩多少条？下游评分或触发阈值在上游吞吐量下能否真实凑够？
时序与因果顺序审查：
- 叙述顺序必须贴合真实执行时间线（先发生什么、再触发什么，切忌倒叙后再用「但」折返）。
表文一致与首尾呼应审查：
- 对照文档中的架构图、流程图、Markdown 表格与正文叙述，确保图表节点与正文模块一一对应、数字口径前后一致。

输出规范

完成精修后：

直接将修改落入目标文档（若有配套校验脚本，先跑通校验确认零报错）。
向用户汇报时，按**「项目现状衔接与架构取舍 → 去除防御性/元说明/过度设计 → 修复的信息与逻辑断点 → 语言与配图升级」**分类清晰列出核心改动。