企业官网建设流程全解析

1. 一句话需求背后的真实工作量

“帮我做个能记录每天工作内容、自动生成周报的 App。”这句话是我一个做产品经理的朋友在咖啡厅随口说的。他当时的表情很轻松，像是在描述一个周末就能搞定的玩具项目。但作为一个接过不少类似需求的人，我太清楚这句话背后藏着多少需要拆解的东西了。

WorkBuddy 这个项目就是从这个场景长出来的。FDE 在这里指的是 Forward Deployed Engineer 的工作模式——不是坐在后台等需求文档，而是直接扎进业务场景里，把一句模糊的话翻译成可执行的技术方案，再一步步推到上线。这个实战手册要讲的就是这条路径怎么走，90 天的时间怎么分配，以及中间那些没人会提前告诉你的坑。

如果你手头正好有一个“听起来很简单”的需求，或者你正在用 FDE 的方式推进某个内部工具，这篇内容应该能帮你省下不少试错成本。我会从需求翻译开始，一路讲到上线后的迭代节奏，中间穿插具体的工具选型、数据结构设计、自动化逻辑和部署策略。所有代码和配置都是可以直接参考的，但更重要的是背后的判断逻辑——为什么这么选，不这么选会怎样。

先给一个全局视角：90 天不是随便定的。前 30 天用来把模糊需求变成可验证的原型，中间 30 天把原型打磨成能用的产品，最后 30 天处理上线、反馈和迭代。每个阶段都有明确的交付物和退出条件，不是拍脑袋往前推。

2. 把一句话拆成可执行的需求清单

2.1 识别需求里的隐藏动词

“记录每天工作内容”这句话里，“记录”是显性动词，但真正的工作量藏在“每天”和“工作内容”这两个词里。“每天”意味着需要处理时间维度——是手动触发还是自动提醒？跨天怎么算？补录怎么处理？“工作内容”更麻烦，它可能是纯文本、可能是结构化条目、可能带附件、可能关联项目或客户。这些在原始需求里全是空白。

我的做法是拿一张纸，把这句话里每个名词和动词都圈出来，然后对每个圈问三个问题：输入是什么？输出是什么？边界在哪里？比如“记录”这个动作，输入是用户当下的描述，输出是一条带时间戳的记录，边界是——如果用户忘了写，第二天能不能补？补的记录时间戳用哪个？

这一步不需要写代码，但需要跟需求提出者坐下来，用具体的场景去逼问。我通常会准备五到八个极端场景，比如“出差路上没网怎么记”“一天做了三个项目怎么归类”“周报里要不要体现耗时”。这些问题的答案会直接决定后面的数据结构。

2.2 用最小可用闭环验证核心假设

需求拆完之后，不要急着画完整的原型。先找一条最短的路径，把“记录→存储→展示”这个闭环跑通。WorkBuddy 的第一版原型就是一个命令行脚本：运行之后弹出输入框，写一句话，回车，存进本地文件，再运行另一个命令就能看到列表。前后不到一百行代码。

这个原型的价值不在于功能，而在于验证一个假设：用户愿不愿意每天花十秒钟做这件事。如果连这个动作都坚持不了，后面加再多自动化都是白搭。实测下来，我那个产品经理朋友用了三天就放弃了手动输入，但他的反馈很关键——“如果它能自动从我的日历和聊天记录里抓取，我可能还会用。”

这个反馈直接改变了项目的方向。原本设想的是一个主动记录工具，实际上用户想要的是一个被动采集加主动确认的工具。这个认知如果等到 60 天后再发现，返工成本会高得多。

2.3 需求清单的优先级排序逻辑

把拆出来的需求按“必须现在做”“可以以后做”“永远不做”三档分类。WorkBuddy 的清单大概是这样的：

这个排序不是拍脑袋的。判断标准就一条：这个功能不做，核心闭环能不能跑通？不能跑通的排第一档，能跑通但体验差的排第二档，跟核心闭环无关的排第三档。很多项目死掉就是因为第一档还没跑通就开始做第三档的东西。

3. 技术选型：为什么最后选了这套组合

3.1 前端形态的取舍：从命令行到桌面应用

第一版命令行原型验证了需求，但要让非技术用户日常使用，必须有一个图形界面。这里面临一个选择：做 Web 应用、桌面应用还是移动应用？

Web 应用开发最快，但 WorkBuddy 需要读取本地的日历和文件系统，浏览器沙箱限制太多。移动应用体验最好，但开发周期长，而且用户主要的工作场景在电脑前。桌面应用成了折中方案，既能访问本地资源，又能提供比命令行友好的界面。

