FDE前线部署工程师实战手册：AI Coding从需求到上线

1. 从一句话到上线：FDE 到底在做什么

第一次听到“FDE”这个词，很多人会以为是某种新框架或者新工具。其实 FDE 是 Forward Deployed Engineer 的缩写，直译过来叫“前线部署工程师”。这个角色最早在硅谷的一些 AI 公司里流行起来，核心工作模式就一句话：把客户嘴里那句模糊的需求，变成能跑起来、能上线、能交付的产品。

WorkBuddy 这个项目，就是围绕 FDE 工作流打造的一套实战方法论。它要解决的问题很具体：传统开发流程里，产品经理写 PRD、设计师出图、开发排期、测试验收，一圈走下来少则几周多则几个月。但很多场景下，客户要的东西其实没那么复杂，一句话就能说清楚——“我想要一个能自动整理会议纪要的工具”“我想要一个能帮我盯竞品动态的小助手”。这种需求用传统流程走，成本高得离谱，但用 FDE 模式配合 AI Coding，可能一个下午就能出原型。

这套手册适合谁看？三类人最对口。第一类是独立开发者和小团队，手里有想法但缺人手，想用 AI 把效率拉满；第二类是企业内部的创新小组，需要快速验证业务假设，做 MVP 给老板看；第三类是想转型做 FDE 的工程师，想搞清楚这个岗位到底需要什么技能栈、怎么在 90 天内完成能力搭建。不管你之前有没有全栈经验，只要你能把需求说清楚，剩下的部分这套流程都能帮你补上。

我自己的背景是做了七八年后端，中间也带过小团队做产品。第一次接触 FDE 模式的时候，最大的感受是：它把“写代码”这件事的权重降低了，把“理解需求”和“快速验证”的权重拉高了。以前我们总想着架构要优雅、扩展性要强，结果花了两周搭架子，需求方看了一眼说“这不是我要的”。FDE 的思路完全反过来——先用最短路径跑通核心链路，让需求方看到东西，再根据反馈迭代。这个转变听起来简单，但实际操作起来，里面有很多细节和坑。

接下来我会从整体设计思路、核心环节拆解、实操流程、常见问题四个维度，把这套手册的精华部分完整展开。每个部分都会配上我实际踩过的坑和总结出来的技巧，尽量让你看完就能上手。

2. 整体设计思路：为什么 FDE 模式能跑通

2.1 传统开发流程的瓶颈在哪里

先说清楚为什么要用 FDE 模式。传统软件开发流程有一个隐含假设：需求是确定的，只是需要被翻译成代码。所以流程设计成瀑布式——需求分析、系统设计、编码、测试、部署，每个阶段都有交付物，每个阶段都要评审。这套流程在需求稳定、周期宽松的场景下没问题，但放到快速验证的场景里就崩了。

崩在哪里？三个地方。第一，需求翻译损耗。客户说“我要一个能自动整理会议纪要的工具”，产品经理理解成“语音转文字+摘要提取”，开发理解成“调个 API 就行”，结果做出来发现客户要的是“从会议录音里提取待办事项并自动分配给相关人”。每一层翻译都会丢信息。第二，反馈周期太长。从需求确认到看到东西，中间隔了几周，等东西出来的时候，市场环境可能已经变了。第三，沉没成本绑架决策。投入了两个月开发，即使发现方向不对，也很难下决心推倒重来。

FDE 模式针对这三个问题做了针对性设计。需求翻译损耗用原型对话解决——不写文档，直接做出来给客户看，让客户对着实物提意见。反馈周期用AI Coding 加速解决——把编码时间从周压缩到小时。沉没成本用小步快跑解决——每个迭代只做最小闭环，验证不通过就立刻转向。

2.2 FDE 工作流的核心闭环

FDE 工作流可以概括成一个四步闭环：听、拆、做、验。

“听”不是被动听客户说什么，而是主动挖掘客户真正要解决的问题。客户说“我想要一个自动整理会议纪要的工具”，你要追问：会议纪要用在什么场景？谁来看？看完之后要做什么动作？这些问题问清楚，才能判断核心功能到底是什么。

“拆”是把一句话需求拆成可执行的任务列表。拆的时候遵循一个原则：先做数据流，再做交互。数据从哪来、经过什么处理、存到哪里、怎么展示，这条链路先跑通，界面丑一点没关系。

