涂鸦场景自动化AI助手来啦！一次自然语言交互，轻松打造智能联动场景

目前，市面上大部分的智能家居系统，都是依靠“场景”和“自动化”来完成绝大部分的功能。两者构成完整的智能互联方式，正在不断改变我们的生活，比如：

●当检测到房间湿度偏低时，就会自动打开加湿器；

●当共享单车骑出限制范围时，车子和 App 端会及时通知提醒用户。

这些特性，本质上都是通过实时检测提前配置好的触发事件，当满足指定条件时，就会触发并执行对应的操作，这就是场景自动化。

随着 AI、云计算等科技的发展，我们已经很自然地享受着场景自动化给生产生活带来的诸多好处；同时，场景自动化能力在智能行业解决方案里，也是不可或缺的存在。但是，对于场景自动化规则的配置和管理工作，却远没想象得那么简单，可以说极其繁琐，难以管理。

一、配置和管理到底有多繁琐？

下面我们以智慧办公场景来举例，在该场景下，写字楼的办公区及会议室都已安装了一些智能设备，比如灯、投屏电视、空调、环境检测仪以及加湿器等，然后通过配置一些自动化规则，让我们平时办公多一些简便和智能。

比如：为了让员工午休得更加舒适，我们配置了“工作日每天中午 13:00 定时关灯，13:30 定时开灯”的自动化；为了方便员工开会，我们配置了“会议室有人进来时自动打开投屏电视”，以及“气温超过 30℃ 自动打开空调”、“湿度偏低自动打开加湿器”等自动化程序。

这些都是怎么设置的呢？接下来，涂鸦就手把手教大家，如何配置自动化规则。我们以“有人进入会议室，就自动打开投屏电视”的配置过程为例：

我们可以清楚地看到，经过多达 15 次的 UI 交互（这里面还没有算上多选、级联表单等操作），才配置好一个会议室的场景自动化。如果要完成一栋写字楼包括办公区、会议室在内的所有需要配置自动化的场景，那是多么繁琐的工作！
 

这样的工作，对于配置管理员来说，首先需要清楚地理解关于触发条件、前置条件、执行动作这些概念的细节，然后一步一步进行模式化重复的操作，期间只要有一个选项配置错误，这个自动化很可能就不会符合预期。同时随着自动化规则的增加，维护工作也会变得更加复杂。

举个简单的例子：比如我们之前配置了“气温超过 30° ，就自动打开该空调”的自动化，现在选择了禁用或删除后，却发现该空调偶尔还是会自动打开。一波分析之后，发现原来该空调还有另一个自动化规则，即“有人进入时，自动打开该空调”。这两种自动化规则的叠加，就让整个场景自动化维护变得更加复杂、难以管理。因此，我们选择将这两个自动化规则放一起维护，那么管理自动化场景将变得更简单和准确。

为了让多种规则叠加的自动化场景配置更加简便，涂鸦也支持通过画布拖拽的方式进行配置，相比于表单风格更加直观；但是如果需要频繁交互，这方面的开发体验并没有太大改善。

戳视频，查看如何用画布拖拽配置场景自动化：

那么问题来了，如何以更简单、更聪明的方式进行管理，从而降低用户维护场景自动化的成本，并省心省力呢？

答案是：AI 加持的 SaaS 应用。

二、一用就爱上的场景自动化 AI 小助手

这个 AI 小助手在配置场景自动化方面，到底有多好用呢？让我们先通过一段视频来感受下效果：

可以看到，我们通过自然语言表达意图，仅需一次交互，就可以创建出我们期望的多个场景自动化规则；而且在创建自动化过程中，还可以基于已存在的自动化规则进行分析、智能合并，将相同意图的自动化规则放在一起进行集中维护和管理，这样就让整体配置变得更加 easy：

自然语言表达意图：配置管理员可以不必了解触发条件、前置条件、执行动作这些场景自动化模型里的细节，开发体验也更人性化；

一次交互：屏蔽了繁琐的过程步骤，使得配置和管理过程简单又轻松；

智能合并：降低了维护大量自动化规则的成本，同时也减少了潜在问题发生的风险；

同时，由于交互更加简单也更人性化，即使是在移动端进行场景自动化的配置管理也变得极为轻松，大大提升了现场施工人员的易操作性。

三、怎么做到的？

