企业官网建设流程全解析

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

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

很多人觉得需求写得越短越省事，实际情况恰恰相反。一句话需求的信息密度极低，它把大量隐含假设都甩给了执行方。比如“做一个帮同事记录工作事项的小工具”，这句话里至少藏着十几个未定义项：用户是谁、数据存哪里、要不要登录、多端同步还是单机、离线能不能用、通知怎么发、权限怎么分、上线到哪个平台。

我在实际项目里踩过最典型的一个坑，就是拿到一句话需求后直接开写，写到一半发现对方想要的是手机 App，而我做的是网页版。返工成本极高。所以第一步不是写代码，而是把这句话“翻译”成一份可执行的需求清单。

翻译的方法我习惯用“五问法”：

• 谁用：目标用户是个人、小团队还是公开用户
• 用来干嘛：核心动作是什么，记录、查询、统计还是协作
• 在哪用：手机、电脑、还是都要
• 数据放哪：本地、云端、还是第三方服务
• 做到什么程度算完成：能跑通就行，还是要能给别人用

这五个问题问完，一句话需求基本就能膨胀成半页纸的功能列表。这个过程不需要写文档，口头确认加聊天记录截图就够，关键是双方对“做什么”达成一致。

1.2 WorkBuddy 与 FDE 在流程里的定位

WorkBuddy 这类工具的核心价值，是把“需求到代码”这段路缩短。它本质上是一个工作台，把需求整理、代码生成、调试、部署这些环节串在一起。而 FDE（Forward Deployed Engineer，前置交付工程师）这个角色，做的事情就是站在需求和实现之间，把模糊的话变成能跑的东西。

我理解的 FDE 工作流是这样的：先跟需求方对齐目标，再用 AI Coding 工具快速产出原型，然后自己验证、修 bug、补细节，最后交付。这个角色不需要是算法专家，但必须懂业务、懂基本工程、会用工具。DeepSeek 这类模型在其中的作用，是承担大量重复性的代码生成和解释工作，让 FDE 能把精力放在判断和决策上。

为什么强调 FDE 而不是纯开发？因为一句话需求的项目，往往没有完整的产品文档和测试团队。FDE 要一个人把产品、开发、测试的活都干了，工具就是他的杠杆。

1.3 90 天路径的阶段性划分逻辑

90 天不是随便定的数字。我把它拆成三个阶段，每个阶段有明确的产出物：

• 第 1 到 30 天：把一句话需求变成能跑的原型，重点是“通”
• 第 31 到 60 天：把原型变成能用的产品，重点是“稳”
• 第 61 到 90 天：把产品变成能交付的 App，重点是“上线”

这个划分的依据是风险递减。前 30 天风险最高，因为需求可能理解错；中间 30 天风险在技术实现；最后 30 天风险在发布和兼容。把高风险的事放前面，返工成本最低。

提示：90 天是参考节奏，不是硬性 deadline。实际项目里我见过 45 天就上线的，也见过拖到半年的。关键不是天数，而是每个阶段有没有明确的“通过标准”。

2. 核心工具链与关键细节解析

2.1 WorkBuddy 工作台的安装与缓存目录调整

WorkBuddy 的安装本身不复杂，但缓存目录的设置是个容易被忽略的点。默认情况下，它会往系统盘的用户目录里写缓存，项目一多，C 盘很快就满了。我实测过一个中型项目，缓存能占到 8 到 12 GB。

调整缓存目录的通用思路是找到配置文件，把 cache path 指向空间充足的盘。具体位置各版本略有差异，通常在安装目录下的 config 文件或用户目录的隐藏文件夹里。改完之后要重启工作台，让它重新索引。

# 示意：查找 WorkBuddy 相关配置目录 find ~ -maxdepth 3 -iname "*workbuddy*" -type d 2>/dev/null

找到目录后，把里面的 cache 或 workspace 路径改到大容量盘。改之前先备份原配置，改完如果启动异常，直接还原。

注意：缓存目录不要放在网络盘或移动硬盘上，读写延迟会让工具卡到没法用。我试过放 NAS 上，索引一个项目花了十几分钟。

2.2 AI Coding 工具的选择与 DeepSeek 的接入

AI Coding 工具现在选择很多，核心差异在三点：代码补全质量、上下文理解能力、以及能不能接入自己的模型。DeepSeek 在这几个维度上表现比较均衡，尤其是长上下文场景，读一个几千行的项目再改代码，不容易丢上下文。

