#WorkBuddy# 交付人员也能做大屏前端了：我和 AI 协作一个月的四点真实心得

一、先说结论：AI 填上的是"最后一公里"的沟

我在一家做智慧建筑的公司做交付。我们交付的项目里有一类活儿特别磨人：给客户做可视化界面。

这活儿以前是前端开发和 UI 设计在做。但现实中总有三个错位：

• 最懂客户要什么的人，做不出来。 交付人员天天在客户现场，最清楚哪块数据要突出、哪个告警要抢眼，但不会写前端，界面改不动。
• 能做出来的人，不在现场。 找前端支援？大屏项目经常十几个并行，排期永远排在"后天"。
• 于是时间就在中间蒸发了。 现场发现要改 → 提需求 → 等排期 → 改完客户验收期已过。

我这两个月一直在用 WorkBuddy 磨这件事，到今天可以这样说一句：交付人员不必会写前端代码，也能独立完成大屏界面的开发和美化。

如果你也在用 AI 干活，尤其是做交付、做实施、做业务的，希望能少走点弯路。

二、心得一：别让它猜，给它"真的东西"

这是我踩的第一个、也是最大的一个坑。

最开始我是这么用的：把需求说清楚，然后让它"帮我做个停车场监控大屏"。结果它交出来的东西看着挺像那么回事，但粘进x系统里就报错。

试了两三次之后我想明白了问题在哪：我对它说的一切都是描述，它对我做的一切都是猜测。

平台有自己的格式规范，场景文件长什么样、图标文件长什么样、路径怎么写、图层怎么组织——这些细节我说不出来，它更猜不到。它只能按"百度上大概是这样"的通用认知去写，而通用认知在具体的商业引擎面前一文不值。

后来我改了做法，只做一件事：从引擎里把真实产物导出，喂给它。

• 导出一份真实跑通的场景文件 → 让它照着格式产出
• 导出一份官方的组件配置 → 让它照着这个能力封装
• 导出真实图标文件 → 让它照着规范画

效果是立竿见影的。从"反复报错"到"一次导入成功"，中间只差了"给它一份真东西"。

这条心得我后来用在了很多地方：让它写方案，先给它一份客户认可的旧方案；让它做表格，先给它一张我们内部在用的模板。AI 最强的是模仿能力和泛化能力，前提是你得先给它一个能模仿的对象。 你给的东西越真实、越具体、越接近最终形态，它的产出就越可用。

反过来说，如果你手上连一份真实的参照都没有，那这一行大概还不适合交给 AI——先把参照物拿到手，比反复描述需求有效一百倍。

AI设计一个交互界面

三、心得二：教它一次，要看它能不能"换个场景还会"

这是我觉得区分"会用它"和"不会用它"的关键。

我们那个大屏里有两个月度趋势图：一个是进场车辆数，一个是停车收益。我先让它做了进场车辆那个，做得不错。

到第二个的时候，我没有再描述一遍需求，只说了句："照刚才那个的模式，再做一个月度收益图。"

结果它不只是复制粘贴——它把配色、单位、数据系列类型、演示数据全部参数化了，抽成了可以复用的同一个模板，然后派生出了第二个图。也就是说：它理解了"月度趋势图"这个模式，而不只是抄了一个文件。

这个测试很重要。因为只能照抄的 AI，你每次都得从头教一遍；能理解模式的 AI，你教一次就能覆盖一类需求。

我现在自己的习惯是：凡是交给它的任务，做完第一遍之后，我都会多问一句"还能用在哪"。如果它能自己泛化，说明这个能力我以后可以放心复用；如果只能原样照搬，那我就得重新想想该怎么描述。

顺带说，这次也出现过我没预料到的情况——它主动纠正了我。

我凭印象告诉它"圆角用圆弧画"，它去查了官方手册，回来跟我说我记错了，正确的是另一套做法，然后按正确的重写了整个界面的圆角。如果它当时顺着我错的说法干，整个界面的圆角根本画不出来。

所以做 AI 协作，别把自己当成"绝对正确的甲方"。你手上有的是业务判断，它手上可能有一个更可靠的资料库。它反驳你的时候，先别急着压回去。

四、心得三：要求它自己验证，而不是"我觉得没问题"

这一条是我认为最有杠杆的一条，也是最容易被忽略的一条。

AI 有个特点：它交付的时候语气特别自信。 它说"已修复""已验证""没问题"，听起来都很笃定。但我踩过太多次坑——它说修好了，我一用还是错的。

后来我改了规矩：不要它说"我检查了"，要它拿出检查的证据。

具体是这么做的：让它修改完之后，自己写一段测试脚本真的跑起来，把输出结果贴出来给我看。不是复述代码逻辑，是贴运行结果。

这个要求一提出来，效果特别明显：

• 它真的会暴露自己前面没做对的地方，我见过好几次它自己跑完说"发现问题，重新修"
• 我拿到的不是"应该没问题"，而是"跑出来的实际结果是这样"
• 我判断它做得好不好的成本大幅下降——我不需要懂代码，我看输出就行

这里有个认知转变：我不需要能看懂它的代码，但我需要能看懂它的结论和证据。 就像我不懂装修，但我能验收——你告诉我这面墙是直的，我拿尺子量给我看。

这一条对不懂技术的使用者尤其重要。我们判断不了过程，但完全可以要求看到结果。 敢跑给人看的 AI，可信度比只会说"应该没问题"的高得多。

指引AI发现问题

五、心得四：把它当"翻译层"，不是当"打字员"

前三条都是方法，这一条是认知，也是我这两个月最大的收获。

一开始我把 AI 当"帮我干活的":我不想做的东西扔给它，它做完我拿走。这样用没错，但价值有限——省的是我的时间，产出还是原来的产出。

真正让我改变想法的是一个瞬间：当那个大屏界面从"一堆做不动的素材"变成"我能在引擎里改配色、调布局的成品"之后，我突然意识到——

我作为一个不懂前端的人，居然在独立完成前端的工作，而且在做美感判断。

AI 在这里的角色不是"帮我写代码的人"。它是翻译：

• 我这边说的是业务语言："这块要突出""这个告警要抢眼""客户不喜欢这个配色"
• 引擎那边认的是技术语言：场景结构、图元组织、样式参数、绑定机制
• 它站在中间，把我的话翻译成引擎听得懂的形态

想通这一点之后，我跟它协作的方式完全变了。我不再纠结"这个功能怎么实现"，我只说清楚"我要什么效果"，然后把工作交给翻译层。

对我们的交付团队来说，这件事的意义是很具体的：原来"我知道客户要什么，但我做不出来"这个死结被解开了一部分。 交付人员的能力边界，从"只能提需求"推进到了"能自己做出成品并调优"。省下的不只是开发排期，更是现场响应速度——客户说改，我当场就能改。

图标自动分好类

六、最后：几个我认为重要的用法习惯

除了上面四条心得，还有几个小习惯我觉得很有用：

先求跑通，再求好看。 不要一上来就追求完美成品。先做出一个"能被正确使用的、最粗糙的版本"，确认这条路走得通，再往上加细节。我这次第一步就是个很土的正方形加文字，但它验证了格式是对的。

给前后对比的样本。 我经常把"改之前"和"改之后"的两版文件都给它，让它看出差别在哪。这比我说十句"这里不太对"都有用。

让它说明它的犹豫。 我会问它"这里有没有不确定的地方"。它主动说出来的风险点，往往就是真正会出问题的地方。

保留你自己的判断权。 最终界面好不好看、客户会不会满意、这个方案能不能落地——这些是它给不了答案的，只能人来定。它给的是产能和可能性，决策得自己做。