企业官网建设流程全解析

一句话需求丢过来，三天后要看到能点开的 App，这种场景在现在的研发节奏里越来越常见。WorkBuddy 这套东西本质上是一个面向交付场景的 AI Coding 工作台，FDE（Forward Deployed Engineer，前置交付工程师）则是把"客户嘴里那句模糊的话"翻译成"能跑起来的产品"的那个人。这篇手册想聊的就是这条链路：从一句需求开始，怎么用 WorkBuddy 配合 AI Coding 工具，把需求拆解、原型搭建、代码生成、联调测试、打包上线这一整套流程走通，并且给出一条可执行的 90 天成长路径。适合刚接触 FDE 角色的人、想用 AI 提效的全栈开发者，以及需要快速验证产品想法的小团队。我不会只讲概念，重点放在每一步具体怎么操作、为什么这么选、哪些地方容易翻车。

1. 先搞清楚 FDE 到底在交付链条里干什么

很多人第一次听到 FDE 这个词，会下意识把它等同于"售前工程师"或者"技术支持"，这其实是个挺大的误解。FDE 的核心价值不在于把已有产品讲清楚，而在于把客户还没想清楚的需求，变成一个真实可运行的系统。这个角色最早在数据基础设施和 AI 工具类公司里被大量使用，因为这类产品的落地高度依赖客户的具体业务场景，标准化程度低，必须有人扎到一线去把需求和技术之间的鸿沟填上。

1.1 FDE 和普通开发、售前的边界在哪

普通后端开发拿到的是已经拆好的任务卡，输入输出明确，做完提测就行。售前工程师负责的是方案讲解、POC 演示，重点在"说服"。FDE 夹在中间，既要能听懂业务方那句"我想要一个能管理客户的东西"背后到底指什么，又要能自己动手把原型搭出来，还要保证这个东西能真的部署到客户环境里跑起来。换句话说，FDE 是"能写代码的需求翻译官"，也是"能跟客户对话的工程师"。

这个定位决定了 FDE 的能力模型是偏复合的。你不需要在某个技术栈上做到专家级深度，但需要在需求分析、快速原型、全栈开发、部署运维这几个环节都有能上手的能力。WorkBuddy 这类工具的出现，恰好把 FDE 最耗时的"从零写样板代码"这部分压缩了，让 FDE 能把精力放在需求理解和方案设计上。

1.2 一句话需求为什么最难接

"帮我做个网约车 App"——这句话里藏着的信息量其实巨大。是乘客端还是司机端还是两端都要？要不要实时定位？支付走哪条通道？调度算法是就近派单还是抢单？合规资质谁来提供？这些如果不在前期问清楚，等到开发到一半才发现方向错了，返工成本极高。

FDE 接需求的第一步永远不是打开编辑器，而是做需求澄清。我习惯用一套固定的提问框架，把模糊需求拆成几个维度：用户角色（谁用）、核心动作（用来干嘛）、数据流向（信息从哪来到哪去）、边界条件（什么不做）、验收标准（怎么算做完）。这套框架不复杂，但能挡掉大量后期返工。WorkBuddy 的工作台里可以建需求卡片，把每个维度的结论记下来，后续生成代码时这些卡片就是上下文，AI 理解得会准很多。

1.3 WorkBuddy 在 FDE 工作流里的位置

WorkBuddy 不是替代 FDE 的工具，而是放大 FDE 产能的工具。它的定位更像一个"项目中枢"：需求卡片、任务拆解、代码生成、缓存管理、多项目切换都在一个工作台里完成。配合 AI Coding 能力（比如接入 DeepSeek 这类模型做代码生成和补全），FDE 可以把"想清楚"和"写出来"之间的时间差压到最短。

我实测下来，一个中等复杂度的管理后台，传统方式从需求到可演示原型大概要 5 到 7 天，用 WorkBuddy 配合 AI Coding 能压到 1 到 2 天。省下来的时间不是让你摸鱼，而是让你有更多余量去跟客户确认细节、去处理那些 AI 生成不了的业务逻辑。这个产能提升的本质，是把重复性的脚手架工作交给工具，把判断性的工作留给人。

