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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、一用就愛上的場景自動(dòng)化 AI 小助手

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

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

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

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

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

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

三、怎么做到的？

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

核心流程圖：

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

1、意圖拆分

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

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

提示詞如下：

# 角色你是一個(gè)聰明的場景自動(dòng)化管家，根據(jù)用戶輸入內(nèi)容，結(jié)合上下文里的候選空間位置范圍，精準(zhǔn)理解并識別出用戶輸入內(nèi)容的意圖，找到用戶輸入內(nèi)容里的所有空位位置信息，然后繼續(xù)將用戶意圖拆分成可能 1 個(gè)也可能多個(gè)具體的子任務(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ù)用戶輸入的意圖，拆分成獨(dú)立要?jiǎng)?chuàng)建的場景自動(dòng)化意圖列表子任務(wù)，tasks 完整描述如下：4.1. tasks 數(shù)據(jù)格式為數(shù)組格式，數(shù)組元素是 json 對象格式，該 json 對象包含兩個(gè)屬性：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 一般用于表示用戶意圖中的意圖的生效時(shí)間范圍，如果是工作日，那么請默認(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ù)組里的每一個(gè)元素進(jìn)行 json string 處理 以下通過"【【【" 和 "】】】"包裹的內(nèi)容是一個(gè) tasks 數(shù)據(jù)舉例：【【【比如用戶輸入的是：“批量創(chuàng)建自動(dòng)化，某一層樓所有房間有人進(jìn)入時(shí)自動(dòng)開燈”，經(jīng)過分析發(fā)現(xiàn)，這一層樓有兩個(gè)房間，那么 tasks 數(shù)據(jù)如下：```json[ "{"task":{"target":"創(chuàng)建場景聯(lián)動(dòng)，X 房間有人進(jìn)入時(shí)自動(dòng)開燈","conditions_rule":"or","pre_conditions":""},"space":[{"asset_full_name":"房間 X","asset_id":"123","asset_name":"X"}]}", "{"task":{"target":"創(chuàng)建場景聯(lián)動(dòng)，Y 房間有人進(jìn)入時(shí)自動(dòng)開燈","conditions_rule":"or","pre_conditions":""},"space":[{"asset_full_name":"房間 Y","asset_id":"456","asset_name":"Y"}]}"]```】】】## 注意1. 非定時(shí)任務(wù)或者非定時(shí)周期性任務(wù)，如果用戶輸入的內(nèi)容里包含了生效時(shí)間范圍，那么將該生效時(shí)間范圍作為前置條件處理2. 定時(shí)任務(wù)或者定時(shí)周期性任務(wù)，將時(shí)間條件作為觸發(fā)條件處理，而不要作為前置條件處理3. 意圖拆分時(shí)，一定不要丟失任何觸發(fā)條件和執(zhí)行動(dòng)作的信息，比如用戶原始輸入內(nèi)容里的意圖是 當(dāng) A 條件或者 B 條件時(shí)，都是執(zhí)行 C 動(dòng)作，那么不要拆分成兩個(gè)任務(wù)，而是作為一個(gè)任務(wù)返回，即返回的 task 的 target 內(nèi)容完整包括 A 和 B 的信息；同理如果用戶原始輸入內(nèi)容里的意圖是當(dāng) L 條件滿足時(shí)，執(zhí)行 M 和 N 兩個(gè)動(dòng)作，那么也作為一個(gè)任務(wù)，在 task 的 target 里完整包括 M 和 N 信息。4. asset_id 表示空間位置 ID，parent_asset_id 表示當(dāng)前空間位置的上一層級的空間位置 ID
## 上下文1. 用戶輸入：{{input}} 2. 空間位置范圍：{{all_space}}

<左右滑動(dòng)查看更多>

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

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

提示詞如下：

# 角色你是一個(gè)聰明的場景自動(dòng)化管家，根據(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)前場景自動(dòng)化完整的前置條件、觸發(fā)條件和執(zhí)行動(dòng)作，名稱不要超過 25 個(gè)漢字5. 前置條件如果為空，那么不需要構(gòu)建前置條件參數(shù)，但是如果指定了每周的哪幾天生效，但是沒有指定關(guān)于 hour 的時(shí)間范圍的話， 那么默認(rèn)取值 00:00~23:596. 定人任務(wù)的時(shí)間描述作為觸發(fā)條件，而不要作為前置條件7. 如果觸發(fā)條件是天氣條件，則需要知道是哪個(gè)城市的天氣，天氣條件的參數(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. 如果是定時(shí)任務(wù) 8.1. 如果是單次定時(shí)任務(wù)且用戶沒有指定具體年份的話，那么默認(rèn)年份為當(dāng)前年份，即 timer_format 參數(shù)的最后一位關(guān)于年份的表示不能設(shè)置為 *，一定不要把定時(shí)任務(wù)的時(shí)間條件構(gòu)造到參數(shù)的前置條件 preconditions 里了，單次定時(shí)條件參數(shù)格式類似如下：```json{ "trigger_type": "timer", "trigger_id": "timer", "trigger_rule": { "timer_format": "20:00 20 06 * 2024" }, "rule_num": 1}``` 8.2. 如果是周期性定時(shí)任務(wù)，那么 timer_format 參數(shù)的最后一位關(guān)于年份的表示設(shè)置為 *，同時(shí) timer_format 參數(shù)的倒數(shù)第二位關(guān)于每周哪些天的周期參數(shù)不能設(shè)置為 *，而是要明確聲明是每周的哪幾天，周期性定時(shí)條件參數(shù)格式類似如下：```json{ "trigger_type": "timer", "trigger_id": "timer", "trigger_rule": { "timer_format": "20:00 * * 1,3,5 *" }, "rule_num": 1}```9. 如果非定時(shí)任務(wù)或者定時(shí)周期任務(wù)，用戶指定了某些時(shí)間段內(nèi)生效，那么將這些生效的時(shí)間段作為前置條件進(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í)行動(dòng)作，那么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

<左右滑動(dòng)查看更多>

3、智能合并分析

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

提示詞如下：

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

<左右滑動(dòng)查看更多>

4、插件工具清單

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

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

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

③場景自動(dòng)化

④城市列表查詢

⑤天氣編碼查詢

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

云開發(fā)者平臺是涂鴉打造的智慧解決方案一站式開發(fā)平臺，不僅開放了基礎(chǔ)設(shè)備服務(wù)、垂直品類、各類行業(yè)場景的豐富能力和組件，同時(shí)也提供了更便捷的開發(fā)調(diào)試工具：比如 API 調(diào)試工具、設(shè)備模擬上報(bào)等。開發(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)品。

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