本月，为了试探自己 vibe coding 的能力以及它的边界，在月初心血来潮决定 clone 大名鼎鼎的 NotebookLM。当然，这其中还有另一个缘由：不在于局限于文本输出。最终，差不多三周之后，基本完成。整个技术栈和人员配置：
- agentic 前端：nextjs + copilotkit
- 文档处理：docling + pgvector，python
- agent 后端：langgraph agent + pgvector，python
- llm provider： google gemini api
- vibe coding 工具一如既往：主程 CC + 辅程 Codex
- 人员：1 人
虽说是三周，但每天也就至多投入 4～5 小时（注：工作日且并非每个工作日），这其中受限于几点：
- 这个项目毕竟是实验项目，不赚钱
- 目前使用的 CC 并非 max plan，每当时限到的时候，就需等待。
- 因为是 adhoc 的方式，并非那种一上来就有很清晰的产品设计路线图，更多的是信马由缰，等到灵感来时才动手。
最终的效果：UI 高度相似，主要功能基本实现。没有做的几件事：
- prompt 本身的优化
- langgraph 工作流的优化
这是因为我更关心整体架构，而非局部性能，具体效果可以在我的视频号查看这个视频。
整个过程的收获：
- 敲定了工程化的工作方式：
- 我手写 ticket + ui 图 + references // 注：小 ticket
- CC 生成设计文档，我 review // 注：类似 plan mode，但是设计文档存放于我显式指定的位置
- 认可后 CC 实现，我测试
- 定期重构和 clean 代码
- 确定了文档规则，避免了 ai 在写文档时写入大量废话和重复内容，典型比如：
- 不要包含代码细节，只包含代码地图，因为 code 是 source of truth
- 凡事可以在其他文件找到的，均用链接
- 确立 coder 和 ai 的职责划分
最终，这些内容形成了一篇标题特俗的文章，发布到了我的微信号上：消耗上亿 Token 后我又总结了一份 Claude Code 的工程经验，：）。（友情提示：这篇文章其实是基于我的英文 slides 写就，内容反而不如后者详实，有兴趣看的话，自行从文后评论去找）
在整个编码过程中，另一个体验是：假如你的环境可以方便 ai 自行验证，那么只要不是设计和 model 能力的问题，你可以很快得到一个不错的结果。这个在实现文档处理部分功能时体会尤为明显：因为它本身是 cli，且数据库也在本地 docker 中，数据库表结构也很明确。于是，在 coding 时，ai 实现完了，它就会自行跑 cli ，然后去查数据库，并根据结果自行分析和调整代码。
其背后的逻辑其实跟这篇文章里，由 ai 自行去利用 playwright mcp 进行测试如出一辙。
团队总结
本月的小伙伴总结：
- 维护一套持续更新的业务文档与组件文档。当修改某一功能时，将该功能对应的业务说明、相关流程以及组件设计文档作为一个整体语境输入给 AI。
- 在让 AI 进行 UI 和交互设计时，优先使用设计领域内的专业术语与风格体系（如 Minimalism、Swiss Style 等），而不是“简约，高级，有质感”这类词。
- 让 AI 想办法自测代码可以大幅减少返工率。如果项目能做到 TDD 最好，如果做不到或者成本非常高，那么至少也需要让 AI 实现交叉验证，总之有测试可以大幅减少返工率，以及提升代码准确率
工具尝试
由于不满于 gemini cli 的质量和速度，我终于装上了 opencode，主要是用它来和我付费的 gemini api key 配合。阔是，体验结果并不像各大自媒体中吹嘘的那么好。具体我也懒得说了，一个原因可能是因为 claude code 的开发体验太好了，;)