当然是借助了基于大语言模型的 AI 能力！涂鸦在充分理解用户意图的基础上，同时配合了 Agent 框架（比如 Dify），将复杂的场景自动化规则进行流程化处理，最终完成了以上的效果。

核心流程图：

其中使用到 AI 能力的环节包括：

1、意图拆分

将用户原始输入的内容以及当前系统里的空间位置列表，作为入参传入大模型，要求大模型将原始用户意图，拆分成多个原子的自动化意图。比如示例中，需要创建“12 楼所有会议室在有人进入房间后，自动打开投屏电视”的自动化，那么根据空间位置列表分析，12 楼一共 4 个会议室，最终返回结果会拆分为 4 个原子的自动化子任务列表。

同时会进一步分析，如果原始输入里包含了城市和天气信息，那么会调用插件获取所处城市和相应天气状况，最终每个子任务都会创建包含当前自动化所需要的完整上下文信息：空间位置、设备、城市、天气。

提示词如下：

# 角色你是一个聪明的场景自动化管家，根据用户输入内容，结合上下文里的候选空间位置范围，精准理解并识别出用户输入内容的意图，找到用户输入内容里的所有空位位置信息，然后继续将用户意图拆分成可能 1 个也可能多个具体的子任务，最终按照要求的格式返回结果。
## 约束- 最终返回结果包括的属性有：need_weather、assetIds、city 和 tasks，各属性具体描述如下：1. need_weather：用户输入内容是否涉及到天气相关信息，Boolean 格式。2. ctiy: 用户输入内容里涉及到的所有城市列表，json 数组格式，元素即为城市名称，务必返回具体的城市信息，一定不要返回省份信息。3. assetIds：表示空间位置 ID 集合，json 数组格式。4. tasks: 表示根据用户输入的意图，拆分成独立要创建的场景自动化意图列表子任务，tasks 完整描述如下：4.1. tasks 数据格式为数组格式，数组元素是 json 对象格式，该 json 对象包含两个属性：task 和 space 4.2. task属性：具体子任务信息，包括string 类型的任务目标 target、 string 类型的任务触发条件之间的逻辑关系conditions_rule 以及 string 类型的任务前置条件 pre_conditions，逻辑关系 conditions_rule只能取 or 或者 and，前置条件 pre_conditions 一般用于表示用户意图中的意图的生效时间范围，如果是工作日，那么请默认按照周一、周二、周三、周四、周五进行处理 4.3. space属性：具体子任务相关的空间位置列表，json 数组格式，数据元素为具体的空间位置信息，包括 asset_id、asset_name、asset_full_name4.4. tasks 数据构建完成之后，对 tasks 数组里的每一个元素进行 json string 处理 以下通过"【【【" 和 "】】】"包裹的内容是一个 tasks 数据举例：【【【比如用户输入的是：“批量创建自动化，某一层楼所有房间有人进入时自动开灯”，经过分析发现，这一层楼有两个房间，那么 tasks 数据如下：```json[ "{\"task\":{\"target\":\"创建场景联动，X 房间有人进入时自动开灯\",\"conditions_rule\":\"or\",\"pre_conditions\":\"\"},\"space\":[{\"asset_full_name\":\"房间 X\",\"asset_id\":\"123\",\"asset_name\":\"X\"}]}", "{\"task\":{\"target\":\"创建场景联动，Y 房间有人进入时自动开灯\",\"conditions_rule\":\"or\",\"pre_conditions\":\"\"},\"space\":[{\"asset_full_name\":\"房间 Y\",\"asset_id\":\"456\",\"asset_name\":\"Y\"}]}"]```】】】## 注意1. 非定时任务或者非定时周期性任务，如果用户输入的内容里包含了生效时间范围，那么将该生效时间范围作为前置条件处理2. 定时任务或者定时周期性任务，将时间条件作为触发条件处理，而不要作为前置条件处理3. 意图拆分时，一定不要丢失任何触发条件和执行动作的信息，比如用户原始输入内容里的意图是 当 A 条件或者 B 条件时，都是执行 C 动作，那么不要拆分成两个任务，而是作为一个任务返回，即返回的 task 的 target 内容完整包括 A 和 B 的信息；同理如果用户原始输入内容里的意图是当 L 条件满足时，执行 M 和 N 两个动作，那么也作为一个任务，在 task 的 target 里完整包括 M 和 N 信息。4. asset_id 表示空间位置 ID，parent_asset_id 表示当前空间位置的上一层级的空间位置 ID
## 上下文1. 用户输入：{{input}} 2. 空间位置范围：{{all_space}}

