企业官网建设流程全解析

先交代一下背景：我最近用AI以对话式开发的方式，也就是大家说的 vibe coding，把一个小程序从零到一做了出来，并且已经顺利跑完了本地调试和真机预览的全流程。整个过程差不多花了两天，实际写代码的时间可能不到一个小时，剩下的时间全在和AI沟通需求、调样式、修边界情况。这篇记录就把我踩过的坑、摸索出来的对话套路，以及最后的成品效果，事无巨细地分享出来。

如果你是个想入门小程序开发但一直没动手的新手，或者你已经在写业务代码、但想试试让AI帮你加速日常开发，再或者你单纯好奇“AI写代码到底能不能真正落地”，这篇文章应该都能给你一些参考。我不会只展示“AI好厉害”的成果，更想聊聊它哪些地方特别顺手、哪些地方差点把我气到摔键盘。

1. 为什么我拿“小程序”开刀做 vibe coding

我手头其实攒了好几个想做的小工具，一开始纠结过要不要先做个网页版或者命令行工具，但最后选小程序，是因为它能逼着AI走完一套完整的项目闭环，而不只是生成几个零散的脚本文件。

1.1 小程序对AI来说是个“天然好捏”的载体

小程序有一套固定的目录结构，页面文件、组件文件、配置文件、样式文件分工明确，逻辑层和视图层分离。这套约定比传统前端项目要死板得多，但死板反而给了AI非常大的优势：它不需要去猜你的工程搭建方式，而是直接按照平台约定生成一套能跑起来的骨架。我用的是某小程序开发框架，AI生成的代码几乎不用改目录结构，文件放对位置就能直接编译。

相比之下，如果你让AI“写一个Web应用”，它反而容易迷茫，因为 React、Vue、工程化工具链、CSS方案都有太多分支选择，生成的代码往往能看但不好接。而小程序这边，页面就是 JSON 配置加 WXML 结构加 JS 逻辑加 WXSS 样式，AI在这套稳定上下文里表现得非常靠谱。

另外小程序天然带有云开发能力，数据库、存储、云函数都是开箱即用，这对“快速做出一个工具型产品”是致命加分项。你不用自己搭后端，也不用处理域名备案和服务器部署，AI生成的前端代码可以直接对接云开发语法。可以说，小程序的开发范式正好长在AI的舒适区里。

1.2 我最终要做一个什么样的成品

我不是想做一个花里胡哨的Demo，而是想解决一个真实生活问题：平时经常需要在多个平台间收集零散信息，比如临时记一笔金额、存一段随手抄来的文字、记录某个地点的坐标。用备忘录太乱，用笔记软件太重，打开即记、按标签快速筛选才是刚需。

所以我把目标定为一个极简的记录工具小程序，核心功能只有三个：快速新增一条记录、按标签筛选历史记录、支持简单的关键词搜索。界面走极简风，不需要登录，本地缓存优先，数据量大了才引导用户用云开发同步。这个尺寸的项目既能考验AI的完整度，又不至于复杂到失控。

提示：给AI下需求的时候，目标越“单一”越好。我见过很多翻车案例，上来就描述“做一个社区团购+社交+积分商城”，AI生成出来的东西既不像话，也没法调试。小步快跑，先从最小可行版本开始。

2. 工具选型和对话式开发的方法论

工欲善其事，必先利其器。vibe coding 看起来像是“随便聊就能出代码”，但实际效果天差地别。我试了两三个AI编程工具，最后稳定在一个老牌通用AI助手上面，下面说说我的选型维度和对话技巧。

2.1 AI编程工具怎么选更顺手

当前市面上的AI助手非常多，我的筛选标准归纳下来就三条：上下文长度、代码库理解能力、多轮对话的稳定性。

上下文长度决定了它能记住多少你之前的修改。我一开始用某个开源本地模型试过，靠聊天窗口连续对话，结果它过一会儿就把前面定好的页面结构给忘了，让我非常头疼。后来换成云端服务，上下文拉长之后，整体流畅度明显上了一个台阶。

代码库理解能力比很多人想象的重要得多。一个懂小程序工程的AI，会知道修改一个页面的时候需要同步改 JSON 里的导航栏配置、JS 里的数据字段、WXSS 里的样式类名。弱一点的AI只会改你提到的那一处，导致页面能编译，但整体风格稀碎。

多轮对话稳定性则关乎体验。开发过程中你肯定会反复提出小调整，比如“这个按钮往上挪一点”“字太大”“颜色太艳”，如果AI每次调整都会顺带把无关代码也改一遍，那对比差异就很痛苦。我用的那个工具在这一点表现尚可，但也不是每次都能精准命中。

2.2 我最常用的三段式需求表达法

