企业官网建设流程全解析

1. 第208天：产品点亮的那一刻，我却按下了暂停键

第208天，我的AIR眼镜V0.9终于跑完了最后一轮系统测试。戴上它，看到眼前的半透明界面正常弹出AI助手回复、导航箭头和翻译文本，我心里冒出的第一个念头不是"成了"，而是"如果重新来一遍，我不会这么设计"。

AIR眼镜这个项目，说白了就是一台戴在脸上的轻量计算终端：带近眼显示、带麦克风阵列、带摄像头，能语音问答、能翻译、能提词、能看导航，核心卖点是"把AI从手机屏幕里解放出来，放到你的眼前和耳边"。208天前我开始做它的时候，市面上还没有几款真正把AI大模型塞进眼镜形态的产品。我当时很笃定：这才是下一块屏幕。

但完成的那一刻，我花了一个下午把整机测试数据、决策日志、采购清单全部翻出来重看。做完了，我却决定重新想一遍。这篇就是那一天的完整复盘。

1.1 这个项目原本想解决的问题

最初立项的时候，我给自己写的一句话是：人机交互的带宽不该被一块6寸屏幕锁死。

手机通知、导航、翻译、备忘录、AI问答——这些信息90%只需要"扫一眼"或"听一句"，但我们现在必须掏出手机、解锁、打开App、退出，一顿操作猛如虎。AIR眼镜的目标，就是让信息主动找用户：你走路时眼睛能扫到导航箭头，听外语时耳朵能收到同声翻译，开会时眼前能飘提词稿，剩下的事交给语音。

听起来很美对吧？我就是被这个愿景带着跑了208天。

我当时的范围界定得非常"极客"：单目显示、AI语音助手、手势识别、摄像头取词翻译、手机通知同步、导航信息流转。现在回头看，这份PRD更像一个功能清单，而不是一个产品定义。但当时谁劝我都没用，年轻嘛，项目总有那么一段不听劝的时候。

1.2 208天的时间线：从动手到"阶段性完成"

先交代一下节奏，方便后面讲述具体问题时有参照。

半年多的业余时间，几乎全部砸在这里面。白天上班，晚上和周末画板子、改驱动、调模型。不是没想过放弃，但每次把新功能跑通的那个瞬间，又觉得自己无所不能。

直到第208天，我把所有"跑通了"的功能放在同一个场景里实测的时候，才意识到：功能全通，不等于产品成立。

2. 硬件的取舍：Birdbath光学、RK3588和一块1400mAh电池

说技术之前先聊聊选型。AIR眼镜最核心的三个硬件决策：显示方案、主控平台、供电形态。这三样决定了产品的体积、续航和成本上限，后期几乎无法推翻重来。

2.1 显示方案为什么选了Birdbath而不是光波导

近眼显示目前主流就两条路：Birdbath（鸟浴式光学）和几何光波导/衍射光波导。

Birdbath的原理不复杂：OLED微显示屏发出的光线经过分光镜和球面镜反射，在空气中折叠光路后进入人眼。好处是结构简单、量产成本低、显示色彩和对比度好，个人开发者也能通过现成模组搭出来。缺点同样明显：光机体积大，装在眼镜上会突出一个圆柱体，透过率也只有20%左右，外界光线被削弱，户外观看效果打折。

光波导则是在一片玻璃基板上用纳米微结构把光线"导"进眼睛，镜片可以做得接近普通眼镜。问题是贵，单片全彩衍射光波导模组的开模价动辄几十万，个人项目基本没戏。

我当时的选择完全基于预算和时间：Birdbath光机模组，单目，右眼，MicroOLED，720p分辨率。采购成本控制在三千元以内，一个周末就能点亮。第40天我看到图像清晰显示在眼前的瞬间，兴奋得在工作室里转了三个圈。

后来我才想明白，光波导虽然贵，但"眼镜形态"和"显示效果"本来就该是一体的。Birdbath模组帮我跑了原型验证，但也让我在结构阶段付出了巨大代价——详见第4章。

