本月处于从南到北的战略大转移的过渡期，故而出镜率少了，而是将更多的精力放在其他方面：
- 产品新功能的开发
- 工业 Agent 的微信集成
- vscode-docpilot 插件支持 mermaid 渲染
- MonaKit 的小步快跑，以及围绕它建立的 Mona 宇宙的插件（注：尚未发布）开发。
- 本地社区和从业者的接触和交流，分别参加了两场有代表性的社区活动
本月强调的实践
先来看看我觉得有代表性的团队小伙伴心得：
- 将 url 给 ai 作为参考链接时，需要注意对应的网站类型，若是那种 CSR 网站，单靠 url 不行，需给 ai 提供类似 playwirght 这样的工具方能抓取到完整内容。
- 在与 ai 结对调试时，将期望、截图、日志（没有的话，让 ai 加上）等信息一并提供给 ai，能大幅提升调试效率。同时，将经验教训记录下来，形成知识库，便于后续参考。
- 在长对话中，ai 会遗忘甚至混乱，即使提醒也未必有效，甚至会引入新的错误，此时，重启对话并提供必要的上下文信息是更好的选择。
另一个值得吹嘘的是在考虑 MonaKit 架构时想到的歪招：Gemini Cli 和 Claude Code 助我“抄袭” Starlight 的设计。
一些老生常谈，我也就懒得列了，这里的关键是：不在于你了解多少，而在于你是否能真正去实践，同时将整个过程视为通关游戏：
- ai 是队友
- 老怪是“产品需求”
- 通关的目标就是“交付你自我感觉良好的产品”
如此以游戏化的心态去面对，自然会开发出属于你自己的实践和歪招。
本月相关见闻
关于 vibe coding，这个月我读到两篇有意思的内容，本来想独立灌水各写一篇，但受制于时间和必要性一直未写。正好在此一并列出关键点，算是对于 vibe coding 实践的补充。
我从来不读 ai 写的代码
一篇是 Zed 的访谈：Vibe coding in practice w/ Manuel Odendahl。这其中最让我震惊的地方是受访者的极端行为：从不读 AI 写的代码。
鉴于 Zed 本身在 vibe coding 界江湖地位，它的采访者自然也不是什么等闲之辈，所以我也就耐着性子看完了差不多一个小时的访谈。最后，我释然了：这哥们虽然自称不读 ai 写的代码，但实际上构建了一套基于 yaml 的 DSL。这本质上跟我们现在从来不读编译后的代码，而只跟 js 或 java 这类高层语言打交道的本质极其类似。只是他的这套基于 yaml 的 dsl 尚未通用到高级语言这样的级别。
vibe coding 老兵经验
这是无意间刷到的另一篇 vibe coding 杂谈，Just Talk To It - the no-bs Way of Agentic Engineering，不少观点跟我类似，自然大为欣赏，故而摘录。
关于 model
作者在撰文时全面转向 codex，其时恰逢 CC 的降智事件。从使用角度来讲，作者觉得 codex 背后的模型更聪明，用较少的话就能有更多的输出且质量不错。
以上感觉基本跟我类似，不过最近感觉 CC 的输出强于 codex，考虑到是月初的文章，以及 CC 也在进步，这种状况倒也合理，未来会持续观察。
关于 worktree
作者坦言自己尝试的结果是让开发更慢而不是更快，因为要起多个 dev server，以及他的应用是跟 twitter 相关的应用，受限于 webhook、登录次数限制等等，最终不再使用。
我也不是这类并行开发工作流的爱好者，主要原因除了作者说的外，还在于：
- 我个人喜欢一次考虑一件事，若是几件事相关，不如放在一起干。
- 我是 pro plan，并非无限 token 的 max，因为目前困扰我的并非这种 ai 性能，而是其他非技术方面。
- 大多数情况下，针对同一个项目代码 repo 进行并行开发，其时会降低速度，而不是提高。为何：沟通成本增加了。
若真需要并行开发，我可以想到的：
- CC 写代码；Codex 做 review；再让 Gemini 干点啥……
- 将大项目拆分成子项目，遵循 unix 设计哲学，让子项目之间的依赖最小化，并且不经常变动。若接口存在经常变动的可能性，那么考虑它们是否真的值得划分开。
关于那些 Jargons： slash command、mcp、plugin、subagent
作者并没有用太多的 slash command 和 mcp。关于 mcp，作者也主要就 chrome-devtools-mcp，并坦言 mcp 几乎都可以用 cli 工具替代。
关于 plugin 和 subagent，作者毫不掩饰对于它们的失望：
It’s me sigh-ing. What a big pile of bs. This one really left me disappointed in Anthropic’s focus. They try to patch over inefficiencies in the model.
并且还说，与其建一个所谓的 AI engineer subagent 告诉它一堆看似华丽的 prompt，还不如让它 google 相关领域的最佳实践管用：
If you want to get better output, telling your model “You are an AI engineer specializing in production-grade LLM applications” will not change that. Giving it documentation, examples and do/don’t helps. I bet that you’d get better result if you ask your agent to “google AI agent building best practices” and let it load some websites than this crap.
再次印证上下文才是关键的老话，😄。当时 CC 尚未推出 Skill，自然咱们没法看到作者的辣评。
从我个人的状况来讲：
- slash command 和 mcp，也没有太多，mcp 也就一个 playwright。
- plugin，我觉得它的最大价值在于提供了组织内复用经验的一个简单方式。
- subagent，感觉一般般。
- skill，本质上相当于面向 agent 的专业话题指南，但我个人觉得若非提供了好的 script （它是工作流程中关键步骤可复现结果输出的强力保证，因为是代码），跟你自己把相关的东西组织在一个文件中放在一个专用目录下没有质的区别，我在之前的文章中提过的土法子与之类似。
归根结底，将相关知识更好地组织方便 ai 去查找才是王道，并且这样的东西是工具中立的，可随时方便从 A 转到 B。
无独有偶，Gemini 也推出了插件机制，各位可自行查阅。
关于 prompt
作者主要采用：一两句话 + 截图来跟 ai 交流。而且，最近大热的 deepseek-ocr 又让“一图胜千言”的话题热闹起来了。
关于 spec driven
作者采用的是非正式的 spec，更多的时候是用对答方式直接跟 ai 交流，觉得必要了才让 ai 写 spec。
前月总结曾提到想试试 spec-kit 之类的工具，但限于时间精力而搁置。这个月，我抽时间看了看，初步感觉是：不喜欢（让各位失望了 😄）。主要原因是：
- 我比较讨厌一个工具在我的工程目录下自行创建一堆文件。
- 我也非常讨厌一种僵化的开发套路，尤其是它每次都给你开一个新分支来对应新特性。
- 我也推崇并采用特性分支的做法，但是我讨厌的是自作主张地给我创建了，我希望这个控制权在我而不是工具。
- 同时，我也不喜欢记一大堆命令，在有自然语言交流的 ui 下，再强行要求记一大堆命令，我觉得是开倒车。而且私以为也是大多是人发现 slash command 华而不实的原因，往往都是一开始兴冲冲写了一大堆，实际发现大多数情况下还不如直接对话来的方便。
但是，以上都不是根本原因。更主要的原因是，我目前很多尝试都只是简单的想法尝试，懒得花时间去写一个内容翔实的 spec。并且，我也觉得 spec 依旧还是有价值：当你的需求目标都很明确的情况下，spec 驱动未尝不是一种好方法。
但若是你正在进行新产品的尝试，我个人觉得灵活度不够，而且舍本逐末。
因此，我初步的结论是：
- spec driven 非常适合外包行业或者是做外包项目
- 但对于新品开发，poc 或 mvp，完全没有必要。更好的做法是，让 ai 基于已认可的 mvp 或 poc 生成一份新的 spec，然后按工程实际去进行。
至于是不是采用 spec-kit，那是个人喜好。你要问我会不会用，我的答案是：短期内不会。