“做”是用 AI Coding 工具快速实现。这里的关键是选对工具链。WorkBuddy 生态里常用的组合是 DeepSeek 做代码生成、Claude Code 做代码审查和重构、本地环境做调试。工具选对了，编码效率能差出三到五倍。

“验”是把做出来的东西给需求方看，收集反馈，然后回到第一步。这个循环越快，最终交付的东西越接近真实需求。

2.3 为什么选 WorkBuddy 作为落地平台

WorkBuddy 在这个流程里扮演的是工作台角色。它把需求管理、任务拆解、代码生成、环境配置、部署上线这些环节串在一起，减少切换成本。我对比过纯手动流程和 WorkBuddy 流程的效率差异，同样一个“会议纪要整理工具”，手动流程从需求到可演示原型大概需要 3 到 5 天，WorkBuddy 流程可以压缩到 4 到 6 小时。

这个效率提升主要来自三个设计。第一，缓存目录和项目结构标准化。WorkBuddy 对项目目录有约定，AI 生成代码时不需要反复确认路径，减少了大量“文件放哪里”的沟通成本。第二，与 DeepSeek 等模型的深度集成。代码生成的质量和速度都比通用对话式 AI 高出一截，尤其是在处理业务逻辑的时候。第三，部署链路内置。做完的东西可以直接推到测试环境，不需要手动配置服务器。

注意：WorkBuddy 的缓存目录默认在用户目录下的隐藏文件夹里，如果项目多了之后磁盘占用会比较大。建议在设置里把缓存目录改到空间充裕的盘符，具体路径在“设置-高级-缓存管理”里修改。

3. 核心环节拆解：从一句话到任务列表

3.1 需求澄清：把模糊描述变成可执行问题

需求澄清是 FDE 流程里最容易被低估的环节。很多人觉得“客户都说了要什么，直接做就行了”，结果做出来发现完全不是那么回事。我的经验是：客户说的第一句话通常是解决方案，不是问题本身。你要做的是把解决方案还原成问题，再重新推导解决方案。

举个例子。客户说“我想要一个能自动整理会议纪要的工具”。这句话里，“自动整理会议纪要”是解决方案。你要追问的是：现在会议纪要怎么整理的？谁在整理？整理完给谁看？看完之后要做什么？这些问题问完，可能会发现真实需求是“会议结束后 10 分钟内，把待办事项同步到每个人的任务列表里”。这个需求和“整理会议纪要”听起来差不多，但实现路径完全不同。

需求澄清有一个实用技巧：用“如果只能做一个功能，你选哪个”来逼优先级。客户通常会说“都重要”，但如果你坚持只能选一个，他们会告诉你哪个是核心。这个核心功能就是第一版要做的全部内容。

3.2 任务拆解：从功能描述到代码模块

需求澄清完之后，下一步是把功能描述拆成代码模块。拆解的原则是按数据流拆，不按界面拆。界面可以后面再调，数据流不通整个东西就是死的。

还是用会议纪要工具举例。数据流是这样的：录音输入 → 语音转文字 → 文本摘要 → 待办提取 → 任务分配 → 通知推送。这条链路里，每一步都是一个独立模块，可以单独开发和测试。拆完之后你会发现，真正需要 AI 能力的只有“语音转文字”和“文本摘要”两步，其他都是常规业务逻辑。

拆解的时候要注意模块之间的接口定义。比如语音转文字模块的输出格式是什么？文本摘要模块的输入格式是什么？这些接口定义清楚，后面 AI 生成代码的时候才能保证模块之间能对接上。我一般会用简单的 JSON 格式定义接口，比如：

{ "input": {"audio_url": "string", "language": "string"}, "output": {"text": "string", "confidence": "float"} }

这个 JSON 就是模块之间的契约，AI 生成代码的时候把这个契约贴进去，生成的代码基本不需要改就能对接。

3.3 工具链选型：AI Coding 工具怎么配

工具链选型直接决定开发效率。WorkBuddy 生态里常用的组合是DeepSeek + Claude Code + 本地调试环境。这个组合的逻辑是：DeepSeek 负责生成代码，Claude Code 负责审查和重构，本地环境负责跑测试。

为什么这么配？DeepSeek 在代码生成任务上的表现比较稳定，尤其是处理业务逻辑的时候，生成的代码结构清晰、注释完整。Claude Code 的优势在于代码审查，它能发现一些逻辑漏洞和边界情况，这些是生成阶段容易忽略的。本地环境用 Docker 或者直接跑在宿主机上都行，看项目复杂度。

