@pzy560117/codex-harness 0.1.3 → 0.1.5

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/thesis-writing/references/ai-integrity-and-originality.md

@@ -1,191 +1,191 @@
-# 合规降重与 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`
+# 合规降重与 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`

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/thesis-writing/references/citation-templates.md

@@ -1,99 +1,99 @@
-# 引文格式与句式模板
-
-> [!IMPORTANT]
-> 本文件中的 `[1]`、`[2]`、`[3]` 只是格式示例，不代表固定编号。
->
-> 论文实际写作时，所有编号必须按**正文首次出现顺序**分配：
->
-> 1. 谁先在正文第一次被引用，谁就是 `[1]`
-> 2. 下一条首次出现的文献才是 `[2]`
-> 3. 同一文献重复引用时继续沿用原编号
-> 4. 文末参考文献列表也必须按正文首次引用顺序同步排列
-
-> [!IMPORTANT]
-> 当学校未单独规定来源比例时，参考文献来源建议按以下结构控制：
->
-> 1. 中文参考文献约 60%
-> 2. 英文参考文献约 20%
-> 3. 其他参考文献约 20%
->
-> 其中官方文档、RFC、标准、技术手册等应归入“其他参考文献”，不能大量替代中文和英文学术文献。
-
-> [!IMPORTANT]
-> 当学校模板未给出更高数量要求时，论文终稿参考文献默认**不少于 15 条**。
->
-> 按 15 条估算时，可直接按以下基线补齐：
->
-> 1. 中文不少于 9 条
-> 2. 英文不少于 3 条
-> 3. 其他约 3 条
->
-> 如果当前草稿只有 8 到 12 条文献，不要直接润色正文，应先补齐文献池再排正文编号。
-
-## GB/T 7714-2015 常见格式示例
-
-### 期刊论文
-
-格式：
-
-作者. 题名[J]. 期刊名, 年, 卷(期): 起止页码.
-
-示例：
-
-[1] 张三, 李四. 基于 Redis 的分布式锁设计与实现[J]. 计算机工程, 2023, 49(8): 120-127.
-
-### 学位论文
-
-格式：
-
-作者. 题名[D]. 城市: 学校, 年.
-
-示例：
-
-[2] 王五. 基于状态机的预约系统设计与实现[D]. 南京: 南京理工大学, 2021.
-
-### 网络资源
-
-格式：
-
-作者/机构. 题名[EB/OL]. (发布日期)[引用日期]. URL.
-
-示例：
-
-[3] VMware. Spring Boot Reference Documentation[EB/OL]. [2026-04-08]. https://docs.spring.io/spring-boot/docs/3.2.4/reference/html/
-
-## 编号排序规则
-
-1. 正文中的引文采用顺序编码制。
-2. 编号依据不是文献类型，也不是作者姓名，而是**第一次在正文中出现的先后顺序**。
-3. 如果第三章先引用某文献，而第一章没有引用它，那么它仍应按全篇第一次出现的位置参与编号。
-4. 文末参考文献列表必须与正文编号一一对应，按 `[1]`、`[2]`、`[3]` 顺序排列。
-5. 改稿后若正文引用顺序改变，必须整体重排，不能残留跳号、重复号或正文文末不一致的问题。
-
-## 来源结构建议
-
-1. 研究现状部分优先使用中文和英文学术文献，不要用官方文档充当研究成果来源。
-2. 第二章关键技术介绍可以少量引用官方文档或标准，但数量应受控。
-3. 如果正文参考文献明显被官方文档占据主体，说明来源结构失衡，需要补中文和英文论文。
-4. 对系统类本科论文，优先做到“中文文献为主、英文文献补充、其他文献兜底”。
-5. 如果学校没有特殊规定，优先把文献池扩到 15 条以上再进入终稿整理阶段。
-
-## 研究现状常用句式
-
-1. 文献[x]提出了……方法，该方法在……场景下取得了较好效果，但在……方面仍存在不足。
-2. 国外相关系统多侧重于……，对……问题的处理相对成熟；相比之下，国内研究更强调……[x]。
-3. 现有研究普遍关注……，但针对……这一具体业务约束的讨论仍较少[x]。
-4. 与上述工作不同，本文将研究重点收敛到……，原因在于当前项目需要优先解决……问题。
-5. 综合已有研究可以看出，……已经具备较成熟方案，但……仍然是工程落地中的难点。
-
-## 第二章技术介绍常用句式
-
-1. JWT 的无状态认证机制已在文献[x]中有较为系统的描述，本文主要关注其与角色权限边界的结合方式。
-2. 关于 Redis 分布式锁的实现原理，文献[x]给出了基础方法，本文进一步将其应用到……资源竞争场景中。
-3. 文献[x]指出状态机模型适合处理多阶段业务流转问题，这为本文设计订单状态闭环提供了理论依据。
-
-## 第三章/第四章设计引用句式
-
-1. 参考同类系统在……方面的设计经验[x]，本文在总体结构上采用了……方案。
-2. 结合文献[x]对……的讨论，以及本系统的业务边界，本文最终选择……而非……。
-3. 现有系统在……方面的处理思路为本文提供了启发，但考虑到当前项目规模，本文做了……调整。
+# 引文格式与句式模板
+
+> [!IMPORTANT]
+> 本文件中的 `[1]`、`[2]`、`[3]` 只是格式示例，不代表固定编号。
+>
+> 论文实际写作时，所有编号必须按**正文首次出现顺序**分配：
+>
+> 1. 谁先在正文第一次被引用，谁就是 `[1]`
+> 2. 下一条首次出现的文献才是 `[2]`
+> 3. 同一文献重复引用时继续沿用原编号
+> 4. 文末参考文献列表也必须按正文首次引用顺序同步排列
+
+> [!IMPORTANT]
+> 当学校未单独规定来源比例时，参考文献来源建议按以下结构控制：
+>
+> 1. 中文参考文献约 60%
+> 2. 英文参考文献约 20%
+> 3. 其他参考文献约 20%
+>
+> 其中官方文档、RFC、标准、技术手册等应归入“其他参考文献”，不能大量替代中文和英文学术文献。
+
+> [!IMPORTANT]
+> 当学校模板未给出更高数量要求时，论文终稿参考文献默认**不少于 15 条**。
+>
+> 按 15 条估算时，可直接按以下基线补齐：
+>
+> 1. 中文不少于 9 条
+> 2. 英文不少于 3 条
+> 3. 其他约 3 条
+>
+> 如果当前草稿只有 8 到 12 条文献，不要直接润色正文，应先补齐文献池再排正文编号。
+
+## GB/T 7714-2015 常见格式示例
+
+### 期刊论文
+
+格式：
+
+作者. 题名[J]. 期刊名, 年, 卷(期): 起止页码.
+
+示例：
+
+[1] 张三, 李四. 基于 Redis 的分布式锁设计与实现[J]. 计算机工程, 2023, 49(8): 120-127.
+
+### 学位论文
+
+格式：
+
+作者. 题名[D]. 城市: 学校, 年.
+
+示例：
+
+[2] 王五. 基于状态机的预约系统设计与实现[D]. 南京: 南京理工大学, 2021.
+
+### 网络资源
+
+格式：
+
+作者/机构. 题名[EB/OL]. (发布日期)[引用日期]. URL.
+
+示例：
+
+[3] VMware. Spring Boot Reference Documentation[EB/OL]. [2026-04-08]. https://docs.spring.io/spring-boot/docs/3.2.4/reference/html/
+
+## 编号排序规则
+
+1. 正文中的引文采用顺序编码制。
+2. 编号依据不是文献类型，也不是作者姓名，而是**第一次在正文中出现的先后顺序**。
+3. 如果第三章先引用某文献，而第一章没有引用它，那么它仍应按全篇第一次出现的位置参与编号。
+4. 文末参考文献列表必须与正文编号一一对应，按 `[1]`、`[2]`、`[3]` 顺序排列。
+5. 改稿后若正文引用顺序改变，必须整体重排，不能残留跳号、重复号或正文文末不一致的问题。
+
+## 来源结构建议
+
+1. 研究现状部分优先使用中文和英文学术文献，不要用官方文档充当研究成果来源。
+2. 第二章关键技术介绍可以少量引用官方文档或标准，但数量应受控。
+3. 如果正文参考文献明显被官方文档占据主体，说明来源结构失衡，需要补中文和英文论文。
+4. 对系统类本科论文，优先做到“中文文献为主、英文文献补充、其他文献兜底”。
+5. 如果学校没有特殊规定，优先把文献池扩到 15 条以上再进入终稿整理阶段。
+
+## 研究现状常用句式
+
+1. 文献[x]提出了……方法，该方法在……场景下取得了较好效果，但在……方面仍存在不足。
+2. 国外相关系统多侧重于……，对……问题的处理相对成熟；相比之下，国内研究更强调……[x]。
+3. 现有研究普遍关注……，但针对……这一具体业务约束的讨论仍较少[x]。
+4. 与上述工作不同，本文将研究重点收敛到……，原因在于当前项目需要优先解决……问题。
+5. 综合已有研究可以看出，……已经具备较成熟方案，但……仍然是工程落地中的难点。
+
+## 第二章技术介绍常用句式
+
+1. JWT 的无状态认证机制已在文献[x]中有较为系统的描述，本文主要关注其与角色权限边界的结合方式。
+2. 关于 Redis 分布式锁的实现原理，文献[x]给出了基础方法，本文进一步将其应用到……资源竞争场景中。
+3. 文献[x]指出状态机模型适合处理多阶段业务流转问题，这为本文设计订单状态闭环提供了理论依据。
+
+## 第三章/第四章设计引用句式
+
+1. 参考同类系统在……方面的设计经验[x]，本文在总体结构上采用了……方案。
+2. 结合文献[x]对……的讨论，以及本系统的业务边界，本文最终选择……而非……。
+3. 现有系统在……方面的处理思路为本文提供了启发，但考虑到当前项目规模，本文做了……调整。