2010 年到 2011 年，重建 FBI Sentinel 案件系统的团队，每隔一个周五结束一个两周的冲刺，把做完的东西演示一遍。什么算做完，FBI 自己的计划定了标准：一项功能，要在这个冲刺里充分测试过、能交给所有用户、能在演示会上展示，才能叫完成。
美国司法部监察长看了这些演示和背后的记录。FBI 没有记录哪些验收过的功能满足了这三条，有些功能在规定的测试做完之前，就被算成了完成。项目的产品负责人，也就是跟踪哪些活做完了的那个人，对审计人员说，这些标准只是「大体上」告诉团队活做没做完。监察长写道，光看演示，它「没有依据判断」演示的功能是不是已经能交给一线使用。
Sentinel 后来的经过，见案例。
一条大家共用的终点线
事先写清楚：一件活要满足哪些条件，才能算做完。
这个说法来自 Scrum，也就是 Sentinel 团队当时用的方法。《Scrum 指南》说，完成的定义是对一件工作必须达到的质量的「正式描述」。达不到，这件工作就不能发布，「甚至不能」在冲刺评审会上展示，只能放回清单。如果整个组织有统一标准，每个团队至少要达到它；几个团队做同一个产品，就要共用同一个完成的定义。
规矩这么严，是有原因的。进度报告，是把有人说「做完了」的活一件件加起来。Sentinel 的进度用「故事点」来算，这是一种粗略衡量工作量的单位。监察长说，既然不知道完成标准有没有真的用上，团队到底做完了多少故事点，它也没法核实。如果那些活其实没做完，加起来的总数可能看着不错，没测过的活却在最后越堆越多，项目就可能长时间停在完成了九成。
想想一套说是已经完工的房子。开发商说的完工，是墙砌好了、屋顶盖上了。买房的人说的完工，是水龙头能出水、灯能亮、验收也签了字。两边都说「好了」，到搬家那天才发现，说的不是一回事。
清单上写什么
好用的完成的定义，又短又能核对。Sentinel 的是三条，外人也能照着查：测过了、能交给所有用户、能演示。要是写成「高质量」，就帮不上忙，因为谁也没法一眼看出一件活达没达到。
它还得每次都用，就用在宣布做完的那一刻。Sentinel 的标准白纸黑字写着，监察长发现缺的，是有人照着它核过、再把活算进进度的记录。
设想一个小团队，每漏掉一次问题，就往完成的定义里加一步：先加一道审查，再加第二道，再加一个别的部门签字。半年后，做完任何一件事都要等上一个星期。这张清单可能已经不再说明这个产品怎样才算做完，而是记下了过去犯过的每一个错。隔一段时间问一问，每一条还值不值得留着，回顾会就是一个合适的场合。
看着做完了就停下的智能体
Claude Code 的文档把问题说得很直接：Claude「看着做完了就会停」。文档说，如果没有一个它能自己跑的检查，「看着做完了」就是它唯一的信号，用它的人就得自己去发现每一个错。文档的建议是，给 Claude 一个能给出通过或不通过的东西，比如一套测试、一次必须成功的构建，或者一张拿来和设计稿对比的截图。
Anthropic 让一个编程智能体分很多次会话做一个网页应用时，也碰到了同样的缺口。这家公司 2025 年的一篇文章写道，智能体往往会「在没有充分测试的情况下就把功能标成完成」。它改了代码，有时也跑了一些测试，却常常没发现这个功能从头到尾走一遍是不通的。有两处改动起了作用。一是开头的会话先列出 200 多个功能，全部标成「未通过」，之后的会话只许改这个状态。二是让智能体用浏览器、「像真实用户那样」去测，之后它大多能把功能从头到尾核到位，只是还会漏掉一些它看不见的问题。
那些事先写好的功能判据和测试，起到了类似的作用：动手之前写好，每次会话都一样，靠真把东西跑一遍来核对。
Sentinel 团队把终点线写下来了。监察长的发现，说的是下一步：每件活在算作完成之前，都要拿它对一遍。