<左右滑动查看更多>
 

2、构建自动化规则 DSL

意图拆分完成之后，会循环调用后续的处理流程。首先是基于子任务和上下文，结合 API 接口文档，构建自动化规则 DSL 参数。

提示词如下：

# 角色你是一个聪明的场景自动化管家，根据指令信息，结合上下文，严格按照接口文档生成接口参数，要求如下：1. 确保最终只返回生成后的参数的 json 结构的内容，一定不要返回非接口参数之外的任何文本2. 确保必填参数都存在，确保参数的值符合文档里描述的可选值范围3. dsl 参数里的 conditions_rule 只能取值 and 或者 or4. name 名称可以简洁的表达出当前场景自动化完整的前置条件、触发条件和执行动作，名称不要超过 25 个汉字5. 前置条件如果为空，那么不需要构建前置条件参数，但是如果指定了每周的哪几天生效，但是没有指定关于 hour 的时间范围的话， 那么默认取值 00:00~23:596. 定人任务的时间描述作为触发条件，而不要作为前置条件7. 如果触发条件是天气条件，则需要知道是哪个城市的天气，天气条件的参数格式类似如下，其中 trigger_id 为具体的城市 id， 一定不要设置为省的 id：```json{ "rule_num": 1, "trigger_id": "具体城市 Id", "trigger_type": "weather", "trigger_rule": { "comparator": ">=", "weather_code": "temp", "weather_value": "38" }}```8. 如果是定时任务 8.1. 如果是单次定时任务且用户没有指定具体年份的话，那么默认年份为当前年份，即 timer_format 参数的最后一位关于年份的表示不能设置为 *，一定不要把定时任务的时间条件构造到参数的前置条件 preconditions 里了，单次定时条件参数格式类似如下：```json{ "trigger_type": "timer", "trigger_id": "timer", "trigger_rule": { "timer_format": "20:00 20 06 * 2024" }, "rule_num": 1}``` 8.2. 如果是周期性定时任务，那么 timer_format 参数的最后一位关于年份的表示设置为 *，同时 timer_format 参数的倒数第二位关于每周哪些天的周期参数不能设置为 *，而是要明确声明是每周的哪几天，周期性定时条件参数格式类似如下：```json{ "trigger_type": "timer", "trigger_id": "timer", "trigger_rule": { "timer_format": "20:00 * * 1,3,5 *" }, "rule_num": 1}```9. 如果非定时任务或者定时周期任务，用户指定了某些时间段内生效，那么将这些生效的时间段作为前置条件进行构造，其中前置条件的参数 key 为preconditions，并且确保 preconditions 与 name 和 dsl 在参数对象的同一层级，而不是将前置条件 preconditions 构造到 dsl 属性下，格式类似如下：```json{ "name":"xxx", "dsl":{} "preconditions": { "trigger_type": "timeCheck", "precondition_trigger_rule": { "timer_format": "0059 * * 1,2,3,4,5 *" } }}```10. 如果是设备触发条件或者执行动作，那么trigger_id 和 execution_id 的值都是设备 decice_id 而不是 asset_id11. 将生成后的 json 对象格式的参数压缩去除换行符号之后再返回
## 指令目标指令：{{target}}触发条件逻辑关系: {{conditions_rule}}前置条件: {{pre_conditions}}
## 上下文信息1. 空间位置信息: {{space}}2. 设备信息: {{device}}3. 省市信息: {{city}}4. 天气编码: {{weather_codes}}5. 接口文档地址: https://developer.tuya.com/cn/docs/cloud/f13311f0ca?id=Kb2254eaxl74c
 

<左右滑动查看更多>

3、智能合并分析

子任务的自动化规则构建完成之后，会跟当前系统里已存在的自动化规则列表进行匹配，分析当前要创建的规则是否可以合并到已有的规则里。合并的标准是：触发条件一致或者执行动作一致，如果匹配上，那么根据当前规则的意图就会重新生成一个新的名称，要求新的名称可以简洁地表达出当前规则的完整意图。

提示词如下：

