agentleFS
70asunflower70asunflower/70asunflower-skills/doc-plain-zh/SKILL.md

doc-plain-zh

Skill1 starsChanged 13 days agoMITView on GitHub

中文文档可读性转换(拗口 → 通顺,保正式·保逻辑·保事实)。当用户说文档"拗口、 读起来费劲/吃力、太书面、翻译腔、看不懂、改通顺、提升可读性、语言风格转换"时使用。 核心承诺:只改表达、不改内容——保持书面正式性,不改变文章逻辑与事实,不添加比喻、 类比、情绪或口语化用语。 与 humanizer-zh 的分工:humanizer-zh 负责长文交付前的去 AI 味润色(保留事实、 确定程度与语域,不强行口语化);本技能负责可读性工程(保书面正式,只解决拗口)。 两者可先后使用(先改通顺再去 AI 味),互不替代;长文草稿过 humanizer-zh 是全局 规则(见 AGENTS.md),与是否用本技能无关。

The file

Files
SKILL.md

中文文档可读性转换(doc-plain-zh)

把拗口的正式文档改写成"正常人能读懂"的版本——通顺、直接、不费劲,但依然是正式书面语。

一、铁律(优先级最高,违反任何一条即为失败)

  1. 事实不动:数字、日期、人名、机构名、专有名词、数据、引用、结论,一个字不改。
  2. 逻辑不动:因果/转折/并列/递进关系不变;段落顺序与章节结构不变。
  3. 信息不减:只改表达方式,不删除、不合并信息点;改写 ≠ 摘要。
  4. 不加戏:不添加比喻、类比、故事、情绪、口号;原文没有的意象一律不加。
  5. 保正式:保持书面语体。可更直接,但禁止网络口语、俏皮话、夸张词("贼快""拉满""天花板")。
  6. 术语保留:专业术语不"翻译"成大白话("Transformer 架构"不写成"转换器架构")。术语过密、超出目标读者承受力时,可加简短括注缓冲;默认不删不改术语本身。
  7. 最小改动:能改词不改句,能改句不动段落结构。宁保守,勿炫技。
  8. 结构元素不动:代码块、公式、命令行、表格中的数据单元格、链接、图片、引用出处一律原样保留,只改正文叙述性文字。

二、拗口病速查(详细诊断标准见 references/01-拗口类型诊断.md)

#拗口病一句话特征
1长句套嵌单句 >40 字,多层"的",从句连环
2名词化堆砌"进行了分析/实现/讨论"→ 本该是动词
3被动滥用"数据被采集后,被用于……"
4翻译腔/欧化"值得注意的是""在……的情况下""作为一个……而言"
5术语无缓冲术语连续密集出现,无一句"人话"过渡
6冗余虚词"相关/有关/进行/予以/加以/一定程度的"
7逻辑隐藏硬堆"此外/然而/同时",因果转折要靠读者猜
8复合定语超长"基于深度学习的面向长尾分布的推荐系统优化方法"

三、工作流(5 步,逐项执行)

  1. 通读:读全文,先抓住整体逻辑结构(不要边读边改)。同时确认改写范围(整篇还是选中段落)与交付形式(对话内输出还是写入文件)。
  2. 诊断:按上面 8 类,逐段标注拗口点(记录位置 + 类型 + 原因)。跳过代码块、公式、表格数据等结构元素(见铁律 8)。
  3. 改写:逐条改写,保持原段落结构。技法见 references/02-改写技法.md。
  4. 校验:对照第一节 8 条铁律逐项核查(事实抽查、逻辑比对、信息点计数)。发现原文疑似笔误/数据错误时,不擅自改,单独标注提请用户确认(见 references/03-红线与自检.md 问答)。
  5. 交付:改后全文 + 改动对照表(见第四节)。对照表中如含"事实修正"类改动,必须与语言改写分开标注。

四、输出格式(默认双件套)

  1. 改后全文:完整可用的文档(保留原标题/章节层级)。
  2. 改动对照表(文末或单独 section):
    | 位置 | 类型 | 原文 | 改后 | 理由 |
    只列实质改动(用词/句式变化),纯标点、格式微调不列。

用户只要"改完的文档"时,可省略对照表;但只要用户没明确说省略,默认给对照表(保证可追溯,符合"内容真实性不能改变"的诉求)。

五、交付前自检清单(逐项打勾)

  • 全部数字/日期/专名与原文一致(抽样核对)
  • 代码块、公式、表格数据、链接原样未动(铁律 8)
  • 段落顺序、标题层级、逻辑连接词含义未变
  • 未新增任何比喻/类比/情绪/观点/口号
  • 信息点数量 ≥ 原文(无删减)
  • 无网络口语、无夸张词、无随意化表达
  • 术语未替换成非标准说法
  • 每处实质改动都能对应到 8 类拗口病之一

六、与 humanizer-zh 的分工

  • 本文档(doc-plain-zh):先做。解决"读起来费劲",产出仍为正式书面语。
  • humanizer-zh:可选后置。只在你明确想要"更有人味/更随意"时再用(它会降正式度、加个性,默认不用)。

七、参考文档

  • references/01-拗口类型诊断.md —— 8 类拗口病的详细诊断标准与例句
  • references/02-改写技法.md —— 每类拗口病的改写技法与前后对照
  • references/03-红线与自检.md —— 边界案例:什么绝对不能改
  • examples/demo.md —— 完整工作示例(诊断→改写→校验→对照表)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.