Scientific writing zh

中文科技与项目写作

Overview

本技能面向中文科研论文、技术报告、算法设计说明、申报材料、会议纪要和正式交付文档。核心原则是：表达强度不得超过证据强度。语言优化可以改善结构、逻辑与可读性，但不能制造事实、数据、引用、实现、效果或结论。

“低 AI 痕迹”在本技能中指减少模板腔、空泛主张、抽象动词堆叠和过度整齐的结构，使文字更具体、稳定、克制、可核验；它不用于规避检测器，也不用于掩盖虚构内容或冒充人工原创。

When to Use

适用于以下触发场景：

• 中文论文、摘要、引言、方法、结果或结论的起草与修订；
• 科研或工程项目报告、算法设计说明和技术方案；
• 申报书、总结、纪要、汇报稿和PPT文字；
• “降低AI味”“减少套话”“正式化但不改事实”；
• 长文档目录、章节职责、术语和交叉引用整理；
• 图表、公式、代码、方案与正文之间的一致性检查；
• DOCX/PDF正式件的只读审查和交付前验收。

不用于：创意文学、营销宣传、刻意口语化写作；替用户虚构研究结果、引用或业务成效；绕过作者身份、学术诚信或内容检测要求。

Non-Negotiable Evidence Boundary

写作前把内容分为四类：

类别	可用表达	禁止越界
已证实事实	直接陈述，并保留来源	扩大时间、范围、对象或因果
有限证据	“在所分析样本中”“当前记录显示”	写成总体规律或稳定效果
设计意图	“设计用于”“计划支持”	写成已实现、已部署或已验证
待确认事项	占位、问题清单或降级表达	用常识补齐为项目事实

如果一句话不能回答“依据是什么、适用到哪里”，就删除、降级或标为待确认。详见references/evidence-and-boundaries.md。

Core Workflow

1. 定义交付合同

先确认材料类型、读者、用途、长度、事实来源、不得改变项、不得披露项和输出格式。长文档为每章写一份“章节合同”：本章回答什么、使用哪些证据、输入输出是什么、与前后章如何衔接、哪些内容不在本章展开。

完成标准：可以用一句话说明交付物目的，并列出不可变事实和待确认项。

2. 建立最小证据台账

将关键主张映射到用户材料、原始数据、代码/配置、正式规范或公开文献。不同来源只能证明其直接覆盖的事实：方案可证明设计意图，代码可证明实现行为，日志或产物可证明特定运行记录，评估数据才可支撑性能结论。

完成标准：每个关键数字、结论、公式和状态主张都有来源或明确标记。

3. 先组织职责，再写连续正文

技术段落优先采用：

问题或输入状态 → 处理过程及依据 → 输出或去向 → 适用边界

不要把目录、流程框或代码函数逐项扩写成流水账。算法章节先明确科学问题、尺度、输入、变换、输出和限制，再决定公式、图表和实现细节的粒度。

完成标准：每段承担一个可命名的技术职责，删去该段会出现明确的信息缺口。

4. 执行科学性审查

逐项核对：

• 术语、变量、单位、时空尺度和坐标是否一致；
• 相关关系是否被误写为因果；
• 理论解释是否被误写为实际实现；
• 个例是否被外推为总体性能；
• 代理变量、约束或启发式步骤是否被夸大为完整物理求解；
• 公式是否可追溯、变量是否定义、适用条件是否完整。

算法设计文档按需加载references/algorithm-design-documents.md；图表和公式加载references/figures-tables-and-formulas.md。

5. 执行低模板化表达审查

重点删除或改写：

• 无对象的“提升、促进、赋能、保障、实现”；
• 无证据的“显著、全面、稳定、先进、有效”；
• 同义反复和每段相同的“首先—其次—最后”；
• 为显得完整而添加的价值表态、展望或结论；
• 比证据更确定的语气。

优先使用具体主语、动作对象、条件、结果和边界。不要机械替换连接词。详见references/scientific-style-and-low-ai-trace.md。

6. 验证交付物，而不只验证文字

涉及文件时：

1. 不覆盖原件，生成可识别的新版本；
2. 结构检查标题、目录、编号、图表、公式、引用和敏感信息；
3. 实际导出PDF，检查分页、裁切、图题、表头、公式和字体回退；
4. 任何影响分页的修改后重新验证；
5. 明确区分“文件生成成功”“文档审查通过”和“业务/实验验证通过”。

详见references/document-review-and-delivery.md。

Task-Specific Routes

任务	按需加载
事实边界、引用和主张审查	references/evidence-and-boundaries.md
降低模板腔、成熟中文科技风格	references/scientific-style-and-low-ai-trace.md
长文档目录、章节协作和术语	references/long-document-workflow.md
算法设计、项目技术说明	references/algorithm-design-documents.md
科学图、表、公式和图文一致性	references/figures-tables-and-formulas.md
DOCX/PDF只读审查和交付	references/document-review-and-delivery.md
需求、合同与设计文档对照	references/requirements-crosswalk.md
论文逐章汇报与指标解释	references/paper-briefing-workflow.md

可复制模板：

• 章节合同：templates/chapter-contract.md
• 主张—证据矩阵：templates/evidence-matrix.csv
• 术语登记表：templates/terminology-register.csv
• 正式交付终审：templates/final-review-checklist.md

合成示例：

• 修改前后对照：references/examples/synthetic-before-after.md
• 主张—证据矩阵：references/examples/synthetic-evidence-matrix.md
• 算法设计提纲：references/examples/synthetic-algorithm-outline.md

仅在任务需要时读取对应资源，避免一次性加载全部参考。

Output Contracts

直接润色

优先交付修改稿；若存在事实缺口，另列“待确认”，不要把审计过程压过用户需要的正文。

修改后：
...

待确认：
- 该结论缺少适用样本或来源。

长文档起草

先给可审核的多级目录、章节合同、证据/图表计划和待确认项；经确认后逐章写正文。不要一次生成整篇看似完整但事实失控的文档。

审查任务

区分：明确错误、证据不足、需用户决定、可选风格调整和已核验正常项。用户要求只读审查时不得直接修改原稿。

Common Pitfalls

1. 把“低AI味”做成同义词替换。 修复：回到主语、对象、条件、证据和边界。
2. 方案、代码、日志混为一种证据。 修复：分别说明设计、实现和运行状态。
3. 公式越多越专业。 修复：只保留来源、变量和适用条件完整的最少公式集。
4. 目录承担不了章节职责。 修复：建立章节合同和跨章映射后再写。
5. 图表只是装饰。 修复：每张图表明确其问题、来源、变量、单位和支撑结论。
6. 审查结果直接改原件。 修复：先报告、再由用户决定；始终保留新版本。
7. 为完整性补成果或展望。 修复：没有证据就删除或写成待验证目标。
8. 把检测通过等同于科学正确。 修复：自动检查只证明其覆盖的结构条件，不能替代领域审查。

Verification Checklist

• 关键事实、数字、引用和公式均有来源或状态标签。
• 未新增未经确认的单位、时间、数据、成果、效果或结论。
• 术语、变量、单位、尺度和因果强度前后一致。
• 每段有明确职责，不是目录扩写或空泛评价。
• 低模板化修改没有改变事实或专业含义。
• 图、表、公式、正文和实现证据之间没有明显冲突。
• 不含不必要的个人、项目、基础设施或内部实现信息。
• 文件任务生成新版本，并完成与结论相匹配的结构和视觉验证。