目前，市面上大部分的智能家居系統(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ī)則的配置和管理工作，卻遠(yuǎn)沒想象得那么簡單，可以說極其繁瑣，難以管理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、怎么做到的？

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

核心流程圖：

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

1、意圖拆分

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

同時會進(jìn)一步分析，如果原始輸入里包含了城市和天氣信息，那么會調(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 一般用于表示用戶意圖中的意圖的生效時間范圍，如果是工作日，那么請默認(rèn)按照周一、周二、周三、周四、周五進(jìn)行處理 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ù)組里的每一個元素進(jìn)行 json string 處理 以下通過"【【【" 和 "】】】"包裹的內(nèi)容是一個 tasks 數(shù)據(jù)舉例：【【【比如用戶輸入的是：“批量創(chuàng)建自動化，某一層樓所有房間有人進(jìn)入時自動開燈”，經(jīng)過分析發(fā)現(xiàn)，這一層樓有兩個房間，那么 tasks 數(shù)據(jù)如下：```json[ "{"task":{"target":"創(chuàng)建場景聯(lián)動，X 房間有人進(jìn)入時自動開燈","conditions_rule":"or","pre_conditions":""},"space":[{"asset_full_name":"房間 X","asset_id":"123","asset_name":"X"}]}", "{"task":{"target":"創(chuàng)建場景聯(lián)動，Y 房間有人進(jìn)入時自動開燈","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é)合上下文，嚴(yán)格按照接口文檔生成接口參數(shù)，要求如下：1. 確保最終只返回生成后的參數(shù)的 json 結(jié)構(gòu)的內(nèi)容，一定不要返回非接口參數(shù)之外的任何文本2. 確保必填參數(shù)都存在，確保參數(shù)的值符合文檔里描述的可選值范圍3. dsl 參數(shù)里的 conditions_rule 只能取值 and 或者 or4. name 名稱可以簡潔的表達(dá)出當(dāng)前場景自動化完整的前置條件、觸發(fā)條件和執(zhí)行動作，名稱不要超過 25 個漢字5. 前置條件如果為空，那么不需要構(gòu)建前置條件參數(shù)，但是如果指定了每周的哪幾天生效，但是沒有指定關(guān)于 hour 的時間范圍的話， 那么默認(rèn)取值 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ù)且用戶沒有指定具體年份的話，那么默認(rèn)年份為當(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)生效，那么將這些生效的時間段作為前置條件進(jìn)行構(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ī)則列表進(jìn)行匹配，分析當(dāng)前要創(chuàng)建的規(guī)則是否可以合并到已有的規(guī)則里。合并的標(biāo)準(zhǔn)是：觸發(fā)條件一致或者執(zhí)行動作一致，如果匹配上，那么根據(jù)當(dāng)前規(guī)則的意圖就會重新生成一個新的名稱，要求新的名稱可以簡潔地表達(dá)出當(dāng)前規(guī)則的完整意圖。

提示詞如下：

# 角色你是一個專業(yè)的場景自動化專家，結(jié)合場景自動化規(guī)則描述，精準(zhǔn)理解觸發(fā)條件、前置條件和執(zhí)行動作模型，分析上下文中”將要創(chuàng)建的場景自動化“和“已經(jīng)存在的場景自動化”之間的規(guī)則差異，然后按照以下對應(yīng)的情況進(jìn)行處理，并嚴(yán)格按照指定的格式返回最終結(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（表示啟用）- 如果是情況一或者情況二，即更新已存在的場景自動化實例，那么嚴(yán)格按照上下文中的更新場景自動化的接口文檔描述生成接口參數(shù)，賦值給到 param 屬性上；結(jié)合空間位置、設(shè)備以及城市、天氣等信息，生成一個新的場景自動化名稱，要求最終的名稱包含了關(guān)鍵的空間位置、設(shè)備、城市、以及天氣信息，可以直觀的表明最終將要被更新的場景自動化意圖- 如果是情況三，即啟用已存在的場景自動化實例，那么將已存在的場景自動化實例 ID 賦值給到 param 屬性上- 對生成后的 json 對象進(jìn)行壓縮去除換行符，然后通過 json string 進(jìn)行序列化后作為最終結(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 功能。