AI编程不能替你完成什么

AI 编程工具正在改变开发方式，但它的边界同样清晰。这一章讲清楚哪些事情 AI 做不了、做不好，以及为什么人类开发者的判断力在可预见的未来仍然不可替代。

从一个常见的误解说起

「有了 AI 编程助手，我是不是不需要学架构、不需要懂业务、不需要做 Code Review 了？」

这个问题在过去两年里被反复提起。答案是明确的：不是。

AI 编程工具确实能大幅提升编码效率——自动补全、函数生成、单元测试编写、文档生成、代码翻译，这些场景下它的表现已经相当出色。但如果把视角拉远，软件开发的真正难点从来不只是「写代码」本身。架构决策、业务理解、需求判断、安全审计、性能调优、跨系统协调、团队沟通——这些工作需要的不是代码生成能力，而是工程判断力。

根据 2025 年的行业数据，尽管 AI 编程工具的使用率在持续上升，开发者对 AI 输出准确性的信任度反而从 40% 下降到了 29%。工具越多、使用越频繁，人们反而越不放心——这背后是一个值得深思的信号。

本文的目的不是否定 AI 编程的价值，而是帮你画清一条线：这条线以内，AI 是你的强力助手；这条线以外，你必须自己做判断。

AI 编程的能力边界

架构决策：需要全局视角和权衡

架构设计不是「写一段能跑的代码」，而是在多个约束条件下做出取舍。可扩展性与简单性之间怎么选？一致性与可用性之间怎么平衡？技术选型的长期维护成本怎么评估？这些问题的答案取决于团队规模、业务阶段、预算约束、技术栈现状等一系列上下文信息。

AI 能帮你列出几种架构方案的优缺点，但它无法替你做出那个「适合当前团队和业务阶段」的决定。原因很简单：AI 不掌握你的项目全貌。 它的上下文窗口是有限的，无法同时理解数百个文件之间的依赖关系、历史遗留代码的设计意图、以及未来半年的业务规划。

一个典型的场景是：你让 AI 帮你设计一个微服务拆分方案，它能给出符合教科书原则的通用方案，但它不知道你团队只有 3 个人、不知道你当前的部署基础设施不支持服务网格、不知道你的数据一致性要求比延迟要求更高。这些「不知道」决定了它的方案在纸面上正确，但在你的项目里行不通。

业务理解：需要领域知识

软件开发的核心挑战往往不是技术，而是理解业务。一个电商系统的「退货」流程，涉及库存回滚、退款策略、物流状态同步、客服工单、财务对账等多个环节。AI 可以帮你生成每个环节的代码片段，但它无法替你理解：

• 这个业务的实际用户是谁？他们的使用场景是什么？
• 产品文档里没写的隐含规则是什么？（比如「VIP 用户退货优先处理」）
• 不同地区的法规差异如何处理？（比如欧盟的 14 天无理由退货）
• 哪些边缘情况在实际运营中频繁出现？

这些知识来自与产品经理的沟通、与客服的反馈收集、对用户行为的观察，而不是从训练数据中能直接提取的。

需求判断：需要与人沟通

需求不是从 PRD 文档里直接搬到代码里的。真实的需求充满了模糊性、矛盾和隐含假设。当产品经理说「做一个类似 XX 的功能」时，这句话背后有大量需要澄清的东西：

• 「类似」是指交互类似还是逻辑类似？
• 哪些部分要复用，哪些要做差异化？
• 优先级怎么排？MVP 阶段先做哪些？
• 与现有功能的冲突怎么处理？

AI 无法替你参加需求评审会，无法替你在会议上追问那些没有写进文档的关键细节，也无法替你判断一个需求在当前阶段是否值得做。需求判断的本质是沟通和决策，不是编码。

安全审计：需要专业安全思维

这是一个特别值得重视的领域。多项研究表明，62% 的 AI 生成代码包含设计缺陷或已知安全漏洞，即使在开发者使用了防护措施的情况下，这个比例依然居高不下。

AI 生成代码的安全问题主要有以下几类：

• 注入漏洞：模型可能在生成的代码中将未经验证的输入直接拼接到数据库查询中，产生 SQL 注入风险
• 权限控制缺失：AI 倾向于生成「能跑通」的代码，而不是「安全的」代码，常常忽略访问控制和认证检查
• 硬编码密钥：为了快速完成任务，AI 可能在代码中直接写入 API 密钥、数据库密码等敏感信息
• 不安全的默认配置：AI 可能建议使用 eval() 执行动态表达式，或使用不安全的加密算法

更隐蔽的风险是「幻觉依赖」：AI 在代码中引用不存在的 npm 包名或 Python 库，这些包名被攻击者抢注后植入了恶意代码。网络安全公司 Socket 的研究人员已经警告过这种现象——AI 生成的幻觉包名具有「可预测性」和「语义合理性」，形成了可被利用的攻击面。