接入方式一般是配置 API 端点和密钥。以常见的编辑器插件为例，在设置里找到模型提供方，填入 DeepSeek 的接口地址和 key，然后选模型版本。配置完先拿一个小文件测试，确认能正常返回再上大项目。

{ "provider": "deepseek", "model": "deepseek-chat", "apiBase": "https://api.deepseek.com", "maxTokens": 8192 }

参数里 maxTokens 不要一上来就拉满，先给 4096 试，稳定了再往上加。上下文窗口开太大，响应会变慢，而且容易触发限流。

2.3 从需求到代码的提示词设计要点

用 AI 生成代码，提示词的质量直接决定产出质量。我总结的模板是“背景 + 目标 + 约束 + 输出格式”四段式。

背景写清楚这是什么项目、用什么技术栈；目标写清楚这次要做什么功能；约束写清楚不能用什么、必须兼容什么；输出格式写清楚要完整文件还是代码片段。

举个例子，同样是“做一个记录页面”，差的提示词是“帮我写个记录页面”，好的提示词是：

背景：一个内部工作记录工具，前端用 React，后端用 Node，数据存本地 SQLite。目标：做一个记录列表页，支持新增、删除、按日期筛选。约束：不要引入额外 UI 库，用原生 CSS。输出：完整的组件文件。

这样生成的代码基本能直接用，改的地方很少。

2.4 工具链组合的取舍逻辑

工具不是越多越好。我见过有人同时装五六个 AI 插件，结果互相冲突，编辑器天天崩。我的建议是：一个主 AI Coding 工具，一个辅助查文档的工具，一个版本管理工具，够了。

WorkBuddy 负责工作台和项目管理，DeepSeek 负责代码生成和解释，Git 负责版本控制。这三样覆盖了从写到管的全部环节。其他工具按需临时装，用完就卸。

3. 实操过程与核心环节实现

3.1 第 1 到 30 天：把一句话需求跑通

这个阶段的目标只有一个：让核心功能能跑起来。不要管界面好不好看，不要管异常处理完不完善，先让它动。

第一步是搭骨架。用 WorkBuddy 新建项目，选好技术栈模板。如果是 App，我一般先用跨平台方案起步，因为改起来快。骨架搭好后，把数据模型定下来。数据模型是整个项目的地基，改一次伤筋动骨。

第二步是生成核心功能代码。把需求拆成最小可运行单元，一个一个让 AI 生成。比如记录工具，先做“新增记录”，再做“显示列表”，再做“删除”。每做完一个就手动测一次，确认没问题再往下。

第三步是本地跑通。这个阶段不部署，就在本地跑。跑通的标准是：核心流程能完整走一遍，不报错，数据能存能读。

// 示意：一个最小记录功能的数据结构 const record = { id: Date.now(), content: "", createdAt: new Date().toISOString(), tags: [] };

这个阶段最容易犯的错是过早优化。看到代码不优雅就想重构，结果功能还没跑通，时间全花在改结构上。忍住，先让它跑。

3.2 第 31 到 60 天：把原型变成能用的产品

原型跑通后，问题会集中爆发：边界情况没处理、界面丑、性能差、数据会丢。这 30 天就是解决这些问题。

先处理数据可靠性。本地存储要加备份机制，云端存储要加失败重试。我一般会加一个简单的本地缓存层，网络断了也能用，恢复后自动同步。

再处理界面。这个阶段可以引入 UI 组件库，把之前手写的样式替换掉。替换的时候注意保持功能不变，一次只改一个页面，改完就测。

然后处理性能。列表长了会卡，就加分页或虚拟滚动；启动慢了，就做懒加载。性能优化的原则是先测量再优化，不要凭感觉。用工具看一下到底哪里慢，再动手。

这个阶段还要开始写测试。不需要全覆盖，把核心流程的测试补上就行。测试的作用不是证明代码对，而是防止改 A 坏 B。

3.3 第 61 到 90 天：打包上线与兼容处理

最后 30 天是发布阶段。App 上线涉及的环节比网页多：打包、签名、商店审核、版本兼容。

打包前先做一轮完整回归，把所有功能过一遍。然后处理不同屏幕尺寸和系统版本的兼容。我一般会准备三台测试设备：小屏、大屏、老系统。老系统最容易出问题，因为新 API 不支持。

签名和证书要提前准备，这个环节经常卡时间。证书申请、配置、打包验证，一套走下来顺利的话两三天，不顺利一周都搞不定。

商店审核有不确定性，所以提交时间要留足。第一次提交被拒很正常，常见原因是隐私说明不完整、权限申请过多、截图不符合规范。被拒后按反馈改，改完重新提交。

