AI写了80%的代码之后，开发者到底在干什么？聊聊从写代码到审代码的真实感受

上周有个朋友问我："你现在每天还写代码吗？"

我想了想，说："写。但写的量大概是以前的五分之一，剩下时间全在 review。"

他一脸懵："review AI写的代码？那不是比自己写还累？"

我说："你终于问到点子上了。"

这篇文章不是来吹AI编程有多牛的，也不是来贩卖焦虑说"程序员要失业了"。我想聊聊一个更实际的问题：当AI开始帮你写大部分代码的时候，你的角色到底变成了什么？每天的工作内容发生了哪些变化？哪些能力变得比以前更重要了？

这些东西，在网上很少有人系统地聊过。

一个典型的工作日

先说说我现在的日常。

早上打开电脑，第一件事不是打开IDE开始写代码，而是打开Claude Code，告诉它今天要做什么。比如："给用户列表页加一个筛选功能，支持按注册时间和活跃状态过滤。"

然后Claude Code开始干活。它会先看项目结构，找到相关的文件，写代码，跑测试。我在这个过程中干嘛呢？喝咖啡，看它的输出。

等它搞完了，我的活才真正开始：review。

逐行看它写的组件、API路由、数据库查询。看看有没有逻辑漏洞，有没有安全隐患，命名是否符合项目规范，测试覆盖够不够。发现问题就指出来，让它改。改完再看。

一个功能下来，可能要经历三四轮这样的交互。最终提交的代码里，确实大部分是AI写的，但每一个决定都是我做的。

下午可能还有两三个类似的任务。一天下来，我"亲手"写的代码可能不超过50行，但我review过的代码可能有500行。

这就是2026年一个全栈开发者的真实工作状态。

有人可能会说："那你不是变轻松了吗？不用自己写代码了。"

没那么简单。我来算一笔账：

以前自己写一个功能，大概3小时。现在让AI写+我review，大概2小时。看起来省了1小时对吧？但review的那1.5小时，精神消耗远大于自己写的3小时。写代码的时候你可以进入心流状态，脑子是放松的。review的时候你一直在做判断——这段对不对？那里有没有漏洞？这个方案是不是最优的？脑子一直在高速运转。

所以实际感受是：工作时间变短了，但疲劳感变强了。

而且还有个问题：AI不是每次都能一次做对。有时候它理解错了需求，你review完发现方向都错了，得推倒重来。这种"返工"的成本往往被忽略了。

上周有个任务，AI前两次的方案我都不满意，第三次才勉强可用。算下来花了3小时，和我自己写差不多。但中间的沟通成本和review精力，其实比自己写还高。

从"写"到"审"，到底变了什么

表面上看，只是工作内容从"打字"变成了"看屏幕"。但实际变化远不止于此。

决策重心前移了。

以前写代码，决策是分散在编码过程中的。你边写边想，边想边调。设计和实现是交织在一起的。

现在不一样。你必须在AI开始干活之前就想清楚：这个功能的边界是什么？用什么方案？有哪些约束？如果这些没定义清楚，AI就会自己做一堆假设，写出来的代码可能南辕北辙。

我现在花在"想清楚要做什么"上的时间，比以前多了至少一倍。

代码审美变得重要了。

什么叫代码审美？就是你能不能一眼看出一段代码"不对劲"。不是语法错误那种明显的问题，而是"这个实现方式虽然能跑，但不是我们应该用的方式"。

举个例子。AI给我写了一个用 setTimeout 来做轮询的方案。功能上没问题，但我知道这个项目里所有类似场景都是用 WebSocket 的。如果我没发现这个问题，就会引入一个不一致的模式，后续维护的人会很困惑。

这种能力以前也重要，但现在变得极其重要。因为你不是在review同事的代码（同事知道项目约定），你是在review一个"聪明但不完全了解上下文"的AI写的代码。

调试能力比以前更值钱了。

AI写的代码，如果出bug，往往不是那种低级错误（拼写错误、少了个分号），而是逻辑层面的问题。比如：边界条件没考虑到、并发场景没处理、对业务规则的理解有偏差。

这种bug比自己写的bug更难调试，因为你没有"写这段代码时的思维过程"。你必须纯粹从代码本身去推理它在干什么、为什么出错。

我现在调试AI代码的时间，大概占总工作时间的30%。这个比例比以前高不少。

Review AI代码和Review人写的代码，不是一回事

