refine-it

优化润色

工作流

1. 识别文档及其用途。

   • 根据提示和上下文，推断文档类型、受众、目的、预期语气和所需的修改幅度。
   • 如果请求指定了具体修改——修复、替换、添加、删除或更正——就将本次修改限定在该范围内；只有在用户要求开放式优化时，才进行更广泛的润色。
   • 保留明确的约束、事实陈述和决策。如果重组、合并、调整顺序或精简章节能让文档更清晰或更实用，就这样做。
   • 将操作性文本——触发条件、权限、标签、状态、API 名称、配置键、路由和资格规则——视为行为定义：润色措辞和分组，但绝不改变含义。
   • 如果意图确实模糊，只提出最少且必要的问题；否则，选择最能改善文档实际用途的修改幅度。

2. 重写前先评估。

   • 检查目的是否明确、结构是否薄弱、内容是否重复、措辞是否含糊、是否存在隐含假设、缺少背景、语气不符、过度声称或内容未完成——重写前，按这些标准评估每个章节。
   • 检查内容是否有充分铺垫：读者尚未接触某个概念，文本就已经依赖该概念，这是结构缺陷，通常可以通过调整顺序解决。判断单位是概念，而非词语——即便没有术语，段落也可能依赖读者尚不了解的观点。
   • 区分润色问题和策略问题。除非用户另有要求，否则应果断改进当前方向，但不要改变文档的目标、受众或操作行为。
   • 如果文档已经很好地满足其用途，只做轻微润色，或说明无需实质性修改；不要为了让修改看起来明显而凭空制造改动。

3. 直接优化和润色。

   • 提供更完善的版本，而不只是提出批评；除非用户只要求评审意见。
   • 删除填充内容和重复内容，选用具体的动词和名词，理清层级，让隐含的决策明确。判断一段内容是否值得保留，要看删掉后会有什么影响，以及它为读者带来了哪些前文没有提供的价值，而不是凭感觉决定。
   • 根据内容选择形式：论述用段落；真正并列的条目用列表；同类结构重复三次或更多时，表格才有价值；措辞本身是重点时，用引用。标题应点明要点，而不只是主题。
   • 精简前先找出需要保留的术语——领域术语、限定语、约束和有意采用的具体措辞——除非它们确实多余，否则应予保留。
   • 只添加能从现有文档中明确推导出的内容。
   • 对于指导执行者的文档——技能、运行手册、政策或 Agent 提示词——删去那些不改变行为、也不要求判断的语句：纯粹强调的内容，以及只是重复后续规则的理由。保留能帮助读者在缺乏指导时作出判断的理由。
   • 保留用户的表达风格；随意、直接或鲜明的措辞应维持原有语气，不要一概改成千篇一律的企业文风。
   • 如果工作流中的某条规则会让句子变差，就换一种方式修改，或者保留原句：规则应服务于读者。句子即使遵循所有规则，却读起来像机器写的，也算失败。

4. 完成交付。

   • 对润色后的版本进行最后一轮精简：在保留含义、语气和步骤 3 中明确补充内容的前提下，尽量采用最简洁的表述。
   • 如果用户很可能会直接使用最终版本，请将其放在最前面。
   • 对于较短的内容，除非备注有助于避免误解，否则只返回润色后的版本。对于较长的内容，使用 Final Version，后接可选的 Notes。
   • 仅在有用时添加简洁的备注，包括重大修改、假设、尚未解决的歧义、需要核实的说法，或已删除、重命名或精简的关键术语。
   • 如果要编辑仓库文件，请更新该文件并总结修改的文件。这只是文本编辑；不要运行代码检查、链接检查、构建或其他工具。

示例

修改前："为了能够利用此功能，用户需要先着手配置设置。" 修改后："要使用此功能，请先配置设置。" (删去冗余表达，选用具体动词，同时保留原意和直接的语气。)