具体技术栈上，我选了 Electron 加 React。Electron 的争议一直很大，体积大、内存占用高，但它的优势在这个场景里很关键：可以用前端技术栈快速迭代界面，同时通过 Node.js 集成访问系统 API。对于一个内部工具来说，开发效率比运行时效率重要得多。

如果你也在做类似的桌面工具，我的建议是：先问自己能不能接受 Web 应用。如果本地资源访问不是硬需求，Web 应用加 PWA 的方案会省掉很多打包和分发的麻烦。

3.2 数据存储：为什么没用数据库

记录类应用的数据结构其实很简单，一条记录就是时间戳加文本加标签。这种场景下，引入 SQLite 甚至 PostgreSQL 都是过度设计。WorkBuddy 最终用的是 JSON 文件加内存索引的方案。

具体来说，每天的记录存成一个独立的 JSON 文件，文件名就是日期。应用启动时把所有文件加载进内存，构建一个按日期和标签的索引。写入时先更新内存索引，再异步落盘。这个方案的好处是数据完全透明，用户可以直接用文本编辑器打开查看，备份就是复制文件夹，迁移就是拷贝文件。

坏处也很明显：数据量大了之后内存占用会上升，全文搜索效率会下降。但实测下来，即使存了三年的记录，文件总数也就一千多个，总数据量不到十兆，内存索引的构建时间在两百毫秒以内。对于个人工具来说，这个量级完全不需要数据库。

3.3 自动采集的技术路径

自动采集日历事件是 WorkBuddy 的核心功能之一。不同操作系统提供的接口不一样，这里需要做一个适配层。macOS 上可以通过系统自带的脚本桥接访问日历数据库，Windows 上可以用系统提供的日历 API，Linux 上则依赖桌面环境的具体实现。

我的做法是定义一个统一的采集接口，每个平台实现各自的适配器。采集到的原始数据先统一转换成内部格式，再进入后续的处理流程。这个适配层的代码量不大，但需要处理各种边界情况，比如权限被拒绝、日历服务未启动、事件时间格式不一致等。

// 采集适配器的接口定义 class CalendarAdapter { async requestPermission() { throw new Error('Not implemented'); } async fetchEvents(startDate, endDate) { throw new Error('Not implemented'); } normalizeEvent(rawEvent) { throw new Error('Not implemented'); } }

每个平台的适配器继承这个基类，实现三个方法。权限请求单独抽出来是因为不同平台的权限模型差异很大，有的在首次调用时弹窗，有的需要提前在设置里授权。把权限处理独立出来，可以让主流程的逻辑更干净。

4. 核心功能的实现细节与踩坑记录

4.1 快速记录窗口的交互设计

记录窗口的设计目标只有一个：让用户用最短的路径完成输入。WorkBuddy 的方案是全局快捷键呼出一个无边框窗口，输入框自动聚焦，回车保存并关闭，Esc 取消。整个流程不需要碰鼠标。

这个看似简单的交互，实现起来有几个坑。第一个是快捷键冲突，不同操作系统和不同应用占用的组合键不一样，需要提供一个可配置的快捷键设置界面。第二个是窗口焦点问题，Electron 的无边框窗口在某些系统上会出现呼出后不自动聚焦的情况，需要在窗口显示事件里手动调用聚焦方法。

第三个坑最隐蔽：输入法的兼容性。中文输入法在输入过程中会触发多次键盘事件，如果直接在回车事件里保存，可能会把未上屏的拼音也存进去。解决方案是监听输入框的合成事件，在合成结束前忽略回车。

let isComposing = false; input.addEventListener('compositionstart', () => { isComposing = true; }); input.addEventListener('compositionend', () => { isComposing = false; }); input.addEventListener('keydown', (e) => { if (e.key === 'Enter' && !isComposing) { saveRecord(input.value); closeWindow(); } });

这段代码不长，但没有处理合成事件的话，中文用户基本没法正常使用。

4.2 周报生成的模板引擎设计

周报生成的核心逻辑是把一段时间内的记录按项目或标签聚合，然后套进一个模板里。模板引擎没有用现成的库，而是自己写了一个简单的字符串替换加条件渲染的逻辑。原因很简单：需求太具体了，引入一个通用模板引擎反而要花时间学习它的语法和限制。

模板的结构大概是这样的：开头是时间范围，中间按项目分组列出主要工作内容，结尾是下周计划。每个部分的内容都来自记录数据的聚合结果。聚合逻辑里有一个容易忽略的点：同一条记录可能关联多个标签，聚合时要注意去重，否则周报里会出现重复条目。

