• 请不要在回答技术问题时复制粘贴 AI 生成的内容
VeryZero
V2EX  ›  程序员

你们都如何 review AI 生成的大量代码,保障功能质量

  •  
  •   VeryZero · 9h 54m ago · 1647 views

    用 codex 这么久,从刚开始的屎山横飞慢慢调教到现在 99%的代码都由 AI 生成,并且上线质量比我自己写的还高,我以为我自己练成了。

    直到我最近接了一个新模块的需求,灾难发生了。

    这个模块因为比较老,从代码风格到项目规范都与我一直在维护的模块差异很大,并且由于我从来没碰过这块业务的细节,导致 codex 也没有这个模块的记忆。

    为了补业务细节,从阅读需求开始我就让 AI 全程参与,并且让$Grill with Docs 一致拷问我,讨论并设计完后生成了一堆 ticket ,AI 照着 ticket 一个个执行并验收。

    到了 review 代码的时候我人傻了,完全就是屎山,流程模糊、结构混乱、坏味道一堆,看完血压都能飙升,根本看不明白。

    这两天我一边擦屁股一边在思考,到底问题出在哪,如何去解决。目前总结出来的主要是下面这些,抛砖引玉吧,希望大家踊跃讨论,一起提高驾驭技术。

    长上下文导致失忆

    我虽然知道长下文会导致失忆,但是这次体感特别明显。我在 AGENTS.MD 里积累了一些项目规范,以前都遵循的挺好,但这次代码中出现大量与 AGENTS.MD 约定不一致的情况,似乎 gpt 失忆了。 我猜测是不是跟$Grill with Docs 这个 skill 有关,因为之前的项目我只用$Grill Me ,不会让他输出成文件。当上下文中被填充了大量的约束,智商可能就会下降。之前在某篇文章中看到过,给 AI 的提示词尽量给正向引导,而不是大量的禁止约束。

    自己总结代码风格而不要让 AI 总结

    我们都知道,AI 会参考项目中原有代码,如果原代码是好的,就会学好,反之就会学坏。 我之前负责的模块之所以 AI 驱动运行良好,是因为经过这么多年的持续优化,已经形成了我个人的编码偏好,写新的代码时候 TA 照着抄就可以了。但是到了新模块并没有我的风格,并且原代码的风格又很差,就导致 AI 有样学样跑偏了。 后来我让 AI 总结我负责模块的编码偏好并整理成.md ,让 AI 基于这个.md 的偏好对这坨屎山进行重构。效果还不错,但是因为这个偏好文件是总结性的,比较宽泛抽象,很多细节偏好需要我手动补进去。

    技能并不是银弹,反而可能是洪水猛兽

    gpt5.6 出来后很多人说跟 superpower 有冲突,我因为很早就卸载 superpower 了,所以没感觉。但是经过这个项目,我感觉不仅仅 superpower 的问题,$Grill Me 那一套可能也有问题。这个项目之初我是装了$Grill Me 全家桶,现在删了只剩$Grill Me 了,因为目前来看效果并不好,并且会导致每一次对话都非常慢,严重降低了反馈效率。即使$Grill Me 我也用的有点力竭,昨天重构时他拷问了我 2 个小时才开始执行,整整 2 个小时!我就在那一直确认,人也不敢离开,结果执行重构也就花了半个小时。现在感觉还是 codex 的 plan 模式舒服,只问重点,并且更容易知道我要什么。

    先写这么多,我要继续擦屎去了,毕竟留给我的时间不多了。。

    20 replies    2026-08-09 21:45:52 +08:00
    NoCash
        1
    NoCash  
       9h 5m ago   ❤️ 2
    楼主,经这一战,你觉得 AI 的泡沫什么时候破
    scegg
        2
    scegg  
       9h 0m ago
    与人干活时候一样(虽然很多项目组不执行):除非前端不可自动化测试的部分,必须全分支单元测试覆盖。CI 的时候必跑所有单元测试。
    loading
        3
    loading  
       8h 57m ago
    人也 hold 不住超级多的上下文。

    内存永远是不够的。
    WilliamZuo
        4
    WilliamZuo  
       6h 34m ago
    把锅甩给别人。
    WilliamZuo
        5
    WilliamZuo  
       6h 33m ago
    AI 降低了做决策的间隔,但没有降低做决策的成本,解决方法就是责任转移不做决策。
    john1024
        6
    john1024  
       6h 32m ago
    你可以专门搞一个 review 的角色。这个角色智商一定要高。它可以是 max/xhigh 版本的 Ter 。也可以是 high 的 sol 。但不能是太高思考的 sol ,因为太拖沓。
    msg7086
        7
    msg7086  
       6h 19m ago
    一个实施模型,一个审查模型。
    比如说你让 GPT 实施,让 Gemini 审查。
    GPT 写 Spec 和 HLD ,然后交给 Gemini 审查,告诉他这是你竞争对手模型写的计划书,狠狠拷打。
    然后把拷打完的意见交给 GPT 评估,让 GPT 照着修改。GPT 不同意的,让他写意见书。
    重复以上两步直到双方意见一致。
    然后你让 GPT 写代码提交,然后让 Gemini 审查最新提交,狠狠拷打。
    然后把拷打完的意见交给 GPT 评估,让 GPT 照着修改。GPT 不同意的,让他写意见书。
    重复以上两步直到双方意见一致。
    然后闭着眼睛推送代码。
    foryou2023
        8
    foryou2023  
       6h 3m ago   ❤️ 2
    拆分需求,把大任务拆分为小任务,然后小任务完成了,再 ai 复查,自己再亲自验收一下,完成了再进行下一个任务。

    不让 ai 一次完成所有的任务,这样肯定完成不了的。
    extrem
        9
    extrem  
       5h 46m ago
    “由于我从来没碰过这块业务”

    答案不是很清楚吗?什么 grillme 、skill ,总结这个总结那个,都不是根本原因啊,关键是自己要真的懂项目啊
    Yishanshan
        10
    Yishanshan  
       5h 3m ago
    TDD ?
    rccoder
        11
    rccoder  
       3h 22m ago
    如果是比较重要的老项目,大一点的需求,我基本上的流程就是:

    - 和 AI 一起理一下需求,结合需求文档和代码,列出需要实现的功能模块,以及一些模块边界(过程中我会提供一些我的想法)
    - 人 和 AI 一起 Review 上面要实现的功能,看是否有问题(人 Review 主体设计以及能立马想到的边界,AI 再查漏补缺)
    - AI 主些代码(我会逐步在代码中,写相关的 rules ,比如 XX 模块,应该遵循怎样怎样的规范。不是一开始就写的,发现有问题会补)
    - AI 先 Review 一轮
    - 人再去仔细 Review 代码,发现明显不合理的,会再让 AI 去改(人比较少参与写代码,但会告诉 AI 你应该如何如何改,觉得能沉淀经验的会放在前面的 rules) —— 基本一个大一点的需求,这一环节 review 产生的 commit 至少会上 10 个
    - AI 再去 Review 一轮
    - 人再看
    - 互相看几轮

    ---

    实话实说,在目前我遇到的严谨场景下,目前 AI 对大点的需求做不到一下子就能搞定。

    但帮我做非常大的查漏补缺,以及 AI 写代码确实快,因为他我会不吝啬重构代码,我提要求,他来完成。完成不了的,一般就是我要求提的不够好或者不够细

    ---

    在这样的情况下,AI 代码的贡献率,我基本在 94%,但人在过程中还是起来非常重要的 Review 角色
    thedog
        12
    thedog  
       3h 17m ago
    已经不 review 了。我的代码已经是 codex 的了
    ylsc633
        13
    ylsc633  
       2h 50m ago
    我是这么做的

    首先,项目的框架是我自己搭的,不是说语言的框架,是业务的框架,设计的时候,是拉着 AI 一起设计,但是具体怎么流转、领域之间关系 都是我自己定的,这一块,核心代码在哪,怎么写的,该怎么写 都是我自己定的,代码是 AI 写的,但是每一行我都看了

    然后根据这套业务框架,我定了一些 skill 和 rule ,后续不管业务怎么迭代,都必须先加载这些 skill 和 rule ,后续发展也确实很快,公司组织 OPT ,很多非我领域的人来写我这块代码,一周需求数量远远大于 5 ,代码行数完全看不过来

    包括我自己后来也是,写需求,一个需求代码可能超过 2w 行(还不是 JAVA 代码,是 golang 的,只是按照 DDD 设计的,非常啰嗦,要不是 AI 写,我自己写,不可能搞这么复杂的),完全看不过来,每次需要 CR 的时候,一个是让 AI 根据 SKILL 和 rule 显式加载,然后进行 review

    另外就是人工 review ,只 review 领域不要乱,现成的功能尽量复用,不要复写一套,所以要特别注意 新文件,至于业务逻辑,只能靠 研发自己自测 和 测试同学 黑盒测试了

    现在有个很明显的弊端,就是我自己已经不知道 系统已经有哪些业务能力了,很多东西是 AI 写的,或者别人利用 AI 写的,我自己都不太清晰了。
    wonderfulcxm
        14
    wonderfulcxm  
       2h 26m ago via iPhone
    拷问两小时……我直接让它滚
    ihainan
        15
    ihainan  
       2h 20m ago
    Claude Code 写,调用 Codex 做对抗式 Review 。现在纯 Vibe 项目人工审核已经比登天还难了,还是得魔法击败魔法。
    wangathena856
        16
    wangathena856  
       2h 2m ago
    我现在会把 review 前移成“可执行的验收清单”,而不是等代码全部生成后再读一大坨。每个小任务开工前先固定 4 样东西:允许修改的文件、不可变的接口、必须通过的测试、人工要看的关键路径。AI 完成后只看这个任务的 diff ,先跑测试和静态检查,再重点盯新增文件、重复实现、异常分支与删除操作。任务一完成就开新上下文,只保留短 spec 、决策和测试结果,不把整段讨论历史一直带着走。

    老模块还有个比较有效的办法:先让 AI 只读调查,画出调用链和数据流,人确认它理解无误后才允许修改。你这次的问题我感觉不只是“上下文失忆”,更像是业务模型和验收标准没有被压缩成可检查的约束; AGENTS.md 能管风格,但兜不住业务正确性。
    mingtdlb
        17
    mingtdlb  
       1h 0m ago
    黑盒编程是这样的,什么时候上下文到 B 级别,智力再上几个台阶,能从架构的角度考虑问题,估计就真实现 ai coding 了,也就没你啥事了
    yexiaoqi
        18
    yexiaoqi  
       52 mins ago
    如果是线上主要流程,最起码要自己过一遍,如果自己写是什么样子,然后 AI 写完代码还是要自己过一遍的。

    还是要自己不断总结适合自己的 Skills 或者 Harness
    gpt5
        19
    gpt5  
       48 mins ago
    小红挺神的,有很多正常人类无法想象但是存在市场的黄牛/代理行为。
    cccn
        20
    cccn  
       44 mins ago
    ai 自己 review ,我只给他目标即可。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   2795 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 50ms · UTC 14:30 · PVG 22:30 · LAX 07:30 · JFK 10:30
    ♥ Do have faith in what you're doing.