作品集里的 AI 项目怎么经得起追问

01熟悉的场景THE FAMILIAR SCENE

作品集里放着三个 AI 项目，聊起来第一句就露馅："这个 RAG 为什么选这个切块方式？""……教程里是这么写的。"第二句还没来，项目已经从"作品"降级成"作业"。

这不是项目数量的问题。放十个这样的项目，不如放一个接得住追问的——看的人心里很清楚，十个"跟做"和一个"自己做"，含金量差在哪。

"经得起追问"也不是玄学——它有一份具体的清单，而且你已经见过。

看你项目的人，手里有一份和你一样的清单。F-003 讲过怎么读别人的 AI 项目：找四样东西——任务定义、运行轨迹、验证方式、边界声明。四样俱全是工程，四样全无是表演。

有经验的人看项目就是这么看的，不管他有没有见过这份清单——这是审查的通用直觉：你做的是什么（任务）、真跑过吗（轨迹）、怎么知道对（验证）、哪里会挂（边界）。多数追问，都是从这四个口子进来的。

所以对策不用发明，F-003 里就写着：这套目光是双向的——写自己，反过来把四样东西留全。追问的口子在哪，证据就备在哪。

任务定义：题要自己立。教程的题不算数——不是因为教程可耻，是因为定义任务的那串决策（F-008 第三级"造"练的东西）没有发生在你身上。题可以很小，"给我们实验室的文献做一个能溯源的问答"就比"做一个 RAG"强得多。操作就一条：README 第一段写清这个项目解决什么、不解决什么。

运行轨迹：留下它真跑过的证据。日志、trace、失败又重试的记录。演示视频是轨迹里最弱的一种——它只证明"有一次成功过"。一份带着失败记录的日志，比十秒钟的顺滑录屏更能让人相信这东西真的跑过。

验证方式：写下"我怎么知道它对"。哪怕只是十个手工测试用例加一个对拍脚本。注意，写方式比写数字稳："我用这三类输入各测十次"接得住追问，"准确率 95%"会立刻引来第三句——95% 是怎么测出来的？数字没有方式撑着，就是下一个破绽。

边界声明：主动说出它在哪会挂。什么没做、什么场景下不行、哪个部件最脆。同一个事实，主动声明是加分项，被问出来是减分项——先后手不同，一个是底气，一个是破绽。边界声明还有一个隐藏作用：它证明你测过边界，这本身就是工程能力。

项目放进作品集之前，给它过一个测试，只有两句：

第一句："为什么这么做？"考的是决策——F-008 的三级台阶、F-009 的决策归属，练的都是这一句。答案不能是"教程这么写的"或"AI 这么给的"，至少要能说出一个被你比较过再放弃的选项。

第二句："怎么知道它对？"考的是验证。答案指向你留的验证方式和轨迹——说得出方式、拿得出记录，这句就接住了。

两句都接得住，放进作品集；接不住，要么回去补，要么诚实地把它标注为"练习"。练习不丢人，冒充作品才丢人——而且一问就穿。它和 F-009 的复述检验是一对：复述是关起门对自己的检验，追问是敞开门被别人检验。复述过不了的项目，不必送去被追问。

作品集的单位不是项目的数量，是能接住的追问的数量。

这份底稿是站内两篇笔记在研习层的展开：项目怎么从"做过"变成"可追问的证据"，三类材料（Artifact、Boundary、Review）的完整判断见 N-003 项目如何变成可追问证据；没有实验室和算力，题从哪里选、闭环怎么搭，见 N-010 没有实验室怎么做。

想看一个照这个标准做的实物，站内有：P-006 Minimal Agent Loop 的 README 就是按四样东西写的，可以当模板对着看。

底稿负责教你把证据留全；证据怎么被人读、被人信，判断在笔记里。