共计 1283 个字符，预计需要花费 4 分钟才能阅读完成。
如今，我的编程习惯是这样的：晚上开始写代码时，我会使用 claude code 和 kilo 组合，简单描述后便让它自行运行，然后我就去休息了。
早上醒来时，通常能看到一个完整且可运行的代码库，代码量之庞大令人惊讶。
接着，我会切换到 gemini 2.5pro，询问它代码的具体功能。经过我调整的提示，gemini 不断地对代码进行详细解释，输出大量的 markdown 内容，而我则趁机下楼享用午餐。
午餐过后，我开始仔细阅读 gemini 的输出，以了解昨晚 AI 所完成的工作。
如果发现问题，我会将其记录下来。
然后，我会切换到 o3 high，让它列出待办事项，逐步按照我的要求进行修改。
总的来说，opus 非常适合项目启动，它会考虑很多因素，例如可观测性和排错效率等。此外，opus 的代码通常能一次性成功运行，而许多关于 AI 的代码基准测试只是让 AI 处理一小段代码，无法体现 opus 的真正优势。如果前期的基础没有搭建好，后续的重构将变得愈加困难。
o3 high 非常聪明，对于细节的修改必须由它提供方案，而 sonnet 常常提出一些不切实际的建议，尤其是在算法方面。o3 high 在某些方面的洞察力甚至超过了专业程序员，但它的输出 token 数量却显得不足，因此需要通过待办事项和继续指令让其持续工作。
gemini 的强项在于其出色的上下文理解和响应速度，非常适合翻译工作。它能清晰把握代码的逻辑和意义。一个小窍门是，gemini 并不一定需要根据其他代码生成翻译文档。例如，针对两个互相调用的 python 代码 A 和 B，gemini 可以分步进行分析：先理解 A 的输出 markdown，再根据 A 的 markdown 和 B 生成 B 的 markdown，最后根据 B 的 markdown 检查 A 的 markdown。通过这种方式，gemini 能够在一夜之间全面理解千万行的代码库，且不会出现理解错误。
sonnet 4.0 则更适合根据详细的 spec 文档进行编程，它的能力与 spec 的详细程度成正比。然而，sonnet 的智商较低，这种低智商在深度使用过程中会逐渐显现。例如，它无法理解某些代码已被弃用，而 o3 high 在调用逻辑上很快就能掌握。随着代码库的庞大和逻辑的复杂，sonnet 的问题会愈加明显。
这种工作方式与 spec 编程大相径庭。之前我也尝试过纯粹的 spec 编程。
实际上，就是让 o4 mini 帮助讨论出一个 spec，然后由 sonnet 生成代码。
但问题在于，很多时候我自己一开始都未能想到，这样的 spec 难以做到全面。
AI 有时也需要进行一些性能测试，才能转变思路。因此，我与 AI 都需要通过实验来形成一个完整的 spec。
如果你需要 claude code，欢迎私信我，我将分享我们 20 人软件工程师团队的全面使用经验 (●’◡’●)
