从一句话需求到上线App：FDE工作台与AI Coding的90天交付路径

1. 从一句话需求到上线 App 的整体思路拆解

1.1 为什么“一句话需求”反而更难做

很多人觉得需求越简单越好做，实际情况恰恰相反。“帮我做一个约球 App”这种一句话需求，信息量几乎为零，但隐含的决策点可能有几十个：用户怎么注册、场地怎么来、支付走不走、消息推送用哪家、后台谁来管。真正的难点不在于写代码，而在于把一句话拆成可执行的任务清单。

WorkBuddy 这类 FDE（Forward Deployed Engineer，前置交付工程师）工作台的价值就在这里。它不是单纯的代码生成器，而是一套把“模糊需求 → 结构化任务 → 可运行代码 → 可上线产物”串起来的流程系统。我把它理解成一个“需求翻译层 + 工程脚手架 + 交付流水线”的组合体。

FDE 这个角色在海外已经比较成熟，核心特征是：直接面对业务方，同时具备工程落地能力，一个人能从需求沟通走到部署上线。国内越来越多团队开始设这个岗，WorkBuddy 这类工具就是为这种“单人全栈交付”场景设计的。

1.2 整体链路的四个阶段

我把从一句话到上线的完整链路拆成四段，后面所有内容都围绕这四段展开：

• 需求结构化：把一句话拆成用户故事、数据实体、页面清单、接口清单
• 技术选型与脚手架：确定前端框架、后端框架、数据库、部署方式，生成项目骨架
• AI Coding 迭代：用 AI 辅助编码，逐模块实现，边写边验证
• 交付与上线：打包、部署、域名、监控、灰度

这四个阶段不是线性的，实际做的时候会在二三阶段之间反复横跳。但心里有这个框架，就不会迷路。

1.3 90 天路径的分配逻辑

标题里提到 90 天路径，我按实际交付经验给一个参考分配：

这个分配的前提是单人全职投入。如果是业余时间做，整体周期要乘以 2 到 2.5。我见过太多人低估了“打磨与上线”这一段，实际上线前的联调、兼容、文案、图标、隐私政策这些琐事，能吃掉整个项目 30% 的时间。

2. 需求结构化：把一句话拆成可执行清单

2.1 用户故事拆解法

拿到“做一个约球 App”这种需求，第一步不是打开编辑器，而是拿张纸（或者打开 WorkBuddy 的需求面板）做用户故事拆解。我习惯用“角色 + 动作 + 目的”的句式：

• 作为普通用户，我想按位置搜索附近的球场，以便快速找到能去的地方
• 作为发起人，我想创建一场约球并设置人数上限，以便控制场地人数
• 作为参与者，我想报名并看到已报名名单，以便确认有没有熟人

每个用户故事再往下拆成验收标准。比如“按位置搜索球场”的验收标准是：输入地址后 2 秒内返回结果、结果按距离排序、无结果时给出友好提示。这一步做扎实，后面写代码时几乎不用再想“这个功能到底要做什么”。

2.2 数据实体与关系梳理

用户故事拆完，自然能提取出数据实体。约球 App 的核心实体大概有这些：

• User：id、昵称、头像、手机号、位置
• Venue：id、名称、地址、经纬度、营业时间、价格
• Event：id、发起人、场地、开始时间、人数上限、当前人数、状态
• Registration：id、event_id、user_id、报名时间、状态

实体之间的关系用一句话说清楚：一个 User 可以发起多个 Event，一个 Event 属于一个 Venue，一个 Event 有多个 Registration。这套关系直接决定了数据库表结构，也决定了后端接口的设计。

提示：实体梳理阶段一定要把“状态字段”想清楚。比如 Event 的状态有“招募中、已满员、已开始、已结束、已取消”，这些状态之间的流转规则如果不提前定，后面会到处打补丁。

2.3 页面清单与接口清单

实体确定后，页面清单基本就出来了：

1. 首页（附近球场 + 热门约球）
2. 球场详情页
3. 创建约球页
4. 约球详情页（含报名按钮和名单）
5. 个人中心（我的约球、我的报名）