跟AI沟通需求，我强烈建议不要甩一两句话就让开工。要把你的需求拆成三个部分，我称之为“身份 + 任务 + 边界”。身份是让AI知道你在做什么场景，任务是具体的功能描述，边界是告诉AI哪些不能做或者先不做。

一个典型的开场prompt是这样的：你是一个熟悉某小程序开发框架的前端工程师，请帮我创建一个极简记录工具小程序，首页是记录列表，底部有新增按钮，点击后弹出半屏输入面板，支持填写文本、金额和标签；本次先不要接云开发数据库，数据存本地缓存。最后再加一句：生成时请把文件清单列出来，每个文件标注用途。

这套说法的好处是，AI会在生成代码之前先做一层工程规划。我实测下来，只要把“任务”描述清楚，AI给出的文件结构基本能对得上，省去了大量来回纠偏的对话。

2.3 从“模糊想法”到“技术需求”的翻译技巧

作为非科班出身的人，我一开始根本不知道小程序里“弹出半屏输入面板”在技术上叫半屏弹层还是底部抽屉，也不清楚要用到什么组件。但我学会了让AI帮我做翻译：先描述感受，再让它给我技术方案。

我第二次对话时直接说：我想在首页做一个按钮，点击后从底部滑上来一个浅灰色的面板，里面可以输入文字，这个在你们小程序里一般用什么组件实现？AI直接给出了可用的方案，还推荐用内置的半屏弹层组件。那一刻我发现，vibe coding 的门槛比你想象低，你不需要懂专业名词，只要能把想要的效果描述出来，AI会帮你把概念转成代码语言。

心得：有时候与其直接问“我要实现XXX功能”，不如先说“我想要一个什么样的体验”，让AI给你补充技术选型。它给出的名词解释和组件推荐，本身就是在帮你补课。

3. 实操记录：两天做出一版能跑的小程序

下面进入正题，我把整个开发过程按时间线拆开，记录关键节点、核心对话和最终代码形态。如果按照本文的步骤走，大概不需要两天，你可以压缩到半天。

3.1 初始化项目骨架的完整流程

我先在本地安装好小程序开发者工具，然后新建了一个空白项目。接下来我没有像传统流程那样手动创建一堆文件，而是直接打开AI对话窗口，把下面这段需求扔了进去。

我需要一个记录工具小程序，要求如下：

• 使用原生小程序开发，不需要第三方UI库
• tabBar 有两个页面，一个用于记录列表，一个用于标签管理
• 记录列表页需要支持下拉刷新
• 每条记录在列表上展示标题、标签和金额
• 数据先存本地缓存，封装一个 storage 模块，方便后续替换成本地数据库
• 请先创建 project.config.json 之外所有必要文件，并标注每个文件的职责

AI返回了完整文件清单，包括 app.js、app.json、utils/storage.js、pages/index/index、pages/tags/tags 等约10个文件。我不需要自己动手创建任何文件，只需要在工具里点同步就能看到。这个环节最惊艳的不是代码本身，而是AI把所有基础配置一次性给齐，比如页面路径注册、tabBar 的图标路径占位、全局样式变量，基本不用再手动排查。

3.2 核心页面和交互的搭建过程

记录列表页是整个小程序的门面。AI生成的基础版本做了一个纵向列表，通过 data 数组循环渲染。但首批代码并不完美，主要问题在于没有空态页面，首次使用一片空白让人误以为报错了。我于是追加了一个调整需求：当记录列表为空时，展示一个居中的提示文案和插图，文案用“还没有记录，点右下角添加一条吧”。

添加记录交互我一开始没想清楚，所以让AI自己提方案。AI给了一个底部半屏弹层方案，里面包含一个多行输入框、一个标签选择器和一个金额输入框。提交时做基础校验，标题为空就轻提示，不阻断输入。这部分生成得比较稳定，我几乎只改了标签选择器的样式，把胶囊式标签改成了更适合单手操作的网格样式。

存储层是比较容易忽略但非常重要的部分。AI生成的 storage 模块封装了 get、set、remove 几个方法，还做了 JSON 解析异常保护。如果后端数据格式变了，或者本地缓存里的数据损坏了，不至于整个页面崩溃。这套封装我后面在真实设备上跑的时候的确派上了用场。

3.3 如何一步步让AI把风格调成我想要的样子

我审美比较固定，喜欢大字号、粗细对比明显、背景干净的风格。但AI默认生成的是典型的“模板小程序感”：浅灰色背景、蓝色按钮、方角卡片。为了调整观感，我用了风格参考法，把一段直接描述发给AI。

请把首页列表的卡片改成白色背景、大圆角、细边框，标题字号放大到34rpx且加粗，标签使用浅色底深色字，金额右对齐并用等宽字体风格。整体风格走清爽、克制、偏纸质笔记本质感的路线。颜色主色用深灰，辅助色用浅绿，不要用任何渐变色。

