什么规模的项目不适合用 AI 写

我给烧烤店做那个小程序的时候，全项目手写的代码不到 20 行，其余都是 AI 生成的，客户验收通过，收了 ¥3000。同一时期我另一个单人小工具，我坚持自己写。什么规模的项目不适合用 AI 写，我的判断不看代码量，看两件事。

什么规模的项目不适合用 AI 写：看寿命，不看规模

判断标准是这个项目要活多久和出错谁来兜。

活得短、错了无所谓的，规模再大也能交给 AI。

活得长、错了要赔钱的，哪怕只有两百行，也得自己盯着。

两类项目的对比

| 维度 | 适合用 AI 写 | 不适合用 AI 写 |

|---|---|---|

| 生命周期 | 一次性、用完即弃 | 长期维护、持续迭代 |

| 出错代价 | 重跑一遍就行 | 涉及收钱、数据、对外服务 |

| 需求稳定性 | 需求清晰，规则固定 | 需求还在变，规则没人说得清 |

| 技术栈熟悉度 | 你熟，能一眼看出问题 | 你没做过，看不出对错 |

| 团队交接 | 只有你自己用 | 后面还有人要接手 |

| 典型例子 | 数据清洗脚本、内部工具、样板页 | 付费逻辑、权限系统、核心对账 |

注意最后一行：决定因素不是行数，是这几行的位置。

哪些规模的项目其实很适合

比想象中多。

几百行的一次性脚本、后台内部页面、数据迁移程序、格式转换工具——这些交给 AI 效率高得离谱。

我内容生产里的封面和稿件批处理，基本都属于这一类，写坏了重跑就行。

判断口径很简单：这个项目挂了，损失是不是「重来一次」？ 是的话，放心交出去。

哪些小项目反而不能交

我列三类：

一类是钱。付费、退款、对账、分账，任何一处算错都是真金白银。

一类是权限。谁能看什么、谁能改什么，写错了不会报错，但会出事。

一类是数据迁移。跑错一次，原始数据可能就没了。

这三类的共同点是：错误不会在运行时暴露，只会在事后暴露。 而事后往往已经来不及。

还有一种情况：不是项目不适合，是你现在不适合

如果你完全不懂这个技术栈，那这个项目再小也不适合交给 AI。

原因不是 AI 写得差，是你没有验收能力。

这种时候的替代方案是：让 AI 写一个最小可运行的例子，你把它读懂、改几遍，再决定要不要继续。

我的选择与理由

我的项目基本拆成两层。

外层是效率层：内容处理、脚本工具、内部页面、模板，AI 全包。

内层是责任层：涉及收款、涉及用户数据、涉及第三方对账的部分，我自己写骨架，AI 只填实现。

我操盘过月流水 2000 万的卡牌项目，那套系统里的对账逻辑，放到今天我也不会整个交给 AI。

这个划分不是能力问题，是责任问题。 谁能承担后果，谁就该拿决定权。

常见问题

Q：什么规模的项目不适合用 AI 写？

A：跟代码量没关系。长期维护、出错要赔钱、涉及收钱和用户数据的项目不适合放手，哪怕只有两百行。

Q：小项目是不是可以随便让 AI 写？

A：看错误类型。挂了重跑一次就行的，随便写；写错了事后再也补不回来的，再小也要自己盯。

Q：不懂的技术栈能用 AI 写项目吗？

A：不建议直接做项目。可以先让它写最小示例，你读懂改会了再动手，否则你没有验收能力。

相关阅读

• AI 写业务逻辑为什么总漏，我找到 3 个原因
• AI 写代码会偷偷改坏别处吗，我吃过一次
• AI 写代码的边界在哪，3 个信号说明它在猜
• AI 写的代码能直接上线吗，我过 5 道关
• AI 编程适合新手还是老手，看这两个场景

本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。