AI编程能力边界清单：能干什么，不能干什么

分不清AI编程能干嘛不能干嘛，要么被它坑，要么白白不用。

被坑的那种：把一个架构设计扔给AI，它给了你一个看起来合理但根本没法维护的方案，你照着做了两周，返工。

白白不用的那种：写一个标准的增删改查接口，手敲了半小时，事后才知道三十秒就能搞定。

这两种情况都是对能力边界没概念。这篇就是要把这个边界搞清楚。

---

为什么要搞清楚边界

很多人接触AI编程工具之后，会快速跑向两个极端：一端是"AI什么都能做，以后不用学了"，另一端是"AI生成的代码一堆问题，还不如自己写"。

这两个极端都基于同一个错误：把AI当成一个整体去评价，而不是看它在具体任务上的表现。

AI编程的能力边界不是一条线，是一张地图——某些地方地势平坦、AI跑得很快；某些地方坑洼密布、你得自己走。你的工作是看懂这张地图，把自己的时间用在它跑不了的地方。

对每一条边界，我们都会说三件事：它擅长/不擅长的是什么、为什么会这样、你该怎么配合。

---

擅长的那些事

1. 样板代码（Boilerplate）

干什么：Express路由骨架、React组件模板、数据库连接配置、Dockerfile基础版、各种框架的starter结构——所有"有固定套路、写法高度相似"的代码。

为什么擅长：这类代码在训练数据里出现过几十万次，AI见过太多，模式烂熟于心。你说需求，它照套路给你。

怎么配合：描述清楚你要的技术栈和约束。"用Express+TypeScript写一个带JWT鉴权的路由骨架，错误统一走中间件处理"，这种描述给的结果比"写个后端路由"准确得多。生成之后，核对框架版本是否匹配你的项目——这类代码的主要风险是版本对不上。

---

2. CRUD增删改查

干什么：标准的数据模型读写操作：查列表、查详情、新增、更新、删除。加上分页、排序、基础过滤逻辑，一并搞定。

为什么擅长：CRUD有极强的结构规律性，给定数据模型和接口规范，生成过程接近"填空"。这是AI编程里性价比最高的一类任务，节省时间最直接。

怎么配合：把你的数据模型、接口规范、ORM/框架告诉它。如果你用Prisma，说你用Prisma；如果返回格式有特定要求，贴一个示例。边界条件（空值处理、字段长度限制）说清楚，否则它可能漏掉。

---

3. 重构既有代码

干什么：提取重复逻辑为函数、把回调改成Promise/async-await、分解过长的函数、把硬编码的魔法数字换成常量、统一命名风格。

为什么擅长：这类任务有明确的"输入代码"和"目标模式"，AI可以看清楚变换规则，操作的是结构而不是逻辑。它不需要理解你的业务，只需要懂代码模式。

怎么配合：指定重构范围和目标。"把这个函数里超过3层的回调改成async/await，保持功能不变，注释不要动"——越具体越好。重构完之后跑测试，确认行为没变。

---

4. 写单元测试

干什么：给你的函数写测试用例——正常路径、边界输入、异常情况。用Jest、pytest、JUnit等主流测试框架。

为什么擅长：写测试有固定结构（Arrange-Act-Assert），AI理解函数的输入输出之后，能系统性地想到测试场景，往往比你自己想得更全。

怎么配合：把被测函数的代码和预期行为说清楚。如果有mock的依赖，告诉它用什么库来mock。生成后检查：覆盖率数字好看不代表测的是真实行为，看一眼断言写的是不是有意义的东西。

---

5. 解释报错 / 查文档

干什么：把报错信息贴给它，让它解释什么意思、可能是什么原因、怎么排查。或者问某个库的API用法，让它给示例。

为什么擅长：AI见过大量的报错模式和技术文档，这本质是检索+解释任务，它擅长把模糊的信息整理清楚。比你自己搜索再拼凑快很多。

怎么配合：贴完整的报错堆栈，不要只贴最后一行。加上上下文："我在用Docker跑Node 20，这是完整的错误"。报错解决方案要自己验证，AI给的方向不一定是你具体场景的根因。

---

6. 学新框架 / 快速上手

