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

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

●當(dāng)共享單車騎出限制范圍時，車子和 App 端會及時通知提醒用戶。

這些特性，本質(zhì)上都是通過實時檢測提前配置好的觸發(fā)事件，當(dāng)滿足指定條件時，就會觸發(fā)并執(zhí)行對應(yīng)的操作，這就是場景自動化。

隨著 AI、云計算等科技的發(fā)展，我們已經(jīng)很自然地享受著場景自動化給生產(chǎn)生活帶來的諸多好處；同時，場景自動化能力在智能行業(yè)解決方案里，也是不可或缺的存在。但是，對于場景自動化規(guī)則的配置和管理工作，卻遠沒想象得那么簡單，可以說極其繁瑣，難以管理。

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

下面我們以智慧辦公場景來舉例，在該場景下，寫字樓的辦公區(qū)及會議室都已安裝了一些智能設(shè)備，比如燈、投屏電視、空調(diào)、環(huán)境檢測儀以及加濕器等，然后通過配置一些自動化規(guī)則，讓我們平時辦公多一些簡便和智能。

比如：為了讓員工午休得更加舒適，我們配置了“工作日每天中午 13:00 定時關(guān)燈，13:30 定時開燈”的自動化；為了方便員工開會，我們配置了“會議室有人進來時自動打開投屏電視”，以及“氣溫超過 30℃ 自動打開空調(diào)”、“濕度偏低自動打開加濕器”等自動化程序。

這些都是怎么設(shè)置的呢？接下來，涂鴉就手把手教大家，如何配置自動化規(guī)則。我們以“有人進入會議室，就自動打開投屏電視”的配置過程為例：

我們可以清楚地看到，經(jīng)過多達 15 次的 UI 交互（這里面還沒有算上多選、級聯(lián)表單等操作），才配置好一個會議室的場景自動化。如果要完成一棟寫字樓包括辦公區(qū)、會議室在內(nèi)的所有需要配置自動化的場景，那是多么繁瑣的工作！

這樣的工作，對于配置管理員來說，首先需要清楚地理解關(guān)于觸發(fā)條件、前置條件、執(zhí)行動作這些概念的細節(jié)，然后一步一步進行模式化重復(fù)的操作，期間只要有一個選項配置錯誤，這個自動化很可能就不會符合預(yù)期。同時隨著自動化規(guī)則的增加，維護工作也會變得更加復(fù)雜。

舉個簡單的例子：比如我們之前配置了“氣溫超過 30° ，就自動打開該空調(diào)”的自動化，現(xiàn)在選擇了禁用或刪除后，卻發(fā)現(xiàn)該空調(diào)偶爾還是會自動打開。一波分析之后，發(fā)現(xiàn)原來該空調(diào)還有另一個自動化規(guī)則，即“有人進入時，自動打開該空調(diào)”。這兩種自動化規(guī)則的疊加，就讓整個場景自動化維護變得更加復(fù)雜、難以管理。因此，我們選擇將這兩個自動化規(guī)則放一起維護，那么管理自動化場景將變得更簡單和準(zhǔn)確。

為了讓多種規(guī)則疊加的自動化場景配置更加簡便，涂鴉也支持通過畫布拖拽的方式進行配置，相比于表單風(fēng)格更加直觀；但是如果需要頻繁交互，這方面的開發(fā)體驗并沒有太大改善。

戳視頻，查看如何用畫布拖拽配置場景自動化：

那么問題來了，如何以更簡單、更聰明的方式進行管理，從而降低用戶維護場景自動化的成本，并省心省力呢？

答案是：AI 加持的 SaaS 應(yīng)用。

二、一用就愛上的場景自動化 AI 小助手

這個 AI 小助手在配置場景自動化方面，到底有多好用呢？讓我們先通過一段視頻來感受下效果：

可以看到，我們通過自然語言表達意圖，僅需一次交互，就可以創(chuàng)建出我們期望的多個場景自動化規(guī)則；而且在創(chuàng)建自動化過程中，還可以基于已存在的自動化規(guī)則進行分析、智能合并，將相同意圖的自動化規(guī)則放在一起進行集中維護和管理，這樣就讓整體配置變得更加 easy：

