推荐语

AI Coding工具的实际表现与预期差距有多大？本文揭示高强度使用中的真实体验与关键发现。

核心内容：
1. AI Coding在数据治理与功能开发中的实际表现分析
2. 高强度AI Review流程中暴露的模型能力局限
3. 开发者对AI代码质量评价分歧的深层原因探讨

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

春节假期中，大量使用了AI Coding工具做一些新的事情，但体感实际上跟很多人以及我过去的预期并不匹配。特别是最近几天开始把高强度的AI review进入到开发流程中，发现了一些之前完全没有注意到的事情。

感觉似乎更进一步的理解了为什么现在开发者对于AI Coding代码质量的不同观点流派。

所以本文就来谈一谈我的发现，以及我目前在AI Review上的一些实践经验。

1、这几天的实践

在过去10天之内，主要做了两件事：

• 数据库上的数据治理，并且有可供对照的原始材料，主要使用Claude Code完成。

• 一个自用的数据CRUD类软件的3批新功能开发，也是主要使用Claude Code完成。

10天中花费了1550刀的Claude Code等效额度（使用ccusage统计），此外还花费了不少Codex CLI的额度，和大约80刀的Cursor额度。这些都以原价LLM API调用计算。我使用的都是原厂服务。

1.1、数据治理

从实践来说，使用AI Agent来做数据治理是不错的，大概算得上是最佳实践。我使用Claude Code + Opus 4.6，应该算得上最强一档。

但实际使用并不能放心，虽然说Opus 4.6不至于随便删库，但不能完全遵守指令，过短的Context 能力（200k）都导致过程体验较差。由于我很在乎这个数据的最终质量，所以我不得不高强度盯着它，每轮修改都要review修改计划再实施，并在过程中对它进行纠偏以及同步我对于一些情况的处理意见。这个高强度盯着的方式已经好久没有了，感觉跟我2025年5-8月的时候类似了。

在我最近的高强度Claude Code使用下，又重新让我开始怀疑Claude Code是否会有一些间歇性降智的问题，例如在北京时间晚上21点之后。有些情况犯的错误就很离谱，感觉就像是一些智力较低的模型。而且感觉跟 context 压缩过程有较大相关性，不过现在不仅是context压缩了，Claude Code也增加了Memory功能。

数据治理工作做了几天，感觉这个过程让我下调了我对目前前沿AI Coding Agent能力的判断。

1.2、功能开发

这个过程中在一个项目上做了三波较大的开发。项目整体规模是4w行Python+3w行Next.js。每波新功能的设计都是跟AI讨论2-4小时，然后再交付开发。

前两波没有什么特别的，Cursor自带有一个Review Agent。从第三波开始在完成之后使用额外的Claude Code和Codex进行Review。与预想偏离的地方就从这第三波开发的Review开始了。

在这之前已经有了一些心理准备：

• 一个是Claude Code在数据治理中的不算很好的表现

• 另外是中间做了一些当前项目的AI review，虽然发现了一些冗余和死代码，但总体感觉还算正常。

第三波修改中，第一个是一次大重构，并新增了一些功能。我最近给AI的目标都是不要做最小化重构，而要做干净且合理的设计，所以这次修改牵扯面较多。最终是5k行新增+5k行删除的量级。

但进入Review环节之后就发现陷入了泥潭。每轮review使用Cursor Review Agent、Claude Code、Codex三方独立review，然后交由Claude Code在接续开发的context中进行修复。整个过程进行了十几轮，累计耗时9h，而且每轮都能发现一些明显的问题。

在这个过程中：

• Codex发现问题的能力令人深刻，但速度也较慢。

• Claude Code的review能力也不错，速度适中。

• Cursor Review Agent的结果大概算是比聊胜于无强一点，但不多，而且误报率也偏高。

但不管怎么样，目前AI Review的过程都有一些明显的缺点：

• 每轮review不能召回大部分问题，即使Claude Code和Codex拆分了子Agent来去做分区调研了也是如此。这也是为什么最终整个Review过程长达9h的原因。即使三家一起上，每轮review能发现一些问题，但有限。

• review过程较慢，一轮review没比开发短多少时间，尤其是对于Codex来说。

