工作成果的检查与验收

如果人类在委托工作后，仍然需要逐项阅读结果、判断是否完成、发现遗漏并安排下一步，那么持续推进和成果检查的责任就还没有真正交出去。

HomoErectus 希望让个体在接受工作后，能够维护目标与结果之间的联系：理解要求，安排执行和检查，核对实际产物，处理发现的问题，并在证据充分时作出交付判断。人类主要参与重要产品取舍、范围变化和其他确实需要其决定的事项。

本文说明这一工作方式的设计。它是否可靠、是否减少人类管理负担，需要结合实际成果、检查证据和人类介入情况验证。

一、先明确什么情况下才算完成

检查从目标开始。

一项工作需要说明：希望得到什么结果，在什么条件下成立，有哪些约束，以及哪些事项必须经过有权方决定。要求存在歧义时，个体应先通过已有资料和上下文核对；仍涉及产品含义或重要取舍的，再整理为明确问题。

主项目将交付要求的依据分为三类。

第一类来自实际意图和明确约束。外部委托需要联系真实请求；自主活动则需要联系个体自身的目标来源。例如，要交付的是可查看的草稿，还是已经发送的消息；要验证的是局部函数，还是完整使用路径，都需要保持清楚。

第二类来自完成这类工作所需的专业质量判断。例如，一份研究报告需要检查论据是否支持结论；一项计算需要核对字段含义、单位和关键结果。这些要求需要有任务依据，不能仅凭标题中的“研究”“报告”等词生成固定检查清单。

第三类来自所采用方法的验证条件。例如，一项已有技能要求特定输入、前置能力和结果检查，实际使用时就需要核对这些条件。

三类依据共同形成有效交付要求。必须满足的内容需要贯穿后续活动，建议性改进则需要与其区分，避免工作范围不断扩大。

二、把要求、产物、版本和证据联系起来

一项完成判断，需要回答几个具体问题：

例如，某项代码检查通过，需要联系当时的代码与运行条件。之后修改了相关实现，就需要判断原证据是否仍然适用；一张旧版本截图，也不能自动说明当前版本的表现。

产物与证据还需要能够实际取得。模型描述一个文件，不能证明文件已经写入；协作者给出一份测试摘要，也需要能够联系原始结果及其覆盖范围。

这种对应关系使个体能够持续回答“还缺什么”，也使人类在需要复核时，可以直接找到依据，而不用重新拼接整个工作过程。

三、选择能够回答实际要求的检查

不同检查支持不同范围的结论。

源码审查能够帮助理解实现和潜在问题；编译或格式检查能够发现相应结构错误；局部测试能够检查特定输入和行为；真实组合运行才能进一步说明这些部分在实际路径中怎样配合。

涉及持久化的要求，还需要写入之后的读取；涉及恢复的要求，需要中断后继续运行的证据；涉及交付的要求，则需要确认产物在约定位置可查看，或相应通信实际到达了什么状态。

检查应当与工作内容相称。

研究材料需要核对来源、时效、冲突和推论范围。数据结果需要检查输入含义、处理规则及关键数值。文档需要实际打开或读取成品，核对内容与必要格式。代码或自动化则需要根据目标检查真实执行、结果和相关失败条件。

操作成功与目标满足分别判断。例如，命令退出正常可以证明该次运行结束，但结果是否正确还需要内容证据；文件存在可以证明产生了文件，是否完整可用仍需检查。

同样，也不应把所有工作都扩展为最大范围测试。个体需要选择足以回答当前要求的检查，说明覆盖范围，并保留确实尚未验证的部分。

四、PEOR 怎样承担检查与验收判断

成果检查属于推进目标的一部分。

Planner 在组织工作时，需要安排实现、材料获取、检查和必要交付，使每个步骤能够为当前目标提供贡献。Executor 执行实际操作，Observation 保留返回结果，R/P 再根据目标和证据判断进展。

R/P 需要回答：这份结果满足了哪些要求？还有什么义务没有完成？现有证据是否足够？需要继续检查、修复、补充材料，还是已经可以交付？

步骤已经全部执行，并不意味着目标已经完成。如果仍有未满足要求，就需要继续安排适当工作，或者明确阻塞与失败。

协作同样遵循这一关系。其他 Agent 返回的结果，先成为当前活动的观察材料，再由个体联系整体目标检查。下层活动的成功，可以支持上层的一部分要求，但不能自动代替上层完成判断。

增加一个审阅 Agent 可以提供额外判断，但其意见仍需要联系实际产物和证据。多个 Agent 都说“没有问题”，也需要能够说明它们检查了什么、针对哪个版本，以及是否覆盖了关键要求。

运行时可以核对结构、引用、版本和权限等明确条件。内容是否充分、论证是否成立、结果是否符合专业要求，则需要结合实际材料作出判断，不能用某个关键词出现或某个状态字段代替。

五、检查失败之后怎样继续