性能调优：需要理解系统全貌

AI 可以帮你写一个排序算法，也能帮你分析单个函数的时间复杂度。但真正的性能问题往往不是单个函数的问题，而是系统级的：

• 数据库慢查询可能是因为索引设计不合理，而索引设计取决于查询模式和读写比例
• 内存泄漏可能跨越多个模块，需要理解对象生命周期和引用链
• API 响应慢可能是因为级联调用太多，而调用链的设计涉及服务间的数据依赖

性能调优需要理解整个系统的运行方式——数据怎么流动的、瓶颈在哪里、哪些优化是局部的、哪些是全局的。AI 能帮你跑 profiler、分析火焰图、建议优化方向，但「判断哪个瓶颈最值得先解决」这个问题，需要你对系统全貌的理解。

复杂业务逻辑：跨模块、跨系统

当一个功能涉及多个模块、多个服务、多个数据源时，代码的复杂性不再来自语法，而是来自协调。状态一致性怎么保证？分布式事务怎么处理？失败重试策略怎么设计？消息队列的消费者怎么处理乱序消息？

这些问题没有标准答案，每个项目的技术栈、基础设施、数据模型都不一样。AI 能给你参考实现，但它无法替你理解你的系统里这些组件是如何实际协作的。

AI 常犯的错误

理解 AI 常犯的错误类型，有助于你建立有效的审查策略。

幻觉代码

AI 最常见的错误是「一本正经地胡说八道」：生成看起来语法正确、逻辑合理，但实际上引用了不存在的 API、不存在的库、或者编造了不存在的函数参数。

例如，AI 可能生成这样的代码：

import { validateEmail } from 'validator-pro'; // 这个包不存在
import { formatDate } from 'date-utils'; // API 与真实库不一致
 
const result = validateEmail(input, { strict: true }); // 参数签名是编造的

这些代码在静态分析时可能不会报错（因为语法正确），但在运行时会直接崩溃，或者更糟——产生错误的结果而不报错。

安全漏洞

如前文所述，AI 生成的代码中安全漏洞的比例相当高。一个典型的案例是：AI 在生成用户认证代码时，可能使用不安全的哈希算法（如 MD5）存储密码，或者在权限校验中只检查单一角色而忽略了角色继承关系，导致权限绕过。

过度工程

AI 有一种倾向：对简单问题给出过度复杂的解决方案。让它写一个简单的配置读取功能，它可能引入依赖注入框架；让它处理一个 CSV 文件，它可能设计一个完整的数据管道架构。这是因为 AI 的训练数据包含了大量开源项目代码，而这些代码往往是「生产级」的复杂实现。

忽略边界条件

AI 生成的代码通常覆盖「正常路径」（happy path），但对边界条件的处理往往不完整：

• 空值检查缺失
• 数组越界未处理
• 并发场景下的竞态条件
• 极端数据量下的性能退化
• 时区、编码、国际化相关的边界情况

上下文丢失

在长对话或多轮迭代中，AI 会逐渐「忘记」之前的约定和约束。你可能在第 3 轮对话中确定了错误处理策略，但到第 15 轮时 AI 生成的代码已经不再遵循那个策略了。这不是 bug，而是上下文窗口的物理限制。

对比表格

表 1：AI 能做 vs 不能做的任务对比

表 2：AI 常见错误类型与预防措施

表 3：人类开发者不可替代的核心能力

表 4：AI 辅助 vs 完全依赖 AI 的风险对比

真实案例

案例一：AI 生成的 URL 验证脚本引发的爬虫事故

一位初级工程师使用 AI 编程助手生成了一个 URL 验证和页面抓取脚本。AI 给出的代码在功能测试中运行良好，能快速识别目标页面并提取内容。但团队在 Code Review 中发现了几个问题：

1. 脚本没有设置爬虫范围限制（crawl scope），可能抓取到不该访问的内部页面
2. 没有处理连接超时的重试策略，在高并发场景下会耗尽系统资源
3. 缺少 robots.txt 的解析逻辑，不符合爬虫规范

团队花了额外的时间修复这些问题。虽然这让发布延迟了 24 小时，但上线后相关的运维工单减少了 35%。如果没有人工审查，这个脚本在生产环境中很可能引发一次严重的爬虫事故。

案例二：AI 幻觉依赖导致的供应链安全事件

2024 年，安全研究人员发现了一种新型供应链攻击模式：开发者使用 AI 编程工具生成代码时，AI 引用了一个不存在的 npm 包名。攻击者发现这个「幻觉包名」后，在 npm 上注册了同名包并植入了恶意代码。当开发者运行 npm install 时，恶意代码被自动安装到项目中。

这个事件的可怕之处在于：AI 生成的包名具有「语义合理性」——它看起来像是一个真实的、合理的包名，开发者不会在使用前逐一核实每个包的真实性。Socket 公司的研究指出，这种幻觉包名具有「可预测性」和「可重复性」，意味着攻击者可以系统性地利用 AI 的这种缺陷。

