这篇是 Shinsuke KAGAWA 8 月 2 号发在 dev.to 的，讲他自己的编码代理工作流被更强模型搞得更糟。我扫标题时以为又是“工作流该改了”那一类劝世文，读到它卡在字段名上的那次事故才决定推。
一个已经批准的实施任务，代理停住不干了。工作流要求字段名必须叫 “Implementation Approval.Status”，工作计划里明明白白写着 “approved”。工作计划都批准了，它停在批准字段本身。作者管这个叫旧工作流的标签敏感，被强模型更认真地执行了。
这不是模型笨。旧规则被旧模型模糊地糊弄过去，新模型把它当真了。你没有移除的规则，会被新模型当成法律。
一路读下来，这篇最值得带走的是作者那个区分：工作流约束分两种，边界约束缩小解空间，工作生成约束创造额外义务。字段名精确匹配就是后一种，它给模型派了一个和实现无关的活。强模型没让这类规则消失，只是执行得更死。
作者举的例子比这个更离谱。评审者要求确定性的两万行证明，规划者直接接受了，没评估这个证明对决策有什么价值。规则就这么一条一条长出来，越来越像工作，离实现越来越远。他把它叫棘轮效应，我读完只觉得这更像一台不断给自己派活的机器。
还有那个数据导入导出的变更。工作计划最后包含了账户设置和生产运维，早就不在实施范围内。工作生成约束会在组织里自我蔓延，它不止住在一个代理上。
最难受的是他在实施前卡住的那次。不是代码写不下去，是找不到外部会计证据、文档审批记录、精确发布命令、详细的 E2E 环境假设，所以工作流拒绝往前走。大部分实施本可以继续。这些都不是实现需要的输入，是规则规定的证明。找证据本身就是那个额外义务。
FixedBench 那组数据也往同一个方向指。他们拿五个较新的编码模型测两百个已经修复的问题，代理在 35% 到 65% 的案例里还是改出了不期望的变更。这个数字高得让我怀疑，问题不在代理不会判断，而是工作流给了它一个“必须改点什么”的预期。
作者提过一种改法：把指令改成“先验证并把弃权视为成功”。结果乱改少了，代理却开始在部分需要继续工作的已修复代码上主动弃权。放宽一条规则，只是把卡壳的地方从乱动换成不动。这大概就是为什么光删规则不够，得知道删掉的那条到底属于哪类。
这条没法跑，是观点类，只读了。不过读完我把自己夹子里三条还在用的 prompt 模板翻出来，拿作者那四个审查规则提问挨个过了一遍：移除这条规则会怎样？它限制范围还是创造工作？模型能根据证据选吗？换个全新会话还成立吗？
一条直接死了。那是给代码审查代理写的老规矩：每次改完，列出所有可能受影响但未修改的文件。以前觉得这是谨慎，现在看是工作生成约束，强迫模型写一份没人看的清单。移除它不损失什么，只省 token。
另外两条暂时没事。一条是真边界约束，只改目标文件、不新增依赖。另一条看起来像派活，但我换了个全新会话试，它防的是一个我会重复踩的具体错误，所以先留着。不是所有工作生成约束都该删，但答不出“移除它有后果吗”的，真没资格留下。
作者后面做得最对我胃口的一件事，是把审批检查从“要特定字段名”改成“接受语义等价的证据”。这一步直接挖掉了那个 “Approval.Status” 事故的根。但他没停在这，他给评审接收者加了三种选择：应用、拒绝、返回用户决策。重复相同偏好又没新证据，就不再阻塞工作流。放宽本身也被加了一条截止条件。
他差点又掉进另一个坑。简化交接之后，规划者把生成的 E2E 测试骨架当成无关文件丢了，早期垂直证明直接失效。后来他只能恢复要求：把骨架用在最早可实现边界任务上。这就是工作生成约束的讨厌之处，刀切少了漏，切多了又把该留的当成累赘。
这篇不是推给所有人的，是推给那种工作流越改越重、越删越不敢删的人。不点链接也能带走的一句——下次给代理加规则之前，先停下来问一句：这条是在收窄它，还是在给它派活。边界约束比工作生成约束经得起时间，但多数现存的规则，是后者。