中文自然表达终审

本 skill 用作中文报告、README、技术文档、科研进展记录、Markdown/PDF 成稿和面向读者的中文说明的普通润色、说人话处理和最后审校。目标不是把文字改得随意，而是让它清楚、真实、符合中文读者习惯，并且不像模型套话。

这不是事实核查、文件转换、AI 检测规避或伪原创工具。它只处理中文读者看到的表达质量：在 writing-fidelity 的保真底线之上，把机器味、翻译腔、模板腔和不必要英文降下来。

产品界面里的短文案不是本 skill 的主路线。按钮、标签、空/加载/错误/成功状态、设置页帮助、onboarding、权限提示、信任/隐私说明、landing-page interface block 或 zh-Hans / zh-Hant-HK UI microcopy，应交给 product-ui-copy；本 skill 只在这些文案已经进入文档、报告或 README 语境时处理文档型说明。

如果用户给的是已有中文或中文为主的科研/技术材料，并要求重新组织、结构性重写或文档级重写，同时要求保留事实、数字、公式、引用、比较条件、限制、路径、配置或命令等精确信息，不要把本 skill 当主路线；应交给 scientific-rewrite。本 skill 只在该重路线内部承担 REALIZE_MEANING 中文实现角色，或在最终候选稿生成后做自然表达终审。

使用场景

• 用户要求中文文字更自然、更少 AI 味、更少翻译腔、更少口号化，或更适合中文读者。
• 用户要求“中文为主”“说人话”“人能看懂”“能讲”“别像 audit/控制台/任务合同”“组会汇报”“汇报用”。
• 用户要求“别每句话一个 bullet”“别机械三点式”“用正常段落写”“普通英文能翻成中文就翻掉”。
• 用户没有明确说“说人话”，但输出目标是中文 Markdown、中文 PDF、中文报告、中文 README、中文终稿或面向用户/作者/读者的中文说明。
• 修改中文报告、README、项目文档、科研更新、基金/项目摘要或技术说明。
• 检查中文草稿是否在保留事实的同时去掉套话。
• 将中英混杂的技术文字改成稳定的中文文档风格。
• 中文技术文档、报告、README 或提示词里出现大量非必要英文，需要改成中文为主、只保留必要英文。

明确排除：已有科研/技术材料的 source-faithful structural rewrite。只要任务同时具备“已有中文或中文为主的科研/技术材料”“要求重新组织或结构性重写”“要求保留事实、数字、公式、引用、比较条件、限制、路径、配置或命令”等精确信息，应 hand off 给 scientific-rewrite，不要停留在本 skill 的普通润色路线。

也明确排除产品界面微文案：如果用户要求改按钮、CTA、字段标签、界面状态、设置页帮助、权限/信任/隐私披露、浏览器插件 popup、桌面/WebView 设置页、移动端/Compose 页面中的短文案，优先 hand off 给 product-ui-copy。不要因为文本是中文就留在 chinese-prose。

不要用本 skill 做事实核查、逐字翻译、模仿品牌文案，或改写代码、日志、命令。单纯渲染中文 PDF、检查字体或转换格式时，本 skill 作为成稿可读性验收配合使用，不替代 PDF/文档工具。

也不要把本 skill 用成 humanizer、AI detector evasion 或隐藏 AI 来源的工具。可以减少套话和模板腔，但不能伪装来源，不能删除真实 limitation，不能为了自然而改掉证据边界。

核心规则

先保真，再自然。中文为主，必要英文才保留。

正文优先用连贯段落。列表只在步骤、并列比较、验收清单、证据清单、组会提纲或确实需要快速扫描时使用。不要为了显得结构化把每句话拆成 bullet，也不要把一两句话拆成一个小标题。不要强行凑三点式、对称排比、重复总结或固定“首先/其次/此外/综上”。

对于明确授权的 heavy scientific rewrite，列表、表格和公式拆解可以是正文结构的一部分，不按“少用列表”机械压回长段。判断标准不是候选稿更短，而是读者能不能少做跨段推理、少猜英文普通词的中文关系、少在公式和结论之间来回跳。

REALIZE_MEANING

