AI Coding 的局限与边界
清醒认识 AI 不能做什么，和知道它能做什么一样重要。
总览：AI Coding 的能力边界
完全胜任 │ 需要辅助 │ 不建议使用
────────────────────────────────────
┌─────────┬──────────┬──────────┐
代码生成 │ │ │ │
├─────────┼──────────┼──────────┤
架构决策 │ │ │ │
├─────────┼──────────┼──────────┤
业务理解 │ │ │ │
├─────────┼──────────┼──────────┤
└─────────┴──────────┴──────────┘不适合使用 AI Coding 的场景
1. 关键安全代码
markdown
场景
- 支付处理
- 权限认证
- 数据加密
- 金融计算
## 原因
- 错误代价极高
- AI 可能引入漏洞
- 需要专业安全审计
## 替代方案
- 人工编写
- AI 辅助生成候选方案
- 严格安全审查2. 全新架构决策
markdown
场景
- "我们用什么前端框架？"
- "微服务还是单体？"
- "数据库选型"
## 原因
- 涉及业务、团队、组织
- AI 缺乏深度上下文
- 决策影响长远
## 替代方案
- 团队讨论
- 参考行业实践
- AI 辅助收集信息3. 复杂业务规则
markdown
场景
- 复杂的领域逻辑
- 多状态机的状态转移
- 涉及法律法规的逻辑
## 原因
- 业务规则细节 AI 不知道
- 法规要求不能由 AI 决定
- 错误后果严重
## 替代方案
- 业务专家设计
- AI 辅助实现（已有规则）
- 严格测试 + 业务验证4. 高性能优化
markdown
场景
- 关键路径性能优化
- 算法优化
- 内存优化
## 原因
- 需要运行时验证
- AI 缺乏性能直觉
- 优化空间需人工探索
## 替代方案
- 性能分析（Profiler）
- 人工优化关键路径
- AI 辅助生成候选5. 像素级 UI 还原
markdown
场景
- "严格按照 Figma 设计稿实现"
## 原因
- AI 视觉理解有限
- 像素级精度难达成
- 设计细节 AI 容易遗漏
## 替代方案
- 人工实现关键 UI
- AI 辅助布局
- 设计 Token 化6. 复杂的动画与交互
markdown
场景
- 复杂的 CSS 动画
- 复杂的物理交互
- 游戏化效果
## 原因
- 需要反复调参
- 视觉效果需人工判断
- 性能与效果平衡
## 替代方案
- 参考开源实现
- 人工调优
- AI 辅助微调7. 法律敏感的代码
markdown
场景
- 用户协议相关
- 数据合规相关
- License 相关
## 原因
- 法律问题需专业人士
- AI 不能提供法律建议
- 错误可能导致法律风险
## 替代方案
- 法务审核
- 标准库/模板
- 谨慎处理8. 极端复杂算法
markdown
场景
- 复杂的数学算法
- 底层系统算法
- 大规模并发控制
## 原因
- AI 容易产生"看起来对"的算法
- 难以验证
- 出错代价高
## 替代方案
- 参考学术论文
- 人工设计
- 充分测试AI 的"软肋"
软肋 1：缺乏"业务直觉"
typescript
// AI 写的代码
function calculateUserDiscount(user) {
if (user.level === 'gold') return 0.2
if (user.level === 'silver') return 0.1
return 0
}
// 业务实际：
// - gold 用户在特殊节日额外 5%
// - silver 用户首单 8%
// - 注册 30 天内所有用户 +5%
// - VIP 推荐的用户额外折扣
// 这些 AI 不知道软肋 2：缺乏"品味"
typescript
// AI 写的代码可能"正确但丑"
function fetchUserDataAndProcessAndDisplay(userId) {
// 一长串函数
}
// 优秀开发者会拆分
function useUser(userId) {
const user = useUserData(userId)
const processed = useProcessedUser(user)
return useUserDisplay(processed)
}软肋 3：缺乏"判断"
什么值得做、什么不值得做？
什么该简化、什么该保留？
哪些是临时方案、哪些是长期方案？
这些 AI 都不能替你判断。软肋 4：缺乏"创新"
颠覆性创新通常来自对业务的深度理解 + 跨界思考。
AI 能组合已有方案，但很难创造全新方案。AI 擅长的场景（再次明确）
为了平衡，也明确 AI 擅长的：
模板代码
typescript
// AI 极擅长
- CRUD 组件
- 表单组件
- 列表组件
- API 客户端
- 类型定义
- 路由配置模式化代码
typescript
// AI 极擅长
- 按既有模式扩展
- 按规范补全
- 重复样板代码文档与注释
markdown
// AI 极擅长
- JSDoc
- README
- API 文档
- 注释简单重构
typescript
// AI 极擅长
- 变量改名
- 函数提取
- 文件拆分测试编写
typescript
// AI 较擅长
- 单元测试
- 组件测试
- 边界测试AI 与人的协作边界
┌─────────────────┬────────────────┐
│ AI 主导 │ 人主导 │
├─────────────────┼────────────────┤
│ 模板代码生成 │ 架构决策 │
│ 简单重构 │ 业务规则设计 │
│ 文档生成 │ 复杂调试 │
│ 测试编写 │ 性能优化 │
│ 简单 Bug 修复 │ 安全审计 │
│ 代码补全 │ 选型决策 │
└─────────────────┴────────────────┘何时不用 AI Coding
判断准则
markdown
## 不用 AI 的 5 个问题
1. 错误代价是否极高？
→ 是：不用或极谨慎
2. 是否涉及业务核心逻辑？
→ 是：人主导
3. 是否需要深度业务理解？
→ 是：人主导
4. 是否需要创新性方案？
→ 是：人主导
5. 是否需要专业判断？
→ 是：人主导
如果 3 个以上回答"是"，完全不用 AI Coding。实战判断
markdown
## 案例
### 案例 1：支付回调处理
- 错误代价：极高
- 业务深度：很深
- 判断：完全不用 AI，人工编写
### 案例 2：CRUD 列表组件
- 错误代价：低
- 业务深度：低
- 判断：AI 主导，人审查
### 案例 3：复杂表单校验
- 错误代价：中
- 业务深度：中
- 判断：AI 生成，人审查校验逻辑
### 案例 4：架构选型
- 错误代价：高
- 判断：人主导，AI 辅助收集信息
### 案例 5：性能优化
- 错误代价：中
- 判断：人主导，AI 辅助实验团队如何处理"边界"
建立"红绿灯"机制
markdown
## AI Coding 红绿灯
### 绿灯：AI 主导
- 模板代码
- 简单 CRUD
- 文档生成
- 测试编写
- 简单重构
### 黄灯：AI 辅助，人主导
- 业务逻辑
- 中等重构
- Bug 修复
- 性能优化
### 红灯：禁用 AI
- 支付/权限/安全
- 架构选型
- 合规相关
- 全新创新团队规范
markdown
## 团队 AI 使用边界
### 必须人工
- 所有支付相关代码
- 所有权限/认证代码
- 所有密钥管理代码
- 所有 .env / 配置变更
- 所有 CI / 部署配置
- 所有 package.json 依赖变更
### AI 辅助（需审查）
- 业务逻辑代码
- 复杂组件
- 重构
### AI 主导
- 模板代码
- 简单组件
- 文档
- 测试心理层面的边界
AI 不是万能的
"AI Coding 不是银弹，不能解决所有问题。"
"AI Coding 是放大器：好的实践放大，坏的实践也放大。"人的价值
"在 AI 时代，人的价值不在于写代码的速度，
而在于判断、决策、品味、业务理解。"持续学习
"AI Coding 在快速演进，今天的局限明天可能解决。
但今天不能做的，今天就别勉强。"总结
知道 AI 做不到什么，比知道它能做到什么更重要。
- 红绿灯机制
- 关键代码人主导
- AI 是辅助不是替代
- 不要"AI 万能论"
下一节：未来趋势