干什么：你要用一个没用过的库——比如第一次配Zod schema验证，第一次写tRPC路由——让AI给一个最小可运行示例，解释关键概念，讲常见坑。

为什么擅长：这是AI最接近"有经验的同事"的场景。它知道这个框架的入门路径，能用你熟悉的类比解释陌生概念，比你从头读文档要快。

怎么配合：告诉它你已有的背景知识，避免它讲你已经懂的东西。"我熟悉Express，第一次用Fastify，帮我写一个带body验证的POST路由，顺便讲一下和Express写法不一样的地方"——这种带背景的问法比"怎么用Fastify"好得多。

---

需要人盯、不擅长的那些事

下面这些任务，不是说AI一定干不了，而是说：你不能把结果直接拿走用，风险太高或者错误概率太大。需要你深度介入。

---

1. 架构决策

典型场景：要不要引入消息队列？用微服务还是单体？数据库要不要拆库？这些决策影响未来一两年的开发成本。

为什么不擅长：架构决策依赖你的具体约束——团队规模、运维能力、当前流量量级、未来增长预判、技术债现状。AI没有这些信息，即使你告诉它，它也没有在你这个具体项目里"吃过亏"的经验积累。它给的方案通常是"合理的通用答案"，不是"最适合你当下情况的答案"。

怎么配合：用AI做方案调研，让它列出几种方案的权衡对比，但最终判断要你自己做。你的约束条件要亲自检验，不能只听AI的评估。

---

2. 复杂业务逻辑

典型场景：多条件的报销审批流程、涉及多个状态机的订单流转、跨系统的数据同步规则。

为什么不擅长：这类逻辑往往是"说不清楚但大家心里都有数"的东西——产品经理讲了一半，剩下一半靠历史口口相传。AI没有参与过你们的业务历史，它对需求的理解只来自你的描述。描述有一处模糊，生成的逻辑就会有一处偏差，而且你可能短期内发现不了。

怎么配合：先自己把业务规则写清楚——用流程图或文字穷举所有条件分支。这个工作AI帮不了太多，得你来做。规则写清楚之后，再让AI按照规则写代码，这时候它能帮上忙。

---

3. 性能极致优化

典型场景：接口P99延迟要降到5ms以内；GPU矩阵运算要压到某个时延；内存占用要精确控制。

为什么不擅长：极限性能优化需要结合你的运行环境、硬件特性、当前瓶颈的profiling数据。AI可以给你通用的优化方向，但知道你的系统在哪里卡死，还是得你自己测、自己看火焰图。

怎么配合：先自己做profiling，找到真正的瓶颈。把测量结果和代码一起给AI，让它针对你的具体瓶颈提建议，而不是让它猜。

---

4. 安全敏感的代码

典型场景：密码哈希方案、OAuth鉴权流程、SQL注入防护、加解密实现、权限校验逻辑。

为什么不擅长：AI生成的安全代码可能是正确的，也可能有一个不起眼的遗漏，而那个遗漏就是漏洞。安全代码的问题不在于"大方向错"，而在于"一个细节没注意"——比如比较密钥时用了==而不是恒等时间比较，这种东西AI不保证每次都想到。

怎么配合：不要对AI生成的安全代码有任何假设。用成熟的安全库（bcrypt、passport.js、jsonwebtoken）替代自己实现，让AI写调用代码，不要让它自己发明轮子。关键路径要自己审，或者找有经验的人审。

---

5. 新颖算法 / 研究级问题

典型场景：你要针对特定数据分布设计一个新的缓存淘汰策略；或者要用特定约束的图算法解一个没有标准解的调度问题。

为什么不擅长：AI擅长已有模式的重组，对于真正新颖的问题——没有明确已知解法、需要从第一性原理推导的问题——它很容易给你一个"听起来合理但实际错的"方案，而且自信满满。

怎么配合：这类任务先用AI做背景调研和文献整理，但不要直接要它给方案。方案要你自己推导，或者找领域专家。

---

6. 需求本身不清楚

典型场景："做一个用户系统"——就这一句，后面什么都没有。