这里AI的文案理解能力是关键。它能把“纸质笔记本质感”转化成“大留白”“细分割线”“米白背景”等具体样式参数。经过三轮调整，最终的视觉风格跟我的预期大概重合了80%。剩下那20%是我自己手改的样式变量，实在不值得为了它跟AI来回磨。

3.4 云开发接入：从纯本地到数据同步

第一版跑通后，我开始给它加“后手”：通过云开发把数据备份到云端。为什么要加这一步？因为纯本地缓存有一个致命问题，小程序更新或者清理缓存后数据就没了。万一用户换了台设备，记录就彻底丢失。

接入云开发不需要写任何后端接口。AI生成了一段云函数代码，用于同步本地记录与云端集合。我只需要在开发者工具里创建对应环境名，再配置好 collection 权限即可。AI生成的云函数写得相当工整，错误处理完备，代码质量甚至比很多外包团队的初始版本高。

不过这里有一个很重要的教训：AI对云开发环境配置的理解是默认“你已经有环境了”，它不会提醒你去开通云服务，也不会帮你处理环境ID。这一步折腾了我将近一个小时，最后是我自己发现环境列表是空的，创建之后所有请求才恢复。

注意：用AI生成对接云开发的代码时，提前把“环境ID”“集合名”“权限设置”这些边界条件在prompt里说明，否则AI会给出一份理论正确但跑不通的代码。后来我在第二次类似项目中吃了这个亏。

3.5 真机预览与编译调试的实操记录

开发工具里的模拟器跑得很好，不一定是真机没问题。我碰到最典型的问题是底部安全区适配，iPhone 全面屏底部那条横线直接覆盖了tabBar，点按区域直接失效。AI在代码里没有处理这个，因为开发工具默认不显示真机的完整安全区。

解决办法是让AI在样式里加上环境变量的适配代码，使用 safe-area-inset-bottom 处理 tabBar 高度，同时给弹层底部加上安全距离。AI对这个问题的理解很快，替换样式后真机表现正常。

另一个高频问题是组件自带的默认样式在不同平台下的表现不一致。比如单行省略的写法在开发者工具里正常，在部分安卓机型上会显示三行。这些属于平台级差异，AI的代码规范没问题，但没法预判所有机型。我的策略是凡涉及文本截断，统一用多行截断写法，并用样式覆盖默认行为。

4. 我在 vibe coding 过程中踩过的具体坑

这一节是我认为最有价值的部分。网上许多教程讲到AI生成代码都是报喜不报忧，但实际开发过程中狗血剧情真的不少。我整理了五个最具代表性的翻车现场，每个都附上了排查思路和最终解法。

4.1 需求描述太抽象，代码能跑但完全不是我想要的

第一次给AI描述首页时，我说的是“要好看一点”。结果AI给了一套带轮播图和动态背景的模板式页面，完全不适合记录工具。我意识到问题在于“好看”是主观感受，不是可执行指令。从那次以后，我所有需求描述里必须带上参考关键词，比如“类似苹果备忘录的极简风格”“参考豆瓣电影的卡片布局”，AI的生成效果立刻稳定了一个档次。

4.2 上下文窗口再长也挡不住它“记忆飘移”

聊到第25轮的时候，AI突然把之前定义好的存储字段名改了，从 text 改成了 content。这导致列表页和新增页彻底失联，页面能编译但数据根本显示不出来。排查花了我20分钟。后来我学乖了，涉及关键字段名和公共模块时，直接把前后端依赖关系发给它，并提醒“不要改动storage模块的对外方法名”。

实操心得：如果你在一个项目里长时间对话，一旦发现AI开始频繁“自创”命名，果断开启新对话，并把目前的完整文件结构和核心导出字段贴进去。新对话虽然丢了记忆，但至少不会继续在错误的命名上叠加。

4.3 样式“越调越崩”，不如在关键节点锁版

AI改样式存在一个天然缺陷：它没有“视觉记忆”。你让它把按钮改成青色，它会把全站所有按钮都改成青色，甚至把选中的标签也改成青色。改完你告诉它太青了，它又可能把卡片背景也带了。在连续五轮样式调整之后，我意识到必须“锁版”：每次对样式满意后，就明确告诉AI“当前样式已确认，后续只修改交互逻辑，不要改动任何颜色和间距”。这招非常管用，它后续的改动基本不会触碰样式。

4.4 AI对“平台差异”缺乏直觉，真机跑了才知道

开发者工具和真机是两个世界，这句话在小程序里尤其正确。AI能处理代码层面的兼容问题，但无法感知物理设备上的表现差异。比如自定义弹层在部分安卓机上有蒙层穿透问题，点击蒙层关闭的同时也会触发底层页面的滚动事件。这些BUG在模拟器上完全无法复现，只能靠真机用户反馈。

