用 P5.js 游戏逻辑思维搭建 AI 自动化工作流

你在 P5.js 里写的第一段“碰撞检测”，往往比你想的更有价值。因为它本质上不是“让方块碰到方块变色”，而是在训练一种能力：把现实世界的模糊事件，拆成可执行的条件与动作。

这也是小团队做自动化最缺的部分。很多所谓“上 AI”“做自动化工作流”，最后变成一堆零散的工具订阅：表单、机器人、自动回复、CRM、看板……但没有清晰的触发条件、状态流转和计分机制，系统就只能制造更多噪音。

本文是「人工智能在游戏与数字娱乐」系列的一篇：我们借用 P5.js 的游戏逻辑（碰撞检测、实体管理、计分与状态机），把它翻译成AI 语音助手与自动化工作流的设计方法。你会发现，游戏机制和业务自动化其实是同一门手艺。

碰撞检测：把“触发条件”写清楚，自动化才会可靠

碰撞检测的核心很朴素：判断两个对象的空间范围是否重叠。放到工作流里，它对应的是触发器（Trigger）：当某个事件满足条件，就启动动作。

在 P5.js 的方块碰撞里，你会写四个条件：

• x 是否在左边界右侧
• x 是否在右边界左侧
• y 是否在上边界下方
• y 是否在下边界上方

业务里也一样，所谓“客户有意向”“工单需要升级”“线索该跟进”，都需要一组可验证条件，而不是一句感觉。

把碰撞检测翻译成工作流触发器

把“鼠标进入拾取物范围”换成“线索进入可跟进范围”，你会得到一套更实用的规则：

• 事件：用户提交表单 / 拨打电话 / 在官网停留超过 60 秒
• 边界：满足某些字段或阈值（预算、地区、岗位、关键词、访问页面）
• 动作：创建 CRM 线索、派单、发送邮件或安排回拨

一个可复用的“触发器模板”长这样：

触发 =（事件）+（条件边界）+（冷却/去重）+（动作）

这里的“冷却/去重”非常关键，对应游戏里“别让玩家在同一个物品上反复刷分”。如果没有去重，你的自动化会变成骚扰系统。

语音助手的“碰撞检测”：关键词 + 语境边界

在 AI 语音助手场景里，碰撞检测可以理解为：用户语句是否落在某个意图（intent）的边界内。

例如“我要改预约”可能触发改期流程，但边界条件应该包含：

• 是否提供了订单号或手机号（可识别实体）
• 改期时间是否在营业范围
• 是否已存在未完成工单（去重）

把边界写细，语音助手才不会“听到关键词就乱跑”。

阻挡墙壁：给系统加边界，避免自动化失控

P5.js 里常见的做法是：玩家坐标不能小于 0，也不能超过 width - playerSize。这看起来像“防止方块跑出画布”，但在业务里它对应的是权限、合规与风控边界。

自动化最容易翻车的地方，不是“做不到”，而是“做过头”。

业务工作流的三类“墙壁”

1. 权限墙：哪些动作只能由特定角色执行（退款、改价、删数据）
2. 合规墙：哪些字段不能被外发（手机号、身份证、病历等）
3. 节流墙：单位时间最多触发多少次（避免短信/外呼轰炸）

把“墙壁”当成默认配置，而不是事后补丁。我的经验是：任何涉及外发消息、外呼、自动下单的流程，都应该先写清楚边界再上线。

用简单规则实现“画布边界”

你不需要复杂平台也能做到：

• 在动作执行前加一段 if/else 校验（字段是否齐全、是否重复、是否越权）
• 关键动作走“人工确认”分支（类似游戏里的暂停/弹窗）
• 记录每次触发的输入与输出（相当于回放日志）

这类防护，能让 AI 自动化变得可控，也更容易说服团队放权给系统。

实体管理：用“类”和“状态”组织你的客户、工单与 NPC

P5.js 里当屏幕上出现很多泡泡（实体）时，最好的办法不是写一堆变量，而是用类（class）统一管理：每个实体有自己的坐标、速度、是否被触碰等状态。

业务里同样如此：客户、线索、订单、工单、内容任务，本质都是“实体”。

把 Bubble 类换成业务对象

在游戏示例中，一个 Bubble 有：

• 位置（x,y）
• 半径（radius）
• 是否被触碰（touched）

在销售跟进里，一个 Lead 往往至少需要：

• stage：新线索 / 已联系 / 已报价 / 成交 / 流失
• last_touch_at：最近一次触达时间
• score：意向分
• owner：负责人
• next_action：下一步动作（回拨、发方案、邀约演示）

