Prose & Gap Polish

通过五步编辑与逻辑审查工作流,将粗糙的技术文档和脚本转化为清晰、简练且内容丰富的草稿。

worldwonderer
2026年10月16日
0 收藏
48 下载

安装与下载

1 ClawHub CLI

从源直接安装技能的最快方式。

npx clawhub@latest install prose-gap-polish

2 手动安装

将技能文件夹复制到以下位置之一

全局模式 ~/.openclaw/skills/
工作区 {'/skills/'}

优先级:工作区 › 全局 › 内置

3 提示词安装

将此提示词复制到 Openclaw 即可自动安装。

请帮我使用 Clawhub 安装 skill-prose-gap-polish。如果尚未安装 Clawhub,请先安装(npm i -g clawhub)。

更倾向于下载?

获取包含原生技能文件的ZIP压缩包。

下载技能 (.zip)

基本信息

名称 Prose & Gap Polish
Slug prose-gap-polish
创建者 worldwonderer
创建时间 2026-10-16 05:51:07
更新时间 2026-10-16 05:51:07
收藏数 0
使用量 48
浏览量 2

安装指南

  1. ClawHub CLI 从源直接安装技能的最快方式。
    npx clawhub@latest install prose-gap-polish
  2. 手动安装 将技能文件夹复制到以下位置之一
    全局模式
    ~/.openclaw/skills/
    工作区
    /skills/
    优先级:工作区 > 本地 > 内置
  3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
    请帮我使用 Clawhub 安装 prose-gap-polish。如果尚未安装 Clawhub,请先安装(npm i -g clawhub)。
    更倾向于下载?
    获取包含原生技能文件的ZIP压缩包。
    下载技能 (.zip)

什么是

Prose & Gap Polish 是用于技术提案、演示脚本、产品设计文档和回顾报告的 Openclaw Skills 文档编辑工作流。它通过合并破碎的句子、用具体语言替换内部术语,以及删减防御性解释、自指性评论和不必要的脚注来提高可读性。
该技能不仅审查风格,还审查含义和推理。它会检查模棱两可的引用、缺失的上下文、不一致的术语、数据和时间线的不匹配,以及因果逻辑中的漏洞。当项目文件或其他真实来源可用时,它会使用这些文件来核实事实,而不是凭空捏造缺失的细节。

应用场景

润色技术提案,使没有项目背景的读者也能理解其架构和假设。
完善读起来像零散笔记或依赖内部简写的演示脚本或产品设计文档。
删去重复的免责声明、元评论、过多的括号以及掩盖核心业务逻辑的实现细节。
找出不明确的代词、模棱两可的修饰语、不一致的术语或不断变化的统计定义。
识别缺失的项目上下文、未解释的数据输入或不熟悉的系统和概念。
审核文档中矛盾的数字、错误的计算、颠倒的时间线以及图表、表格和正文之间的不匹配。
在与利益相关者分享 AI 生成或协作编辑的草稿之前对其进行审查。

工作原理

合并片段并澄清语言: 将相关的短句合并为连贯的散文,恢复缺失的主语和动作,并用具体的措辞替换发明术语、未解释的缩写和套话。
精简分散注意力的内容: 删除重复的防御性免责声明、自指性评论、冗余脚注、过多的括号以及过早的过度工程,同时保留重要的业务规则。
解决歧义: 检查代词、修饰语边界、平行结构、术语和统计分母,以便读者准确识别每个陈述的含义。
弥补信息缺口: 从项目新人的角度进行阅读。寻找未解释的系统、人员、事件、业务规则和数据输入;查阅可用的项目来源以核实事实并添加简洁的上下文。
修复逻辑和一致性: 检查架构选择、现有功能的重用、计算、阈值、年代顺序、因果关系,以及正文、图表和表格之间的一致性。
应用并报告更改: 在有工作文件可用时,在目标文档中进行编辑并运行任何提供的验证脚本。按项目上下文和架构、移除的杂物、修复的缺口以及语言或图表改进来总结关键更改。

配置指南

该技能中未指定任何软件包安装、CLI 命令或专用配置。使用时,只需让兼容的编码 agent 将 Prose & Gap Polish 应用于文档即可。提供草稿,并在需要事实核对时提供对相关项目文件或其他真实来源的访问权限。

此技能未定义任何安装或 CLI 命令。

如果文档是包含验证脚本的项目的一部分,则该技能的输出指导是在进行编辑后运行相关的提供检查。

数据架构

该技能未定义必需的输入格式、元数据分类、生成的文件布局或持久数据架构。它对用户提供的目标文档进行操作,并可以查阅可用的项目来源(例如代码、数据库、任务工件和历史文档)来验证上下文和事实。
项目 工作流中的角色
目标文档 要编辑的草稿,例如技术计划、脚本、设计文档或回顾报告。
项目真实来源 用于验证系统行为、字段定义、业务规则或历史上下文的可选参考。
支持图表和表格 与正文进行比较,以识别不匹配的节点、图形或描述。
验证脚本 编辑后运行的可选项目提供检查;未规定特定的脚本或输出格式。
更改摘要 围绕项目上下文和架构、移除的杂物、修复的信息和逻辑缺口以及语言或图表改进组织报告。

高级特性

五轮审查:
将语言质量、简练性、歧义性、上下文完整性和逻辑一致性分为不同的编辑维度。
真实来源验证:
指导 agent 在填补事实空白之前检查可用的代码、数据库、任务工件或历史文档。
零背景读者测试:
评估不熟悉先前讨论、仓库或源材料的读者是否能理解该文档。
跨工件一致性检查:
将正文与图表、流程图、表格和数字定义进行比较。
技术推理审查:
检查架构重用、不必要的复杂性、计算、阈值、年代顺序以及因果关系链接。
直接文档编辑:
当 agent 有权访问目标文件时,工作流要求将修改应用于该文档并运行可用的验证检查。
结构化更改报告:
引导 agent 按类别报告编辑内容,以便用户审查内容更改和可读性改进。


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

文档与逐字稿五步深度精修(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 步:排查并消除歧义句

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

代词与省略指代歧义:
当一句话前文出现了两个以上人物、系统或数据集时,后半句的「他 / 她 / 它 / 这 / 两者 / 对应项」必须点名具体对象。
并列与修饰边界歧义:
检查「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 表格与正文叙述,确保图表节点与正文模块一一对应、数字口径前后一致。
输出规范

完成精修后:

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

No Black Box

发布说明撰写