2.2 主控选型：个人开发者为什么选了RK3588

主控是整个系统的CPU。我的优先级是：接口丰富度 > 算力 > 生态成熟度 > 成本。

候选主要有三个方向：高通骁龙平台、全志/瑞芯微平台、以及"单片机+手机投屏"的轻量方案。

高通的XR2是很多商业AR眼镜的选择，但个人开发者拿不到开发板，签NDA流程长，而且核心板价格感人。手机投屏方案虽然轻，但整机变成"眼镜+手机"双设备，我想要的"端侧AI"就没了意义。

最后选了瑞芯微RK3588：8核Cortex-A76/A55，集成6TOPS NPU，带双ISP、多路显示接口，能跑AOSP（Android开源系统），且核心板带焊接好的基础外围，个人开发完全够用。它让我可以在眼镜里本地跑语音唤醒模型和手势检测，不必一切依赖网络。

这个选择在开发期帮了大忙。RK3588的开发文档和社区资料相对齐全，遇到的坑（比如VPU编解码对齐、NPU算子精度问题）都有人在论坛踩过。不过它也是一块功耗大户，空载就1.5W，满载能飙到6W以上——这对后面续航和发热的影响是致命的。

2.3 传感器与音频：我最终敲定的整机清单

整机除了主控和显示模组，还集成了这些模块：

• IMU惯性传感器：BMI270，用于头部姿态识别，拿它做"点头确认/摇头取消"的交互基础。
• 手势摄像头：OV9281全局快门摄像头，120fps，专门拍手部动作，数据送到NPU跑手势关键点模型。
• 取词摄像头：OV5640自动对焦摄像头，朝向场景，用于OCR拍文字。
• 双麦克风阵列：用于波束成形，定向拾取人声，抑制环境噪声。
• 骨传导扬声器：贴在镜腿内侧，不堵耳朵，声音通过颞骨传到内耳。
• 环境光传感器：自动调节显示亮度。
• 电池：异形软包锂电池，标称容量1400mAh。

这套配置在当时看来相当"豪华"，每一件都有明确用途。但回过头数一下，全身上下的传感器和工作模块加起来有十几个，任何一个都在贡献功耗、发热和重量。当时的我没有"少就是多"的意识。

2.4 一块电池引发的热设计博弈

最大的矛盾发生在电池和发热之间。

我们想当然地认为：眼镜重量最好不要超过60g。留给电池的重量上限只有28g左右，对应异形软包电池的容量极限大概是1400mAh。而整机在显示+识别+NPU推理同时开启时，实测功耗在4W上下。

简单算一笔账：1400mAh电池，标称3.8V，总能量约5.32Wh，除以4W功耗，理论续航83分钟。实际还要考虑发热降频、电压跌落、转换效率，最终实测亮屏连续使用续航为82分钟（那台机器个体差异还蛮大，另一台74分钟就关机了）。

更麻烦的是发热。RK3588满载时芯片表面温度轻松到65℃，通过结构件传导到右眼镜腿，而镜腿正好贴着太阳穴。测试中连续使用30分钟后，太阳穴位置实测温度到了41℃。41℃是什么概念？暖宝宝贴久了也就这温度，人体对持续接触的耐受阈值在37-38℃上下。

为了降温我试过：改散热片材质、加导热凝胶、降低NPU频率、把主控从镜腿移到镜框前部（反正远离太阳穴位置）。效果有限，最好的方案是限制CPU频率到70%来换取温度降低，代价是AI回复速度明显变慢。

这个矛盾直到最后都没有真正解决。我当时的解法是"软件限频+提示用户注意休息"，本质上是在糊弄。

3. 软件与AI架构：眼镜不是手机，交互得重新设计

硬件只是载体，真正让AIR眼镜"活"起来的是软件。这一层我踩的坑不比硬件少。

3.1 从AOSP里拆出一套"眼镜系统"

