research-log 是做什么的？
以工程师事后复述的方式记录研究：一个测量故事、一个精确到可重新实现的规范、一份带数字的验证记录，以及一份诚实的未知事项清单——全部打包为一个自包含的 HTML 文件（CSS 和图片嵌入，无外部资源）。
核心承诺：每一项声明要么有测量支撑，要么标记为未证实，要么列为开放项。 如果需要一句指引：阅读产物只能知道你写了什么；只有真实系统才能告诉你它意味着什么。
工作流
1. 首先清点证据
在动笔之前，从对话、仓库、日志和用户那里收集：
- 时间线：日期、尝试过什么、哪些失败了、哪些令人意外
- 每一项测量及其精确数值和获取方式
- 验证运行：拿什么与什么对比，以及误差数值
- 他人复现工作所需的工具、文件路径和命令
- 未解决的问题及纯假设
不要编造测量值、日期或数字。 如果缺少某个数字，请询问或标记为 OPEN。带有虚构数据的文档比没有文档更糟糕——记录中的空白本身就是记录的一部分。
2. 学习约定
在动笔之前阅读 references/style-guide.md——风格体现在细节中（能证明论点的标题、保留在叙事中的失败、确切的数字、无营销话术）。准备好编写内容模块时，阅读 references/content-format.md。
3. 选择骨架
六个核心部分，按此顺序编号。除非有明确理由，否则不得省略任何部分；如果存在“构建真实物品”的弧线，可在规格部分和工具部分之间插入案例研究章节。
| # | 章节 | 必须包含 |
|---|---|---|
| 1 | 故事 | 逐日时间线；每一步都归因于一次测量；包含死胡同和意外 |
| 2 | 方法 | 一句认识论陈述 + 表格：测试物 → 问题 → 答案 |
| 3+ | 规格 | 字节/协议/格式表格，精确到可重新实现，并带有置信度标签；数学公式以代码块形式呈现 |
| −2 | 工具与操作方式 | 可直接复制的真实命令和路径 |
| −1 | 验证记录 | 每次测量运行的定量误差 + 一个底线提示框 |
| −0 | 开放问题 | 诚实的未知项，每项标记为 OPEN 或 HYP |
4. 编写与构建
将内容编写为一个 Python 模块，定义 DOC（格式见 references/content-format.md），将其保留在项目中以便文档可重新生成，然后运行：
python3 <skill-dir>/scripts/build_doc.py content.py out.html
打开输出文件并检查渲染效果，然后再向用户展示。
5. 自我审计
- 每一条事实性声明都必须带有标签，或者位于验证记录中
- 故事中至少包含一个意外、失败或修正——如果工作中确实没有，就直接说明，而不是人为制造戏剧性
- 数字精确并带有单位（0.445 秒，而不是“快”；64,779 像素，而不是“很多”）
- 每个图片标题都要说明该图片证明了什么，而不是展示了什么
- 操作命令必须是实际运行过的，或者明确标注为未测试
- 开放问题必须存在（总会有开放问题）
- 底线必须是一句话，别人能够凭记忆复述
标签
四种置信度标签，内联放置在它们所限定的声明末尾：
- HW（绿色）——在实际受测系统上测量得到的。对于非设备类工作同样适用：在实时运行中、在测试台上、在生产环境中测量得到的。
- FILE（蓝色）——在所有检查过的产物（文件、抓包、日志）中为真。
- HYP（紫色）——与所有证据一致，但未经证实。
- OPEN（灰色）——未知；没有任何证据表明哪一方成立。
事实带标签；评论不带。如果领域内有更好的名称，可在文档顶部重命名一次并一致使用——但必须保留这四个层次的划分。
语气
同行的工程师，第一人称复数，零营销话术。数字精确并带单位。句子简短。幽默干涩且稀罕。失败和修正属于故事正文，而不是脚注。同事按角色致谢（“一位同事交付了两个 PNG 序列…”）。
起源
源自 TriCaster DVE 研究日志（waldobjekt.org，2026 年 11 月 1–3 日，与 Claude 共同创作）——原始文档自带其 build_doc.py；本技能将该方法泛化。