提示：DeepSeek 的代码生成质量跟提示词质量强相关。提示词里要包含三样东西：功能描述、输入输出格式、边界条件。缺一样，生成的代码就要返工。

工具链配好之后，还要设置好缓存目录。WorkBuddy 默认的缓存目录在系统盘，项目多了之后会拖慢系统速度。建议改到数据盘，具体操作是：打开 WorkBuddy 设置，找到“缓存管理”，把路径改成D:\workbuddy_cache或者类似的位置。改完之后重启一次 WorkBuddy，让配置生效。

3.4 90 天能力搭建路径

如果你是从零开始学 FDE，90 天是一个比较合理的周期。我把这 90 天分成三个阶段。

第 1 到 30 天：基础能力搭建。这个阶段的目标是熟悉工具链和基本流程。每天花 2 小时，第一周学 WorkBuddy 的基本操作和缓存目录配置，第二周学 DeepSeek 的提示词写法，第三周学 Claude Code 的代码审查功能，第四周做一个完整的练手项目——比如一个简单的待办事项管理工具。这个阶段不要追求完美，能跑通就行。

第 31 到 60 天：实战能力提升。这个阶段的目标是独立完成一个真实需求。找一个身边的朋友或者同事，问他们有没有什么重复性工作想自动化。拿到需求之后，完整走一遍“听拆做验”流程。这个阶段会遇到很多坑，比如需求理解偏差、AI 生成的代码跑不通、部署环境配置错误。每个坑都是学习机会。

第 61 到 90 天：效率优化和知识沉淀。这个阶段的目标是把效率提上去。具体做法是：把前 60 天重复用到的代码片段整理成模板，把常见问题的解决方案整理成文档，把工具链的配置整理成脚本。做完这些之后，同样一个需求，处理时间能比第一个月缩短一半以上。

4. 实操过程：一个完整案例的拆解

4.1 案例背景：网约车司机端小工具

为了让你更直观地理解整个流程，我用一个实际做过的案例来拆解。需求方是一个做网约车业务的朋友，他的原话是：“我想要一个工具，能让司机在接单间隙快速记录车辆状况，比如油量、里程、有没有异响，然后自动生成日报。”

这句话听起来简单，但里面有几个模糊点。第一，“接单间隙”是什么场景？是停车等单的时候，还是行驶过程中？第二，“车辆状况”具体包括哪些项？第三，“日报”给谁看？看完之后做什么？这些问题问清楚之后，真实需求是：司机在停车等单时，用手机快速勾选车辆状况，系统自动汇总成日报，发给车队队长。

4.2 需求拆解与任务列表

需求明确之后，拆成任务列表：

1. 移动端界面：勾选式表单，包含油量、里程、异响、胎压、灯光五个项
2. 数据存储：本地存一份，同步到云端一份
3. 日报生成：每天固定时间把当天记录汇总成文本
4. 推送通知：日报生成后推送给队长

这四个任务里，第一个和第二个是核心链路，第三个和第四个是增强功能。第一版只做前两个，后两个等验证通过再加。

4.3 代码生成与调试过程

移动端界面用 React Native 做，因为跨平台，iOS 和 Android 都能跑。数据存储用 SQLite 本地库加一个简单的云同步接口。代码生成的时候，我把任务描述和接口定义一起贴给 DeepSeek，提示词是这样的：

功能：移动端车辆状况记录表单 输入：无 输出：JSON 格式的记录数据 字段：oil_level (0-100), mileage (number), abnormal_sound (boolean), tire_pressure (number), light_status (boolean) 要求：使用 React Native，表单提交后存到 SQLite，同时调用云同步接口

DeepSeek 生成的代码基本可用，但有两个问题需要手动改。第一，SQLite 的建表语句没有加索引，数据量大了之后查询会慢。第二，云同步接口没有做失败重试，网络不好的时候数据会丢。这两个问题都是 Claude Code 在审查阶段发现的，改起来很快。

调试的时候遇到一个坑：React Native 的 SQLite 库在 Android 和 iOS 上的行为不一致，Android 上需要手动开启 WAL 模式才能支持并发读写。这个坑在文档里没写，是我跑了两次测试才发现的。解决办法是在数据库初始化的时候加一行：

db.executeSql('PRAGMA journal_mode=WAL;');

4.4 部署与验证

第一版做完之后，打包成 APK 发给朋友测试。他用了三天，反馈了两个问题：第一，表单勾选太慢，司机等单时间短，需要更快的方式。第二，日报格式不对，队长想要的是表格，不是纯文本。

