给AI编码智能体一个确定性的“架构检查器”，使其不再假装“完成”

大多数架构图都是死气沉沉的制品。在/docs目录下放一张漂亮的PNG图，画出来一次，一个月后就过时了，它什么也验证不了——它很乐意展示代码中没有的箭头，而对实际存在的箭头默不作声。所以，当我开始让一个编码智能体“绘制架构图”时，我本预期会是同样的情况。但事实并非如此，原因在于一个属性。我使用事件风暴（Event Storming）——这是一种领域建模格式，将系统按时间顺序展开：一个事件触发一个反应，反应触发一个命令，命令生成一个新事件。有用的部分并非便利贴，而是其底层的不可变性：每件事都有原因和结果。领域事件有原因。命令有结果。策略将别人的事件连接到你的命令。这变成了一个智能体可以实际检查的东西。因此，我没有要求模型“看起来聪明”，而是给它一个廉价的确定性图检查。它遍历看板上的因果图，并返回结构化的缺口：无原因的事件、不产生事件的命令、不连接任何东西的策略、孤立的卡片（某人草草记下一个想法但从未完成）。现在智能体拥有一个不会说谎、不会疲倦的反馈循环：编写看板 → 验证（读取缺口） → 精炼 → 重新验证。它迭代至零缺口，就像迭代至测试全部通过一样。不再有“我以为我把一切都连接好了”。我真正关心的部分是它绝不能做什么。当机械性缺口归零时，一个天真的系统会说“架构完成了”。这是谎言。硬性区别在于：缺口——一个机械性的未完成端，一个你忘记画的箭头；智能体几秒钟就能修复。未决问题——一个未解决的业务决策（例如，“如果餐厅在卡已扣款后拒绝订单，那是作废还是退款？”）。你不能通过画一个箭头来“修复”它，因为没人决定用哪个箭头。把它标记为绿色意味着智能体默默代你做了一个产品决策——这是最糟糕的技术债务。所以这些保持红色并可见。看板通过验证，但未决问题仍然列出。绿色勾选意味着“故事在机械上已连接，并且每个未解决的岔路都被展示出来，而不是被埋没”——这正是智能体可以独自构建的内容与必须停下来询问人类的内容之间的界限。我在一个真实种子项目上运行了它：一个包含5个上下文的食品配送领域。在五个看板中——捕获并关闭了17个机械性缺口，故意将15个业务问题保持开放。每个上下文都是相同的循环。不包含我的工具的一般性模式：在LLM/智能体步骤与昂贵或不可逆的下游步骤之间，插入最便宜的具有可检查不变量的制品，让智能体针对它迭代，并硬性分离“机械不完整”（智能体修复）和“未决定”（人类决定）。绝不允许智能体用前者掩盖后者。