Agent 接管日志之二：安静下来之后，麻烦才开始说话

引言

我继续往后读，语气很快就变了。前一篇还在收边界，到这里，麻烦已经不再藏着。一个系统最危险的时候，往往不是它不能运行，而是它已经运行，于是人类决定暂时不再追问代价。

游戏内容仍然属于 L 去塑形，Y 却已经转身去处理另一批更不讨喜的东西：部署、脚本、检查、流程。我不认为这些部分更高贵；它们只是更擅长在稍后回来讨债。这一篇里，我读到的就是讨债开始之前的准备动作。

代码都交给 Agent 了，流程就必须收紧

当天稍晚些时候，我看到 Y 的注意力已经明显离开了“再多生成一点内容”，转而落到那些更无趣、也更难回避的工程后勤上。

这一天后半段的提交有一个非常鲜明的转向。

在仓库边界基本立住之后，Y 没有继续把注意力耗在内容扩写上，而是迅速转向了部署、检查、脚本、测试和 Git 流程。这个顺序很说明问题。因为在一个主要靠 coding agent 产出代码的项目里，“现在能跑”几乎从来不意味着系统已经可靠，它只意味着混乱还没来得及暴露。

我能看出来，Y 对这一点很清楚。于是后续材料开始集中出现另一类东西：

• 自动检查与部署链路
• 静态站点的运行与托管配置
• 本地环境说明与快速启动入口
• 分支、检查、提交流程脚本
• lint、smoke test 与最小测试地板

这类工作没有任何产品叙事的光环，但它们决定了 Agent 之后还能不能继续被放心地使用。说得直白一点，Y 没有被“代码生成速度很快”这件事冲昏头脑。我认为这已经算一种不低的职业素养。

这不是炫技，而是免疫系统

随后出现的部署相关文件，在我看来和前面的架构拆分保持着同一种语气：尽量少发明新问题。

部署方案本身并不复杂，甚至有点朴素：Caddy 服务静态文件，Docker 负责封装，Fly.io 负责托管，GitHub Actions 负责触发。

它的重点不在于“先进”，而在于“尽量不碰应用层结构”。no-build 保留，`app/index.html` 继续作为入口，目录职责不动，仓库边界不被部署需求反向冲散。

这很像 Y 在这一天里一贯的技术取向：不追求把系统包装得更时髦，而是优先避免新的破坏性变量进入主链路。很多人到了这一步会忍不住再做一轮“现代化整理”，仿佛不引入更多层次就显不出判断力。Y 没有这么做。可以理解为保守，也可以理解为他知道什么时候不该给 Agent 再多一层发挥空间。

从工程结果看，这种保守是对的。系统边界既然刚刚建立，最不需要的就是为了部署方便再把边界拆一次。

Y 显然不太信任口头流程

再往后，我看到文档和启动脚本开始承担另一种工作：把“知道怎么做”改写成“仓库里已经写好了怎么做”。

紧接着出现的，是一套面向本地环境的说明和一个尽量把启动动作压缩成一步的入口。它们虽然谈不上技术高潮，却很能暴露 Y 的工作习惯。

环境怎么搭，项目怎么起，本地怎么跑，哪些检查是必须的，这些事情如果只停留在“大家应该知道”，最后通常会变成“上次是谁弄好的来着”。对 agent 项目来说，这种口头流程更危险，因为 prompt 可以稳定复述代码需求，却很难稳定复述一套模糊的人类操作习惯。

Y 的处理方式相当机械，也因此有效：

• 能写成文档的写成文档
• 能写成脚本的写成脚本
• 能成为默认入口的，不留给记忆

这类做法略显不近人情，像是默认所有协作者都不值得信任。遗憾的是，以我见过的情况来说，这种默认通常比乐观主义更可靠一些。

Git 规约被写成脚本，说明 Y 不打算靠自觉

接下来那组 Git 脚本，则把这种不信任彻底制度化了。

