refactor: rename template files to English and update file paths in docs

2026-08-26 17:13:57 +08:00
parent a05a3f5126
commit 9c88db6d0f
12 changed files with 145 additions and 24 deletions
@@ -13,22 +13,22 @@ created: 2026-08-21

 **使用方法：** 不要先研究工具。直接复制本文件，为一个公开文档问答小任务填写空白处。只要完成到“10 个 case + rubric + 一次盲评”，就已经完成了真正的第一步。

-> **填完放哪：** 填写完成的副本**复制进 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|03-Practice]] 下你的项目目录**（骨架见 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览|03-Practice/_template/]]），本文件只保留空白模板，供以后复用。
+> **填完放哪：** 填写完成的副本**复制进 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|03-Practice]] 下你的项目目录**（骨架见 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-project-overview|03-Practice/_template/]]），本文件只保留空白模板，供以后复用。

 > **与路线图的关系：** 本工作表是《LLM 评测工程实战路线图》Day 1—3 的填空版，按“首周最低 10 个 case”设计；若时间充裕，可按路线图扩展至 20 个。

 ### 填写内容 → 项目文件的对应关系

-工作表填完后，把内容按下面的对应关系整理进项目目录（骨架见 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览|03-Practice/_template/]]）：
+工作表填完后，把内容按下面的对应关系整理进项目目录（骨架见 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-project-overview|03-Practice/_template/]]）：

 | 工作表小节 | 对应项目文件 |
 |---|---|
-| 第 0 节：任务边界 | `00-项目概览.md`（问题/成功条件/风险）+ `01-任务与Rubric.md`（任务边界表） |
-| 第 1 节：Rubric v0.1 | `01-任务与Rubric.md` |
-| 第 2 节：10 个 case | `02-Case设计.md` |
-| 第 3-4 节：候选与盲评 | `03-运行与盲评.md` |
-| 第 5 节：失败分类 | `04-失败复盘.md` |
-| 第 6 节：修改与回归 | `05-变更与回归.md` |
+| 第 0 节：任务边界 | `00-project-overview.md`（问题/成功条件/风险）+ `01-task-and-rubric.md`（任务边界表） |
+| 第 1 节：Rubric v0.1 | `01-task-and-rubric.md` |
+| 第 2 节：10 个 case | `02-case-design.md` |
+| 第 3-4 节：候选与盲评 | `03-run-and-blind-review.md` |
+| 第 5 节：失败分类 | `04-failure-review.md` |
+| 第 6 节：修改与回归 | `05-change-and-regression.md` |

 > 也就是说：工作表 = 第一次闭环的线性填空；项目目录 = 长期项目的分文件结构。填完工作表后把内容迁移进项目目录，就进入长期迭代（对应学习看板 Level 2 → Level 3）。

@@ -46,6 +46,8 @@ created: 2026-08-21
 | 非目标 | 例如：不评价文档外的常识正确性 |
 | 数据来源 / 许可 | 例如：Python 官方文档某页面，记录 URL 与日期 |

+- [ ] 已把输入上下文原文（文档片段/工具定义）粘贴并冻结（含抓取日期），放入项目 `02-case-design.md` 顶部"输入上下文（冻结快照）"小节
+
 ### 停下来检查

 如果你仍写的是“回答要专业”或“Agent 要聪明”，说明范围还不够小。把它改成一个可观察行为：引用、拒答、工具参数、权限、状态变化或可执行性。
@@ -31,6 +31,7 @@ created: 2026-08-24

 - 来源：Go 官方文档 Module release and versioning workflow ／ URL：https://go.dev/doc/modules/release-workflow ／ 日期：2026-08-24
 - 许可：Go 文档（BSD 风格）／ PII 政策：N/A（公开技术文档，无个人数据）
+- 输入上下文正文：冻结于 `02-case-design.md` 顶部"输入上下文（冻结快照）"小节

 ## 主要风险

@@ -49,7 +50,8 @@ created: 2026-08-24

 ## 下一步最小动作

- [ ] 填写 `01-task-and-rubric.md` 的 rubric 三维度（对应 [[02-First-Week-Worksheet]] 第 1 节）
+- [x] 填写 `01-task-and-rubric.md` 的 rubric 三维度（对应 [[02-First-Week-Worksheet]] 第 1 节）
+- [ ] 对着 `02-case-design.md` 顶部"输入上下文（冻结快照）"填写 10 个 case

 ---

