AI 摘要
What I cannot create, I do not understand
以前我对费曼这句话的理解比较老派：代码你手敲不出来，你就是不懂
但在今天这个大模型满天飞的环境下，似乎有了新的理解：
如果你脑子里没有一张完整的业务闭环和工程蓝图，那你在 AI 面前其实就是在盲开
产品层面的盲区：你连该让 AI 写什么都不知道
很多人产生了一种错觉，觉得有了 AI，自己单枪匹马分分钟就能搓出一个商业级应用
举个最直白的例子：你想做一个 AI SaaS 软件。但如果你自己都没有作为深度用户去体验过优秀的同类产品，你用 AI 生成出来的东西一定会极其可笑
因为你对 SaaS 的业务流根本没有建立起 理解，所以你根本无法向 AI 下达正确的 创造 指令：
- 你只知道让 AI 写个 登录页，却不知道让它写 新手指引，因为你不懂新用户注册后的第一步最容易流失
- 你只知道让 AI 写个 调用大模型 API，却不知道让它设计 Token 计费池和并发限制，结果一上生产环境被人恶意一刷，账单当场爆炸
- 你只知道让 AI 接入 Stripe 支付，却根本不懂怎么处理 Webhook 里的 订阅降级、退款和过期重试，因为你以为支付就是 付钱-开通 这两步，根本不理解 SaaS 订阅制的复杂状态机
这时候费曼那句话就应验了：你自以为在 创造 一个产品，其实你只是用 AI 拼凑了一个根本跑不通商业逻辑的玩具
工程层面的盲区：跑起来之后，灾难才真正开始
退一步讲，就算你把产品逻辑理顺了，让 AI 去写代码。这事儿得看你怎么定义 搞定
能 的部分大家都体会过了：AI 确实能把项目 从 0 到 0.6 的时间压缩得很短。你说一句搞个 FastAPI + React，它立马给你吐出一整套路由、组件、接口。一键跑起来，看着挺像那么回事
但 不能 的部分，往往是从代码跑起来那一刻才真正开始
知乎上有个老哥总结过一个特别典型的 链式翻车 惨案：
- 用户连点两次提交，数据库里莫名其妙多了两条脏数据
- 你让 AI 去修，AI 在前端加了个防抖
- 你想着后端也得兜底啊，让它再加个唯一索引
- 接着为了捕获异常给用户个友好提示，AI 改了返回结构——啪，顺手把其他接口的响应格式全搞崩了
修了三轮之后，这项目就成屎山💩了，每次改动都在赌今天会不会踩雷。那位老哥有一句话说得极为精准：主流程只是 30%。AI 最擅长的就是让你产生 主流程跑通了就万事大吉 的错觉，而真正折磨人的，永远是剩下那 70% 的边缘分支和系统状态
复杂项目难在约束与边界
复杂项目难的从来不是代码量，而是 约束 与 权衡
Nginx 团队的工程师(知乎老哥自称)做过一个很有意思的实验，让 AI 从零糊一个系统级的 C 项目（事件驱动、多线程那种）。结论非常贴近工程现实：AI 砌墙的速度贼快，但它手里根本没有图纸
模块边界在哪？依赖方向怎么理？这些统统得靠人脑子去定
这里面潜伏着一个极其致命的陷阱：看起来一切正常
当你依赖同一个模型去生成实现代码和测试用例时，它们的盲区是完全重合的。测试用例照着错误的假设写，跑出来当然是一片绿灯，但这叫 虚假的成功，就是你 被 AI 骗了。 如果你没有跳出代码之外去 review 和推翻它的能力，你连自己是怎么掉坑里的都不知道
再看个最近发生的例子。青龙面板最近的一个 Issue（#2933）就非常典型：因为鉴权逻辑对路径大小写处理不一致，配合 Express 默认的不敏感策略，像 /aPi/... 这种变体路径居然能直接绕过 JWT 校验，命中实际路由并打到高权限接口
这种坑其实是个特别典型的工程问题。AI 在写接口时，通常只会考虑最理想的执行路径，只要正常请求能跑通就算大功告成。但真实业务里的路由策略、白名单限制、大小写处理，这些需要全局约束的地方，AI 根本照顾不到。它只覆盖 快乐路径（Happy Path），稍微变个形的异常请求，它根本想不到去防
这句话放到今天到底指什么
我现在觉得，它指的早就不是 你得手写每一行代码 了
它的真正意思是：你必须具备对整个产品业务和系统工程的绝对掌控力
你想靠 AI 搓出一个真正能上线的商业产品，你敢不敢在发布前回答这几个问题：
- 产品与商业侧：你的核心业务闭环了吗？不管你做的是 AI SaaS 还是社区工具，新手指引、防刷策略和核心资源的消耗控制兜得住吗
- 架构与工程侧：并发一旦上来，用户在核心链路（比如支付或调用大模型）断网了，你的重试、补偿、降级机制和事务边界做好了吗
- 安全与权限侧：默认的接口暴露面有哪些？会不会被变体路径越权访问，甚至被人直接把你后台的高权限 API 拿去当肉鸡
如果你答不上来，那你用 AI 堆出来的这个东西就算能跑，也只是 暂时没死 而已。AI 帮你写得越快，你欠的业务债和技术债就越多
我现在怎么用 AI
AI 该用还是得用，毕竟速度摆在那里。但我现在的心态彻底变了：我是这个产品的产品经理兼架构师，而 AI 只是个手速极快但完全不担责的赛博外包
配合它干活，我现在基本只守着这几套底线：
- 先理清业务流再动手。在连用户路径、核心状态机都没想清楚之前，绝对不盲目让 AI 去生成代码。产品的全景蓝图必须在我自己脑子里
- 核心边界死死握着。鉴权、数据一致性、核心回调处理、资源消耗逻辑，这些决定产品命脉的模块，具体的代码块可以让它去填空，但架构怎么定、边界在哪，必须我自己拍板
- AI 套娃 Review。第一遍生成的代码我绝对不直接合进项目。我会开一个新的 Context，让 AI 去 review：这段逻辑有没有漏洞？高并发下会不会出大问题？用魔法打败魔法，强迫它提升代码质量
- 逼它输出失败模式与对抗性测试。别光给我一坨能跑的代码，直接问它：这个核心接口报错了怎么回滚？主流程测一遍没报错就行了，剩下的时间全拿去测重复提交、越权访问和异常参数，专挑它想不到的死角攻击
工具再强，代码写得再快，一旦产品在半夜挂了，或者业务被人恶意刷爆了，爬起来连服务器擦屁股的终究还是我们自己
最后来看一个梗图
参考链接：
- 知乎：仅凭ai真的能做好复杂项目吗？
- 知乎回答（NGINX 洪志道）：知乎链接
- 微软安全建议：Running OpenClaw safely: identity, isolation, and runtime risk
- 青龙面板鉴权绕过 Issue：#2933
如无特殊说明 《What I cannot create：AI 时代的工程真相》 为博主LIN 原创，转载请注明原文链接为：https://blog.lin03.cn/archives/137/