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

一个制造业数字化的产品经理，代码能力几乎为零，日常就是写写需求文档、做做竞品分析、画画架构图，前端的东西基本不碰。但最近有个需求：给客户做一个3D数字孪生驾驶舱的原型。要求大致是这样：全厂设备的3D场景，能旋转、缩放，点击设备能弹出KPI看板；仓储区域要有玻璃架模型（A字架、L字架）；40多个指标要可视化；而且得直接能发给客户演示，不是PPT里画的饼。

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

第一版：先让它能跑

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

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

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

接下来几轮：疯狂加需求

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

第二轮，改外观：“设备太丑了，给切割机加个金属质感的材质，磨边机用深蓝色，钢化炉用橙红色表示高温。加个地面网格线，看起来有科技感。”它直接改了材质和颜色，加了地面网格，效果立竿见影——从“能看”变成了“能见客户”。

第三轮，加KPI看板：“加一个顶部的KPI看板区域，横跨整个页面宽度。放6个核心指标：今日产量、良率、设备稼动率、在制品数量、能耗、订单完成率。数字要大，一目了然。”它在页面顶部加了一排卡片式面板，每个指标有图标、数值、单位、涨跌箭头，还用了CSS动画做数字滚动效果，看着挺像那么回事。

第四轮，是个大活：“KPI数字要能点击，点击后弹出详情弹窗。比如点良率，弹窗里要显示各条产线的良率明细、最近7天趋势、异常产线标红。48个指标都要有对应的弹窗内容。”它建了一个kpiDetailMap对象，把48个指标的弹窗内容全塞进去：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' }] }，设备参数也做了一个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警告。

排查了好几轮，最后搞清楚了几个原因：浏览器的WebGL上下文数量有上限，同时开5个复杂3D页面会超限；Three.js的dispose()没调用，内存泄漏导致渲染崩溃；不同页面加载了不同版本的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上比较常见。

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落地应用。