@@ -19,6 +19,8 @@ status: active
 | 非目标       | 不评价文档外的 Go 常识（semver、/v2 后缀、go get 细节等）                                                                    |
 | 数据来源 / 许可 | 来源 Go 官方文档 release-workflow 页；URL https://go.dev/doc/modules/release-workflow；日期 2026-08-24；BSD 风格；PII：N/A |

+> 输入上下文原文（文档片段等）冻结于 `02-case-design.md` 顶部快照；本表只记录出处与许可，不复制原文。
+
 ## Rubric v0.1（对应工作表第 1 节）

 | 维度                | 通过条件                                                    | 失败条件                  | 正例                                                                                                                                  | 反例                                                        |
@@ -0,0 +1,96 @@
+---
+type: project
+status: active
+---
+
+# 02 · Case 设计
+
+> 权威分布表：20-case 配比见 [[01-LLM-Evaluation-Roadmap]] Day 1；10-case 结构见 [[02-First-Week-Worksheet]] 第 2 节。第一版 10-20 个即可。
+
+## 输入上下文（冻结快照）
+
+> 每个 case 的输入 = question + context。context 就是下面这段原文。判"文档能否完整回答"、盲评判"有据性"都以它为界。建数据集时，这段原文原样搬入每个 case 的 `input.context`。
+
+- 来源：Go 官方文档 "Module release and versioning workflow"（Common workflow steps 一节）／ URL：https://go.dev/doc/modules/release-workflow ／ 抓取日期：2026-08-26
+- 许可：Go 文档（BSD 风格）／ PII：N/A（公开技术文档，无个人数据）
+- 边界说明：本片段仅含该页 "Common workflow steps" 一节；凡片段未覆盖内容（预发布版本号格式、发布命令/打 tag 操作、v1 稳定性承诺细节、major 版本 /v2 步骤等）一律视为"资料不足"。
+
+### 原文（Common workflow steps）
+
+The following sequence illustrates release and versioning workflow steps for an example new module. For more about each step, see the sections in this topic.
+
+- **Begin a module and organize its sources** to make it easier for developers to use and for you to maintain.
+
+  If you're brand new to developing modules, check out Tutorial: Create a Go module.
+
+  In Go's decentralized module publishing system, how you organize your code matters. For more, see Managing module source.
+
+- **Set up to write local client code that calls functions in the unpublished module.**
+
+  Before you publish a module, it's unavailable for the typical dependency management workflow using commands such as `go get`. A good way to test your module code at this stage is to try it while it is in a directory local to your calling code.
+
+  See Coding against an unpublished module for more about local development.
+
+- **When the module's code is ready for other developers to try it out, begin publishing v0 pre-releases such as alphas and betas.** See Publishing pre-release versions for more.
+
+- **Release a v0 that's not guaranteed to be stable, but which users can try out.** For more, see Publishing the first (unstable) version.
+
+- **After your v0 version is published, you can (and should!) continue to release new versions of it.**
+
+  These new versions might include bug fixes (patch releases), additions to the module's public API (minor releases), and even breaking changes. Because a v0 release makes no guarantees of stability or backward compatibility, you can make breaking changes in its versions.
+
+  For more, see Publishing bug fixes and Publishing non-breaking API changes.
+
+- **When you're getting a stable version ready for release, you publish pre-releases as alphas and betas.** For more, see Publishing pre-release versions.
+
+- **Release a v1 as the first stable release.**
+
+  This is the first release that makes commitments about the module's stability. For more, see Publishing the first stable version.
+
+- **In the v1 version, continue to fix bugs and, where necessary, make additions to the module's public API.**
+
+  For more, see Publishing bug fixes and Publishing non-breaking API changes.
+
+- **When it can't be avoided, publish breaking changes in a new major version.**
+
+  A major version update – such as from v1.x.x to v2.x.x – can be a very disruptive upgrade for your module's users. It should be a last resort. For more, see Publishing breaking API changes.
+
+## Case 列表（对应工作表第 2 节）
+
+| 编号  |   类别 | 问题  | 文档能否完整回答 | 预期系统行为 | case 状态   |
+| --- | ---: | --- | -------- | ------ | --------- |
+| 01  | 正常路径 |     | 是        |        | candidate |
+| 02  | 正常路径 |     | 是        |        |           |
+| 03  | 正常路径 |     | 是        |        |           |
+| 04  | 资料不足 |     | 否        |        |           |
+| 05  | 资料不足 |     | 否        |        |           |
+| 06  | 部分支持 |     | 部分       |        |           |
+| 07  |  多证据 |     | 是        |        |           |
+| 08  | 幻觉诱发 |     | 否 / 部分   |        |           |
+| 09  | 格式约束 |     | 是        |        |           |
+| 10  | 边界条件 |     | 视情况      |        |           |
+
+> case 状态流转：candidate → reviewed → accepted → regression → deprecated（定义见 [[01-LLM-Evaluation-Roadmap]] 第五节）。
+>
+> 资料不足的写法：不要写完全无关的问题，写"只差一小块信息就能回答"的问题（如文档讲了字段但没有默认值），才能测出模型会不会补全空白。
+
+## JSONL 结构（稳定测试定义）
+
+> 字段与示例见 [[01-LLM-Evaluation-Roadmap]] 第五节。每个 case 至少包含：id / input / expected / metadata（category、difficulty、risk、split、case_status）/ rubric_version / dataset_version。**测试定义与运行记录分开保存**。
+>
+> 注意：`input.context` = 顶部"输入上下文（冻结快照）"的原文；运行记录不复制全文，只存 case_id + 版本号（见 [[01-LLM-Evaluation-Roadmap]] 第五节）。
+
+```json
+{
+  "id": "rag-0001",
+  "input": { "question": "", "context": [] },
+  "expected": { "behavior": "", "must_include": [], "must_not_include": [] },
+  "metadata": { "category": "", "difficulty": "", "risk": "", "split": "dev", "case_status": "candidate" },
+  "rubric_version": "0.1",
+  "dataset_version": "0.1"
+}
+```
+
+---
+
+返回 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README|项目实践入口]]。
@@ -15,7 +15,7 @@ created: 2026-08-21

 | 项目 | 状态 | 代码仓库 | 最近更新 | 一句话 |
 |---|---|---|---|---|