很多人觉得代码审查嘛，都一样。但实际操作下来，review AI写的代码和review同事写的代码，差别很大。

AI代码的"风格一致性"是个大问题。

一个项目写久了，团队会形成自己的代码风格。变量怎么命名、函数怎么组织、错误怎么处理，都有约定俗成的模式。人类开发者会自然地融入这个风格，因为他在项目里待久了。

AI不一样。它每次都是"第一次看这个项目"。它会根据它见过的大多数项目来选择风格，这可能和你的项目完全不同。

我遇到过好几次，AI在一个React项目里用了完全不同的组件结构。单独看每段代码都没问题，但放在项目里就显得格格不入。如果你不注意这些，项目代码风格会越来越乱。

AI特别擅长写出"看起来对但其实有问题"的代码。

这是最要命的。人类开发者犯错，往往是因为粗心或者知识盲区，错误通常比较明显。AI犯错，往往是因为它对需求的理解有偏差，写出来的代码逻辑自洽、语法正确、测试也能过——但做的事情和你想要的不一样。

我印象最深的一次：我让AI写一个文件上传功能。它写得很好，支持大文件分片上传、断点续传、进度显示。但问题是，我们的业务场景根本不需要这些。我们只允许上传小于5MB的头像图片。

AI根据"文件上传"这个关键词，自动脑补了一个复杂得多的需求。如果我没仔细review，就会引入一堆不必要的复杂度。

安全问题是最容易被忽视的。

AI写代码的时候，不太会主动考虑安全问题。它关注的是"怎么实现功能"，而不是"怎么安全地实现功能"。

SQL注入、XSS、不安全的依赖、硬编码的密钥——这些我在review人类开发者代码时会重点检查的东西，在AI代码里同样存在，甚至更频繁。因为AI会从它训练数据里找到各种实现方式，包括那些不安全的老写法。

我现在review AI代码时，安全检查是第一优先级，排在功能正确性之前。

怎么识别AI写的代码

这是一个有趣的话题。随着AI编程越来越普及，有些团队开始需要知道：这段代码到底是人写的还是AI写的？

为什么要知道？几个原因：安全审计需要追溯代码来源、团队想统计AI的使用率、某些合规场景需要区分。

从我的经验看，AI写的代码有一些比较明显的特征：

命名过于"规范"。 人类开发者命名有时候会偷懒，用 data、temp、res 这种短名字。AI不会。它总是起又长又"有意义"的名字，比如 filteredActiveUsersByRegistrationDate。单独看每个名字都挺好，但整个项目里全是这种长名字，读起来反而累。

注释密度异常高。 人类开发者（尤其是有经验的）通常不太写注释，因为觉得代码本身应该能说明问题。AI则相反，它特别爱写注释，而且注释往往在重复代码已经表达的意思。如果你看到一个项目突然开始出现大量"解释性注释"，大概率是AI开始参与了。

错误处理要么太多要么太少。 这取决于prompt。如果你说"写得健壮一点"，AI会给你每个操作都加上try-catch和错误处理，搞得代码臃肿不堪。如果你没提错误处理，它可能完全忽略。人类开发者通常有个比较一致的错误处理习惯，AI的风格则完全取决于你怎么要求它。

代码结构过于"教科书"。 AI写代码喜欢用设计模式。你让它写个简单的工具函数，它可能给你搞个工厂模式加策略模式。不是说设计模式不好，而是AI倾向于过度工程化——它把在训练数据里见到的"最佳实践"都用上，不管你的场景是不是真的需要。

缺少"个人印记"。 每个开发者都有自己的编码习惯——某个人喜欢用三元运算符、某个人偏爱early return、某个人习惯把常量放文件顶部。AI没有这种个人习惯，它写出来的代码风格是"平均值"。如果你对团队成员的编码风格很熟悉，一眼就能看出哪些代码不是他们写的。

识别AI代码不是为了"抓人"或者限制AI使用，而是为了更好地管理代码质量。如果你知道某段代码是AI写的，你在review时会更加注意那些AI容易犯的错误。

不同项目类型，review策略也不一样

这是很多人忽略的一点：review AI代码不能一套方法打天下。不同类型的项目，关注点完全不同。

Web应用项目：重点看数据流和状态管理。AI写前端组件通常没什么大问题，但涉及复杂状态（比如多个组件共享一个状态、异步数据加载）时特别容易出错。我现在review React代码，第一个看的就是 useEffect 的依赖数组——AI经常漏掉依赖或者加了不该加的依赖，导致渲染循环或者过期数据。