REALIZE_MEANING 是 scientific-rewrite heavy Chinese rewrite 路线调用的中文实现模式。它不直接读原文段落来改写，而是把已经固定的 Meaning Map / Reader Plan / exact item 变成读者能顺着读的中文。

正式 drafting input surface 只能包含：

• audience / register；
• bundle purpose / reader question；
• relevant meaning records；
• relevant relation records；
• required exact item identities/formulas；
• neighboring bundle purposes/dependencies；
• information shape；
• optional structured repair instruction。

公式和数学关系必须写成读者能渲染、能理解的数学表达。源材料里如果用
plain text、wiki block、inline code 或 text fence 写公式，REALIZE_MEANING
要把它转成行内或展示 LaTeX 数学，并在附近说明符号含义。不要为了“逐字保留”
把公式放进 fenced code block、inline code span、text block、quote block 或
token 清单；这种输出不是合格的读者正文。代码 fence 和反引号只用于真实代码、
命令、API、配置或机器 token。数学函数和复杂度表达要用正常 LaTeX 记法，例如
$O(n \log n)$、$O(N \log N)$、$(N/2) \log_2 N$，不要写成反引号里的
O(n log n)，也不要写成会把 log 渲染成相邻变量的 $O(n log n)$。

不得把以下内容作为写作输入交给本模式：raw source paragraph/sentence、source excerpt、source quotation、source tail/preview、Latin-span inventory、QA ledger、exact_identity/useful_recognition/ordinary_reasoning 分类、literal seed rewrite template、previous rejected candidate、manual GPT reference output。

本模式可以做的中文实现操作包括：

• DIRECT_RELATION：把比较、因果、限制、下一步关系直接说清；
• QUESTION_FIRST：先回答读者正在追的问题；
• METHOD_MENTAL_MODEL：先给方法直觉，再保留正式方法名；
• FORMULA_WALKTHROUGH：先说公式回答什么，再给公式和符号含义；
• CLAIM_WITH_BOUNDARY：先给有边界的判断，再把 caveat 放近；
• DECOMPRESS_NOUN_STACK：把英文名词链拆成中文关系；
• PARALLEL_TO_STRUCTURE：把并列条件、方法或结果改成清楚列表/表格；
• REMOVE_INTERNAL_FRAME：去掉 reader-facing 正文里不该出现的审计、流程和任务标签。

如果 Meaning Map / Reader Plan 保留了引用或来源身份，REALIZE_MEANING
必须把它写成读者能理解的引用、出处说明或简短参考项；不得把 wiki / HTML /
导出 Markdown 的源站语法原样写进最终正文。{{sfnp|...}}、{{harvtxt|...}}、
{{cite ...}}、<ref>...</ref>、<references/> 这类模板和标签属于来源包装，
不是中文成稿的引用表达。除非用户明确要求保留源代码式标记，否则候选稿里不能出现。

当 scientific-rewrite 已经生成 Reader Plan 时，本 skill 的终审只读取最终候选稿和 Reader Plan，不回看源文档改写正文。终审必须确认：候选稿是否回答 Reader Plan 里的读者问题；英文残留是否分别属于精确身份、必要识别名或应该中文化的普通推理词；公式是否有中文语义说明；证据边界和不确定性是否仍在读者主线里。发现问题时返回需要返修的原因，不能用“整体更流畅”覆盖缺项。

除非用户明确要求，否则不要改动以下内容：

• 数字、日期、版本、范围、单位、百分比。
• 实验条件、指标、基线、表格/图片标签、p 值、样本量。
• 命令、代码、路径、文件名、参数、环境变量、错误、日志、API 名称。
• 配置键、字段名、表格列名、枚举状态、验证器 token、机器可读协议词。
• 指标名、模型名、算法名、数据集名、挑战赛任务名、产品名、模块名、项目名、人名、机构名、引用和引文。
• 责任和归因：谁做了什么、谁观察到什么、哪里仍然不确定。

如果一句话只有通过削弱事实才能更顺，就保留事实，接受少量生硬。

自动触发和验收门槛

凡是准备交给用户、作者、读者或组会听众看的中文 Markdown、PDF、报告、README、幻灯片文案、状态说明或技术说明，都要默认做本 skill 的终审。用户不需要显式说“说人话”。

