企业官网建设流程全解析

1. 项目全景：六个阶段和十六个坑怎么排布

先说结论：用 WorkBuddy 搭一个能上线的 App，和用它在本地跑通一个 Demo，是两回事。前者是一条从想法到商店上架的完整生产线，后者只是生产线上的一个环节。我把整个过程压缩成六个阶段，踩了整整十六个坑，最后沉淀出一套可以复制到下一个项目的工作流。如果你正准备用 AI 编程工作台加速 App 开发，这篇文章值得你花十分钟看完。

我拿这个项目做了个样板：一个面向中小团队的轻量任务协作 App，覆盖登录、任务列表、详情、评论、消息推送这些最常见模块。之所以选这个方向，是因为它几乎包含了大多数上架 App 的共性难点——账号体系、跨端适配、网络请求、本地缓存、权限声明，以及最磨人的应用市场审核。模板本身不是重点，重点是这套"六个阶段 + 十六个坑"的流程，能直接迁移到你自己的项目里。下文的每一个阶段、每一个坑，我都会说清楚当时怎么想的、怎么踩的、最后怎么解的。

1.1 WorkBuddy 解决的到底是什么问题

先说清楚 WorkBuddy 的定位。它不是 IDE 的替代品，也不是单纯的代码补全插件，而是一个以"任务"为单位的 AI 编程工作台。你可以给它安装技能包（skill），让它在 Vue、uni-app、测试脚本、上架检查这些特定领域里有更专业的表现；你还可以写一份全局规则文件，让它后续处理所有任务时都遵循同样的技术栈和代码规范。这种形态最核心的价值，是把"上下文"固定下来：技术栈、目录结构、命名规范、质量门槛都不用你反复交代，它自己知道。

选它的原因其实很现实。传统开发一个 App，要经历环境搭建、脚手架初始化、页面编写、接口联调、多端编译、打包签名、上架审核，每一环都需要人工盯，任何一个环节出问题都会卡住整条链路。而用 WorkBuddy 这类工作台，最理想的状态是：你负责拆解任务和做验收，它负责把重复劳动吃掉。但"最理想"三个字是要打引号的，因为现实里坑远比想象中多。这套工具能帮你把薄弱的环节补上，但它也会非常高效地把你的坏习惯放大，比如需求不清、边界模糊、代码不设防。这也是我为什么要写下这篇总结的原因。

1.2 为什么必须要分六个阶段

我一开始没分阶段，一口气把需求全部扔给它，结果产出质量断崖式下跌。后来才明白，AI 工作台和人类团队有个共同点：任务边界越清晰，交付质量越高。于是我把整个项目拆成了六个阶段：需求冻结与方案定型、工作台初始化与全局规则沉淀、核心功能逐块开发、数据链路与联调、测试与收边、上架发布与善后。

每个阶段都有明确的入口和出口。阶段一没做完，不进阶段二；阶段四没搞定，不碰阶段六。这种"门禁式"的推进方式，能有效防止 AI 在一个没想清楚需求的项目里自由发挥。反过来，如果阶段一偷懒省事，后面所有阶段都会为这个决定买单。后文里的十六个坑，至少有五个的根源都在阶段一。

1.3 十六个坑的速览表

为了让你对后文有个整体感知，我先把十六个坑按阶段列成一张速览表。这张表在我项目里贴在墙上当"作战地图"用：每完成一个阶段，就对着它检查一遍，确认没有遗留坑再往前走。你会发现坑的分布很不均匀——需求阶段虽然一个代码都没写，却埋了三个大雷；开发联调阶段集中了最多的问题，这也很正常，毕竟那是代码量和交互路径最密的地方。

这张表建议你保存下来，对照后文逐条看，效果会好很多。

1.4 这套流程能省什么、不能省什么

很多人问"开发一个能上架的 App 大概要多少钱、多久"，这个问题的答案在 AI 工作台下已经和传统开发完全不同了。传统模式下，一个双端工具型 App 从零到上架，两个人全职大概要 4 到 6 周，成本大头是开发工时和反复联调。用 WorkBuddy 这套流程，我一个人在两三周内走完六个阶段，而且上架后两周没出现需要紧急修复的问题。