系统底子选择的是Android 12 AOSP，原因很现实：RK3588的BSP（板级支持包）对Android支持最成熟，GPU驱动、VPU解码都有现成的。我只需要做减法。

我砍掉了电话、短信、原生桌面、Chrome、输入法、GMS全家桶等模块，保留核心的SurfaceFlinger合成、AudioFlinger、Sensor HAL框架和网络栈。开机时间从原生系统的23秒压缩到9秒，空闲内存从3.8G降到1.2G。

然后我写了一个桌面应用，其实就是全屏Flutter界面，分成几个卡片：AI对话、翻译、提词、导航、通知。通过一个自定义的WindowManager服务，把应用内容投射到Birdbath光机那块MicroOLED上。

有一个细节值得提醒：不要直接复用手机系统的状态栏和通知框架。手机通知是"亮屏打扰"，眼镜通知是"随时存在"。AIR眼镜的通知应该走专门的通知抽象层，根据当前场景决定是语音播报、眼前弹窗还是静默排队。这个抽象层我第120天才开始做，前面一直在硬套Android原生的NotificationListener，体验非常割裂。

3.2 本地NPU与云端大模型的分工

AI能力是我的核心卖点，但绝不能做成"一个对话框走天下"。我的分工原则是：轻量任务端侧跑，复杂理解云端跑，结果呈现走眼前。

端侧NPU负责三件事：

• 本地唤醒词识别（自训练的小模型，识别"你好小AEA"这个口令，响应延迟约180ms）；
• 手势实时检测（手部关键点模型，轻量版，在NPU上推理约13ms/帧）；
• 头动姿态识别（配合BMI270判断点头/摇头）。

云端负责自然语言对话和长上下文理解。眼镜端录音到云端，返回文本后通过TTS播报并同时在MicroOLED上显示卡片。

这个架构的问题很快暴露出来：网络依赖和链路延迟。本地唤醒、云端识别、返回渲染的超时设置我最初给了5秒，但实际环境下经常跑到8-10秒。用户说完一句话，等了快十秒眼镜才回复，这在真实对话里完全不可接受。

第160天我专门优化了一轮：把语音流改为流式上传，一边说话一边传数据包，大模型返回也用流式拼接，实现"边说边出字"。最终把端到端延迟压到约2.8秒（网络条件好的Wi-Fi下）。但一到户外用4G/5G网络，延迟又开始飘。

3.3 双麦克风阵列：我以为的降噪和实际的降噪

双麦阵列是我比较自信的部分。两个麦克风间距3cm，用延迟差做波束成形，理论上能增强前方人声60%的响度，同时抑制侧面噪声。

真实场景打击了我。第一次在地铁站实测，语音识别准确率从安静的92%掉到54%。环境里有广播报站、车轮轰鸣、人群交谈，波束成形算法在相干噪声（也就是从四面八方来的噪声）面前几乎失效。

我加了AI降噪后处理，在RK3588的NPU上跑一个轻量降噪模型，效果有改善，准确率回到71%。但延时多烧了120ms，这对本来就紧张的链路雪上加霜。后面我学乖了：把降噪模型换成RNN结构、降低模型参数，延时压回到60ms左右，才勉强平衡。

这段经历让我深刻理解一句话：麦克风数量堆不出一流的降噪，算法模型才是关键。

3.4 手势识别：实验室95%准确率，到了太阳底下现原形

手势模块我采用YOLO风格手部检测+关键点模型，在RK3588 NPU上推理。实验室测试集准确率95%，我一度把它当成核心交互方式。

第一次户外测试就翻车了。下午两点的强光下，OV9281全局快门摄像头在逆光场景里把手的轮廓和环境背景融在一起，检测框频繁抖动。更尴尬的是，用户走路时手部偏转角度稍微大一点，关键点就会飞。我统计的真实环境准确率只有78%左右，而且是把"偶尔识别不出来"都算作成功的情况下。