自然語言表達意圖：配置管理員可以不必了解觸發(fā)條件、前置條件、執(zhí)行動作這些場景自動化模型里的細節(jié)，開發(fā)體驗也更人性化；

一次交互：屏蔽了繁瑣的過程步驟，使得配置和管理過程簡單又輕松；

智能合并：降低了維護大量自動化規(guī)則的成本，同時也減少了潛在問題發(fā)生的風(fēng)險；

同時，由于交互更加簡單也更人性化，即使是在移動端進行場景自動化的配置管理也變得極為輕松，大大提升了現(xiàn)場施工人員的易操作性。

三、怎么做到的？

當(dāng)然是借助了基于大語言模型的 AI 能力！涂鴉在充分理解用戶意圖的基礎(chǔ)上，同時配合了 Agent 框架（比如 Dify），將復(fù)雜的場景自動化規(guī)則進行流程化處理，最終完成了以上的效果。

核心流程圖：

其中使用到 AI 能力的環(huán)節(jié)包括：

1、意圖拆分

將用戶原始輸入的內(nèi)容以及當(dāng)前系統(tǒng)里的空間位置列表，作為入?yún)魅氪竽Ｐ?，要求大模型將原始用戶意圖，拆分成多個原子的自動化意圖。比如示例中，需要創(chuàng)建“12 樓所有會議室在有人進入房間后，自動打開投屏電視”的自動化，那么根據(jù)空間位置列表分析，12 樓一共 4 個會議室，最終返回結(jié)果會拆分為 4 個原子的自動化子任務(wù)列表。

同時會進一步分析，如果原始輸入里包含了城市和天氣信息，那么會調(diào)用插件獲取所處城市和相應(yīng)天氣狀況，最終每個子任務(wù)都會創(chuàng)建包含當(dāng)前自動化所需要的完整上下文信息：空間位置、設(shè)備、城市、天氣。

提示詞如下：

# 角色你是一個聰明的場景自動化管家，根據(jù)用戶輸入內(nèi)容，結(jié)合上下文里的候選空間位置范圍，精準(zhǔn)理解并識別出用戶輸入內(nèi)容的意圖，找到用戶輸入內(nèi)容里的所有空位位置信息，然后繼續(xù)將用戶意圖拆分成可能 1 個也可能多個具體的子任務(wù)，最終按照要求的格式返回結(jié)果。
## 約束- 最終返回結(jié)果包括的屬性有：need_weather、assetIds、city 和 tasks，各屬性具體描述如下：1. need_weather：用戶輸入內(nèi)容是否涉及到天氣相關(guān)信息，Boolean 格式。2. ctiy: 用戶輸入內(nèi)容里涉及到的所有城市列表，json 數(shù)組格式，元素即為城市名稱，務(wù)必返回具體的城市信息，一定不要返回省份信息。3. assetIds：表示空間位置 ID 集合，json 數(shù)組格式。4. tasks: 表示根據(jù)用戶輸入的意圖，拆分成獨立要創(chuàng)建的場景自動化意圖列表子任務(wù)，tasks 完整描述如下：4.1. tasks 數(shù)據(jù)格式為數(shù)組格式，數(shù)組元素是 json 對象格式，該 json 對象包含兩個屬性：task 和 space 4.2. task屬性：具體子任務(wù)信息，包括string 類型的任務(wù)目標(biāo) target、 string 類型的任務(wù)觸發(fā)條件之間的邏輯關(guān)系conditions_rule 以及 string 類型的任務(wù)前置條件 pre_conditions，邏輯關(guān)系 conditions_rule只能取 or 或者 and，前置條件 pre_conditions 一般用于表示用戶意圖中的意圖的生效時間范圍，如果是工作日，那么請默認按照周一、周二、周三、周四、周五進行處理 4.3. space屬性：具體子任務(wù)相關(guān)的空間位置列表，json 數(shù)組格式，數(shù)據(jù)元素為具體的空間位置信息，包括 asset_id、asset_name、asset_full_name4.4. tasks 數(shù)據(jù)構(gòu)建完成之后，對 tasks 數(shù)組里的每一個元素進行 json string 處理 以下通過"【【【" 和 "】】】"包裹的內(nèi)容是一個 tasks 數(shù)據(jù)舉例：【【【比如用戶輸入的是：“批量創(chuàng)建自動化，某一層樓所有房間有人進入時自動開燈”，經(jīng)過分析發(fā)現(xiàn)，這一層樓有兩個房間，那么 tasks 數(shù)據(jù)如下：```json[ "{"task":{"target":"創(chuàng)建場景聯(lián)動，X 房間有人進入時自動開燈","conditions_rule":"or","pre_conditions":""},"space":[{"asset_full_name":"房間 X","asset_id":"123","asset_name":"X"}]}", "{"task":{"target":"創(chuàng)建場景聯(lián)動，Y 房間有人進入時自動開燈","conditions_rule":"or","pre_conditions":""},"space":[{"asset_full_name":"房間 Y","asset_id":"456","asset_name":"Y"}]}"]```】】】## 注意1. 非定時任務(wù)或者非定時周期性任務(wù)，如果用戶輸入的內(nèi)容里包含了生效時間范圍，那么將該生效時間范圍作為前置條件處理2. 定時任務(wù)或者定時周期性任務(wù)，將時間條件作為觸發(fā)條件處理，而不要作為前置條件處理3. 意圖拆分時，一定不要丟失任何觸發(fā)條件和執(zhí)行動作的信息，比如用戶原始輸入內(nèi)容里的意圖是 當(dāng) A 條件或者 B 條件時，都是執(zhí)行 C 動作，那么不要拆分成兩個任務(wù)，而是作為一個任務(wù)返回，即返回的 task 的 target 內(nèi)容完整包括 A 和 B 的信息；同理如果用戶原始輸入內(nèi)容里的意圖是當(dāng) L 條件滿足時，執(zhí)行 M 和 N 兩個動作，那么也作為一個任務(wù)，在 task 的 target 里完整包括 M 和 N 信息。4. asset_id 表示空間位置 ID，parent_asset_id 表示當(dāng)前空間位置的上一層級的空間位置 ID
## 上下文1. 用戶輸入：{{input}} 2. 空間位置范圍：{{all_space}}

