# 第 280 期 - 喜欢宋体 > 封面图拍摄于杭州新开的恒隆商场，周末过去逛了逛，喝了一杯 AITCoffee，味道还不错，看到墙上有这么一个纸窗户，上面写着宋字，我最近产品官网喜欢用这个字体，很古典。 - Issue: 280 - 发布日期: 2026/08/31 - HTML: https://weekly.tw93.fun/posts/280 - JSON: https://weekly.tw93.fun/api/posts/280.json - English translation: https://weekly.tw93.fun/en/posts/280.md --- 封面图拍摄于杭州新开的恒隆商场，周末过去逛了逛，喝了一杯 AITCoffee，味道还不错，看到墙上有这么一个纸窗户，上面写着宋字，我最近产品官网喜欢用这个字体，很古典。 > **记录每周看到的接地气的潮流技术，筛选后发布于此，觉得不错可关注此周刊，方便获取更新通知** ## 潮流工具 **celldock-for-mac：在 Mac 上使用蜂窝网络、短信和通话** 这个产品有点意思，假如你手上有大疆的 4G 模块可以试试，我也打算搞一个玩玩，甚至可以插一张 SIM 卡，配一个模块，就变成出门在外的随身 Wi-Fi 了。 **kooky：又一个专为 AI Coding 优化的 macOS 终端** 支持侧边栏 workspace 管理、水平 / 垂直分屏、一键启动 agent、实时查看 agent 状态，也能在 pane 底部直接看到 Git、Node、Python 等工作区状态。 **史前动物博物馆的 3D 教学展示** 应该是父母给孩子做的一个史前动物博物馆的展示，挺有意思的，可以玩玩看。 **JJ：和 Git 兼容、但更适合 Agent 的版本管理** 这个思路还不错，底层还是 Git 仓库，工作区的模型更简单，更适合 Coding Agent 来使用，比如 AI 改错了，收拾起来会容易很多。 **介绍一下 Mole 的擦屏幕和擦键盘功能如何更好使用** 很多小伙伴问擦屏的时候还想擦键盘怎么办，其实默认就兼容了，去设置里打开擦屏的输入保护授权，再从 logo 进擦屏功能，非常推荐顺手设个快捷键，之后就可以拿细软布很舒服地擦屏幕和键盘，键盘也不会误触。
## 随便看看 **宝玉的 AI 原生开发流程：一个真实案例的完整复盘** 现在写代码在整个软件开发流程中只是一个环节，而且在 AI 时代，它反而是变化最小、最不需要操心的环节，因为现在的大模型在编码方面已经训练得极好了，简单的自然语言提示词就够了。真正有意思的变化是在代码之外：需求怎么分析、方案怎么设计、原型怎么做、测试怎么跑，这些「写代码之外」的事情，才是 AI 原生开发真正改变游戏规则的地方。 **最近发现这些年我的口味居然变了不少** 很神奇，大学期间一直觉得自己只吃辣的，不可能去碰那种甜口的菜，殊不知在杭州待了快十年，慢慢就喜欢上了各种口味。其实甜口的菜，清淡的菜也有很好吃的，比如最近我很喜欢去吃福建菜，很鲜很嫩的那种感觉。人生也是这样，越经历越有新东西可以体验，多好。
**随便写写：AI 时代如何保证代码可持续迭代和维护** 想从产品工程师视角和大伙聊聊，在代码全部由 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 合作开发打下一个比较稳的根基。之前手写代码的乐趣已经没有了，好在这件事弥补了一些纯 AI Coding 过程的无聊，让工程师的专业度得以延续下去。