中文工科顶刊论文写作 Skill
这个 skill 在做什么
把中文工科顶刊（机械工程学报、自动化学报、计算机学报、仪器仪表学报、控制与决策、振动工程学报等）的写作范式拆成可执行步骤。本 skill 的核心信念：
- 顶刊写作不是玄学，是范式。范式可以学。
- AI 写作的痕迹会被审稿人一眼看出。本 skill 的语言指引以"反 AI 味"为底线。
- 创新性是争出来的，不是吹出来的。本 skill 区分"真创新"和"包装"，并给出对应表达方式。
- 图是审稿人接触论文的第二眼（第一眼是标题摘要）。本 skill 提供可执行的 matplotlib 模板。
不覆盖：参考文献的检索与格式化（用户另有 skill）。
第一步：判断当前阶段
用户的请求可能落在 4 类阶段中的一类（也可能是组合）。先判断，再加载对应 reference。不要一上来就把所有 reference 全读了——上下文成本很高，按需加载。
| 阶段标志 | 用户可能说的话 | 加载 |
|---|---|---|
| A. 规划 | "我想做一个 XX 方向的研究"、"帮我想几个创新点"、"这个题目能写吗"、"帮我搭个大纲"、"国内外现状梳理一下" | references/stage-planning.md |
| B. 写作 | "帮我写引言"、"摘要怎么写"、"这章用什么结构"、"实验部分该写哪些内容" | references/stage-drafting.md |
| C. 润色 | "这段太 AI 了"、"读起来不像论文"、"帮我改成学术语言"、"这段逻辑顺不顺" | references/stage-polishing.md |
| D. 单点诊断 | "这个创新点够新吗"、"帮我画一张 XX 图"、"这个图符合规范吗"、"消融实验该怎么呈现" | 对应专项 reference |
判断不清就问用户。例如："你目前是在选题阶段，还是已经有初稿了？" 比起猜错路径走偏，多问一句省得多。
第二步：按需加载 reference
| reference | 内容 | 何时加载 |
|---|---|---|
references/writing-patterns.md |
标题/摘要/引言/章节范式、语言风格、长句结构 | 任何写作或润色任务 |
references/word-count.md |
字数 / 篇幅规范速查表——各章节、各段、各句的字数区间，及主流期刊要求 | 用户问"X 应该多少字"、"够不够长"、"超了吗"，或起稿前规划字数预算 |
references/exemplars.md |
2 篇真实顶刊论文的完整仿例（摘要+引言+结论原文 + 段落功能注解 + 可模仿点） | 起草任何一节前都建议先读对应部分；用户说"给个范例""我对照着写"时必读 |
references/innovation.md |
创新点的"识别 / 包装 / 头脑风暴"三种模式 | 用户提到创新、贡献、novelty、亮点、为什么这是新的 |
references/figures.md |
9 类图（流程/网络/机械结构/曲线/散点/柱状/云图/图像对比/表格）的规范，每类有 matplotlib 实现要点 | 用户要画图、看图、改图 |
references/stage-planning.md |
规划阶段 SOP（选题论证 → 现状梳理 → 创新点提炼 → 技术路线 → 大纲） | 阶段 A |
references/stage-drafting.md |
按章节的写作 SOP（标题/摘要/引言/方法/实验/结论） | 阶段 B |
references/stage-polishing.md |
三遍润色法（语言 → 逻辑 → 形式）+ AI 痕迹清单 | 阶段 C |
关于 exemplars.md 的用法：仿例不是用来抄的，是用来感受整体节奏和句式弹性的。规则告诉 Claude "应该怎么写"，仿例让 Claude 看到"真正写出来是什么样"。两者结合比单看规则有效得多。每写一节前都建议先看对应仿例的段落，找到节奏感再下笔。
加载只读你需要的部分（这些文件都做了二级目录），不要一次全文读。
绘图任务：scripts/paper_plot.py 是一个可直接 import 的 matplotlib 配置模块，提供顶刊风格的 rcParams、配色、字体、9 类图的快速函数。用户要画图时优先用它，而不是从零写 matplotlib。
核心原则（任何阶段都适用）
1. 第一性原理：审稿人想看什么
审稿人不是来欣赏你文笔的。他/她在 30 分钟内要回答 4 个问题：
1. 你解决的是不是个真问题？（→ 引言要把"问题"讲透，不是讲背景）
2. 你的方法是不是真的新？（→ 创新点要"对比着说"，不是孤立陈述）
3. 你的方法是不是真的有效？（→ 实验要有对比、有消融、有定量）
4. 这事跟我（审稿人）有什么关系？（→ 结论的"为...提供"段不是套话，是钩子）
写每一句话时问自己：这句话回答了上面 4 个问题中的哪一个？没有回答任何一个的句子，多半是水分。
2. 反 AI 味的底线
中文工科论文的"AI 味"集中在以下几类，本 skill 默认全部规避（详见 references/stage-polishing.md）：
- 空洞的过渡词："综上所述"、"总而言之"、"值得注意的是"、"随着...的不断发展"、"在当今社会"
- 被动句堆叠：连续 3 个以上"被...""可以被..."的结构
- 大词无实："深度赋能"、"全面提升"、"显著优化"——但没说提升了多少、优化了哪里
- 三件套结构癖：什么都要"首先、其次、最后"。变量稍多就用"在 X 方面、在 Y 方面、在 Z 方面"
- 形容词堆砌："广泛的""深入的""全面的""系统的"作为修饰前置形容词
- AI 喜欢的词："旨在""致力于""探索性地""一定程度上""有效地"（高频出现就有问题）
判断标准：如果一句话去掉所有形容词和副词，剩下的内容是不是仍然成立且信息量没变？是 → 那些形容词是水分，删掉。
3. 工科论文的"动词库"
学会这套动词，文风立刻像论文：
| 场景 | 推荐动词 | 避免 |
|---|---|---|
| 提出方法 | 提出、建立、构建、设计、发展（一种...） | 想到、做了、搞了 |
| 实验验证 | 验证、表明、证明、揭示、证实 | 说明、看出、显示 |
| 现状描述 | 已有的研究、相关工作、学者们 | 别人、大家、人们 |
| 指出问题 | 然而、仍存在、鲜有涉及、尚未充分考虑 | 但是、可是、不过 |
| 描述效果 | 显著降低/提升 X%、相比 Y 减少了... | 大大改善、明显变好 |
| 引出本文工作 | 为此、针对上述问题、本文聚焦于... | 所以我们、于是 |
4. "示出 vs 说出" 原则
说出："本方法效果显著。" → 空洞。
示出："本方法在 NASA 飞机涡扇发动机数据集上将 RMSE 由 16.2 降至 12.7（降幅 21.6%），优于 Transformer 基线模型。" → 信息。
任何形容词级别的判断，都要用数据/对比/具体场景示出，而不是直接说出。
5. "为什么"先于"是什么"
写引言、写动机、写创新点时，先回答：
- 为什么是这个问题？（→ 工程价值或学术价值）
- 为什么现有方法不行？（→ 局限的具体原因，不是"不够好"）
- 为什么你的方法行？（→ 机制层面的解释，不是"我们做了"）
只描述"是什么、做了什么"的段落，是在浪费篇幅。
工作流程总览
用户提需求
↓
判断阶段 (A/B/C/D)
↓
加载对应 reference (按需，分节读)
↓
按 reference 的 SOP 执行
↓
对照"核心原则"自查
↓
交付前再过一遍"反 AI 味清单"
重要：每个阶段的 reference 末尾都有一个自查清单。完成任务前对照清单逐项核对，再交付。
关于本 skill 的边界
- 不替用户做研究决策。"这个方向值不值得做""这篇能不能中"这类问题，skill 给的是分析框架，不是结论。
- 不编造实验数据。润色时如果发现段落没有数据支撑，提醒用户补，不要替他/她编一个数字进去。
- 不替用户决定论文挂谁、署什么单位。
- 不处理参考文献（用户另有 skill）。
如果用户的请求超出工科范围（比如想写一篇社科论文），先告知本 skill 是为工科顶刊设计的，问用户是否仍要用。
