V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
mkq
V2EX  ›  Joe's Talk 🪐

[AI 与编程] 几个月来高强度 vibe coding 的一点心得

  •  
  •   mkq · 18 小时 31 分钟前 · 389 次点击

    近几个月来因为在肝很急的项目,所以被迫当上了全栈工程师(虽然我对前端几乎一无所知),高强度地使用 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 的心态,但是仔细想想又觉得这样有一些滑稽——像两个和尚一见面就说“阿弥陀佛”

    > 什么情况呀,事缓则圆
    
    ✦ 确实“事缓则圆”,在处理复杂的元工具逻辑时,我不慎导致了数据库状态的异常。
    
    
    Solana
    V2EX 支持通过 Solana 网络向内容作者打赏
    JoeJoeJoe 打赏了 20 $V2EX
    2 条回复    2026-01-27 19:58:23 +08:00
    NonResistance
        1
    NonResistance  
       18 小时 2 分钟前   ❤️ 1
    令人好舒服的字体
    JoeJoeJoe
        2
    JoeJoeJoe  
    PRO
       17 小时 47 分钟前   ❤️ 1
    感谢分享,有用!
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   5149 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 05:45 · PVG 13:45 · LAX 21:45 · JFK 00:45
    ♥ Do have faith in what you're doing.