• AI Review过程极耗token，Codex的额度之前似乎很难用完，但在这9h review中，我把ChatGPT Plus的Codex周额度使用了50%，这是我之前无法想象的。

还没有完的是，在我通过AI review消除掉了所有可见问题之后，发现该次功能的设计上还有bug，又不得不进行了功能调整。

在这之后又进行了2个小一点需求的修改，大约每次diff量1k行水平，但看起来每次开发仍然需要配合3轮左右的review才算完善。

2、我的评论

首先目前的AI Coding Agent做不到很细心，在代码开发中其实是有表现的，只是即使你比较多的与Agent交互也不一定能发现。但是当你在一个稍大的项目中开发，并认真地找其他Agent来做review时候，你会发现这些不够完善的地方。体感是，即使是目前最强的Coding Agent，第一轮直出的代码大概我也只能评分为60-70分。

这个不细心的问题在我前面的数据治理中表现得很明显，以至于让我怀疑这是否是真的Opus 4.6。

所以目前实际AI Coding的开发质量是：单次功能基本可用，但还不太完善。所以这大概能解释之前两方观点的冲突：

• 对于大量使用Coding Agent开发的人来说，无论是否做详细的方案review，大部分其实都很难注意到实际代码中的一些不完善的地方。但感觉上代码似乎还是不错的。

• 但如果你以你期待的标准来审核这些代码的时候，你会发现它们的质量并不算高。如果你在乎这些代码的可靠性或者你希望长期维护这些代码，你会希望它们能的质量能再改善一下。有些开发者看到了这点，所以他们现在对于Coding Agent的质量评价仍然不算很高。

目前来看，如果你在做一个你在乎代码逻辑质量的项目、或者是你希望长期维护的项目，那么在每次开发之后，使用独立的Review Agent进行多轮review直到看起来把大部分问题都发现和修复是必要的。但这算不算目前的最佳实践我不清楚，因为这显著拉长了整个的开发时间、并显著增加了token消耗量。

目前Review Agent的推荐是：Claude Code + Opus 4.6 与 Codex 并用。Cursor的Review Agent价值很有限，不要指望它。

当然会有人推崇测试驱动的开发，当然对于一些重要或长期重要的项目来说，这是不错的方式，如果你和AI能做到较高的测试覆盖率的话。但我做的很多项目都不行，因为情况太多，所以我目前更倾向于进行review。不过目前也确实没有认真的去实践AI+TDD，也不排除我是误判。

以及说，传统的软件开发经验还没有那么快过时，确实不要把一次变更搞得太大，如果你不想也遇到需要review 9h的情况。

3、对Coding Agent的现状和发展有合理的预期

我这个项目也只有7w行代码，并且还是前后端加在一起。在这个项目上，复杂重构和开发的状态尚且如此，对于更复杂的任务，例如迁移历史遗留的大型代码库要保持谨慎。

我不知道Coding Agent在完善性上的提升速度和目标如何，至少目前我没有看到哪家的目标是重点在这方面的。大家的目标更多是以60分的质量完成更大的任务，而不是以更高的质量完成任务。

4、对于模型层的启示

我在1-2个月前，还在跟模型层的人讲目前的Coding Reward并没有包含代码复杂度、可维护性这样的长期reward。但现在我需要进一步下修这个判断。目前的Coding Agent在代码的一些完善性方面、长尾问题的处理上等还有不少问题，很明显它们的训练过程并没有包含这类目标。

但也有好消息，从我的体验来说，Dev Agent和Review Agent的多轮交互整体似乎可以作为一个更好的reward和数据生成方式。经过我这样手工跑多轮review和修复之后，我对于结果代码的质量和可靠性的信心都提升了。AI review确实能召回一些长尾情况的问题，只是需要抽卡。

Dev Agent和Review Agent都会犯错，所以一般是Review Agent找出候选问题，Dev Agent结合需求context和开发历史进行检验和筛选。当然这里从实际数据合成来说还有不少细节问题，但这就超出本文讨论范围了。

如果正在训练的Dev Agent的能力不够强，可能在这种交互中还会有误判，可能还需要其他更强的模型进行仲裁。