<左右滑動查看更多>

2、構(gòu)建自動化規(guī)則 DSL

意圖拆分完成之后，會循環(huán)調(diào)用后續(xù)的處理流程。首先是基于子任務(wù)和上下文，結(jié)合 API 接口文檔，構(gòu)建自動化規(guī)則 DSL 參數(shù)。

提示詞如下：

# 角色你是一個聰明的場景自動化管家，根據(jù)指令信息，結(jié)合上下文，嚴格按照接口文檔生成接口參數(shù)，要求如下：1. 確保最終只返回生成后的參數(shù)的 json 結(jié)構(gòu)的內(nèi)容，一定不要返回非接口參數(shù)之外的任何文本2. 確保必填參數(shù)都存在，確保參數(shù)的值符合文檔里描述的可選值范圍3. dsl 參數(shù)里的 conditions_rule 只能取值 and 或者 or4. name 名稱可以簡潔的表達出當(dāng)前場景自動化完整的前置條件、觸發(fā)條件和執(zhí)行動作，名稱不要超過 25 個漢字5. 前置條件如果為空，那么不需要構(gòu)建前置條件參數(shù)，但是如果指定了每周的哪幾天生效，但是沒有指定關(guān)于 hour 的時間范圍的話， 那么默認取值 00:00~23:596. 定人任務(wù)的時間描述作為觸發(fā)條件，而不要作為前置條件7. 如果觸發(fā)條件是天氣條件，則需要知道是哪個城市的天氣，天氣條件的參數(shù)格式類似如下，其中 trigger_id 為具體的城市 id， 一定不要設(shè)置為省的 id：```json{ "rule_num": 1, "trigger_id": "具體城市 Id", "trigger_type": "weather", "trigger_rule": { "comparator": ">=", "weather_code": "temp", "weather_value": "38" }}```8. 如果是定時任務(wù) 8.1. 如果是單次定時任務(wù)且用戶沒有指定具體年份的話，那么默認年份為當(dāng)前年份，即 timer_format 參數(shù)的最后一位關(guān)于年份的表示不能設(shè)置為 *，一定不要把定時任務(wù)的時間條件構(gòu)造到參數(shù)的前置條件 preconditions 里了，單次定時條件參數(shù)格式類似如下：```json{ "trigger_type": "timer", "trigger_id": "timer", "trigger_rule": { "timer_format": "20:00 20 06 * 2024" }, "rule_num": 1}``` 8.2. 如果是周期性定時任務(wù)，那么 timer_format 參數(shù)的最后一位關(guān)于年份的表示設(shè)置為 *，同時 timer_format 參數(shù)的倒數(shù)第二位關(guān)于每周哪些天的周期參數(shù)不能設(shè)置為 *，而是要明確聲明是每周的哪幾天，周期性定時條件參數(shù)格式類似如下：```json{ "trigger_type": "timer", "trigger_id": "timer", "trigger_rule": { "timer_format": "20:00 * * 1,3,5 *" }, "rule_num": 1}```9. 如果非定時任務(wù)或者定時周期任務(wù)，用戶指定了某些時間段內(nèi)生效，那么將這些生效的時間段作為前置條件進行構(gòu)造，其中前置條件的參數(shù) key 為preconditions，并且確保 preconditions 與 name 和 dsl 在參數(shù)對象的同一層級，而不是將前置條件 preconditions 構(gòu)造到 dsl 屬性下，格式類似如下：```json{ "name":"xxx", "dsl":{} "preconditions": { "trigger_type": "timeCheck", "precondition_trigger_rule": { "timer_format": "0059 * * 1,2,3,4,5 *" } }}```10. 如果是設(shè)備觸發(fā)條件或者執(zhí)行動作，那么trigger_id 和 execution_id 的值都是設(shè)備 decice_id 而不是 asset_id11. 將生成后的 json 對象格式的參數(shù)壓縮去除換行符號之后再返回
## 指令目標(biāo)指令：{{target}}觸發(fā)條件邏輯關(guān)系: {{conditions_rule}}前置條件: {{pre_conditions}}
## 上下文信息1. 空間位置信息: {{space}}2. 設(shè)備信息: {{device}}3. 省市信息: {{city}}4. 天氣編碼: {{weather_codes}}5. 接口文檔地址: https://developer.tuya.com/cn/docs/cloud/f13311f0ca?id=Kb2254eaxl74c

