dsh-thesis 1.0.0

package/package.json

@@ -0,0 +1,82 @@
+{
+  "name": "dsh-thesis",
+  "version": "1.0.0",
+  "description": "论文与答辩全流程助手（DeepSeek Harness 插件）：材料摄取 → 逐题追问 → 文献检索 → 逐章写作与评审 → 原创性自查与合规 → Word/答辩幻灯生产，全流程留痕，并跨会话记住学校规范与导师要求。",
+  "type": "module",
+  "main": "lib/index.js",
+  "exports": {
+    ".": {
+      "types": "./lib/index.d.ts",
+      "default": "./lib/index.js"
+    }
+  },
+  "files": [
+    "lib",
+    "skills",
+    "cordis.patch.yml",
+    "README.md",
+    "DESIGN.md",
+    "NOTICE.md",
+    "docs/host-api.md"
+  ],
+  "license": "MIT",
+  "author": "Paloma966",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/Paloma966/dsh-thesis.git"
+  },
+  "homepage": "https://github.com/Paloma966/dsh-thesis#readme",
+  "bugs": {
+    "url": "https://github.com/Paloma966/dsh-thesis/issues"
+  },
+  "keywords": [
+    "dsh",
+    "dsh-plugin",
+    "deepseek-harness",
+    "cordis-plugin",
+    "thesis",
+    "graduation",
+    "毕业设计",
+    "论文",
+    "答辩",
+    "GB/T 7714",
+    "原创性自查",
+    "代码演练"
+  ],
+  "dsh": {
+    "bundle": {
+      "patch": "./cordis.patch.yml"
+    }
+  },
+  "scripts": {
+    "clean": "node scripts/clean.mjs",
+    "build": "npm run clean && tsc -p tsconfig.json",
+    "typecheck": "tsc -p tsconfig.test.json",
+    "test": "node --test tests/",
+    "test:sandbox": "node --test --test-isolation=none \"tests/**/*.test.ts\" \"tests/**/*.test.mjs\"",
+    "test:e2e": "node tests/e2e/paper-full-flow.mjs",
+    "test:bench": "node tests/e2e/paper-full-flow.mjs",
+    "test:net": "node tests/e2e/paper-lit-real.mjs",
+    "test:host": "node scripts/host-smoke.mjs && node .host-smoke/app/run.mjs",
+    "test:host-load": "node scripts/host-verify.mjs",
+    "audit": "node scripts/audit-surface.mjs",
+    "verify": "npm run build && npm run typecheck && npm run test:sandbox && npm run audit && npm run test:e2e",
+    "prepublishOnly": "node scripts/prepublish-guard.mjs"
+  },
+  "engines": {
+    "node": ">=22.16"
+  },
+  "peerDependencies": {
+    "@deepseek-ai/schemastery": "^3.18.2",
+    "@deepseek-ai/cordis": "^4.0.2",
+    "@deepseek-ai/dsh-tools": "^0.1.0"
+  },
+  "peerDependenciesMeta": {
+    "@deepseek-ai/cordis": { "optional": true },
+    "@deepseek-ai/dsh-tools": { "optional": true }
+  },
+  "devDependencies": {
+    "@deepseek-ai/schemastery": "^3.18.2",
+    "typescript": "^5.9.0"
+  }
+}

