文案与方案五步精修
对技术方案、宣讲逐字稿、产品设计文档或复盘报告执行五步深度精修:(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;并列取平均名次;同分优先最近出现……」 - 「以临时文件写完后原子重命名的方式写入……若文件损坏则写空信号文件并记录任务事件,绝不阻塞日常生产……」
- 在每一章末尾都重复一遍「社媒评论仅作参考,所有事实必须以本集反求为准」「无需人工手填」「不再另建独立文件」。
- 「若无有效百分位则记 0;无有效评论则记 0;平台接口未返回的字段记
- 改法:同一条核心原则全篇只在一个最关键的位置讲透一次;代码层的常规工程卫生(如原子写文件、字段
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叫模式),必须在同场出现时用不同定语区分。
- 同一份文档里如果同一个词指代不同层级的东西(如既把 T1/T2 叫模式,又把
- 统计口径与分母切换歧义:
- 同一段里连续出现多个百分比或分子分母时(如先按「打回原因」算占比 84.7%,紧接着按「项目声音处理方式」算打回率 33.4%),必须在切换处点明统计维度与分母基数。
第 4 步:排查并补齐信息断点(Information Gaps)
核心判据:假设读者没看过业务原片、没读过代码仓、没参加过前序讨论,从第一行顺读到最后一行——凡是突然冒出一个未交代来龙去脉的人物、事件、现有系统模块、公式变量或业务规则,就是信息断点。
排查四类高频信息断点
- 与现有项目/系统的关系断点:
- 新方案是凭空新建一套系统,还是长在现有流水线上?必须先讲清现有项目已经做到哪一步、有哪些现成资产与模块,再点明新方案在哪个节点切入、复用了什么、补齐了哪块短板。
- 业务背景与跨模块关联断点:
- 为什么在一个讲 A 的方案里同时改起了 B?(点明两者的业务耦合关系,如做外部效果归因前必须先在内部审片台把打回原因拆清)。
- 上下游数据流断点:
- 方案里提到的输入数据从哪来、长什么样?(如提到「与本集反求对上」,需点明剧本反求已产出带角色名、时间码的分场剧本、多语种官方字幕与逐镜描述)。
- 人物身份与剧情前情断点(针对案例/逐字稿):
- 案例中出场的人物是谁、与主角什么关系?提到的事件具体在演什么?为什么选它或淘汰它?
补齐原则
- 先查真值,绝不瞎编:若文档所在项目有代码仓、数据库、任务产物或历史文档,先用检索工具查清真实逻辑、字段定义或剧情原文,顺带揪出原稿里的事实错标。
- 嵌入式交代,不喧宾夺主:用简明扼要的架构对位或前置原因句把背景嵌进主线,不堆砌百科式废话。
第 5 步:排查并修复逻辑断点(Logical Gaps)
不仅要看「每句话通不通」,更要审视整条链路和方案设计本身合不合理、前后能不能自洽:
- 技术方案合理性与现有能力复用审查:
- 检查方案是否放着系统已有的结构化数据(如已有的剧本反求、台词本、镜头表、多语种字幕)或 AI Agent + Skill 能力不用,反而设计了繁琐低效的纯人工环节(如人工拉进度条标注时间码);若有,主动用自动化/Agent 链路替代人工瓶颈。
- 过度设计砍除与轻量化审查:
- 检查方案是否在一期还没跑通前,就设计了复杂的动态阈值状态机、多层缓存淘汰、繁琐的异常对账表或用不上的冗余字段;把超前设计果断收敛为简单直接的规则。
- 漏斗算术与门槛自洽审查:
- 用算术验算上下游数字是否对得上:上游每天采集/处理多少条?经过过滤后剩多少条?下游评分或触发阈值在上游吞吐量下能否真实凑够?
- 时序与因果顺序审查:
- 叙述顺序必须贴合真实执行时间线(先发生什么、再触发什么,切忌倒叙后再用「但」折返)。
- 表文一致与首尾呼应审查:
- 对照文档中的架构图、流程图、Markdown 表格与正文叙述,确保图表节点与正文模块一一对应、数字口径前后一致。
输出规范
完成精修后:
- 直接将修改落入目标文档(若有配套校验脚本,先跑通校验确认零报错)。
- 向用户汇报时,按**「项目现状衔接与架构取舍 → 去除防御性/元说明/过度设计 → 修复的信息与逻辑断点 → 语言与配图升级」**分类清晰列出核心改动。
Top skills in this category
Feishu Evolver Wrapper
@autogame-17(Depreciated: This skill is no longer maintained; its related functions have been absorbed by the Evolver main body.) Feishu-integrated wrapper for the capability-evolver. Manages the evolution loop lifecycle (start/stop/ensure), sends rich Feishu card reports, and provides...
Edge TTS
@i3130002Text-to-speech conversion using node-edge-tts npm package for generating audio from text. Supports multiple voices, languages, speed adjustment, pitch control, and subtitle generation. Use when: (1) User requests audio/voice output with the "tts" trigger or keyword. (2) Content needs to be spoken rather than read (multitasking, accessibility, driving, cooking). (3) User wants a specific voice, speed, pitch, or format for TTS output.
Google Ads
@hith3shInspect Google Ads accounts and campaigns, run GAQL reports, and coordinate campaign or audience changes with confirmation via the Google Ads API. Use this s...
Google Analytics
@hith3shRun GA4 reports, inspect properties, list audiences and data streams, and analyze traffic and conversion data via the Google Analytics Data API. Use this ski...
Figma
@maddiedreeseProfessional Figma design analysis and asset export. Use for extracting design data, exporting assets in multiple formats, auditing accessibility compliance, analyzing design systems, and generating comprehensive design documentation. Read-only analysis of Figma files with powerful export and reporting capabilities.