Agent 说完成了。测试全绿，文件已经生成，任务面板也亮起成功。这个瞬间最容易让人松一口气。可当你真的打开产品，点下用户要点的按钮，结果可能没有出现。登录完成却进不了工作台，视频渲染成功却没有声音，文章发布成功却只停在草稿箱。问题不在于 Agent 撒谎，而在于我们把离用户太远的信号，当成了交付本身。

很多团队的完成标准停在活动证据。代码改过了，命令跑过了，日志打印了，工单关闭了。这些证据只能说明事情发生过，不能说明目标已经达成。就像快递系统显示包裹离开仓库，不等于收件人已经拿到手。活动证据有用，但它只能站在证据链的第一层。

第二层是技术证据。单元测试、类型检查、构建和接口返回都很重要。它们能快速发现错误，也能防止旧问题反复出现。但测试只回答我们事先写进去的问题。没有被表达成断言的风险，不会因为测试全绿就自动消失。更关键的是，测试环境里的对象、权限、网络和身份，往往与真实用户所处的环境不同。

第三层是最终产物证据。用户拿到的不是源代码，也不是测试报告。用户拿到的是网页、视频、文章、文件、消息或一次可完成的操作。因此，验证必须落在最终生成物上。视频要打开播放，检查时长、画面、声音、字幕和封面。文章要进入真实草稿或发布页面，检查标题、排版、图片和链接。模板生成脚本通过，不代表生成后的脚本一定能运行。源文件正确，也不代表交付给用户的二进制一定正确。

第四层是用户动作证据。真正的问题不是系统内部发生了什么，而是用户能否从起点走到结果。登录的完成标准，不是接口返回令牌，而是用户能够进入正确页面并继续操作。上传的完成标准，不是存储写入成功，而是用户能看到、打开并使用文件。发布的完成标准，不是任务进入队列，而是目标渠道出现可识别的内容与外部回执。

第五层是已知风险证据。每次事故都会暴露一条具体的薄弱链路。修复之后，必须把那条风险变成可重复验证的验收项。曾经出现过静音视频，就要检查音轨；曾经把内部说明写进成品，就要从普通读者视角再审一次；曾经出现本地和远端不一致，就要在生产前确认主分支与运行版本。风险复验不是增加仪式，它是在阻止同类事故换一个外观回来。

还有一层经常被忽略的证据，外部身份。内部数据库写着成功，用户却看不到内容时，我们需要外部平台给出的对象标识、链接、草稿编号或发布回执。它让交付从自我报告变成可追溯事实。没有外部身份，所谓发布成功可能只是一次内部状态变化。

证据链最直接的价值，是把谁更可信的争论变成哪一层还没有被证明。Agent 说完成了，不必立刻相信，也不必立刻否定。先找最终产物，再走用户路径，讨论自然会回到事实。

如果成品已经存在，也能直接使用，但用户动作仍然失败，就继续检查权限、入口和状态流。如果动作已经成功，却没有外部标识，就补平台回执。每一层都有清楚的问题，不需要用新概念掩盖未知。

任务运行得越久，投入的人越多，大家越希望它已经结束。这种期待很容易把接近完成误认成已经完成。可用户不会因为我们的投入而降低结果标准，现实也不会因为日志很长而自动让功能可用。

真正的完成标准必须站在用户那边。用户不关心渲染经过多少步骤，也不关心队列重试几次。用户只关心视频能不能看，文章能不能读，按钮能不能产生承诺的结果。

内部观测当然重要。清晰的日志、状态和测试能帮助我们快速定位最后一公里为什么没有抵达。它们的职责是帮助结果成立，而不是在结果缺席时替结果作证。

健康的生产线会让内部记录和外部结果彼此相连。任务记录能找到最终资产，最终资产能找到外部平台身份，外部身份又能回到本次运行和内容版本。任何一处断开，都说明闭环还没有完成。

文章生产就是一个直观例子。文字写完只代表内容存在，排版完成只代表成品可读，进入公众号草稿箱才代表渠道交付发生。最后还要打开草稿，确认标题、封面、正文和链接没有在同步中走样。

视频生产的证据更多。渲染成功并不等于成片合格。要确认文件能够解码，时长符合预期，画面不是黑屏，音轨真实存在，字幕没有遮挡，封面与视频语言一致。上传后还需要平台给出视频身份。

软件功能也一样。接口测试通过以后，要在真实页面触发动作，确认加载、权限、跳转、错误提示和后续状态。用户走到结果，才是这条功能链抵达终点的证据。

如果一项验收只能由工程人员理解，它还不是好的最终用户标准。好的标准应该使用用户语言，描述用户做什么、看到什么、得到什么。内部对象留在实现层，不应成为用户替系统承担的理解负担。

好的证据也不等于堆满截图和日志。证据应该刚好回答完成标准。一个可访问的外部链接、一段最终文件探测结果、一次真实路径的关键状态，再加一条已知风险复验，通常比几十页过程记录更有价值。

选择证据时可以问三个问题。它是否直接对应用户结果，是否能被下一位接手者复核，是否能暴露同类问题再次出现。如果三个答案都是肯定的，这条证据才值得进入长期交付记录。

把这些层次连起来，就得到一条更可靠的证据链。活动证据说明做过，技术证据说明局部行为符合预期，产物证据说明成品可用，用户动作证据说明目标可达，风险证据说明旧伤没有复发，外部身份说明结果确实存在于目标世界。任何一层都不能单独代表全部，但它们组合起来，才能让完成经得起追问。

