本月的总结比以往要来的晚一些，因为昨天一直忙于优化手头正在 vibe 的 ios app。好在努力没有白费，最终的结果让我得以在聊天群里炫耀：
ios 自带的不如我的
这便是我正在 vibe 的新尝试：Lingo，一个 local first 的智能助手，一个 mac/ios native app。
说到这里，就顺便 share 一下我正在和已经尝试过的 vibe coding 项目。下图源自本月开始的 vibe coding 实战课程内容的 slides：
列位看官应该可以看出来，它们都是不同类型，不同应用场景的项目。这样的做的方式无它，只不过是：
- 尝试新想法，看看是否有发家致富的可能性。
- 探索 vibe coding 的边界，为未来更快、更高、更强积攒必要的经验。
我的 swift vibe coding 体验
vibe coding 工具表现
总的来讲，比起这类工具的强项：js/ts 和 python 系，整体表现要差很多，加之 gui 类应用本来也没有太好的测试方式导致像 CC 和 Codex 这类 coding agent 很难左脚踩右脚。
不像 web 或 cli 应用，起码还可以让它跑 playwirght 和调 cli，再配合 docker 就能实现很大程度的自测自写。（这里先不论测试本身是否可以覆盖全部场景。）
因为，你成了它开发反馈的重要一环，需时不时将截图传给它看。
CC 和 Codex 表现不同
并且有意思的是，CC 一开始表现欠佳，基本上都是 Codex 来给它收拾残局；但是随着项目代码慢慢变多，CC 的表现开始超越 Codex。这其中除了工具本身在迭代表现也是动态的原因之外，会不会还有另外的原因： CC 更擅于从项目中学习呢？
以上纯属个人臆断，且开发中也未曾安装 swift skill。
vibe coding 是个涌现式设计的过程
我最早看到“涌现式设计”一词还是敏捷和 TDD 正当红的时候。其实，它的核心无非是根据反馈调整设计思路的过程。
与之前我尝试的 vibe coding 的项目不同，lingo 有很多关于音频、图像和视频的处理，并非简单调用 coreml 就能搞定，尤其是预处理和后处理。
对于这类强算法相关的项目，CC 和 Codex 无一例外会给出复杂的解法。一开始其实我并未在意，因为本来对这类复杂度就有预期，而且相信它们在这方面肯定比我强。因此，一开始我的任务就是 review 思路和测试。
一开始进展还顺利，跟以往一样，我顶多是在它迷路的时候指点迷津。待功能主体 ok，开始打磨细节之时，比如翻译文字的大小、方向、布局之时，便发现总是不尽如人意。
某次深入讨论时，在 CC 给我列出一个复杂的计算方式之时，当时我灵机一动，给出了我凭直观的感觉，让它直接从识别出的 box 的大小方面去考虑，不要去想复杂的计算算法。CC 瞬间明白我的意思，拍了一通彩虹屁，给出了简单且我们都满意的结果。
我也找到了博导指导博士生研究方向的感觉 😄 。
警惕强算法方案
在强算法背景的项目中，CC 很容易会预设按强算法设计方向去设计方案。大多数情况下，这没有问题，但也需注意这并非全部。而这也恰恰是开发存在的价值：在它过于偏执之时，拉它一把。
有价值的团队总结
环境和 LSP
给 AI 提供最合适的方式工具去工作，并且在 prompt 中明确指示 AI 使用给定的工具或工作方式，而不是让 AI 完全自主决策会事半功倍，例如:
- 明确指示 AI 使用
github-cli(gh命令) 而不是 webFetch 方式获取 github 资源信息(issue, ticket 等)，不然更省 token, 准确率更高，而且速度更快 - 给定
compose.yaml/Vagrantfile等文件让 AI 明确启动测试环境完整自主测试。这样 AI 可以每次在修改完代码之后自动跑完整的测试环境进行验证，并且测试完毕之后清理测试环境，而不是虚构测试环境和测试用例，代码更准确 - 安装必备的 LSP 工具让 AI 明确调用 (opencode 自带，claude code 可以安装对应的 SKILL)，可以让 AI 在编辑代码过程中发现语法错误，可以大大减少返工次数
项目词汇表
可以创建一个 glossary.md 项目业务术语文档。用于统一人和 AI 对关键概念的理解，减少“名词不一致”导致的沟通和实现偏差。比如项目中 Virtual Equipment 在实际业务中表示 组态, 就可以这么记录：Virtual Equipment | 组态，虚拟设备
后继
关于 lingo 的演示视频，再进一步调优后会放出。同时，我有了另一个想尝试的点子，尽情期待！