# 合规降重与 AI 痕迹控制

本文件讨论的是**合规写作**，不是规避检测的花招。

目标只有两个：

1. 让论文真正体现你对项目的理解与分析
2. 降低因模板化表述、直接搬运、无来源改写导致的重复率和 AI 痕迹

## GitHub 经验提炼

### 1. 来自 MasterThesis101 的可取做法

从 GitHub 仓库 `SUTFutureCoder/MasterThesis101` 可提炼出几条对论文质量直接有帮助的规则：

1. 尽可能使用论文文体，不写废话。
2. 创新点、工作量、思路和方法要“论出来”，并和现有方法做对比。
3. 章节之间要有递进关系或清晰关系图，不能各写各的。
4. 论文提交给导师前必须先自查。

### 2. 来自 OpenDraft 的可取做法

从 GitHub 仓库 `federicodeponte/opendraft` 可提炼出几条 AI 使用边界：

1. AI 生成内容只能作为研究草稿起点，不能当成终稿直接提交。
2. 必须自行核验所有来源。
3. 必须加入自己的分析、判断和结论。
4. 必须检查学校或机构的 AI 使用政策。
5. 不能编造引用，不能把 AI 当成论文作者。

## 降低 AI 痕迹的正确方法

### 1. 从“本项目事实”出发，不从“通用套话”出发

高风险写法：

- 随着互联网的发展……
- 系统具有良好的可扩展性和实用性……
- 该模块大大提升了用户体验……

低风险写法：

- 本系统将订单确认、支付、退款三个高冲突节点统一收口到订单状态机中，原因在于……
- 档期资源采用日期粒度建模，而不是时间段粒度，主要考虑到当前业务……
- 摄影师详情页同时展示套餐、评价和档期，是为了减少用户在预约前的页面跳转……

### 2. 每段至少落一个“本项目特征”

每个自然段尽量包含以下至少一类信息：

1. 当前项目的业务约束
2. 当前项目的设计取舍
3. 当前项目的实现边界
4. 当前项目的测试结果
5. 当前项目的不足和改进方向

如果一个段落放到任何管理系统论文里都成立，这种段落就很容易显得 AI 味重。

### 3. 一次只让 AI 处理一个小问题

不要让 AI 一次性生成整章终稿。

正确做法：

1. 先列提纲
2. 再写单个小节
3. 再补引文
4. 再补图表说明
5. 最后人工通读改写

### 4. 保留“人的判断”而不是只保留“系统做了什么”

高 AI 风险段落通常只有事实，没有判断。

应主动补充：

1. 为什么选这个方案
2. 为什么没选另一种方案
3. 这个方案解决了什么
4. 还没解决什么

### 5. 主动写出局限和失败边界

通篇只有正面结果、没有局限、没有边界，往往很像 AI 平滑生成。

应在各章自然写出：

1. 当前版本未实现什么
2. 哪些测试尚未完成
3. 哪些功能只是设计阶段设想
4. 哪些数据结论还不足以外推

## 摘要与研究现状示范骨架

### 中文摘要三段式骨架

1. 第一段写研究目的与意义：
   本文针对……场景中存在的……问题，设计并实现了……系统，目标在于……
2. 第二段写研究内容与方法：
   系统采用……技术路线，围绕……、……、……等关键问题，提出了……方案。
3. 第三段写结果与结论：
   验证结果表明，系统已能够……，但在……方面仍有进一步完善空间。

### 研究现状对比段骨架

1. 先概述现有研究方向：
   现有研究主要集中在……与……两个方向。
2. 再列举代表成果并加引文：
   例如，文献[x]采用……；文献[y]重点解决了……。
3. 再指出不足并引出本文切入点：
   但针对……这一具体场景，现有工作在……方面仍存在不足，因此本文选择……

## 降低重复率的正确方法

### 1. 不直接搬运这些材料

以下内容最容易带来重复率问题：

1. 开题报告
2. 需求设计文档
3. README
4. 其他毕业论文的研究现状
5. 官方文档定义段落

### 2. 正确改写方式不是同义词替换

错误做法：

- 把原句逐词替换
- 把中文文献逐句翻译再回译
- 把开题报告句子换几个词继续用

正确做法：

1. 先理解原文在说什么
2. 再用当前项目语境重写
3. 最后补引用

### 3. 对“借来的观点”和“自己的结论”分开写

推荐结构：

1. 先概述已有研究或已有做法，并加引文
2. 再说明这些做法对本文的启示
3. 最后写本文自己的选择与调整

这样既能降重，也更像论文。

### 4. 引文要真实进入正文

如果只是文末列参考文献，正文不引用，既不能降重复风险，也不能提升学术可信度。

## AI 使用合规策略

### 1. 查学校政策

如果学校或导师对 AI 有明确规定，必须优先遵守。

### 2. 保留修改过程

建议保留：

1. 分章节草稿
2. 修改前后版本
3. 引文核验记录
4. 图表替换记录

原因不是“应付检测”，而是为了证明你有真实写作与修改过程。

### 3. 不提交“一键生成终稿”

凡是长段统一口吻、无局限、无校核、无真实引文的终稿，风险最高。

## 自查清单

提交前逐项检查：

1. 是否还有大段开题报告原句
2. 是否还有 README 或需求文档直搬段落
3. 是否还有“随着……发展”这类空泛套话
4. 是否每章都有项目特有的判断和边界
5. 是否所有引用都已核验真实存在
6. 是否每个核心小节都有至少一个“为什么这样设计”
7. 是否存在整页都可以替换到别的系统论文里的通用段落

## 经验来源

以下 GitHub 项目提供了可吸收的方法论：

1. `SUTFutureCoder/MasterThesis101`
2. `federicodeponte/opendraft`
