WorkBuddy FDE 90天路径：从一句话需求到上线App的实战指南

一句话需求丢过来，三周后要看到能装进手机里的东西，这种场景在不少小团队里反复上演。WorkBuddy FDE 这套打法，就是冲着这种"需求模糊、时间紧、人手少"的处境来的。它把从一句话到上线 App 的全过程拆成可执行的阶段，核心不是教你写某个具体功能，而是让你掌握一套把模糊想法快速收敛成可交付产品的节奏感。适合独立开发者、小团队技术负责人，以及需要快速验证产品假设的产品同学。接下来我会把 90 天路径里的关键节点、每个阶段该做什么、容易在哪里翻车，按我实际跑过几轮的经验摊开讲。

1. 先搞清楚 FDE 到底在解决什么问题

1.1 一句话需求为什么总是变成灾难

"做个能记录每天心情的小工具，顺便能看趋势。"这句话丢给不同的人，能长出完全不同的东西。有人理解成极简打卡，有人理解成带社交的动态流，还有人直接上 AI 情绪分析。问题不在于需求本身模糊，而在于没有人把它翻译成"可验证的最小行为单元"。

FDE 的第一层含义就是 Front-end Driven Engineering 的变体——以最终用户能感知的界面行为为起点，反向推导数据结构和接口。传统做法是先设计数据库、再写 API、最后拼界面，结果往往是界面做出来发现数据模型根本支撑不了交互。FDE 把这个顺序倒过来：先画出用户点一下会发生什么，再倒推需要存什么、传什么。

我试过在一个内部工具项目里用传统顺序，光数据表就改了四版，每次改完前端都要跟着动。后来换成 FDE 思路，先拿纸画出三个核心界面的状态变化，半小时就把数据字段定下来了，因为每个字段都能对应到界面上某个具体元素的显示或隐藏。

1.2 90 天路径的节奏划分逻辑

90 天不是随便定的。前 30 天做需求收敛和技术验证，中间 30 天做核心功能闭环，最后 30 天做打磨和上线准备。这个划分的关键在于：每个阶段都有明确的"退出条件"，不满足就不进入下一阶段。

这个表看起来简单，但实际执行时最容易犯的错是"收敛期拖太久"。我见过一个项目在技术选型上纠结了六周，最后发现选哪个框架对最终产品影响不到 10%。收敛期的退出条件只有一个：端到端最小交互跑通，哪怕界面丑、数据假、只支持一个用户。

1.3 谁适合用这套路径，谁不适合

适合的情况：需求方只能给出一句话描述、团队没有专职产品经理、需要在三个月内看到可演示的东西、技术栈相对自由。

不适合的情况：已经有完整 PRD 和设计稿的项目、需要对接大量遗留系统的企业级应用、合规要求极高的领域。这些场景下 FDE 的快速迭代优势发挥不出来，反而会因为跳过详细设计而埋下隐患。

2. 收敛期：把一句话拆成可执行的任务清单

2.1 需求翻译的三层拆解法

拿到一句话需求后，我习惯做三层拆解。第一层是"用户动作"，第二层是"系统响应"，第三层是"数据变化"。以"记录心情"为例：

• 用户动作：点击"记录"按钮
• 系统响应：弹出输入框，显示当前时间
• 数据变化：新增一条记录，包含时间戳和文本内容

这三层拆完，你会发现很多隐含假设浮出水面。比如"显示当前时间"意味着需要获取设备时间，"新增记录"意味着需要本地存储或远端存储。每个假设都是一个待确认的技术决策点。

拆解时有个技巧：用"如果……那么……"的句式逼自己补全边界。如果用户不输入内容直接点保存，那么应该怎么处理？如果同一天记录多次，那么趋势图怎么展示？这些问题在写代码之前问出来，比写完再改成本低得多。

2.2 技术选型的最小验证法

收敛期最忌讳的是"选型靠感觉"。我的做法是：对每个候选方案，只验证一个最关键的不确定点。比如选本地存储还是远端存储，不确定的是"离线场景下数据一致性怎么保证"，那就写一个最小 demo，模拟断网后新增数据、恢复网络后同步，看冲突处理是否可接受。

这个验证不需要完整实现，可能就几十行代码。但它的价值在于：用最小成本排除掉明显不合适的方案。我试过在一个项目里同时验证了三种存储方案，每种只花半天，最后选定的方案在后续开发中几乎没有返工。

注意：最小验证的代码不要直接进主分支，单独开一个验证分支或者临时目录，验证完就删。这些代码的质量标准是"能跑通逻辑"，不是"能上线"。

2.3 收敛期的常见翻车点

第一个翻车点是"需求蔓延"。验证过程中突然觉得"这个功能顺便也做了吧"，结果收敛期变成半个开发期。我的应对方法是：所有新想法记在一个"待评估清单"里，收敛期结束前不碰。