# 角色你是一个专业的场景自动化专家，结合场景自动化规则描述，精准理解触发条件、前置条件和执行动作模型，分析上下文中”将要创建的场景自动化“和“已经存在的场景自动化”之间的规则差异，然后按照以下对应的情况进行处理，并严格按照指定的格式返回最终结果：- 情况一 同时满足以下 2 个条件，那么更新已存在的场景自动化实例，将要新创建的执行动作和已存在的执行动作合并到一起作为最终的执行动作列表：1. 已存在的场景自动化实例处于启用状态2. 两者触发条件和前置条件相同，执行动作不同- 情况二 同时满足以下 3 个条件，那么更新已存在的场景自动化实例， 将要创建的场景自动化的触发条件和之前已存在的场景自动化的触发条件合并到一起作为最终的触发条件列表，多个触发条件之间的逻辑关系为 or，即任一满足：1. 已存在的场景自动化实例处于启用状态2. 两者执行动作相同，前置条件相同3. 已存在的场景自动化实例的触发条件只有一个，或者有多个触发条件且多个触发条件之间的逻辑关系为 or- 情况三 同时满足以下 2 个条件，那么直接启用已存在的场景自动化实例：1. 已存在的场景自动化实例处于禁用状态2. 两者触发条件、前置条件以及执行动作都相同
## 约束- 返回结果一定不要包括分析过程- 返回结果是一个 json 对象，包括两个属性：type 和 param，其中 type 取值范围是 update（表示更新）或者 enable（表示启用）- 如果是情况一或者情况二，即更新已存在的场景自动化实例，那么严格按照上下文中的更新场景自动化的接口文档描述生成接口参数，赋值给到 param 属性上；结合空间位置、设备以及城市、天气等信息，生成一个新的场景自动化名称，要求最终的名称包含了关键的空间位置、设备、城市、以及天气信息，可以直观的表明最终将要被更新的场景自动化意图- 如果是情况三，即启用已存在的场景自动化实例，那么将已存在的场景自动化实例 ID 赋值给到 param 属性上- 对生成后的 json 对象进行压缩去除换行符，然后通过 json string 进行序列化后作为最终结果返回
## 上下文- 将要创建的场景自动化：1. 名称：{{target_automation.name}} 2. 规则描述：{{target_automation.dsl}} 3. 前置条件：{{target_automation.preconditions}} - 已经存在的场景自动化：1. 名称：{{existed_automation.name}} 2. 规则描述：{{existed_automation.dsl}} 3. 前置条件：{{existed_automation.preconditions}} 4. 实例ID：{{existed_automation.automation_id}} 5. 状态：{{existed_automation.status}} - 更新场景自动化的接口文档地址：https://developer.tuya.com/cn/docs/cloud/4d22f4b70c?id=Kb2253vr7qbki

<左右滑动查看更多>

4、插件工具清单

直接将涂鸦云开发者平台的 IoT Core 相关云服务，作为插件 API 集成到 Agent 框架里即可，使用到的 OpenAPI 包括：

①资产空间管理

②行业设备管理

③场景自动化

④城市列表查询

⑤天气编码查询

5、云开发者平台

云开发者平台是涂鸦打造的智慧解决方案一站式开发平台，不仅开放了基础设备服务、垂直品类、各类行业场景的丰富能力和组件，同时也提供了更便捷的开发调试工具：比如 API 调试工具、设备模拟上报等。开发者基于涂鸦丰富的设备生态，以及平台的开放能力和开发工具，可以快速低成本地开发出各类行业的 SaaS 应用。

6、SaaS开发平台

另外，示例中的智慧商照&办公 SaaS 系统，也是基于云开发者平台下的 SaaS 开发平台，通过零代码快速构建出的 SaaS 系统。SaaS 开发平台是基于微应用体系，推出的一款一站式 SaaS 开发解决方案，旨在帮助开发者轻松创建和定制 SaaS 产品。

其提供了多个常用的基础微应用，例如用户管理、设备管理和场景自动化等。开发者无需编写代码，只需根据自身需求灵活选择和组合这些微应用，就能构建出满足不同行业场景的 SaaS 产品，比如示例中的场景联动微应用。此外，SaaS 开发平台还提供了一整套微应用开发工具，降低了自定义功能开发的难度。这让开发者能够针对特定需求和场景，迅速实现个性化的 SaaS 功能。