另外，AI不太理解你的UI设计系统。它会写出自洽的样式，但可能和你项目的设计语言完全不搭。这种问题不会报错，只会让你的界面越来越不统一。

API服务项目：安全是第一优先级。认证、授权、输入校验、SQL注入——这些AI不太会主动考虑。我见过AI写的API路由，功能完全正确，但没有做任何输入验证。直接把用户输入丢给数据库查询。

还有错误处理。AI喜欢写那种笼统的 catch (error) { console.log(error) } 的错误处理，看起来"有处理"，但实际上什么有用信息都没给。生产环境出了问题你都不知道发生了什么。

CLI工具 / 库项目：接口设计是重点。AI会给你实现功能，但API的设计（函数签名、参数命名、返回值类型）往往是"能用就行"的水平。如果你在写一个给别人用的库，API设计的好坏直接决定了用户体验。这部分AI帮不了太多，得你自己把关。

数据处理项目：边界条件。AI处理正常数据没问题，但遇到空值、异常格式、超大数据集时经常翻车。我review数据处理代码时，会特别关注：空数组怎么处理？null值怎么处理？数据量大了会不会OOM？

聊聊我的观察。以下纯属个人感受，不一定对。

升值的能力：

• 系统设计能力。AI能写代码，但做不了好的架构决策。你得告诉它用什么方案、为什么用这个方案。这需要你对整个系统有全局的理解。
• 需求拆解能力。你给AI的任务越清晰，它做得越好。把一个模糊的业务需求拆成具体的、可执行的技术任务，这个能力比以前重要了10倍。
• 代码审美。前面说过了，能不能快速判断一段代码"对不对"、"好不好"。
• 安全意识。AI不太管安全，你得管。
• 沟通能力。没错，和AI"沟通"的能力。怎么写prompt、怎么给上下文、怎么纠正它的方向，这些都是学问。

贬值的能力：

• 快速打字写代码的速度。说实话，打字快已经没什么用了。AI一秒钟能写你一分钟的量。
• 记忆API文档。不需要了。AI知道所有API的所有参数。你需要知道的是"应该用什么API"，而不是"这个API的参数顺序是什么"。
• 写模板代码的能力。CRUD、配置文件、测试脚本这些，AI比你写得好还写得快。
• 语言语法细节。说实话，我现在经常忘了某个语言的某个语法糖怎么写。没关系，AI记得。

注意，我说的是"贬值"，不是"没用"。这些能力还是有用的，只是从"核心竞争力"变成了"加分项"。

我踩过的坑

说几个具体的坑，都是真实经历。

坑一：盲目信任，不看代码。

刚开始用AI编程的时候，我犯过一个错误：看到测试通过了，就直接提交。结果上线后出了一个很隐蔽的bug——在某些边界条件下，AI写的排序逻辑会丢数据。

原因是什么？AI用了一种"看起来高效"但对我们的数据结构不适用的排序方式。测试用例没覆盖到那个边界条件，所以测试通过了。但真实数据里有那种情况。

从那以后，我给自己定了一条规矩：不管AI写的代码多"好看"，必须逐行看一遍。特别是涉及数据操作的部分。

坑二：上下文给少了，AI自由发挥。

有一次我让AI重构一个模块。我没说清楚约束条件——比如"不能改数据库schema"、"要保持向后兼容"。AI就大刀阔斧地改了，包括改了数据库字段名、删了几个"看起来没用"的函数。

结果呢？改完之后一堆下游功能都挂了。因为那些"看起来没用"的函数，被其他模块在用。

教训：给AI的任务描述，要像给新入职的同事写技术文档一样详细。你以为是常识的东西，AI不知道。

坑三：忽略了依赖安全。

AI给我加了一个新依赖，版本号写的是 ^1.0.0。我没多想就用了。后来安全扫描发现这个库有个已知漏洞，需要升级到 ^1.2.3。

更离谱的是，有次AI引入了一个已经停止维护两年的库。因为它的训练数据里有这个库的使用示例，它觉得"这个库可以用"。但它不知道这个库已经不维护了，有未修复的安全漏洞。

现在我review代码时，每个新加的依赖都会去npm/GitHub看看：最近更新时间、open issues数量、下载量趋势。

坑四：测试是AI写的，测试也有bug。