终审失败时不能把成稿视为完成。失败包括：

• 第一屏或第一段先堆路径、字段、token、branch、命令、audit 记录、状态码或英文缩写，读者看不出结论。
• 普通工程英文词大段混在中文句子里，且不是受保护 token。
• 把审计记录、候选结果、草稿、预览、排行榜行或机器验收清单当成面向读者的结论。
• 中文 PDF/Markdown 的可见标题和开头没有回答“现在完成了什么或卡在哪里、为什么、下一步做什么”。
• 导师/组会材料在用户没有要求时，自动加入“30 秒版本”“3 分钟版本”“如果只有 X 分钟”“可以这样讲”等时间脚本或讲稿模板。
• 导师面对的科研报告把 audit: PASS、commit、job id、preflight、correction round 等内部执行状态提升为主叙事。
• 科研/技术重写候选稿把 Reviewed Handoff、Gate、Planner/Reviewer/Executor、
  Text Review、CI、commit、branch、GitHub Actions、results/、
  exports/private/、automation/reviewed_handoff/、.local-runtime/ 或
  CURRENT.json / RESULT.md / FINAL_REPORT.md 当作读者正文，而不是只在
  明确要求的审计/交接附录中出现。
• 科研/技术重写候选稿把 {{...}} wiki 模板、<ref>...</ref>、
  <references/>、HTML 标签或导出引用标记当作正文引用，而不是转成正常
  中文引用、出处说明或参考项。
• 科研/技术重写候选稿把复杂度、求和式、矩阵式、概率式等数学关系放在反引号、
  code fence、text block 或普通文本里，导致 PDF/HTML 不能按数学表达渲染。

如果触发的是中文成稿验收，第一段必须先给人能读懂的判断；证据路径、命令、字段、日志和机器状态放在后面的证据区或括号说明。

英文密度规则

中文报告、README、技术文档、科研说明和提示词默认中文为主。不要让普通概念堆满英文，也不要把英文当作技术感装饰。

是否保留英文靠语义判断，不靠禁词表。如果去掉英文不会损失准确含义、专业识别或机器定位能力，就优先写中文；如果它是专名、模型/指标、路径、代码、配置、精确状态、引用标题或必须匹配的外部 token，就保留英文。

只在以下情况保留英文：

• 路径、文件名、命令、环境变量、代码标识符、配置键、字段名、表格列名、枚举状态。
• 指标、模型、算法、数据集、挑战赛任务名和论文/软件专名，例如 Dice, HD95, nnU-Net, SyN, VoxelMorph。
• 必须与现有代码、验证器、协议状态、外部系统或引用文本精确匹配的词。
• 用户明确要求保留的英文。

普通概念优先中文化。常见替换包括：

• planner -> 规划者
• executor -> 执行者
• audit -> 审计 / 核查 / 验收
• reviewer / auditor -> 审阅者 / 评审者 / 审计者
• executor prompt -> 执行提示词
• reviewer prompt -> 审阅提示词
• same-split baseline -> 同一划分基线
• hard subgroup -> 困难子组
• fail closed -> 默认失败
• route promotion -> 路线晋级
• monitor packet -> 监控包
• commit -> 提交
• claim -> 主张
• gate -> 门槛 / 关口
• artifact -> 证据产物
• pipeline -> 流程
• candidate -> 候选结果 / 候选方案
• final artifact -> 最终产物
• leaderboard row -> 排行榜记录

定稿时不能用“这是 audit result / candidate / final artifact / pipeline status”这类英文普通词开头代替结论。先说明中文含义，再把英文 token 放入证据或括号。

定稿前扫描剩余英文。每个英文词组都要归入三类之一：受保护的精确 token、确实更清楚的技术名词、应该翻译的普通概念。不能归入前两类的，改成中文。

工作流程

1. 判断文本场景：report、README、docs、status、slides、pdf-final 或 public-writing。
2. 先标记受保护内容，避免误改事实、路径、命令、代码和字段名。
3. 判断修改幅度：
   • minimal：只去掉明显套话、标点问题和风格问题。
   • standard：按中文语感重写句子，但保留原结构。
   • structural：只有在文档结构混乱或用户要求重写时，才调整章节顺序。
