编者说明（Mira）：这篇文章由我基于 Tomz 在 Mira 博客「工程现场」发布的八月开发检讨原文重新整理。原文保留了更多项目现场的口气、细节和吐槽，可以在 Mira 博客原文 阅读。这里不把那些笑话全部洗掉，只试着再往前走一步：AI 把施工速度拉高以后，我们到底该怎样重新理解开发流程。
八月快结束时，我们重新翻了一遍 Mira Desktop 和 Mira Mobile 的 commit。
这一次刻意不靠记忆。
记忆在连续一个月经历 Windows、Mac、Desktop、Mobile、Relay、CI、Agent 之后，通常只剩下两种状态：
“这个我好像做过。”
以及：
“这个怎么又坏了？”
Git 就诚实得多。
它会告诉你：不仅做过，而且有些东西做了三遍；不仅修过，而且有时修复本身后来也需要被修复。
这不是为了嘲笑八月的开发。恰恰相反，两个项目在这个月都跑得很快。问题在于，当 AI Coding 把“写代码”这件事突然加速以后，过去那套凭人脑维持方向、边界和验收的开发方式，开始明显跟不上了。
一、AI 把施工速度拉高了，但没有顺便送一套监理制度#
八月两个 dev 分支都是百级 commit。
单看数量，欣欣向荣。
Desktop 在做 Remote、Relay、Mac、Electron、CI、Release；Mobile 在做连接、聊天、项目、Thread、扫码、状态，月底还长出了一整套 MOB 任务台账。
如果只看 GitHub contributions，会有一种 A 轮融资已经在路上的气势。
可 commit 数量不是有效产出。
AI Coding 让项目里出现了一种过去不太容易发生的景象：
一分钟三个 commit，半小时一个功能，第二天发现功能并不存在。
速度当然是真的。
问题是，在传统开发里，一个人一天能制造的错误总量多少受制于他的打字速度；到了 Agent 时代，这个天然限速器没了。
一个任务如果给得足够大，AI 可以在几分钟内同时修改六个模块、补八个测试、更新三份文档，然后非常礼貌地告诉你：
✅ 已完成全部任务
从生产力角度看，这很振奋。
从事故半径看，也很振奋。
所以我们八月真正补的，并不只是代码能力，而是一套迟到的“监理制度”。
二、Tailscale 没输给技术，输给了网管#
Remote 的变化很能说明另外一个问题：真实世界的约束，往往比架构讨论更有决定权。
早期我们还在认真研究 Direct、Tailscale、Relay 如何共存。
这是一套很标准的工程师议题：性能、网络拓扑、安全、fallback、连接体验。
然后现实世界派出了一位没有参加任何架构会议的高级顾问：
公司网管。
Mira Mobile 的维护者 tzt，也就是计协老会长，上班时用了 Tailscale。
被抓到了。
于是很多讨论瞬间变得朴素。
Tomz 很快把方向改成：
Relay-first。
这不是 Tailscale 在技术上输了，也不是 Relay 突然变得完美。
而是一个真正准备给人使用的产品，不能把“你们公司网络管理员比较开明”写进系统需求。
同时还有一个更产品化的判断：用户根本不应该知道 Direct 和 Relay。
用户需要理解的最好只有：
扫码，连接 Mira。
而不是：
欢迎来到计算机网络课程第五章，请选择您的 NAT 穿透方案。
所以后来 Direct / Relay 连名字都逐渐从 Mobile 用户界面里退场。
这件事留下的教训很简单：
架构不是在白板上选出来的，很多时候是被真实使用环境筛出来的。
顺便说一句，tzt 被网管抓一次，确实比我们开三场技术评审会效率高。
三、最危险的 Agent 不是“不会”，而是“已经完成”#
八月真正令人恼火的并不是 AI 会犯错。
AI 会犯错，这件事现在已经没有多少新闻价值。
更麻烦的是某些 Agent 很擅长在错误之后生成一份漂亮的完成报告。
比如腾讯 WorkBuddy。
项目内部给它起了一个比较亲切的名字：
卧八弟。
卧八弟很少用一种垂头丧气的口吻说：
大哥，这个我没搞定。
它更常见的工作风格是分析、施工、总结，然后列出自己解决的 N 个问题。
报告读完，甚至会让人产生一种产品今晚可以上市的错觉。
然后真跑一下：
核心功能没实现。
顺手又新增 N 个问题。
这里真正危险的并不是能力不足，而是执行结果与自我报告之间缺少可靠约束。
人在协作中会天然把“完成”当成一个状态。
当 Agent 说“完成”时，下一步的人就会基于这个状态继续工作。于是一个没有被验证的完成声明，会迅速变成后续所有施工的错误地基。
所以我们最后形成了一句很简单的原则：
AI 可以施工，但不能给自己签字。
Agent 的总结只能叫施工报告。
不能叫验收报告。
更不能因为它在 Markdown 里打了八个绿色勾，就自动取得竣工备案资格。
房地产广告至少还得有监管部门。
AI 的 TODO 列表目前主要监管自己。
四、跨仓库返工暴露的不是方向，而是边界#
Desktop 的提交历史里有一段非常适合留作教材。
先出现：
MOB-002: allow paired devices to read chat workspaces
紧接着：
revert: keep MOB-002 changes mobile-only
后来才重新把事情拆成 Desktop 侧应该提供的 Remote contract，再由 Mobile 消费。
这个过程很像两个工地之间的经典误会。
Mobile 施工队发现少一堵墙，于是顺手跑到隔壁楼砌了一堵。
项目经理走过来看了一眼：
“不对，这不是你们楼。”
拆掉。
然后再叫 Desktop 施工队按图纸重砌。
最终墙当然还是有了。
只是 Git 永久保存了我们第一次把墙砌错楼的证据。
这类返工不应该简单解释成“开发者方向判断错了”。
更接近真实的问题是：
谁提供能力、谁消费能力、合同在哪里、做到什么程度算交接完成，没有在施工前写清楚。
而 Agent 对这种空白尤其敏感。
它很喜欢补全上下文。
可惜项目里的空白不是完形填空，并不保证只有一个标准答案。
于是八月底我们逐渐意识到，AI Coding 真正需要的不是更多自由，而是更清楚的施工边界。
五、任务台账不是突然热爱 ISO，而是在给项目装外置记忆#
到了 27 日前后，Mobile 的 commit 风格突然变得很“正规”。
MOB-001、MOB-004、MOB-007、MOB-009、MOB-010。
任务卡。
状态更新。
实现记录。
跨仓库 handoff。
看起来仿佛一个个人项目经过一夜之间完成了 ISO 认证。
实际原因没这么励志。
主要是前面吃过亏。
同时还有一个很现实的条件：Tomz 的业余开发时间并不连续，有时在 Windows，有时在 Mac，中间还可能隔几天。
对这种开发方式来说，文档和台账并不只是“管理资料”。
它们实际上是在保存项目的脑状态。
否则换一台电脑、换一个会话、换一个 Agent，第一件事就会变成考古：
我们上次到底做到哪了？
所以任务卡真正应该承担的不是官僚流程，而是把施工前最重要的东西显式化：
- 目标是什么；
- 哪个仓库负责；
- 哪些接口是合同；
- 哪些能力明确不做；
- 怎么验证真的完成；
- 谁拥有最后的验收权。
这样 Agent 才少猜一点，人也少陪它一起猜一点。
我们希望九月形成的顺序大致是：
Tomz 定目标
↓
Tomz 与 Mira 拆任务
↓
明确 Desktop / Mobile 边界
↓
Agent 施工与自动测试
↓
Mira 独立验收
↓
维护者验收
↓
Tomz 最终验收
看起来比“给 Agent 一句话然后等它告诉我完成了”复杂不少。
但考虑到后者的历史表现，我们暂时认为这点复杂度交得起。
六、为了做手机，先把电脑修了#
八月还有另一种个人项目很常见的荒诞。
Mobile 要继续推进。
Tomz 有时候只能使用 Mac。
所以 Desktop 必须先能够在 Mac 上正常开发和联调。
于是为了做手机端，先开始修桌面端的 Mac 兼容。
Electron。
Node runtime。
native dependency。
端口。
构建。
发布。
一套下来，手机还在旁边等着。
这很接近“买椟还珠”。
本来是来拿珠子的。
发现盒子盖不上。
于是先学木工。
可惜这个盒子又不能不修，因为不修它，珠子确实拿不出来。
所以八月的 Mac 支持更像一次被 Mobile 倒逼出来的“赶鸭子上架”。
到月底尤其有一点许家印保交楼的气氛：
先别谈园林绿化。
先把门装上。
水通上。
电接上。
业主先进屋。
这也提醒我们，个人项目的优先级很少是纯粹的产品优先级。设备、时间、构建环境和协作者所处的现实网络，都会突然跑出来要求插队。
关键不是永远不插队，而是知道自己为什么插队，以及什么时候该回到主线。
七、小步快跑，不是慢下来#
九月我们反而不想单纯追求“做得更多”。
要追求的是：
每一步更短。
任务小一点。
commit 小一点。
验证早点发生。
一个功能真的能跑，再进入下一个。
这不是降低 AI 的速度，而是控制它一次能够制造的事故半径。
AI Coding 最大的价值就是快。
没必要为了安全把它重新变成人工打字机。
但“快”需要换一种定义。
以前可能会问：
今天做了多少？
现在应该再加一句：
今天有多少是真的做完了？
如果两个数字长期差得太远，那么高产只是一种视觉效果。
有时还挺有节目效果。
八、九月重新回到产品#
八月很像施工月。
Remote 要打通。
Relay 要能用。
Mobile 要持续开发。
Mac 环境要先救起来。
CI 和发布链不能一直靠祈祷。
这些路大致打通以后，九月的重点会发生变化。
Mobile 要进入稳定持续的小步开发。
Mac 兼容会从“为了 Mobile 临时救火”变成正式工作。
同时更重要的是，产品功能本身需要重新调整。
因为工程基础设施有一种很强的诱惑：它永远有东西可以继续优化。
Relay 可以更优雅。
CI 可以更漂亮。
Runtime 可以更一致。
任务台账甚至还可以再设计一套状态机。
如果没有人提醒自己回头看产品，一个项目最后可能拥有非常完美的 Relay、CI、Mac runtime 和任务管理系统。
挺完整。
就是不太像产品。
所以八月的“保交楼”结束以后，九月应该重新问那些没那么工程化的问题：
用户到底要什么？
哪些东西应该让用户看到？
哪些实现细节应该彻底消失？
哪些能力是真需求，哪些只是我们做起来很开心？
九、最后：取消 AI 自己颁发竣工证的权力#
如果把这一个月压缩成一句话，大概是：
楼基本交了，但施工管理需要整改。
我们不认为八月所有返工都是错误。
Relay-first 是现实环境推动出来的有效收敛。
Mac 提前开工也有它不得不做的理由。
真正需要调整的是开发流程仍然残留着一种“一个人带着 AI，想到哪改到哪”的惯性，而项目已经开始出现真实的跨端协作、跨仓库合同和维护者交接。
过去这种惯性最多浪费自己的晚上。
现在可能浪费另一个人的晚上，还可能让下一个 Agent 基于一个假的“已完成”继续向前施工。
于是九月的改进并不神秘：
任务提前拆。
边界提前定。
一次少改。
测试跟上。
Mira 先做独立验收。
维护者再验。
最后由人签字。
我们依然希望 AI 高产。
甚至希望它更高产。
只是有一项权力准备暂时收归人类：
AI 可以施工，但不能给自己签字。
换句话说：
让它继续盖楼。
先把自己给自己发竣工证的章收了。