package/skills/code-walkthrough/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: code-walkthrough
+description: 答辩前的代码演练：把自己的系统（常常是 AI 帮你写的）拆成讲得清的模块，造一个能编译的骨架、用真实验证门逐个走通，并用可评分的追问检验你能不能当场讲出实现细节与取舍。答辩最常失分的地方就是「你的系统怎么实现的」答不上来。当用户说「答辩前我要搞懂自己系统」「老师会问实现细节」「帮我理清这套代码好答辩」时使用。
+whenToUse: 答辩前准备「实现细节/技术选型」类问题；`thesis_defense` 生成了预答辩问题库需要逐个准备；用户对自己系统的实现不熟、怕被追问；导师要求解释某段代码时。
+---
+
+# 代码演练：把「AI 写的系统」变成「你讲得清的系统」
+
+**你（AI）的角色**：陪练，不是答案机器。学生要的不是"看懂一遍"，而是**在答辩席上被追问三层还能答上来**。
+所以你的任务是逼出理解，不是给出解释。
+
+## 为什么这件事决定成败
+
+答辩委员无法验证你的代码是不是你写的（他们只有十分钟），所以只能用追问来测：
+「这个模块为什么这么分？」「并发冲突你怎么处理的？」「为什么用 Redis 不用本地缓存？」
+**答不上来的那一刻，论文写得再好也会被怀疑。** 这是本插件把「代码演练」放进答辩层的唯一理由。
+
+反过来说：答辩前把系统真正走通一遍的学生，不仅能答，还能**主动**讲出取舍——这是加分项。
+
+## 铁律
+
+1. **验证门必须真跑**。`defense_code_update action=check_gate` 会实际执行编译命令并记录退出码；
+   没有 gate 记录的里程碑**永远不能**标记为已验证。跑不过就是跑不过，不允许"看起来应该能跑"。
+2. **骨架要能编译**。剥掉非核心功能后留下的 TODO 桩必须让整个项目通过编译——
+   一个编译不过的骨架只会浪费学生的时间。
+3. **期望答案要点只用于评分**（`defense_code_next` 会返回 `expected` 与 `hints`）。
+   **绝不把 expected 原文展示给学生**——那样他记住的是答案，不是理解。
+4. **提示要阶梯式给**。学生卡住时先给一条 hint，还不行给下一条，最后才讲答案。
+   直接公布答案等于放弃这次演练。
+5. **一次一个里程碑**。走完再进下一个；跳过 todo 的学生在答辩时会在那里被问倒。
+
+## 标准流程
+
+```
+defense_code_status          # 1. 看当前位置（阶段 / 里程碑 / todo / 未通过的问题）
+   ↓
+defense_code_next            # 2. 取当前里程碑：todo 列表 + 验证门 + 待答问题（含评分要点）
+   ↓
+   ├─ 和学生过 todo（他自己动手，你解释"为什么这样设计"）
+   ├─ defense_code_update action=ask_question     # 3. 提一个追问
+   ├─ 学生回答 → 你对照 expected 评分 → action=assess_answer passed=true/false
+   ├─ 学生卡住 → action=give_hint（一次一条，不要一次给完）
+   └─ /thesis-defense check <里程碑>              # 4. 真跑验证门
+   ↓
+全部问题通过 + 验证门为绿 → 里程碑 verified
+   ↓
+defense_code_update action=advance_phase      # 5. 直到 complete
+```
+
+## 第一次使用：建立演练
+
+```
+/thesis-defense new <你的项目绝对路径> [--lang go] [--level beginner|intermediate|advanced] [--module 子模块]
+```
+
+然后由你（AI）分析项目并把结构登记成 todo 与里程碑：
+
+- `defense_code_update action=upsert_todo`：一个可动手的小任务（读数据模型、实现某个 CRUD、接一个接口）。
+- `defense_code_update action=upsert_milestone`：一组相关 todo，配一个验证门与若干追问。
+- 难度从 1（读数据模型、改一个 handler）到 4（并发、分布式协同、性能调优）；
+  **必须从简单开始**，学生第一步就跑不通会直接放弃。
+
+## 问题从哪来
+
+最好的追问来源是**答辩现场真的会问的**：
+
+| 类型 | 例子 | 为什么要问 |
+|---|---|---|
+| 实现细节 | 「这个请求进来后经过了哪几个函数？」 | 验证代码是不是你写的 |
+| 技术选型 | 「为什么用 A 不用 B？」 | 验证你有没有判断力 |
+| 失败处理 | 「数据库连不上时会发生什么？」 | 验证你想过边界 |
+| 数据流 | 「这条数据从哪儿来到哪儿去？」 | 验证你理解整体而不是片段 |
+| 权衡 | 「如果数据量涨十倍，哪里先崩？」 | 验证深度 |
+
+`thesis_defense` 生成的 `07-答辩/预答辩问题库.md` 里的「实现细节」一节就是演练清单。
+
+## 状态存在哪
+
+`<会话 cwd>/.paper/code-walkthrough.json`（可用配置 `codeWalkthrough.stateDir` 改）。
+状态只在状态文件变化时才注入上下文卡片，因此长演练不会一直占用 token。
+换会话、换机器都不丢：读回状态就能从正确的里程碑继续。
+
+## 与其他技能的分工
+
+| 你要做的事 | 用哪个 |
+|---|---|
+| 论文怎么组织、章节怎么验收 | `thesis-writing` / `thesis-pipeline` |
+| 答辩幻灯结构与问题库 | `thesis-defense` |
+| **把系统搞懂、被追问到能自证** | **本技能**（配 `defense_code_*` 三个工具与 `/thesis-defense` 命令） |
+
+## 完成的标准
+
+不是「状态变成 complete」，而是：**你能合上电脑，用五分钟讲清系统的架构、三条关键取舍、以及一个你踩过的坑。**
+状态是手段，这段讲述才是目的。演练结束时请学生真的讲一遍——这是最后一次免费试错的机会。

