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

AI 写代码的速度已经超过你的阅读速度,你会放心把 Code Review 也交给 AI 吗?

  •  
  •   sunxfancy · 3 days ago · 5588 views
    最近用 AI 开发一个 AI native 的开源游戏引擎 EVEngine ,遇到了一个挺尴尬的问题:

    AI 写代码的速度,已经超过了我阅读代码的速度。

    以前开发一个功能,可能需要花几天时间,天天都盼着有人能帮我写,发个 pr 给我。

    现在反过来了。

    我同时使用 Codex 、Cursor 、DeepSeek 等工具开发,几个 Agent 并行工作,一天下来就可能产生大量代码和 PR 。

    代码写得越来越快,但审查代码简直累死个人。

    尤其是游戏引擎这种项目,涉及底层架构、并发、内存管理、渲染等模块。很多问题不是看一眼 Diff 就能发现的。

    于是我开始尝试另一种方式:

    让 AI 写代码,再让其他 AI 来 Review 。

    目前我在 EVEngine 项目中尝试通过 Qodo AI Review 和 CI 的一些约束判断来辅助审查 PR 。

    这里有一个真实的 PR ,大家可以直接看看:

    https://github.com/EVEngine/EVEngine/pull/443

    AI 给出了 3 个 bug ,然后我的 agent ,还一一回复并修复了这三个 bug ,并重新提交。

    但越是这样做,我越觉得有一个问题绕不过去:

    如果我不放心 AI 写的代码,凭什么放心另一个 AI 审查的结果?

    两个 AI 都认为代码没问题,真的就意味着没问题吗?

    如果最终还是需要我把几千行代码全部读一遍,那么 AI 带来的开发速度提升,会不会被 Code Review 吃掉很大一部分?

    我现在逐渐倾向于另一种思路:

    未来程序员的工作,可能不再是逐行检查每一处实现,而是更多地审查架构、需求、测试覆盖以及最终行为。

    但这也意味着,我们必须找到一种比“AI 说没问题”更可靠的验证方式。

    不知道大家现在是怎么处理 AI 生成的大量代码的?

    你们会放心让 AI Review AI 吗?

    如果 AI Review 通过、CI 通过,你会直接 Merge 吗?还是一定要自己看完所有代码?

    ----------------------------------

    最后,顺手给我的项目打个广告,EVEngine ( https://github.com/EVEngine/EVEngine )是从头设计的类 love2d 风格的 2d 、3d 混合渲染的开源游戏引擎,简单容易上手的同时,又提供各种高级光源阴影光追效果、程序化地形生成、各种 RTS 、RPG 、CardGame 等高层级玩法模块,还提供了大量的 mcp 服务功能帮助 AI 调试、理解代码行为。

    SSUI ( https://github.com/sunxfancy/SSUI )是我去年设计的一款开源的替代 ComfyUI 的 AI 生图、生视频、生 3D 、生动作的 AI 模型调用工具,基本功能实现了,但 bug 还比较多,最近在努力添加 AMD 显卡的支持。这两个项目连起来就是一整套 AI 辅助游戏开发的工具。

    喜欢的朋友请 star 一下多多支持。
    62 replies  •  2026-10-20 00:55:35 +08:00
    mzotw2babm
        1
    mzotw2babm  
       3 days ago
    这也是我目前的痛点:如何保证 AI 生成的代码完美符合最初的需求。我现在还没有答案,如果你有答案了,记得抠抠我= =
    ffalex
        2
    ffalex  
       3 days ago via Android
    我不放心又能怎么办,现在是 cluade 派发任务,sol 做任务,然后 claude 再审
    midsolo
        3
    midsolo  
       3 days ago   ❤️ 1
    我司用的 openspec ,搞了套 "筛选 + 打分" 的混合质检机制,AI 把需要质检的需求筛选出来并进行打分,分数低质量差的人工质检,剩下的全部 AI 质检。
    xidaduo
        4
    xidaduo  
       3 days ago
    为啥不放心? AI 能力比我强多了
    voidemoer
        5
    voidemoer  
       3 days ago
    只能说服自己相信 AI ,等再过一两年,就可以真心实意的完全相信 AI 了。
    zerovoid
        6
    zerovoid  
       2 days ago
    人写的代码也有 bug 啊,这不是很正常。
    不存在完全没问题的系统。

    只能把测试用例写细一点,减少 bug 。
    JinShu
        7
    JinShu  
       2 days ago
    反过来思考,你在用别人做的软件,你也看不到源码,你不也一样放心用?
    pnczk2019
        8
    pnczk2019  
       2 days ago
    如何让几个 AI 分工?有什么 SKILL 还是什么分享吗.
    doug
        9
    doug  
       2 days ago via iPhone
    不会 我现在连 ai 帮我加代码都怕 它给出的建议我会逐一过目 然后自己添加 添加完后叫它帮我看看还有没有其它问题 然后自己运行看结果
    churchmice
        10
    churchmice  
       2 days ago
    @JinShu #7 这是一码事情吗
    cs3230524
        11
    cs3230524  
       2 days ago
    现在是你配合 AI 工作
    iamnotarobot0
        12
    iamnotarobot0  
       2 days ago
    我在写方案的时候就会让 ai 把验收标准写好,方案也会走不同的模型 review 。 最后代码写完也走不同的模型来 review ,现在感觉基本 OK ,没有发生过什么大问题。

    当然一般都还是会自己看一下的, 不然确实有点不放心。
    cvooc
        13
    cvooc  
       2 days ago via Android
    多切几个 ai 开全新会话反复审查,绝大多数都能审出来,就是钱包感人。不过稳定后只需要审最近提交的改动,就好很多了。
    qiaobeier
        14
    qiaobeier  
       2 days ago
    不给不行啊
    yuanmomo9090
        15
    yuanmomo9090  
       2 days ago via iPhone   ❤️ 2
    这个也是我的痛点。我现在使用 AI 的方式感觉很原始。先聊天,聊一个 plan ,包含了所有的实现细节,甚至改动哪个文件,具体的改动是什么样子的,也要包含测试用例,然后再让 AI 实现,即便这样,AI 依然会漏掉一些逻辑没实现。然后我人工一个个看,然后一步步 review ,再用另一个 AI 交叉 review ,然后一直到两个 AI 都 OK ,真的是很浪费时间和精力。

    好处就是有同事用 AI 写了大几千行代码,完全是 AI 写的,完全没有人工介入的 PR ,我能用几百行,更好的设计方案把整个重写了,实现更好。

    昨天应该这个跟同事吵起来了,下周一又是聊天的一天。
    sunxfancy
        16
    sunxfancy  
    OP
       2 days ago
    @iamnotarobot0 这个确实是个办法,但有时候期望是什么样子的结果又很难描述准确,我就见过 AI 上来列了一大堆验收标准,结果自己死活也做不到
    Maxwe11
        17
    Maxwe11  
       2 days ago
    阿里出了个工具 alibaba code review 还不错,内置了很多规则,也可以自己补充完善,在产品设计和技术实施两个部分都用强力高智模型写,实施可以用量大便宜的按照规划实施,除去 harness 里工程的自审外,再搭配 ocr(搭配高智的其他模型)做交叉审,基本上比一个普通码农靠谱儿多了。
    GeminiPro
        18
    GeminiPro  
       2 days ago
    如果是为自己服务,当然不放心交给 AI ,但现在,整个世界都处于一种既不理性的狂热状态,老板都不在质量问题,那还说啥,直接蹬就完事了。
    broadliyn
        19
    broadliyn  
       2 days ago   ❤️ 1
    https://claude.dev/blog/solving-code-review-at-anthropic/
    刚好昨天 claude 官方就分享了他们的 code review 访谈。

    基本就是人负责定义验收标准,code 已经 review 不完了,那就索性不 review 了。
    出问题了怎么办?把精力放到如何快速恢复回滚上面。

    可能 ai 时代,的确要换种思维去面对传统软件工程。
    xyooyx
        20
    xyooyx  
       2 days ago
    各类语言百花齐放的时代,你会 review 机器码吗?
    yinanc
        21
    yinanc  
       2 days ago
    这是 10 个月前的帖子吗?
    moudy
        22
    moudy  
       2 days ago
    @broadliyn web 容器可以轻松回滚,已经装到飞机汽车电站里的程序也没事回滚么?
    mogita
        23
    mogita  
       2 days ago
    @yinanc +1

    用 Agent 写码、Agent review 的流程已经快一年了,人只负责打方向
    XProxyAi
        24
    XProxyAi  
       2 days ago
    这个时代最有价值的是测试用例,只要测试用例过了,就行,别的不用管,没 AI 的时候,也是这么过来的
    Hylasca
        25
    Hylasca  
       2 days ago
    我感觉问题不在于 AI 写代码或者 AI review 代码,不安全感来自于 AI 的实现方法你心里没有底。现在我更关心的是 AI 去实现的代码流程是如何的,尽量多让它画图去搞懂它要实现的流程,相互的依赖和复杂度,一旦你觉得完全理解了,那最后代码 review 你不用太纠结具体它怎么实现某个具体 func ,也不用每一行都仔细阅读,你只用关心它是否按照你理解的流程和方法去实现的。当然了基本的 guardrill 肯定要有,比如严格的 lint rule, 尽量高的测试覆盖。最后,如果我还是觉得在代码 review 上面花的时间多了,我会定期和 AI 讨论过去 1 一个月我 PR review 的时间到底花在什么事情上,是否能通过写一些 AI skills 针对性的减少 review 的时间。
    hikarugo
        26
    hikarugo  
       2 days ago
    没意义的兄弟,如果 AI 都找不出来的问题,你极大概率也找不出来,或者需要顶级程序员花百倍的时间,现在纠结这些根本没意义了,把 AI 当黑盒,写好自动化测试即可(也可以让 AI 做哦)

    技术细节根本不重要了,站在产品角度思考问题,我管你这那的算法优化多牛逼呢,我只看体验符不符合要求
    customer
        27
    customer  
       2 days ago via iPhone
    超过阅读速度证明推理级别选太低了,那个出来都是垃圾代码
    sampeng
        28
    sampeng  
       2 days ago via iPhone   ❤️ 1
    ai review 我一直在用,但用多了警醒过来了。代码本身不追求完美,而是合适。完美要看在哪个角度看。ai review 没有这个概念,最终结果就是代码一堆补丁。最简单的例子,并发竞争问题。你自己写的代码知道这玩意是线性的,不可能存在这个场景。结果…ai 觉得那不行,不加锁会死。然后是一大堆加锁的垃圾代码在你代码库里了…
    sampeng
        29
    sampeng  
       2 days ago via iPhone
    其实更准确的说,我不光不主张 ai 无脑 review ,我只让他 review 我关心的点,超过的不允许报告给我。另一方面,我单元测试都不让 ai 写。写多了我发现都是虚假的安全感。不如不写,有需要的我自己写 case 再实现。
    sunxfancy
        30
    sunxfancy  
    OP
       2 days ago
    @hikarugo O(∩_∩)O 哈哈~,说的好像也很有道理
    8bit
        31
    8bit  
       2 days ago
    我感觉用外包和 AI 的思路很相似
    bowencool
        32
    bowencool  
       2 days ago
    不然呢?你不放心就自己看呗,谁拦着你了吗
    liuzigenghhh
        33
    liuzigenghhh  
       2 days ago
    我觉得最好的方案是 懂得他的 实现逻辑, 但不需要逐行看代码, 做完整链路的 单元测试、集成测试、端到端测试, 至于 如何实现的, 完全放权
    catazshadow
        34
    catazshadow  
       2 days ago
    说出不需要 review 的那一刻,AI 编程就已经跟正经的工程实践没关系了
    broadliyn
        35
    broadliyn  
       2 days ago
    @moudy
    这里只是提供一个业务场景的思路,至于适不适合自己业务,自己不会判断吗?
    uni
        36
    uni  
       2 days ago
    “未来程序员的工作,可能不再是逐行检查每一处实现,而是更多地审查架构、需求、测试覆盖以及最终行为。”

    anthropic 的工程博客好像也是这么写的

    但是我个人有更细化的做法,就是在 AGENTS.md 里面限制代码的行为:
    Optimize for local static reasoning: keep control flow, state transitions, effects, and call targets inferable from nearby code.
    Use explicit, concrete data structures and types that encode exactly the valid states and alternatives; handle alternatives with explicit case analysis.
    Use polymorphism only for genuine parametric genericity; do not use inheritance or runtime dispatch.
    Avoid explicit loops unless explicitly allowed; use idiomatic functional combinators such as map, filter, fold, and language-specific equivalents.
    Except where required by third-party APIs, mutable state may exist only as state threaded through fold.
    Keep a stable name stem for a value while it should be mentally tracked as the same thing; carry it across local bindings and function boundaries rather than renaming it for how it is produced, stored, moved, or accessed. Change the name only when a new distinction must itself be tracked thereafter.

    有了这些限制之后,阅读代码的速度将会得到提升。

    最后的最后,你会发现,上面这个工作最终的导向,我认为还是 effect system 赶紧实装。
    jko123
        37
    jko123  
       2 days ago
    ai 写代码、ai 审核已经是常态了,人类要做好的就是描述清楚需求,如果连需求都不描述清楚,那就真写不出可靠的系统
    413420
        38
    413420  
       2 days ago
    完美是不可能的,有问题后面修就是了
    limhiaoing
        39
    limhiaoing  
       2 days ago
    不放心也没办法呀,review 不过来呀!
    WayneShao
        40
    WayneShao  
       2 days ago via Android
    现在已经变成了
    “这代码居然是人写的,风险也太高了,打回去让 AI 重写”
    Jack66
        41
    Jack66  
       2 days ago
    体会人盯肉盾吧,如果一天同时开 3-5 任务,精力榨干。能吸收理解多少
    winglight
        42
    winglight  
       2 days ago
    这。。。谁 review 代码谁就是傻瓜。。。。如果不放心,请用最强的 AI
    kneo
        43
    kneo  
       2 days ago
    看标题我就知道你是来推广的。
    BlackSas
        44
    BlackSas  
       2 days ago
    我最近在用 grok bot 工程师的 pstack 插件。只要验证过一次,就可以相信它。
    icyalala
        45
    icyalala  
       1 day ago
    说难听点,你搞得这种小型游戏引擎已经无人在意了
    要不然有需求时我直接拿 AI 搓一个自定义的满足个性化需求,要不然就用 AI 已经训练过的成熟引擎
    shmilypeter
        46
    shmilypeter  
       1 day ago
    如果 AI 写代码的速度远远超过看代码的速度,那么肯定来不及人眼 review 的
    penisulaS
        47
    penisulaS  
       1 day ago
    刚看到这样一篇文章 https://www.aymannadeem.com/artificial/intelligence,/developer/tools/2026/09/24/plan-mode-is-dead.html

    我的想法是:除非出现类似脑机接口的机制,理解所需要的时间是不可压缩的,这意味着在极其有限的时间,你无法理解 ai 所写的大量东西。同时语言也无法精确的表达事物,这意味着你很难通过语言把你心目中的东西完美传递给 ai 。
    Lukedis
        48
    Lukedis  
       1 day ago
    我让 DeepSeek 做了一次全量代码审查,用了 15 ,后端用 9 块多,前端用了 5 块多
    Zeos3154
        49
    Zeos3154  
       1 day ago
    说一下我自己的情况,我现在有在 GitHub 上接 CodeX Connector ,每次代码一推 PR 就自动审。但是我会遇到一个很让我很难受的问题,就是第一轮推送,然后它给我找出几个 bug ,然后让 Agent 修了,修完以后再推送,又有新的 bug ,就反反复复的,就让我很难受,就感觉一直没有收敛吧,所以后来我就要求只改和当前 PR 有关的内容,和当前 PR 没关系的,那你就该提个 issue 就提 issue ,后面再改
    Lighfer
        50
    Lighfer  
       1 day ago
    我比较简单粗暴,重复让 AI 审查修复,绝大多数问题基本都能发现解决,剩下的都是不影响功能、性能的小问题了,AI 发现问题要列表,人工确认哪些需要修复哪些不需要,以及修复方案是否合理,不然完全 AI 自由发挥的结果就是过度防御变成和过度设计。
    这种方式持续了快一年了,目前没出过问题,就是特别耗时耗 token...
    aweim
        51
    aweim  
       1 day ago
    周五刚搞了一个生产 bug ,把我一个不相干的重要 API 删了。review 不出来。
    HENQIGUAI
        52
    HENQIGUAI  
       1 day ago
    用人不疑疑人不用
    ugpu
        53
    ugpu  
       1 day ago
    还在觉得 ai 不可靠 ai 的代码不行 自认为不符合预期的那群人
    《辞职去学习什么叫虚心》 《如何使用 AI 》《问问自己你一个 臭干技术的 搞了这么多年搞出什么了不起的技术项目来了?》
    ugpu
        54
    ugpu  
       1 day ago
    @aweim 这是不会用 ai 怎么会 review 不出来? git 记录不能读取?不能生成上一次 生产部署 hash 对比当前发版 hash 之间的改动 报告?
    layxy
        55
    layxy  
       1 day ago
    审不过来了,而且有时候也懒得审了,程序员有个坏毛病就是不喜欢读别人写的代码,AI 写的也是一样的问题
    6581
        56
    6581  
       1 day ago
    @midsolo 这个我觉的比较靠谱,以后做需求就相当于是做产品是一样的,通过流程质检来控制代码质量。
    lfsc
        57
    lfsc  
       1 day ago
    程序员思维,那老板为什么就放心程序员写的代码呢,他会一处一处审核吗?
    sunxfancy
        58
    sunxfancy  
    OP
       1 day ago
    @ugpu 我去,太狠了;)
    ugpu
        59
    ugpu  
       1 day ago
    @sunxfancy 使用 ai 的思维就应该是 所有的问题都抛给他 他来解决 他来决策 而人就应该只盯着屏幕 看生成的报告 给出的提示 最后的总结; 然后核对清单列表.
    ai 现在依然被定义为高超技艺的执行者 决策者那种模型似乎民用的还差一点
    chaoooooos
        60
    chaoooooos  
       1 day ago
    @Lighfer 我也是差不多这样
    mushokumunou
        61
    mushokumunou  
       17h 58m ago
    pstack 可以試試,生成自己習慣的 xx-mode ,然後讓他合并 pr 就行了。
    mushokumunou
        62
    mushokumunou  
       17h 50m ago
    @icyalala 對,所以現在已經迷茫了,要自己寫個需求?還是 rea 逆向一個已經成熟的應用?
    我是選擇後者,ai 都這樣瘋狂了,會動腦子的人太多了,還不如讓那些動腦子的人先寫個原型的,好玩就逆向他。
    把更多的精力用於市場,推廣反而更重要,反正大部分應用,ai 參與的,作者本人也未必能全看懂。大家都一樣。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   3462 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 128ms · UTC 10:46 · PVG 18:46 · LAX 03:46 · JFK 06:46
    ♥ Do have faith in what you're doing.