首页做得很漂亮，而我找不到游戏在哪
第一版首页像一本印刷杂志：大标题，大块留白，顶上是 Connect6、国际象棋和 Hive 的拼贴图。说实话，比我自己能设计出来的好看。
但三张图都不能点。它们是游戏的照片，不是入口。手机上，真正能开局的地方埋在十七屏之后。
没有任何东西坏了。测试全过，目录、链接和元数据都正确，页面也很快。按项目写下来的标准，它已经做完了。
我打开它，找不到游戏在哪。
系统能检查页面是否按要求完成，却不知道一个人打开后能不能马上找到游戏。那版首页没有失败；它只是完成了写下来的任务。下一步怎么改，验收清单里没有答案。
这 8 天也不是连续运行的。我的 token limit 到上限，系统就会停下来等刷新。我会趁这些空档把当时的站点当作普通用户来玩，也跟 Agents 讨论刚看到的问题。额度恢复、工作重新开始时，我那句“找不到游戏”，就成了下一轮工作的起点。
有起点，但没有预设终点
这正是这次与以前不同的地方。过去那些完整产品都能闭环：交付一个程序，或者做完一款游戏，终点在开始前就知道。这个平台的起点也很清楚——先搭出一个可以玩的站点——但我没有列出它最终必须包含什么。
我说的开放目标，就是起点和方向都清楚，终点没有预先写好。具体到每个线程，工作仍然很窄：做一个模块，修一个问题，过一组验收。但一轮做完以后，平台有了新的状态，下一项任务可能来自原来的计划，也可能来自工作中暴露的问题，或者像这次首页一样，来自一个用户的实际反应。
这也带来了连续性的问题。下一批功能要沿用前面留下的决定；做到第 40 件事时，负责它的线程可能从未见过第 4 件事，但两者不能互相打架。我最初用 Claude Code Ultra Mode 推进。它很适合钻进一个边界清楚的任务，但没有一个会话适合一直装着整个项目。我开始按任务分配模型，也把共同状态留在线程之外。
这不是一次模型排名实验。我的问题很实际：谁来决定下一步，哪个工具能把当前这件事做好，以及换了线程以后，前面定下来的规则还能不能留下来。
一层薄调度器、文件系统和一份短宪法
这套架构的冷启动一点都不神秘。项目开始时，我把目标告诉 Fable——当时 Anthropic 最强的模型——让它先搭出能工作的最薄调度系统。最初版本把多个无头的 Codex 和 Claude Code 进程当作 Agents。这里的 Agent 只是一个有独立上下文、工具和工作范围的运行线程，不是长期存在的虚拟员工；有新任务时，调度器启动一个，或者唤醒旧线程继续。
这个闭环跑起来以后，系统便在实际工作中继续扩张。智能体一边做产品，一边修改调度器、补充调度表单、细化角色和文档。后来的多 Agent 系统不是我预先画好的一套完整架构，而是从那个冷启动版本不断迭代出来的。
我没有采用现成调度层。Codex 和 Claude Code 本身已经能读写文件、运行命令、检查代码和完成任务，Harness 不必重新实现这些能力，只处理任务分配、线程生命周期、共同状态和下一次该唤醒谁。工作暴露出新需要时，智能体也可以反过来修改它。
这些 Agent 也没有依赖一套复杂的专用通信协议。它们通过文件系统协作：宪法保存最高层的规则，项目文档保存决定、经验、发现和修正，调度表单记录任务、线程和进度。一个进程写下结果，后来新启动或被唤醒的进程再从这些文件继续。
宪法只回答几件事：什么可以当作事实，出现分歧时谁来裁决，怎样才算做完，哪些边界不能碰。智能体再从这些原则往下写手册和其他工作文档。新线程不需要知道此前每一次讨论；它先读宪法、调度表单和相关文档，再从写下来的状态继续。
Opus 规划，GPT 执行，谁都不批改自己的作业
在我当时使用的配置里，Opus 是负责规划的主模型，几个主要协调线程也由它承担。它的一兆上下文可以同时放下宪法、相关手册、当前计划和当前 diff；GPT-5.6 在那套配置里做不到这一点。
执行任务时情况不一样。GPT-5.6 更快，有些代码也写得更好，还能通过 Codex 直接调用生图能力；站点里的原创图片和其他视觉素材都由这条链路生成。前端则常常是 Opus 做出来的更合我的口味。这些都是我在这个项目里的实际观察。
实际运行时，角色一直很清楚：
- 规划与协调：Opus 读取宪法、相关手册、当前计划和 diff，拆分任务并维持方向。
- 执行与素材：GPT-5.6/Codex 承担大量代码任务，并通过生图能力制作站内原创视觉素材。
- 交叉评审：一个模型执行，另一个模型检查，尽量让第二遍检查换一套思路。
我看着错误一点点变成规则
工作大致按同一个循环推进：先查规则，写计划，做模块，测试，再把结果交给另一个模型检查。theworldatplay.com 从一张五子棋棋盘慢慢扩成 52 款游戏，后来又加上 AI、每日谜题和手机端适配。
过程中有些问题测试抓不到。一次布局错误通过了自动检查，我们便把真实截图和逐张目检写进验收要求；一次动效让玩家看不懂当前状态，手册里就多了“动效不能代替说明”。以后遇到相似任务，新线程会先读到这些规则。
这些手册不是我坐下来一次写完的。它们是项目在出错、修正、复查的过程中慢慢积累出来的，大部分文字也由智能体自己整理。
入门关我一关都过不去
后来它们做了谜题模式，我去玩入门档。过不去。不是“有点难”，是一关都过不去。
问题出在“入门”这个词的定义上。题目来自真实题库（这次是围棋的死活题），而它们把开头几章建在题库的中位数附近——如果“入门”意味着“我们手上最容易的那一端”，这个做法完全讲得通。但那个题库本身就难。里面的长手数死活题，实测解出率的中位数是 0.12：十次尝试有近九次失败。第一章就是从这批材料里取的。
这不是 bug。任何一个数字都没错，从原始数据到排期的每一步都站得住，而结果是一个入门者过不去的入门档。
修法现在写在生成器的注释里：把长题单独拆成靠后的一章，入门档做厚，第 1 章吃掉最容易的 26%，每日排期按题池的十分位、中位、九十分位铺开，而不是坐在中位上。这些没有一条来自测试。它们来自我一直输。
数据没有错，但它掩盖了一个很简单的事实：一个第一次接触这些题的人很可能过不了第一章。系统自己不会以新手的身份坐下来玩，所以这件事只能从实际使用里暴露出来。
从那以后，我会隔一段时间跳出开发流程，直接打开站点使用。我找不到游戏，就说找不到；我看不懂一颗棋子在做什么，就把当时看到的东西写下来；动画让我等得莫名其妙，也照样记录。它们不是完整的需求，只是一个用户卡住的位置。
智能体极其擅长满足一条写下来的标准。而“当一个新手”不是一条标准。
有时是仲裁者，有时是鼓励师
我偶尔还要做决定。有些分歧两边都讲得通，现有文档也没有答案。继续分析不会自动选出一边，这时我会直接定下来，让后面的工作有一个共同前提。
还有一种情况更简单：两个线程反复重开同一场讨论，一边承认另一边有道理，一边又把原来的论证再讲一遍。没有测试失败，代码也没坏，只是讨论不再产生新信息。我会告诉它们，这个方案已经够用了，发出去，继续下一件事。
我写软件很多年，从来没需要鼓励过它。
这是我以前从未有过的开发体验。我不是以程序员的身份参与，基本上也不是产品经理，而是作为一个用户待在开发过程里。我告诉系统自己在哪里迷路，在文档解决不了分歧时做选择，也在讨论已经没有新东西时叫停。平台的大部分代码和规则仍由智能体完成，但这些判断我没有交出去。