8.0
热点
AI SCORE
编程提效2026-09-06 17:25
AI 写代码已成常态，程序员的核心价值转向代码审查
dev.to · AI#AI编程#代码审查#Copilot
Editor brief · 编辑速览
84% 开发者已使用或计划使用 AI 编程工具，但 AI 生成代码的「差不多」问题依然存在。文章给出具体审查清单：Token 有效期、并发安全、错误处理等，是目前最实用的 AI 代码审查 SOP。
AI 现在能写代码了。
这件事已经不再令人惊讶。
你可以向 Copilot、Claude Code、Cursor、Codex 或其他编程 Agent 描述一个功能，几分钟后就能得到一个可用的实现。
有时候确实令人印象深刻。
但有一个更重要的问题：
你真的相信这些代码足以发布吗？
根据 Stack Overflow 2025 开发者调查，84% 的开发者正在使用或计划使用 AI 工具。
与此同时，开发者对 AI 生成内容的信任仍然有限。开发者反馈最多的痛点之一，是得到的答案几乎正确，但又不完全对。
Source: https://survey.stackoverflow.co/2025/ai
而这个"几乎正确"的部分，恰恰是开发者仍然不可替代的地方。
AI 或许会写出更多代码。
但仍然需要人类来判断这些代码是否正确、安全、可维护，以及是否真的值得合并。
以下是我认为每个开发者都应该实践的简单审查工作流。
想象一下你告诉一个 AI Agent：
Add password reset support.
几分钟后，它生成了完整的功能。
代码可以编译。
测试甚至可能通过。
但在阅读实现之前，先问自己：
重置令牌的有效期是多久？
同一个令牌能否被使用两次？
如果邮箱不存在会发生什么？
是否需要登出已有的会话？
我们是否暴露了用户账号是否存在的信息？
这很重要，因为 AI 可以非常干净利落地构建错误的东西。
这个方案解决的是正确的问题吗？
这一个问题就能节省大量时间。
AI 通常擅长写一个函数。
但它并不总能理解这个函数应该放在系统的哪个位置。
例如，一个 Agent 可能会创建这样的结构：
components/
├── PaymentForm.tsx
├── PaymentAPI.ts
├── StripeService.ts
└── Database.ts
从技术上讲，一切都能正常工作。
但数据库访问真的应该放在 UI 组件旁边吗？
在关注小的语法细节之前，先检查：
业务逻辑放在正确的层级了吗？
Agent 是否复制了已有的服务？
Agent 是否忽略了你现有的项目结构？
Agent 是否绕过了其他地方已经在用的抽象层？
六个月后，另一个开发者能看懂这段代码吗？
一个文件可能包含完全正确的代码，但放在错误的位置。
AI 生成的功能在一切顺利时往往表现很好。
生产环境并不总是那样运转。
看一个简单的例子：
const user = await getUser(id);
return user.name;
user === null
现在问一些更难的问题。
请求被提交了两次怎么办？
两个用户同时更新同一条记录怎么办？
数据库不可用怎么办？
令牌已经过期怎么办？
用户没有权限怎么办？
输入为空或极大怎么办？
外部服务返回了畸形数据怎么办？
这些情况并不令人兴奋。
但它们正是大量真实 bug 所在的地方。
好的审查不只是检查正常流程是否工作。
而是尝试找出正常流程在哪里会停止工作。
现在常见的 AI 工作流是这样的：
AI writes the feature
↓
AI writes the tests
↓
Tests pass
↓
Merge
这看起来很高效。
但有一个弱点。
如果模型误解了需求，它可能也会基于同样的误解来写测试。
所以不要只问：
Write tests for this feature.
问一些更难的问题。
Find five ways this implementation could fail.
What important edge cases are missing?
Which inputs could break this function?
What security assumptions does this implementation make?
然后自己审查或补充最重要的测试。
AI 绝对应该帮助测试。
只是不应该成为评判自己工作的唯一裁判。
这一点很容易被忽略。
AI Agent 可能会因为让任务更快而安装一个包。
npm install some-package
在接受它之前，检查：
我们真的需要这个依赖吗？
它有活跃的维护吗？
它有已知的安全问题吗？
它引入了多少传递依赖？
用几行现有代码能否完成同样的事？
许可证适合这个项目吗？
有时候 AI 生成的功能很小。
但它添加的依赖并不小。
不要只审查 AI 写的内容。
要审查 AI 引入的内容。
使用编程 Agent 时，这一点更加重要。
现代编程 Agent 可能有权访问：
Filesystem
Terminal
Git repository
Environment variables
Database
Cloud services
External APIs
这是 Agent 强大的原因。
也是错误代价更高的地方。
Stack Overflow 2025 调查报道称，许多开发者对 AI Agent 的安全和隐私风险感到担忧。
Source: https://survey.stackoverflow.co/2025/ai
每当 Agent 做了大改动时，要额外关注：
.env files
authentication
authorization
API permissions
database migrations
CI/CD configuration
cloud credentials
secrets
问题不再只是：
AI 写了什么代码？
AI 被允许触碰什么？
这个区别很重要。
开发者自然倾向于关注 Git diff 中的绿色行。
但 AI 也可能删除重要的代码。
有时候删得太多了。
所以在审查一个大型 AI 生成改动时，也要仔细看红色行。
为什么删除了这个？
这个行为是被有意替换了吗？
AI 是否删除了验证逻辑？
是否删除了边缘情况处理器？
这会在其他地方造成回归吗？
新功能可能工作得很好，但同时悄悄地破坏了旧功能。
始终审查 Diff 的两端：
+ Added code
- Removed code
人工审查不意味着手动检查所有东西。
当 AI 写更多代码时，你现有的开发者工具变得更加重要。
Type checking
Linting
Unit tests
Integration tests
Security scanning
Dependency scanning
Static analysis
Build verification
CI
npm run lint
npm run typecheck
npm test
npm run build
AI 加快了代码生成的速度。
所以我们的验证流程也需要变得更强大。
在合并一个 AI 生成的 PR 之前，问自己一个简单的问题：
如果一个初级开发者提交了完全相同的 PR，我会批准吗？
如果答案是否定的，不要仅仅因为 AI 写得快就合并它。
如果你会问一个人类开发者：
你为什么选择这个架构？
如果你会要求一个人类开发者补充更多测试：
要求 AI 补充更多测试。
如果你会拒绝一个人类开发者的不安全代码：
也拒绝 AI 的不安全代码。
质量标准不应该降低。
AI 已经让开发者变得更快了。
Stack Overflow 2025 年调查报道称，使用 AI Agent 的开发者通常能看到真实的效率提升。
Source: https://survey.stackoverflow.co/2025/
GitHub 也报道了 AI 辅助软件开发的快速增长，以及使用 LLM 相关工具的仓库数量激增。
所以 AI 可能会继续做更多这类事：
Boilerplate
CRUD code
Components
Refactoring
Tests
Documentation
Small features
但开发者仍然需要处理：
Requirements
Architecture
Security
Trade-offs
Verification
Debugging
System design
Product decisions
这就是有趣的变化。
最好的开发者可能不再是最快敲出代码的人。
而是可以审视 AI 生成的代码并快速回答：
这个真的正确、安全、可维护、可以发布到生产环境吗？
这比单纯知道如何给 AI 编程工具写 prompt 要有价值得多。
这正在成为常态。
更难的部分是知道这段代码是否值得发布。
所以下次一个 AI Agent 在三分钟内改了 20 个文件，不要只被速度打动。
检查架构。
打破快乐路径。
审查权限。
然后判断这段代码是否真的足够好。
AI 可以是作者。
你仍然需要是审查者。
你还是在合并前审查每个 AI 生成的文件吗？