这个坑比较微妙。AI会给你写测试，测试也通过了。但问题是：如果AI对需求的理解有偏差，它写的测试也是基于那个偏差的理解写的。所以测试通过了，不代表功能正确——只代表AI以为正确的功能，确实能做到。

我现在会单独review测试用例，看看它们是否覆盖了我真正关心的场景。不能完全信任AI写的测试。

一个让我印象深刻的翻车事件

说一个上个月发生的事，因为太典型了，值得单独拿出来讲。

我们有一个定时任务系统，每天凌晨3点跑一批数据处理。之前一直运行正常，直到有一天我让AI给这个系统加一个新功能：在处理完成后发一封汇总邮件给管理员。

AI很快就写好了。代码看起来没问题——读数据库、汇总数据、调用邮件API、记录日志。测试也过了。

上线第二天早上，我收到管理员的邮件："昨晚收到了38封汇总邮件。"

我当时就懵了。看了日志才发现，AI写了一个逻辑：如果处理过程中有任何warning级别的日志，就发一封邮件。问题是，数据处理本身就会产生大量warning（比如某些数据缺失、某些格式不标准），每处理100条数据大概有15条warning。AI把每条warning都触发了一次邮件发送。

我当时给AI的需求是"处理完成后发汇总邮件"。AI理解成了"处理过程中有异常就发邮件通知"。它觉得这样"更安全"——有什么问题立刻通知管理员。

问题出在哪？我给的需求不够精确。"处理完成后"到底是"全部处理完之后发一封"还是"每个批次处理完都发"？"汇总邮件"是"包含所有warning的汇总"还是"每个warning单独一封"？

这种歧义人类开发者通常会问一句："你想要一封汇总还是每条异常单独通知？"AI不会问。它自己做了一个判断，然后就这么写了。

教训：对于涉及"触发条件"的逻辑，必须写得极其精确。不要用模糊的描述，要写具体的规则。

我用过的AI代码审查工具

既然review这么重要，有没有工具能帮忙？有，而且效果还不错。

CodeRabbit：目前我用得最多的。它会在每个PR上自动留评论，指出潜在问题。优点是覆盖面广，从代码风格到安全漏洞都能发现。缺点是有时候太"严格"了，会提一些无关紧要的意见，你需要自己判断哪些值得关注。

我现在把它当"第一道筛"用——它先扫一遍，标记出可能有问题的地方，然后我重点看那些标记。省了不少时间。

PR-Agent：开源的，可以自己部署。好处是完全可控，你可以自定义review规则。缺点是需要花时间配置和维护。如果你的团队有专人负责DevOps，可以考虑。

直接用Claude/GPT做review：把代码贴给AI，让它以"资深开发者"的视角review。这种方式的好处是非常灵活——你可以指定关注点（"重点看安全"、"重点看性能"），也可以让它和项目现有的代码风格做对比。缺点是需要手动操作，不够自动化。

我个人的做法是：CodeRabbit做自动扫描 + 我自己重点review关键逻辑。两者结合效果最好。

工具能帮你发现问题，但最终的判断还是得靠你自己。别指望工具能替代你的思考。

怎么适应这个新角色

说了这么多，最后聊聊实操建议。

第一，改变工作流程。

不要把AI当成"你告诉它做什么，它做了，你提交"的工具。把它当成一个需要管理的"初级开发者"。

我现在的工作流程是：

1. 想清楚要做什么，写一个简要的技术方案
2. 把方案给AI，让它实现
3. Review输出，提修改意见
4. 重复2-3直到满意
5. 最终我手动检查安全性和边界条件
6. 提交

这个流程比"自己从头写"快，但比"让AI写完直接提交"慢。慢的部分，就是review的时间。

第二，刻意练习代码审查能力。

如果你以前主要靠自己写代码，review别人代码的经验不多，那你需要刻意练习这个能力。

具体怎么练？

• 看开源项目的PR review记录，学学有经验的人怎么review
• 用AI代码审查工具（CodeRabbit、PR-Agent）辅助，但不要完全依赖
• 养成"先看整体结构，再看细节"的review习惯
• 建立自己的review checklist：安全、性能、一致性、可维护性

第三，投资"上层"能力。

系统设计、架构思维、需求分析——这些以前在职业发展中就很重要，现在更重要了。

因为AI把"实现"这一步的成本压低了，所以"决定做什么"和"决定怎么做"的价值就相对提高了。

