不会写代码的产品经理，用 workbuddy 搞了个 Three.js 3D 驾驶舱，迭代了 9 个版本

先说结论：能用，但没那么神。踩了不少坑，最后确实做出来了。

背景

我是做制造业数字化的产品经理，代码能力约等于零。日常写需求文档、做竞品分析、画架构图，前端的东西基本不碰。

最近有个需求：给客户做一个 3D 数字孪生驾驶舱的原型。要求大概是这样：

• 全厂设备的 3D 场景，能旋转缩放
• 点击设备弹出 KPI 看板
• 仓储区域要有玻璃架模型（A 字架、L 字架）
• 40 多个指标要可视化
• 能直接发给客户演示，不是 PPT 里画的饼

以前这种活，要么等前端排期（两周起步，还不一定排得上），要么外包（改一轮要三天，沟通成本巨大）。这次我试了个新路子：用 WorkBuddy，一个本地跑的 AI 编程助手，自己干。

下面记录一下整个过程。

第一版：先让它能跑

我跟 WorkBuddy 说了第一句话：

"帮我做一个工厂的 3D 数字孪生页面，用 Three.js，单 HTML 文件。场景里要有切割机、磨边机、钻孔机、清洗机、钢化炉，设备用不同颜色的方块表示就行，点击弹出参数面板。"

两分钟后，它给了我一个能跑的 HTML 文件。

说实话，很粗糙。设备就是几个彩色方块，地面一片灰色，灯光打得平平的。但关键是——它能跑。浏览器打开，鼠标拖拽能旋转视角，滚轮能缩放，点击方块能弹出一个半透明的信息面板。

这个「能跑」特别重要。因为从此刻开始，我不再是「写需求文档等排期」的状态，而是「看着一个能动的东西提意见」的状态。前者是空对空，后者是实打实的迭代。

接下来几轮：疯狂加需求

有了能跑的底子，我开始一轮一轮提。全程都是自然语言，不用写一行代码。

第二轮，改外观：

"设备太丑了，给切割机加个金属质感的材质，磨边机用深蓝色，钢化炉用橙红色表示高温。加个地面网格线，看起来有科技感。"

它直接改了材质和颜色，加了地面网格。效果立竿见影——从「能看」变成了「能见客户」。

第三轮，加 KPI 看板：

"加一个顶部的 KPI 看板区域，横跨整个页面宽度。放 6 个核心指标：今日产量、良率、设备稼动率、在制品数量、能耗、订单完成率。数字要大，一目了然。"

它在页面顶部加了一排卡片式面板，每个指标有图标、数值、单位、涨跌箭头。还用了 CSS 动画做数字滚动效果，看着挺像那么回事。

第四轮，这是个大活：

"KPI 数字要能点击，点击后弹出详情弹窗。比如点良率，弹窗里要显示各条产线的良率明细、最近 7 天趋势、异常产线标红。48 个指标都要有对应的弹窗内容。"

48 个指标，每个都要有独立的弹窗逻辑和数据。它建了一个 kpiDetailMap 对象，把 48 个指标的弹窗内容全塞进去：

const kpiDetailMap = {
  yieldRate: {
    title: '良率详情',
    trend: [96.2, 95.8, 97.1, 96.5, 95.3, 96.8, 97.2],
    lines: [
      { name: '切割线A', value: 97.5, status: 'normal' },
      { name: '磨边线B', value: 94.1, status: 'warning' },
    ]
  },
  // ... 48个指标
};

设备参数也做了一个 paramDetailMap，25 个参数（主轴转速、进给速度、温度、压力等）都能点。

这里有个小插曲：48 个指标的弹窗内容，我本来想自己一个个写。后来发现 WorkBuddy 可以按模板批量生成，我只需要审核修正。比如它给「良率」生成的弹窗里，趋势数据是 [96.2, 95.8, 97.1, ...]，产线明细有切割线A、磨边线B这些。数据是假的，但结构是对的。我只需要把真实数据换进去就行。

第五轮，加全屏：

"加个全屏按钮，在右上角。客户演示的时候全屏效果好。"

Fullscreen API，几行代码的事，但演示效果提升很大。客户看的时候全屏一开，沉浸感完全不一样。

第六轮，设备动画：

