一句话需求丢过来三周后要看到能装进手机里的东西这种场景在不少小团队里反复上演。WorkBuddy FDE 这套打法就是冲着这种需求模糊、时间紧、人手少的处境来的。它把从一句话到上线 App 的全过程拆成可执行的阶段核心不是教你写某个具体功能而是让你掌握一套把模糊想法快速收敛成可交付产品的节奏感。适合独立开发者、小团队技术负责人以及需要快速验证产品假设的产品同学。接下来我会把 90 天路径里的关键节点、每个阶段该做什么、容易在哪里翻车按我实际跑过几轮的经验摊开讲。1. 先搞清楚 FDE 到底在解决什么问题1.1 一句话需求为什么总是变成灾难做个能记录每天心情的小工具顺便能看趋势。这句话丢给不同的人能长出完全不同的东西。有人理解成极简打卡有人理解成带社交的动态流还有人直接上 AI 情绪分析。问题不在于需求本身模糊而在于没有人把它翻译成可验证的最小行为单元。FDE 的第一层含义就是 Front-end Driven Engineering 的变体——以最终用户能感知的界面行为为起点反向推导数据结构和接口。传统做法是先设计数据库、再写 API、最后拼界面结果往往是界面做出来发现数据模型根本支撑不了交互。FDE 把这个顺序倒过来先画出用户点一下会发生什么再倒推需要存什么、传什么。我试过在一个内部工具项目里用传统顺序光数据表就改了四版每次改完前端都要跟着动。后来换成 FDE 思路先拿纸画出三个核心界面的状态变化半小时就把数据字段定下来了因为每个字段都能对应到界面上某个具体元素的显示或隐藏。1.2 90 天路径的节奏划分逻辑90 天不是随便定的。前 30 天做需求收敛和技术验证中间 30 天做核心功能闭环最后 30 天做打磨和上线准备。这个划分的关键在于每个阶段都有明确的退出条件不满足就不进入下一阶段。阶段天数核心目标退出条件收敛期1-30需求翻译 技术选型验证能跑通一个端到端的最小交互闭环期31-60核心功能完整可用真实用户能完成主流程打磨期61-90稳定性 体验 上线通过内部验收清单这个表看起来简单但实际执行时最容易犯的错是收敛期拖太久。我见过一个项目在技术选型上纠结了六周最后发现选哪个框架对最终产品影响不到 10%。收敛期的退出条件只有一个端到端最小交互跑通哪怕界面丑、数据假、只支持一个用户。1.3 谁适合用这套路径谁不适合适合的情况需求方只能给出一句话描述、团队没有专职产品经理、需要在三个月内看到可演示的东西、技术栈相对自由。不适合的情况已经有完整 PRD 和设计稿的项目、需要对接大量遗留系统的企业级应用、合规要求极高的领域。这些场景下 FDE 的快速迭代优势发挥不出来反而会因为跳过详细设计而埋下隐患。2. 收敛期把一句话拆成可执行的任务清单2.1 需求翻译的三层拆解法拿到一句话需求后我习惯做三层拆解。第一层是用户动作第二层是系统响应第三层是数据变化。以记录心情为例用户动作点击记录按钮系统响应弹出输入框显示当前时间数据变化新增一条记录包含时间戳和文本内容这三层拆完你会发现很多隐含假设浮出水面。比如显示当前时间意味着需要获取设备时间新增记录意味着需要本地存储或远端存储。每个假设都是一个待确认的技术决策点。拆解时有个技巧用如果……那么……的句式逼自己补全边界。如果用户不输入内容直接点保存那么应该怎么处理如果同一天记录多次那么趋势图怎么展示这些问题在写代码之前问出来比写完再改成本低得多。2.2 技术选型的最小验证法收敛期最忌讳的是选型靠感觉。我的做法是对每个候选方案只验证一个最关键的不确定点。比如选本地存储还是远端存储不确定的是离线场景下数据一致性怎么保证那就写一个最小 demo模拟断网后新增数据、恢复网络后同步看冲突处理是否可接受。这个验证不需要完整实现可能就几十行代码。但它的价值在于用最小成本排除掉明显不合适的方案。我试过在一个项目里同时验证了三种存储方案每种只花半天最后选定的方案在后续开发中几乎没有返工。注意最小验证的代码不要直接进主分支单独开一个验证分支或者临时目录验证完就删。这些代码的质量标准是能跑通逻辑不是能上线。2.3 收敛期的常见翻车点第一个翻车点是需求蔓延。验证过程中突然觉得这个功能顺便也做了吧结果收敛期变成半个开发期。我的应对方法是所有新想法记在一个待评估清单里收敛期结束前不碰。第二个翻车点是技术选型过度比较。三个候选方案各写一个 demo 就够了不要试图把每个方案的优缺点都列全。实际项目中选型的决定性因素往往只有一两个其他差异在三个月周期里根本体现不出来。第三个翻车点是没有真实用户参与。收敛期的验证如果只靠自己拍脑袋很容易做出自己觉得好用但别人不会用的东西。哪怕只找两三个目标用户聊十分钟也能发现大量盲区。3. 闭环期让核心功能真正跑起来3.1 主流程优先于边缘功能闭环期的唯一目标是真实用户能完成主流程。什么叫主流程就是用户打开 App 后为了达成核心目的必须经过的最短路径。心情记录工具的主流程是打开 → 记录 → 查看记录。其他所有功能都是边缘功能。我见过太多项目在闭环期把时间花在设置页、主题切换、分享功能上结果主流程还有 bug。正确的做法是主流程的每个环节都做到能用且不崩溃边缘功能先放占位符或者直接隐藏。具体操作上我会把主流程的每个步骤写成一个检查项每天结束时过一遍。比如冷启动后 3 秒内能看到主界面点击记录按钮能正常弹出输入保存后列表能立即刷新杀掉进程重开数据不丢失这四个检查项全部通过才算闭环期达标。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 上线前的验收清单上线前我会过一遍固定的验收清单这个清单是根据多次踩坑总结出来的检查项通过标准冷启动3 秒内可见主界面主流程完整走通 10 次无异常数据持久化杀进程重开数据完整异常提示断网、存储满、权限拒绝均有提示返回键各页面返回逻辑正确后台恢复切后台再回来状态不丢失这个清单不需要很复杂但每一项都要实际验证不能靠应该没问题。我试过因为没验证后台恢复上线后发现用户切出去接个电话回来数据就没了紧急发版修复。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 天周期至少能少踩一半的坑。 
长河君 · 2026/10/10 21:10:26 · 阅读 1.2k 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 天做打磨和上线准备。这个划分的关键在于每个阶段都有明确的退出条件不满足就不进入下一阶段。阶段天数核心目标退出条件收敛期1-30需求翻译 技术选型验证能跑通一个端到端的最小交互闭环期31-60核心功能完整可用真实用户能完成主流程打磨期61-90稳定性 体验 上线通过内部验收清单这个表看起来简单但实际执行时最容易犯的错是收敛期拖太久。我见过一个项目在技术选型上纠结了六周最后发现选哪个框架对最终产品影响不到 10%。收敛期的退出条件只有一个端到端最小交互跑通哪怕界面丑、数据假、只支持一个用户。1.3 谁适合用这套路径谁不适合适合的情况需求方只能给出一句话描述、团队没有专职产品经理、需要在三个月内看到可演示的东西、技术栈相对自由。不适合的情况已经有完整 PRD 和设计稿的项目、需要对接大量遗留系统的企业级应用、合规要求极高的领域。这些场景下 FDE 的快速迭代优势发挥不出来反而会因为跳过详细设计而埋下隐患。2. 收敛期把一句话拆成可执行的任务清单2.1 需求翻译的三层拆解法拿到一句话需求后我习惯做三层拆解。第一层是用户动作第二层是系统响应第三层是数据变化。以记录心情为例用户动作点击记录按钮系统响应弹出输入框显示当前时间数据变化新增一条记录包含时间戳和文本内容这三层拆完你会发现很多隐含假设浮出水面。比如显示当前时间意味着需要获取设备时间新增记录意味着需要本地存储或远端存储。每个假设都是一个待确认的技术决策点。拆解时有个技巧用如果……那么……的句式逼自己补全边界。如果用户不输入内容直接点保存那么应该怎么处理如果同一天记录多次那么趋势图怎么展示这些问题在写代码之前问出来比写完再改成本低得多。2.2 技术选型的最小验证法收敛期最忌讳的是选型靠感觉。我的做法是对每个候选方案只验证一个最关键的不确定点。比如选本地存储还是远端存储不确定的是离线场景下数据一致性怎么保证那就写一个最小 demo模拟断网后新增数据、恢复网络后同步看冲突处理是否可接受。这个验证不需要完整实现可能就几十行代码。但它的价值在于用最小成本排除掉明显不合适的方案。我试过在一个项目里同时验证了三种存储方案每种只花半天最后选定的方案在后续开发中几乎没有返工。注意最小验证的代码不要直接进主分支单独开一个验证分支或者临时目录验证完就删。这些代码的质量标准是能跑通逻辑不是能上线。2.3 收敛期的常见翻车点第一个翻车点是需求蔓延。验证过程中突然觉得这个功能顺便也做了吧结果收敛期变成半个开发期。我的应对方法是所有新想法记在一个待评估清单里收敛期结束前不碰。第二个翻车点是技术选型过度比较。三个候选方案各写一个 demo 就够了不要试图把每个方案的优缺点都列全。实际项目中选型的决定性因素往往只有一两个其他差异在三个月周期里根本体现不出来。第三个翻车点是没有真实用户参与。收敛期的验证如果只靠自己拍脑袋很容易做出自己觉得好用但别人不会用的东西。哪怕只找两三个目标用户聊十分钟也能发现大量盲区。3. 闭环期让核心功能真正跑起来3.1 主流程优先于边缘功能闭环期的唯一目标是真实用户能完成主流程。什么叫主流程就是用户打开 App 后为了达成核心目的必须经过的最短路径。心情记录工具的主流程是打开 → 记录 → 查看记录。其他所有功能都是边缘功能。我见过太多项目在闭环期把时间花在设置页、主题切换、分享功能上结果主流程还有 bug。正确的做法是主流程的每个环节都做到能用且不崩溃边缘功能先放占位符或者直接隐藏。具体操作上我会把主流程的每个步骤写成一个检查项每天结束时过一遍。比如冷启动后 3 秒内能看到主界面点击记录按钮能正常弹出输入保存后列表能立即刷新杀掉进程重开数据不丢失这四个检查项全部通过才算闭环期达标。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 上线前的验收清单上线前我会过一遍固定的验收清单这个清单是根据多次踩坑总结出来的检查项通过标准冷启动3 秒内可见主界面主流程完整走通 10 次无异常数据持久化杀进程重开数据完整异常提示断网、存储满、权限拒绝均有提示返回键各页面返回逻辑正确后台恢复切后台再回来状态不丢失这个清单不需要很复杂但每一项都要实际验证不能靠应该没问题。我试过因为没验证后台恢复上线后发现用户切出去接个电话回来数据就没了紧急发版修复。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 天周期至少能少踩一半的坑。