目前，市面上大部分的智能家居系統，都是依靠“場景”和“自動化”來完成絕大部分的功能。兩者構成完整的智能互聯方式，正在不斷改變我們的生活，比如：

●當檢測到房間濕度偏低時，就會自動打開加濕器；

●當共享單車騎出限制范圍時，車子和 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 功能。