每个页面需要哪些接口，也顺手列出来。比如约球详情页需要：GET /events/:id、POST /events/:id/register、DELETE /events/:id/register、GET /events/:id/registrations。这份清单就是后面 AI Coding 的“任务输入”，越具体，AI 生成的代码越准。

2.4 用 WorkBuddy 做需求结构化的实操

WorkBuddy 的需求面板支持把用户故事直接转成任务卡片。我的做法是：先把上面拆好的用户故事一条条录进去，每条卡片带上验收标准；然后用它的“任务依赖”功能把卡片串起来，比如“创建约球”依赖“球场列表”先完成。

这一步的产出物是一份任务看板，每个卡片对应一个可独立开发、可独立验证的功能点。我实测下来，一个中等复杂度的 App，需求结构化阶段能拆出 40 到 80 张卡片。卡片粒度控制在“半天到两天能做完”比较合适，太粗容易失控，太细管理成本高。

3. 技术选型与脚手架搭建

3.1 技术栈选择的三个约束

选技术栈不是选最流行的，而是选最匹配约束的。我一般看三个约束：

• 团队能力：一个人做，就选自己最熟的；有协作，就选生态好、文档全的
• 交付周期：90 天要上线，就别碰需要大量自建基础设施的方案
• 运维成本：没有专职运维，就选托管服务，别自己搭服务器集群

基于这三点，约球 App 这种中等复杂度项目，我的默认选型是：前端用 React 或 Vue，后端用 Node.js（Express 或 NestJS）或 Python（FastAPI），数据库用 PostgreSQL，部署用托管平台。这套组合的好处是生态成熟、AI 训练语料多、遇到问题容易搜到答案。

3.2 用 AI Coding 生成项目骨架

技术栈定了之后，用 AI Coding 工具生成骨架。这里的关键是提示词要给足上下文。我常用的提示词结构是：

技术栈：React + Vite + TypeScript，后端 FastAPI + PostgreSQL 项目结构：前端 frontend/，后端 backend/ 需要生成：目录结构、依赖清单、基础配置文件、健康检查接口 约束：前端用 pnpm，后端用 poetry，都要有 .env.example

DeepSeek 这类模型在生成脚手架代码时表现不错，尤其是配置文件这种模式化内容。但要注意，AI 生成的依赖版本可能过时，生成后一定要手动核对package.json和pyproject.toml里的版本号，把明显过时的依赖升到当前稳定版。

3.3 数据库迁移与种子数据

骨架搭好后，第一件事是把数据模型落成迁移文件。我用 Alembic（Python）或 Prisma Migrate（Node）来管理迁移。每个实体一张表，字段类型和约束按需求阶段定的来。

种子数据很重要，别跳过。准备一份seed.sql或seed.py，插入 10 个球场、20 个用户、5 场约球。这样前端一跑起来就有数据可看，联调效率高很多。我见过有人等到前端页面全写完才想起来没数据，结果调试时到处是空状态，浪费大量时间。

3.4 环境变量与配置管理

配置管理是新手最容易埋雷的地方。我的原则是：所有环境相关的值都走环境变量，代码里不出现任何硬编码的地址、密钥、端口。

一份典型的.env.example长这样：

DATABASE_URL=postgresql://user:pass@localhost:5432/workbuddy JWT_SECRET=change_me_in_production MAP_API_KEY=your_map_key PORT=8000

.env文件加进.gitignore，.env.example提交到仓库。这样别人克隆下来就知道要配哪些变量。WorkBuddy 的工作台里可以配置环境变量模板，切换环境时自动注入，省去手动改配置的麻烦。

4. 核心功能开发与 AI Coding 实战

4.1 从任务卡片到代码的映射

需求阶段的每张卡片，对应开发阶段的一个提交（或一组提交）。我的习惯是：一张卡片开一个分支，分支名用卡片编号，比如feat/EVENT-012-create-event。这样代码和需求能对上，后面查问题方便。

AI Coding 在这个阶段的作用是“加速实现”，不是“替代思考”。具体做法是：把卡片的验收标准、相关数据模型、接口约定一起喂给 AI，让它生成初版代码，然后自己审一遍，改掉不合理的地方。我实测下来，AI 生成的代码大概能直接用 60%，剩下 40% 需要调整——主要是边界处理、错误提示、类型定义这些细节。

4.2 后端接口开发示例