"设备要有状态动画。正常运行的设备加个缓慢旋转的效果，报警的设备加红色闪烁，停机的设备变灰。"

它给每个设备加了动画回调。正常设备绕 Y 轴缓慢旋转，报警设备的材质颜色在红色和原始色之间插值闪烁，停机设备降低透明度。

第七轮，模拟实时数据：

"KPI 数据现在是写死的，加个模拟数据刷新。每 3 秒随机波动一下数值，看起来像实时数据。"

加了定时器，数值在基准值上下随机浮动，涨跌箭头也跟着变。客户演示的时候数字一直在跳，看着挺唬人的。当然，实际对接的时候这些模拟数据要换成真实 API 调用，但原型阶段够用了。

到这里，一个页面已经 1166 行、65KB 了。

你可能会问：一个 HTML 文件搞这么大，不觉得该拆组件了吗？

我的想法是，原型验证阶段，单文件就是最方便的。一个文件，微信发给客户就能打开，不用 npm install，不用起服务，不用跟客户解释「你先装个 Node.js」。等验证完了要产品化，再让前端来重构。到时候这 1166 行就是需求文档——比任何 PRD 都直观。

第八版：用工厂实拍照片改模型

前面几版的仓储区域，A 字架和 L 字架都是 WorkBuddy 自己「想象」的——蓝色架子，整齐排列，看着像那么回事，但跟我们实际的完全不一样。

我发给工厂的同事看，人家直接说：

"这不对。我们的 A 字架是白色烤漆的，A 字造型，底下有 4 个红色万向轮。玻璃是竖着插在横梁之间的，不是平放的。"

光靠文字说不清楚。我直接拍了两张工厂实拍照片发过去：一张 A 字架侧面照，一张 L 字架正面照。

它真的看了照片。从照片里提取了白色漆面、A 字造型、5 根横梁、4 个红色万向轮这些信息，然后用 Three.js 重建了模型。每一根横梁、每一个轮子都是独立的对象，有正确的尺寸和颜色。

但第一次改完有新问题。

打开页面一看——玻璃「漂浮」在架子上方，跟架子之间有一道明显的缝隙。像是被放在了一个隐形的托盘上。

我截图，用红圈标出漂浮的位置，发给它：

"玻璃飘起来了，没有贴合横梁。玻璃底部应该跟最下面那根横梁齐平。"

它改了 Y 轴偏移量。第二次打开，玻璃不飘了，但方向反了——本来应该面向通道的架子，转了 180 度面朝墙壁。

"架子方向反了，玻璃面应该朝向工厂通道方向。"

改了旋转角度。第三次，方向对了，但玻璃的间距太密，看着像一整块。

"每片玻璃之间要有间距，就像实际插在架子里那样，能看到每片独立的玻璃。"

第四次，终于对了。白色 A 字架，红色万向轮，玻璃一片一片竖着插在横梁间，间距均匀。

这个过程来回四五轮，花了大概半小时。

回头看这半小时，投入产出比其实挺高的。如果让前端来做这个模型，光理解「A 字架长什么样」就得花半天——你还得给他看照片、解释结构、确认尺寸。而 WorkBuddy 直接看照片就能提取结构信息，我只需要在「不对」的时候指出来。

这段经历让我想明白一件事：AI 给你的不是一次性完美结果，而是一个可以反复磨合的搭档。你要做的就是知道哪里不对、怎么描述不对、期望改成什么样。

第九版：翻车了

受前面成功的鼓舞，我决定搞个大的：给五大工艺设备各做一个独立的数字孪生页面，每个页面有设备 3D 模型、实时参数面板、历史趋势图。

满怀期待地打开第一个——切割机的页面。

白屏。

刷新，还是白屏。打开第二个，磨边机的——有东西了，但渲染到一半就卡住了，控制台一堆 WebGL 警告。

排查了好几轮，最后搞清楚了几个原因：

1. 浏览器的 WebGL 上下文数量有上限，同时开 5 个复杂 3D 页面会超限
2. Three.js 的 dispose() 没调用，内存泄漏导致渲染崩溃
3. 不同页面加载了不同版本的 Three.js，互相冲突

最后的解决方案：不同时打开 5 个页面，改成一个导航页面点进去看单个设备，退出时释放资源。