要强调的是，省掉的是重复劳动，不是思考。需求判断、边界控制、验收标准、合规检查这些事，AI 目前替代不了，它们恰恰是决定项目生死的关键。所以我的观点是：把 WorkBuddy 当作"能稳定供能的队友"，不要当成"什么都知道的教练"。它可以加速你的执行，但决策权必须留在你自己手里。这也是后文所有经验和模板的底层逻辑。

2. 逐阶段实操：从需求冻结到商店上架

2.1 阶段一：需求冻结，方案定型

这个阶段没有代码，但它是整个项目里我最后悔没做足的一环。所谓冻结，不是"想清楚"，而是"写下来并确认边界"。我给项目定了第一版需求清单：账号登录（App 内账号 + 团队邀请）、任务管理的增删改查、任务评论、消息推送、个人中心。每一类我都标注了"本期必须做 / 本期不做 / 后续版本做"三类状态。"本期不做"往往是很多人不好意思写下来的，但恰恰是它保住了整个项目的交付节奏。

具体操作上，我让 WorkBuddy 根据需求清单，自动生成了技术方案候选：原生、uni-app、Flutter 三种方案，并让它列出每种方案在"双端上架、开发速度、AI 生成代码的适配度"三个维度上的对比。最后选了 uni-app + Vue 3。理由是：一个小团队的工具型 App 不需要原生级的性能；uni-app 的 API 封装比较统一，AI 训练语料里含有大量相关代码，生成的代码可复用率更高；后续如果要接微信小程序，同一套代码还能继续用。

这里重点解释"为什么这么选"。原生开发在两端的 UI 细节上最灵活，但 AI 工作台要同时维护两套代码，出问题的概率翻倍；Flutter 的渲染能力强，但在国内上架时涉及到的打包链路更长；uni-app 的编译链路相对成熟，HBuilderX 和 CLI 方案都有大量现成实践。交付速度是第一优先级时，它是最稳的选择。当然这不是说 uni-app 完美，后面阶段里很多坑恰恰是跨端框架带来的，但至少在"让 AI 快速上手"这一项上，它是当时的最优解。

2.2 阶段二：工作台初始化与全局规则沉淀

安装 WorkBuddy 后，第一件事不是写代码，而是配环境。我当时踩的坑从环境变量开始，后面会详细说。这里讲正确做法。首先，把 Node、JDK、Android SDK、Xcode Command Line Tools 这些底层依赖装齐，并把它们的路径写进终端配置。然后给 WorkBuddy 单独指定项目缓存目录，避免系统盘被 node_modules 和编译产物塞满。这里对应的就是很多人经常问的"WorkBuddy 怎么更改系统缓存目录"——在配置里设置 cache_dir 指向一个专门的大分区即可。

第二步是安装 skill。这一步类似给编辑器装插件，但强很多。比如安装 Vue3 技能包、uni-app 技能包、代码审查技能包之后，它生成代码时会自动带上对应框架的写法习惯，而不是用纯前端思路写不适配的代码。我还会装一个"上架检查"技能包，在阶段六用来做元数据和权限声明的自查，省了不少事。

第三步是最重要的一步：写全局规则文件。这个文件的作用，相当于给这个 AI 工作台立"团队章程"。我用的模板长这样：

project: task-note stack: uni-app + Vue 3 + Pinia language: zh-CN build_target: ios, android rules: - 组件统一使用组合式 API - 页面放 src/pages，组件放 src/components - 禁止凭空捏造不存在的 API 和组件方法 - 每次改完代码必须执行 type-check - 接口请求统一走 src/utils/request.js - 未经确认，不允许修改全局入口文件

这份文件写好之后，后续所有任务都会自动携带这些约束条件。换句话说，你不需要在每个任务描述里重复"我是 Vue3 项目"这句话，它自己知道。这套机制很省心，但前提是写对位置——不是写在某个任务的提示词里，而是写进工作台级的全局配置中。很多用户都在搜"给 WorkBuddy 定几条规则，后续对所有任务都生效"，其实就是这一步。

2.3 阶段三：核心功能逐块开发