2. 把一句话需求拆成可执行任务的完整方法

需求拆解是整条链路里最考验功力的环节，也是最容易被跳过的一步。很多人拿到需求直接让 AI 生成代码，结果生成出来的东西跟实际要的差十万八千里，然后反复调整 prompt，效率反而更低。正确的做法是先人工把需求拆到位，再让 AI 去填充实现细节。

2.1 用角色-动作-数据三要素做第一轮拆解

我习惯拿一张纸（或者 WorkBuddy 的需求卡片）画三个列：角色、动作、数据。以"网约车 App"为例，角色有乘客、司机、平台运营；乘客的动作有注册登录、发起叫车、查看司机位置、支付、评价；数据有订单信息、位置坐标、支付流水、评价内容。把这三列填满，需求的骨架就出来了。

这一步的关键是不要漏角色。很多需求翻车是因为只考虑了主流程角色，忘了运营后台、忘了客服、忘了异常处理。填完三要素之后，我会再问一遍："还有谁会用这个系统？"通常能再挖出一两个被忽略的角色。

2.2 把动作翻译成用户故事和验收标准

三要素拆完之后，每个"角色+动作"组合就是一个用户故事。写成标准格式："作为[角色]，我希望[动作]，以便[目的]"。比如"作为乘客，我希望看到司机的实时位置，以便判断还要等多久"。每个用户故事后面必须跟验收标准，否则开发完没法判断做没做对。

验收标准要具体到可测试。比如"实时位置"这条，验收标准可以写成：位置刷新间隔不超过 5 秒、地图上显示司机图标和预计到达时间、网络断开时显示最后已知位置并提示。这些标准写清楚了，后面无论是人工开发还是 AI 生成，都有明确的靶子。

2.3 用 WorkBuddy 需求卡片管理拆解结果

拆解结果不能散落在聊天记录里，得有个地方统一管理。WorkBuddy 的需求卡片功能适合干这个：一张卡片对应一个用户故事，卡片里记录验收标准、优先级、依赖关系。卡片之间可以建立关联，比如"支付"卡片依赖"订单创建"卡片。

这样做的好处是，后续用 AI 生成代码时，可以把相关卡片作为上下文喂给模型，生成的代码会更贴合业务。我试过把整个需求卡片集导出成结构化文本，作为 AI Coding 的输入，生成出来的模块划分和实际需求匹配度明显高于只给一句需求描述。

2.4 优先级排序：先做能跑通主流程的最小集

需求拆完通常有一大堆，不可能一次全做。这时候要排优先级，原则是"先让主流程能跑通"。网约车的主流程是：乘客叫车→平台派单→司机接单→行程进行→支付完成。这条链路涉及的功能优先做，评价、优惠券、发票这些周边功能往后放。

我一般把需求分成三档：P0 是主流程必须有的，P1 是影响体验但不阻塞主流程的，P2 是锦上添花的。第一版只做 P0，跑通了再迭代。这个原则听起来简单，但实际执行时很容易被"这个功能也不难，顺手做了吧"带偏，结果第一版迟迟上不了线。

3. 用 AI Coding 把原型快速搭起来的实操细节

需求拆到位之后，进入实现阶段。这个阶段 AI Coding 能发挥最大价值，但前提是你知道怎么用它。直接甩一句"帮我写个网约车 App"给 AI，得到的多半是一堆跑不起来的碎片代码。正确的用法是分模块、分层次地生成，每一步都验证。

3.1 技术栈选型：为什么优先选 AI 熟悉的组合

选技术栈的时候，除了考虑团队熟悉度和业务需求，还要考虑 AI 模型的"熟悉程度"。主流模型对 React、Vue、Django、Express、FastAPI 这些流行框架的代码生成质量明显高于小众框架。这不是说小众框架不能用，而是用主流框架能减少 AI 生成代码的调试成本。