我的排查方式是：把问题描述给AI，告诉它“点击蒙层会连带触发底层页面的滚动，应该使用 catch 冒泡捕获还是禁用底层滚动”，也就是给出二选一的处理方向。AI给出的方案准确且不引入新问题。

4.5 别被“一次性生成”的爽感骗了，结构化重构才是老江湖的做法

在项目快收尾时，我突然想加一个数据统计功能，让AI把所有记录按月份汇总。AI尝试直接在列表页里塞一段汇总函数，代码逻辑没有问题，但页面开始变得臃肿。这一步是我主动叫停并要求它重构的：把统计逻辑抽到独立模块，页面只做展示。AI重构后的代码清晰很多，甚至把没必要传给页面的字段都过滤掉了。

这件事给我的启发是，AI能加速编程，但架构设计的主动权还是要留在自己手里。你可以不懂每个函数的内部实现，但至少要能判断哪些代码正在变得不可控，并果断指挥AI来一次重构。

5. 如何把AI写代码这件事真正变成你的开发习惯

项目收官后，我复盘了整体工作流。vibe coding 并不是“让AI替代你写代码”，而是“让你用产品经理的思维来管代码”。它带来最大的变化是，开发和设计之间的反馈循环被压缩到分钟级。以前改一个按钮可能要翻半天代码，现在一句话就办到了。

5.1 我给新手的三条“降噪”建议

第一，每个功能模块单独开一个对话。比如新增记录一个对话，标签管理一个对话，云开发一个对话。不同模块之间的技术栈虽然相同，但对话上下文如果混杂在一起，AI容易把A模块的风格带进B模块。你可以把公共字段发给每一个对话，但不要在同一个对话里跨模块做大改。

第二，一定要让AI先输出计划再生成代码。我通常会在具体需求后面加一句“先输出你的实现计划，计划确认后再写代码”。这个要求会显著提高代码的符合度。AI在写代码之前已经规划好了，不会写一步想一步，结构性错误少非常多。

第三，养成版本控制的习惯。没上正经代码托管工具之前，我全靠手动备份文件。有一次AI把一整页代码改出问题，我想退回前一版居然找不到，只能靠AI重新生成再手动缝合，极其痛苦。后来把项目托管好，每次让AI改完，方便随时对比。

5.2 vibe coding 的适用边界

我现在更愿意把 vibe coding 定义成“创意快速验证工具”，而不是“生产级开发手段”。如果你要做的是一个内部工具、个人作品集、课程项目、Hackathon Demo，它几乎是无敌的效率神器。但如果你要做一个需要大量真实用户、有复杂权限系统、涉及高并发场景的商业项目，那AI能帮的忙就很有限了。

它比较拉胯的方向包括：复杂的动画交互、深度的性能调优、跨端行为差异大的业务逻辑。AI能生成看起来正确的代码，但离生产级还有距离。你要是把这些代码直接上线，可能等着你的就是体感卡顿和线上事故。

5.3 从这次记录里提炼的通用工作流

现在每当我有一个想试试的产品点子，我都会走一遍这套流程：

1. 在文档里用大白话写清楚“这个产品要解决什么问题”，不写技术方案。
2. 把文档发给AI，让它提出技术选型和文件结构。
3. 让AI生成骨架代码并直接编译，确认项目能跑通。
4. 逐个页面做交互和视觉优化，每页一个对话窗口。
5. 本地功能做完后，在开发者工具里反复编译和清理报错。
6. 最后才是真机预览，并重点检查安全区、兼容性和异常提示。

这套流程已经把我要做的项目从“一个月才能上线”压缩到“一个周末出Demo”。我觉得对于那些经常有想法但被实现成本挡在门外的人来说，这真的是一个特别好的时代。你不一定需要成为一个资深程序员才能做出一款像样的产品，你只需要懂逻辑、有审美、能说清楚需求，剩下的都交给AI跑腿。

6. 最后再说点实在的

如果你读完这篇也想试试，我建议从明天就开始，不用等一个所谓的完美时机。找个周末，选一个你自己真的会用到的小工具，打开AI助手，把第一句话发过去：“请帮我创建一个极简记录小程序。”就这么简单。

我这次做完之后最大的改变，不是掌握了多少新框架用法，而是养成了“把每个灵感快速做成原型”的习惯。以前我会说“这个想法不错，但要做出来太累了”，现在我会说“先让AI写个一版，反正半小时能搞定”。哪怕最后这个版本不会上线，它也会让我对“做产品”这件事保持持续的信心。

最后分享一个特别有价值的个人经验：AI写代码的最高境界不是让它帮你写，而是让它陪你讨论。闲聊时的灵光一现、代码审查时的叫板质疑、技术方案上的讨价还价，这些才是最值得你投入时间的部分。技术永远在迭代，但那种能跟工具深度协作的感觉，一旦你体验过，就很难再回去了。