实现与反馈

「已经完成」之后，表单真的能用吗？

agent 修改了代码并宣布完成，却没启动应用。你提交一次表单才发现：缺少服务配置时，界面仍显示成功。代码存在，不等于行为成立；运行环境要让这类错误及时暴露。

先建立预期，再让反馈驱动实现

接过边界清楚的工单，先复现问题，或为新行为建立可判定的预期。实现后运行相关检查；失败就修复并重跑，通过后留下行为证据。

HITL 指人参与关键决策。AFK 指任务边界和反馈足够明确后，agent 独立推进。如果目标、范围或验收仍需人判断，就先保留人的参与。

Fix the environment your agent runs in

本站译意：修好 agent 所运行的环境。

— Matt Pocock2026-10-01

让不同检查覆盖不同问题

TypeScript 项目可用类型检查、相关测试、格式与 lint。交互行为还需要能操作的开发服务器、可读日志或冒烟 CLI。选能发现当前风险的组合，不把工具数量当成可信度。

检查必须能抓到有意义的错误

测试若只是重新写一遍实现逻辑，可能与实现一起出错。先说清什么坏行为应该失败，再看检查能否发现它；能够从设计上禁止的错误，也应改善对应边界。

保留必要的行为测试，确认边界确实让用户看见正确结果。一次检查通过，只证明它检查到的内容，不能替代其余风险的判断。

自动化从一件低风险任务开始

先观察一个小任务的证据和返工，再决定扩大自动化范围。Ralph 循环是历史入口，Sandcastle 是工具入口；它们都不能证明无人值守发版已经可靠。

练习：为表单补齐三段证据

先写预测：服务地址缺失时，界面与日志分别应出现什么？再为同一份输入安排失败运行与修复后运行，避免只凭修改后的截图判断。

动手练习

复现假成功，再证明它被修复

• 失败证据：在测试环境移除服务地址，提交表单，记录错误的成功提示。
• 修复：配置无效时返回明确失败，保留输入并允许重试。
• 通过证据：同样条件下显示错误；补齐配置后提交，记录真实成功结果。
• 可重复：注明启动方式、配置条件、输入和期望输出，不记录凭据。

参考思路

两次运行使用相同输入，并对照配置条件。检查要同时证明缺配置不会假成功、合法配置仍能成功；日志帮助定位，界面结果证明用户看见什么。

怎样才算完成？

另一位协作者按记录能重跑，并判定成功或失败。失败证据、修复和通过证据彼此对应；若关键检查没跑，就标明验证缺口，再进入评审与 PR。

速查

来源

• Matt Pocock · 2026-10-01
• 反馈回路 / Feedback loops
• Ralph

非官方、非商业的学习整理，与 Matt Pocock 无隶属或背书关系。所引作品版权归原作者；MIT 复用内容另附版权与许可声明。