什么时候该让 AI 写，什么时候自己写
不是所有代码都适合交给 AI，也不是所有代码都值得自己手写
判断原则
我的判断标准很简单：AI 写完我需要花多长时间 review。如果 review 时间 < 自己写的时间，让 AI 写；如果 review 时间 > 自己写的时间，自己写。
这个标准听起来废话，但实际执行时很多人会犯一个错——只算"写代码"的时间，不算"调试 AI 写的代码"的时间。AI 生成的代码 80% 情况下能跑，但那 20% 的边界情况才是真正吃时间的。
让 AI 写：确定性高、模式固定
| 场景 | 为什么适合 AI | 我的实测 |
|---|---|---|
| CRUD 接口 | 模式固定，FastAPI + SQLAlchemy 的套路代码 | FinBuddy_Web 的 12 个 CRUD 接口，AI 写了 10 个，review 5 分钟搞定 |
| 数据转换/序列化 | 输入输出明确，Pydantic model 互转 | FinBuddy 的数据层 schema 转换，AI 一次生成 200 行，改了 3 行 |
| 配置文件/样板代码 | 结构固定，填参数就行 | Dockerfile、nginx 配置、CI 脚本，AI 写的比自己查文档快 5 倍 |
| 单元测试 | 给定函数签名，测试用例模式化 | 但要注意：AI 生成的测试经常只覆盖 happy path，边界条件还得自己补 |
| 正则表达式 | AI 写正则比人靠谱，人写正则容易漏边界 | 解析通达信数据格式的正则，AI 一次写对，我自己写调了半小时 |
自己写：边界复杂、影响面大
| 场景 | 为什么不适合 AI | 我的教训 |
|---|---|---|
| 认证/授权逻辑 | 安全敏感，一个边界条件漏了就是漏洞 | FinBuddy_Web 的 JWT 刷新逻辑，AI 写的版本没处理 token 过期但 refresh_token 还有效的窗口期 |
| 并发控制 | 竞态条件多，AI 很难考虑到所有时序 | Basic_Web 的分布式信号量，AI 生成的版本在高并发下会超发，必须自己加原子性检查 |
| 状态机/流程引擎 | 状态转换有隐含约束，AI 容易漏转换条件 | FinBuddy 的意图解析器有 7 种执行模式，AI 生成的路由逻辑漏了 2 种模式间的互斥关系 |
| 性能敏感的热路径 | AI 不关心性能，生成的代码经常有冗余计算 | K 线数据批量处理，AI 版本比手写版慢 3 倍——每条记录都创建新对象而不是复用 |
| 跨模块重构 | AI 看不到全局依赖，改一处漏三处 | FinBuddy 从 7 个 Agent 砍到 3 个，这种架构级重构 AI 根本帮不上忙 |
灰色地带：先让 AI 出草稿
有些场景不是非黑即白。我的做法是：让 AI 出第一版草稿，然后自己重写关键部分。
比如 FinBuddy 的 Swarm 编排引擎，AI 写了整体框架，但意图解析的路由逻辑我自己重写了——因为只有我知道 7 种执行模式之间的优先级和互斥关系。AI 写的版本看起来完整，但跑起来会在边界情况下选错模式。
这种"AI 出草稿 + 人重写关键路径"的工作流，比纯手写快 40%，比纯 AI 靠谱 10 倍。