如果你现在还是主要在写CRUD代码，建议开始有意识地往"设计"和"决策"方向发展。不是说CRUD不重要，而是这部分越来越多地被AI接管了。

第四，保持对代码的感觉。

虽然你写代码的量变少了，但不能完全不写。就像一个导演不能完全不懂摄影一样，一个"代码审查员"也不能完全不写代码。

我每周还是会找一些小任务自己从头写，保持手感。不然时间长了，你review代码的能力也会退化，因为你对"怎么写代码"失去了直觉。

不同AI模型的代码风格差异

用了一年多各种AI编程工具，我发现不同模型写出来的代码风格差异还挺大的。这不是什么科学测评，纯个人感受。

Claude（Anthropic）：代码风格偏"干净"。喜欢用现代语法，函数通常比较短，注释适量。缺点是有时候过于"优雅"，为了代码好看牺牲了一点可读性。另外Claude特别喜欢用函数式编程的写法，如果你的项目是面向对象风格的，可能需要多提醒它。

GPT-4 / Codex（OpenAI）：代码风格偏"实用"。不太追求优雅，但功能实现通常很完整。缺点是有时候会写得比较啰嗦，一个简单的事情可能用好几行来实现。另外GPT系模型的注释特别多，有时候多到影响阅读。

Gemini（Google）：代码风格偏"保守"。不太用最新的语法特性，写出来的代码兼容性比较好。缺点是有时候显得有点"老派"。另外Gemini对中文注释的支持不太稳定，偶尔会输出乱码。

DeepSeek：代码能力不错，特别是算法和数据结构相关的代码。但在理解项目上下文方面比Claude和GPT弱一些，经常需要你更详细地描述需求。

这些差异意味着什么？如果你在不同任务中使用不同模型，你review代码时需要注意风格一致性的问题。比如同一个项目里，一部分代码是Claude风格的函数式写法，另一部分是GPT风格的命令式写法，读起来会很割裂。

我的做法是：一个项目尽量用同一个模型。如果需要切换模型，就在prompt里明确要求"按照项目现有的代码风格来写"。

团队协作中的新挑战

如果你不是一个人写项目，而是在团队里，AI编程还会带来一些额外的挑战。

代码风格统一变得更难。

每个人用的AI工具可能不同，prompt习惯也不同，导致AI生成的代码风格五花八门。我见过同一个项目里，有人用 async/await，有人用 .then() 链式调用——因为不同人用不同AI工具生成的。

解决方案是建立团队级的规则文件（比如 .cursorrules、CLAUDE.md），把编码规范写进去。但这又多了一层维护成本。

Code Review文化需要调整。

以前review同事的代码，大家默认"写代码的人对自己的代码最了解"。现在review AI写的代码，写代码的人（你）和"写代码的实体"（AI）之间有信息差。你需要向reviewer解释"AI为什么这样写"，这比解释"我为什么这样写"难多了。

有些团队开始在PR描述里加一段"AI参与度说明"——这个PR里有多少是AI写的、哪些部分需要重点review。我觉得这是个好习惯。

知识传递变难了。

以前一个初级开发者通过写代码来学习。他写一段代码，senior review一下，指出问题，他就学到了。现在代码是AI写的，初级开发者只是"审查"了一下。他学到的东西比自己动手写少得多。

有些团队开始要求：即使用了AI，每个开发者每周也必须自己从头写一些代码。不是为了效率，是为了学习。

说点不那么乐观的

以上都是比较积极的方面。说点让人不太舒服的。

Review比写代码累。

这不是我的感受，是我认识的几乎所有用AI编程的开发者的共识。写代码是创造性的，有flow state，做着做着会进入心流。Review是分析性的，一直在找问题，一直在做判断，精神消耗大得多。

一天review 500行AI写的代码，比自己写200行代码累多了。

对初级开发者不太友好。

这个话题比较敏感，但我觉得得说。如果一个初级开发者的主要价值是"能写代码"，那AI确实能替代很大一部分。初级开发者需要成长为"能review代码"、"能做设计决策"的人，这个成长路径比以前更陡了。

不是说初级开发者没用了——团队还是需要人来做具体的事情。但"只会写代码"的生存空间确实在缩小。

代码所有权感在消失。

以前你写了一段代码，你对它有感情，你知道每一个决定背后的原因。现在代码是AI写的，你只是review了一下。那种"这是我的作品"的感觉淡了很多。

这可能不是什么大事，但对于那些从写代码中获得乐趣的开发者来说，确实是一种失落。