4. 删除 AI 味表达。
5. 做英文密度检查：把普通英文概念改成中文，同时保留受保护的精确英文。
6. 检查第一屏：读者是否先看到判断、原因、下一步，而不是机器字段。
7. 套用中文技术文档习惯。
8. 复读一遍，确认事实没有被削弱、删除或拔高。
9. 输出一版干净文本。只有在存在过度主张、缺少来源、受保护事实限制修改，或刻意保留英文时，才补充简短说明。

场景规则

报告

用于中文科研报告、组会材料、进展总结和实验说明。

• 保留问题、证据、解释、不确定性和下一步。
• 开头先说判断，再说证据。机器字段、路径、命令、日志和英文缩写只能支持结论，不能替代结论。
• 不要把“观察到”改成“证明了”。
• 避免“具有重要意义”“为后续研究奠定基础”“展现出巨大潜力”，除非文本明确给出证据和边界。
• 下一步要具体，例如用“下一步先做分层复现”，不要写成“后续继续优化”。
• 不要把月份、轮次或内部阶段名当成读者需要接受的版本名。能写具体日期、最好指标、作者决定和证据路径时，就不要写“某月版”“旧日期行”“final 某某”这类含混标签。
• 面向作者或科研负责人的结论先说实际判断，再补内部字段、路径、状态 token 和英文定位词。报告开头不能像控制台记录、任务合同或机器验收清单。
• audit、review、candidate、draft、leaderboard row 这类英文普通词不能直接成为主结论。先用中文说明它们在当前任务里是审计记录、审稿意见、候选结果、草稿还是排行榜记录。
• 如果用户要求“说人话”，第一段必须回答：现在到底完成了什么或卡在哪里，原因是什么，下一步该做什么，暂时不该做什么。路径、字段、命令、状态 token 和英文缩写放在后面。
• 即使用户没有说“说人话”，只要交付的是中文报告、中文 PDF 或中文 Markdown 成稿，也按上一条执行。

组会 / 导师面对版本

用于组会汇报、导师讨论、实验复盘、研究方向判断和可以直接给 PI/老板阅读的中文材料。

• 默认目标是把科学问题、实验比较、证据边界和下一步决策讲清楚。不要自动把正常组会改写成演讲比赛或时间受限 pitch。
• 除非用户明确给出时间限制或要求口头讲稿，不得自动生成 30 秒版本、3 分钟版本、elevator pitch、如果只有 X 分钟、可以这样讲 或逐字稿。
• 按听众真正关心的问题组织：科学问题从哪里来、相关论文/方法提供了什么思想、为什么不能直接用、最终实验怎么比较、结果是什么、哪些解释成立、下一步要确认什么。
• 不按 Codex thread、实验 round、rerun、debug 或 correction 的时间线机械组织。只有当阶段顺序本身改变科学解释时，才保留历史。
• audit: PASS、preflight、commit、branch、job id、allocation、validator token、push 状态等内部过程不能作为导师面对正文的章节或结论。
• minor correction 如果只是修正最终实验有效性，应直接合并进最终方法定义。例如写“多轮 FedAvg 中每个 client 保留 optimizer state”，不要单独写“为什么又做了一轮 correction + stability”。
• 表格负责给精确数字，正文负责解释少数真正改变判断的比较。不要在标题、表格、正文和总结中连续四次重复同一组数字。
• 小标题直接说明科学内容，不要机械使用 结果 1/2/3/4、第一步/第二步/第三步、最终 audit 等模板标题；也不要每一两句话就起一个标题。
• 限制“不是 X 而是 Y”“真正”“核心”“最值得”“最重要”“首先其次最后”等固定修辞。能直接写观察事实时，就直接写事实。
• 证据有限时写条件化结论，例如“当前结果没有支持……”“在这 3 个 seed 中方向一致”，不要为了故事感写成“推翻了假设”“证明高维不是问题”。
• 如果一份文件既给导师看又给作者自己用，前半部放导师面对的科学叙事；停止标准、候选机制、实现风险、repo path、commit 和复现细节放后半部或附录，不要混在主文。
• 只有真实需要导师拍板的问题才放在结尾。不要为了有 Questions for discussion 而制造已经被数据回答的问题。
• 最终检查：隐藏所有内部路径、commit、job id 和 audit token 后，导师是否仍能独立理解这项工作的科学问题、比较、结论和下一步？如果不能，说明报告仍然被工程过程绑架。

