企业官网建设流程全解析

2013年前后，那家搜索巨头内部实验过一款名叫 Antigravity 的浏览器产品，流程简单得离谱：你输入“解魔方机器人”这类需求，屏幕上出现的不再是一排蓝色链接，而是一块能拖拽、能改动、看起来随时可以拿去干活的项目画布。用 Antigravity 造解魔方机器人，在当年听起来像魔术，但放到今天拆解，其实就是把一台机器最麻烦的感知、决策、执行三层工作，用对话的方式一次性铺在你面前。这篇文章，我打算沿着这个思路写一遍真正落地的过程，顺带把几处容易翻车的细节摊开聊。

1. 当年那场“搜索即拼装”的Demo，为什么偏偏拿魔方当开场

先看背景。Antigravity 并不是一个开放下载的产品，而是一次交互形态的探索：它想证明搜索结果的终点不一定是一篇网页，而可以是“一块可编辑的应用画布”。有人对着搜索框敲了一句话，画布上会流式浮出项目标题、参数选项、代码片段、图片素材，甚至一个可拖拽的装配示意。我现在回忆起来，它其实比后来很多生成式 AI 界面早了差不多十年，只不过当时没有大模型这种底座，画布上的“生成”更多是模板组合与结构化数据。

那场演示里最常被提到的案例，正是“make a rubik's cube solving robot”。为什么偏偏是魔方？因为魔方是一个完美的综合实验载体：

• 它有绝对的标准性，六个面、九宫格，状态可枚举，方便程序描述。
• 它有颜色识别问题，摄像头怎么在复杂环境下分清红橙、白黄。
• 它有路径规划问题，给定当前状态后如何算出一组可执行动作。
• 它有执行控制问题，机械结构怎么把算法输出变成真实的旋转。

换句话说，一台解魔方机器人浓缩了机器人领域中视觉、算法、运动控制三个核心模块，但硬件体量又小到一张桌面就能放下。对任何演示来说，这都比“让机械臂抓个杯子”更有记忆点，也比“做个网页查询天气”更有工程冲击力。Antigravity 选它当样例，本质上不是想解决魔方，而是想告诉观众：以后你只要会说需求，搜索就能帮你把整台机器的“初稿”拼出来。

不过，演示动画再漂亮，落到真机上是另一码事。我照着 Antigravity 的思路，把“搜索即拼装”翻译成今天大家更熟悉的做法——用一轮清晰的需求描述，让 AI 先生成项目骨架，再逐步迭代。这个流程对做机器人特别实用：它逼着你在动手前把感知、决策、执行三层想清楚，而不是先买一堆舵机再说。

2. 一台解魔方机器人，拆开其实是感知、决策、执行三块板子

想用任何工具造这台机器，第一步都是把黑箱拆成白箱。魔方机器人从功能上分，永远跳不出三块：知道魔方什么样、算出怎么转、执行转动。每块都有独立的选型空间，但只有把它们拼起来，才算完整系统。

2.1 感知层：怎么把“魔方长什么样”变成程序能读的数据

大部分人第一反应是“给六面各拍一张照，然后数颜色”。逻辑没错，落地全是细节。

我见过比较稳的做法是用一个固定机位的 USB 摄像头，从魔方正上方拍当前面，然后靠一个小型机械结构把魔方翻面或旋转，依次采集六个面。拍照后首先要做透视矫正，否则边界拍歪了，色块中心的取样点会偏进相邻色块里。比较省事的方法是让魔方放在一块印有标记点（比如四个角上的黑色圆点）的底板里，程序先识别这四点，算出透视矩阵，再映射到 9 个色块中心做采样。

颜色采样本身不能用整片面积平均。因为魔方贴纸边缘在转动中会有倒角，玩具魔方的颜色在边角处往往溢出。可靠的做法是取每个色块中心半径约 4~5 像素的圆形小斑块，用这个小区域的平均色作为该色块的颜色，能大幅减少污染。然后别直接用 RGB 判断，环境光一变，RGB 三个通道同时偏移，阈值很难写。更稳的方案是转成 HSV 空间，按色相为主体，饱和度和明度做辅助过滤。

这里有一个非常容易被 AI 或者教程忽视的点：白平衡。如果整个图像的色温偏冷，黄和白几乎分不开，黄绿也容易混淆。我在做的过程中会先加一个简单的校准环节：先放一张标准白色纸片，拍一张图计算三通道偏移量，之后每帧图像都做一次减法补偿。这一步半小时能省下来后面调软件两三天的崩溃。

