长假结束，9 月的团队 Vibe Coding 总结如约而至。
本月强调的实践
一将无能累死三军
面对不确定性较大的事情，放弃思考图省事，放手让 AI 自己去做，你最终可能会陷入反复修改的死循环，最终不得不自己收拾烂摊子：详见Claude Code 开车大折返：从弃用 Pagefind 到重新拥抱。
打开思路，AI 也是“同事”
AI 不同于以往的工具和类库，它具有生成能力，能听得懂人话。这无疑扩大了它的能力边界，如果仅仅把它当作一个普通的、更强的的 API 接口，那无疑是捧着金饭碗要饭。
将其视为一个“同事”，会给你带来思维上的转变，进而自行挖掘更宽广的使用场景。面对不确定或思维盲区时，不妨尝试先与 AI 交流讨论一番，或许会有意想不到的收获：详见钱都花了，为何你们吹爆的 Cursor、Claude Code 和 Codex 仍然没有输出我想要的结果？。
照此逻辑推演，很自然的会得出：自然语言也可以作为测试规范，于是乎有了帮你执行测试的同事：告别 Playwright 脚本，迎接 AI 驱动的 E2E 测试新范式。
搞不懂 AI 写的代码？让测试帮你质问它
这一条来自团队成员的实践分享：
不要 review 代码，技术不如 ai 的时候 review 不明白，用测试验证结果，当然测试也用 ai 来生成。
这本质上就是“结果导向”，大家应该都对影视作品中“我只看结果”的霸总们印象深刻吧 😄。
对于经验不足的新手或面对陌生领域的老鸟们，此条实践尤为适用。但这里有个前提：你得非常清楚你想要的结果是什么。并且，这里的结果不仅仅是正例，还包括反例。换而言之，你得有一份详尽的测试清单。
否则，你可能会漏掉 AI 给你埋的雷。
在 AI 遇到问题时，你需要提供帮助
说白了，要当好“服务型领导”，而不仅仅是发号施令之后就坐等小弟来汇报结果。当发现它明显无法胜任某项任务时，要么：
- 直接接手
- 在重构我们英文站点的知识卡片时，原来的实现为重度 react 组件，但我们希望将其改造为更符合 astro 风格的方式。一番尝试后，发现 AI 小弟改得一塌糊涂，最后由团队成员直接接手完成。
- 提供必要的帮助，典型如：
- ui 设计时，提供参考样例。
- 代码实现时，提供重要依赖的代码，让其直接学习。
总之，在霸凌 AI 之前，先反思自己的支持是否到位。
本月尝试的工具
本月适逢 Claude Code 降智加封锁风波，同时 OpenAI 新版 Codex 好评如潮，于是乎，小伙伴尝试了 Codex 并解决了不少问题，其中一个详见：利用 Codex 增强 Astro 站点中 Reveal.js Markdown Slides 的图片渲染。
总的来讲，小伙伴的对它的满意度不错。
此外，原本有意尝试各方都在吹的 Spec 驱动开发，奈何由于时间、精力等若干原因，最终无疾而终。