后来我想通了：手势识别适合"固定终端+受控环境"（比如车机、智能家居面板），不适合在移动场景里当主动交互。用户戴眼镜时手在忙，手势不可能一直伸在摄像头视野里。正确的交互应该是"低头一看、头动选择、语音确认"的渐进式链路，而不是空手比划。这个认知，直接导致我后面决定砍掉手势模块。

4. 从"能亮"到"能戴出门"：结构件改了十一版

硬件能跑通只是第一步，对我来说更折磨的是让这套东西看起来"不是实验室产物"。当初选Birdbath的时候我就知道，结构这关不会好过。

4.1 结构迭代：重心、配重和镜腿里的线缆

Birdbath光机的体积决定了一件事：眼镜右前方必须突出一个光机模组，重量集中在前部。第一版结构件做出来，整机前重后轻，戴上低头，眼镜直接往下滑。我甚至试过在左镜腿尾部塞配重铁块，结果顺利把整机重量拉到了112g——戴十分钟就压得鼻梁疼。

从第150天到第195天，我前后改了十一版结构件。每一次的重点都是：把主控核心板从镜腿中段挪开，把重量重新分配，让镜框主梁受力而不是鼻托吊着。最终把整机重量压到79g，重心落在镜框中心偏后两毫米。没有专业工业设计背景，纯靠手感和不断测试调整。

这个过程中最耗时间的不是3D打印本身，而是重新规划内部走线。摄像头、屏幕、麦克风、骨传导喇叭、IMU、电池，六组线束要在一根直径6mm的镜腿里井井有条地穿过，还不能被转动关节挤压。我换了三版线束方案，最后是定制FPC软排线才解决。

4.2 户外测试：显示器的敌人是太阳

第206天，我做了第一次完整户外路测。时间是下午两点，阳光直射。

Birdbath光学方案的透过率大约只有18%-25%，等于说外界阳光经过镜片衰减后，人眼看到的世界偏暗；而MicroOLED屏的峰值亮度通常标称1000-3000nit，但经过Birdbath光路多次折反射到达人眼，实际感知亮度再打折扣。两相叠加，白天室外看到的显示内容非常模糊。

我把亮度调到最高，勉强能看到白色文字，但彩色地图完全不可用。到了树荫下，效果好不少，可一旦走出阴影立刻"隐形"。这意味着我最初定义的导航、AR信息叠加这些主打场景，在白天根本没法用。

我后来加了环境光传感器做自动增益，但物理上限摆在那里。光波导方案透过率能做到80%以上，显示内容叠加在真实世界上依然清晰，这才是户外场景的唯一解。但那需要资金和时间，个人项目做不到。

4.3 从5个核心功能砍到3个：提词器成了救命稻草

第180天左右，我面临一个选择：整机功耗超标、发热失控、UI交互来不及打磨，5个核心功能（AI问答、翻译、导航、提词、通知）只能重点保3个。

我做了两轮用户测试（拉了几个朋友试用）。观察下来发现一个规律：试用者玩得最多的功能是AI对话和翻译，因为新鲜；但真正让他们"愿意戴第二天的"功能，却是提词器。

原因很现实：提词器是纯文本显示，不需要高亮度、不需要实时网络、不需要AI推理，功耗低，显示效果最好，而且对经常录视频、做演讲的人有明确价值。而翻译和导航在户外显示效果不佳，刚需场景没打透。

最终我把资源集中到：AI对话、提词器、通知流转。翻译和导航降级为"实验功能"，只在连接手机时需要。

这个砍功能的过程教会我一件事：当你不确定什么是用户真正需要的，就去看哪个功能在真实环境里最不容易出问题。能够稳定工作的功能，远远比"很酷但总出错"的功能有价值。

5. 做完那天的完整测试：七个让我沉默的问题

第208天下午，我把整机充满电，去户外做了最后一次全场景路测。整个流程走下来，我在笔记本上列了七个问题，这个问题清单直接促使我按下暂停键。