2.2 决策层：Kociemba 算法为什么是主流的“标准答案”

感知层输出的是一个长度为 54 的字符串，代表六面九宫格的颜色排列。决策层要做的，是根据这个字符串算出一组还原动作。

如果只是随便用搜索算法硬试，状态空间太大了，个人电脑也跑不动。业界常用的开源实现是 Kociemba 两阶段算法。它思路非常巧妙：第一阶段先通过较少的转动把魔方带到一个“软目标”子空间，这个子空间里所有角块方向、棱块方向都是正确的，并且中层棱块位置也大体对；第二阶段再在这个受限空间里求解精确还原。这样分两步走，把搜索剪枝做得极其干净，普通家用电脑上平均求解在 20 步左右，一些实现甚至能跑到十几步。

在项目里我一般直接用 Python 的kociemba这个库，示例代码非常短：

import kociemba # facelets 按 U R F D L B 六个面的顺序，每面 9 个字符拼接 facelets = "UUUUUUUUURRRRRRRRRFFFFFFFFFDDDDDDDDDLLLLLLLLLBBBBBBBBB" solution = kociemba.solve(facelets) print(solution)

这段代码本身没有技术难点，真正的坑在于facelets的顺序。不同库对六个面的排列顺序约定不同，一旦你拼接时按“上、下、前、后、左、右”这种人体直觉顺序喂进去，解出来的动作就完全对不上物理转面。我自己会在代码里单独写一个备注常量，把 54 个字符逐面打印出来，用真实魔方对照一次，确认无误再合并整机。

2.3 执行层：先想清楚三个自由度，还是要多自由度机械臂

执行层是整台机器里争论最多的地方，因为同一个解算结果可以有好几种物理表达。

第一种是“机械臂夹着魔方转”。类似工业臂形态，舵机多，姿态复杂，视觉上很有演示效果，但结构刚性和舵机精度要求都高，而且很容易因为手臂回程误差让魔方松动。

第二种是“旋转工作台 + 顶部夹持器”。魔方固定在中央平台，平台可以水平旋转，顶部有一个可下压的夹持器压住某一层，底部或侧边的驱动头完成该层旋转。这种方案有点像高速解魔方机器人，效率高，但实现时对摩擦力的依赖很重。

第三种是“固定平台 + 单面执行器”。摄像头识别完所有面之后，把魔方放到一个只能转某一固定面（比如顶面）的执行器下，执行器由舵机驱动，每次只转顶层。需要换面时，再用一个简易翻面机构把魔方换个朝向。

我自己最推荐刚开始做的人先做第三种，理由非常朴素：它把机械不确定性降到最低。一套舵机、一个亚克力支架、一台上位机，就能完整跑通算法链，等整体流程调顺了再升级成旋转式。

3. 我按 Antigravity 的思路对话式搭原型：提示词、画布修改与导出

Antigravity 那个年代没有大模型，今天我们有，那套“对话式搭项目”的体验就变成了非常实用的工作流。我复刻的时候，把自己当成画布的使用者，从一句完整的需求描述开始。

3.1 第一轮提示词：别再说“帮我做个魔方机器人”这种空话

如果你只抛一句“写一个解魔方机器人”，AI 大概率会回一堆开放式的科普内容。真正有效的第一轮描述，应该把感知、决策、执行三块都点名，并且给出你的硬件边界。我实际用的提示词大概是这样的：

我想用树莓派加普通 USB 摄像头做一个解魔方机器人。摄像头从上往下拍摄魔方一面，旁边有舵机驱动的简易翻面结构。请给出硬件选型和接线图，视觉部分用 OpenCV 识别六面颜色，求解用 kociemba 库，执行部分用舵机控制，代码结构分成 camera_capture、color_detect、cube_solve、servo_execute 四个模块。请输出 Python 代码、Arduino 固件和 BOM 表。

这样一轮提示词下来，AI 会先把模块边界画清楚，而不是糊成一团。你后面改任何一块，都不会牵动全部代码。

如果 Antigravity 画布完整可用，它会把上述输出变成一组可拖拽模块：左侧是一堆零件卡片，右侧是实时生成的代码和接线图。你可以把“舵机驱动”那张卡片从一个引脚拖到另一个引脚，画布上的示意图和代码同步更新。现实中我们的替代品就是“下一轮追问”，但骨架思路一致。

3.2 在画布上做“第二版修改”：换执行结构，不换算法