以“创建约球”接口为例，验收标准是：登录用户可创建、必填字段校验、场地必须存在、时间必须晚于当前、人数上限 2 到 50。

用 FastAPI 实现大概是这样：

from fastapi import APIRouter, Depends, HTTPException from pydantic import BaseModel, Field, validator from datetime import datetime router = APIRouter() class EventCreate(BaseModel): venue_id: int start_time: datetime max_participants: int = Field(ge=2, le=50) description: str = "" @validator("start_time") def start_time_must_be_future(cls, v): if v <= datetime.now(): raise ValueError("开始时间必须晚于当前时间") return v @router.post("/events") def create_event(payload: EventCreate, user=Depends(get_current_user), db=Depends(get_db)): venue = db.query(Venue).get(payload.venue_id) if not venue: raise HTTPException(status_code=404, detail="场地不存在") event = Event( creator_id=user.id, venue_id=payload.venue_id, start_time=payload.start_time, max_participants=payload.max_participants, description=payload.description, status="recruiting", ) db.add(event) db.commit() db.refresh(event) return event

这段代码里，校验逻辑用 Pydantic 的 validator 做，业务校验（场地存在）在接口里做，状态初始化在创建时定。分层清晰，后面加逻辑不会乱。

4.3 前端页面开发要点

前端我建议先做“数据流”，再做“样式”。具体说，就是先把接口调通、状态管理跑通，页面丑一点没关系；等数据流稳了，再统一调样式。反过来做的话，样式改一遍、数据流改一遍，返工量翻倍。

以约球详情页为例，数据流是：进入页面 → 请求GET /events/:id→ 渲染基本信息 → 请求GET /events/:id/registrations→ 渲染名单 → 根据当前用户是否已报名，决定按钮显示“报名”还是“取消报名”。

状态管理用 React 的话，小项目用 Context + useReducer 就够了，别一上来就上 Redux。我见过太多项目为了“规范”引入重型状态库，结果代码量翻倍，收益几乎为零。

4.4 AI Coding 的提示词技巧

用 AI 写代码，提示词质量直接决定产出质量。我总结了几个实用技巧：

• 给上下文：把相关的类型定义、接口签名、已有代码片段一起贴进去
• 给约束：明确说“不要引入新依赖”“用现有的 xxx 工具函数”“错误处理用统一的 handleError”
• 给示例：贴一段项目里已有的、风格一致的代码，让 AI 照着写
• 分步要：别一次让它写整个模块，一次一个函数或一个组件，质量高很多

注意：AI 生成的代码一定要跑测试。我踩过的坑是 AI 写了一个“看起来对”的排序逻辑，实际跑起来发现边界条件处理错了，导致列表顺序偶尔乱掉。这种问题不跑测试根本发现不了。

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

5.1 环境与依赖类问题

问题一：本地能跑，部署后报错。九成是环境变量没配全，或者本地和线上的依赖版本不一致。排查方法：把.env.example和线上环境变量逐项对比，用pip freeze或pnpm list导出依赖清单，和线上对比。

问题二：数据库连接超时。先确认数据库地址和端口对不对，再确认网络是否可达，最后看连接池配置。托管数据库通常有连接数上限，连接池开太大反而会触发限制。

问题三：缓存目录混乱导致构建失败。这类工具类问题，WorkBuddy 的缓存目录可以在设置里改，改完记得重启工作台。缓存目录别放在系统盘，也别放在同步盘（比如某些云盘同步目录），同步冲突会导致文件锁死。

5.2 功能逻辑类问题

问题四：报名人数超过上限。这是典型的并发问题。两个用户同时报名，都读到“当前 9 人，上限 10 人”，都判断可以报名，结果变成 11 人。解决办法是在数据库层加约束，或者用行锁。最简单的是在registrations表上加唯一索引，报名时用INSERT ... ON CONFLICT DO NOTHING，再检查插入结果。

问题五：时间显示不对。时区问题。数据库存 UTC，前端按用户时区渲染。别在数据库里存本地时间，后患无穷。

问题六：列表分页错乱。排序字段不唯一导致的。比如按创建时间排序，同一秒创建的两条记录顺序不稳定。解决办法是排序时加一个唯一字段做次级排序，比如ORDER BY created_at DESC, id DESC。

