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

Agent 开发时代,你们还在做 Code Rview 吗?

  •  
  •   mixuxin · 17h 15m ago · 2463 views

    大家目前都是 codex 、claude code 等 Agent 逻辑一把梭,现在大家内部还有 Code review 吗?

    大家的团队都是如何保证工程质量的?

    23 replies    2026-08-26 15:20:52 +08:00
    Need4more
        1
    Need4more  
       17h 8m ago
    找 agent 来 review ,完全拥抱 ai
    L4Linux
        2
    L4Linux  
       17h 2m ago via Android   ❤️ 1
    能一把梭,靠 agent review ,说明代码逻辑简单,只是体力活。
    mixuxin
        3
    mixuxin  
    OP
       16h 59m ago
    @L4Linux 感觉有道理。像一些规模比较大、运行周期比较长、稳定性要求比较高的项目,确实不太敢直接“一把梭”,也不太敢完全依赖 Agent Review 、例如淘宝 、抖音这些 ~
    1258
        4
    1258  
       16h 51m ago via Android
    靠测试覆盖。涉及 UI 就靠真人体验
    ClericPy
        5
    ClericPy  
       16h 29m ago   ❤️ 3
    spec 驱动,文档→测试→开发→验收 循环

    文档是唯一标准

    整天被催进度变需求,哪有那么多时间 review ,不过差的模型真的老自作主张,Harness 多了遇到矛盾的约束就打架乱搞,每次都靠好模型验收找补回来
    Kylin30
        6
    Kylin30  
       13h 59m ago
    图灵面对恩格玛时已经给出答案
    mogita
        7
    mogita  
       13h 1m ago
    订阅了 codex pro 专门用来自动 review PR 。
    GeruzoniAnsasu
        8
    GeruzoniAnsasu  
       11h 46m ago   ❤️ 1
    直接引用: https://www.v2ex.com/t/1236043#reply36

    review 应该是一个工程质量环节,不是完成代码实现的步骤。review 的目的是确保我跟 LLM 能双向理解彼此追求的细节,正如设计师会来盯你的前端到底有没有精确到那 1px 一样。
    383394544
        9
    383394544  
    PRO
       9h 46m ago
    review 还是要的,只是不看 code 了。我每次开完 PR 都会让 claude 请 codex 审一遍。完成一个架构的时候让 agent 写技术文档给我看(我有另一个 repo 专门放项目文档,还建了文档站),确保我了解这次实现的原理。如果之后要改也是先让 agent 分析,然后我跟他讨论改进方案。

    要把 agent 当员工,不是当许愿机。
    gibber
        10
    gibber  
       9h 36m ago
    @ClericPy 那要有很强的架构能力吧,能提前把所有问题都事无巨细的考虑周全写进文档
    Sezxy
        11
    Sezxy  
       6h 55m ago
    review, 避免 AI 降智或者跑偏。 另外 AI 写的代码有时候很啰嗦,只考虑实现需求,不会考虑性能问题
    wombat
        12
    wombat  
       6h 39m ago
    公司的项目,必然 review ;个人玩具、无所谓。公司的项目长期运营,定制化会很多,当前的模型有时候处理不了那么多的业务分支。

    公司有个项目跑在 k8s ,关联很多系统和客户,业务分支很多。 有次需求写的很详细的 spec 文档,包括需求+Task+验收标准。 用 5.6Sol+Opus5+Grok4.5 ,反复审计 review ,都没发现一个严重的 bug (业务分支太多,某分支处理逻辑,AI 产生的是错的)。 现在的模型普遍存在的问题就是,上下文过长压缩后信息丢失,或者在上下文多重点情况下不知道哪些是重点。
    ReinXD
        13
    ReinXD  
       6h 36m ago
    ai 写,ai review
    wombat
        14
    wombat  
       6h 34m ago
    @wombat 我们另一个团队是 AI 写 AI review ,全靠 AI 。 看过他们的代码,写的越多,架构方面问题越多。 哈哈哈哈哈。但能跑,有些隐藏的 bug 。
    jesseZhang
        15
    jesseZhang  
       6h 26m ago
    我是属于个人开发者,然后我是非科班出身的,所以我选择每次部署到生产都 code review 一下。
    但主要就是混个眼熟,因为我觉得我也看不太懂细节。
    不过在这个过程中,我对写代码理解的更深了,一些大概的写法,函数啊,封装啊,调用啊啥的,然后对 git 的使用理解也更深了,分支管理合并的时候,到底 git 工程是做了什么,红色的绿色的改动,每一次改修小不迭代的好处。
    这是我尝试 code review 的原因,我感觉对一个非程序员来说,可以获得对代码有新的理解,从而更加建立写代码的自信。
    当然产品上线了,还是要回归一下的,该测试还是测试 ui ,让 ai 给测试 case 。
    maocat
        16
    maocat  
       6h 22m ago
    @ClericPy 这点我是赞同的,理想的 spec, 就算哪天代码丢了,切换开发语言,架构,通过 spec 直接快速生成一套新系统,但是,没有这么完美的东西
    rrZ2C
        17
    rrZ2C  
       6h 18m ago
    个人项目已经看不过来了
    公司项目还是会认真 review ,因为只负责其中 2 个模块而且很多依赖纯内部
    raolight
        18
    raolight  
       6h 3m ago
    疑人不用,用人不疑
    default996
        19
    default996  
       5h 47m ago
    ai 动不动就查询全部记录,修改删除其中 1 条记录它也要全部重新查出来。
    功能实现,测试全都通过,翻看其中的代码才知道,到处都是拼接的 SQL ……
    iugo
        20
    iugo  
       5h 32m ago
    AI review + 人工 review.

    AI 目前会有一些不符合架构要求的问题, 但这些细化的要求暂时没有被写入 AI review 的 prompt 中 (其实在更抽象的文档中, 但是 AI 能力不行, 不能将这部分抽象要求应用在项目内). 这时候只能人来发现.
    Tayshin
        21
    Tayshin  
       5h 17m ago
    已经放弃 review ,尝试用约束和测试来把关。
    不看代码无非是因为
    1. 没那么多时间
    2. 无人在意项目的质量与漏洞,大家只会盯着交付吞吐
    2. 无法仅通过阅读看出所有问题,至于简单的错误 AI 也能识别

    现在坚持人工 review 都只是因为没有足够的质量保证手段,只好沿用过去的老方法,惯性使然罢了。

    自动化的识别 AI 的逻辑漏洞,完成一系列测试才是根本需求。
    linkopeneyes
        22
    linkopeneyes  
       4h 55m ago
    公司的不 review,自己的小项目不让 ai 写进去,而是输出给我,我自己一点一点看过去再复制进去
    unco020511
        23
    unco020511  
       1h 34m ago
    提交前我还是会让 AI 整体 review 一下
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   5433 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 58ms · UTC 08:55 · PVG 16:55 · LAX 01:55 · JFK 04:55
    ♥ Do have faith in what you're doing.