企业官网建设流程全解析

我上个月给自己下了一个有点“狂”的任务：一周内，从零到一把一款音乐播放器做成能上生产环境的 Flutter 鸿蒙 App。更离谱的是，这次我打算全程用 Vibe Coding 的方式推进——也就是让 AI 承担大部分编码执行、我来定义需求和把关架构。以前我写 Flutter 应用总是碎片化地复制粘贴各种代码片段，一个播放器项目能拖一个月；这次换打法之后，我发现自己不是“少写了多少代码”，而是把时间重新放回了该放的环节。这篇文章就是我这次 7 天冲刺的完整记录：怎么拆任务、怎么用 AI 高效生成 Flutter 鸿蒙代码、鸿蒙适配到底和安卓差多少、以及那些文档里不会写但发布会要命的细节。

如果你正在犹豫要不要用 AI 辅助开发鸿蒙应用，或者你的 Flutter 项目准备兼容鸿蒙生态，这篇连载的第一篇应该能给你一份能直接照做的路线图。内容会比较长，我尽量把“为什么这么做”也讲清楚——毕竟光给结论不给理由，换个场景你就不会用了。

1. 先聊清楚：Vibe Coding 到底是怎么帮我做鸿蒙 Flutter 应用的

很多人一听到 Vibe Coding 就以为是一句话扔给 AI，然后等出一整个 App。真有这么简单就好了。我在这次项目里的定义很明确：AI 负责快速产出可运行的 Dart 代码，我负责拆需求、定接口、审代码和修边界问题。整个开发过程中，我想要的是一个又能聊需求又能直接给方案的结对编程搭档，而不是一个“代码生成器”。

1.1 为什么过去的碎片化开发方式真的会卡住

之前我写音乐播放器，习惯是到处找片段：列表页从某项目抄一下，播放页从另一个 Demo 改，网络层看心情封装。最后代码里充满了三种不同的 loading 状态、两套错误处理逻辑、甚至还有互相冲突的播放器插件实例。这其实就是碎片化的代价——每段单看都对，合起来就是个定时炸弹。

这次我换了个思路，把整个应用当成一套系统来设计：音频层只暴露统一的播放接口，UI 层只靠状态对象订阅更新。这个架构草图是我和 AI 一起讨论确定的，不是某个人丢给我一份模板。AI 在方案阶段的帮助被严重低估了——它会主动追问“后台播放怎么处理”“弱网下音频流策略是什么”，这些问题过去往往要等开发到一半才暴露出来。

1.2 实际操作中被验证有效的协作姿势

我把 Vibe Coding 拆成三个固定动作：先对话建模、再小块生成、最后集中审查。对话建模不只是描述功能，而是把边界、异常、平台差异都讲清楚。小块生成是指每次只让 AI 产出一个文件或一个类，绝不一次性生成“整个播放器”。集中审查是每天花固定时间把当天代码通读一遍，该重构就重构。

这套流程听上去朴素，但特别管用。比如在定义播放队列状态时，我告诉 AI“我需要支持顺序播放、单曲循环、列表循环三种模式，队列在空列表和加载失败时不能崩”，它给出的实现里就用了一个枚举类型加一个队列快照的拷贝策略，而不是把逻辑散落在页面里。这样的设计一旦确定，后面接 UI 和接后台时都省了很多沟通成本。

说句实在话：用 Vibe Coding 不等于你的工程质量会自动变好。会提问、会拆解、会审查的人，AI 才是杠杆；什么都不会的人，AI 只是把烂代码生成得更快而已。

2. 7 天冲刺拆解：别想一口气吃完，我把每天要交付的东西列给你

一周时间从零到发布，关键不是“能写多少代码”，而是“每天能验证什么结论”。我把整个周期切成了七个小的交付节点，每一天结束的时候，项目都必须处在“可编译、可运行、可展示”的状态，而不是一堆半成品文件躺在目录里。

2.1 7 天时间线与每日验收标准

我直接把计划表放出来，内容不多，但每一条都是真的执行过的：