5.3 上线交付类问题

问题七：域名解析不生效。先确认 DNS 记录类型对不对（A 记录指向 IP，CNAME 指向域名），再确认 TTL 有没有过期，最后用dig或nslookup验证。刚改完记录通常要等几分钟到几小时。

问题八：HTTPS 证书报错。托管平台一般自动签证书，如果报错，检查域名是否已正确解析到平台、是否开启了强制 HTTPS。自签证书的话，注意证书链要完整。

问题九：移动端浏览器唤起安装。这个需求在 iOS 和 Android 上行为不同。iOS 用 Safari 的“添加到主屏幕”，Android 用 Web App Manifest。别指望一套代码两端完全一致，做好降级提示。

5.4 常见问题速查表

5.5 独家避坑经验

第一条，别在周五下午上线。上线后出问题，周末没人配合排查，只能干着急。周二周三上线最稳，出问题有完整工作日处理。

第二条，上线前跑一遍完整主流程。从注册到创建约球到报名到取消，手动走一遍。自动化测试覆盖不到的地方，手动走一遍能发现大量问题。

第三条，留回滚方案。部署平台一般支持版本回滚，上线前确认回滚按钮在哪、怎么用。数据库迁移要写 down 脚本，别只写 up。

第四条，监控和日志先于功能上线。至少要有错误日志收集和基础的健康检查。没有日志的线上系统，出问题就是盲人摸象。

6. 90 天路径的节奏控制与交付清单

6.1 前 30 天：把地基打牢

前 30 天的目标不是“做出功能”，而是“把地基打牢”。具体包括：需求文档定稿、数据模型定稿、脚手架跑通、CI/CD 配好、第一个端到端功能（比如用户注册登录）跑通。

这个阶段最容易犯的错是急着写业务代码。地基没打好，后面每加一个功能都要返工。我见过一个项目，做到第 40 天发现数据模型设计有问题，改模型导致前面所有接口重写，直接损失两周。

6.2 中间 30 天：核心功能冲刺

第 31 到 60 天是功能冲刺期。按任务看板从上往下做，每完成一张卡片就部署到测试环境验证。这个阶段的节奏是“小步快跑”：一天完成一到两张卡片，每天结束前把当天代码合并到主分支并部署。

冲刺期要控制范围。需求会不断冒出来，我的原则是：不影响主流程的需求一律记下来，放到上线后再说。主流程就是“用户能注册、能创建约球、能报名、能取消”，其他都是锦上添花。

6.3 后 30 天：打磨与上线

最后 30 天做三件事：修 bug、补文案和图标、准备上线材料。上线材料包括隐私政策、用户协议、应用图标、启动页、应用商店描述（如果要上架）。

这个阶段最耗时的往往是“非技术”部分。隐私政策要写、图标要设计、截图要准备，这些事看着简单，加起来能占一周。提前准备，别等到最后。

6.4 交付清单

上线前对照这份清单逐项确认：

• 所有核心功能在主流程上跑通
• 错误日志和健康检查已配置
• 数据库有备份策略
• 环境变量在线上已配全
• 域名和 HTTPS 正常
• 隐私政策和用户协议已就位
• 回滚方案已确认
• 至少一轮完整的手动回归测试

这份清单看着基础，但每一条都是踩过坑总结出来的。我个人的体会是，上线这件事，准备得再充分都不为过，因为线上出问题的代价远高于多花两天准备。

6.5 后续扩展方向

上线不是终点。约球 App 上线后可以扩展的方向很多：场地评价、约球群聊、战绩记录、场地预约支付、球队管理。但别一上线就全铺开，先看用户反馈，哪个功能呼声高先做哪个。

技术层面，用户量上来后要考虑的扩展点：数据库读写分离、接口缓存、CDN 加速静态资源、消息推送服务化。这些等有实际压力再做，提前做就是过度设计。

我个人在实际操作中的体会是，从一句话需求到上线，最难的不是技术，而是“把模糊变清晰”的能力。需求拆得越细，后面越顺；地基打得越牢，上层越稳。WorkBuddy 这类工具能加速这个过程，但替代不了思考。工具是放大器，方向对了它帮你跑得更快，方向错了它帮你错得更快。