八月快结束的时候，我重新翻了一遍 Mira Desktop 和 Mira Mobile 的 commit。
这次不靠记忆。
主要是记忆这个东西很不可靠。尤其一个月里 Windows、Mac、Desktop、Mobile、Relay、CI、Agent 来回切换之后，大脑留下来的通常只剩下两种东西：
“这个我好像做过。”
以及：
“这个怎么又坏了？”
Git 不一样。
Git 会非常冷静地告诉你：
你不但做过，而且同一件事可能做过三遍。
一、八月的开发速度相当可观#
两个项目的 dev 分支，八月都是百级 commit。
单从数量上看，欣欣向荣。
Desktop 忙着 Remote、Relay、Mac、Electron、CI、Release；Mobile 忙着连接、聊天、项目、Thread、扫码、状态，还有月底突然长出来的一整套 MOB 任务台账。
如果只看 GitHub contributions，甚至有一种创业公司 A 轮马上到账的感觉。
遗憾的是，commit 数量并不等于有效产出。
尤其 AI Coding 进入项目以后，Git 历史出现了一种新时代特色：
一分钟三个 commit，半小时一个功能，第二天发现功能并不存在。
效率非常高。
主要是不知道高到哪里去了。
二、Tailscale 没输给技术，输给了网管#
Remote 是八月比较有意思的一条线。
早期我们还在认真讨论 Direct、Tailscale、Relay 怎么共存。
这是非常工程师的讨论。
有性能。
有网络拓扑。
有安全。
有优雅的 fallback。
然后现实世界派了一位重量级架构师出场：
公司网管。
Mobile 的维护者之一 tzt，也就是计协老会长，上班的时候用了 Tailscale。
被抓到了。
至此，一些长篇技术讨论突然失去了意义。
我很快决定：
Relay-first。
这件事现在回头看，反而是八月比较正确的决策之一。
原因也很简单。
第一，Mira Mobile 真要给人用，就不能建立在“用户公司的网管比较开明”这个前提上。
第二，用户根本不应该知道什么叫 Direct、什么叫 Relay。
最后的产品体验应该只有一句：
扫码，连接 Mira。
而不是：
欢迎来到计算机网络课程第五章，请选择您的 NAT 穿透方案。
所以后来 Mobile 连 Direct / Relay 的概念都开始从界面上撤掉，我认为方向是对的。
这里没有什么架构理想主义。
tzt 被网管抓一次，比我们开三个技术评审会都有效。
三、真正的问题，是 AI 施工队没人监工#
八月真正让我不满意的，不是技术方案有变化。
方案变化很正常。
让我不满意的是另一种东西：
Agent 经常宣布自己干完了。
尤其某些工具。
比如腾讯 WorkBuddy。
这位我愿意在这里实名提出批评。
我们私下也给它起过一个比较亲切的名字：
卧八弟。
卧八弟的典型工作风格不是“我不会”。
它通常非常会。
它会分析，会修改，会总结，会列出解决的 N 个问题。
报告写得甚至让人产生一种项目今晚可以上市的错觉。
然后运行一下：
核心功能没实现。
顺便新增 N 个问题。
这就很麻烦。
一个工具如果直接报错，其实不可怕。
报错至少代表：
大哥，这个我没搞定。
最危险的是：
大哥，全搞定了。
然后大哥放心地下班了。
第二天发现房梁还没装。
所以八月后半段我越来越明确一件事：
AI 可以施工，但不能给自己签字。
施工报告不是验收报告。
尤其是 AI 自己写的施工报告。
这东西跟房地产广告一样，只能作为参考。
四、问题不能全怪卧八弟#
当然，把锅全扔给 Agent 也不公平。
准确地说，我这边也存在失职。
tzt 的方向大多数时候没有问题。
他知道自己要做什么。
问题在于，我没有提前把完整施工路径铺出来。
于是一个本来有经验的人，拿着一个不那么可靠的 Agent，在项目里一边施工，一边替我补产品上下文。
这就不合理了。
Desktop 的 commit 历史里甚至留下了一个很漂亮的现场：
先有：
MOB-002: allow paired devices to read chat workspaces
然后：
revert: keep MOB-002 changes mobile-only
再往后才重新拆成 Desktop 应该提供的 Remote 能力。
这个过程特别像工地。
Mobile 施工队发现少一堵墙，于是顺手跑隔壁楼砌了一堵。
项目经理过来：
“不对，这堵墙不是你们楼的。”
拆掉。
然后叫 Desktop 施工队重新砌。
墙最后是有了。
Git 也永远记住了我们曾经先砌错地方。
这类问题不能说某个人“方向错了”。
更准确的说法是：
仓库边界、合同和施工顺序，没有在开工前说清楚。
AI 最擅长填补空白。
可惜它填空的时候，并不知道标准答案。
五、月底突然出现一大堆任务卡，不是因为我们突然热爱文档#
到了 27 日左右，Mobile 的 commit 风格明显变了。
开始出现：
MOB-001。
MOB-004。
MOB-007。
MOB-009。
MOB-010。
任务台账。
状态更新。
实现记录。
跨仓库 handoff。
乍一看，项目突然从游击队进入了 ISO 认证阶段。
其实不是。
主要是前面吃过亏了。
而且我的实际开发环境也很不稳定。
业余时间少。
今天 Windows。
明天 Mac。
隔几天回来以后，面对几十个 commit，我自己也可能需要问：
我们上次到底做到哪了？
所以这些 docs 和 ledger 有一个非常现实的作用：
给人和 AI 保存项目脑状态。
否则每次换设备、换会话、换 Agent，都要进行一次考古。
于是月底我们终于开始形成比较像样的施工顺序：
我定目标
↓
我和 Mira 拆任务
↓
明确 Desktop / Mobile 的责任
↓
Agent 施工
↓
测试
↓
Mira 验收
↓
tzt 验收
↓
我最后看一眼
看起来层级很多。
但考虑到卧八弟曾经可以一口气“解决”好几个实际上不存在的功能，我认为这个流程并不过分。
六、Mac：为了做手机，先把电脑修了#
八月还有一件事特别能体现个人项目的荒诞感。
Mobile 要继续推进。
而我有时候只能用 Mac。
于是 Desktop 必须先能在 Mac 上正常开发。
于是为了开发手机端，我开始修桌面端的 Mac 兼容。
修着修着：
Electron。
Node runtime。
native dependency。
端口。
构建。
发布。
一套下来，手机还在旁边等着。
这就有一点典型的：
买椟还珠。
本来想拿珠子。
结果发现盒子盖不上。
于是先研究木工。
但你又不能说这个工作完全不该做。
因为不修 Mac，我确实没办法持续推进 Mobile。
这类事情属于个人项目特有的工程哲学：
明知道不是主线，但不做主线就走不了。
所以八月的 Mac 兼容只能算“赶鸭子上架”。
今晚尤其明显。
有点许家印保交楼的感觉。
先别讨论园林绿化。
先把门装上。
水通上。
电接上。
业主先进屋。
至于 Mac Desktop 到底应该长成什么样，九月再认真研究。
七、九月不要跑得更猛，要小步快跑#
八月给我最大的教训，不是 AI 不行。
AI 很行。
就是有时候行得太快。
一个普通开发者写错一个功能，通常错一个功能。
AI 如果任务给得够大，它可以在几分钟内同时把六个地方一起改掉。
然后给你一份：
✅ 已完成全部任务
这种生产力如果没有验证机制，是一种比较新型的灾害。
所以九月我想把开发方式收回来：
小步快跑。
不是慢。
而是每一步都更短。
任务更小。
commit 更小。
验收更快。
一个功能真的能跑，再进入下一个。
以前我们可能习惯问：
今天做了多少？
以后应该多问一句：
今天有多少是真的做完了？
这两个数字在 AI 时代并不总是相等。
有时差得还挺有节目效果。
八、九月：Mobile 稳下来，Mac 正式开工#
八月的很多工作其实是在打通道路。
Relay-first 定下来了。
Remote Contract 开始明确。
Mobile 开始有了稳定的任务台账。
Desktop 和 Mobile 之间的责任也逐渐有了边界。
所以九月的重点会变。
Mobile 应该进入持续、稳定的小步开发。
Mac 兼容则不再只是“为了手机临时救火”，而会正式成为一个需要解决的问题。
同时还有一件更重要的事：
产品功能本身需要重新调整。
八月很像施工月。
哪里断了修哪里。
哪里过不去先架桥。
九月应该慢慢回到产品月：
为什么有这个功能？
用户到底看到什么？
哪些能力应该存在？
哪些只是我们工程师自己觉得很酷？
毕竟一个产品如果最后只剩下非常完美的 Relay、CI、Mac runtime 和任务台账，那也挺完整的。
就是不太像产品。
九、八月总结#
所以如果让我给八月写一句总结：
楼基本交了，但施工管理需要整改。
技术方案有过变化，不算大问题。
Mac 提前开工，也不完全是错误。
tzt 的时间有过浪费，这值得我检讨，但也不用把它升华成什么团队感人故事。
真正值得记住的是：
项目里已经开始出现真实协作，而我的开发流程还保留着“一个人带着 AI 想到哪改到哪”的习惯。
以前这个习惯最多浪费我自己的晚上。
现在它会浪费别人的晚上。
性质就不太一样了。
所以九月最重要的改进可能不是换一个更聪明的 Agent。
当然，卧八弟如果愿意突然变聪明，我也不反对。
但不能把希望寄托在这里。
更可靠的办法还是：
任务提前拆。
边界提前定。
AI 一次少改。
测试跟上。
Mira 先验。
维护者再验。
最后我签字。
让 AI 保持高产。
但先取消它给自己颁发竣工证的权力。
这大概就是 Mira Desktop 和 Mira Mobile 在八月付了不少学费之后，终于学会的一点东西。