为什么不擅长：这不是AI的问题，是任何人接到这种需求都会懵。需求模糊，AI会自己做很多假设，生成一个"默认版"用户系统，然后你说这不是你要的。反复返工，效率反而更低。

怎么配合：需求分析这一步得你自己先做。把"用户系统"拆成：用什么注册、存什么字段、角色有哪几种、密码找回怎么走——然后把拆好的需求给AI，它才能给你有用的代码。

---

一张对比表

任务类型	AI表现	适合让AI做	你要做什么
样板代码	好	直接交	核对版本和约束
CRUD增删改查	好	直接交	说清数据模型
代码重构	好	直接交	跑测试验证
写单元测试	好	直接交	检查断言质量
解释报错	好	直接交	自己验证结论
学新框架	好	直接交	带背景知识提问
架构决策	一般	调研对比	判断权衡
复杂业务逻辑	差	规则写清后	自己梳理规则
性能极限优化	一般	给瓶颈后	先做profiling
安全敏感代码	有风险	调用层	必须亲自审
新颖算法	差	背景调研	自己推导方案
需求模糊任务	很差	不建议直接交	先拆清楚需求

---

判断口诀

碰到一个任务，不确定该不该交给AI，用这三问过一遍：

第一问：这件事有没有"标准答案"？ 有的话，AI能做。CRUD、样板代码、测试——答案是收敛的，AI见过太多了。 没有的话，进第二问。

第二问：就算做错了，能不能被你发现？ 能发现（跑测试、看diff、能验证）——可以让AI做，你审。 不容易发现（安全漏洞、架构问题、业务逻辑偏差）——要么自己做，要么深度介入审。

第三问：需求说清楚了吗？ 说清楚了——交给AI。 没说清楚——先把需求搞清楚，再交AI。

三问口诀：**有标准答案、错了能发现、需求说清楚——交。**否则，先盯着。

---

常见问题

Q：AI写的代码出了问题算谁的？

你的。代码一旦进了你的仓库、上了你的线，你就是负责人，不管谁写的。这不是在说别用AI，而是在说：审代码是你不可绕过的责任，不能因为"是AI生成的"就觉得不用看。Claude Code和Cursor都提供diff视图，养成习惯每次都看一遍。

Q：AI越来越强，这些边界以后还成立吗？

部分边界会随着能力提升收窄——比如今天说"需要人盯"的复杂业务逻辑，未来更强的模型可能处理得更好。但有一些边界是结构性的：架构决策依赖你的具体约束，需求分析需要你跟真实用户沟通，安全审计需要你为自己的系统负责——这些不是"AI不够聪明"的问题，是"AI没有你的上下文和责任"的问题。

Q：我只是写写小脚本、做做个人项目，边界也要这么认真搞清楚吗？

个人项目低风险，可以宽松一些——安全和架构那条线可以没那么严。但"需求说清楚"和"错了能发现"这两问无论什么项目都适用，因为这不是安全问题，是效率问题：需求没说清楚，让AI反复生成，浪费的是你的时间。

Q：我提问技巧不好，AI给的结果总不准确，是不是说明AI不适合我这个场景？

先排除提问的问题，再判断场景适合性。很多时候"AI做不了这件事"，其实是"我没把这件事说清楚"。参考这篇文章里的"怎么配合"部分，试着把约束和上下文说得更具体。如果说清楚了还不准，再考虑这件事本身是否适合交给AI。关于如何跟AI有效协作，1.4节有更详细的展开。

Q：AI能做架构图/技术方案的初稿吗？

可以，但要把它当成"有AI帮你起头的草稿"，不是最终方案。让AI列出你正在考虑的几种方案的权衡对比，这个任务它做得不错，因为是已知模式的整理。但"最终选哪个"这一步，你得根据自己项目的真实情况来，不能直接把AI的推荐当决策。

---

搞清楚边界，你才知道在哪里该放心交出去、在哪里该自己死守。不是要你少用AI，是要你用在刀刃上。

边界这张地图看完了，下一步可以去看1.1节：AI编程到底是什么了解工具分级，或者直接看1.3节：Vibe Coding什么时候用、什么时候坑，这两篇和本节一起构成L1认知的基础框架。

---

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。