一、引子：AI 开发时代的"新常态"
上周和一个朋友聊天，他问我："你现在写代码还用不用 AI？"
我说："用啊，但和一年前完全不一样了。"
一年前，AI 对我的意义是"写一段代码就跑去问 ChatGPT"。现在，AI 贯穿了我开发的每一个环节——从需求分析到代码生成，从测试到代码审查，再到部署监控。不是 AI 替代了我，而是我学会了在每个环节让 AI 做它擅长的事。
这篇文章不讨论哪个工具最好，也不给一堆空泛的"AI 改变世界"说教。我想分享的是我过去半年真正在用的开发工作流——每一步怎么用 AI 提效，哪些环节最适合让 AI 介入，哪些必须自己拍板。
二、需求分析阶段：AI 帮你理清思路
很多人以为 AI 写代码才是提效，但我觉得 AI 最大价值出现在写代码之前。
2.1 需求模糊时，让 AI 帮你追问
每次接到一个模糊的需求，我现在的流程是这样：
- 把原始需求扔给 Claude，让它列出"做这件事需要明确的问题清单"
- 针对每个问题，让 AI 给出 2-3 个候选方案和各自的 trade-off
- 我选一个方向，AI 帮我细化成具体的技术方案
比如有次产品说"给后台加个搜索功能"，我让 Claude 追问了 8 个问题：
| 维度 | 问题 |
|---|---|
| 搜索范围 | 全文搜索还是字段匹配？跨表还是单表？ |
| 性能要求 | 预期数据量多大？是否需要实时索引？ |
| 排序规则 | 按相关性、时间还是自定义权重？ |
| 技术栈约束 | 能用 ES 还是只能用 MySQL LIKE？ |
这些问题看似简单，但每次自己从头想总会漏掉一两个，上线才发现"哦，忘了问这个"。
2.2 技术方案文档自动生成
需求明确后，我会让 AI 根据讨论结果生成一份技术方案草稿：
# 技术方案：后台搜索功能 v1.0
## 选型
- 短期：MySQL FULLTEXT INDEX（数据量 < 100 万）
- 长期：预留 Elasticsearch 迁移方案
## 接口设计
GET /api/search?q={keyword}&page={page}&size={size}
## 数据流
用户输入 → 分词 → 索引查询 → 结果排序 → 返回
## 风险点
1. 大数据量下 MySQL 全文索引性能问题
2. 中文分词准确率依赖配置
这个草稿我修改 15 分钟就能定稿，比从零写省了至少 2 小时。
三、编码阶段：AI 是你的结对编程搭档
编码阶段是我用 AI 最多的地方，但踩的坑也最多。
3.1 代码生成的正确姿势
我现在的编码工作流分三层：
第一层：脚手架代码全交给 AI
- 新建 API 端点、数据模型、基础 CRUD
- 这种代码模式固定，AI 几乎零失误
第二层：业务逻辑让 AI 写初版，我改
- 把需求描述 + 接口签名给 AI
- 拿到代码后检查边界条件和异常处理
- 这一步通常能省 60% 的编码时间
第三层：复杂逻辑自己写，AI 做 review
- 涉及核心算法、事务一致性、并发控制
- 自己写完后交给 AI review，让它找遗漏
3.2 Prompt 技巧
和 AI 配合写代码，最关键的技巧是给足上下文：
# 不好的 prompt
"帮我写个用户注册接口"
# 好的 prompt
"帮我写一个用户注册接口：
- 框架：FastAPI
- 数据库：PostgreSQL + SQLAlchemy
- 字段：username, email, password（bcrypt 加密）
- 校验：邮箱格式、密码强度（≥8位含大小写+数字）
- 返回：201 + user_id，重复邮箱返回 409"
第二个 prompt 生成的代码我基本不需要改，第一个至少要迭代 3 轮。
3.3 AI 生成代码的常见坑
| 坑 | 表现 | 对策 |
|---|---|---|
| 幻觉 API | 用了不存在的库或方法 | 让 AI 注明每个 API 的来源版本 |
| 忽略错误处理 | 只写了 happy path | 要求 AI 列出所有异常场景 |
| 安全漏洞 | SQL 注入、XSS | 每次生成后加一轮 security review |
| 过度抽象 | 为了"可扩展"堆了 5 层继承 | 要求 YAGNI（你不会需要它） |
四、测试阶段：AI 驱动自动化测试
测试是最适合 AI 发挥的环节——因为测试代码模式化程度高，但人写起来最烦。
4.1 单元测试自动生成
我现在写完一个函数后，会直接让 AI 生成测试用例：
def calculate_discount(price: float, user_level: str) -> float:
"""
根据用户等级计算折扣价
- 普通用户：无折扣
- VIP 用户：9 折
- SVIP 用户：8 折，且满 100 再减 10
"""
discounts = {'vip': 0.9, 'svip': 0.8}
level = user_level.lower()
final = price * discounts.get(level, 1.0)
if level == 'svip' and price >= 100:
final -= 10
return round(max(final, 0), 2)
AI 会生成的测试覆盖：
- 正常路径：三个用户等级各一个
- 边界值：价格 0、价格 99.99、价格 100
- 异常：未知等级、负数价格
- 特殊字符：大小写混写
我需要做的就是检查测试逻辑对不对，然后 pytest 跑一遍。
4.2 AI 帮你"找到"你没测到的
更进阶的用法是让 AI 做**变异测试（mutation testing）**的简化版：让 AI 修改你的代码逻辑（比如把 > 改成 >=，把 and 改成 or），然后看测试能不能抓到。抓不到的，就是你的测试盲区。
五、代码审查阶段：AI 做第一道防线
代码审查是团队开发中最花时间的环节之一。AI 不能替代人的审查，但它可以当"第一道筛子"。
5.1 AI Code Review 清单
我会让 AI 在每次 PR 提交后自动检查以下维度：
| 维度 | AI 能做的 | 必须人看的 |
|---|---|---|
| 代码风格 | eslint/prettier 规则 | — |
| 安全漏洞 | SQL 注入、XSS 模式 | 业务逻辑安全 |
| 性能问题 | N+1 查询、循环中发请求 | 架构级性能 |
| 测试覆盖率 | 哪些行/分支没覆盖 | 测试质量 |
| 命名规范 | 统一命名风格 | 领域术语准确性 |
5.2 实际流程
# 提交 PR 后，自动触发
claude code review --diff "main..feature/xxx"
# AI 输出类似：
## Review Summary
- 🔴 严重：第 42 行有 SQL 拼接风险，建议用参数化查询
- 🟡 建议：第 78 行循环中调用了外部 API，考虑批量处理
- 🟢 优化：第 15 行的变量命名 `data` 过于泛化，建议更具体
开发者先修 AI 发现的问题，再提交给人审查。这一步能减少 50% 以上的 review 轮次。
六、部署与运维：AI 监控与排错
部署环节 AI 的价值不在于"自动部署"（CI/CD 早就能做了），而在于排错和根因分析。
6.1 日志分析的 AI 辅助
生产环境出问题时的传统流程：
- 翻日志 → 2. 找关键词 → 3. 猜原因 → 4. 修复
AI 辅助后的流程：
- 把报错日志贴给 Claude → 2. 它能直接指出根因并给出修复建议
# 原始错误日志
Error: ENOENT: no such file or directory, open '/app/config/prod.json'
Error: Cannot read properties of undefined (reading 'database')
# AI 给出的分析（15 秒内）
根因：配置文件 /app/config/prod.json 不存在
可能原因：
1. Docker 镜像未包含配置文件
2. 挂载卷未正确映射
3. 环境变量 CONFIG_PATH 指向了错误路径
建议修复：
- 检查 Dockerfile 中 COPY 配置的路径
- 确认 docker-compose.yml 的 volumes 配置
这个场景我实测过：人肉翻日志平均 20 分钟找到根因，AI 不到 30 秒。
6.2 监控告警的智能降噪
AI 还能做告警聚合。当 50 个告警同时触发时，AI 能告诉你"这 50 个告警都是同一个根因——数据库连接池满了"，而不是让你从 50 封邮件里一个个看。
七、总结：新的工作流范式
回到开头那句话：AI 没有替代我，但它改变了我做事的每个环节。
几个关键经验：
- 分清楚 AI 擅长的和自己擅长的 — 模式化工作交给 AI，决策和判断自己来
- 上下文比提示词更重要 — 给 AI 足够的上下文，它给你的东西质量翻倍
- 把 AI 当实习生，不是当大神 — 它写的代码你要 review，它给的建议你要思考
- AI 工作流需要刻意练习 — 用 3 天可能觉得效率没变，用 3 个月回不去了
如果你现在还在"写一段代码问一次 ChatGPT"的阶段，试试把 AI 嵌入到你的完整工作流里。三周后你会发现自己回不去了。
觉得有用的话点个赞 👍，欢迎在评论区分享你的 AI 开发工作流！
