- Rewrite folder-relative wikilinks (resolved from vault root) to unique basenames or full vault-root paths so they actually resolve in Obsidian - Fix malformed table links with spaces around the | alias separator - Plugin updates from Obsidian (any-block, omnisearch, quickadd, etc.)
type, tags, status, created
| type | tags | status | created | ||
|---|---|---|---|---|---|
| hub |
|
active | 2026-08-21 |
项目实践入口
这里用于放实际 Eval 项目,而不是继续积累理论笔记。学习材料告诉你“为什么”和“怎么做”(02-Why-Guide、01-LLM-Evaluation-Roadmap);项目目录保存你亲自得到的证据。
建议的第一批项目
按以下顺序推进。先完成一个小型、可重跑的闭环,再增加框架和自动化:
rag-eval-lab/— 公开技术文档约束问答agent-tool-eval/— 模拟工具调用、权限与状态code-agent-eval/— 编译、测试、静态分析与回归
每个项目创建独立子目录,例如:
03-Practice/
└── 2026-我的第一个公开文档问答评测/
├── 00-项目概览.md
├── 01-任务与Rubric.md
├── 02-Case设计.md
├── 03-运行与盲评.md
├── 04-失败复盘.md
└── 05-变更与回归.md
每个项目至少保留:
task.md
datasets/
rubrics/
runs/
scripts/
reports/
为什么笔记和数据要分开
这个 Obsidian 专区保存思考与决策;代码仓库保存 JSONL、脚本和原始运行输出。两边互相链接即可:
| 放在 Obsidian 项目目录 | 放在代码仓库 |
|---|---|
| 为什么选这个题、成功条件、设计取舍 | datasets/、runs/、scripts/、原始输出 |
| rubric 的修改理由 | 可执行 schema 与校验脚本 |
| 失败模式、实验结论、下一个假设 | 机器生成报告、日志与图表 |
| 项目复盘、作品展示文字 | README、依赖、CI 配置 |
原则: Obsidian 是你的“工程判断日志”,代码仓库是你的“可运行事实”。不要让任何一边替代另一边。
每个项目都要回答的五个问题
- 用户想完成什么任务?
- 什么情况算成功,什么情况算失败?
- 你故意设计了哪些边界或负例?
- 最常见的失败在哪里,为什么?
- 修改后,你如何证明没有破坏原有能力?
项目模板
可直接复制以下内容到新项目的 00-项目概览.md:
---
type: project
status: active
project_type: rag-eval
---
# 项目名称
## 问题与范围
## 一句话成功条件
## 主要风险
## 当前版本
## 关键链接
- 工作表:
- 代码仓库:
- 数据集:
- 最近报告:
## 下一步最小动作
开始前
先完成 02-First-Week-Worksheet,再建立你的第一个项目目录。