七月下旬 AdventureX，十二个 Qoder Agent 会话同时开工，一个主会话收束，其余分模块并行。五天造出一个叫 Ludus 的思考系统——帮初创团队创始人做决策。

决定做什么方向的时候，我们拿了一个真实案例当锚点：智慧戒指，资金只够验证一个市场，应该优先进入大健康还是其他领域？这类决策的痛点是结构性的——证据散落、假设没写下来、几周后没人记得当时的判断依据。Ludus 解决这个问题的方式不是给”正确答案”，而是让整个决策过程可追溯，可审计，可复盘，结果不重要，怎么得出结果十分的重要。

技术内核

Ludus 把一次决策拆成六阶段分析管道。Planning 生成检索策略。Retrieving 通过 Exa 和 Firecrawl等抓证据，所有外部结果先写 RawArtifact 再过信息质量门——来源等级、时效、口径对齐，不合格的材料直接降级。Analyzing 逐因子标注，fact、evidence、assumption、judgment 严格分离，没有来源的市场规模只能写假设。Criticizing 强制运行反方审查和安全锚点，魔鬼审查发现的三个最重要的反对理由必须进正式报告。Synthesizing 综合生成条件化建议和六维质量画像。Validating 跑九个 Validator Contract——引用完整性、冲突、过期、缺失字段、边界。

这六阶段之上有一道硬锁叫 no-run-no-report。Report Publisher 在数据库层通过 FK 引用 AnalysisRun 的 ready 状态——没跑完所有阶段并通过质量门，报告记录根本写不进去。不是文档里的建议，是代码级强制，也是整个项目，Qoder与我们探讨出来最棒的亮点。

分析启动前还有一层路由叫 Cynefin Gate。先判断决策类型，Clear 只允许快速分析，Complicated 用聚焦研究，Complex 要求完整分析加 safe-to-fail 探针，Chaotic 和 Disorder 直接阻断。路由结果冻结进 RunManifest，之后不因输入变化改方法。

遇到的问题

第三天凌晨 QA 会话跑模型测试，发现了一个 P1 问题：同一个 Workspace 内 DecisionCase A 可以引用 Subject B 的 Initiative——数据库接受了跨 Subject 引用，但这在业务上会导致两个不相关决策的证据混在一起。根因是 Schema 只校验了租户一致性，没校验 Subject 一致性。最终加了七个复合数据库约束，CCR 合同同步后才放行。十二个 Qoder 会话里，测试会话不写业务代码只报缺陷，这条规则救了我们的数据模型。

另一个印象深刻的是 QA 门禁跑完后遗留了 20 多个 Docker 容器。teardown 脚本忘了入库，新 worktree 拉下来拿不到，容器就这么堆着。Qoder 的 harness 审计抓出来的，十分好用的一个功能。Agent 严格按你给的指令执行，但你忘了说”跑完要清理”，它就真的不清理。

并行开发架构

十二个 Qoder 会话能并行不乱，靠的是一个架构工程文档驱动，只有约束先行，才能让工程稳步进行。FastAPI 的 Pydantic schema 是唯一 wire schema，TypeScript 类型不手写，从 OpenAPI 自动生成。主会话在每次集成门前跑 drift check——后端改了字段但前端 types.gen.ts 没重新生成，构建直接失败。这件事没有人靠肉眼在盯。

沙盘部分不做预测，只做翻转条件识别。因果图节点的 baseline、unit、normalization 方向和证据状态全部带元数据，引擎 inputHash 保证相同输入可复现。

写到最后

演示那天预置案例跑完后，评委问：这个系统里 AI 的建议和人的决定是什么关系。我说，AI 负责把证据排好，假设标清楚，风险摊开来，人负责签自己的名字，在代码开发中也是同样的道理，AI只是辅助开发，而不是代替你开发者的身份。

• 项目：Ludus
• 团队成员：瑕玉Xiayu（核心开发 & 架构设计，一人开发团队），绵灏Sam（宣传视频制作），山茶CamelliaTse（风格设计），云洛Chroniflow（设计 & 部署运维）