AdventureX 结束两天了。这几天我一直在想一个问题：五天内造出一个决策操作系统、拿两个奖，靠的是什么？

认真复盘之后，答案比我一开始想的要简单——我写的代码比自己预期的少。

不是偷懒。是十二个 Qoder 会话同时开工——一个主会话负责收束和集成，其余分模块在各自的泳道上并行推进：有的写数据模型和迁移，有的做分析管道，有的管认证和签署，有的搭前端工作台，有的做沙盘引擎，有的写测试和跑合规。我只做三件事：定产品方向、做关键决策、写集成代码。

这个转变不是一蹴而就的。黑客松刚开始的前几个小时，我还在自己写——搭仓库、配环境、写第一个数据模型。但很快我发现：五天里我自己能写的代码有限，但我需要做的决策次数是无限的。一个 schema 字段应该是 VARCHAR 还是 TEXT？一个 API 端点应该是 POST 还是 PUT？前端要不要在 useEffect 里直接调 API？如果这些全部自己做判断之后再动手，时间根本不够。

所以我把执行拆出去了。但不是随便拆——Ludus 的六条泳道不是让 Agent 随便改代码，每个会话有明确的 write scope 和禁止规则：Contract Lead 不允许给其他泳道发明 UI 捷径，Web Lead 不允许手写 response DTO，QA Lead 只报缺陷不直接改实现代码，Simulation Lead 不允许把未确认的图用于正式建议。这些规则不是口号——Gate 门禁会在每 6 小时集成时强制检查，合同漂移、跨泳道越界、no-run-no-report 失败，任何一项都直接阻断。

用了这么多 Agent 会话之后，我最大的感受不是”它们多快”，而是它们的出错方式很一致。人类开发者有自己的代码风格和思维惯性——有的喜欢过度抽象，有的喜欢硬编码。Agent 的出错模式更纯粹：它们严格遵守你的指令，但也严格遵守你指令中的所有模糊之处。QA 会话在审阅 Task 2 的数据模型时，发现同一个 Workspace 内跨 Subject 引用被接受了——这在业务上是错的，但 Agent 严格按”我被告知的 schema”来检查，它没有”这不对吧”的直觉。这就是人必须做的事：不是在 Agent 产出之后验收，而是在它们并行产出的过程中发现矛盾和遗漏。

这几天的经验给了我一个初步判断：Agent 擅长 schema 和迁移、合同生成和漂移检查、测试编写、重复性配置和 Docker 部署脚本。Agent 不擅长产品方向判断、用户体验决策、跨泳道的架构一致性。人必须做的是定义”不可降级合同”——哪些功能即使砍掉其他所有也不能丢，以及判断 Agent 产出之间的逻辑矛盾。

Ludus 的不可降级合同只有 11 条。合同链不能断裂、签署必须原子化、no-run-no-report 必须 fail-closed——这些是在项目开始前就写死的。五天里我无数次想加新功能，每次看到这 11 条就收手了。

最后拿了 Qoder 和 Money Whisperer 两个奖，方向完全不同。Qoder 看中的是六泳道加 Gate 门禁的工程体系——一个人确实能靠这套方法论接近小团队的产能。Money Whisperer 看中的是把”证据→假设→条件化建议→翻转阈值”这套决策框架用在个人理财上的潜力。这说明 Ludus 的核心价值不在任何一个具体功能，而在那套方法论本身。

讲实话，Prototype 和真正可发布的产品之间还有很长的路。六泳道模型在冲刺期运行良好，但扩展到完整 MVP 时，泳道数量可能反而要减少——更多并行不等于更快，管理 overhead 自己也吃时间。但有一件事我比较确定：把工程治理变成自动化是正确的方向。合同漂移不应该靠人眼检查，schema 变更不应该靠群消息通知。把这些软规则变成硬门禁，才是 AI 时代的工程该有的样子。