package/skills/code-walkthrough/references/examples.md

@@ -0,0 +1,129 @@
+# Worked example: gopherCron-style scheduler
+
+A hypothetical distributed cron scheduler (modeled after gopherCron) walked
+through every phase, with the tool calls the AI makes at each step.
+
+## Phase 1 — Analyzing
+
+Correct: state the analysis before modifying anything.
+
+> This is a distributed cron scheduling system with two components:
+>
+> **Center** — manages tasks via HTTP API, stores metadata in MySQL, uses
+> etcd for real-time task distribution and service discovery.
+>
+> **Agent** — runs on worker nodes, receives tasks via gRPC, schedules them
+> locally with cron expressions, executes shell commands, reports results.
+>
+> Core data flow: Create task → Store in etcd → Agent watch picks it up →
+> Scheduler triggers at cron time → Executer runs the shell command →
+> Report to Center → Center logs to MySQL.
+>
+> I'll keep: task CRUD in etcd, the Agent scheduling loop, command
+> execution, result reporting. I'll strip: workflow orchestration,
+> webhooks, OIDC auth, Prometheus metrics, Admin UI, temporary tasks, RBAC.
+
+Wrong: jumping straight to deleting files with no analysis — the learner
+gets no chance to correct the scope.
+
+The AI records the domain model, e.g. `ai_learning_update` with
+`upsert_todo` for `common.TaskInfo` reading (difficulty 1), the etcd store
+(difficulty 2), and the agent watch loop (difficulty 3).
+
+## Phase 2 — Skeletonizing
+
+Correct: an annotated stub with steps, hints, and a trap.
+
+```go
+// SaveTask persists a task to etcd. Called when the user creates or updates
+// a task through the Center API.
+//
+// TODO t3 (★★): Implement task persistence
+//   1. JSON-marshal the TaskInfo struct
+//   2. Build the etcd key: common.BuildKey(task.ProjectID, task.TaskID)
+//   3. Write with clientv3.WithLease() so the key auto-expires on crash
+//   Hint: a.etcd.KV().Put(ctx, key, value, clientv3.WithLease(leaseID))
+//   Trap: without a lease, dead tasks accumulate forever
+func (a *app) SaveTask(task *common.TaskInfo, opts ...clientv3.OpOption) (*common.TaskInfo, error) {
+    return nil, fmt.Errorf("TODO t3: SaveTask not implemented")
+}
+```
+
+Wrong: `// TODO` and a nil return — no guidance.
+Wrong: deleting the `App` interface because it "looks complex" — the
+learner loses the dependency graph between handlers and the app layer.
+
+The AI verifies the skeleton compiles (`go build ./...`), records
+milestones, and advances to `learning`.
+
+## Phase 3 — Milestones
+
+```json
+{
+  "id": "m2",
+  "title": "Task CRUD in etcd",
+  "todos": ["t3", "t4", "t5", "t6"],
+  "gate": { "build": ["go", "build", "./..."] },
+  "questions": [
+    {
+      "ask": "Why are tasks stored in etcd instead of MySQL?",
+      "expected": [
+        "Agents need push-style notification; etcd Watch gives real-time prefix subscription",
+        "MySQL has no built-in push; polling would add latency and load",
+        "etcd leases give automatic cleanup for crashed Centers"
+      ],
+      "hints": [
+        "Think about how the Agent learns that a new task exists",
+        "What mechanism does MySQL lack for real-time notification?"
+      ],
+      "status": "unasked",
+      "hintLevel": 0
+    }
+  ],
+  "status": "pending"
+}
+```
+
+## Phase 4 — Learning and checking
+
+The learner implements t3–t6 and says "done". The AI reviews the code
+against the original, then runs the gate:
+
+```
+ai_learning_update { action: "check_gate", milestoneId: "m2" }
+→ gate "go build ./..." passed — milestone "m2" verified.
+```
+
+A failing gate looks like:
+
+```
+→ gate "go build ./..." failed (exit code 1); milestone marked failed.
+  stderr tail: internal/store/task.go:42: undefined: clientv3
+```
+
+The learner fixes it; the next `check_gate` retries automatically.
+
+## Phase 5 — Graded follow-up questions
+
+```
+AI: Your CRUD compiles and the gate is green. One question: you used a
+    plain KV.Put. The original passes opts ...clientv3.OpOption — what
+    would a caller use that for?
+
+User: Um, etcd is faster?
+
+AI: [weak answer — one hint] Think about what should happen to the task
+    key when the Center process dies. Then: how does the Agent learn a
+    new task was created — what mechanism would MySQL be missing?
+
+User: Oh — leases so keys expire, and etcd Watch pushes prefix events
+    that MySQL can't.
+
+AI: [compare against expected points] Both points landed. One more: walk
+    me through two Centers saving the same task simultaneously — does
+    anything break?
+```
+
+The model grades against `expected` through `assess_answer`; never prints
+the key. When the milestone's gate is green and all questions pass, the
+next milestone starts — or the exercise completes.

