YuukiAS 中文自然表达终审
本 skill 用作中文报告、README、技术文档、科研进展记录、Markdown/PDF 成稿和面向读者的中文说明的普通润色、说人话处理和最后审校。目标不是把文字改得随意，而是让它清楚、真实、符合中文读者习惯，并且不像模型套话。
这不是事实核查、文件转换、AI 检测规避或伪原创工具。它只处理中文读者看到的表达质量：在 writing-fidelity 的保真底线之上，把机器味、翻译腔、模板腔和不必要英文降下来。
如果用户给的是已有中文或中文为主的科研/技术材料，并要求重新组织、结构性重写或文档级重写，同时要求保留事实、数字、公式、引用、比较条件、限制、路径、配置或命令等精确信息，不要把本 skill 当主路线；应交给 scientific-rewrite。本 skill 只在该重路线内部承担 REALIZE_MEANING 中文实现角色，或在最终候选稿生成后做自然表达终审。
使用场景
- 用户要求中文文字更自然、更少 AI 味、更少翻译腔、更少口号化，或更适合中文读者。
- 用户要求“中文为主”“说人话”“人能看懂”“能讲”“别像 audit/控制台/任务合同”“组会汇报”“汇报用”。
- 用户要求“别每句话一个 bullet”“别机械三点式”“用正常段落写”“普通英文能翻成中文就翻掉”。
- 用户没有明确说“说人话”，但输出目标是中文 Markdown、中文 PDF、中文报告、中文 README、中文终稿或面向用户/作者/读者的中文说明。
- 修改中文报告、README、项目文档、科研更新、基金/项目摘要或技术说明。
- 检查中文草稿是否在保留事实的同时去掉套话。
- 将中英混杂的技术文字改成稳定的中文文档风格。
- 中文技术文档、报告、README 或提示词里出现大量非必要英文，需要改成中文为主、只保留必要英文。
明确排除：已有科研/技术材料的 source-faithful structural rewrite。只要任务同时具备“已有中文或中文为主的科研/技术材料”“要求重新组织或结构性重写”“要求保留事实、数字、公式、引用、比较条件、限制、路径、配置或命令”等精确信息，应 hand off 给 scientific-rewrite，不要停留在本 skill 的普通润色路线。
不要用本 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、
textblock 或普通文本里，导致 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、确实更清楚的技术名词、应该翻译的普通概念。不能归入前两类的，改成中文。
工作流程
- 判断文本场景：
report、README、docs、status、slides、pdf-final或public-writing。 - 先标记受保护内容，避免误改事实、路径、命令、代码和字段名。
- 判断修改幅度：
minimal：只去掉明显套话、标点问题和风格问题。standard：按中文语感重写句子，但保留原结构。structural：只有在文档结构混乱或用户要求重写时，才调整章节顺序。
- 删除 AI 味表达。
- 做英文密度检查：把普通英文概念改成中文，同时保留受保护的精确英文。
- 检查第一屏：读者是否先看到判断、原因、下一步，而不是机器字段。
- 套用中文技术文档习惯。
- 复读一遍，确认事实没有被削弱、删除或拔高。
- 输出一版干净文本。只有在存在过度主张、缺少来源、受保护事实限制修改，或刻意保留英文时，才补充简短说明。
场景规则
报告
用于中文科研报告、组会材料、进展总结和实验说明。
- 保留问题、证据、解释、不确定性和下一步。
- 开头先说判断，再说证据。机器字段、路径、命令、日志和英文缩写只能支持结论，不能替代结论。
- 不要把“观察到”改成“证明了”。
- 避免“具有重要意义”“为后续研究奠定基础”“展现出巨大潜力”，除非文本明确给出证据和边界。
- 下一步要具体，例如用“下一步先做分层复现”，不要写成“后续继续优化”。
- 不要把月份、轮次或内部阶段名当成读者需要接受的版本名。能写具体日期、最好指标、作者决定和证据路径时，就不要写“某月版”“旧日期行”“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。