根据反馈，第二版做了两个改动：把勾选式表单改成语音输入加自动识别，日报格式改成 CSV 表格。这两个改动花了大概两个小时，改完之后朋友说“可以用了”。

这个案例从需求到可用版本，总共花了大概 6 个小时。如果走传统流程，光需求评审和 UI 设计就要两三天。这就是 FDE 模式的优势——把时间花在验证上，而不是花在流程上。

5. 常见问题与排查技巧实录

5.1 AI 生成代码跑不通怎么办

这是最常见的问题。AI 生成的代码跑不通，通常有三个原因。第一，依赖版本不匹配。AI 训练数据里的库版本可能跟你本地环境不一致，导致 API 对不上。解决办法是在提示词里指定版本号，比如“使用 React Native 0.72.0”。第二，环境配置缺失。比如缺少环境变量、缺少配置文件、缺少数据库连接。解决办法是把环境配置信息也贴进提示词。第三，逻辑边界没覆盖。AI 生成的代码通常只处理正常情况，异常情况需要手动补。

排查的时候用二分法：先把代码拆成最小可运行单元，逐个测试，找到跑不通的那个单元，再针对性修改。不要一上来就改整个文件，那样效率很低。

5.2 缓存目录导致的问题

WorkBuddy 的缓存目录如果配置不当，会出现几种典型问题。第一，磁盘空间不足。缓存文件默认存在系统盘，项目多了之后系统盘会满。解决办法是改到数据盘，前面已经说过。第二，缓存冲突。多个项目共用同一个缓存目录时，可能会出现文件覆盖。解决办法是每个项目单独设置缓存子目录。第三，缓存损坏。突然断电或者强制关闭 WorkBuddy 可能导致缓存文件损坏，表现是项目打不开或者代码生成异常。解决办法是删除缓存目录下的临时文件，重启 WorkBuddy。

注意：删除缓存文件之前先备份项目代码，缓存里可能包含未保存的修改。

5.3 需求变更怎么处理

FDE 流程里需求变更是常态，不是异常。处理原则是：小变更直接做，大变更先验证。小变更指的是不影响核心链路的调整，比如改个字段名、调个界面颜色，这种直接改就行。大变更指的是影响核心链路的调整，比如把本地存储改成云端存储，这种要先做一个最小验证，确认可行之后再全量改。

我自己的经验是：需求变更的频率跟原型演示的频率成反比。演示越频繁，需求变更越少。因为每次演示都是一次对齐，对齐次数多了，偏差自然就小了。所以不要怕演示，哪怕东西还很粗糙，也要尽早给需求方看。

5.4 常见问题速查表

5.5 独家避坑技巧

第一个技巧：提示词里加“不要做什么”。AI 生成代码的时候，如果你只说“要做什么”，它可能会加一些你不需要的功能。比如你只要一个简单的表单，它给你加了一套完整的用户认证系统。所以在提示词里明确说“不需要用户认证”“不需要权限管理”，能省很多清理时间。

第二个技巧：每次只改一个模块。AI 生成代码的时候，如果你一次让它改多个模块，它可能会把模块之间的接口改乱。正确做法是一个模块一个模块改，改完测试通过再改下一个。

第三个技巧：保留每次生成的版本。AI 生成的代码不一定每次都比上次好，有时候改着改着发现还是第一版好用。所以每次生成之后都存一个版本，用 Git 或者简单的文件复制都行。我一般用 Git，每次生成完 commit 一次，回滚很方便。

第四个技巧：部署之前先在本地跑一遍完整流程。很多人本地测试只测单个模块，部署之后才发现模块之间对接有问题。正确做法是在本地把完整流程跑一遍，从输入到输出，确认没问题再部署。

6. 效率提升的进阶玩法

6.1 模板化：把重复劳动变成一键操作

做 FDE 时间长了之后，你会发现很多需求是类似的。比如“记录数据+生成报表”这个模式，在车辆管理、库存管理、工时管理里都出现过。这种重复模式可以做成模板，下次遇到类似需求直接套。

模板化的具体做法是：把项目结构、数据库 schema、常用组件、部署脚本整理成一个基础模板，新项目直接从模板复制。WorkBuddy 支持项目模板功能，在创建项目的时候选择“从模板创建”，然后选你整理好的模板就行。