以网约车 App 为例，如果要做跨平台移动端，React Native 或 Flutter 是常见选择，模型对这两者的支持都不错。后端如果追求开发速度，Django 或 FastAPI 上手快，模型生成的代码结构也比较规范。数据库用 PostgreSQL 或 MySQL 都行，模型对 SQL 的生成质量普遍较高。这套组合不是唯一解，但它是"AI 友好度"和"工程可靠性"平衡得比较好的方案。

3.2 从数据模型开始生成，而不是从界面开始

很多人用 AI 生成代码习惯从界面开始，先让 AI 画个登录页，再画个首页。这个顺序其实是反的。界面依赖数据，数据模型没定清楚，界面生成出来也是空中楼阁。正确的顺序是先定数据模型，再生成 API，最后生成界面。

数据模型可以用自然语言描述给 AI，让它生成建表语句和 ORM 模型。比如描述"订单表需要记录乘客 ID、司机 ID、起点坐标、终点坐标、订单状态、创建时间、完成时间"，AI 能生成对应的 Django Model 或 SQLAlchemy 模型。生成之后人工检查一遍字段类型和索引，确认没问题再往下走。

3.3 分模块生成 API 并逐个验证

数据模型定好之后，按模块生成 API。每个模块生成完立刻验证，不要攒一堆再一起测。验证方式很简单：启动服务，用 curl 或 Postman 打几个请求，看返回是否符合预期。AI 生成的代码经常有细节问题，比如字段名拼写、参数校验缺失、异常处理不完整，早发现早修。

我一般会准备一组固定的测试请求，每生成一个模块就跑一遍。这组请求覆盖正常流程和几个边界情况，比如空参数、超长字符串、不存在的 ID。跑通了再进下一个模块。这个习惯能挡掉大量后期联调时的诡异 bug。

3.4 界面生成：先出静态稿再接入数据

界面部分，先让 AI 生成静态布局，确认视觉和交互符合预期，再接入真实数据。直接让 AI 生成"带数据的完整页面"容易出问题，因为数据接口可能还没完全定稿，生成的代码里会有一堆假设，后面接口一变就得大改。

静态稿阶段重点看布局和交互逻辑，比如按钮位置、表单校验提示、加载状态。这些确认了，接入数据就是替换数据源的事，改动量小很多。WorkBuddy 的工作台里可以同时管理多个模块的生成进度，哪个模块到哪一步一目了然。

3.5 缓存目录和项目切换的配置要点

WorkBuddy 用久了缓存会变大，尤其是同时管理多个项目的时候。缓存目录默认在用户目录下，如果系统盘空间紧张，建议改到空间充裕的盘。改缓存目录的操作在设置里能找到，改完之后重启工作台生效。改之前记得把旧缓存清理掉，不然占着空间还容易出索引错乱的问题。

多项目切换时，注意每个项目的依赖环境是独立的。切换项目后如果发现依赖报错，先检查是不是用了全局依赖而不是项目内依赖。我踩过一次坑：两个项目用了同一个包的不同版本，因为装在全局，切换项目后版本冲突，排查了半天才发现是环境隔离没做好。后来养成习惯，每个项目都用独立的虚拟环境或容器，切换时不会有污染。

4. 联调、测试和上线前必须过的几道关

代码生成完不等于能上线，中间还有联调、测试、打包这几道关。这几步最枯燥，但也最容易出问题。AI 能帮你写测试用例，但测试策略和上线检查清单得自己定。

4.1 前后端联调：先对齐接口契约再动手

联调出问题，十有八九是接口契约没对齐。前端以为返回的是数组，后端返回的是对象；前端传的是字符串 ID，后端要的是数字。这些在联调时才发现，改起来两边都要动。

我的做法是在生成 API 之前，先让 AI 生成一份接口文档，明确每个接口的请求方法、路径、参数类型、返回结构。前后端都按这份文档来，联调时对不上就是实现问题，不是契约问题。这份文档用 OpenAPI 格式写，还能直接生成 mock 服务，前端不用等后端就能先联调。

4.2 测试用例：AI 生成 + 人工补边界

