我们怎么交付
一个人 + AI，为什么能做完一个团队的活
也说清楚哪些事 AI 做不了、我们怎么兜底。你要判断的不是「他一个人行不行」， 而是「这套做法能不能交付出你能用的系统」。
最后更新：2026-09-25
五步交付
摸业务，不接需求文档
先弄清这门生意怎么赚钱、当前卡在哪个环节、谁在用这套系统。需求文档写得再细，也解决不了"为什么要做这个功能"。
AI 做：整理访谈记录、生成待确认清单 |人做：判断哪个问题最值钱、砍掉不必要的功能
两周出能点的原型
不做 PPT 方案，直接给能点开、能输数据的原型。老板看得见的东西，才能给出真反馈。
AI 做：写出大部分界面与接口骨架 |人做：定数据模型与业务规则——这步错了后面全废
真实数据跑一遍
拿客户真实的历史数据导进去跑，而不是造的测试数据。绝大多数设计缺陷是在这一步暴露的。
AI 做：写导入脚本、清洗异常数据 |人做：判断哪些"脏数据"其实是业务的真实规则
上线并陪跑
上线不是终点。第一个月跟着一线用，看他们实际怎么操作，改掉别扭的地方。
AI 做：按反馈快速改动、补测试 |人做：现场看人怎么用、判断该改系统还是改流程
沉淀成可复用的资产
每做完一个项目，把设计与踩过的坑沉淀到内部功能库，下一个客户直接复用，成本逐次下降。
AI 做：整理成结构化卡片 |人做：判断哪些经验是通用的、哪些只在这家成立
这种角色有个名字：FDE
FDE 是 Forward Deployed Engineer（前向部署工程师）的缩写，指 直接进到客户业务里做交付的工程师： 先搞懂这门生意怎么赚钱、卡在哪，再写代码，上线后继续跟着业务改。 它和传统外包最大的区别是——不接需求文档，接的是业务问题。
传统外包
按需求文档计价，文档写什么做什么。需求写错了也照做，上线即返工，双方都难受。
FDE 交付
对结果负责：先确认要解决的业务问题，做出来跑通，再按实际使用情况迭代。
为什么一个人能做完
AI 承担了编码里重复的大头（界面、接口、脚本、测试），人只花时间在业务判断和关键设计上。
风险在哪、怎么兜底
一个人的最大风险是断点。做法是：代码和文档全部进客户可见的仓库，关键设计写成文字，随时可交接。
AI 做不了的部分
说清楚边界比吹能力重要。以下这些，目前只能靠人：
- 判断哪个业务问题值得做——AI 会把你说的每个需求都实现，不会告诉你其中三个是伪需求。
- 数据模型与业务规则的取舍。这步错了，后面写得再快都是在错误的地基上盖楼。
- 现场观察。一线怎么操作、在哪儿偷懒、哪个字段永远乱填，只能靠人去看。
- 责任。系统出问题时，客户要找的是一个能负责的人，不是一个模型。