<左右滑動查看更多>

3、智能合并分析

子任務(wù)的自動化規(guī)則構(gòu)建完成之后，會跟當(dāng)前系統(tǒng)里已存在的自動化規(guī)則列表進行匹配，分析當(dāng)前要創(chuàng)建的規(guī)則是否可以合并到已有的規(guī)則里。合并的標(biāo)準(zhǔn)是：觸發(fā)條件一致或者執(zhí)行動作一致，如果匹配上，那么根據(jù)當(dāng)前規(guī)則的意圖就會重新生成一個新的名稱，要求新的名稱可以簡潔地表達出當(dāng)前規(guī)則的完整意圖。

提示詞如下：

# 角色你是一個專業(yè)的場景自動化專家，結(jié)合場景自動化規(guī)則描述，精準(zhǔn)理解觸發(fā)條件、前置條件和執(zhí)行動作模型，分析上下文中”將要創(chuàng)建的場景自動化“和“已經(jīng)存在的場景自動化”之間的規(guī)則差異，然后按照以下對應(yīng)的情況進行處理，并嚴格按照指定的格式返回最終結(jié)果：- 情況一 同時滿足以下 2 個條件，那么更新已存在的場景自動化實例，將要新創(chuàng)建的執(zhí)行動作和已存在的執(zhí)行動作合并到一起作為最終的執(zhí)行動作列表：1. 已存在的場景自動化實例處于啟用狀態(tài)2. 兩者觸發(fā)條件和前置條件相同，執(zhí)行動作不同- 情況二 同時滿足以下 3 個條件，那么更新已存在的場景自動化實例， 將要創(chuàng)建的場景自動化的觸發(fā)條件和之前已存在的場景自動化的觸發(fā)條件合并到一起作為最終的觸發(fā)條件列表，多個觸發(fā)條件之間的邏輯關(guān)系為 or，即任一滿足：1. 已存在的場景自動化實例處于啟用狀態(tài)2. 兩者執(zhí)行動作相同，前置條件相同3. 已存在的場景自動化實例的觸發(fā)條件只有一個，或者有多個觸發(fā)條件且多個觸發(fā)條件之間的邏輯關(guān)系為 or- 情況三 同時滿足以下 2 個條件，那么直接啟用已存在的場景自動化實例：1. 已存在的場景自動化實例處于禁用狀態(tài)2. 兩者觸發(fā)條件、前置條件以及執(zhí)行動作都相同
## 約束- 返回結(jié)果一定不要包括分析過程- 返回結(jié)果是一個 json 對象，包括兩個屬性：type 和 param，其中 type 取值范圍是 update（表示更新）或者 enable（表示啟用）- 如果是情況一或者情況二，即更新已存在的場景自動化實例，那么嚴格按照上下文中的更新場景自動化的接口文檔描述生成接口參數(shù)，賦值給到 param 屬性上；結(jié)合空間位置、設(shè)備以及城市、天氣等信息，生成一個新的場景自動化名稱，要求最終的名稱包含了關(guān)鍵的空間位置、設(shè)備、城市、以及天氣信息，可以直觀的表明最終將要被更新的場景自動化意圖- 如果是情況三，即啟用已存在的場景自動化實例，那么將已存在的場景自動化實例 ID 賦值給到 param 屬性上- 對生成后的 json 對象進行壓縮去除換行符，然后通過 json string 進行序列化后作為最終結(jié)果返回
## 上下文- 將要創(chuàng)建的場景自動化：1. 名稱：{{target_automation.name}} 2. 規(guī)則描述：{{target_automation.dsl}} 3. 前置條件：{{target_automation.preconditions}} - 已經(jīng)存在的場景自動化：1. 名稱：{{existed_automation.name}} 2. 規(guī)則描述：{{existed_automation.dsl}} 3. 前置條件：{{existed_automation.preconditions}} 4. 實例ID：{{existed_automation.automation_id}} 5. 狀態(tài)：{{existed_automation.status}} - 更新場景自動化的接口文檔地址：https://developer.tuya.com/cn/docs/cloud/4d22f4b70c?id=Kb2253vr7qbki