5.1 亮度不够：核心卖点在最需要它的场景里失效

户外导航是AIR眼镜最核心的卖点之一，但前面提到，Birdbath光路的物理透过率太低。我站在正午的路口，眼前的导航箭头几乎溶解在阳光里。我把测试数据记下来：阴影环境可见度70%，直射阳光下降至35%。

这不是调参能解决的，除非把MicroOLED亮度再翻三倍——但亮度越高功耗越大，电池扛不住；或者换光波导——但成本直接涨二十倍。

5.2 发热：太阳穴位置在第34分钟开始抗议

整机连续使用34分钟后，我明显感觉右眼镜腿与太阳穴接触的位置发烫。拿红外测温枪打了一下，接触面40.5℃。我知道很多硬件产品的国标要求是表面温度不超过44℃，40.5℃甚至算"合规"，但用户体感不会听你解释合规标准——就是不舒服。

发热的来源很集中：RK3588在AI对话场景下高频运行，加上MicroOLED驱动板紧挨着镜腿外壳。我试过把主控搬到眼镜前框，虽然远离太阳穴，但额头接触区域开始发热，同样不可接受。

5.3 续航与充电：82分钟续航在"全天佩戴"面前是个冷笑话

整机续航实测82分钟，充电时间却要2.5小时。用户早起戴上，到公司路上用完电量，剩下的时间它只是一块挂在脸上的死重量。

更尴尬的是充电方式：因为我做的是工程原型，用了磁吸触点充电，放在桌上看起来还行。没有考虑过换电，也没有考虑过"备用电池盒"这种思路。在眼镜这个形态里，续航问题的答案可能不是把电池做大，而是把功耗做低 + 把非核心功能交给手机。

5.4 AI对话链路延迟：2.8秒的等待会打断任何自然交流

端到端延迟2.8秒是我优化后的最好成绩，但这是Wi-Fi环境。换成手机热点后，实测平均延迟4.6秒。用户问一个问题，盯着眼镜等将近5秒才有反应，这种感觉非常消耗耐心。

我复盘了链路：音频采集（无延迟）→噪声抑制60ms→本地端点检测260ms→流式上传→云端排队与大模型生成→流式返回→TTS200ms→显示渲染60ms。优化的空间都在云端，但那是不可控的；可控的本地部分已经压到了极限。

5.5 手势识别：热闹场景里的误触发比沉默更尴尬

户外测试走到步行街，人多、背景复杂。手势识别模块在那样的场景里几乎免疫了"等待手势"逻辑，连续误触发了三次AI对话、两次拍照（我还有拍照功能）。我当场关掉了手势识别。

实验室里95%的准确率，到了真实场景就变得不可靠。而交互设备一旦"不可靠"，用户就宁愿不用。

5.6 重心与鼻梁压力：79g也有79g的痛

整机79g，比第一版的112g轻了不少，但长时间佩戴（超过1小时），鼻梁和耳廓还是会疼。普通眼镜用户对重量的感知阈值很低，60g是分水岭。我的V0.9还是超过了。

结构上可以再做轻，但代价是电池容量更小、续航更短，这是一个死结。唯一的出路还是换光波导从而去掉Birdbath的大外壳，或者干脆不做显示——只做AI音频眼镜。

5.7 最关键的沉默问题：没有一个场景让我说出"我会天天戴"

七个问题里，最让我沉默的是最后一条。技术问题都有办法缓，但产品定义问题想不出来。

我翻了一遍产品简介：AI助手、翻译、提词器、导航、通知。听起来功能丰富，但我问自己："我作为一个开发者，今天出门会戴上它吗？"答案是犹豫。

我得承认，AIR眼镜V0.9是一个"为了做出来而做出来"的产品。它证明了我能解决一长串硬件和软件难题，但所有这些能力没有指向一个清晰的日常场景。用户为什么在办公室、逛街、通勤时戴一个79g的眼镜？我答不上来。

