这是「成为 AI Native Builder」连载的第 1 篇，全系列目录见文末。
哈喽，我是 lv。
先说一下近况。
我现在在一个 AI Native 团队，岗位是需求交付工程师。
简单说就是：接到一个需求，它可能清晰，也可能模糊，然后由我 + AI 交付一个需求的完整闭环。
比如你看到的：canvasagents.dev/ 这个产品也是我一个人 + AI 搞定的一个产品，包括从需求梳理、产品设计、UI/UX、全栈研发、测试验收、部署上线运维、运营宣发等。
我更愿意把这个角色叫做：AI Native Builder。
这段时间，我把一路踩过的坑、总结出来的方法，整理成了一本《成为 AI Native Builder》小册。
总共 9 篇，接下来，我会在这里逐篇开源连载。
这一篇是开篇，先聊一个几乎每个用 AI 的人都遇到过的问题～
两种体验
同样用 AI，有人能稳定交付，有人在「生成 → 不对 → 再生成」里打转。差别不在 AI，在人。
有同学用 AI 的时候可能是这种体验：
一个需求丢给 AI，过一会儿就交付了，质量还不错，上线也没出什么事，就算有什么 bug 也能快速地修复。
但是也有的同学是这样子的：
-
让它做个功能，它很快就写完了，一跑，不是自己要的；
-
你补充说明，它改了，又把另一个地方改坏了；
-
来回几轮，你开始怀疑：AI 是不是没那么聪明？
-
最后你自己上手改，心里嘀咕：还不如我自己写。
-
一旦出了问题要改 bug 的时候，效率就更低了。
尽管 AI 生成的很快，但是感觉交付不稳，而且反复返工。
算下来，效率并没有想象中那么高，甚至还要给它擦屁股，背黑锅。
问题不在 AI 不够聪明
同一个模型，在不同的人手里，交付质量差别很大。
所以问题大概率不在模型。
AI 很强，但它是一个概率模型，没有人能保证它百分之百把一个需求做对。
模型越来越强，只能说明它出错的概率越来越小，不代表它不会出错。
既然它一定会出错，真正的问题就变成了三个：
1. 你知道什么是对的吗？
如果你自己都说不清这个需求做到什么样算对，AI 只会做得更乱。
2. 你怎么知道它做对了？
它说"做完了"，你信吗？凭什么信？
3. 它做错了，你接得住吗？
上线之后出了问题，你能多快发现、定位、修复？修不了，能不能回滚？
能稳定交付的人，未必有意识地这样想过，但他们的做法，一定回答了这三个问题。
答不上来的人，就会一直陷在返工里。
带着上面这三个问题，我们下面来介绍一下「成为 AI Native Builder」这个系列。
这个系列要聊什么
我把这三个问题整理成一套可以复用的方法论，我叫它 AI Native 交付质量三角模型：定义正确、验证正确、失败可恢复。
围绕它，小册分三部分：
-
是什么：AI Native Builder 是一个什么样的角色？「AI 原生」到底原生在哪里？
-
为什么：AI 的能力已经走到了哪一步？为什么人人都在用 AI，团队却没变快？应届生卷不过 AI，资深程序员反而像老中医？
-
怎么成为：一个保证 AI 交付质量的模型，加上一个真实的实战案例，把成为 AI Native Builder 的两条路说清楚。
以上三部分就是整个系列的主题，我不太想聊用 AI 写代码能有多快，速度现在已经不稀奇了。
我更想聊的是：怎么让 AI 交付出来的东西，稳定地对。
写在最后
如果你也在用 AI 干活，也遇到过返工，希望提升 AI 交付的质量，这个系列应该能帮你理一理思路。
下一篇，我们从一个定义开始：到底什么是 AI Native Builder？ 一个人 + AI，真的能把原本一整个团队的活干完吗？
「成为 AI Native Builder」连载目录
- 开篇：为什么 AI 总在返工？（本篇）
- 什么是 AI Native Builder：一个人 + AI，交付完整闭环
- 真正意义上的 AI 原生，原生在哪里？
- 人人都在用 AI，团队为什么没变快？
- 应届生卷不过 AI，资深程序员像老中医
- 怎么保证 AI 的交付质量：AI Native 交付质量三角模型
- 实战（上）：一句话，让 AI 做出一个产品演示官网
- 实战（下）：从 0 到 1 做一个产品官网，我迭代了 5 轮
- 收官：成为 AI Native Builder 的两条路
觉得有用的话，点个赞、收藏一下；关注我，连载更新会第一时间推送给你。