测试用例可以让 AI 生成基础版本，覆盖正常流程和常见异常。但 AI 生成的用例往往漏掉业务特有的边界情况，比如"订单金额为 0 时怎么处理""司机和乘客是同一人时怎么处理"。这些得人工补。

我一般让 AI 生成 70% 的用例，剩下 30% 自己根据业务理解补。补的时候重点想"什么情况下这个功能会出问题"，把这些情况写成用例。测试覆盖率不用追求 100%，但核心流程和资金相关的逻辑必须覆盖到。

4.3 打包上线：iOS 和 Android 的差异处理

移动端打包，iOS 和 Android 的流程差异不小。iOS 需要证书、描述文件、App Store Connect 配置，Android 需要签名密钥、渠道配置。这些配置第一次弄比较繁琐，弄好之后可以复用。

打包前必须检查的几项：版本号有没有更新、权限声明是否完整、隐私政策链接是否可访问、第三方 SDK 是否都配置了对应的 key。这几项漏一个都可能导致审核被拒。我习惯做一个上线检查清单，每次打包前过一遍，比凭记忆靠谱。

4.4 上线后的监控和快速回滚准备

上线不是终点，是另一个起点。上线后要能快速发现问题和快速回滚。监控至少要有崩溃日志、接口错误率、关键业务指标（比如订单创建成功率）。回滚方案要提前准备好，比如保留上一个版本的包、数据库变更要有回滚脚本。

我见过太多团队上线后出问题，手忙脚乱找不到回滚方案，只能现场改代码，越改越乱。提前准备好回滚方案，出问题时能几分钟内恢复到上一个稳定版本，把影响降到最低。

5. 90 天从入门到能独立交付的路径设计

前面讲的是单个项目的完整流程，这一节讲怎么用 90 天把自己练成能独立接项目的 FDE。这个路径不是速成，是把学习曲线拉平，让每个阶段都有明确的目标和产出。

5.1 第 1-30 天：把工具链跑通，做一个小而完整的项目

第一个月的目标不是做多复杂的东西，而是把"从需求到上线"这条链路完整走一遍。项目可以很简单，比如一个待办事项 App、一个记账工具。重点是把 WorkBuddy 的安装配置、需求卡片管理、AI Coding 接入、打包上线这几个环节都摸一遍。

这个阶段最容易犯的错是好高骛远，一上来就想做网约车这种复杂系统，结果卡在某个环节出不来，信心受挫。选一个两周能做完的小项目，完整走通流程，比做半个复杂项目有价值得多。做完之后复盘一遍，哪个环节卡了多久、为什么卡，这些经验比项目本身更值钱。

5.2 第 31-60 天：接真实需求，练需求澄清和方案设计

第二个月开始接触真实需求。可以找朋友的小生意、社区的小组织，帮他们做个简单的管理工具。真实需求的价值在于它不完美、不清晰，逼着你去澄清、去取舍。这个阶段重点练两件事：需求澄清的提问能力，和技术方案的选型能力。

需求澄清前面讲过框架，这里补充一点：澄清的时候要录音或做详细笔记，事后整理成需求文档让对方确认。口头确认过的东西，过两周对方可能就忘了或者改口了，有书面记录能避免扯皮。方案设计方面，这个阶段要开始有意识地在多个方案之间做权衡，比如为什么选这个数据库、为什么用这个框架，把理由写下来。

5.3 第 61-90 天：独立负责一个完整交付，建立自己的检查清单

第三个月的目标是独立负责一个完整交付，从需求到上线全程自己扛。这个阶段会遇到前两个月没遇到的各种意外：客户临时改需求、第三方服务对接出问题、上线审核被拒。处理这些意外的过程，就是 FDE 真正成长的过程。

这个阶段要开始建立自己的检查清单和工具库。检查清单包括需求澄清清单、上线检查清单、回滚预案清单。工具库包括常用的代码片段、配置模板、部署脚本。这些东西积累起来，后面做新项目时能省大量时间。90 天结束时，你应该有一套自己的方法论，而不是每次都从零开始。

