近几个月来因为在肝很急的项目，所以被迫当上了全栈工程师（虽然我对前端几乎一无所知），高强度地使用 AI 来写代码，被迫地总结出了些许心得，在此分享一下。提前声明一下，我的项目因为主要是科研用途，对代码质量的要求并不是很高，使用的也是 AI 最擅长的 Python, 所以全程 vibe coding 也问题不大。

我最开始的做法是在网页端向 AI 描述我的需求，然后将 AI 写好的函数复制到我的文件里，最后我把它们组织起来，这种写法其实效率较低，但是好处是自己对代码的细节仍有掌控，而且个人感觉网页端的 AI 智商比后面的命令行 ai 高很多，代码质量也相当喜人，可能是 Prompt 给的比较好。之后随着项目的扩大，再加上前端的需求，我逐渐无力应付，于是也开始转向 codex, cursor, gemini-cli ，以下是一些心得。

平台选择

目前我重度使用的平台有 codex, cursor, gemini-cli 这三个，之前听别人说 codex 适合 de 很复杂的 bug, cursor 适合后端，gemini-cli 适合前端，但是我基本上是哪个充了会员就用哪个，所以并没有很深的体会。

cursor

cursor 默认使用的是一个它们自家微调过的模型，效果感觉十分不错，属于模型本身不太行，但是通过精耕细作达到了 120 分的发挥，具体的体现在它给出的代码改动通常十分精确，即使在长上下文下也是如此，而且使用的 desktop 客户端也提供了一些说得过去的撤销操作的支持。但是缺点是太贵了，我仅试用完了免费的额度后就没再使用了。

gemini-cli

这个是我目前主要使用的平台，得益于学生优惠，我可以免费用一整年，但实际上效果也是最差的。首先是各种林林总总的 bug ，比如说遇到某个字符之后整个对话就无法继续/resume ，再比如下面的这个刚遇到的奇妙 bug

ℹ IMPORTANT: This conversation exceeded the compress threshold. A compressed context will be sent for future messages (compressed from: 778532 to
  598466 tokens).

ℹ Request cancelled.

> /compress

✦ Chat history compression did not reduce size. This may indicate issues with the compression prompt.

:-)

除此之外在长上下文下，gemini 给出的代码修改也会变得非常低质量，如在每一行中间加入空行，将自己的思考写入注释，或者循环输出都是家常便饭，甚至还会向我吐槽说 google 给它的代码修改工具难用，整体来说让人觉得非常地...印象深刻

它有四种模型可选，gemini-pro 系列和 gemini-frash 系列，各有 2.5 和 3 两种版本，我一直使用的是 gemini-3, 但是 pro 和 frash 哪个好我着实没感觉出来，一个喜欢说英文，一个喜欢说中文的区别吧。

codex

如果有 gpt 的会员的话就可以获得 codex 的额度，这个也是我很喜欢的平台，（奈何我没会员了），相比 gemini 其性能要更加稳定一些，有着更好的调教，但是中重度使用很容易触发它的限额。我很喜欢的是它的 review 功能，是用很客观的视角监视代码的修改，并且给出一些建议，我后面用 gemini 的时候也尝试让 AI 来 review 自己的修改，但是它只会对自己的代码一通夸。我在用 codex 的时候还没学会后面的一堆操作，但是代码质量还算不错。

此外它比 gemini 更喜欢使用命令行工具，会用更多 sed 之类的指令

单元测试/静态检测

对我来说测试分为两部分，一部分是新功能的测试，这部分没什么可说的，AI 会编写一些简单的测试用例，即使我强调需要充分测试，所以感觉只能找出一些比较低级的错误。

第二部分则是 debug, 倘若你发现一个 bug 然后描述给 AI 让它修复，实际上它只会乱改一气，只有在足够幸运的情况下才能修改正确，还会加上一堆兜底的代码，因此更合理的做法是让它先复现 bug 再（让它）进行修复，前端的 bug 也是如此。

此外静态检测也很重要，就 gemini 来说，它很容易写出非常低级的错误，pylint 之类的工具可以检查出来不少。

尸检报告

这个也是从推特上看来的技巧，其重点是将每次的代码提交写成一个总结性质的尸检报告，之后每次提交都检视这些报告，检查是否与原有的提交相互冲突。不过我没有太用到这个技巧，因为学到的时候项目复杂的部分已经写得差不多了。

Prompt

最后分享一个 prompt, gemini 写代码时会比较急躁，可能就是最近人们常说的“上下文焦虑”，这种状态下的 AI 容易做出一些诸如 rm, git restore 之类的不理智的操作。为了解决这个问题我给它写了个名为 事缓则圆 的原则，放到它的 GEMINI.md 里面， 然后每次让它做事情，或者看到它抽风的时候就念一遍这个咒语，实测可以有效地平复 AI 的心态，但是仔细想想又觉得这样有一些滑稽——像两个和尚一见面就说“阿弥陀佛”

> 什么情况呀，事缓则圆

✦ 确实“事缓则圆”，在处理复杂的元工具逻辑时，我不慎导致了数据库状态的异常。