第二个翻车点是"技术选型过度比较"。三个候选方案各写一个 demo 就够了，不要试图把每个方案的优缺点都列全。实际项目中，选型的决定性因素往往只有一两个，其他差异在三个月周期里根本体现不出来。

第三个翻车点是"没有真实用户参与"。收敛期的验证如果只靠自己拍脑袋，很容易做出"自己觉得好用但别人不会用"的东西。哪怕只找两三个目标用户聊十分钟，也能发现大量盲区。

3. 闭环期：让核心功能真正跑起来

3.1 主流程优先于边缘功能

闭环期的唯一目标是"真实用户能完成主流程"。什么叫主流程？就是用户打开 App 后，为了达成核心目的必须经过的最短路径。心情记录工具的主流程是：打开 → 记录 → 查看记录。其他所有功能都是边缘功能。

我见过太多项目在闭环期把时间花在设置页、主题切换、分享功能上，结果主流程还有 bug。正确的做法是：主流程的每个环节都做到"能用且不崩溃"，边缘功能先放占位符或者直接隐藏。

具体操作上，我会把主流程的每个步骤写成一个检查项，每天结束时过一遍。比如：

1. 冷启动后 3 秒内能看到主界面
2. 点击记录按钮能正常弹出输入
3. 保存后列表能立即刷新
4. 杀掉进程重开数据不丢失

这四个检查项全部通过，才算闭环期达标。

3.2 数据层的稳定性设计

闭环期最容易出问题的是数据层。本地存储要考虑并发写入、远端存储要考虑网络异常。我的经验是：不管最终选什么存储方案，都在数据层加一个"操作队列"。

操作队列的逻辑很简单：所有写操作先进入队列，由队列按顺序执行。这样即使用户快速点击多次保存，也不会出现数据覆盖或顺序错乱。队列的实现不需要很复杂，一个数组加一个执行标志位就够了。

// 简化的操作队列示例 const queue = []; let isProcessing = false; function enqueue(operation) { queue.push(operation); processQueue(); } async function processQueue() { if (isProcessing) return; isProcessing = true; while (queue.length > 0) { const op = queue.shift(); try { await op(); } catch (e) { console.error('操作失败', e); } } isProcessing = false; }

这段代码看起来简单，但它解决的是闭环期最让人头疼的"偶现数据错乱"问题。我试过在一个项目里因为没加队列，用户快速点击保存导致两条记录互相覆盖，排查了半天才定位到。

3.3 闭环期的用户反馈循环

闭环期一定要有真实用户在用。哪怕只有三五个，也要让他们每天用，然后收集反馈。反馈的收集方式不需要很正式，一个共享文档或者群聊里问一句"今天用下来哪里别扭"就够了。

关键是反馈的处理节奏：每天固定时间看反馈，分类成"必须修"和"可以等"。"必须修"的标准是：影响主流程完成，或者导致数据丢失。"可以等"的统统进待评估清单，闭环期不碰。

我踩过的坑是：闭环期听到用户说"要是有个搜索功能就好了"，然后花三天做了搜索，结果主流程的保存失败问题没修，用户直接不用了。后来我定了个规矩：闭环期只修主流程相关问题，新功能一律等打磨期。

4. 打磨期：从能用到好用的关键动作

4.1 性能优化的优先级判断

打磨期最容易陷入"什么都想优化"的状态。我的判断标准是：只优化用户能感知到的卡顿。具体来说，冷启动超过 3 秒、列表滚动掉帧、点击后超过 500 毫秒没响应，这三个是必须解决的。其他性能指标，只要不影响使用，都可以放。

优化的顺序也有讲究。先做"减少工作量"的优化，比如缓存计算结果、延迟加载非首屏内容；再做"加快执行"的优化，比如换更快的算法、用更高效的数据结构。前者往往收益更大且风险更低。

我试过在一个列表页做优化，一开始想换虚拟滚动组件，后来发现只是每次渲染都重新计算了排序，加个缓存就解决了。所以优化前先定位瓶颈，不要凭感觉换方案。

4.2 异常处理与降级策略

打磨期必须把异常路径走一遍。网络断了怎么办？存储满了怎么办？权限被拒了怎么办？这些场景在开发期很少遇到，但上线后一定会出现。

我的做法是：对每个可能失败的操作用户可见的地方，都设计一个降级方案。比如远端同步失败时，先存本地并提示"将在网络恢复后同步"；存储写入失败时，提示用户清理空间并保留当前输入内容。

降级策略的核心原则是：不要让用户丢失已经输入的数据。哪怕功能不可用，也要让用户能把数据复制出来。这个原则看起来简单，但实际做的时候很容易忽略。我见过一个工具在保存失败时直接清空了输入框，用户当场就卸载了。

4.3 上线前的验收清单

上线前我会过一遍固定的验收清单，这个清单是根据多次踩坑总结出来的：

这个清单不需要很复杂，但每一项都要实际验证，不能靠"应该没问题"。我试过因为没验证后台恢复，上线后发现用户切出去接个电话回来数据就没了，紧急发版修复。

