01为什么 demo 不算数WHY DEMOS DON'T COUNT
普通软件的演示是可信的：功能今天在，明天大概率还在，因为代码是确定的。AI 系统不是——同一个输入，两次输出可以不同；换个措辞，成功变失败。所以一段流畅的演示视频只证明一件事：存在至少一条顺利的路径。它不回答这条路有多宽、走偏了会掉进什么。
这不是说做 demo 的人在骗人，而是这类系统的性质决定了"看过一次"约等于没看。于是读 AI 项目需要一套新的目光：不看它秀什么，看它留下了什么可以被检查的东西。
02四样东西FOUR ARTIFACTS
① 任务定义。它到底接了什么活：输入什么、约束什么、什么算完成。没有任务定义，"成功率 90%"这种话没有分母。本站把它的工程化形态叫 TaskSpec。
② 运行轨迹。从接到任务到给出结果，中间每一步的记录：读了什么、调了什么工具、哪步失败又重试（F-001 讲过循环，trace 就是循环的行车记录仪）。有轨迹，失败可以定位；没轨迹，成败都是玄学。
③ 验证方式。结果是被"看着不错"验收的，还是被测试、规则、对照检查过的？关键区别：验证是不是独立于生成——自己夸自己不算验证。
④ 边界声明。项目主动说明"我不做什么、什么情况会失败"。这一条最反直觉：敢写边界的项目通常更可信，因为写边界意味着作者真的知道系统在哪里会碎——吹牛的人从不知道自己在哪会碎。
03评测的三个层次THREE LEVELS
第一层，单次目检。跑一次，人看一眼。demo 就在这层。成本最低，说服力也最低。
第二层，固定题集。准备一组固定任务和判分标准，每次改动后全部重跑，看分数变化。这是"benchmark"的本义——它把"感觉变好了"变成"比如 37 题对了 31 题"。私有系统也该有自己的小题集，哪怕只有二十题。
第三层，过程评测。不只判结果对错，还检查过程质量：轨迹里有没有乱撞、失败后会不会自我修正、有没有触碰不该碰的东西。Agent 这种循环系统，两次运行结果一样、过程可以天差地别——过程评测是它特有的必修课。
层次越高成本越高，但可信度的跃升发生在第一层到第二层之间：从"看过"到"可重复地量过"。
04读别人的项目，写自己的项目READ & WRITE
这套目光是双向的。读别人：开源项目、产品发布、论文宣称，先找四样东西，缺哪样就在心里降一档——尤其注意只有跑分没有轨迹的"榜单型项目"。写自己：反过来把四样东西留全。这有个额外的红利——对没有大厂背书的个人项目来说，完整的证据链就是最好的背书：别人可以不信你的描述，但可以亲手检查你的轨迹。
这正是本站项目档案写法的来源：P-001 的档案完整示范了这个结构——定位、已实现、未实现、可验证方式、边界。格式不是仪式，是把"四样东西"制度化。把项目变成可追问证据的完整方法，见 N-003 项目如何变成可追问证据。
05常见误区PITFALLS
把跑分当结论。分数只在它的题集范围内有效。题集是英文的，不代表中文行；题集是选择题，不代表开放任务行。看到分数先问：考的是什么卷子？
把"能复现 demo"当成"能复现能力"。照着 README 跑通了示例，只说明示例这条路是通的——还是第一层。能力的复现要在你自己的任务上重跑题集。
把边界声明读成免责声明。两者气质完全不同：免责声明是律师写的"出事别找我"，边界声明是工程师写的"这里我测过，会碎"。前者保护作者，后者帮助读者——分不清这两个，就分不清营销和工程。
06连回判断TO THE NOTES
证据类型的完整编目，见 证据索引（七类证据各自能证明什么）；N-005 的五件材料是这四样的工程化版本——任务定义与声称合并在 README，产物和测试是验证方式的两种形态；轨迹与回放的深入，见 N-007；把这套方法做成平台的实践，见 P-001 OpenAgent；为什么证据链先于 demo 的完整论证，见 N-005；长任务系统里质量门怎么设，见 N-009。
研习三部曲到此闭环：F-001 懂了系统是什么，F-002 懂了知识怎么进系统，F-003 懂了怎么判断系统可不可信——接下来读站内的笔记，生词会少很多。
07自测清单SELF CHECK
- 能说出四样东西，并解释缺任何一样意味着什么吗？
- 看到"成功率 90%"，第一反应是问分母和题集吗？
- 能区分结果评测和过程评测吗？知道 Agent 为什么需要后者吗？
- 能分辨边界声明和免责声明的气质差异吗？
- 自己的项目，四样东西现在留全了几样？