怎样把证据链写进日常工作？不要只写开发任务，要写用户可观察的完成标准。不要写完成登录接口，而要写新用户可以登录、进入工作台并看到自己的项目。不要写生成视频，而要写成片可以播放，画面、声音、字幕和封面都正确。不要写发布文章，而要写目标账号中出现对应草稿或内容，并记录可核验的外部标识。

然后把验证动作放在生产链路里，而不是留给最后一个疲惫的人凭感觉检查。自动化适合验证格式、状态、数量和可解析性。真实环境适合验证初始化、权限、跳转和平台回执。人工复核适合判断内容是否像给真实读者看的成品。三者不是互相替代，而是各自负责最擅长的一段。

这套方法的核心不是不信任 Agent，而是不把判断权交给任何单一叙述者。Agent 可以执行、汇报、解释和建议，但现实拥有最终否决权。只要最终产物打不开，只要用户动作走不通，只要外部平台没有对应结果，任务就仍然没有完成。证据不是对效率的拖累，它让我们更早发现虚假的完成，避免在后续任务中支付更高的返工成本。

SoloMap 的价值也在这里。路线图不只是任务列表，它应该保留每个阶段要达成的结果、完成标准、执行记录和交接证据。Agent 可以帮助推进工作，但项目方向与验收权仍掌握在你手里。你不需要理解每一处内部实现，只需要确认这一阶段承诺的用户结果是否真实存在。

现在就做一个十五分钟的动作。打开你当前阶段的完成标准，找出一句只描述内部活动的话，把它改成用户可观察的结果。再增加一个最终用户验收动作，亲自走一遍，并保存产物或外部回执。下一次 Agent 说完成了，你不必靠信任或怀疑做决定。沿着证据链看一遍，现实会给出答案。

只证明忙碌的材料应该放在辅助位置。命令列表、过程截图、模型自评和完成套话可以用于排障，却不该占据交付结论的中心。中心位置必须留给最终产物与用户结果。

证据链会改变 Agent 的任务边界。要求不再只是修改文件，而是明确要交付什么、保留什么边界、用什么真实动作验收。Agent 仍然拥有执行空间，但不能自行缩短终点。

它也会降低人的验收压力。验收者不用通读所有实现细节，更不用凭感觉判断 Agent 是否可靠。顺着完成标准检查证据，就能知道任务停在哪一层，下一步该补什么。

同类故障再次出现时，第一反应不该是再造一个模块。先看原有证据为什么没有拦住它。可能是验收项缺失，可能是验证对象错了，也可能是结果检查过却没有持久记录。根因通常藏在证据链断点。

系统韧性因此有了朴素尺度。第一次问题可能靠人发现，第二次同类问题应该被已有验收识别。如果每次都要重新分析、重新发明、重新改主链，说明经验还没有进入稳定生产方式。

冻结生产基线的意义也在这里。稳定版本负责重复执行已经验证的路径，章节生产只替换内容，不修改模板、Runner 和治理心智。若每次内容都必须先改生产线，那就不能证明基线稳定。

验证基线不能只看它能否启动。还要看它能否在不改代码的前提下接收新章节，完成文章、视频、封面、渠道发布和外部回执，并在最后给出一致性诊断。

当整条链连续成立，新增章节才真正从研发活动变成生产活动。主题和表达可以变化，生产者不必为了每篇内容重新设计系统，最终用户始终得到同一套自然完整的体验。

六层证据可以压缩成一张很短的验收卡。做过什么，技术检查是否通过，最终产物在哪里，用户动作是否成功，已知风险是否复验，外部身份是什么。六个问题足以让完成声明落地。

这张卡不需要暴露给最终用户。它服务的是交付责任，让系统吸收内部复杂度。最终用户仍然只看到一个自然、完整、可以直接使用的产品结果。

如果时间真的很紧，至少不要省掉最后三项。打开最终产物，走一次真实用户动作，记录外部身份。它们是内部成功与现实结果之间最短的桥。

完成不是一种语气，也不是任务面板上的颜色。完成是用户承诺已经在现实中成立，并且任何接手者都能沿着证据再次确认。

最容易被忽略的，是验证动作本身也要指向最终对象。检查上传请求成功，不能代替检查平台里的视频。检查文章 HTML 合法，不能代替打开公众号草稿。验证对象错了一层，结论就会比现实提前。

证据还必须持久存在。只在当时看过一次，却没有记录资产位置、外部身份和风险复验，下一位接手者仍然只能重新猜测。可恢复的项目上下文，需要把结论与能够复核它的事实放在一起。

验收通过之后，也要明确剩余风险。没有覆盖到的环境、需要人工判断的内容、仍依赖外部平台的状态，都应该被如实保留。可信并不来自宣称没有风险，而来自知道哪些结果已经证明，哪些边界仍然存在。

这样定义完成，看起来比一句任务成功更严格，却会让后续推进更轻。下一章不必重新追溯上一章发生了什么，新的 Agent 也不必从聊天记录里猜测旧结论。证据让交接成为继续行动的起点。

最终，稳定生产不是让每次运行都毫无波动，而是让内容变化不会迫使主链变化，让已知问题能够被原有验收发现，让任何完成声明都能回到普通用户真正拿到的结果。