5. 90 天里最容易踩的五个坑

5.1 把"快速"理解成"跳过设计"

FDE 强调快速，但不等于不设计。跳过设计的结果往往是写到一半发现数据结构支撑不了交互，然后大改。我的做法是：用半天时间画清楚核心界面的状态流转，这个时间投入在后续开发中能省下至少三天。

状态流转图不需要很正式，纸上画几个框加箭头就行。关键是每个框代表一个界面状态，箭头代表触发状态变化的行为。画完之后，数据字段自然就出来了。

5.2 过早引入复杂架构

90 天周期里，大部分项目用不上复杂的架构模式。我见过在三人小团队里上微服务、上消息队列、上容器编排的，结果光环境搭建就花了两周。这个周期的项目，单体架构加清晰的模块划分就够了。

模块划分的标准是：每个模块只做一件事，模块之间通过明确的接口通信。比如数据模块只管存取，UI 模块只管展示，业务逻辑放在中间层。这个划分不需要框架支持，靠目录结构和代码规范就能实现。

5.3 忽视真机测试

模拟器上跑得好好的，真机上各种问题。这个坑我踩过不止一次。真机和模拟器的差异主要在：性能、权限、存储路径、网络环境。打磨期一定要在至少两台不同档次的真机上跑主流程。

真机测试的重点不是功能，而是体验。比如列表滚动是否跟手、点击反馈是否及时、键盘弹出是否遮挡输入框。这些问题在模拟器上很难发现，但直接影响用户留存。

5.4 没有预留缓冲时间

90 天路径排得很满，但实际执行中一定会有意外。我的经验是：每个阶段预留 20% 的缓冲时间。收敛期 30 天，实际按 24 天排任务；闭环期 30 天，按 24 天排；打磨期 30 天，按 24 天排。剩下的 18 天用来处理意外。

这个缓冲不是偷懒，而是对现实的尊重。需求变更、技术难题、人员请假，这些都会发生。没有缓冲的计划，一旦出意外就会全线延期。

5.5 上线即结束的心态

上线不是终点，而是另一个起点。上线后的第一周要密切监控崩溃率和用户反馈，及时修复严重问题。我习惯在上线后保持每天看一次崩溃日志，持续两周。

崩溃日志里最值得关注的是"高频但低影响"的问题。比如某个页面在特定机型上闪退，虽然用户量不大，但说明代码有隐患。这类问题修起来往往很快，但不修可能在某次系统更新后变成大面积问题。

6. 几个能直接抄的实操模板

6.1 需求翻译模板

拿到一句话需求后，按这个模板填一遍：

原始需求：[一句话] 用户动作：[用户会做什么] 系统响应：[系统应该怎么反应] 数据变化：[需要存什么] 边界情况：[如果不……那么……] 最小验证：[用最简单的方式验证什么]

填完这个模板，基本就能判断需求是否足够清晰。如果某个字段填不出来，说明还需要跟需求方确认。

6.2 每日检查模板

闭环期和打磨期每天花五分钟填这个：

今日目标：[今天要完成什么] 实际完成：[实际做了什么] 阻塞问题：[遇到什么卡住了] 明日计划：[明天第一件事做什么]

这个模板的价值不在于记录，而在于逼自己每天明确"今天最重要的一件事是什么"。我试过不写这个，结果每天忙忙碌碌但主流程没进展。

6.3 上线检查脚本

如果做的是 Web 或跨平台应用，可以把部分检查写成脚本自动跑：

#!/bin/bash # 简化的上线前检查脚本 echo "检查构建产物..." if [ ! -f "dist/app.js" ]; then echo "构建产物缺失" exit 1 fi echo "检查关键资源..." for file in "index.html" "manifest.json"; do if [ ! -f "dist/$file" ]; then echo "缺少 $file" exit 1 fi done echo "检查通过"

脚本能自动化的部分有限，但至少能避免"忘记构建"或"漏打包资源"这种低级错误。

6.4 用户反馈分类表

收集到反馈后，按这个表分类：

这个表的关键是"处理阶段"这一列。很多反馈不是不重要，而是不该在当前阶段处理。明确这一点能避免频繁切换上下文。

7. 关于 90 天路径的个人体会

跑过几轮 90 天周期后，我最大的体会是：时间盒的价值不在于"逼你快"，而在于"逼你取舍"。当你知道只有 90 天时，自然会砍掉那些"看起来不错但非核心"的功能，把精力集中在真正影响用户完成主流程的事情上。

另一个体会是：FDE 这套方法对技术负责人的要求其实更高。你需要同时具备需求翻译能力、技术判断力和节奏把控力。缺了任何一项，要么做出来的东西不是用户要的，要么技术方案撑不住，要么进度失控。

最后分享一个我一直在用的小技巧：每个阶段结束时，花半小时写一段"如果重来一次我会怎么做"的复盘。不需要很长，三五句话就行。这些复盘积累下来，下一轮 90 天周期至少能少踩一半的坑。