火影跑团模组测试PilotDeck：AI三轮自动迭代修复

面壁智能联合清华大学、OpenBMB开源发布了PilotDeck，这是一款定位为“智能体协作舱”的新工具，旨在让AI从单纯的“响应器”变成真正能推进项目的协作者。一位开发者用PilotDeck开发了一套火影忍者主题的跑团桌游模组，结果发现它竟然会在半夜自己醒来“加班”修改问题，连续迭代三轮，几乎不需要人工干预。

在过去的AI应用中，大模型通常只能完成单次问答或固定指令，一旦面对需要持续修改、多文件关联的复杂项目，常常显得力不从心。PilotDeck的设计初衷正是为了解决这一痛点。它被称为“协作舱”，意味着AI能在同一个工作空间中管理项目记忆、用户反馈和任务状态，像一个真正的同事那样参与项目。此次开源自面壁智能、清华大学和OpenBMB，也意味着这一能力将向更多开发者开放。

作者选择的测试项目是一套火影忍者主题的TRPG模组，剧情时间线从第七班成立一路延伸到木叶崩溃事件。这类模组包含大量角色台词、战斗数值、事件分支和判定规则，对AI的一致性和逻辑性要求相当高。初始版本的模组存在三个明显问题：骰子使用时常卡住、数值明显失衡、剧情过于单薄。这些问题在桌游设计中相当致命，也很适合检验AI的修复能力。

作者把自己的意见用自然语言反馈给PilotDeck，后者没有像常规助手那样简单重写一段文本，而是自动开始修改整个项目。整个过程共经历了三轮迭代，每一轮都包含自动修复和回归测试。回归测试意味着AI会重新检查之前已经修正的问题是否再次出现，从而保证修改不会产生新的“副作用”。根据作者的记录，前一轮的修正并没有在后续版本中回归，说明自动修复并非简单粗暴地覆盖，而是具备一定的稳定性与因果理解力。

这次测试给作者留下了好几处深刻的印象，而最让他感到特别的，是PilotDeck的“记忆白盒化”设计。系统的项目记忆被清晰地分为两层：Project Memory（项目记忆）和Feedback Memory（反馈记忆）。前者负责保存项目的整体设定、角色数据和进展，后者则记录用户每次提出的具体反馈。这种分层让AI在修改时能准确区分哪些是既有事实、哪些是需要响应的新要求。更重要的是，白盒化的记忆机制让用户能直观地看到AI“在想什么”，方便随时干预和校正。

从火影跑团模组的自动迭代过程来看，PilotDeck展现出的能力已经超出了简单的“生成-输出”模式。当AI能够自主发现问题、持续修改并回归验证时，它就不再是一个被动的工具，而更像一个有记忆、能复盘的项目协作者。这种“半夜自己加班”的自觉性，或许正是未来AI工作流中最值得期待的变化。