阶段三的核心纪律是"一次只做一件事"。我把任务列表拆成粒度很小、可独立验收的单元：先做登录页 UI，再写登录接口请求，再写 token 存储，再做任务列表页，再做任务详情页……每一块完成、验证、提交后再开下一块。这种节奏有点笨，但非常适合 AI 工作台。你把任务拆得越细，它越不会跑偏，你验收起来也越轻松。

比如登录页，我给 WorkBuddy 的任务描述是："在 src/pages/login 下生成登录页，包含手机号输入、验证码输入、登录按钮；调用 POST /auth/login 接口；成功后把 token 存入 storage；参考设计稿的主色为 #2D6CDF；按钮禁用态和 loading 态都要有。"这样它产出的代码有明确的验收标准，你不需要在一堆需求里猜它到底完成了什么。

这个阶段最常见的反弹是"AI 太能瞎编"。它可能写出一个并不存在的 uni-app API，然后编译成功但运行报错。我的止损办法是：让它输出代码前先列出一个"本次任务会用到的 API 清单"，我快速确认一遍再让它继续。看似多了一步，实际上节省了后面的调试时间。第二个经验是：组件粒度要控制。如果页面和组件都放在一个大文件里，AI 后续改一个功能时经常连带破坏无关代码。所以我强制要求每个页面文件不超过 300 行，超出就拆组件。这个规则写进全局文件后，后续生成的代码天然更整洁。

2.4 阶段四：数据链路与联调

功能页面能跑起来之后，真正的硬仗是数据和接口。这个阶段我定了一个"数据流约定"：所有请求必须经过统一的 request 工具函数，统一处理 token 注入、过期刷新、错误码；所有响应先走一层拦截器，再到页面。这个约定写进了全局规则，因此 AI 生成的每个接口请求都天然合规。

// src/utils/request.js 的核心思路 // 统一注入 token，拦截错误码，避免每个页面重复处理 const request = (options) => { const token = uni.getStorageSync('token') return new Promise((resolve, reject) => { uni.request({ ...options, url: BASE_URL + options.url, header: { Authorization: `Bearer ${token}` }, success: (res) => { if (res.statusCode === 401) { // 触发统一刷新登录态流程 return refreshLogin().then(resolve).catch(reject) } resolve(res.data) }, fail: reject, }) }) }

联调时最大的坑出现在登录态上。我们的后端 token 有效期是 2 小时，而前端刷新 token 的机制在"浏览器唤起 App"的场景下没有兜底。具体说，用户在分享页点击链接，iOS 通过 scheme 唤起 App 时回传了一个短期授权 code，但 App 因为缓存策略问题没能正确消费它，回调参数丢失，导致登录静默失败。排查了很久，最后的解法是：在 App 冷启动场景下，先检查 URL 参数，再走一次"刷新登录态"的完整流程，而不是直接信任本地缓存。

同一阶段，本地缓存策略也出过问题。任务列表接口返回了新数据，但页面冷启动时优先读了本地缓存的旧数据，造成用户看到的数据比服务器落后。修法很笨但有效：给缓存加版本号字段，如果远端数据 version 高于本地，就直接覆盖。后来我把这个逻辑沉淀成模板函数，所有列表页复用，问题再没出现过。

2.5 阶段五：测试与收边

AI 工具能大幅提速开发，但"测试"这件事它不会替你做。我在阶段五做了三类测试：逻辑测试（重点覆盖登录、新建任务、修改任务状态）、兼容性测试（模拟器和真机、iOS 和 Android、大小屏）、异常测试（弱网、接口报错、token 过期）。说实话，AI 生成的代码在"正常路径"上通常没有大问题，可一旦跑到异常路径，各种边界问题就会冒出来，所以异常测试反而是我最看重的。

兼容性测试里最隐蔽的问题是"模拟器能跑，真机装不上"。原因通常是证书、描述文件或包名不一致。这里需要非常严格地把开发证书、打包证书、包名、版本号四者统一。我的经验是：切到真机调试时，先把打包配置里的 bundle id 与开发者后台的注册包名逐字核对，空格都不能差。

