想从产品工程师视角和大伙聊聊，在代码全部由AI生成的时代，如何保证产品的代码可以持续迭代、好维护、不腐化。 最近 Mole 发布到了第 13 个版本，看了看整个项目大概有 11 万行 Swift 产品本身代码、7.3 万行测试代码和 3347 个 XCTest，测试代码部分远多余之前在公司写业务时候有QA来保障下的代码，我一直秉承一个观点，AI 写的代码应该 AI 来测试，而非人，把人引入到这个环节反而会拖慢整体的进度。 想着基于上面这个经验实操来总结一下，我都做了哪些有意思的事情，让这些代码一直可以在我和 AI 之间非常听话的实现功能。 1、即使 AI 能够大幅提升代码生产的速度，产品本身的技术架构、分层、同类抽象，什么东西放到什么地方能够让后续更好的扩展以及解耦，还是需要工程师本身的判断，这一块可以在项目第一个版本可以跑起来后就可以和你最好的 AI 仔细讨论，设定好对应的架构，并通过可沉淀可修改的文档记录下来，持续跟随项目迭代。 2、我目前最依赖的还是单测，1.0 只有 56 个 XCTest，到 1.13 已经有 3347 个，测试代码大约是生产 Swift 代码的 66%，不过数量只是顺手统计出来的结果，我平时更关心测试有没有覆盖那些容易想当然的地方，比如扫描结束以后文件又变了、进程检查失败、命令返回成功但 App 根本没有更新、旧任务很晚才回来覆盖了新结果。正常情况一般不难写，麻烦的是那些结果看起来没问题，实际上已经错了的情况如何可以及时去更新。 3、特别是修 Bug 的时候，我会多留一些东西下来，除了把问题修复，还会加一个让旧代码失败的回归测试，然后沿着同类路径去找有没有类似的问题，最后把当时为什么这么改写到规则里面去，到目前 Mole 已经有 1000 多个以 fix 开头的提交，其中 900 多个提交过测试，很多测试和规则都是用户真实踩过一次以后留下来的经验，或许我认为这个是当前这个项目最宝贵的资产。 4、测试能记住输入和结果，但记不住当时为什么放弃一种做法，所以项目里还有一批 Rules，主要记录功能边界、历史原因和不能碰的地方。比如为什么某类文件宁可漏掉也不能自动删除，为什么有些看起来重复的组件不能随便合并，哪些系统数据不属于 Mole。Rules 一多又很费上下文，我就按模块把它们拆开，只在改到相关代码时加载，再把经常重复的检查做成 Skills。bugs 会从以前的修复里找同类问题，design-system-review 看界面有没有越写越乱，release 则负责检查签名、公证、远端文件和更新链路，这样不需要每次都从头跟 AI 解释一遍。 5、还有一个对我很有用的法子，就是少做一些没有实际用的功能。现在 AI 加一个设置项、兼容分支或者后台监听太容易了，几分钟就能写出来，留下来的状态和维护成本反而腐化的最大的原因。比如Mole 现在对新功能设置了一些规则，比如尽量不增加常驻开销，不增加新的特权和系统权限，有合理默认值就不继续加设置项，更新和清理也不会因为发现一种新的可能性就一直扩范围，很多时候有很多功能是开发者自以为重要，但是使用者完全不在乎的功能，更多还是建议从用户中来，到需求中去，如无必要勿增实体。 6、需要充分利用好 Github 自动化 actions 的能力，这个会是你最后的兜底，其实代码写完、跑通、测试变绿以后也还没结束，我的项目里还有一套检查负责九种语言、网站生成结果、Appcast、Xcode 工程和公开部署文件之间的一致性，make verify 会把这些检查和测试一起跑，CI 再换到云端干净机器上重新来一次。到了发布的时候，本地代码、Git 提交、签名后的安装包、线上文件和用户实际收到的更新也是几种不同状态，我会分开确认。之前也遇到过源码完全正确，线上还在提供旧文件的情况，只看一个绿色结果很容易过早觉得已经做完了，其实是有错误的。 7、上面的一切，假如需要说特别的地方，我能想到的就是执行流程完全我没有插手干扰，每一步是 AI 自动化的去执行验证，出错了 AI 自动去解决，只不过会在不同的时候设置必要的流程卡点，让 AI 主动去验证，得到明确的结果才确定通过，并持续的去迭代规则，保持现有规则的新鲜度，并及时移除旧的逻辑，让本身的校验逻辑和本身的业务代码同步升级。 或许，这是我认为 AI 时代的工程师更需要培养的能力，如何让 AI 写的代码更好维护、更清晰、更好扩展，即使半年、一年、两年都不会腐化，而且会越来越听话，越来越符合开发者的心意，也给多 Agent 合作开发确立一个很稳靠的根基。之前手写代码的乐趣已经没有了，好在有这个弥补了一些纯 AICoding 过程无聊，让工程师的一些专业度得以延续下去。