这份计划最关键的一点是：每一天的验收标准都必须是可演示的。如果哪天验收不了，第二天起床第一件事就是解决前一天的问题，绝不带着隐患继续往后冲。D4 是最难的一天，因为它把 UI、状态、音频、网络全部串起来了，任何一个环节掉链子，播放器都是“看起来有了，实际上不能放”。

2.2 时间紧的时候，AI 最该帮什么忙

以前遇到这种时间表，我会把“写完所有页面”当成最大的压力来源，代码量最大、最熬人。但这次我让 AI 去写那些高重复、低决策量的代码：列表的 loading 骨架、卡片组件、下拉刷新逻辑、接口 DTO 映射。我集中精力盯三件事：音频引擎的封装、鸿蒙平台行为的适配、后台播放那套复杂状态流。

客观来说，AI 生成的代码里有一半以上是可以直接用的，但剩下那些需要改动的地方，基本集中在“边界状态”上——比如断网时的异常恢复、音频被电话打断后的焦点回归、页面销毁时播放器实例该不该跟着销毁。这些细节如果不自己盯，生产环境一定会踩爆。

3. 鸿蒙适配比想象中多一步：权限、后台和媒体会话

做 Flutter 开发很多年的人，第一次接触鸿蒙工程时多少会有点“这居然不能直接照搬安卓”的感受。鸿蒙不是安卓套壳，它的工程结构、权限声明、后台任务约束都有自己的逻辑。我在 D5 前后集中处理了这块，可以说，适配工作的坑基本集中在三个地方：权限声明体系、媒体会话交互、后台任务的申请与降级。

3.1 权限模型和安卓是两套逻辑

鸿蒙应用的权限声明是写在独立配置文件里的，默认都是静态申请，敏感权限还要在用户触发功能时动态请求，并且官方要求你在界面里说清楚用途。我在实现麦克风相关能力时没有用，但音乐播放器涉及的“长时任务”权限要特别注意：你需要声明具体的任务类型是音频播放，并且在申请时向系统证明你的应用确实在前台产生了音频会话。

这里有个易踩的坑：很多教程是照搬安卓的“写入外部存储”那套思路，但鸿蒙的媒体库权限是分文件类型粒度的，音乐文件读取、音频资源扫描、通知栏媒体控制都是不同分组。我一开始把权限声明写得太宽，审核的时候被打回了一次，理由就是“申请权限与功能场景不匹配”。后来老老实实按功能拆开，反而一次通过。

3.2 后台播放：不只是切到后台不暂停

音乐类应用最怕的事情是：用户锁屏之后声音断了，或者通知栏没有控制按钮。鸿蒙对后台播放有一套明确的“长时任务”机制，你必须先申请长时任务权限，然后在应用生命周期中主动发起任务，系统才会允许你在后台持续播放。如果你只是开了权限但不在合适时机上报任务，系统照样会在几分钟内挂起进程。

我这次的处理方式是：在播放器真正开始播放声音的瞬间才发起长时任务，而不是 App 一启动就申请。这个细节很重要，因为用户可能只是进来浏览歌单，并不想让你在后台驻留。播放暂停时马上停止任务，避免被系统标记为“异常后台行为”。锁屏媒体控制则依赖鸿蒙媒体会话框架，UI 组件要把播放状态、封面、标题实时同步过去，和 UI 层各自维护状态的做法完全不同。

提醒一句：你如果准备做鸿蒙版播放器，最好把“通知栏控制是否正常”“锁屏状态是否可操作”“断网后任务是否自动退出”这三项写进每天的回归用例里。这些在模拟器上都不太容易暴露问题，真机上才能看出差异。

3.3 Flutter 插件在鸿蒙上的兼容性策略

Flutter 生态里很多音频插件默认只实现了安卓和 iOS 的端侧代码，到了鸿蒙工程里你会发现底层能力是缺失的。我用的方案是抽象出一个 PlayerAdapter 接口，Flutter 侧只面向这个接口调用，具体实现则根据平台不同来选择：在鸿蒙环境走鸿蒙原生媒体能力，通过 MethodChannel 和 Dart 通信，音频播放的循环、速率控制、请求和暂停都收口在统一方法里。