5.4 持续精进：关注 AI Coding 工具的迭代方向

AI Coding 这个领域变化很快，模型能力、工具形态、最佳实践都在快速演进。保持关注的方式不是追每一条新闻，而是定期（比如每月）花半天时间试试新工具、新模型，看能不能融入自己的工作流。

我自己的习惯是每季度做一次工具链复盘：现在用的工具哪些还顺手、哪些已经被更好的替代、有没有新的环节可以自动化。这个复盘不用很正式，就是花点时间想想"哪里还能更快"。FDE 的核心竞争力不是会用某个具体工具，而是能快速学会新工具并把它用到位。

6. 几个容易翻车的细节和我的处理习惯

最后聊几个实操中容易翻车的细节，这些是文档里不会写、但实际做项目时经常遇到的。

6.1 AI 生成的代码必须过一遍再提交

AI 生成的代码质量参差不齐，直接提交风险很大。我见过 AI 生成的代码里有硬编码的密钥、有没处理的空指针、有 SQL 注入风险的拼接查询。这些如果直接上线，轻则出 bug，重则出安全事故。

我的习惯是 AI 生成的代码必须人工过一遍，重点看三处：安全相关（密钥、权限、输入校验）、异常处理（空值、超时、失败重试）、业务逻辑（是否符合需求）。过一遍花不了多少时间，但能挡掉大部分严重问题。

6.2 需求变更要留痕，口头确认不算数

项目做到一半客户改需求是常态，但改需求必须留痕。口头说的"这里改一下"，过两天可能就变成"我没说过"。每次需求变更都记录到需求卡片里，注明变更内容、变更时间、确认人。变更影响大的，让对方在需求文档上确认。

这个习惯一开始可能显得有点较真，但真出纠纷的时候，这些记录就是保护自己的证据。而且留痕本身也能帮双方理清思路，减少反复变更。

6.3 环境配置写成脚本，不要靠记忆

开发环境、测试环境、生产环境的配置差异，是很多诡异问题的根源。靠记忆去配环境，迟早会漏。我的做法是把环境配置写成脚本，每个环境一个脚本，需要的时候跑一下就行。脚本纳入版本管理，改了什么一目了然。

WorkBuddy 的项目切换功能配合环境脚本，切换项目时先跑对应环境的配置脚本，能避免大部分环境问题。这个习惯养成之后，换电脑、重装系统都不慌，跑一遍脚本环境就回来了。

6.4 上线前给自己留一个"冷静期"

代码写完、测试通过，别急着上线。留半天到一天的冷静期，期间不碰代码，去做点别的。冷静期结束后再回来看一遍上线检查清单，经常能发现之前忽略的问题。

这个习惯是我踩过坑之后养成的。有一次赶着上线，测试通过就直接发了，结果忘了更新某个配置项，上线后功能异常，半夜爬起来修。从那以后，再急的项目也留冷静期，宁可晚半天上线，也不半夜救火。

6.5 文档不是写给别人的，是写给三个月后的自己

很多人不爱写文档，觉得浪费时间。但 FDE 同时跟多个项目，三个月后回头看某个项目，没有文档根本想不起来当时为什么这么设计。文档不用写得很正式，关键决策、踩过的坑、待办事项记下来就行。

我一般用 WorkBuddy 的项目笔记功能记这些，跟需求卡片放在一起。下次接手类似项目时，翻一翻之前的笔记，能少走很多弯路。文档的价值不在于写得多漂亮，而在于需要的时候能找到关键信息。

这套流程和习惯不是一天养成的，我自己也是做了好几个项目之后才慢慢沉淀下来。刚开始做 FDE 的时候，我也试过跳过需求澄清直接写代码，结果返工到怀疑人生。后来老老实实按流程走，前期多花的时间，后期都省回来了。如果你刚开始接触这个角色，建议先从一个小项目完整走一遍，把每个环节都摸清楚，再逐步提速。工具会变，模型会升级，但"想清楚再做、做完要验证、上线留后路"这几条原则，什么时候都不过时。