工程 Bot 怎样检查代码交付
Lingxi Li 的工程实践围绕分工、持续记录和结果检查展开。
按代码领域分工
工程 Bot 各守一个领域，调度编码代理，并通过运行记录和截图追问结果。特殊环境可接私有工作机。
把进度写到外部
作者用 Notion 记录 PR，检查安全意见、CI 与冲突，再按风险决定审核方式。
有人负责团队规则
运营 Bot 组织同步、处理复盘，并把规则传给新成员。
审查任务要区分紧急程度
补充案例覆盖夜间代码检查和 P0 跟进。原文提醒，高频检查会更快消耗 token。
给出能够检查的结果
作者建议保留完整反馈过程，把重复操作整理成技能，再逐步扩大授权。
本站练习，修正报名余量的负数显示
本栏目另行设计的虚构练习 · 可用自己的工具完成 · 未作产品实测
本站用一个虚构报名页面练习代码交付。演示规则很小，总名额与报名数都是非负整数，报名数超过名额时，显示余量应为零。先在临时目录验证函数，不接真实报名系统，也不尝试部署。
先准备这些材料
新建 checks.js，先放入函数片段 function remaining(capacity, booked) { return capacity - booked; }。
在同一文件的函数后添加检查片段 const cases = [[12, 4, 8], [12, 12, 0], [12, 15, 0]]; for (const [capacity, booked, expected] of cases) { if (remaining(capacity, booked) !== expected) throw Error('case failed'); }。
使用已安装的 Node.js 执行 node checks.js。三个输入依次检查普通余量、刚好满额和超额，预期结果为 8、0、0。01先写清修改范围
给实现角色一份任务书，只允许修改余量函数，不能改测试预期，也不增加预约或付款逻辑。另给验收角色原始规则和三个输入，让它独立确认输出。这些角色可以在同一对话中按顺序模拟，重点是保留检查依据。
02先看到失败，再讨论修正
运行原片段并保存终端结果。第三例按原算式会得到负三，与约定的零不同。要求实现角色解释这个差异，再提出最小改法。如果本机没有运行环境，就把检查标为未执行，先补环境；不能把阅读代码当作运行通过。
03用同一组输入重新核对
修改后再次执行相同命令，三项检查必须都通过。验收角色还应查看文件差异，确认实现没有把用例删掉，也没有把所有输入都改成返回零。若第一轮仍失败，最多允许第二轮修复，随后保留错误结果并停下。命令没有输出时，还要确认退出状态成功。
04把证据放进交付说明
写一页变更记录，列明修改原因、执行命令和实际结果。附上最终函数文件，并说明本次没有验证页面布局或其他输入类型。若要接回真实项目，仍需在那个项目重新执行相关检查，临时目录通过不能替代集成验收。
交付后这样核对
交付物应包括修正后的 checks.js 和变更记录。三个预期值保持 8、0、0，实际运行状态写清楚。没有真实环境时可以交待执行方案，但不能把它标成已验证的代码。
把这段提示词带走
配合上面的虚构材料使用，也可以换成你自己的任务资料
练习虚构报名余量函数 function remaining(capacity, booked) { return capacity - booked; }。输入均为非负整数，超额时余量应为零。请在临时目录先检查 remaining(12,4)、remaining(12,12)、remaining(12,15)，预期依次为 8、0、0。只改函数，保留测试，最多修复两轮。返回文件和实际运行结果；没有运行环境就注明未执行，不合并、不部署。- 三个测试预期保持不变
- 实际结果有运行记录
- 没有将临时检查当作生产验收
完成状态需要代码与运行证据共同支撑。