另一个教训是机型覆盖。我最初只在 iPhone 14 和一台小米上测试，结果发到测试群后，有同事在小屏手机上发现按钮溢出、键盘遮挡输入框。这类问题在 AI 生成的页面里尤其常见，因为它的默认布局是按标准屏宽写的。补救办法是：在全局规则里加上"所有页面必须适配 320pt 宽度"，并且在验收时用模拟器切到小屏机型过一遍。这个规则一旦加上，后续 AI 生成的页面基本不会再犯同类错误。

2.6 阶段六：上架发布与善后

这是最容易被新手低估的阶段。打包、签名、上传、填写元数据、隐私政策、权限用途说明，每一项都能让审核打回。我的项目在 iOS 端被审核打回过一次，原因是权限描述写得模棱两可——"允许访问相册"这种写法会被判定为含糊。改正方案是写清楚用途："允许访问相册，用于选择任务附件图片并上传给团队成员查看。"

除权限文案外，还有一类特别常见的问题是"设置了权限，但代码里没有对应调用"。审核员会把未使用的权限当作潜在隐私风险，所以打包前要把所有动态权限清单过一遍，用不到的直接去掉。Android 端则要关注包体积和渠道包。默认打包如果不做裁剪，体积很容易超过 80 MB，这在部分应用市场会影响审核和下载转化。我做了三件事：移除未使用资源、按 AB 架构分包、把不必要的动态权限去掉。最终包体积从 92 MB 降到 46 MB，效果非常明显。

善后工作是很多教程不会提的：上架后不是结束，而是监控和告警的开始。崩溃日志、用户反馈、版本回滚预案这三样必须在发布前准备好。用 WorkBuddy 生成一个"发布检查任务"也能帮上忙，它会自动核对版本号、更新说明、隐私链接是否齐全。

3. 十六个坑逐个拆解：现象、原因、解法

这一章是全文最值钱的部分。前两章是按流程走，这一章是按坑走。十六个坑我会按"需求—环境—开发联调—测试上架"四个区间逐条说，每条都包含现象、原因和解法，尽量不写废话。如果你时间有限，可以直接拉到这一章，对着你自己的项目阶段找对应的坑。

3.1 需求阶段的三颗雷

坑 1：需求没有冻结边界。项目做了一半，产品同学（其实是我自己）觉得"加个标签筛选也不难"，于是需求从 5 个模块变成 8 个。AI 的代码结构是围绕原需求生成的，新增功能时它不会主动帮你重构，结果就是打补丁式的代码越来越多。我们后来统计，这次需求蔓延直接让开发周期多出 40%，而且 AI 生成的代码在新增功能时经常和已有结构冲突。教训是：所有需求写成清单，标注"本期 / 下期"，新增内容一律进下期，天塌下来也不动摇。

坑 2：技术栈选型只看热度。最初我倾向 Flutter，因为渲染效果好，社区讨论多。但冷静评估后发现，团队里没人写过 Dart，而 AI 工作台在 Vue 生态的训练语料明显更丰富。比如 Flutter 在桌面端的优势在我们项目里毫无用处，却要为它的编译链路付出额外成本。选型不是选最好的，而是选"工具链 + 团队经验 + AI 适配度"三者平衡的。后来我把"为什么选 uni-app"这条判断写进了项目文档，避免中途反复动摇。

坑 3：低估"能上线"的门槛。功能做完才发现 iOS 需要隐私协议，Android 部分市场需要软著，ICP 备案等要求也都指向同一件事：你是在发布产品，不是发 Demo。这些资质准备周期很长，必须在阶段一就并行启动。我认识不少开发者，功能做得漂漂亮亮，最后卡在资质上，一等就是一个月。软著办理至少要预留三周，别等代码写完再去办，那时候每一周都是煎熬。

3.2 环境配置期的四个坑

坑 4：环境变量路径问题。第一次跑任务时，WorkBuddy 的终端任务报"找不到 Android SDK"，原因是 ANDROID_HOME 只在交互 shell 里生效，没写进全局配置。排查后用 export 写入配置并 source 生效，再验证就通了。具体命令很简单：

echo 'export ANDROID_HOME=$HOME/Library/Android/sdk' >> ~/.zshrc echo 'export PATH=$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools' >> ~/.zshrc source ~/.zshrc