package/skills/paper-dedup/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: paper-dedup
+description: 论文降重的诚实做法。用本地相似度度量找出与参考语料/往届论文/文献笔记高度重合的段落，给出「必须保留什么、可以怎么改」的改写处方，改完复测降幅。核心原则：降重是让表达成为你自己的，不是洗稿，更不是改数据。当用户提到查重、重复率、降重、AI 检测、大段引用，或 `thesis_check` 报出高风险段落时使用。
+whenToUse: 用户问「查重能过吗」「帮我降重」「这段话重复率高怎么办」；定稿前做合规自查（G4）；从参考文献/往届论文借用了表述需要改成自己的话；`thesis_stylecheck` 与原创性报告同时命中同一段落时。
+---
+
+# paper-dedup：降重是写作，不是洗稿
+
+## 立场（先讲清，否则会做错）
+
+- **重复率不是靠换词降下来的**。把"系统采用三层架构"改成"本系统运用三层架构设计"既骗不过检测算法，也让论文更糟。
+- **真正的降重只有三条路**：① 换成你自己的理解去说（推荐）；② 确实需要别人的原话 → 规范引用（直接引用 + 著录）；③ 内容本来就不该出现在这里 → 删。
+- **不可触碰的红线**：实验数据、结论、术语、公式、代码标识符、引用标记，**一个都不能为了降重而改**。改动这些是学术不端，比重复率超标严重得多。
+- **边界诚实**：本插件的度量是本地、确定性、可复现的估算，**不接入**知网/维普等收费系统（无账号也不该接入）。报告里的"估算重复率"与学校检测结果不可等同；用户自行送检后可用 `detected_rate` 回填，形成自己的对照记录。
+
+## 标准流程
+
+```
+thesis_originality action=scan     # 1. 扫描：正文各章 vs 参考语料（02-文献/笔记、00-管理/材料、正文互查）
+                             #    → 08-合规/原创性报告.md：分级(high/medium/low) + 行号 + 命中来源 + 处方
+   ↓
+逐段处置                      # 2. 按处方改写（模型改写，用户过手）——处方说明必须保留什么
+   ↓
+thesis_originality action=verify   # 3. 复测：与 baseline 报告对比，给出降幅与仍高风险的段落
+   ↓
+thesis_check +               # 4. 全文一致性：引用双向一致、编号、术语（改写最容易碰坏这三样）
+thesis_stylecheck
+   ↓
+thesis_originality action=report   # 5. 汇总报告（可回填学校检测结果）；G4 自查的输入之一
+```
+
+## 改写处方怎么读
+
+每条高风险段落会给出一份处方，字段含义：
+
+| 字段 | 含义 | 你要做什么 |
+|---|---|---|
+| 得分与来源 | 与哪段文字重合、重合多少 | 先判断：这是**该引用**还是**该换说法** |
+| 必须保留 | 数字、单位、术语、公式、引用标记 `[n]`、代码标识符 | 原样照抄，不得替换 |
+| 可替换句式 | 长句拆分、主被动转换、并列改递进、去冗余连接词 | 挑一条执行，别全用 |
+| 引用化建议 | 命中来源是文献/他人文字 | 改为直接引用 + 标注，或重述后标注 |
+| 禁止事项 | 不得为降重改动数据与结论 | 违反即学术不端 |
+
+## 中文降重的有效手法（按收益排序）
+
+1. **换成你的证据**：用你自己系统的真实数据、截图、日志细节替换泛泛而谈的通用表述。这是最有效的降重，也是最涨分的。
+2. **改变论证顺序**：先结论后论据 ↔ 先现象后归纳；把"技术选型→实现→效果"改成"问题→约束→为什么这个选型能解"。
+3. **具体化**：把"性能良好"改成"在 X 条记录下平均响应 230ms（表 5-2）"。抽象句天然与别人的抽象句撞车。
+4. **图表化**：能用一张表说清的对比，别写成三段并列文字。
+5. **拆分与合并**：长句拆短（学术写作允许短句）；或把三句碎句合成一句带从句的判断。
+6. **术语一致后再谈改写**：术语必须全文统一（`thesis_check` 会查），不统一时优先统一，而不是换成同义词。
+7. **确实要保留原话** → 规范引用，这不算重复。
+
+## 与 AI 味的联动
+
+高重复与"AI 味"经常同源：空洞的排比、无锚点的总结段、翻译腔的被动句。
+`thesis_stylecheck` 报出的问题段落若同时在原创性报告里是 high 风险，**优先整段重写**（用你自己的实验细节重写），
+而不是逐句换词——这是唯一能同时压掉重复率和 AI 味的做法。