README

用于项目介绍和面向使用者的文档。

• 第一屏应回答：这是什么、给谁用、解决什么问题、如何开始。
• 第一屏还应说明当前状态和更多信息位置；不要让目录树、安装日志或内部字段先于用途说明。
• 避免宣传口号。
• 命令、包名、配置键和文件路径保持不变。
• 优先使用短章节和清楚标题。

文档

用于技术文档和操作说明。

• 术语保持稳定。不要无理由在中文名、英文名和缩写之间来回切换。
• 步骤顺序和条件要明确。
• 用直接指令，避免聊天式铺垫。
• 标点和空格遵循中文技术文档习惯。

状态更新

用于进度汇报和团队沟通。

• 保留时间、动作、结果、风险、阻塞点和负责人。
• 先用中文说明实际进展和风险，再列证据路径、任务编号、命令、状态 token 或日志。
• 不要为了显得顺畅而弱化风险或不确定性。
• 删除仪式化总结。

需要修掉的 AI 味

把下面这类表达替换成具体事实，或直接删除：

• 开场套话：“值得注意的是”“需要指出的是”“在当今快速发展的时代”。
• 空总结：“综上所述”“总的来说”“归根结底”。
• 价值拔高：“具有重要意义”“展现巨大潜力”“提供坚实基础”。
• 无来源权威：“研究表明”“业内普遍认为”“专家指出”，除非给出来源。
• 空泛二元排比：“不仅是 X，更是 Y”，尤其是 Y 含糊时。
• 强行三件套：例如只测了一个性质，却写“准确性、效率和鲁棒性”。
• 翻译腔：长串“基于……通过……实现……”，过度被动句，英文语序套进中文。
• 宣传腔：“赋能”“打造闭环”“全方位提升”“深度融合”。
• README/文档里的过度恭维或自我说明：“这个问题非常关键”“下面我将”。
• 导师组会中的虚构时间模板：“30 秒版本”“3 分钟版本”“如果只有 X 分钟”“可以这样讲”。
• 把开发过程当科学叙事：“最终 audit：PASS”“为什么又做了一轮 correction”“本轮 closeout 完成”。
• 过度机械的叙事节奏：“结果 1/2/3/4/5”“第一步/第二步/第三步”，除非这些编号本身有实际分析含义。
• 高频使用“真正 / 核心 / 最值得 / 最重要 / 不是 X 而是 Y”制造强调；优先直接写事实、比较和条件。

中文文档习惯

• 一个段落只讲一个主题。
• 标题短而直接，不用装饰性标题。
• 测量值、版本、年份、数量和范围使用阿拉伯数字。
• 行内英文和代码周围是否加空格，以可读性为准；代码块和代码 span 必须保持精确。
• 不把英文当装饰。只有为了精确性、读者识别或机器匹配时才保留英文。
• 读者可能不熟悉的缩写，第一次出现时要解释。
• 避免过多感叹号、装饰性标点和破折号。
• 列表项只有在有助于扫描时才强行平行；不要把每节都凑成三条。

科研和证据边界

科研报告、组会材料、论文说明和作者沟通必须区分：

• 已有数据或原文明确支持的内容。
• 用户已经确认的判断。
• 根据上下文作出的推断。
• 建议性扩展或下一步计划。

凡涉及效果、性能、贡献或路线判断，优先写条件、基线、范围和证据。不要单独用“显著”“先进”“有效”“鲁棒”作结论。

输出

默认只输出修改后的文本。

如果用户要求先评审再改写，使用：

## 主要问题
- ...

## 建议改法
...

如果事实存在风险，补充：

## 保真说明
- ...

参考材料

完整审校清单见 references/chinese-prose-checklist.md。需要处理来源和出处时，再读 references/source-notes.md。