function aggregateRecords(records, startDate, endDate) { const filtered = records.filter(r => r.timestamp >= startDate && r.timestamp <= endDate ); const grouped = {}; for (const record of filtered) { for (const tag of record.tags) { if (!grouped[tag]) grouped[tag] = []; if (!grouped[tag].includes(record.text)) { grouped[tag].push(record.text); } } } return grouped; }

这个聚合函数看起来简单，但实际跑起来会发现一个问题：如果用户没有给记录打标签，所有内容都会归到一个“未分类”组里，周报的可读性很差。后来的改进是加了一个自动标签推断的逻辑，根据记录里的关键词匹配预设的项目名称。

4.3 数据同步的简化方案

多端同步是用户提得最多的需求之一，但也是复杂度最高的。WorkBuddy 最终没有做实时同步，而是用了一个更简单的方案：导出和导入。用户可以在设置里把数据导出成一个加密的压缩包，然后在另一台设备上导入。

这个方案听起来很原始，但实际使用中反而更受欢迎。原因是实时同步需要处理冲突合并、网络中断、数据一致性等一系列问题，而且用户对个人工作记录的隐私敏感度很高，把数据传到第三方服务器上很多人是不愿意的。导出导入的方案把控制权完全交给用户，虽然麻烦一点，但心理负担小。

如果你也在做类似工具，不要一上来就追求实时同步。先问用户：你真的需要两台设备同时编辑吗？大多数情况下，导出导入加手动合并就够了。

5. 90 天路径的阶段性拆解

5.1 第 1 到 30 天：原型验证与需求收敛

这个阶段的目标不是做出能用的产品，而是验证核心假设。WorkBuddy 在前 30 天做了三件事：命令行原型、用户访谈、需求清单定稿。

命令行原型花了三天，用户访谈穿插在两周内做了五个人，需求清单在第三周定稿。剩下的时间用来搭建桌面应用的基础框架，包括窗口管理、快捷键注册、数据存储层。这个阶段结束时的交付物是一个能跑通记录和展示闭环的桌面应用，界面很粗糙，但核心流程是通的。

这个阶段最容易犯的错误是过早优化。比如花一周时间打磨界面动画，或者纠结于用哪个状态管理库。这些工作在原型阶段没有任何价值，因为需求随时可能变。我的原则是：只要不影响核心流程的验证，所有非关键路径的东西都用最粗糙的方式实现。

5.2 第 31 到 60 天：功能完善与体验打磨

进入这个阶段，需求基本稳定了，可以开始认真做功能。WorkBuddy 在这 30 天里加了自动采集、周报生成、标签系统、搜索功能。每个功能都遵循同样的节奏：先做最小实现，自己用三天，收集反馈，再决定是继续完善还是砍掉。

自动采集功能在这个阶段经历了一次大改。最初的实现是定时轮询日历接口，每五分钟拉一次数据。实测发现这样会有明显的延迟感，而且频繁调用接口在某些系统上会触发权限警告。后来改成了事件驱动的方式，监听日历变化通知，只在变化时拉取增量数据。这个改动让采集的实时性从分钟级提升到了秒级。

周报生成功能则砍掉了一个原本计划的功能：自定义模板编辑器。原因是测试用户里没有人愿意花时间设计模板，他们只想要一个“看起来还行”的默认模板，然后手动改几个字。这个发现让我把精力从模板编辑器转移到了默认模板的质量上，最终产出的模板直接可用率在八成以上。

5.3 第 61 到 90 天：上线准备与反馈循环

最后 30 天的重点是打包、分发和反馈收集。打包本身不复杂，但跨平台打包需要处理不同系统的签名和权限问题。WorkBuddy 选择了不做代码签名，而是通过内部渠道分发，用户首次打开时需要手动允许。这个选择牺牲了一些便利性，但省掉了购买证书和配置签名流程的时间。

反馈收集用了一个很轻量的方案：应用内嵌一个反馈按钮，点击后打开一个预填了版本号和系统信息的表单。表单提交到一个简单的后端服务，数据存进一个表格里。这个方案的好处是用户不需要注册账号，也不需要跳转到外部网站，反馈的转化率比预期高很多。

上线后的第一周收到了二十多条反馈，其中最有价值的一条是：“周报生成的时间范围能不能自定义？”这个需求在开发阶段完全没被提到，但实际使用中很多人需要生成月度总结而不是周报。这个反馈直接催生了下一个版本的自定义时间范围功能。

6. 那些没人会提前告诉你的坑

6.1 系统权限的静默失败