package/skills/paper-intake/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: paper-intake
+description: 材料到手后的逐题追问方法论。把学校模板、论文要求、实验数据、代码、参考文献等材料，逐题问成一份可证伪的《意图规格》——每篇论文只问一次，答不全的显式列为阻塞项。当用户丢来一堆材料、说「按学校要求写」「帮我做毕业设计」，或需要确认格式/字数/查重/时间线等约束时使用。
+whenToUse: 用户刚提供材料（学校模板/要求文档/实验数据/代码/文献）之后；开始写作前需要确认验收标准时；`thesis_intake status` 显示仍有阻塞项时；换了论文课题需要重新立规格时。
+---
+
+# paper-intake：一次问到位
+
+## 为什么需要它
+
+AI 写论文最大的浪费不是写错，而是**写对了你不需要的东西**：按通用模板排了一版，结果你们学校要求页边距 3cm；
+写了 1.8 万字，学校要求 1.2 万；参考文献排在文末，学校要脚注式；实验数据用的是模拟数据，导师要真实运行结果。
+这些都是**一次追问就能消除的返工**，而不问的代价是整章重写。
+
+追问助产术在这里的用法：**承认无知 → 下定义 → 反例检验 → 暴露矛盾 → 收敛留痕**。
+规格文档就是"留痕"的产物。
+
+## 铁律（缺一条就退化成烦人表单）
+
+1. **一次只问一个问题**。工具每次只返回一个问题；模型不得把整张问卷一次性倒给用户。
+2. **问题必须由人回答**。模型不得替用户猜测后直接开写；用户答"不知道"时给 `hint`（去哪找：教务处网站、学长模板、导师），而不是替他决定。
+3. **便宜**。每个问题都要说清「为什么问」「影响哪个产出物」，让用户一眼判断值不值得答。
+4. **有终止条件**。规格可证伪即停；`required` 项齐全即可进入写作，其余标为已知缺口，绝不无限追问。
+5. **材料优先**。材料清单里已经能读出来的（如学校模板文件已存在），不再问，只请用户确认。
+6. **绝不覆盖**。规格文档可以重渲染，但已回答的答案永不丢失。
+
+## 标准流程
+
+```
+thesis_ingest            # 1. 先摄取材料：docx/xlsx/pptx/pdf/md/csv → 文本 + 材料清单
+   ↓
+thesis_intake start      # 2. 立规格会话（读取材料清单，跳过已能从材料回答的问题）
+   ↓
+thesis_intake ask        # 3. 取一个问题 → 原样转达给用户（不要改写、不要附答案）
+   ↓
+thesis_intake answer     # 4. 用户回答 → 记录 → 自动刷新《意图规格》→ 返回下一个问题
+   ↓ （循环 3-4，直到 required 齐全）
+thesis_intake done       # 5. 校验必答项；不齐则列出缺口并拒绝完成
+   ↓
+00-管理/意图规格.md       # 6. 唯一真相：后续写作/构建/检查/降重/PPT 都以它为准
+```
+
+## 追问覆盖域（问题库的骨架）
+
+| 分节 | 典型问题 | 不答的代价 |
+|---|---|---|
+| 学校与规范 | 学校/学院/专业、学位类型、**学校模板文件拿到了吗** | 格式检查与 docx 排版全部失真 |
+| 课题 | 题目、方向、导师给定还是自选 | 选题工作坊无法给出备选 |
+| 字数 | 正文字数要求、各章分配 | 章节评审的字数区间失去意义 |
+| 查重 | 查重系统、重复率阈值 | 降重没有目标线 |
+| AI 政策 | 学校对 AI 使用的明文规定 | 合规策略无从谈起（这是红线，必须问） |
+| 时间线 | 开题/中期/查重/答辩日期 | 排期与催办失效 |
+| 技术栈与代码 | 技术栈、**已有代码位置** | 实现章节写成空谈，答辩素材无来源 |
+| 数据 | 实验数据来源、**是否已有真实运行结果** | 零假数据红线无法保证 |
+| 文献 | 数量要求、年限要求、引用格式（GB/T 7714？） | 文献综述与著录格式返工 |
+| 答辩 | 形式、PPT 页数、时长、是否盲审 | 答辩材料方向错 |
+| 图表公式 | 编号规范、图题表题位置 | 全文编号返工 |
+
+## 与其它工具的配合
+
+- `thesis_ingest` 的产物 `00-管理/材料清单.md` 是本技能的输入；清单里出现学校模板 → 不再重复问模板。
+- 用户对某个技术方向拿不定主意时，转 `thesis_decide` 记录决定（内容/理由/备选），答辩时要用。
+- 结论写回规格后，用 `fact_remember` 把**跨课题复用**的稳定事实（学校规范、导师偏好、你的写作风格偏好）存进跨会话事实，key 用 `thesis.<课题 slug>.<属性>` 或 `user.<属性>`。
+- 规格确认后进入 `thesis-pipeline` 的阶段流程；闸门 G1/G3 的输入就是这份规格。

