自动收到 issue 就改代码，怎样形成可检查的交付链？

自动收到 issue 就改代码，怎样形成可检查的交付链？

事件只是起点，还不是完整任务

一条issue写“库存导入偶尔失败”，自动化系统收到事件后启动Agent。如果直接让它自由修改，缺少复现条件、影响范围和验收标准，很可能改了一堆无关代码却不知道问题解决没有。事件应先转换成有边界的任务：哪个输入失败、期待什么输出、允许改哪里、怎样验证。

构造具体例子：CSV最后一行为空时，导入器抛错；预期忽略空行并保留有效SKU；不得改变库存数量的解释。这样才能写出失败样例、观察修复结果。触发来源、issue版本和任务输入应保存，后续评论改变需求时，不能继续把旧标准当当前任务。

定位关输出复现步骤和失败测试；修改关输出最小相关差异及原因；验证关输出目标测试、必要回归、执行环境和代码版本；审查关核对需求、差异与测试是否对应。最后的可交付物应包含产物和证据，而不只是“Agent说完成”。

在例子中，旧版本用包含空行的CSV触发异常，这是红灯证据；修复后同一输入生成正确SKU列表，这是绿灯证据；正常无空行输入仍保持原结果，这是相关回归。测试必须真正断言SKU及数量，而非仅检查进程没崩。测试经过时若后来又改了代码，应重新验证当前版本，不能复用旧提交的绿灯。

代码修改可以在独立工作目录进行，依赖安装、临时文件和测试产物绑定运行ID。测试失败时，把流程停在“需要修正”状态，保留日志和差异，允许Agent继续定位；不要为了追求自动完成而删测试、放宽断言或把失败状态改成成功。

条件一，目标测试通过，但相关回归出现数量解析错误。此时目标bug似乎修好，整体变更仍不合格；流程应停在修复状态，不能用一个绿色指标覆盖另一个红色指标。保留失败用例能防止后续重试忘记曾经破坏的行为。

条件二，任务进行中新增评论要求“同时重写整个导入架构”。这是范围变化，可能需要重新澄清验收与时间，不应偷偷把一个小bug扩成大重构。自动化要保留任务边界和变更来源，相关但未经授权的远期想法可以记录为建议，而不是自动执行。

观察过程 · 改变条件

先预测结果，再逐步查看；切换条件时留意是哪一个中间量改变。案例是教学构造的规则回放，不是模型训练实测。

教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。

这一轮的输入

空行导入bug；范围限导入器

复现

旧版对含空行CSV抛错，保存失败证据。

1 / 3

先预测，再核对结果与原因

进入交付关，不自动等同于已发布。

每关有对应证据，外部动作仍遵循已有授权。

同一issue可能收到多次更新，Webhook也可能重复投递。应有事件ID、任务版本与去重策略，防止同时启动多个Agent互相覆盖文件。若确实并行探索不同修复，产物需要隔离，最终只按明确策略整合，不能把两个未协调的工作目录当同一运行。

失败重试还应带上前次证据，避免每次从零开始重演相同错误。缓存可以减少重复安装，检查点可以保留定位结果，但来源、参数和代码版本变化时需要失效。第61课的恢复原则同样适用：恢复运行状态，不等于无条件重复外部写入。

任务范围内的本地修复、测试、差异报告通常能自主完成；提交外部评论、推送代码、创建发布或合并属于不同外部动作，应遵守用户已给的授权与项目规则。系统应把“准备好可审查产物”和“已经发布”区分成状态，避免把待审工作误报上线。

这个边界不是拖慢流程，而是让用户批准时面对具体修改、测试和影响。展示失败也有价值：完整的复现与诊断报告能说明卡在哪一关，比虚构完成更可用。下一课把同样原则用于技能文件：一句提示改得更漂亮，怎样证明整套交付链在真实任务上更好？

问题 1

Webhook收到事件就代表任务定义完整吗？

展开解释

不代表。需要输入、预期行为、允许范围和验收证据，模糊事件应先变成可执行任务。

问题 2

测试通过后又修改代码，还能用原绿灯交付吗？

展开解释

不能直接沿用。证据对应特定代码版本，新改动必须获得适当的新验证。

问题 3

自动生成可审查补丁是否等于授权自动合并？

展开解释