6. 重新想一遍：技术其实不是最大的障碍

第208天晚上，我把所有结论摆在一张白纸上。想来想去，我最终确定了一个判断：V0.9的完成说明技术路线是可行的，但产品定义的起点错了。我一直在思考"能做到什么"，而不是"值得做什么"。

6.1 三个核心结论

重新梳理一整天的反思后，我总结出三条：

第一，显示和AI是两件事，不应该强行绑定在一代产品里。显示目前受光学方案限制，户外体验不达标；但AI音频能力已经基本成熟，完全可以独立成产品。

第二，计算应该分层，而不是全塞在眼镜里。眼镜形态最宝贵的是轻量、佩戴舒适、续航；重计算交给手机或口袋盒子，眼镜只做传感和呈现，才是符合物理规律的架构。

第三，交互链路要从"花哨"回归"稳重"。语音为主，头动辅助，微触控备用，砍掉手势识别。用户不会在公共场合对着空气比划。

6.2 新定义：AIR眼镜的下一步

我在第208天晚上重新写了一页需求文档，标题从"增强现实眼镜"改成"AI随身助理眼镜"，定位也变了：

• 形态上：优先保证40-50g的重量，可长时间佩戴，视觉上接近普通眼镜。
• 交互上：放弃MicroOLED显示，或者只在镜片边缘保留一颗低功耗单色微显示，用于提示性信息（聊天气泡、通知圆点）。绝不再做大屏投射。
• 场景上：主打三个：全天候AI语音问答、实时翻译（只听不说，用耳机或骨传导输出）、演讲提词（需要显示时的专用模式）。
• 算力上：眼镜端用低功耗协处理器常驻（语音唤醒、IMU、BLE链接），ARM大核和NPU按需唤醒；云端大模型作为主力大脑，手机作为中继。

说白了，这个新方向更像"能听会说的AI耳机+一个极简眼镜形态"，先把"贴心助手"做透，再考虑AR显示。

6.3 架构上我会做的三处改动

如果现在重启项目，架构层面第一件事是换主控。RK3588性能强，但功耗线太高。我会选一颗低功耗智能穿戴SoC（比如恒玄、物奇那类），把AI模型做成端侧极小规模，只跑唤醒词和关键词识别，真正的AI对话放到手机App里完成。这样整机待机功耗可以从1.5W降到几十毫瓦，续航问题直接解决。

第二件事是重做音频系统。双麦阵列保留，但算法栈整体换成低功耗DSP实现，不去抢主CPU的资源。耳机式产品在音频链路方面有非常成熟的方案，学它，别自己造轮子。

第三件事是把云端链路写好。要有完善的断网缓存、流式音频上传、大模型 JSON 流式解析，还要有离线短语兜底——用户没网时至少能回复"网络不太稳，稍后再问我一次"。

三个改动背后的逻辑只有一条：别让硬件背负不属于它的任务。

6.4 给同样在折腾这方向的人的建议

折腾了208天，我觉得可以分享一些不那么教科书的东西：

• 先想清楚"谁在什么场景下会天天戴"，再动手画原理图。不要用"功能多所以有价值"骗自己。
• 个人做硬件项目，尽量采购成熟模组。我浪费过一个月在自研手势摄像头的驱动适配，后来发现社群有现成方案，悔得拍大腿。
• 每次做完一个决策，写下行数的理由。第208天复盘时，我翻自己第40天的决策日志，完全理解不了当初为什么执着于单目显示。如果没记下来，连反思都没素材。
• 把"差一点"的和"能用"的严格分开。我的V0.9和能戴出门之间隔着的不是差一点，而是一整套产品化工程。要有心理准备。

最后说一句个人体会：开发AIR眼镜的208天，我学到最多的不是RK3588、不是光学、不是洪泛式AI模型优化，而是学会了承认"我可以做出来，但不代表我应该做出来"。这个反思的过程，比产品本身值钱得多。