这个设计付出的代价是 D4 当天几乎没有写多少 UI，但收益在后面几天集中体现：后台播放、锁屏控制、异常恢复这些能力，我都在原生侧集中实现， Dart 层只需要订阅状态，再也不用到处加平台判断。你要是直接在 UI 里散落一堆平台判断，后面的崩溃排查会很头疼——这点我在 D6 验证过，同一首高码率音频在安卓上正常，在鸿蒙真机上却出现了缓冲问题，因为定位到 PlayerAdapter 一层就锁定了范围，没有花时间在无关代码上瞎猜。

4. 生产级播放器的细节：从状态管理到异常恢复，不能只“能播”

“能播”和“能上生产环境”，中间隔着很多琐碎但致命的问题。我在这个项目里体会最深的是：播放器不是一个页面，而是一个长期存活的状态机。用户切走、锁屏、来电话、网络切换、音频文件损坏，这些都是状态机必须处理的输入。AI 可以帮你把状态机的骨架写出来，但每一种状态的触发条件和迁移路径，必须人来确认。

4.1 播放器状态机的设计与落地

我把播放器状态简化为六种：空闲、加载中、播放中、暂停中、缓冲中、错误。每次状态变化都会同时推给 UI 层和媒体会话层。这个设计直接解决了“页面 A 播放，页面 B 也要显示播放进度”的问题——因为进度不在页面里，而是在播放器服务里。

具体到代码层面，我用了一个不可变的状态对象，每次变更都生成新实例，避免多页面同时修改状态造成互相覆盖。队列更新也走同一套状态推送，切歌、删歌、置顶都在队列快照上操作，再整份替换。这套玩法带了一个额外好处：错误恢复变得好写了。当网络音频加载失败时，状态机会切换到一个错误状态并保留上一份有效的队列快照，用户重试时只是把状态切回“加载中”，重置的代价很小。

4.2 资源释放与内存问题：最容易被忽略的生产级指标

播放器常见的崩溃场景不是功能缺失，而是资源没释放：音频会话没有关闭、异步回调没有取消、后台任务没有及时终止。我在 D6 用连续切换歌曲加反复进出播放页的方式做压力测试，大概第 40 多次操作后应用的内存开始明显上涨，定位后发现是某个回调持有了解码器实例。

这个问题的经典之处在于，正常使用根本感觉不到，但一旦用户听歌一两个小时，内存就积蓄成崩溃。我后来在播放器服务里加了一个统一的资源回收入口，切歌、暂停、退出播放器都会执行回收；同时将回调生命周期托管给播放器服务，页面销毁时只反订阅，不直接关停播放器。真机上连续两小时播放的测试才稳定通过。

4.3 弱网与音频流异常：Vibe Coding 生成的代码需要“喂”边界条件

AI 默认生成的逻辑里，网络请求失败后往往只是抛一个异常，但播放器场景需要更细的策略：是自动重试？还是切到下一首？还是保留错误现场等用户手动操作？我告诉 AI 三档策略：第一档是瞬时失败自动重试两次；第二档是连续失败切换到下一首；第三档是整首音频损坏时报错并保留队列。这样既不过度打扰用户，又不会卡死播放。

这里有一个很实用的提示词技巧：不要只说“处理错误”，而是把具体的业务规则写清楚——什么情况下做什么、连续多少次做什么、用户修正后如何恢复。AI 在拿到明确规则后写的异常处理代码，比我自己凭手感写的要全面得多。

5. 发布前夜：签名、隐私声明和一条一条踩掉的坑

D7 的日程比预想中紧张得多。本来以为功能完成就万事大吉，实际上仅应用的签名构建和隐私合规材料整理，就花了大半天。鸿蒙应用的发布流程有自己的节奏，签名最近还在过程化调整中，如果不提前准备，很容易在审核环节卡住。

5.1 签名、证书和构建链路

Flutter 工程构建鸿蒙应用的时候，需要改用鸿蒙的构建工具链，签名配置也要换成鸿蒙格式的证书文件。我一开始按旧的安卓签名流程操作，打包后的应用始终无法安装到真机上——不是 Flutter 侧的问题，而是包签名类型不匹配。