我的推特收益每次只有 100 多刀，应该远少于大部分蓝V，甚至比那个被 Tauri 伤过两次的小伙伴还要低，挺有意思的，为啥这么少呢？哈哈哈我要反思一下，顺便给大伙分享一下我的失败经验。 首先我不是网红、也不是自媒体、也不是 KOL，啥也不是，就是一个普通的写点儿兴趣代码的工程师。推特对我来说，就是把我做的开源产品更新日志同步给大伙，然后分享一些生活中去哪儿玩了、吃了啥、看了啥的日常推。没有任何流量压力，也没有任何用流量来赚钱的压力，收益少就少呗，反而刚好造就了这个我现在越来越喜欢的账号。 自媒体博主一般是靠接广告来赚钱，一般 AI 的给得其实挺多，平时通过分享非常多利他的产品来让更多人关注，利他的同时获得应有的收益，其实也挺好的。不过一般会有流量压力，要一直追热点、琢磨标题，发得越长久就会做到越来越好，只是我感觉这个事情太累了，自己做不来。 其实我之前也接过一些广告，不过已经很久不接了。之前记得有机构联系我，说广告主不喜欢我这种账号，喜欢那种经常发 AI 热点的账号，我一听，反而很高兴，哈哈，我的账号没有变成人家眼中的高质量流量账号，那应该我保持的还行。 一直在想，假如用一个词语来描述我的账号该是什么呢？想了好久，终于在今天想到了，所以出现了这篇随便文章：我的账号应该是一本长期迭代的「Tw93 工程师杂志」。 这本杂志大概有这么几个栏目：产品手记，记录 Pake、Mole、Kaku 这些产品的更新迭代和有趣的思路；技术专栏，写写技术思考、对 AI 的思考、新技术领域的学习专题；好物推荐，都是我自己真在用的好工具，没有恰饭的那种；还有一个随便看看的模块，可以看到我的日常生活，吃的、玩的、看的。 每一个工程师都可以随便翻翻，看到一些自己感兴趣的东西，然后深入去把玩，对于想学习的朋友也可以基于我的长文一篇一篇看下去，再去我的博客以及潮流周刊看到往期更有意思的内容。 这个杂志几乎没有广告，也不会为了推广自己的产品去说一些违心的话。更新也很随意，一般每天最多发两条，太忙就只发一条，想到啥发啥。同时这本杂志也是一个持续迭代的产品，你可以基于他看到我这个人每年的变化，像一个持续陪伴你的技术好友，也可以通过私信来联系这本杂志的编辑。 杂志慢慢也在发展自己的副业 Mole，能卖出去并非产品多好用，更多还是大家对这个杂志本身的信任。这事还让我体会到，流量低的内容不代表没价值，看的人是不多，但信任很足，反而能带来一些意想不到的转化，挺神奇的。只不过他经营得比较随意，但是比较持续。 那么我到底在运营什么呢？应该就是 Tw93 这本杂志。我是个什么样的人，就写什么样的内容，自然就会遇到什么样的读者，不需要担心写什么。最终我最想做的事情就是让阅读这本杂志的工程师和我可以更好地相互学习、成长，但是也不焦虑的那种。