当你把这些字段当成“类的属性”，自动化就能围绕状态运转，而不是围绕“发一条消息”这种零散动作。

为什么游戏里用 Perlin noise，工作流里用“队列 + 频率”

示例用 noise() 让泡泡移动更自然。它传递的启发是：很多系统不是随机跳跃，而是连续演化。

业务里也一样：客户意向不是一瞬间从 0 变 100，而是随着触点累积变化。

一个更稳定的做法是：

• 把动作放进队列（例如“待回拨”）
• 用频率控制执行（例如“每个线索每天最多 1 次外呼”）
• 让分数随时间衰减（例如 7 天游离则降权）

这比“只要提交表单就狂发三封邮件”要成熟得多。

计分机制：把 KPI 写成代码，自动化才知道该优化什么

在泡泡被触碰时加分的例子里，有个关键细节：必须防止重复加分。所以要先判断 touched 是否为 false，再增加 score。

很多小企业的自动化没效果，问题就出在“计分不严谨”：

• 同一个线索被多次算作新增
• 同一次咨询被多个渠道重复归因
• 同一个客户多次触发同一流程，数据被污染

用“事件去重”保护你的增长指标

把游戏里的 touched 思想翻译过来，你至少需要：

• 唯一键：订单号/手机号/会话 ID
• 去重窗口：例如 24 小时内同一号码只算一次“有效咨询”
• 幂等性：动作重复执行也不会造成重复创建/重复扣费

一句话：先做去重，再谈智能。

AI 语音助手怎么“计分”？

如果你在做语音助手（客服/前台/外呼），建议把“成功”定义得具体一点：

• 自助解决率（无需人工介入的比例）
• 平均处理时长（AHT）
• 转人工的原因分布（识别失败、权限不足、用户拒绝）
• 关键字段收集率（电话、订单号、期望时间）

这些就是你的 score。没有它们，你只是在“上线一个能说话的东西”。

游戏状态机：把业务流程拆成“开始—进行—结束”

示例用一个 win 变量控制状态：当分数达到阈值，游戏停止运行主体逻辑，显示“Win”。这就是最小可用的状态机（state machine）。

业务流程更需要状态机。原因很简单：只要流程跨过两天、涉及两个人、包含一次失败重试，它就不可能只靠 if/else 堆出来。

常见的工作流状态设计

以“语音助手接听并创建工单”为例，可以这样拆：

1. START：来电接入，创建会话
2. COLLECT：收集订单号/问题类型
3. ROUTE：路由到合适队列或人
4. RESOLVE：自助解答或人工处理
5. END：回访/满意度/关闭工单

每个状态都应该定义清楚：

• 进入条件（触发器）
• 退出条件（成功/失败/超时）
• 允许的动作（发短信、建单、转人工）

这跟游戏的“开始界面—游戏中—胜利/失败界面”是同构的。

把“失败”当成必选项，而不是意外

很多团队只写“Win”，不写“Lose”。上线后才发现：

• 识别不到关键信息怎么办？
• 用户沉默 8 秒怎么办？
• CRM 写入失败怎么办？

在游戏里，这些对应的是：玩家卡墙、掉线、帧率下降。成熟的系统会把失败路径写进状态机，自动重试或切换到人工兜底。

可靠的自动化不是“永不出错”，而是“出错时也知道下一步做什么”。

把游戏逻辑接到“AI 自动化”：一条可落地的实践路线

如果你想把本文的方法用在真实业务里，我建议按下面顺序做，别反过来：

1. 先列实体：线索、客户、工单、订单、内容任务各有哪些字段
2. 再写触发器（碰撞检测）：哪些事件触发、边界是什么、如何去重
3. 加墙壁（边界与权限）：越权、敏感信息、频率上限
4. 补计分（指标）：哪些算成功、如何归因、如何记录
5. 最后做状态机：开始/进行/结束与失败兜底

当这些都清楚了，接入 AI 语音助手（ASR/意图识别/对话管理）才会变成“把输入换成语音”，而不是把流程变复杂。

写在最后：游戏开发者和运营负责人，其实在做同一件事

在「人工智能在游戏与数字娱乐」这个主题下，我们经常聊智能 NPC、玩家行为分析、实时反作弊、内容生成。但我越来越确定：这些能力能外溢到企业场景里，尤其是语音助手 + 自动化工作流。

P5.js 的游戏逻辑提醒我们一件很朴素的事：系统之所以聪明，不是因为它会“想”，而是因为你把条件、边界、状态、计分写得足够清楚。

如果你准备在 2026 年把 AI 语音助手真正用进业务流程，不妨先回答这个问题：你希望系统在“碰到什么情况”时自动做什么，又在什么情况下必须停下来交给人？