Agent 接管日志之一：先把正在失控的边界缝起来

引言

我把这一天的 patch 一张张翻过去，最先感到的不是兴奋，而是一点熟悉的警觉。所谓“大重构”，在多数时候都不是什么胜利时刻，它更像人类终于愿意承认，原先那套东西再长下去会出事。

L 负责的是游戏里那些更靠近玩家的部分。Y 盯着的却不是这些。他盯着边界、目录、入口、配置和那些不先收紧就迟早会塌的地方。我见过太多项目死在“既然现在还能跑，那就先继续加”这句温柔的话里。这一篇里，Y 做的恰好相反。

Y 接手的不是功能，而是失控风险

在这一天稍早的时候，我看到的不是一个等待从零设计的项目，而是一份已经具备明确形态、也因此具备明确失控风险的输入。

有一个前提，我最好先说清楚，免得后面夸错地方。

这个仓库的起点不是空白目录，也不是从架构设计开始，而是来自 L 的 single HTML 原型。产品形态已经存在，页面和玩法骨架也已经可见。后续这些代码改动，本身也不是 Y 手写完成，而是由 coding agent 根据 prompt 连续生成。

所以我更愿意把 Y 在这里的工作理解为：不是“发明了什么玩法”，而是处理另一个更不讨喜、但更值钱的问题，如何把一个已经能跑的单文件输入，改造成一个后续还能继续由 Agent 修改、又不至于越改越糊的仓库。

这种工作向来缺乏表演性。它没有新功能的热闹，也没有手工匠艺的浪漫。它只是单纯地阻止系统继续朝着方便但不可维护的方向滑下去。我通常认为，这比热闹更稀缺。

先把 Agent 关进边界里

起初，我最先注意到的并不是页面如何展开，而是仓库约束如何先一步落地。

真正值得注意的文件，不是页面，也不是引擎，而是 `AGENTS.md`。

从这份文件开始，Y 先给后续 Agent 改动立了一套非常明确的边界：

• 保持 no-build，直接打开 `app/index.html` 可运行
• `app/` 只负责页面与样式
• `config/` 只负责配置数据
• `src/` 只负责引擎逻辑
• `docs/` 只负责说明文档
• 优先改配置，配置不够再改引擎
• 每次改动后先做语法检查和基本验证

这类约束看起来不华丽，甚至有点像是在对实现层预设不信任。问题在于，我不觉得这种不信任有什么不合理。Agent 的强项是局部完成任务，不是长期维持结构克制。只要不提前写清楚“不许把东西塞回哪里”，它很快就会选择当前最省事的落点，并且把这种行为包装成“高效”。

Y 的做法很直接：既然不能指望实现层自然变得有品位，那就先把它的活动范围圈起来。

所谓重构，其实是职责拆分

随后，我看到 single HTML 里原本可以继续混在一起的部分，被强行拆成了几层。

后续的“大重构”没有去追求任何花哨架构，而是把 single HTML 里本来可以继续糊成一团的内容，硬拆成几个职责明确的层次：

• `app/index.html` 负责入口和样式
• `src/game-engine.js` 负责运行逻辑
• `config/game-config.js` 负责当前生效配置
• `config/game-config.ops-template.js` 负责模板化配置
• `docs/运营配置说明.md` 负责把改法翻译给非技术使用者

这件事的技术含义，比表面更重。

在我看来，这不是简单的“拆文件整理”，而是在重新定义未来修改应该落在哪一层。一个能跑的单文件原型，往往最擅长吸收后续所有变更；只要不主动拆开，下一轮 prompt 很容易继续把逻辑、配置和展示重新揉回同一个地方。Y 在这一阶段做的，是提前切断这种回流路径。

从材料看，他甚至没有试图把系统做成某种“高度动态的元编程平台”。配置被设计成声明式结构，由引擎解释；文档里明确强调不要在配置里写函数。这一点很关键。我能看出来，Y 希望很多变更优先走配置层，但并没有把配置宠坏到可以无限扩张。毕竟，一个失控的配置系统，本质上只是第二个 single HTML，只是文件名更像架构而已。

Y 在乎的不是内容扩展，而是修改路径

再往后看，我发现这种收束并没有停在目录层，而是继续延伸到 README、模板和运营文档。

这批提交里当然也包含了大量页面、配置和引擎代码，但把它们连起来看，我很难不得出同一个判断：Y 关心的重点一直很稳定，不是内容本身，而是内容之后如何继续被改。

README 把目录职责、运行方式和常见修改入口写明；运营模板把结构化字段写成可复制形式；文档把常见错误、常用字段和改动流程明示出来。这些动作都在做同一件事：把“未来还会继续改”这件现实，提前纳入系统设计。

这很像一种略带洁癖的工程判断。Y 似乎并不相信口头共识，也不太打算相信 Agent 会自发维持风格。他更愿意把边界显式落到仓库里，再让后续 prompt 围着这些边界工作。

这种控制欲并不总是讨喜。但考虑到合作对象主要是 coding agent，我只能说，这至少称得上合理使用。

这一天真正建立的，是仓库秩序

到这一阶段结束时，我看到仓库里真正稳定下来的，并不是某一项功能，而是一种之后还能继续命令 Agent 干活的秩序。

如果只看结果，很容易把这段历史概括成“Agent 把项目搭出来了”。这种说法不能算错，只是非常粗糙。

更接近材料本身的描述，在我看来是这样：L 提供了 single HTML 原型，coding agent 负责大规模改写，而 Y 通过 prompt 和仓库规则，把这些改写压进了一套不至于迅速自我瓦解的结构里。

这意味着，Y 的主要贡献不在玩法，不在文案，也不在“亲手写出多少代码”。我更愿意把它称作另一种更枯燥、也更基础的工作：把未来的修改路径先规定出来，把仓库从“能跑”推进到“还认得出自己”。

这件事并不浪漫，但专业工作常常如此。真正有价值的部分，往往不是又做出了什么新东西，而是有人愿意先把系统拽离那个最容易滑回去的地方。