AI Coding 时代 FDE 成长路径：90 天从需求到上线

一句话需求丢过来，三天后要看到能装到手机上的 App，这种场景在最近一年变得越来越常见。以前这意味着产品、设计、前端、后端、测试排期至少两周起步，现在借助 AI Coding 工具链，一个人从需求到上线的时间被压缩到了以小时计。WorkBuddy 的 FDE（Forward Deployed Engineer，前置交付工程师）模式就是在这个背景下被越来越多团队采用的落地路径——它不是一个单纯的代码生成器，而是一套把"业务语言"翻译成"可运行产品"的完整工作流。这篇内容面向三类人：想转型 FDE 的全栈开发者、需要快速验证想法的产品负责人、以及刚接触 AI Coding 想找一条清晰上手路径的新手。我会把 90 天的成长路径拆开讲，把每个阶段该练什么、踩什么坑、怎么验证自己是否过关，都落到可执行的动作上。

1. 先搞清楚 FDE 到底在交付什么

1.1 从"写代码的人"到"扛结果的人"

很多人第一次听到 FDE 这个词，会下意识把它理解成"会用 AI 写代码的工程师"。这个理解只对了一半，而且是最不重要的那一半。FDE 的核心变化在于交付物的定义：传统开发交付的是"功能模块"，FDE 交付的是"一个能跑起来、能被真实用户打开、能产生反馈的完整产品"。这个差别听起来抽象，落到日常就是——你不能再把"接口写完了"当成阶段性成果，你得让用户真的能在手机上点开那个链接。

WorkBuddy 在这套模式里扮演的角色，是把需求理解、代码生成、环境配置、部署上线这几段原本割裂的流程串成一条线。你给它一句"做一个记录每日饮水量的小工具，能看一周趋势"，它不会只回你一段代码，而是会尝试理解你要的是一个有数据存储、有图表展示、有移动端适配的完整应用。这个"理解意图"的能力，是 FDE 工作流和普通代码补全工具最本质的分界线。

我自己的体会是，刚上手时最容易犯的错，是把 WorkBuddy 当成一个"更聪明的自动补全"。你会习惯性地把需求拆得很碎，一句一句喂给它，结果反而慢。正确的姿势是先把业务目标说清楚，让它自己去做技术拆解，你只在关键决策点上介入。这个思维转换大概需要一到两周才能形成肌肉记忆。

1.2 一句话需求为什么能变成 App

这里要拆解一个很多人好奇的问题：凭什么一句话就能生成一个能上线的 App？答案不在于模型有多神，而在于现代 App 的技术栈已经高度标准化了。一个典型的轻量级应用，无非是前端页面、数据存储、接口层、部署托管这四块，而每一块都有成熟的默认方案。AI Coding 工具做的事情，是把"选型决策"这一步用概率最高的默认值替你做了。

比如你说"做个记账 App"，WorkBuddy 大概率会给你一个前端用 React 或 Vue、数据层用轻量数据库或云函数、部署走静态托管的方案。这个方案不一定是最优的，但它在 80% 的场景下是够用的。FDE 的价值就在于：知道什么时候接受这个默认方案快速跑通，什么时候必须推翻它换成更合适的架构。

提示：不要在一句话需求阶段就纠结技术选型。先让它跑出一个能看的版本，再基于真实运行结果去调整，比在脑子里空想架构高效得多。

1.3 WorkBuddy 与同类工具的定位差异

市面上 AI Coding 工具不少，WorkBuddy 的差异点在于它更偏向"项目级"而不是"文件级"。文件级工具擅长帮你写一个函数、补一段逻辑；项目级工具要处理的是跨文件依赖、环境变量、构建配置、部署脚本这些"胶水层"的问题。而恰恰是这些胶水层，卡住了绝大多数想独立做产品的人。

我做过一个对比，同样一个"待办清单 + 云同步"的需求，用文件级工具你需要自己搭脚手架、配路由、接数据库、写部署脚本，AI 只帮你写业务逻辑；用 WorkBuddy 这类项目级工具，它会连脚手架带部署一起给你。省下来的时间不是线性的，是数量级的。这也是为什么 FDE 能在几天内交付一个 App，而传统流程做不到。

2. 90 天路径的第一阶段：把工具用顺

2.1 前两周只做一件事——跑通最小闭环

新手最容易犯的错是一上来就想做复杂项目。我的建议是前两周只练一个动作：从一句话需求到手机能打开，完整走通一遍，哪怕做出来的是个"点击按钮显示当前时间"的玩具。这个闭环里包含的环节一个都不能少：需求描述、代码生成、本地运行、部署、真机访问。

为什么这么强调闭环？因为 FDE 的核心能力不是写代码，是"让东西跑起来"。你会在跑通第一个闭环的过程中遇到一堆琐碎问题：端口被占用、依赖装不上、部署后白屏、手机访问不了本地服务。这些问题在文档里往往一笔带过，但它们是真实交付路上的主要障碍。提前踩一遍，后面做真项目时就不会慌。