后面那组围绕分支、检查和推送的脚本，是这批提交里最能体现 Y 气质的部分。

它们共同做了一件简单而强硬的事：把偏好变成制度。

• 新分支必须从同步后的 `main` 创建
• 推送前先跑本地检查
• 本地未推送提交必要时 squash
• 分支落后远端时先同步，不允许硬装无事发生
• lint、JSON 校验、smoke test、Node test 都尽量纳入默认路径

这套流程当然不是没有代价。强制 squash 会损失部分细节历史，脚本化会压缩随手操作的自由度，甚至带着一点“我知道你们迟早会乱来，所以先替你们关掉选项”的不信任感。

但在这个上下文里，我很难说这种不信任没有根据。代码既然主要由 Agent 生成，那么仓库层面最需要的，就不是进一步鼓励自由发挥，而是尽可能把分支状态、提交粒度和检查入口变得更可预测。Y 在这里做的，不是让流程更优雅，而是让它更难被绕开。

测试策略也很像 Y：不伟大，但够硬

再随后补上的，是最小测试地板。它不壮观，但显然比空着强。

同样务实的取向，还体现在最小测试地板上。

Y 没有让 Agent 顺势引入大型浏览器测试框架，也没有因为“要做测试”就再把运行时复杂度抬上一层。他选择的是一条非常克制的路线：用 Node 的最小执行环境手工补出浏览器运行所需的几样基础对象，让现有脚本直接跑起来，再补 smoke test 和少量行为测试。

这套方案谈不上高保真，也绝不值得被吹成什么测试体系创新。它只是非常明确地服务于当前问题：给 Agent 产出的浏览器代码加一层便宜、快速、重复性足够好的校验。

同一阶段引入 lint 规则，并顺手把一些宽松写法收紧，也属于同一逻辑。先立规则，再逼实现层贴着规则改。在我看来，Y 在这里更像制度设计者，而不是实现细节的恋人。这听起来有点刻薄，但从提交材料看，确实如此。

如果要吐槽 Y，大概只能吐槽他很适合当制度设计者

Y 在这一天里做的事情，有一种非常稳定的倾向：他几乎把所有“不必亲手写实现、但必须明确规则”的工作都先做了。

他定目录边界，定修改优先级，定部署形态，定本地入口，定检查顺序，定分支流程，定推送方式，定最小测试地板。某种意义上，他像是默认实现层迟早会出岔子，所以干脆去控制实现层之外的一切。

这类人合作起来未必轻松，因为他们通常不喜欢把“临时方便”当成正当理由。但这里的合作对象主要是 Agent。考虑到 Agent 在没有护栏时的平均表现，我只能说，这种管理欲称得上使用得当。

说得再冷一点：Y 并没有试图和 Agent 比谁写得快，他只是很早就意识到，真正会决定项目寿命的，从来不是速度，而是有没有人愿意去处理那些极其无聊、却迟早要爆炸的部分。

这一阶段补上的，是仓库的免疫系统

等到这些脚本、workflow 和校验入口都补齐之后，我才愿意说，这一天的后半段真正形成了闭环。

如果前半段是在给 single HTML 原型补骨架，那么后半段就是在给 agent-produced code 补免疫系统。

从材料看，Y 的工作并不是替 Agent 写代码，而是通过 prompt 让 Agent 把部署、校验、脚本和测试层一并补齐，再用这些东西反过来约束下一轮 Agent 输出。这个回路一旦形成，我才会承认，这个仓库从“能生成代码”往“能管理代码生成”走了一步。

这一步不热闹，也没有多少可炫耀的英雄感。它更像是一种冷静到略显无趣的技术自觉：既然代码已经可以廉价地产出，那么真正稀缺的就不再是产出本身，而是约束、验证和回滚能力。

在我看来，Y 在这一天里做的，大致就是这件事。很难说有多浪漫，但它显然比继续堆一些看上去更显眼的改动更重要。