Antigravity 这类交互的核心价值是“增量修改”。我生成的第一个版本默认输出的是机械臂方案，但我不想用六轴机械臂，于是追加了一轮修改：

请把机械臂方案改成固定平台加单面执行器：摄像头固定，魔方放在平台上，执行器只能旋转顶面，侧面加一个翻面机构。视觉模块不变，求解模块不变，只改执行模块的 Arduino 代码和机械结构说明。

这轮修改的意义在于：视觉和算法两个模块立刻被冻结了，只有执行层在变，排查问题的范围会变得很小。工程里最怕的是所有模块同时改，出了问题根本定位不到是颜色识别错了，还是转面机构动了。

3.3 导出后的本地化：你拿到的只是“接近可运行”的初稿

AI 生成的东西再好，也不能原样烧进板子。我导出代码后，至少要做三件本地化的事情。

第一件，改摄像头。AI 默认写的cv2.VideoCapture(0)在你的环境里可能索引不对，也可能分辨率太高帧率太低。我会先单独跑一个只拍照的程序，按下按键存一张图，确认采集流程正常，再往下走。

第二件，改引脚。AI 生成的 Arduino 代码里舵机接的是 9、10、11，你手头板子可能引脚冲突，或者舵机驱动板需要指定通道。不要盲目信引脚，拿万用表打一遍。

第三件，确认库版本。kociemba在 Python 3 下的接口比较稳定，但 OpenCV 的findContours返回值版本间会有变化，如果 AI 给的代码用了高版本 API，而你装的是老版本，就会报元组解包错误。我一般会新建一个虚拟环境，把 AI 提示里写到的版本号统一装好再跑。

这一步做完，整台机器其实已经能启动，只是大概率转几步就卡住。接下来才是真正磨人的调参阶段。

3.4 硬件搭建与串口联调：先代码后机构，先单步后连续

联调顺序也有讲究。不要一上来就整机跑。我先写一个“只识别不转动”的程序，让摄像头依次拍六面，程序打印每面的颜色矩阵。确认识别准确率，尤其是黄白、红橙这两对“近亲”颜色，能分清楚了，再做转动测试。

转动测试也别直接喂完整解法。我写了一个小工具，让上位机发送单步指令，比如只转 U 面 90 度，Arduino 收到后转动并回报“OK”。等单步能转对，再发一个R U R' U'公式，观察多次转动后魔方朝向是否漂移。这一步能暴露出大问题：机构抓力不足、舵机丢步、旋转后魔方位置偏移。

等到单步和短序列都稳定了，才把完整求解器接进主循环。整个过程像搭积木，但每一步都有明确的验证标准。

4. 把生成方案搬到真实硬件后，最容易被忽略的四个坑

硬件项目做到最后，难点永远在物理世界。下面这几个坑是我反复踩过，而且发现 AI 生成的方案普遍不爱提的。

4.1 光线一换，颜色识别立刻“眼瞎”

我刚开始把摄像头架在窗边，上午识别没问题，下午太阳一斜就疯狂把橙色认成红色。后来加了环形 LED 照明，并且用一张白色校准卡先做白平衡，情况立刻稳定。强烈建议把执行机构的周围做成半封闭遮光罩，或者至少让灯光角度固定，不给环境光留表演空间。

判断颜色阈值时，不要直接用 AI 给的固定 HSV 区间。每人手里的魔方、摄像头、屏幕都不一样。正确做法是写一个 20 行的校准程序，对六种颜色各拍三张图，把实际 HSV 范围自动存成一个 JSON 文件，主程序启动时读取。这个东西十分钟就能写，却能让识别模块耐用很多。

4.2 舵机一多，电源先垮

用普通舵机的人常常忽略电流。单个舵机在堵转时能拉到 1A 乃至更多，如果你让 Arduino 板的 5V 引脚直接带三四个舵机，一转动就会电压跌落，轻则舵机发抖，重则直接复位，整个流程中断。我的做法是单独配一个 5V 3A 以上的舵机电源，Arduino 只负责给信号线，地线统一接，电源线不经过开发板。这样随时拔舵机插头都不会把控制端搞挂。

4.3 抓力不足，魔方越转越歪

单面执行器看起来简单，但问题在于旋转顶层时，下面几层必须被牢牢固定。如果固定力不够，魔方会被“带着跑”，整体在平台上转掉一个角度，下一步操作就偏了。我的解决方式是在接触面贴上 2mm 厚的硅胶垫，增加摩擦力，同时做一个限位挡块，让魔方至少有两个固定边靠住平台上的直角挡板。

