# Chinese Prose > 中文报告、README、Markdown/PDF 成稿、技术文档、科研说明、组会材料和“说人话”终审。任何中文 Markdown/PDF/报告/README/面向用户或读者的中文内容都应自动触发本 skill，用于普通中文润色、中文为主、降低 AI 味/翻译腔/模板腔/宣传腔，并保护事实、数字、术语、命令、引用、实验结果和证据边界。 - Skill: `yuukias/chinese-prose` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add yuukias/chinese-prose` - Raw SKILL.md: https://api.skillmd.com/api/skills/yuukias/chinese-prose/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - License: MIT-compatible synthesis plus public-domain style guidance - Author: YuukiAS (https://skillmd.com/u/yuukias) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/yuukias/chinese-prose --- # 中文自然表达终审 本 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 ...}}`、`...`、`` 这类模板和标签属于来源包装， 不是中文成稿的引用表达。除非用户明确要求保留源代码式标记，否则候选稿里不能出现。 当 `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 模板、`...`、 ``、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 必须保持精确。 - 不把英文当装饰。只有为了精确性、读者识别或机器匹配时才保留英文。 - 读者可能不熟悉的缩写，第一次出现时要解释。 - 避免过多感叹号、装饰性标点和破折号。 - 列表项只有在有助于扫描时才强行平行；不要把每节都凑成三条。 ## 科研和证据边界 科研报告、组会材料、论文说明和作者沟通必须区分： - 已有数据或原文明确支持的内容。 - 用户已经确认的判断。 - 根据上下文作出的推断。 - 建议性扩展或下一步计划。 凡涉及效果、性能、贡献或路线判断，优先写条件、基线、范围和证据。不要单独用“显著”“先进”“有效”“鲁棒”作结论。 ## 输出 默认只输出修改后的文本。 如果用户要求先评审再改写，使用： ```markdown ## 主要问题 - ... ## 建议改法 ... ``` 如果事实存在风险，补充： ```markdown ## 保真说明 - ... ``` ## 参考材料 完整审校清单见 `references/chinese-prose-checklist.md`。需要处理来源和出处时，再读 `references/source-notes.md`。