具体操作上，我建议用最简单的需求起步，比如"做一个显示当前时间和日期的网页，适配手机屏幕"。让 WorkBuddy 生成后，先在本地浏览器验证，再部署到静态托管平台，最后用手机扫码或输入链接访问。整个过程控制在两小时内完成，做不完就说明某个环节卡住了，去把那个环节单独搞明白。

2.2 环境配置里那些没人告诉你的细节

环境配置是劝退重灾区。我见过太多人卡在第一步就放弃了，不是因为难，是因为报错信息看不懂。这里列几个高频问题和处理思路。

这些问题的共同点是：它们和你的业务代码毫无关系，纯粹是工程环境问题。FDE 必须对这类问题有免疫力，否则每次都会被卡住。我的经验是准备一份自己的"环境问题速查表"，每解决一个新问题就记一条，三个月后你就有了一份比任何官方文档都好用的私人手册。

2.3 缓存目录与工作区管理

WorkBuddy 这类工具在运行过程中会产生缓存、临时文件、构建产物，如果不管理，磁盘很快会被塞满，而且项目之间会互相干扰。我建议在第一个月就养成习惯：给每个项目建独立的工作目录，缓存目录单独配置到一个固定位置，定期清理。

具体做法是找到工具的配置文件，把缓存路径指向一个专门的目录，比如统一放在用户目录下的一个隐藏文件夹里。这样做的另一个好处是迁移项目时不会丢配置——你只需要把项目目录和缓存目录一起搬走就行。很多人换电脑或者重装系统后项目跑不起来，就是因为缓存和配置散落在各处没跟着走。

注意：修改缓存目录后要重启工具，并且确认新目录有写入权限，否则会出现"配置改了但不生效"的假象。

3. 第二阶段：从玩具到能用的产品

3.1 需求描述的颗粒度怎么把握

过了工具关，接下来要练的是"把需求说清楚"的能力。这是 FDE 最核心的软技能，也是最难量化的。我的经验是把需求分成三层来描述：业务目标、用户动作、数据流向。

业务目标回答"这个东西解决什么问题"，比如"帮用户记录每天的开销并看到月度汇总"。用户动作回答"用户会怎么操作"，比如"打开就能看到本月总支出，点加号能记一笔，能按分类筛选"。数据流向回答"数据从哪来、存哪去、怎么展示"，比如"用户输入的数据存在本地，汇总数据实时计算，图表用折线展示"。

这三层说清楚，WorkBuddy 生成的结果质量会明显提升。反过来，如果你只说"做个记账 App"，它只能靠猜，猜错了你还得反复改。我实测下来，花五分钟把这三层写清楚，能省掉后面半小时的来回调整。

3.2 什么时候该推翻 AI 的默认方案

AI 给的默认方案在简单场景下够用，但遇到特定需求就必须推翻。判断标准很简单：当默认方案和你的核心需求冲突时，果断换。比如你要做一个需要离线可用的工具，但默认方案依赖云端接口，那就必须换成纯前端本地存储的方案。

再比如你要做一个数据量会持续增长的应用，默认方案可能用的是内存存储或者简单的本地文件，跑一段时间就会变慢甚至崩溃，这时候就得换成正经的数据库。识别这类问题的能力，来自你对"这个方案在什么规模下会失效"的判断，这也是 FDE 区别于纯 AI 工具使用者的地方——你知道边界在哪。

我一般会在项目启动时问自己三个问题：数据会不会越来越多？用户会不会越来越多？有没有必须离线或必须实时的场景？任何一个答案是"会"或"有"，就要重新审视默认方案。

3.3 用真实反馈驱动迭代

产品能跑起来之后，最重要的事情是拿给真实的人用。哪怕只有三五个朋友，他们的反馈也比你自己空想有价值得多。FDE 的工作方式不是"做完再给人看"，而是"能跑就给人看，边用边改"。

收集反馈时要注意区分"抱怨"和"需求"。用户说"这个按钮太小了"是抱怨，背后可能是"我在手机上点不准"这个需求；用户说"能不能加个导出功能"是需求，但你要判断这是不是当前阶段该做的。我的做法是每次迭代只解决反馈里出现频率最高的一个问题，其他的记下来排期。这样能保证产品一直在往对的方向走，而不是被零散意见带偏。

4. 第三阶段：把交付变成可复制的流程

4.1 建立自己的项目模板库

做到第三个月，你应该已经交付过几个小项目了。这时候最有价值的动作是把重复的部分抽出来，做成模板。比如登录注册、数据列表、表单提交、图表展示这些模块，几乎每个项目都要用，每次重新生成是浪费。

我的做法是每做完一个项目，把其中通用的部分整理成一个可复用的起点。下次新项目直接从模板开始，只改业务相关的部分。这个习惯能让你的交付速度再上一个台阶，而且质量更稳定——因为模板里的代码是经过验证的，不会每次都引入新问题。

模板库不需要多复杂，几个文件夹加一份说明文档就够了。关键是坚持维护，每发现一个好用的写法就补进去，每踩一个坑就记一条避坑说明。

4.2 部署与上线的标准化动作