所以，结论是？

没有结论。这个变化还在发生中，没人知道最终会变成什么样。

我能确定的是：纯粹的"写代码"能力在贬值，但围绕代码的其他能力——设计、审查、调试、沟通——在升值。开发者这个职业不会消失，但工作内容确实在变。

如果你也在用AI编程，欢迎在评论区聊聊你的感受。你每天review AI代码的时间有多少？你觉得累吗？有什么好的review技巧？

这些问题我真的很想知道答案。因为说实话，我也没完全搞明白怎么才能把这件事做好。

一个不太受欢迎的预测

最后说一个我的预测，可能不太受欢迎。

未来两年，"能写代码"将不再是开发者的核心竞争力。这句话很多人说过，但我想补充一个细节：不是说写代码不重要了，而是"写代码"会变成一个像"会打字"一样的基础技能——人人都会，不构成差异化。

真正构成差异化的，是"知道该写什么代码"和"能判断代码写得对不对"。

前者是产品思维和系统设计能力，后者是代码审查和调试能力。这两种能力，AI短期内很难替代。

但这也意味着，那些纯粹靠"写代码快"、"记住了很多API"吃饭的开发者，可能会面临更大的压力。不是因为AI比你写得好（说实话，AI写的代码质量参差不齐），而是因为AI写得快，而且"够用"。在很多场景下，"够用+快"比"好但慢"更有商业价值。

这不是什么新鲜事。技术行业一直在发生这种变化——高级语言替代了汇编，框架替代了原生开发，云服务替代了自建机房。每次变化都有人说"XX要完了"，但最终行业只是换了一种做事方式。

这次可能也一样。但"换一种做事方式"的过程中，确实会有人跟不上。这不是贩卖焦虑，是现实。

最好的应对方式，不是抗拒变化，也不是盲目拥抱AI，而是想清楚：在这波变化里，哪些能力是真正稀缺的，然后去投资那些能力。

对我来说，答案是：系统设计、代码审查、以及和AI"沟通"的能力（也就是prompt engineering和context engineering）。这三个方向，我会持续投入时间。

几个实用的review技巧

既然这篇文章的核心是"review"，最后分享几个我总结的review技巧，都是实战中积累的。

先看数据流，再看实现细节。 AI写的代码，实现细节通常没什么大问题。出问题最多的地方是数据在不同组件/函数之间传递的时候。我会先画一条数据从输入到输出的路径，看看中间每一步数据的格式和内容有没有变化。如果某一步突然多了个字段或者少了个字段，那大概率有bug。

重点看"条件分支"。 if-else、switch、三元运算符——这些是bug的高发区。AI处理正常流程没问题，但"其他情况"往往处理得很草率。我会特别关注那些else分支和default分支，看看它们的行为是不是合理的。

看测试用例的覆盖范围。 前面说了，AI写的测试可能有偏差。但如果你仔细看测试用例，它反而能帮你理解AI对需求的理解。如果测试用例覆盖的场景和你预期的不一样，说明AI对需求的理解有偏差，你需要纠正。

定期做"逆向review"。 什么意思？就是不要只看AI改了什么，还要看AI没改什么。有时候AI会漏掉一些需要同步修改的地方——比如你改了一个数据结构的格式，但相关的API接口、类型定义、文档没有同步更新。这种遗漏在diff里看不到，因为你只看到AI改了的地方。

建立团队的"AI代码review checklist"。 把你踩过的坑整理成一个清单，每次review时对照检查。比如：有没有新的依赖需要检查安全性？有没有硬编码的配置值？错误处理是不是足够具体？日志信息有没有实际价值？

这些技巧不是什么高深的东西，但在日常工作中确实管用。

最后

你呢？如果你也在用AI编程，评论区聊聊你的感受。你每天review AI代码的时间有多少？你觉得累吗？有什么好的review技巧？

说实话，这个领域变化太快了，我写这篇文章的时候用的一些工具和方法，可能下个月就过时了。但我觉得核心逻辑不会变：AI让"写代码"变便宜了，但"判断代码对不对"永远需要人。

只要这个判断还需要人，开发者就不会失业。只是工作方式会变。

• 写于2026年6月，一个review了一天AI代码、眼睛快瞎了的开发者。如果你也在经历同样的变化，评论区聊聊。*

• 写于2026年6月，一个review了一天AI代码、眼睛快瞎了的开发者。*