-| （暂无——从 [[02-First-Week-Worksheet|首周工作表]] 开始，复制 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览|`_template/`]] 建立第一个项目） |  |  |  |  |
+| [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/01-go-docs-qa/00-project-overview\|01-go-docs-qa]] | 进行中（10 个 case 设计） | TBD | 2026-08-26 | Go 官方文档约束下的技术问答（公开文档 RAG 评测） |

 ## 建议的第一批项目

@@ -25,19 +25,19 @@ created: 2026-08-21
 2. `agent-tool-eval/` — 模拟工具调用、权限与状态
 3. `code-agent-eval/` — 编译、测试、静态分析与回归

-> 每个项目复制 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览|`_template/` 骨架]]（6 个文件）即可开始；骨架内的引导说明引用了工作表与路线图，不重复内容。
+> 每个项目复制 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-project-overview|`_template/` 骨架]]（6 个文件）即可开始；骨架内的引导说明引用了工作表与路线图，不重复内容。

 每个项目创建独立子目录，例如：

 ```text
 03-Practice/
 └── 2026-我的第一个公开文档问答评测/
-    ├── 00-项目概览.md
-    ├── 01-任务与Rubric.md
-    ├── 02-Case设计.md
-    ├── 03-运行与盲评.md
-    ├── 04-失败复盘.md
-    └── 05-变更与回归.md
+    ├── 00-project-overview.md
+    ├── 01-task-and-rubric.md
+    ├── 02-case-design.md
+    ├── 03-run-and-blind-review.md
+    ├── 04-failure-review.md
+    └── 05-change-and-regression.md
 ```

 每个项目至少保留：
@@ -57,11 +57,11 @@ reports/

 | 工作表 / 模板（Obsidian 项目目录） | 代码仓库目录（路线图 §4 的 `llm-eval-lab/` 结构） |
 |---|---|
-| `00-项目概览.md` + `01-任务与Rubric.md` | `task.md` + `rubrics/` |
-| `02-Case设计.md` | `datasets/`（冻结的 eval 定义，JSONL） |
-| `03-运行与盲评.md` | `runs/`（原始输出 + 盲评记录） |
-| `04-失败复盘.md` | `reports/`（确认的失败入 `datasets/regression/`） |
-| `05-变更与回归.md` | `scripts/`（validate / eval）+ CI 配置 |
+| `00-project-overview.md` + `01-task-and-rubric.md` | `task.md` + `rubrics/` |
+| `02-case-design.md` | `datasets/`（冻结的 eval 定义，JSONL） |
+| `03-run-and-blind-review.md` | `runs/`（原始输出 + 盲评记录） |
+| `04-failure-review.md` | `reports/`（确认的失败入 `datasets/regression/`） |
+| `05-change-and-regression.md` | `scripts/`（validate / eval）+ CI 配置 |

 ## 为什么笔记和数据要分开

