# Paper Write Zh Evidence

> paper-write-zh内部证据写作参考，仅在中文正文写作流程已命中后按阶段读取，不作为用户请求的独立入口。用于把已核验文献、实验材料、图表和用户笔记转化为可追溯论证，防止编造引用、强结论无依据、规划数据冒充真实结果和正文混入过程痕迹。不承担独立系统性文献调研，相关任务转/doubao-literature-research。

- Skill: `ahang1598/paper-write-zh-evidence` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ahang1598/paper-write-zh-evidence`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/paper-write-zh-evidence/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: ahang1598 (https://skillmd.com/u/ahang1598)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/ahang1598/paper-write-zh-evidence

---


# Evidence-Driven Writing：证据驱动写作

本参考把文献池、实验材料和用户笔记转化为论文论证。它适用于引言、相关工作、文献综述、研究背景、讨论、结论，以及任何“说法必须有出处”的正文。

## 一、硬门控

涉及文献、实验、方法对比或领域判断的正文，不要直接生成。先在 `write` 阶段建立两个轻量思考产物；它们是成稿前的脚手架，可作为写作准备落在草稿开头或单独暂存，写作完成后不必保留在正文里：

1. **Evidence Map（证据图）**：哪些材料能支持哪些具体判断。
2. **Paragraph Blueprint（段落蓝图）**：每段承担什么论证角色、使用哪些证据、边界在哪里。

证据图和段落蓝图是 `write` 阶段落笔前的准备，帮助避免边写边编。它们不是强制交付产物，`check_draft.py` 只校验最终正文的引用与形态，不检查蓝图文件是否存在；因此蓝图可写在草稿开头临时区，成稿后删去。

## 二、Evidence Map

每个可用来源一行。来源可以是文献、用户实验日志、图表、数据表、代码仓库说明、学校/期刊模板或用户笔记，但必须标明证据层级。

```markdown
| ID | 来源/材料 | 类型 | 可直接支持的事实 | 可写入正文的判断 | 使用位置 | 风险 |
|---|---|---|---|---|---|---|
```

填写规则：

- 优先使用用户提供的真实材料和已核验文献。
- 只使用 `scholar_search` 返回的英文元数据与引用格式、browser-task 页面可见的题名与摘要、DOI 页面元数据、知网导出信息、用户笔记或用户提供材料中实际存在的信息；没有摘要或更强页面证据时，不要编写全文级结论。
- `scholar_search` 返回的英文元数据可作为 citation-level / metadata-level 来源，用于正式参考文献、文内引用和元数据层判断；普通搜索工具或其他学术元数据工具返回的信息只能列为待核验候选。若正文要支撑方法细节、实验结果、适用场景或局限边界，仍必须补摘要、DOI/出版社页面、arXiv 页面、browser-task 页面可见内容或用户可核验材料。
- 一条证据支持一个具体判断，不支持“该领域很重要”这类空泛说法。
- 弱支持、间接支持或只读到 `scholar_search` 元数据 / 页面可见元数据时，`风险` 标为 `metadata-only`、`abstract-only`、`indirect` 或 `needs-verification`；citation-level / metadata-level 来源不能直接作为全文级正文事实支撑。
- GitHub 仓库、博客和工具文档可作为软件资源说明，不自然替代正式论文来支撑学术主张。
- 每个进入正文的文献性判断都必须带文内引用标识；evidence map 中的 `ID` 和 `来源/材料` 不能只停留在后台表格，必须落实到正文句子中。未指定体例时，中文默认使用 GB/T 7714 顺序编码制 `[1]`、`[2]`；模板要求著者-出版年制、脚注或其他体例时，按模板输出对应的文内标注。

## 三、实验证据协议

结果、讨论、贡献声明或摘要中涉及实验效果时，先明确实验协议。协议可在 `prepare` 阶段随来源写入 `.workflow/source_pool.md`，或作为 `write` 阶段落笔前的准备。协议必须让当前证据链可见，避免把计划、模拟数据或未完成实验写成真实结果。直接生成论文时默认 Draft Mode：可以用规划数据和 mock 表格搭完整初稿，但必须让读者一眼看出这些内容等待真实实验替换。

### 3.1 实验协议必含要素

| 要素 | 必须说明的内容 | 不足时的写法 |
|---|---|---|
| 数据集 | 数据来源、任务对象、训练/验证/测试划分、样本口径 | 标为待补材料，不写泛化结论 |
| 基线 | 对比方法、选择理由、参数或实现来源 | 只写计划对比，不写优于基线 |
| 指标 | 指标定义、计算口径、类别不平衡处理 | 先解释指标用途，不给效果判断 |
| 消融 | 每个声称有效的模块对应一项消融或限制说明 | 贡献降级为设计动机或待验证假设 |
| 泛化 | 跨数据集、跨场景、鲁棒性或失败样例 | 不写“具备良好泛化能力” |
| 可解释性 | 若 XAI 是贡献，说明解释方法、图例或人工核验方式 | 不把可视化示意写成解释性验证 |

### 3.2 方法—实验可追溯表

每个引言贡献都要能追溯到实验、图表、限制说明或未来工作边界。

```markdown
| 贡献/主张 | 方法模块 | 对应实验 | 表/图 | 允许写入正文的结论 | 证据状态 |
|---|---|---|---|---|---|
```

若某个贡献没有实验、图表或限制说明支撑，不要让它继续留在引言贡献列表中；可以改写为“本文尝试”“本文设计”或放入未来工作。

### 3.3 实验阶段门控

涉及实验、结果、讨论或贡献声明时，按以下阶段判断材料是否足够：

| Gate | 检查目标 | 不足时处理 |
|---|---|---|
| D0 数据边界 | 数据来源、样本口径、训练/验证/测试划分是否明确 | 只写实验计划或数据需求 |
| D1 指标口径 | 指标定义、计算方式、类别不平衡处理是否明确 | 先解释指标用途，不给效果结论 |
| D2 对照与消融 | baseline、参数、消融或模块对应关系是否清楚 | 贡献降级为设计动机 |
| D3 结果证据 | 结果表、日志、图、用户确认数值是否存在 | Draft Mode 生成 `PLANNING DATA` 初稿；Final Mode 不写“实验结果表明” |
| D4 正文去污染 | 规划数据、mock 数据、待替换说明是否被清楚标注 | Draft Mode 保留表注/状态块标记；Final Mode 从正文和图表中移除 |
| D5 结论边界 | 结论是否只覆盖当前数据、指标和实验条件 | 删除或降级泛化结论 |

### 3.4 Mock 数据边界

模拟或规划数据在 Draft Mode 中是正式初稿机制，用于把实验章节、表格和讨论结构先搭完整；在 Final Mode 中只能作为待替换风险，不能保留为提交内容。

- 在 `.workflow/paper_draft.md`、表格标题或交付说明中明确标注为 `PLANNING DATA`；不要依赖本地文件名前缀来区分。
- 模拟表格必须保留说明：`PLANNING DATA - replace before submission`。Draft Mode 可以把它放入正文相应位置，Final Mode 必须替换为真实数据或删除。
- 正文若临时使用模拟数值，必须保留“基于规划数据的初稿分析”或 `[待真实实验替换]` 的边界表达。
- Draft Mode 可以写“规划数据初步显示的预期趋势是……”，禁止写成“实验结果表明”“结果验证了”“显著优于”等真实实验结论。
- 交付时应说明哪些内容是规划数据、哪些内容来自真实日志或用户确认。

Draft Mode 结果措辞红黑表：

| 禁止写法 | 替代写法 |
|---|---|
| 实验结果表明…… | 基于规划数据的初稿分析显示…… |
| 结果验证了……的有效性 | 该趋势仍需真实实验验证；若复现，可支持…… |
| 显著优于 / 充分证明 / 全面验证 | 在规划数值中高于……；是否显著需真实实验和统计检验确认 |
| 满足工业实时检测需求 | 在设定硬件和输入尺寸下规划 FPS 为……；产线吞吐仍需部署测试 |
| 具有更强鲁棒性 | 在规划的光照/噪声条件下预期下降幅度较小；真实复杂场景仍待补测 |
| 从表 X 可以看出……这表明…… | 表 X 只用于展示待验证趋势；正文说明最关键差异和待验证边界 |

如果表格或图注含 `PLANNING DATA - replace before submission`，同一段正文也必须出现规划数据边界；不能只在表注标注、正文却按真实结果写。

### 3.5 Draft Mode 图表生成协议

直接生成技术类论文初稿时，不能只列“待补图/待补表”。应生成可替换的图表骨架：

| 类型 | Draft Mode 做法 | Final Mode 要求 |
|---|---|---|
| 表格 | 生成表题、列头、单位、TBD/mock 数值、表注，并标注 `PLANNING DATA - replace before submission` | 使用真实实验数值、日志或用户确认数据 |
| 图 | 使用 `图 X-X 待绘制：图题。内容要求：...`，写明关键元素、坐标轴、输入输出或标注要求 | 插入真实图片或正式绘制图 |
| 结果段 | 解释规划数据应如何支撑论证，只写预期趋势和待验证边界 | 写真实结果、统计/指标和可核验证据 |

技术类期刊论文 Draft Mode 通常至少包含 3-5 个图占位、2-4 个表格；毕业/学位论文通常至少包含 6-8 个图占位、5-7 个表格。若题目是 YOLO/CV/缺陷检测，优先覆盖技术路线图、网络结构图、注意力模块图、特征融合结构图、数据集样例图、训练曲线/PR 曲线、检测结果对比图、消融表、SOTA 对比表和模型复杂度/FPS 表。

## 四、Paragraph Blueprint

每段写作前先定义角色，但不要规定具体句式，避免压制豆包自然表达。

```markdown
### 段落 N
- 角色：背景 / 方法脉络 / 局限 / 研究缺口 / 本文处理 / 结果解释 / 收束
- 主判断：
- 作者处理意图：为什么这些材料需要放在本段，作者要把读者引向哪个有限判断
- 证据 ID：
- 边界或限定：
- 禁止写入：提示词、过程说明、AI来源说明、口语化回填提示、无依据强结论。Draft Mode所需的`PLANNING DATA - replace before submission`和正式图占位属于证据边界，不得删除
```

只有蓝图能说明“这一段为什么存在”时，才进入正文写作。若蓝图只是在罗列文献，先重组为问题、方法、局限或边界。

“作者处理意图”不是写进正文的自我说明，而是写作前的约束：本段材料为什么被放在一起、作者如何取舍、能推出什么有限判断。它用于防止段落像把文献、实验现象和结论句拼接在一起。

## 五、引言模式

可发表的技术类引言通常不是文献清单，而是一条论证链：

1. 应用场景或问题压力：为什么这个问题值得研究。
2. 现有技术路线：按方法家族归纳，而不是按论文年份逐篇罗列。
3. 瓶颈递进：每类路线解决了什么，又留下什么问题。
4. 具体缺口：本文能合理处理的缺口，不夸大成全领域空白。
5. 本文贡献：可用连续段落表达；若目标模板允许，也可用短列表，但列表后应有边界说明。

工程/计算机类论文中，若大纲没有强制独立 Related Work，可以把最相关的相关工作综合进引言，使引言读起来像“问题压力—已有路径—未解瓶颈—本文定位”的论证，而不是“领域介绍—文献罗列—贡献列表”。

这 5 步是论证要素，不是固定五段式。不要机械写成“宏大意义—传统方法问题—近年来显著进展—然而面临挑战—本文贡献如下”。生成前先合并相邻功能块，优先从具体任务约束、数据集现象、失败样例或指标瓶颈进入，而不是从“国民经济/重要意义/研究热点”进入。

不要用冗长的章节安排段落结束引言。一句简洁的组织说明即可；若目标模板不需要，可以省略。

## 六、相关工作与文献综述模式

按主题组织，不按时间或编号堆论文。

一个主题段通常包含：

- 主题开场：定义方法家族或研究流派。
- 证据综合：比较 2-4 个来源在对象、方法、指标或结论边界上的差异。
- 局限边界：说明该主题尚未解决什么。
- 桥接：解释为什么需要下一类方法或本文方案。
- 作者判断：说明本文为什么接受、保留或避开某条技术路线，而不是只复述已有研究。

如果一个段落可以直接转换成表格行而不损失意义，它还不是论文正文，只是文献摘记。

相关工作、研究背景、引言和文献综述中的综合段，即使改写成方法家族或问题条件导向，也不能把文内引用一并抹掉。可接受的写法是把多个来源压成一个综合判断，并在句内或句末保留 `[1-3]`、`（作者, 年份）` 或脚注序号；不可接受的写法是正文无引用、只在文末列参考文献。

## 七、讨论与结论模式

讨论和结论最容易出现 AI 味和价值宣传化，必须使用 evidence map 约束结论强度。

### 讨论

- 解释结果为何出现，而不只重复“提升了”。
- 说明结果成立的实验条件、数据范围和可能失败场景。
- 若缺少消融、日志、可视化或外部数据集，不写“全面验证”。
- 对“工业实时检测”“工程应用价值”等判断要绑定速度、部署条件或待验证边界。

### 结论

- 收束本文真实完成的贡献。
- 当前证据存在会影响结论理解的限制时说明；前文缺口自然产生具体后续问题时再写下一步，否则省略。
- 不重复摘要，不重新宣传研究意义。
- 不补写文献、实验或图表中没有出现的新事实。

## 八、正文污染防火墙

以下内容属于计划、草稿或对话，不得进入论文正文：

- 用户要求：如“写自然一点”“避免 AI 味”“这里展开”。
- 过程说明：如“本段将讨论”“下面从三个方面说明”。
- AI 来源说明：如“部分内容由豆包生成”。
- 自我修正痕迹：如计算过程纠错、括号里的生成思路。
- 口语化待替换说明：如“用户应替换此处”“fill later”“此处插图”。Draft Mode规定的`PLANNING DATA - replace before submission`和含图题、编号、内容要求的正式图占位不属于此类污染。

如果材料缺失，Draft Mode 可在正文中用正式占位说明，例如“图 2 待绘制：检测结果对比图。内容要求：展示改进模型与基线模型在典型缺陷样本上的检测框、置信度和漏检情况。”Final Mode 应在正文外的状态块中标注“待补”，或暂停交付。不要让提示词、口语化回填说明或“用户自行替换”等草稿提示直接混入论文正文。

## 九、反罗列门控

文献驱动段落必须综合至少两个维度：

- 问题条件；
- 方法家族；
- 多项研究共享的局限；
- 与本文方法的直接桥接；
- 有引用支撑的边界。

失败写法：

```markdown
A 提出了方法一。B 提出了方法二。C 提出了方法三。因此该领域发展迅速。
```

较好写法：

```markdown
现有研究主要从特征增强和检测头改造两个方向改善缺陷检测性能。前者通常能够提高弱纹理区域的表征能力，但在背景噪声较强或缺陷尺度变化明显时仍容易引入冗余响应；后者更关注定位与分类分支的匹配关系，却往往需要额外计算开销。由此可见，如何在保持推理效率的同时增强关键缺陷特征，仍是轻量化检测模型需要处理的核心问题。
```

## 十、证据覆盖自检

交付前在对话中自检：

- [ ] 每个文献性判断是否能追溯到 Source ID。
- [ ] 是否有文献只凭题名/元数据就被写成具体研究结论。
- [ ] 是否把仓库或工具文档当作正式论文支撑主张。
- [ ] 是否存在“显著、主流、全面验证、重要价值”等强判断无证据或无边界。
- [ ] 是否有段落只是按文献逐篇罗列。
- [ ] Draft Mode 是否把 `PLANNING DATA` 写成真实实验结论，是否出现“实验结果表明/结果验证了/显著优于/充分证明/全面验证”。
- [ ] 相关工作、研究背景、引言和文献综述中的文献性判断是否已显式挂上文内引用标识，而不是只在文末列参考文献。
- [ ] 实验段是否逐行复述表格数字，而没有解释趋势、异常、机制或边界。
- [ ] 是否有用户提示词、AI 来源说明、计算纠错或待替换说明混入正文。
- [ ] Draft Mode 的 mock 表格和规划数据是否全部标注 `PLANNING DATA - replace before submission`。
- [ ] Draft Mode 的图占位是否有图题、编号和内容要求，而不是空泛“此处插图”。

## 十一、可复用示例

如需查看文献驱动论证结构示例，可查阅本技能打包的 gpr-introduction-example 示例。它只能作为结构模式参考，不能把示例内容迁移到无关论文中；不要通过 shell 或本地目录遍历去查找示例文件。