团队 Vibe Coding 月报 - 2026年7月（你的代码失控了吗？）

继上月发布第一个 ios app 之后，本月除了继续更新，还发布了第一个收费的 mac app：DotPeek，一开始的出发点完全是自用，但随后加入一些有意思的新特性之后，觉得不妨尝试一下收费应用，来看看有多少人愿意为之买单。

目前的战绩：两个付费，半个月内。同时，为了感谢帮我人肉测试的小伙伴，送出了一份。

DotPeek 是什么，为何付费，如何定价

出于对 v1.1 版的自信，在其发布之后，我写了一篇推广软文：“DotPeek 上架：一款本地优先、完全由 Mac 驱动的智能图片浏览器”，因为图太多，懒得在微信里重新贴图和编辑，故而没有发布在公众号，有兴趣的小伙伴可以前往： https://www.dteam.top/blogs/2026-07/dotpeek-an-image-explorer-powered-by-mac 阅读。

为何收费，上面的标题其实已经点出：只依赖 Mac 自身的能力。

它用到的全是系统自带的东西：Vision 负责识图和 OCR，Natural Language 负责语义，Translation 负责翻译，AVFoundation 负责朗读。没有云端处理，没有上传，没有账户，没有跟踪。

除此之外，它还有若干鲜明的特点：

• 图片去重
• 多种搜图方式：以图搜图、以文搜图
• 剪贴板管理
• 漫画支持
• 图片数据抽取

如此丰富的功能并非那种一个周末上架的产物，像图片布局也并非单靠 vibe 就能很快实现，既然如此为何不尝试一把付费呢。况且图片也算是一种常见的媒介。

至于定价，当然是调研同类产品的价格先。此事交待给 ai 最合适不过，你要做的就是等待和拍板。

如何让 vibe coding 的工程不失控

继上月看到的“新词”：Loop Engineering 之后，本月又有一个新词频繁出镜：Graph Engineering。

当然，哥依旧不以为然。

这些新词的背后无非就一个目的：如何让你的 vibe coding 的工程不失控。而这背后其实隐藏了一个完美的销售飞轮：

LLM 厂商：人人都是程序员的时代到了。
LLM KOL：我靠 vibe coded 的 app 实现不菲的被动收入，既轻松又潇洒。
技术小白：我也想这样。
...
技术小白：fuck，我也不知道现在的代码咋回事。
LLM 厂商：你需要用 context engineering、harness、loop engineering、graph engineering ...
LLM KOL：摇旗呐喊
技术小白：死马当活马医吧 ... <== 更高的成本，更高级的意大利面，

预计在一段时间内，这种循环还要重复出现，直到技术小白的子弹打光、精力耗尽。

当然，这里不仅限于技术小白……

失控并非 vibe coding 所独有，在古法编程时代就一直存在。vibe coding 无非将其放大了而已。

但有意思的是：如果在 vibe coding 时同样应用传统的控制失控的工程实践，本应也同样放大它们的效用。但，在这块看到的内容却很少。

或许是幸存者偏差，又或是那些成功控制好的人从来不叫唤。

我个人认为：除了技术能力和工程管理能力之外，首先需要克服的实际上是急于求成的心态。因为 coding 来的太容易，可能会让不少开发者放弃原本的实践，转而倾向于快速看到结果，再快速更改。但由于概率编程的不稳定和 ai 迭代速度太快，导致最终觉察到异常时为时已晚。

此外，老生常谈的上下文管理问题其实也并非 ai 时代的产物，古法编程同样有。对此，我稍微有些调整，总结成以下三条：

1. 代码是唯一的 source of truth
2. 只记录高层架构，目前采用 mermaid 形式
3. 代码之间的关系记录到 code map 中

这种设计涵盖了整体、关系和细节，完美！

并且，最近又最加了一条面向 ai 时代的实践：code reading test。本质上相当于古法时期的 code review，但不同之处在于：它不是以一本浓墨重彩的需求文档为纲，而是以一条条的总结 scenario 为 check list，挨个过。

实验下来，效果不错。

选定 Pi 作为未来项目的基础

这段时间花了点时间看了看 pi，同时小伙伴也尝试了一下 oh-my-pi，看看他的说法：

大的方法论的东西暂时没有大的变更。本月重度体验了下最近比较火的 omp (oh-my-pi) 项目。体验非常好，确实如官方所宣称的那样，快了很多。疑似是它使用极简内核 pi 的效果，非常简单的 system prompt，大大减少了上下文长度，模型执行速度感觉也比 claude code 快很多。

而且这玩意深度兼容 claude code，启动的时候会读取 claude code 的配置目录，对于 claude code 已经安装的插件、skills、slash commands、MCP 等 开箱即用，几乎完全不需要任何额外的配置就可以迁移使用。

omp 对于 LSP 是一等公民支持，开箱即用，注册了常见的 LSP 列表，会自动发现系统中的 PATH 已有的 LSP 并自动启用。而 CC 需要安装插件或 skill 才能使用。自带的 tools 也更多更实用，比如自带了 browser use ，不需要安装 playwright MCP 等。

总之初体验下来感觉非常好，甚至超越了 opencode 在我这的评价

看中它的原因主要有：

1. 轻量型和模块化的设计
2. 相当活跃且成熟的生态社区
3. 现成的 harness 框架
4. 支持热更新的插件设计
5. 支持多种集成方式