解决方式并不复杂：申请鸿蒙开发者证书，配置到工程里，按照官方 HelloWorld 的签名指引把文件和配置逐项对照，再用真机安装验证一遍。但这里有三个必须确认的细节：调试证书和发布证书不能混用；证书的包名必须和申请时填写的应用标识一致；签名生效前最好在命令行里做一次手工构建，不能依赖 IDE 的“一键打包”。

5.2 隐私声明与权限说明：先扫自己再送审

审核被驳回最常见的原因是权限说明模糊。我在第一次提交材料时写了一句“需要存储权限以读取本机音乐”，结果被要求细化。后面我改成“仅在你选择从本机媒体库导入歌曲时访问音频文件，不会扫描与音频无关的媒体内容”，并补上了隐私协议页面。注意：这些声明不只是给审核员看的，用户也真的会读。

除了文字说明，鸿蒙的隐私检测工具会扫描代码里申请的接口和权限是否与声明一致。如果你的代码里调用了某个系统能力但没在声明里体现，扫描也会报警。所以发布前我专门梳理了一遍所有端侧通道调用，确保声明的权限与实际使用的权限一一对应。这块 AI 帮不上太多忙，因为它是合规审查，不是编码效率问题。

5.3 包体积与启动优化的妥协方案

Flutter 应用在鸿蒙上打包后的体积比安卓版大一点，因为引擎和鸿蒙侧的平台层都要包含进去。我做了一个务实的取舍：不再把所有网络图片资源都塞进包内，封面图走瀑布流加载，占位图用原生绘制而不是大图；字体文件只保留常用字符子集。启动逻辑也做了调整，应用首帧只渲染播放器的入口页，音频引擎延迟到用户第一次播放时才初始化。

这样调整之后，冷启动时间比初版下降了大约三成。对于工具型应用来说，这个收益非常实在——用户不是一上来就要听歌，他可能只是想看下你的首页长什么样。

6. 最后想说的关于 Vibe Coding 的心法

如果只让我总结一个词，那就是“审查”。AI 生成的速度越快，审查的责任越重。我在项目中途想过完全放手，让 AI 自己连续写几千行代码，结果在 D5 的合并检查里发现后台播放的代码设计和通知栏状态冲突，如果真按那个版本发布，后台播放时通知栏点击会延迟两三秒。重写那段逻辑花了四个小时，但这件事帮我确立了剩下的两天都按“连续生成 + 每半天审查”的节奏推进。

6.1 几条经过实测的 Vibe Coding 规则

第一，永远让 AI 先给出方案再给代码。项目里凡是复杂的模块，我都先问一句“你打算怎么设计”，然后从它的回答里挑出不合理的地方。直接要代码的话，你只能收到一个看起来不错的实现，但不知道为什么这么设计。

第二，用提交记录当提示词的上下文。我会把能编译、能跑的中间版本当成新的起点，告诉 AI“基于这个版本继续改”，而不是让它每次从零生成一份新的。这样可以极大减少“删了原来的功能”这类事故。

第三，把测试描述也当成需求的一部分。我想验证某一项功能是否符合预期，就直接把验收标准作为需求发给 AI：“当后台播放时来电话，应暂停播放；通话结束后如用户之前处于播放状态，应自动继续播放。”AI 写的代码就会顺着这个链路考虑，而不会只关注“切后台不断流”这一件事。

6.2 这次项目后我对 AI 编程的重新认知

以前我总觉得用 AI 写代码就是“偷懒”，会让自己手生。但这次 7 天的实践告诉我，真正的能力在于快速验证哪些设计是对的。有了 AI，我可以同时比较三种音频接入方案，而不是只挑一种埋头写。多出来的试错成本很低，低到我可以把一个模块重写三遍，然后挑选最稳的版本。

这个系列之后我打算接着写鸿蒙特定组件的适配经验、播放器的进阶手势控制，以及如何把 Vibe Coding 流程沉淀成团队能复用的开发规范。如果你也正在做 Flutter 鸿蒙项目，或者对 Vibe Coding 的玩法有自己的一套，欢迎把你的踩坑经历一起分享出来，我们下期接着拆。