教训就是：3D 场景不要贪多。一次渲染一个，用完就释放，比同时塞 5 个场景靠谱得多。

踩过的其他坑

除了上面翻车那次，还踩了几个坑，一并记录一下。

任务卡住不动。 有一次，一个任务状态一直显示 pending，等了 10 分钟还是 pending。排查后发现是 WorkBuddy 的内部数据库（SQLite）里，这条任务的状态字段卡住了。可能是上一次运行中途崩溃，状态没来得及更新。

解决方案：直接用 SQL 改状态，然后重启应用。

UPDATE tasks SET status = 'completed'
WHERE name = 'xxx' AND status = 'pending';

数据库路径在 ~/.workbuddy/workbuddy.db。

macOS 权限弹窗。 macOS 的隐私权限有时候会反复弹窗要求授权。即使已经在系统设置里授权过了，下次启动还是弹。

tccutil reset Accessibility com.tencent.workbuddy

重置后重新授权就好了。这个问题在 macOS Sonoma 上比较常见，不全是 WorkBuddy 的锅。

AI 没有「物理直觉」。 Three.js 生成的 3D 模型，经常会有物理上不合理的问题：物体漂浮在空中、方向反了、穿模。AI 没有「东西应该放在地面上」这种直觉，你得自己看，发现问题后精确描述给它。

一个技巧：截图标注比文字描述有效 10 倍。我会在截图上用红圈标出问题区域，然后说「这个位置的玻璃飘起来了，应该贴合架子顶部横梁」。比写一大段文字管用得多。

国内模型的兼容性。 我用 Hermes 做本地 AI 网关，接入了几个国内模型（小米 MiMo、智谱 GLM、百度千帆）。这些模型的 API 返回格式跟 OpenAI 不完全兼容——比如有些模型会多一个 reasoning_content 字段，存的是模型的思考过程。如果客户端没处理这个字段，要么报错，要么把思考过程当成回答吐出来。这个坑踩了才知道，先小规模测试比较稳妥。

最后的成果

迭代到 V4.9.x，这个单 HTML 文件已经有了：

• 全厂 3D 场景（设备 + 地面 + 通道 + 仓储区）
• 48 个 KPI 看板（可点击弹详情）
• 25 个设备参数（可点击查看实时数据）
• 基于工厂实拍还原的 A 字架 / L 字架模型
• 全屏模式、设备状态动画、模拟数据刷新
• 五大工艺设备独立数字孪生页面

几点感受

先跑通再优化。 别追求第一次就完美。先让 AI 生成一个能跑的版本，然后在这个基础上迭代。我那个驾驶舱第一版就是一堆彩色方块，但它能跑，这就是一切的起点。

你是产品经理，不是程序员。 你的价值是知道「要什么」和「对不对」，不是知道「怎么写」。把精力放在需求描述和质量审核上，让 AI 去写代码。你不需要会 Three.js，但你需要知道 A 字架长什么样、KPI 看板该放哪些指标。

真实素材比 Prompt 管用。 给 AI 看工厂实拍照片，比写 500 字的描述都管用。它能从照片里提取颜色、比例、结构这些你很难用文字精确表达的信息。能拍照就别写字。

审核不能跳过。 AI 的产出不能直接用。它会犯低级错误（坐标算错、方向搞反），会遗漏关键信息，会把不确定的东西写得很肯定。你的工作是审核、修正、补充。审核比从零写快 10 倍，但不能省。

单 HTML 文件是原型阶段的最优解。 不用装依赖、不用起服务、微信直接发。1166 行看着大，但客户点开就能用。等要产品化了，这 1166 行就是最好的需求文档。

WorkBuddy 解决不了行业认知问题，解决不了数据源问题，解决不了客户关系问题。这些还是得靠自己。

但它解决了一个问题：让不懂前端的人也能快速做出可交互的原型。以前从「想法」到「可演示原型」这个环节，需要等前端排期两周。现在我自己就能搞。不是替代前端，而是把原型验证的效率提上去了。

对产品经理来说，这个价值是实实在在的。

一个制造业数字化的产品经理，日常折腾 ERP 架构、3D 数字孪生、AI 落地应用。欢迎交流。