坑 5：skill 缓存与旧配置残留。我换了一个新版本 skill 后，规则和缓存还是旧的，导致新风格不生效。解决办法是找到缓存目录，手动清理旧版本的 skill 缓存，重启工作台加载新配置。这里也建议大家定期检查缓存目录，换版本后不要直接沿用旧缓存，否则你会以为新版本没效果，其实是旧缓存一直在干扰。

坑 6：全局规则没写对位置。我把规则写在了当前会话的任务说明里，结果新建会话语境就丢了。正确做法是把规则写到 WorkBuddy 的全局配置中，让"后续所有任务"都能读取。这一点对应了很多用户都在搜的"给 WorkBuddy 定几条规则，后续对所有任务都生效"。判断标准很简单：新建一个会话，随便说一句话，看它是否还带着你写的规则。如果丢了，说明你写错位置了。

坑 7：上下文被撑爆。有一次我一次性丢给它 12 个需求，输出质量断崖式下跌，甚至出现了把登录页逻辑拼到任务列表里的错乱。从此我把需求拆成最小任务单元，每个任务控制在 150 行以内的产出，好验证、好回滚。这条经验不仅适用于 WorkBuddy，适用于所有 AI 编程工具——它的上下文窗口再大，也不等于你可以不讲结构地野蛮输入。

3.3 开发与联调的六个坑

坑 8：组件库选型不匹配。起初用了较复杂的 UI 库，结果在 uni-app 编译到小程序时大量组件不兼容。我换成了更轻量、专为跨端设计的组件方案，页面重写了一遍。这个教训是：先确认目标平台，再选组件库，不要因为组件库好看就用它。而且换库的成本不是改两个组件那么简单，公共样式、主题变量、通用弹窗全都要跟着动，AI 又不会主动维护这些依赖关系，最后还是人工收拾。

坑 9：状态管理混乱。Pinia 的 store 没有提前设计，导致多个页面各自维护了一份任务数据。后果是列表页改完状态，详情页不刷新。修正为单一 store 统一管理数据源，页面只通过 store 读写，彻底解决了数据不同步的问题。这个经验对 AI 编程特别重要：AI 生成代码时只盯着局部，如果你不给它一个统一的 store 约定，它会在每个页面里重复造轮子。

坑 10：AI 幻觉 API。它生成过一个 uni.navigateToBack 的自定义参数写法，文档里根本没有。编译通过，一跑就报错。后来我强制要求"输出前列出 API 清单"，把幻觉拦截在写码之前。如果你不想每次都被这种低级错误浪费 20 分钟，这个流程一定要加上，而且要在全局规则里写死。

坑 11：token 与唤起回调问题。前面阶段四里提过，iOS 浏览器唤起 App 时回调参数丢失，根因是冷启动逻辑里没有处理 URL 参数，而 token 刷新又依赖本地旧状态。解法是：冷启动时统一走"解析参数 + 刷新登录态"的流程。这里多说一句：凡涉及"从外部唤起 App"的场景，务必把回调参数的消费放在 App 启动生命周期的第一步，优先级高于本地缓存恢复。

坑 12：本地缓存与远端冲突。本地缓存旧数据直接渲染，视觉上像"改了个寂寞"。加了缓存版本号机制后，本地和远端总能对齐。我把这个机制做成通用工具函数后，写进全局规则里，所有列表页都会自动带上。具体就是每次写入缓存时存一个 version 字段，读取时比较版本，过期就丢。别小看这个字段，它解决的是"用户信任感"级别的体验问题。

坑 13：抓包失败。一开始抓不到 App 的 HTTPS 请求，是因为工作台的代理配置和系统代理没统一。正确做法：将终端代理、系统代理、抓包工具三者配置成同一地址，并信任抓包工具的 CA 证书。这个问题排查了我一个下午，最后发现只是代理没同步，属于典型的"配置不连通"。遇到抓不到包，先按"代理链路上每个环节都指向同一端口"这个原则去查，通常比怀疑代码更高效。

3.4 测试与上架期的三个坑

坑 14：真机证书混乱。模拟器正常，真机提示无法安装。最终定位到描述文件过期，且打包证书与后台 Bundle ID 不一致。核对并替换后解决。这里建议做一张"证书信息对照表"，把证书名、有效期、bundle id、描述文件这四列全列出来，发布前逐项核对，能省掉很多无头绪的排查。别相信自己的记忆，人多手杂时只有表格靠得住。

