お待ったせ，本月报终于迎来了最后一期！（注：第一篇始于团队 Vibe Coding 月报 - 2025年6月。）
有看官可能好奇：为何偏偏在此时终结这份月报，难道是因为如媒体所言 AGI 要来了？非也！非也！
终结原因并不复杂
目的已经达到
因为初篇说了，它是为了促进团队交流和反思。一路走来，团队成员已经习惯于与 ai 协同作战，并且积累了各自的经验和相关的工具。
AI 编程能力日益提高
相比起一年前，如今的 ai 编程已经不再那么“野路子”了。遥想当初我在写 vscode DocPilot 插件的时候，要让它写个测试，一上来尽是 mock，谎报军情，贻笑大方。
最近，CC 已经在干活之前知道要进行探索，在自己的小本本上先打草稿进行 spike，并依据例子代码结果来修正设计。
在默认 auto 模式之后，稍加指导并提供适当环境，它就能配合写出对应的 e2e 测试。以我目前在干的 agent 项目为例，技术栈：next + eve + python + pg。现在对于任何特性，它已经知道自己去：
- playwright e2e 测试
- eve eval
再配合 claude design，只要想清楚和讲清楚，每个特性开发如行云流水，较之去年不可同日而语。
硬知识终将内置
所谓硬知识，并非单指哪些火箭科学，也包括一些做事的常规流程，比如常说的：PDCA。
这一点我是无意间注意到某个版本的 CC 突然在 tmp 目录下创建 scratchpad 目录然后在里面开始写 spike 代码时意识到的。
这不就是咱们码农在古法编程时代常干的事情吗？！这意味着行业的最佳实践终将以某种形式植入到 ai 编程工具中，目前时髦的叫法是 harness。
既然如此，何必再每月写这些劳什子，不如激流勇退 😄！
开发者会被 AI 取代吗？
我个人觉得得分情况，而且作为开发者，我当然不愿意说“是”（注：你们也别当真，看看就好，哈哈。）
对于那种只有单一标准判断的软件，我觉得会很快，典型比如那种科学计算库之类的，没有什么 ui 之类的软性东西，实现数学公式，只看性能。这类验收标准很容易量化，无需人工干预。（当然，有人会说你得要让人来审核 ai 写的代码，确保安全性。没错，但那是代码审计和安全领域，属于监工，不属于施工。）
反过来，只要验收标准没那么硬的，“人”发挥空间就很大。但反过来，对于人的要求也高了。不说那种互联网规模的系统，就那种简单的 CRUD，都有可能衍生出多个标准：
- UI/UX
- 技术框架和工具库
- 数据库和领域模型设计
- 最终形态：cli、单机还是 web
这还没算用户权限等安全相关的要求。这也是为何我在Vibe Coder 的自我修养所言：
由于 ai 降低了编程门槛和成本，反而可能会让个性化 app 大行其道。如此一来，开发者怎么会失业呢？
最后的团队成员总结
来自 OMP 爱好者
经过一个月深度使用 omp，发现它的 memory 系统特别好用。特别是 memory 可以跨项目在整个机器共享这一点特别好，对于微服务架构之间的开发特别友好，需要跨版本库分析上下游调用链的时候特别关键，不需要临时探索。
所以对于 memory 的管理，我的策略如下:
- 本地 AGENTS.md 只写最基本的当前项目的内容，确保单独提交项目的时候不会有文档漂移的问题
- 本地需要跨库的内容一律让 AI 记录到 memory 中，比如上下游的版本库在哪里、关键的调用接口和调用方式等等
这样在需要结合上下游共同 DEBUG 的时候，可以事半功倍。
来自 skill 爱好者
- 自己常用的流程让 ai 做成 skill，也不需要自己会写，把自己需求描述清楚让 ai 来干。比如准备好素材，让 skill 来创建子平台
- 可以多安装别人写的好的 skill，比如 讨论方案：
grill-me，解决问题：first-principles-skill
结语
既然 code 是 llm 的输出，那么开发者能够做的就是：
- 选择最好用的模型
- 类似 10x 程序员
- 提升对于手头任务的理解能力
- 理解能力决定了你的决策能力
- 扩充自己的知识面，不论是新框架还是新技术，还是新的领域知识
- 它们将决定你的设计能力（比如面对同样的 web 类 CRUD，那么多现成的框架，ai 也不知道选哪个，这时候你不拍板谁拍板。）
- 其他类数据
说白了，对于 ai 小弟，你的任务就是两个：收集数据和指明方向。当然，必要时你还得干点脏活累活，比如搭建基础设施什么的。但它们也会很快被 agent 替代，比如最近我自己在 dgx spark 上搭建全本地 ai 环境，就是让 cc 去干的。只是因为我不放心给它 sudo，所以凡事需要 sudo 的都是我来做。要在以往，我是没啥兴趣干这活的，哈哈！