案例三：AI 生成的权限校验导致越权访问

某团队使用 AI 生成了一段权限校验代码。AI 的实现方式是检查用户是否拥有 admin 角色，但遗漏了系统中实际使用的多角色继承模型——一个用户可能同时拥有 editor 和 moderator 角色，这两个角色的组合应该等同于 admin 权限。AI 生成的代码只检查了单一角色名称，导致部分拥有组合角色的用户被错误地拒绝了访问，而另一些本不应该有管理员权限的用户却因为被直接赋予了 admin 角色而获得了过度权限。

这类 bug 的隐蔽性在于：代码逻辑是「正确」的——它确实在检查角色。但它检查的方式与系统的实际权限模型不匹配。

决策路径：什么时候用 AI，什么时候自己判断

下面的流程图可以帮助你判断在具体场景中，应该如何使用 AI 工具：

核心原则：AI 负责「生成」，人类负责「判断」。越靠近业务、安全、架构的决策，越需要人类主导；越靠近语法、格式、模板的工作，越适合交给 AI。

AI 编程安全边界检查清单

在使用 AI 编程工具时，以下检查清单可以帮助你守住质量底线：

代码正确性

• 验证所有引用的 API 和库是否真实存在——在官方文档或 npm/PyPI registry 中确认
• 检查 AI 生成的代码是否遵循项目既有的编码规范和设计模式——不要让 AI 引入不一致的风格
• 为 AI 生成的代码补充边界条件测试——空值、极值、并发场景、异常路径

安全性

• 所有涉及认证、授权、加密的代码必须人工审查——不能直接信任 AI 的安全实现
• 检查是否存在硬编码的密钥、密码或敏感信息——AI 经常生成不安全的快捷实现
• 验证所有外部输入都有校验和过滤——AI 倾向于生成「能跑通」而非「安全」的代码
• 确认依赖项没有在已知漏洞数据库中列出——运行 npm audit 或对应的安全扫描工具
• 检查 AI 引入的新依赖是否真实、活跃、维护良好——防止幻觉依赖和废弃包

架构与可维护性

• 评估 AI 生成的代码是否与现有架构一致——不要让它引入不一致的抽象层或设计模式
• 警惕过度工程——AI 经常为简单问题生成过度复杂的方案，遵循 YAGNI 原则裁剪
• 检查跨模块的影响——AI 生成代码时不考虑你的系统全貌，你需要自己评估影响范围

业务与需求

• 确认 AI 生成的代码真正反映了业务需求——不是「看起来像」，而是逻辑上正确
• 验证边缘业务场景是否被正确处理——退货、退款、超时、并发、国际化等
• 与相关方确认需求理解无误——不要让 AI 的「合理猜测」替代真实的需求沟通

流程

• 记录所有 AI 生成的关键代码及其审查过程——方便回溯和知识积累
• 定期回顾 AI 引入的错误模式——建立团队级别的 AI 使用经验和注意事项

写在最后

AI 编程工具是这个时代开发者能拥有的最强助力。它能帮你写出更快的代码、学新的技术栈、处理重复性工作。但「助力」的意思是「帮助你在正确的方向上走得更快」，而不是「替你决定正确的方向」。

架构决策、业务理解、需求判断、安全审计、性能调优、系统协调——这些工作的价值不在于「写代码」，而在于「做判断」。判断力来自经验、沟通、对业务的理解、对系统的整体认知，以及从失败中学到的教训。这些东西，AI 暂时给不了你。

最好的工作方式不是「用 AI 替代人」，也不是「不用 AI」，而是找到那条清晰的边界：让 AI 做它擅长的生成和辅助工作，让人做它擅长的判断和决策工作。 这条边界不是固定的，它会随着 AI 能力的演进而移动。但至少在当下，清楚地知道这条边界在哪里，是每一个使用 AI 编程工具的开发者必须具备的认知。

参考资料

1. What AI Can't Do (Yet) in Software Development - Berkeley Voices, 2026
2. Understanding Security Risks in AI-Generated Code - Cloud Security Alliance, 2025
3. The Most Common Security Vulnerabilities in AI-Generated Code - Endor Labs, 2025
4. AI 编程能力受限于上下文的限制 - 宝玉的分享, 2024
5. AI 幻觉代码依赖成为新型软件供应链威胁 - 51CTO, 2025
6. Top AI Security Vulnerabilities to Watch out for in 2026 - Cycode, 2026
7. How AI-Generated Code Is Unleashing A Tsunami Of Security Risks - Forbes Tech Council, 2025
8. Here's What AI Coding Can't Do (Yet) - Medium, 2025
9. 从程序员视角看 AI 编程的局限性：2025 年的现实与反思 - CSDN, 2025
10. AI 程式设计中的幻象：幻觉与程式码可信度 - 趋势科技, 2024