检查失败需要回到相应目标中处理。

个体首先核对失败发生在哪里：是实现错误、理解偏差、输入条件变化、依赖不可用，还是检查本身存在缺陷。根据原因，可以补充信息、修复实现、调整局部计划或重新安排检查。

修复之后，需要对照原要求复验，并判断相关变化是否影响已有证据。复验应覆盖变化和未解决的疑点，避免只重复最容易通过的部分，也避免没有新依据地无限重复整套检查。

检查本身也可能需要修正。例如，测试使用了错误输入，或者把约定的“大于”写成了“大于等于”。个体可以修复这些问题，但需要保留原结果、说明修正依据，并确认实质要求仍然完整。

如果改变的是产品含义、必须满足的范围或实质验收标准，就需要回到相应决策方。删除失败断言、放宽要求或把错误结果改为“通过”，不能成为完成工作的办法。

尝试也需要有边界。当现有条件下无法可靠推进时，应保留已经完成的部分、具体障碍和可选方案，形成需要决定的问题。等待决定的工作仍然是未完成状态。

六、怎样作出准确而有用的交付判断

交付判断需要同时说明结论与范围。

个体可以报告某项检查通过、某部分已经完成，也可以报告部分完成、等待条件、无法验证或失败。每种结论都需要联系实际证据。

例如，“本机页面能够打开”与“线上已部署并可访问”是不同结论；“回复草稿已准备”与“已经发给对方”也是不同结论。工作目标要求哪一层，就需要相应层次的证据和授权。

在必要要求得到满足、约定交付完成，并且没有真实剩余义务时，工作应当结束。已经具备足够证据的要求，不必再制造重复检查；只有建议性改进的部分，也不应无限阻止交付。

若范围经过有权方明确调整，需要记录变化依据，再按调整后的要求判断。尚未解决的实质要求，则继续列为未完成，不能通过改写总结隐藏。

人类保留产品方向和重要取舍，并不意味着必须重新完成全部技术审阅。个体应提供可复核的结论、产物和证据，让人类能够在需要时检查，同时将日常核对、修复和跟进留在自己承担的工作之中。

七、以 HomoErectus 自身开发说明验收责任

下面是一个假设场景，用来说明我们希望形成的工作方式，并非 Adam 的真实开发记录。

假设人类确认了一项需求：个体在运行中断后，能够继续处理原来的未完成事项，并且不会重复已经发生的操作。相应开发、执行和检查均处于已授权范围内。

Adam 需要先理解具体要保留什么、哪些行为不能重复，以及什么证据能够支持这些要求，再安排实现、协作和检查。

编程 Agent 返回修改后，Adam 需要核对对应版本、相关逻辑和测试结果。局部模块测试可以提供基础，但这项要求还需要真实组合路径：建立有未完成事项的状态，发生中断，启动新的运行进程，再读取原有状态并观察后续行为。

如果新进程成功启动，却丢失了原来的事项，这项要求仍然没有满足。如果事项保留，但已经完成的外部操作被再次执行，也仍然需要继续修复。

失败结果进入原活动的检查与反省。Adam 根据证据组织排查、协调修复，并在相关版本上复验。过程中发现某种外部结果无法可靠核对时，需要明确限制，判断是否能够通过现有方法解决。

如果必须改变“哪些情况下允许继续执行”的产品语义，Adam 应整理已知事实、选项和影响交给人类决定。一般实现缺陷和检查安排，则由它在已有范围内继续处理。

阶段成果需要说明：对应哪个版本，验证了哪些情况，证据在哪里，哪些情况尚未覆盖。只有必要要求得到支持，才能作出相应范围的完成判断。

这里交出去的责任，包含发现证据不足并继续工作，而不只是汇总编程 Agent 的完成报告。

八、怎样验证检查责任真正被接住

这个工作角色本身也需要接受验证。

首先，要检查结果质量：交付是否满足原要求，是否存在被遗漏、误报或隐藏的问题。能够主动发现缺口、处理失败，并在修复后取得有效证据，是责任落实的重要表现。

其次，要检查持续性：等待、协作、计划变化和中断之后，个体是否仍然知道哪些要求未完成，并能够继续推进。

还需要观察人类实际承担了多少管理工作。人类为什么介入，是否需要反复提醒、补充已经提供的背景、重新阅读全部结果，或者亲自决定每一个常规下一步，都值得记录。

减少消息数量本身不能证明管理负担下降。需要在相近目标、质量与条件下，观察人类的审阅和跟进投入，以及是否仍有工作被留给人类收尾。

检查经历也应当影响个体自身。反复遗漏某类问题，应使它修订能力认识、学习检查方法或调整协作安排；有效方法则需要保留适用范围，并在后来正确使用。

我们希望实现的是：人类说明目标之后，个体能够持续联系要求与证据，组织工作、检查成果、处理缺口，并把真正需要人类决定的问题清楚地带回来。