文案与方案五步精修

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

pitechen

@worldwonderer

Install

$ openclaw skills install @worldwonderer/prose-gap-polish

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

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


核心工作流(五步精修法)

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

精修进度清单:
- [ ] 第 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 步:排查并消除歧义句

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

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

第 4 步:排查并补齐信息断点(Information Gaps)

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

排查四类高频信息断点

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

补齐原则

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

第 5 步:排查并修复逻辑断点(Logical Gaps)

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

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

输出规范

完成精修后:

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

Top skills in this category