自动采集日历数据需要系统权限，但权限被拒绝时的表现因平台而异。有的平台会直接抛出异常，有的平台会返回空数据，还有的平台会弹出一个系统弹窗但应用层收不到任何回调。WorkBuddy 在测试阶段遇到过一次“采集功能正常但数据为空”的问题，排查了半天才发现是权限被静默拒绝了。

解决方案是在采集前主动检查权限状态，如果权限未授予，在应用内显示一个明确的引导提示，告诉用户去哪里开启权限。这个提示不能只写“请授予权限”，要具体到“打开系统设置，找到隐私与安全性，在日历选项中勾选本应用”。

6.2 时间处理的时区陷阱

记录类应用绕不开时间处理。WorkBuddy 早期版本在跨时区使用时出现过记录日期错乱的问题。原因是存储时用了本地时间字符串，读取时按当前时区解析，导致跨时区后日期偏移。

修复方案是统一用 UTC 时间戳存储，展示时再转换成用户当前时区。这个改动涉及所有跟时间相关的代码，包括记录创建、查询过滤、周报聚合。改动量不小，但如果一开始就用 UTC 存储，这些工作都可以省掉。

// 存储时 const timestamp = Date.now(); // 毫秒级 UTC 时间戳 // 展示时 const localTime = new Date(timestamp).toLocaleString(); // 查询某天的记录 function getRecordsByDate(records, dateStr) { const targetDate = new Date(dateStr); const startOfDay = new Date(targetDate); startOfDay.setHours(0, 0, 0, 0); const endOfDay = new Date(targetDate); endOfDay.setHours(23, 59, 59, 999); return records.filter(r => r.timestamp >= startOfDay.getTime() && r.timestamp <= endOfDay.getTime() ); }

6.3 数据备份的自动化缺失

导出导入方案虽然简单，但依赖用户手动操作。实测发现，超过七成的用户从来没有导出过数据。这意味着如果他们的电脑出问题，所有记录都会丢失。这个风险在早期被低估了。

后来的补救措施是加了一个自动备份功能：每天首次启动时，自动把数据目录复制一份到用户指定的备份文件夹，保留最近三十天的备份。这个功能实现起来很简单，但需要处理备份文件夹不可写、磁盘空间不足等异常情况。自动备份加上手动导出，数据安全性才算有了基本保障。

7. 上线之后的迭代节奏

7.1 从反馈到排期的过滤机制

上线后反馈会源源不断地来，但并不是每条都值得做。WorkBuddy 的过滤机制是三个问题：这个问题影响多少用户？有没有临时解决方案？修复成本大概多大？三个问题的答案综合起来决定优先级。

比如“周报时间范围自定义”这个需求，影响面广、没有临时方案、修复成本中等，所以排在了第一优先级。“支持 Markdown 格式”这个需求，影响面窄、用户可以用纯文本代替、修复成本低但收益也低，排在了后面。

这个过滤机制的关键是不要被单个用户的强烈情绪带偏。有的用户会把某个小问题描述得很严重，但实际影响面可能只有他一个人。这时候需要回到数据，看看有多少人遇到了同样的问题。

7.2 版本节奏与灰度策略

WorkBuddy 的版本节奏是两周一个小版本，一个月一个大版本。小版本只修 bug 和小优化，大版本才加新功能。这个节奏的好处是用户可以预期什么时候会有更新，开发节奏也比较稳定。

灰度策略很简单：新版本先发给主动反馈过问题的用户试用，收集一轮反馈后再全量推送。这批用户对产品比较熟悉，反馈质量高，而且他们本身就有参与感，愿意花时间测试。全量推送前至少要有五个灰度用户的确认，否则就再等一个版本。

7.3 什么时候该停下来

这个问题很少有人讨论，但很重要。WorkBuddy 在上线四个月后进入了一个稳定期：核心功能没有大问题，反馈量明显下降，新需求越来越少。这时候继续加功能的边际收益已经很低了。

我的判断标准是：如果连续两个版本的更新内容都是“修复了某某小问题”而没有“新增了某某功能”，就说明产品已经进入维护期了。这时候应该把精力转移到其他事情上，只保持最低限度的维护。继续投入只会让代码越来越复杂，而用户感知到的价值提升微乎其微。

这个项目从一句话需求到上线 App，实际用了 87 天，比计划的 90 天提前了三天。但真正的收获不是按时交付，而是在这个过程中建立起来的一套工作方法：怎么把模糊需求翻译成可执行的任务，怎么在资源有限的情况下做取舍，怎么在用户反馈和开发节奏之间找到平衡。这套方法可以复用到任何一个从零到一的项目上，不管它是 App、内部工具还是其他什么形态。