上电后舵机还有个“校准”问题。舵机本身不知道当前角度，每次开机都应该先让执行器回到一个机械限位点，以此为 0 度基准，再开始后续步骤。如果少了这步，第二次运行时可能所有动作都偏一个固定角度。

4.4 串口通信丢数据，尤其是连着转二十步的时候

Python 和 Arduino 之间我用简单的字符串协议，例如发送U1 R2 F3这样的指令行，每行以换行符结束。Arduino 逐行解析之后，转动完成必须回发一个OK，上位机收到后才发下一条。这个“应答”机制非常重要，否则串口缓冲区塞满，上位机还在猛写，就会出现转两步错一步的神奇现象。

另外，转动时魔方需要稳定时间。如果你刚发完指令立刻就发下一条，即使舵机转完了，整个底座可能还在轻微晃动。我会在每次转动之后加一个 50 到 100 毫秒的稳定等待，测试时根据实际震动微调，转速和稳定本来就是一对要现场取舍的冤家。

4.5 求解结果顺序别忘记校验

最后再说一次facelets顺序。Kociemba 库不是服务套件，它对颜色字符串的排列有要求，一旦物理摄像头采集顺序和它不一致，你会得到一条在逻辑上无比正确、但转起来完全混乱的解法。所以整机组装完后，我会先用手打乱魔方，然后把已知状态喂给求解器，对比它给出的解法前五步，再手动在魔方上验证一遍。这一步通过，才能证明从看到转的链路是通的。

5. 现在再看 Antigravity，它真正留下的不是产品而是工作方法

Antigravity 本身止步于演示阶段，但“用对话把复杂任务拆成可执行画布”的思路，如今已经被无数工具实现了。做机器人这件事尤其适合这种工作流，因为它的模块边界非常清晰，非常适合人机协作：视觉、求解、执行三块可以分别生成，再像拼装模型一样组合起来。

5.1 今天复刻一台机器，我最推荐的依赖组合

给你们一个不会迷路的配置组合：

• 上位机：普通电脑或树莓派。
• 相机：普通 USB 1080p 摄像头，别一开始就上工业相机，调试成本高。
• 视觉：OpenCV + HSV 校准 JSON。
• 求解：kociemba库。
• 控制板：Arduino Uno 或兼容板，负责舵机执行。
• 执行器：两到三路舵机，单面旋转加翻面即可。
• 电源：5V 3A 舵机独立电源。
• 结构：亚克力板或 3D 打印件，关键在于直角挡块和硅胶垫。

这套组合大概一个周末能搭出原型，成本不高，但足够让你理解机器人系统的全链路。

5.2 怎么评价 AI 生成的东西：当“详细计划”，别当“成品”

我在给 AI 提需求的时候，心态一直是“它正在给我生成一份包含图纸和代码的项目计划书”。计划书写得再细，也要由我来负责校准、焊接、调参、验证。所以每次运行失败，我都会先问自己是“它生成错了”还是“我执行错了”，而不是直接怪工具。这种分工其实特别健康：脏活累活自己来，重复脑力活交给模型。

如果后续要扩展，可以考虑给系统加一个“复位模式”：当识别结果明显异常时，摄像头重新校准白平衡，舵机重新回零位。这里用到我在几轮调试里留在代码里的状态机，主循环能优雅地退出当前流程，而不是死锁在那里。这个小扩展很值得做，能大幅提升机器人长时间展示的稳定性。

我在实际完成后复盘，最深的体会是：不用过分迷信任何单点工具，包括 Antigravity，也包括今天的大模型。真正让你把事情做成的，是把一个复杂目标拆成可以逐个验证的小单元，并且老老实实一个单元一个单元打通。魔方机器人就是一个特别好的练习场：你穷尽踩坑后会发现，每一次卡壳都对应某一个具体模块的边界条件，而这个模块一旦修好，整条链路就前进一大截。

最后想分享一个小技巧：如果你也打算做一台，请务必第一天就准备一本实验日志，把每次改动的阈值、现象、结论记下来。硬件调试最怕的不是问题多，而是同样的问题反复用不同的面目出现，日志能帮你识别那套躲在外壳下的老毛病。等你把识别、求解、执行三段全跑通，再回头看第一次开机时那一堆乱飞的颜色框，你大概会和我一样笑着摇头：原来 Antigravity 的魔力，从来不在那个演示画布上，而在画布背后那位愿意动手把初稿打磨成品的人。