提示：上线前把版本号、更新日志、隐私政策这三样准备好。审核方最常问的就是这三个。

3.4 关键环节的参数计算与选择

打包体积是个需要算的账。App 体积直接影响下载转化率，一般控制在 50 MB 以内比较稳妥。控制体积的方法：图片压缩、移除未用依赖、开启代码混淆和压缩。

以图片为例，一张 2000x2000 的 PNG 可能有 3 MB，压成 WebP 后可能只有 300 KB。一个页面十张图，就是 27 MB 的差距。

# 示意：批量转 WebP（需安装对应工具） for f in *.png; do cwebp -q 80 "$f" -o "${f%.png}.webp"; done

启动时间也要算。冷启动超过 3 秒，用户流失明显。优化手段包括延迟初始化、减少启动时的网络请求、把非关键逻辑放到后台线程。

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

4.1 需求理解偏差怎么提前发现

需求偏差是最大的坑，而且往往到后期才暴露。我的做法是在第 1 周就做一个“可点击的假界面”，把核心流程用静态页面串起来，让需求方点一遍。不用真功能，就点按钮跳页面。

这个方法能在几十分钟内暴露大量理解偏差。对方看到界面后，会说出很多之前没提到的需求，比如“这里应该能导出”“这个字段要能搜索”。这些信息比问十遍都管用。

4.2 AI 生成代码的典型问题与修正

AI 生成的代码有几个高频问题：一是幻觉 API，调用了不存在的函数；二是版本不匹配，用了旧版或新版的语法；三是逻辑看似对但边界没处理。

修正方法是“小步验证”。不要一次生成几百行再测，生成一个函数就测一个函数。遇到幻觉 API，把报错信息贴回去让它改，通常两三轮就能修好。

4.3 缓存与构建相关的疑难排查

缓存问题最烦人，因为表现不稳定。常见症状是改了代码不生效、构建产物和源码不一致。排查顺序是：先清构建缓存，再清依赖缓存，最后清工具缓存。

WorkBuddy 的缓存目录如果改过位置，要确认新位置有写权限。我遇到过一次改完目录后构建一直失败，查了半天发现是新目录权限不对。

# 示意：清理常见构建缓存 rm -rf node_modules/.cache rm -rf dist build

清完缓存重新构建，如果问题还在，再往依赖层面查。

4.4 上线阶段的兼容与审核问题

兼容问题集中在老设备和特殊分辨率。测试时不要只用自己的手机，找一台两三年前的旧设备跑一遍。很多在新设备上正常的功能，在旧设备上会闪退。

审核被拒的高频原因我整理过：权限说明不清、隐私政策缺失、截图与实际不符、含有测试内容。提交前逐条对照检查，能省一轮往返。

注意：审核期间不要频繁改版本，一次提交一个稳定版本，改多了容易触发人工复审，时间更长。

5. 90 天路径的节奏控制与经验总结

5.1 每个阶段的通过标准怎么定

没有通过标准的阶段等于没有阶段。我给每个阶段定的标准很具体：

• 第 30 天：核心流程能在本地完整跑通，数据能存能读
• 第 60 天：主要边界情况有处理，界面达到可展示水平，核心流程有测试
• 第 90 天：能打包安装，在目标设备上稳定运行，通过审核

标准要可验证，不能是“感觉差不多了”。感觉是最不靠谱的验收方式。

5.2 时间不够时的取舍策略

90 天经常不够用，这时候要会砍。砍的顺序是：先砍锦上添花的功能，再砍次要流程，最后砍非核心的兼容。核心流程和核心数据绝对不能砍。

我一般会留一个“最小可交付版本”的清单，把功能分成必须、应该、可以三档。时间不够就从“可以”开始砍，砍到“必须”为止。

5.3 一个人做完整流程的精力分配

一个人干完产品、开发、测试、发布，精力分配很关键。我的经验是：需求对齐占 15%，编码占 40%，测试和修 bug 占 30%，发布和兼容占 15%。

编码时间不要超过一半，因为后期修 bug 的时间往往被低估。我见过太多项目前期猛写代码，后期全在填坑。

5.4 交付之后还能怎么扩展

上线不是终点。交付后可以做的扩展包括：收集使用反馈、加数据统计、做自动化测试、优化启动速度。这些不急着做，但要有规划。

我个人在实际操作中的体会是，一句话需求的项目，成败往往不在技术难度，而在需求对齐和节奏控制。技术问题 AI 能帮你解决大半，但“做对的东西”这件事，只能靠人判断。把前 30 天用在确认方向上，比后面三个月埋头写代码要值。