写接口、搭页面、补测试，头两周的产出速度是手写的两三倍。可项目一进入收尾阶段，问题就冒出来了。免费用户每天 3 次的使用限制被 AI 写成了”3 次免费加 3 次付费抵扣”；一次改 4 个文件，AI 把早先约定的统一错误码忘得干干净净；WebSocket 鉴权漏了来源校验，拿既有 token 就能连。这些坑让我看清一件事：AI 编程工具能显著提升产出，但也有明确的能力边界——上下文窗口有限、对长流程状态把握不准、对业务约束与付费策略理解浅、对外部依赖的接口细节不熟、对性能与安全等非功能性要求缺乏判断。理解这些局限，才知道该把它放在什么位置。
一、AI 编程工具擅长的事
先明确它能干什么，才谈得上”局限”。在总结器项目里，我用它动手做的主要是这些场景：
- 写样板代码：CRUD、配置、测试脚手架；
- 解释代码与文档；
- 重构命名、补全注释；
- 跨语言翻译代码。
这些任务有个共同点：输入输出足够明确，规则基本公开，不依赖项目内部的隐含知识。AI 处理这类活质量稳定，出错也容易发现。所以我的用法是”让它把脏活累活干完，我把精力留给判断”。
二、AI 编程工具不擅长的事
不擅长的部分才是决定项目成败的地方。下面这张表是我把项目里实际翻车的场景一条条整理出来的：
| 场景 | 表现 | 原因 |
|---|---|---|
| 跨文件状态追踪 | 容易漏改 | 上下文窗口有限 |
| 业务约束 | 写错规则 | 不知道内部规则 |
| 性能瓶颈 | 写完不优化 | 不掌握 profiling 数据 |
| 安全细节 | 凭直觉 | 不了解攻击面 |
| 付费/权限逻辑 | 出错率较高 | 合规敏感 |
| 多步骤迁移 | 容易漏步骤 | 流程状态不易保持 |
这类问题的共性是”需要项目上下文或真实环境才能判断”。AI 看不到运行时的数据分布，也读不到我们内部的业务规则，凭概率补全出来的代码表面上合理，实际上可能是错的。现在凡是涉及钱、权限、安全、性能的地方，我都会先过一遍这张表，再决定要不要人工接管。
三、项目中遇到的典型问题
纸上谈兵没意思，我把项目里真正踩过的五个坑列出来，每个都附上当时的处理办法。
3.1 上下文漂移
一次写 4 个文件后，AI 忘了前面定的”统一错误码”。我在 PR review 时才发现，每个文件各写一套错误类型。
对策：把规则写入 .cursorrules，并要求 AI 在每段输出前重读约束。我用的规则文件长这样：
# 全局约定（每次对话必须遵守）
- 统一错误码格式：{ code, message, detail }
- 免费用户：每天 3 次，完全免费，不含付费抵扣
- 涉及鉴权：必须校验来源与 token 归属
- 数据库改动：输出对应 SQL 与执行计划规则文件本身就是普通文本，AI 每次会话都会读取，等于给它装了一块”外置记忆”。注意条目要写得短而明确，描述太长反而容易被忽略。
上下文漂移的本质是模型没有跨会话的持久记忆，窗口一滚动，早期约定就被挤掉了。把规则写进 .cursorrules 之后，规则成了每次对话都会加载的”外部记忆”，错误码不一致这类问题基本没有再犯。
3.2 业务规则误读
AI 把”免费用户每天 3 次”写成了”每天 3 次免费 + 3 次付费抵扣”，但我们的实际语义是”完全免费”。这种语义错位很难在编译期发现。
对策：所有付费/权限逻辑由我手写，AI 只生成脚手架。
这条教训我们印象很深——代码能编译、能跑、测试也能过，业务含义却全错了。后来我定了条规矩：凡是产品文档里明确写过的规则，直接自己写，别让 AI 猜。项目里涉及计费的代码后来全部重写了一遍，代价不小。
3.3 性能假设
AI 写的数据库查询没加索引，又因为 ORM 隐藏了 SQL，导致 staging 压测才发现慢。
对策：要求 AI 输出 SQL 或打印 ORM 翻译，重要查询自己 review 执行计划。
AI 优化性能只能靠常识，比如”该加索引”，但它看不到真实数据量和慢查询日志，写出来的优化经常用错地方。把 SQL 显式输出后，我至少能在压测前发现明显的全表扫描，问题提前暴露，省了一轮返工。
3.4 安全漏洞
AI 写的 WebSocket 鉴权漏掉来源校验，复用既有 token 即可连接，给攻击面留了口。
对策：所有鉴权代码人工审 + 安全清单 checklist。
安全这类事风险很高，交给 AI 要格外谨慎。它不了解我们的网络拓扑和攻击面，凭经验补全的鉴权逻辑经常”看起来对”。从那以后，所有鉴权相关代码一律人工 review，并对着安全 checklist 逐项核对，不再依赖 AI 自查。
3.5 长流程易丢步骤
做用户系统从 SQLAlchemy 1.x 升级 2.0 时，AI 第一轮漏了 relationship 写法，第二轮漏了 back_populates，第三轮才补全。每次都要重新检查。
对策：把”步骤”显式化，AI 每完成一步要求输出一段 diff 摘要。
长流程升级是 AI 高概率漏步骤的场景，因为中间态太多，上下文一长就顾此失彼。把步骤拆开、每步强制输出 diff 摘要之后，漏项能在当轮被发现，不用等全部跑完再统一检查，复查成本降了不少。
四、踩坑背后的根因
复盘这些坑，根因可以归结为四点：
- 模型没有持久记忆：每次会话独立；
- 上下文窗口有限：超过窗口后早期信息会丢；
- 没有真实运行环境：模型无法观察实际行为；
- 业务知识不是公开知识：模型只能从仓库猜。
想清楚根因，很多对策就顺理成章了。比如”没有持久记忆”，就把规则外置成文件；”没有运行环境”，就把 SQL、执行计划这类真实观测结果喂给它。与其抱怨 AI 不聪明，不如把项目环境补到它面前，让它少猜。
五、可复用的协作模式
踩过的坑汇总之后，我沉淀出一套协作分工，按任务类型决定谁主导：
| 任务类型 | 协作模式 |
|---|---|
| 样板代码 | AI 写，工程师命名与 review |
| 复杂业务 | 工程师拆分任务，AI 实现单步 |
| 性能优化 | 工程师定方案，AI 改实现 |
| 调试 bug | 工程师定位，AI 写测试 |
| 文档 | AI 写初稿，工程师修正 |
这套分工的核心原则是”判断留给人，执行留给 AI”。任务越靠近业务核心，人的介入越深。现在新功能进来，我先按这张表分配，再不用纠结某个活该不该给 AI。
六、流程与规范
光有分工还不够，得靠流程兜住。我们项目组定了几条硬规矩：
- 重要模块 review 清单：性能、安全、付费、可观测性、错误处理；
- AI 写的代码必须有单元测试；
- 不让 AI 直接改 CI/CD、生产配置；
- 关键 PR 强制第二人 review。
几条规范里，”单元测试必须有”这条性价比偏高。AI 代码语法没问题，但逻辑对不对，测试跑一遍比人眼看可靠。而 CI/CD 和生产配置不让 AI 碰，是为了守住发布链路这条底线，配置写错一次，影响的可能是一整片环境。
七、未来值得期待的改进
局限不是静止的，工具迭代很快，我关注的方向有几个：
- 多文件编辑一致性提升；
- 对仓库结构的长期记忆；
- 与 CI 工具联动，自动跑测试后再让 AI 修；
- 私有业务知识接入（企业内部知识库 + RAG）。
其中”私有业务知识接入”尤其值得期待。一旦 AI 能读到我们内部的规则文档和知识库，3.2 里那种业务规则误读就有望大幅减少。不过在那之前，我还是会守着”判断留给人”这条原则。
常见问题（FAQ）
Q1：AI 编程工具会取代程序员吗？
短期内不会。它替代的是”写样板”的时间，复杂业务仍需人主导。
Q2：AI 写的代码能直接上生产吗？
不能。至少要经过 review、测试、压测三道关。
Q3：怎样让 AI 输出更稳定？
把规则写进 .cursorrules，并把任务拆成 1–2 步的小块。