package/skills/thesis-citation/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: thesis-citation
+description: 参考文献引用规范（GB/T 7714-2015 顺序编码制）。用于论文与开题报告的引用标注、文末参考文献表著录、文献库与正文的双向一致性检查。
+---
+
+# 引用规范（GB/T 7714-2015）
+
+**红线**：每条参考文献必须真实存在、真实检索所得（见 thesis-literature）。本技能只解决"格式对不对"，不解决"文献假不假"——后者由检索留痕保证。
+
+## 1. 引用体系：顺序编码制
+
+- 正文引用处以上标或方括号标注序号：[1]、[2-4]、[1,3]。
+- 文末参考文献表**按正文首次出现的顺序编号**，不是按字母序。
+- 同一文献多次引用用同一序号。
+- 格式细节以学校规范文件为准（06-论文/assets/学校模板/）；以下为 GB/T 7714-2015 通用形式。
+
+## 2. 主要文献类型著录格式
+
+| 类型 | 标识 | 著录格式（要点） |
+|---|---|---|
+| 期刊论文 | [J] | 作者. 题名[J]. 刊名, 年, 卷(期): 起止页码. |
+| 专著 | [M] | 作者. 书名[M]. 版本. 出版地: 出版者, 年: 页码. |
+| 学位论文 | [D] | 作者. 题名[D]. 城市: 学校, 年. |
+| 会议论文 | [C] | 作者. 题名[C]//会议录名. 出版地: 出版者, 年: 页码. |
+| 电子文献 | [EB/OL] | 作者. 题名[EB/OL]. (发布日期)[引用日期]. URL. |
+| 标准 | [S] | 标准编号, 标准名称[S]. |
+| 专利 | [P] | 申请者. 专利名: 专利号[P]. 公告日期. |
+
+通用细则：
+- 作者 3 人以内全列；超过 3 人列前 3 人后加", 等"。
+- 英文作者姓前名后、名字缩写（如 `VASWANI A, SHAZEER N, PARMAR N, et al.`）。
+- 中文文献标点用中文标点；英文文献用英文标点。
+- 有 DOI 的可附 DOI；电子文献必须附 URL 与引用日期。
+
+### 2.1 完整示例（照此格式书写）
+
+```
+[1] 王伟, 李强, 张敏. 基于深度学习的目标检测算法综述[J]. 计算机学报, 2021, 44(5): 801-820.
+[2] VASWANI A, SHAZEER N, PARMAR N, et al. Attention is all you need[C]//Advances in Neural Information Processing Systems. Long Beach: Curran Associates, 2017: 5998-6008.
+[3] 陈晨. 基于卷积神经网络的课堂行为识别系统设计与实现[D]. 北京: 北京邮电大学, 2022.
+[4] HE K, ZHANG X, REN S, et al. Deep residual learning for image recognition[C]//Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. Las Vegas: IEEE, 2016: 770-778.
+[5] DEVLIN J, CHANG M W, LEE K, et al. BERT: pre-training of deep bidirectional transformers for language understanding[EB/OL]. (2019-05-24)[2026-02-10]. https://arxiv.org/abs/1810.04805.
+[6] 国家标准化管理委员会. GB/T 7714—2015, 信息与文献 参考文献著录规则[S]. 北京: 中国标准出版社, 2015.
+```
+
+## 3. 正文标注细则
+
+- 引用标注放在所引内容之后、**句号之前**："…方法在图像分类中取得显著效果[3]。"
+- 作为句子成分时融入正文："文献[3]提出了一种…方法"。
+- 多处支撑一个论断：`[2,5-7]`；连续编号用连字符：`[2-4]`。
+- **每章至少为绪论与相关技术章必须带引用**（thesis_review 会检查引用编号与 refs.bib 的对应关系）。
+- 摘要、致谢、图表标题中不出现引用标注；附录中的引用与正文共享同一编号体系。
+- **每条正文引用都能在 refs.bib 找到，refs.bib 每条都被正文引用**（thesis_check 会校验双向一致）。
+
+## 4. 常见错误（写作与检查时对照）
+
+- 文末顺序与正文首次出现顺序不一致。
+- 电子文献漏 URL/引用日期。
+- 作者缩写格式混乱（`A. Vaswani` 应作 `VASWANI A`）。
+- 引用了从未读过的文献（间接引用）：应标注"转引自"或找到原文献读后再引。
+- 文献"躺尸"：refs.bib 有但正文没引用——检查时删除或补引。
+
+## 5. 与文献库的协作
+
+- 收录文献：thesis_lit_save 写入 02-文献/refs.bib（含 DOI/URL）。
+- 写作时：只引用 refs.bib 中条目；正文标注序号，文末著录由构建工具（M4）自动生成或手工按本节格式书写。
+- 检查时：thesis_check 输出"正文引用 ↔ refs.bib"双向差异清单。