我自己的模板里包含这些东西：一个基础的 React Native 项目结构、一个 SQLite 数据库封装、一个云同步接口封装、一个日报生成脚本、一个部署脚本。新项目从模板创建之后，只需要改业务逻辑部分，基础设施部分不用动。这样能把项目启动时间从两小时压缩到十分钟。

6.2 自动化：把手动步骤变成脚本

FDE 流程里有几个步骤是重复的：环境配置、依赖安装、数据库初始化、部署。这些步骤可以写成脚本，一键执行。

环境配置脚本我一般用 shell 写，内容大概是：检查 Node.js 版本、检查 Python 版本、安装全局依赖、配置环境变量。依赖安装脚本用 npm 或者 yarn 的脚本功能，把常用依赖写进 package.json 的 scripts 里。数据库初始化脚本用 SQL 文件，部署脚本用 Dockerfile 加一个 build 脚本。

这些脚本写一次，后面每个项目都能用。累计节省的时间很可观。

6.3 知识沉淀：把踩过的坑变成文档

FDE 流程里踩的坑如果不记录，下次还会踩。所以每次解决一个问题之后，花五分钟把问题和解决方案记下来。记录格式不用太正式，三行就行：问题现象、原因、解决方案。

积累到一定数量之后，把这些记录整理成分类文档。比如“环境配置类问题”“代码生成类问题”“部署类问题”。下次遇到类似问题，先查文档，查不到再排查。这样能把问题解决时间缩短一半以上。

我自己的文档里记录了大概两百多条问题，覆盖了从环境配置到部署上线的全流程。新同事入职的时候，我直接把这个文档给他们，能省很多培训时间。

7. 从 FDE 到全栈：能力扩展方向

7.1 前端能力：从能用 to 好用

FDE 模式做出来的第一版通常只追求“能用”，界面比较粗糙。但如果要交付给真实用户，界面体验很重要。所以前端能力需要从“能跑就行”提升到“好用”。

提升方向有三个。第一，组件库熟练度。React Native 生态里有几个成熟的组件库，比如 React Native Elements、NativeBase，熟练使用这些库能大幅提升界面质量。第二，交互细节。比如加载状态、错误提示、空状态，这些细节处理好了，用户体验会好很多。第三，性能优化。列表渲染、图片加载、动画这些地方容易出性能问题，需要专门优化。

7.2 后端能力：从单机到云端

第一版通常跑在本地或者单机上，用户量上来之后需要迁移到云端。后端能力提升方向包括：数据库选型（从 SQLite 到 PostgreSQL 或 MySQL）、接口设计（从简单 REST 到 GraphQL 或 gRPC）、部署架构（从单机到容器化部署）。

这些能力不需要一开始就掌握，但要有意识地在项目中逐步引入。比如第一个项目用 SQLite，第二个项目就可以试试 PostgreSQL。逐步升级，不要一步到位。

7.3 AI 能力：从调用到调优

FDE 流程里 AI 主要用来生成代码，但 AI 的能力不止于此。进阶玩法包括：用 AI 做需求分析（把客户访谈记录丢给 AI，让它提取关键需求）、用 AI 做测试用例生成（根据功能描述自动生成测试用例）、用 AI 做代码审查（自动发现潜在问题）。

这些玩法的核心是提示词工程。提示词写得好，AI 的输出质量能差出好几倍。提示词优化的方向包括：明确角色（“你是一个资深 React Native 开发者”）、明确格式（“用 JSON 格式输出”）、明确约束（“不要使用任何第三方状态管理库”）。

8. 我个人的一些体会

做了这么多项目之后，最大的体会是：FDE 的核心竞争力不是写代码，而是理解需求。代码写得好的人很多，但能把客户一句话需求翻译成可执行方案的人很少。这个能力需要刻意练习，练习方法就是多跟需求方聊天，多问“为什么”，多验证。

第二个体会是：工具是杠杆，不是替代品。AI Coding 工具能大幅提升效率，但它不能替代思考。需求理解、方案设计、优先级判断这些事，还是得人来做。工具用得再好，方向错了也是白搭。

第三个体会是：快比完美重要。FDE 模式里，第一版不需要完美，能跑通核心链路就行。完美主义是效率最大的敌人。先做出来，再改好，这个顺序不能反。

最后分享一个小技巧：每次做完一个项目，花十分钟写一个复盘。复盘内容就三样：做得好的地方、做得不好的地方、下次怎么改进。这个习惯坚持半年，能力提升会非常明显。