---
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|项目实践入口]]。