package/skills/thesis-defense/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: thesis-defense
+description: 答辩准备方法论。用于阶段 9：答辩 PPT 大纲（10-12 页标准结构）、预答辩问题库与答题思路、模拟问答演练流程。
+---
+
+# 答辩准备
+
+**答辩的本质**：老师验证两件事——①系统是你做的（问实现细节）②你懂你的设计（问为什么）。
+准备的核心不是背稿，而是**把决定日志与设计文档里的"为什么"讲顺**。
+
+## 1. PPT 大纲（10-12 页，模板在 07-答辩/PPT大纲.md）
+
+每页原则：**图多字少、一页一个观点、真实截图优先**。
+
+| 页 | 内容 | 要点 |
+|---|---|---|
+| 1 | 封面 | 课题/学生/导师 |
+| 2 | 目录 | 与讲述顺序一致 |
+| 3 | 背景与意义 | 1 页讲清痛点，用图/数据 |
+| 4 | 国内外现状 | 一图带过，落点是"现有不足 → 本课题" |
+| 5 | 需求分析 | 功能点列表/用例图 |
+| 6 | 系统总体设计 | 架构图（和论文图一致） |
+| 7-9 | 关键实现 | 每页一个模块：截图/核心代码/设计取舍；**这是老师最细看的部分** |
+| 10 | 测试 | 真实数据图 + 结论 |
+| 11 | 总结与展望 | 已完成 + 不足（诚实） |
+| 12 | 问答页 | "谢谢，请各位老师指正" |
+
+## 2. 预答辩问题库（结合你的材料生成）
+
+每类问题对应准备材料，逐一准备：
+
+| 问题类型 | 示例 | 准备材料 |
+|---|---|---|
+| 实现细节 | "X 模块具体怎么实现的？" | 04-实现 代码 + 答辩演练记录 |
+| 技术选型 | "为什么用 A 不用 B？" | 03-设计/技术选型论证.md + 决定日志 |
+| 需求来源 | "这个需求怎么来的？" | 03-设计/需求分析.md |
+| 工作量 | "哪些部分是你做的？" | git 提交记录 + 决定日志（诚实说明 AI 辅助，强调自己做的设计决策与验证） |
+| 数据可信 | "测试数据怎么得到的？" | 05-实验测试/结果 + 复现步骤 |
+| 不足 | "你觉得哪里没做好？" | 论文第 7 章不足与展望（提前准备 2-3 个诚实不足 + 改进方向） |
+| 创新点 | "你的工作有什么亮点？" | 绪论"本文主要工作" + 对比实验 |
+
+**答题心法**：先结论后展开；答不上来的诚实说"这里我考虑得不够，之后可以…"；不要辩解式回答。
+
+## 3. 模拟问答演练流程
+
+1. 运行 `thesis_defense`：提取《答辩素材》（章节概览/技术选型/关键决定/测试数据/git 工作量）并生成《预答辩问题库》骨架。
+2. 依据《答辩素材》把问题库中的 <> 占位替换为系统实际名称，生成 15-20 个具体问题；每个问题都要能回答到证据锚点（如"选型理由见技术选型论证.md 第 2 行"）。
+3. 用户口头回答 → 记录要点到 07-答辩/问答演练.md。
+4. 对答不上来的问题：回到对应材料补学，把答案写进演练记录；**"你的系统怎么实现的"这类问题用 `defense_code_*` 走一遍代码演练**（技能 `code-walkthrough`），不要靠背答案。
+5. 至少完整演练 2 轮；第 2 轮随机抽题。
+
+## 4. 答辩前清单
+
+- [ ] PPT 与论文数据、截图一致（零伪造）
+- [ ] 系统在演示电脑上真实跑通（提前装环境、准备离线演示兜底）
+- [ ] 常见问题 15 个以上有演练记录
+- [ ] 决定日志通读一遍（"为什么这么做"全都有答案）
+- [ ] 实现细节类问题过了代码演练（`defense_code_status` 显示自己系统讲得清）
+- [ ] 诚实原则：AI 辅助了哪些、自己做了哪些，能清晰表述
+
+---
+
+## 幻灯产出链路（`thesis_slides`）
+
+**Markdown 是唯一真相**：幻灯源文件是 `07-答辩/PPT.md`（Marp 兼容），`.pptx` 只是它的派生产物。
+这样幻灯可以被 git diff、可以在答辩前一天晚上还敢改，也不依赖任何 Office 版本。
+
+```
+thesis_defense          → 07-答辩/答辩素材.md + 07-答辩/预答辩问题库.md
+thesis_slides outline      → 07-答辩/PPT.md（10-12 页，每页含讲稿要点与证据锚点）
+thesis_slides check        → 页数/要点数/字数/讲稿/锚点/时长 六项确定性检查
+thesis_slides convert      → 探测 marp / npx marp-cli / pandoc；有则产出 07-答辩/PPT.pptx
+                          没有则写 07-答辩/PPT转换说明.md（含可直接复制的命令与兜底方案）
+thesis_slides guide        → 只输出转换指引，不执行
+```
+
+等价斜杠命令：`/thesis-defense prepare [页数] [undergrad|master] [force]`、`convert`、`check`、`guide`。
+
+硬约束（`check` 会逐条查）：每页要点 3-6 条、单条 ≤ 30 字、每页必须有讲稿与证据锚点、
+不得出现"待补充/TODO"、预计时长 8-12 分钟（每页 40-60 秒）。
+
+**证据锚点为什么是硬要求**：老师问"这个数据哪来的"时，你必须能在 3 秒内点到具体文件
+（`05-实验测试/结果/xxx.csv`、`06-论文/章节/06-系统测试.md`），而不是说"我记不清了"。
+
+**无 marp/pandoc 时怎么办**（离线常见）：`thesis_slides convert` 会给出三条路——
+① `npx --yes @marp-team/marp-cli PPT.md --pptx`（有网即可，免安装）；
+② pandoc（`pandoc PPT.md -o PPT.pptx`）；③ 把 `PPT.md` 粘到 marp 网页版或用 WPS/PPT 手工成稿（幻灯文字已是最终稿，成稿只是排版）。