春节假期用 AI 完善了懒猫读书，分享一下最近 AI 编程的一些经验给同学们
多个Plan是最好的并行编程方法
Git worktree 虽然在写代码时候不冲突，但是合并的时候还会出问题
所以最佳的方法就是跑很多 Agent，用 Plan 的模式，只跟他们聊天
看哪个 Plant 跑得快，就先执行哪一个
这样最大化利用多个 AI 的能力，又不会有任何代码冲突
应用层的开源项目会越来越少
以后应用层面的开源社区估计就没有了
因为应用层面的开发已经不是代码层面的交互、研究和微调
基本上属于人类用逻辑向 AI 买 token，AI 直接产出成品
真正有开源价值的可能就是一些底层领域，那些真正需要人做一个艺术家精雕细琢的地方
AI积木
AI 编程就是 “思维神交”， 有点像拼积木
最好的效果就是每次只针对一个点详细描述和改进
即使你编程经验丰富，逻辑超级清晰，也不要说太多改进点
因为一旦展开的代码上下文超过 AI 的容量，AI 就会从你的贴身全能专家变成新手 bug 制造机
Plan模式对于项目后期的重要性
Plan 模式对于大型软件项目还是必须的，因为 AI 也有偷懒的倾向
它在后期会为了修复你局部的问题，找一个最省力的方式把你原来写好的代码改的面目全非
所以，越到项目后期越要通过 Plan 模式来 review AI 的思路，避免它捡了芝麻丢了西瓜
先架构再细节
AI 编程的经验分享
优先让 AI 把架构、流程和逻辑搭建好
只要使用流程通了，就成功 80%，然后再和 AI 磨界面细节
AI变成的万能调试手段
AI 编程还是要靠万能手段：说 20 遍不如让 AI 详细把前后端日志详细打印一遍
有一个 2 天都没修复的 bug，最后还是靠超级详细日志一击致命
日志才是和 AI 沟通的最佳编程语言
Grok的奇效
Opus 和 Codex 写代码很厉害，但是他们的训练数据不够新
这时候可以用 Grok 查询一下开源社区最新的最佳实践
然后把 Grok 最佳实践丢给 Opus/Codex， 往往有奇效， 比如我问 Codex/Claude epub.js在移动端文字溢出的问题，这两个 AI 都在分析代码，但是没有找到最佳解决方案。 而 Grok 往往知道什么是社区最好的方案。
Codex的幽默
懒猫读书靠超详细的日志，让 codex 修复了一个超级复杂的 bug
然后我就想要让 codex 记录一下这次珍贵的修复过程到文档，下次再也不要犯同样的错误了
然后超级好笑的事情就来了，哈哈哈哈哈，哈哈哈哈，让我笑会儿
我问 Codex：你每次启动都会查看哪个文档？我们把这次修复的过程记录到文档中，避免下次误导 AI
Codex 回答我：http://CLAUDE.md