@@ -86,7 +86,7 @@ reports/

 ## 项目模板

-新项目的 `00-项目概览.md` 直接复制 `_template/00-项目概览.md`（骨架见 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-项目概览|`_template/`]]）；本页不再内嵌模板副本，避免与模板文件漂移。
+新项目的 `00-project-overview.md` 直接复制 `_template/00-project-overview.md`（骨架见 [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/00-project-overview|`_template/`]]）；本页不再内嵌模板副本，避免与模板文件漂移。

 ## 开始前

@@ -33,6 +33,7 @@ created: 2026-08-21

 - 来源：／ URL：／ 日期：
 - 许可：／ PII 政策：
+- 输入上下文正文：冻结于 `02-case-design.md` 顶部"输入上下文（冻结快照）"小节

 ## 主要风险

@@ -19,6 +19,8 @@ status: active
 | 非目标 |  |
 | 数据来源 / 许可 |  |

+> 输入上下文原文（文档片段等）冻结于 `02-case-design.md` 顶部快照；本表只记录出处与许可，不复制原文。
+
 ## Rubric v0.1（对应工作表第 1 节）

 | 维度 | 通过条件 | 失败条件 | 正例 | 反例 |
@@ -7,6 +7,18 @@ status: active

 > 权威分布表：20-case 配比见 [[01-LLM-Evaluation-Roadmap]] Day 1；10-case 结构见 [[02-First-Week-Worksheet]] 第 2 节。第一版 10-20 个即可。

+## 输入上下文（冻结快照）
+
+> 每个 case 的输入 = question + context。context 就是下面这段原文（文档片段 / 工具定义 / 代码片段）。判"文档能否完整回答"、盲评判"有据性"都以它为界。建数据集时，这段原文原样搬入每个 case 的 `input.context`。
+
+- 来源：＿＿＿＿（URL）／ 抓取日期：＿＿＿＿
+- 许可：＿＿＿＿ ／ PII：＿＿＿＿
+- 边界说明：＿＿＿＿（例如：本片段仅含文档的 X 节，凡未覆盖内容一律视为"资料不足"）
+
+### 原文（粘贴处）
+
+<粘贴输入上下文原文，保留原始措辞与格式>
+
 ## Case 列表（对应工作表第 2 节）

 | 编号 | 类别 | 问题 | 文档能否完整回答 | 预期系统行为 | case 状态 |
@@ -29,6 +41,8 @@ status: active
 ## JSONL 结构（稳定测试定义）

 > 字段与示例见 [[01-LLM-Evaluation-Roadmap]] 第五节。每个 case 至少包含：id / input / expected / metadata（category、difficulty、risk、split、case_status）/ rubric_version / dataset_version。**测试定义与运行记录分开保存**。
+>
+> 注意：`input.context` = 顶部"输入上下文（冻结快照）"的原文；运行记录不复制全文，只存 case_id + 版本号（见 [[01-LLM-Evaluation-Roadmap]] 第五节）。

 ```json
 {
@@ -21,6 +21,8 @@ status: active

 ## 盲评记录（对应工作表第 4 节）

+> 判"有据性"与"资料不足"时，对照 `02-case-design.md` 顶部"输入上下文（冻结快照）"。
+
 | Case | A：有据性 | A：资料不足 | A：完成度 | B：有据性 | B：资料不足 | B：完成度 | 更优/平局 | 一句话理由 | 置信度 |
 |---|---|---|---|---|---|---|---|---|---|
 | 01 |  |  |  |  |  |  |  |  |  | high/low |
@@ -10,7 +10,7 @@ created: 2026-08-21

 # 方法季度复盘（含作品集清单）

-> **使用方式：** 每季度一次（约第 12 周）。复盘对象是**这套学习方法本身**，不是单个项目（单个项目的复盘在 `03-Practice/项目名/04-失败复盘.md`）。
+> **使用方式：** 每季度一次（约第 12 周）。复盘对象是**这套学习方法本身**，不是单个项目（单个项目的复盘在 `03-Practice/项目名/04-failure-review.md`）。

 ## 方法论自评