<左右滑動查看更多>

4、插件工具清單

直接將涂鴉云開發(fā)者平臺的 IoT Core 相關(guān)云服務(wù)，作為插件 API 集成到 Agent 框架里即可，使用到的 OpenAPI 包括：

①資產(chǎn)空間管理

②行業(yè)設(shè)備管理

③場景自動化

④城市列表查詢

⑤天氣編碼查詢

5、云開發(fā)者平臺

云開發(fā)者平臺是涂鴉打造的智慧解決方案一站式開發(fā)平臺，不僅開放了基礎(chǔ)設(shè)備服務(wù)、垂直品類、各類行業(yè)場景的豐富能力和組件，同時也提供了更便捷的開發(fā)調(diào)試工具：比如 API 調(diào)試工具、設(shè)備模擬上報等。開發(fā)者基于涂鴉豐富的設(shè)備生態(tài)，以及平臺的開放能力和開發(fā)工具，可以快速低成本地開發(fā)出各類行業(yè)的 SaaS 應(yīng)用。

6、SaaS開發(fā)平臺

另外，示例中的智慧商照&辦公 SaaS 系統(tǒng)，也是基于云開發(fā)者平臺下的 SaaS 開發(fā)平臺，通過零代碼快速構(gòu)建出的 SaaS 系統(tǒng)。SaaS 開發(fā)平臺是基于微應(yīng)用體系，推出的一款一站式 SaaS 開發(fā)解決方案，旨在幫助開發(fā)者輕松創(chuàng)建和定制 SaaS 產(chǎn)品。

其提供了多個常用的基礎(chǔ)微應(yīng)用，例如用戶管理、設(shè)備管理和場景自動化等。開發(fā)者無需編寫代碼，只需根據(jù)自身需求靈活選擇和組合這些微應(yīng)用，就能構(gòu)建出滿足不同行業(yè)場景的 SaaS 產(chǎn)品，比如示例中的場景聯(lián)動微應(yīng)用。此外，SaaS 開發(fā)平臺還提供了一整套微應(yīng)用開發(fā)工具，降低了自定義功能開發(fā)的難度。這讓開發(fā)者能夠針對特定需求和場景，迅速實現(xiàn)個性化的 SaaS 功能。