夜雨聆风上周一个同事跑来找我，一脸挫败感。
他说："你不是说 TRAE 很好用吗？我让它帮我做性能优化，给我扯了一堆废话，最后还把代码改坏了。"
我问他怎么问的。
他说他直接问：「帮我优化这个系统的性能」，然后把整个项目扔进去了。
我沉默了三秒。
这不是 AI 的问题，这是他对 AI 的认知出了问题。
很多人对 AI 编程工具有两种极端
一种人觉得它什么都能做，把整个系统扔进去，期待 AI 自动帮你"优化"；
一种人觉得它是个玩具，写出来的代码全是废话，干脆不用。
这两种都是误区。
今天我们来好好聊一件事：AI 编程工具，到底能干什么，又真的干不了什么。
搞清楚这个，你才知道怎么用它把效率最大化，而不是一直在踩坑。
先说它能干什么
TRAE、Cursor 这类工具，本质是"有代码上下文的 AI 对话"。它们真正擅长的，是这几类任务：
1. 生成模板代码，快准狠
你说"帮我写一个 Spring Boot 的分页查询接口，参数有关键字和页码"，5 秒钟给你一个可运行的接口，Controller、Service、Mapper 全套。
这种重复度高、模式固定的代码，它比你手写快 10 倍。
2. 解释代码，比文档好用
接手一段老代码，看不懂某个正则或者位运算？
把代码丢给 AI，说"帮我解释这段代码在做什么，用大白话"，它能给你逐行解释，比去查 Stack Overflow 快得多。
3. 定向修改，精准改完不乱
"帮我把这个方法里的 for 循环改成 Stream 写法""把这里的硬编码改成读配置文件"——这种目标明确的改动，它做得又快又稳。
4. 写注释和文档
最被程序员嫌弃的活，AI 最爱干。一个方法 10 秒出注释，一个接口 30 秒出 JavaDoc，你不想写，它帮你写。
5. 排查错误，给出方向
把报错信息和相关代码一起扔给它，它通常能快速指出问题所在。不是每次都准，但 7 成情况都能给你一个正确的排查方向。
再说它真的做不了什么
这才是今天的重点。很多人在这几件事上踩坑，然后开始觉得"AI 没用"。
① 它没法替你做架构决策
"帮我设计一个高并发订单系统的架构"——它能给你一个方案，但这个方案好不好，适不适合你的业务，只有你自己知道。
AI 不了解你的流量规模、团队能力、历史债务、公司预算。它给出的方案是教科书式的，不是为你量身定制的。
架构决策是你的事，AI 只能给你选项，判断是你的。
② 它没法理解业务上下文
"帮我优化这段订单处理逻辑"——它看不懂"金额溢出要走退款流程"这种业务规则，也不知道你们的"库存预占"是什么意思。
业务逻辑是隐性知识，写在文档和代码注释里的只是一部分，更多的在人脑子里。AI 拿不到，就没法真正理解。
它能改代码的形式，但改不了业务的正确性。
③ 它没法做全局性能优化
这就是我同事踩的那个坑。
性能问题通常藏在：慢 SQL、不合理的缓存策略、第三方服务超时、GC 调优……这些需要真实的监控数据、压测数据、线上日志，AI 没有这些数据，它只能靠猜。
你告诉它"查询很慢"，它给你的方案可能是加索引，但如果真正的问题是 N+1 查询，加索引一点用没有。
性能优化要先定位，定位靠数据，数据在你手里，不在 AI 手里。
④ 它没法保证代码安全
让 AI 写权限校验、加密逻辑、SQL 防注入——它能写，但你必须自己 Review。
它见过很多"写了但其实有漏洞"的代码，也可能生成同款。安全问题一旦上线，代价是你承担，不是 AI 承担。
涉及安全的代码，AI 只能是参考，不能是答案。
⑤ 它没法持续跟进一个复杂任务
"帮我把这个 20 个类的模块完整重构一遍"——它会尝试，但很快就会失控：前面改的和后面改的开始冲突，命名不统一，漏改了几个地方，最后烂摊子比原来更乱。
AI 没有持久的工作记忆，它能管好一个窗口里的事，管不好跨越多次会话、多个文件的大任务。
大任务要拆，每次给它一块，验收完再给下一块。
一张表说清楚
| 任务类型 | 适合用 AI？ | 备注 |
|---|---|---|
| 写模板代码 / CRUD | 强烈推荐 | 最适合，省时省力 |
| 解释代码 / 看懂老代码 | 强烈推荐 | 比查文档好用 |
| 写注释 / JavaDoc | 强烈推荐 | 它最爱干这个 |
| 定向改一段代码 | 推荐 | 目标要具体 |
| 排查报错 | 推荐 | 要带上错误信息 |
| 写单元测试 | 推荐 | 快速补测试覆盖 |
| 架构设计 | 辅助参考 | 决策权在你 |
| 业务逻辑实现 | 部分适合 | 要给足业务背景 |
| 性能优化 | 谨慎 | 先自己定位问题 |
| 安全相关代码 | 必须人工审查 | 不能直接用 |
| 整体大模块重构 | 拆小再用 | 一次给一小块 |
所以，AI 会取代程序员吗？
我的判断是：取代不了那些真正理解业务、能做判断的程序员。
AI 能替代的，是那些只会"按需求写代码、不思考、不决策"的执行角色。
但会用 AI 的程序员，可以用更少的时间干更多的活。这才是竞争力的分水岭——
不是"你的代码 AI 能不能写"，而是"你能不能比别人更快地把一件事做对"。
我同事那个例子，问题不在 AI，在于他把架构级的决策扔给了一个工具。就像你不会让实习生"自己决定系统怎么设计"一样，工具就是工具，边界摆清楚，才用得好。
说到底，AI 编程工具改变的不是"程序员这个职业"，而是"程序员完成任务的方式"。
搞清楚边界，把对的事情交给它，把需要判断的事情留给自己——这才是用好 AI 工具的正确姿势。
你用 AI 工具踩过什么坑？或者发现过什么意想不到的用法？
欢迎在评论区聊聊，我每条都看。
觉得有用的话，转发给你身边还没用上 AI 工具的同事——他们可能比你更需要这篇文章。
——VibeCoding大爆炸，持续分享 AI 编程的真实经验