部署这件事，第一次做很痛苦，做多了就是肌肉记忆。我把它标准化成几个固定动作：构建、检查产物、上传、验证、回滚预案。每一步都有明确的检查点，不通过就不往下走。

构建完成后一定要检查产物目录，确认入口文件存在、静态资源路径正确。上传后不要只看部署平台显示"成功"，要真的用手机打开链接验证一遍。回滚预案指的是：如果新版本有问题，你能不能快速切回上一个版本。这个能力在正式项目里是必须的，哪怕你只是给自己做工具，养成习惯也没坏处。

4.3 一个人扛完整条链的能力边界

FDE 模式让一个人能扛完整条交付链，但要知道自己的能力边界在哪。简单应用、内部工具、验证性产品，一个人完全没问题。但涉及支付、复杂权限、高并发、合规要求的场景，还是需要专业分工。

认清边界不是认怂，是成熟。我见过有人用 FDE 模式硬扛一个需要复杂后端架构的项目，结果前期跑得飞快，后期维护成本爆炸。正确的做法是：用 FDE 快速验证想法和跑通核心流程，验证成功后如果需要规模化，再引入专业角色做架构升级。这样既享受了速度，又不会埋下技术债。

5. 那些只有踩过才知道的坑

5.1 需求反复变更导致的返工

最常见也最痛的坑，是需求在开发过程中反复变。今天要做 A，明天改成 B，后天又觉得 A 好。AI 生成代码很快，但每次变更都意味着重新生成、重新测试、重新部署，累积起来的时间成本很高。

我的应对方法是：在动手前把需求写下来，明确这一版做什么、不做什么。变更可以，但要评估影响，不要随口就改。对于探索性需求，先做一个最简版本验证方向，方向对了再投入做完整版。这个习惯能省掉大量无效返工。

5.2 生成代码的隐藏问题

AI 生成的代码能跑，不代表没问题。我遇到过生成的代码里有硬编码的密钥、有没处理的边界情况、有性能很差的循环。这些问题在演示时看不出来，真实使用时就暴露了。

我的检查清单是：有没有硬编码的敏感信息、有没有处理空数据和异常、有没有明显的性能瓶颈、有没有安全漏洞。这四项每次交付前都过一遍，能挡掉大部分隐患。尤其是硬编码密钥，一旦部署到公开环境就是事故，必须养成用环境变量管理的习惯。

5.3 工具依赖带来的能力退化

用久了 AI 工具，会有一个隐性风险：自己的基础能力在退化。以前能徒手写的代码，现在离开工具就写不出来；以前能看懂的报错，现在只会复制粘贴给 AI。这个趋势要警惕。

我的做法是定期做"无工具练习"，挑一个简单功能，关掉 AI 自己写一遍。不是为了不用工具，是为了保持对底层原理的敏感度。当你理解代码在做什么，你才能判断 AI 生成的对不对，才能在它出错时快速定位。工具是放大器，不是替代品。

6. 90 天之后往哪走

6.1 从交付单个项目到沉淀方法论

90 天走完，你应该有了几个能跑的项目和一套自己的流程。接下来的方向是从"能交付"到"能稳定交付"。区别在于：前者靠状态和运气，后者靠流程和沉淀。把你这三个月踩过的坑、总结的技巧、验证过的方案整理成文档，形成自己的方法论。

这份方法论的价值在于可复制。下次遇到类似项目，你不用重新摸索，直接按流程走。带新人的时候，这份文档就是最好的教材。我见过很多技术不错的人卡在"每次都要重新来一遍"的状态，问题就出在没有沉淀。

6.2 把 FDE 能力迁移到团队协作

个人能力再强也有上限，把 FDE 的工作方式推广到团队，价值会放大。核心是统一需求描述规范、统一项目模板、统一部署流程。让团队里每个人都能用同样的方式快速交付，而不是各搞各的。

推广时要注意，不要一上来就要求所有人改变习惯。先自己做出成绩，用结果说话，然后逐步分享你的流程和工具。愿意学的人自然会跟上，不愿意的也不用强求。工具和方法的普及从来都是靠示范，不是靠命令。

6.3 持续跟进工具演进

AI Coding 这个领域变化极快，今天好用的方法下个月可能就过时了。保持跟进的方式不是追每一个新工具，而是关注底层能力的变化。比如模型的理解能力提升了，你的需求描述方式就可以更粗放；部署平台的能力增强了，你的上线流程就可以更简化。

我的习惯是每个月花半天时间，把主流工具的更新过一遍，挑一两个真正有用的点试一下。不盲目追新，但也不闭门造车。这个节奏坚持下来，你会发现自己始终站在比较靠前的位置，而不是被工具推着走。

最后分享一个我自己的小习惯：每交付一个项目，花十分钟写一段复盘，记录这次哪里顺、哪里卡、下次怎么改。三个月下来，这几十段复盘就是我最宝贵的个人资产，比任何教程都贴合我自己的实际情况。FDE 这条路，工具会变、方法会变，但"从需求到上线"这个闭环的能力，会一直值钱。