共计 1353 个字符，预计需要花费 4 分钟才能阅读完成。
目前，我的编程习惯是，晚上开始写代码时，我会使用 claude code 和 kilo 进行初步设置，给出描述后便让它自动运行，然后我就去睡觉。
早晨醒来时，我通常会得到一个功能完备、能够直接运行的代码库，代码量也相当庞大。
接下来，我会将其转换为 gemini 2.5pro，询问代码的具体功能。经过我对提示语的调整，gemini 会不断详细解析代码，输出大量的 markdown 内容，而我则会下楼享用午餐。
午饭后，我开始仔细阅读 gemini 的输出，以了解昨晚 AI 所完成的工作。
如果发现问题，我会将其记录下来。
然后，我会切换到 o3 high，让它根据我的要求逐步调整任务列表，逐项进行修改。
总的来说，opus 在启动项目时非常合适，它会考虑许多因素，比如可观测性和故障排查的效率等。而且，它往往能一次性完成代码的编写，许多针对 AI 的代码基准测试仅仅是让其处理小段代码，这样无法显现 opus 的优势。如果前期的基础未能打牢，后期的重构将变得愈发困难。
o3 high 非常聪明，对于需要细节调整的地方，必须依赖它提供方案，而 sonnet 有时会提出一些相对愚蠢的建议，尤其是在算法方面。o3 high 的洞察力有时甚至超过专业程序员，但由于其输出的 token 量严重不足，因此需要通过待办事项列表和继续命令来推动其继续工作。
gemini 的优势在于其卓越的上下文理解能力和快速响应，特别适合进行翻译任务。它能够很好地理解代码的逻辑和含义。另外，有一个小窍门就是，gemini 并不需要根据其他代码来生成翻译文档。例如，若存在两个相互调用的 python 代码 A 和 B，gemini 可以逐步进行处理，先理解 A 并输出 markdown，然后再根据 A 的输出和 B 的内容生成 B 的 markdown，接着再利用 B 的输出检查 A 的 markdown。通过这种 ABCD 相互验证的方法，gemini 能够在一夜之间全面理解千万行代码库，并且不会出现理解错误。
至于 sonnet 4.0，它更适合根据非常详细的规格说明书来编写代码，规格越详尽，它的表现越强。但 sonnet 的智能水平较低，这种局限性在长期使用中会逐渐显露出来。例如，它无法理解某些代码已被弃用，而 o3 high 能够快速理解代码调用的逻辑关系，sonnet 却可能在一夜之间都无法搞明白。当代码库庞大且逻辑复杂时，sonnet 的问题会逐步显现。
这种工作方式与传统的规格编码有很大不同，我之前也尝试过单纯的规格编码。
实际上，我会与 o4 mini 讨论出一个规格，然后让 sonnet 生成代码。
然而，很多情况下，我一开始并未考虑周全，导致规格难以做到完善。
有时 AI 需要自行进行一些性能测试，才能改变思路，因此我与 AI 都需要通过实验来形成完整的规格。
如果需要 claude code 的相关信息，欢迎私信我，附赠我们 20 人软件工程师团队的全面经验分享 (●’◡’●)