坑 15：小屏兼容性漏测。只验了主流机型，小屏上按钮溢出。在全局规则里强制小屏适配宽度后，AI 下一轮生成的页面自动规避了这个问题。这个坑很典型：AI 默认按标准屏宽布局，所以你的验收清单里必须包含 320pt 宽度和小字号显示这两项。改规则比改代码划算得多，因为规则是全局的，代码是局部的。

坑 16：审核被打回。iOS 因为权限描述含糊被打回；Android 因为收集用户信息但隐私政策链接位置不明显被警告。两者都是"合规细节"，却足以卡住整个发布。改完文案、补全链接、重新提交后通过。审核不是玄学，它遵循公开的准则，你只要把该写清楚的写清楚，该放页面的放页面，就能稳定通过。我后来把权限描述的写法固定成"用于……，以便……"的句式，再也没在这个问题上栽过。

4. 可以直接复用的落地模板

4.1 全局规则模板

我把第二阶段用到的规则文件稍微泛化了一下，你可以直接复制改改看。重点不是里面写了什么，而是你要理解：全局规则是 AI 工作台最重要的"团队章程"。

project: your-app-name stack: uni-app + Vue 3 + Pinia language: zh-CN build_target: ios, android rules: - 组件统一使用组合式 API - 页面进 src/pages，公共组件进 src/components - 列表页统一使用缓存版本号机制 - 所有请求必须通过 request 工具函数 - 禁止使用未经验证的 API，编写前先列 API 清单 - 每个页面文件不超过 300 行，超出则拆组件 - 所有页面适配 320pt 小屏宽度

这份规则我建议在项目第一天就初始化，后续根据踩坑情况不断补充。坑 15 和坑 12 就是从实践中沉淀进规则的典型案例。先有三条能跑的，再慢慢完善，比憋一份大而全的规则文件更现实。

4.2 任务拆解与提交流程

结合这十六个坑，我把提交流程固定成五步：

1. 写清楚任务目标和验收标准，一句话说不清就继续拆。
2. 让 AI 先输出 API 清单和技术方案，确认无误再写代码。
3. 生成代码后立即跑 type-check 和编译，出错第一时间回滚，不补丁式修复。
4. 功能验证通过后，同步更新全局规则或更新文档。
5. 每个阶段完成时对照速览表检查一遍，确认没有遗留坑再进入下一阶段。

这套流程看起来简单，但能稳定提升 AI 生成的代码质量。核心思路是：AI 负责高效产出，人负责验收和卡边界。步骤 3 的"第一时间回滚"尤其重要：AI 修复 bug 时常常会引入新问题，与其让它越修越乱，不如直接回到上一个可用版本再重试。

4.3 上架前的最终检查清单

发布前一天，我一般会拿着这张表逐项打勾：

• 隐私政策页面是否有独立链接，且能在应用内打开
• 每个权限都有明确的用途说明，写法是"用于……，以便……"
• 版本号与构建号在所有平台保持一致
• 包体积做过分包 / 资源裁剪
• 崩溃收集与日志上报已接入
• 版本回滚预案已写好
• 数据接口在上架环境可用，测试域名已切换为正式域名

这些条目没有一条涉及复杂技术，但任何一条漏掉，审核都有可能打回。把这七条打印出来贴在工位上，比刷十篇上架攻略都管用。

4.4 最后想分享的心得

说实话，这套流程第一次跑通的时候，我最大的感受不是"AI 帮我写了多少代码"，而是"AI 把开发的门槛从写代码拉到了做决策"。需求该怎么切，边界在哪里，验收标准是什么，这些判断最终还是要人来拍板。十六个坑里，至少一半不是因为 WorkBuddy 不行才踩的，而是因为我自己在"阶段一"偷了懒。所以如果你打算照这套流程走，我的建议是：在需求阶段多花两天，把方案、边界、资质全部定死，后面会一路顺；反过来，前面省过的功夫，后面都会在某个坑里加倍还回来。另外，规则文件记得从第一天就写好，哪怕刚开始只有三条，也比等到被坑教育了再补强得多。