智慧旅遊：天氣感知行程規劃器
全書最後一站，我們把一條真正的十節點流程從頭到尾、一個節點一個節點拆給你看：怎麼新增、每格填什麼、變數怎麼接。做完之後，還要把它發布成網頁分享給別人，並看看別人拿到連結後實際使用的樣子。這一章特別詳細——因為它就是你未來自己動手時的完整範本。
旅遊規劃最惱人的變數就是天氣：排了滿滿的戶外行程，遇到下雨全泡湯。旅行社與 OTA 若要提供「貼心到會看天氣」的行程建議，傳統做法要串接天氣 API、寫一堆判斷邏輯、再套模板——工程量不小。而這正是工作流的舞台：把「查即時資料 → 依資料決策 → 產出成品」用節點拼出來，不必寫完整程式。
本章目標
- 解決什麼
- 依目的地即時天氣自動調整室內／戶外行程，產出旅遊手冊，並發布分享給任何人使用
- 用到的技術
- HTTP Request ＋ Code ＋ 條件分歧 ＋ 變數聚合 ＋ 模板組裝 ＋ 發布 WebApp——10 個節點
- 難度
- ★★★★★ 全書最詳盡：逐節點教學＋發布分享＋使用者實際操作
不想從頭做？下載本章的 DSL 檔，到你的 Dify「工作室 → 匯入 DSL 檔案」上傳，就能一鍵複製這個範例、改成自己的。
30.0先看成果：你將做出這個
動手拆解之前，先看做完長什麼樣——這樣你就知道自己在往哪裡前進。下面是這個工具發布成網頁、分享出去之後，一位使用者實際拿到的東西：他只填了「城市、天數、偏好」三格，系統就自動查了即時天氣、判斷會下雨，回給他一份完整的雨天版行程手冊。
城市：京都
天數：3
偏好：寺廟、抹茶甜點與老街散步
京都 3 日行程手冊
☁️ 天氣概況
地點：Shijodori
目前：24C, Light Rain Shower
未來天氣：
- 2026-07-05: 21~23C, 降雨機率最高 88%
- 2026-07-06: 21~24C, 降雨機率最高 84%
- 2026-07-07: 20~30C, 降雨機率最高 54%
FLAG=RAINY
🗺️ 建議行程
京都 3 日雨天友善行程規劃
天氣提醒：7/5、7/6 降雨機率高達 84~88%，行程以「室內殿堂、有頂商店街、美術館」為主；7/7 降雨機率降至 54%，安排較多戶外老街散步，並附雨天備案。
📅 Day 1（7/5，降雨機率 88%）— 京都車站周邊＋室內佛堂＋有頂老街
上午
- 三十三間堂（京都國寶級室內佛堂，1001尊千手觀音，全程室內完全不怕雨）
- 🚌 交通：京都駅搭市巴士 100/206 約 10 分鐘，或步行 20 分鐘
- 京都國立博物館（緊鄰三十三間堂，室內展覽，可安排 1 小時）
中午
- 午餐：京都駅「京都拉麵小路」（室內美食街，多家人氣拉麵店）
下午
（以上為實際跑出來的行程手冊開頭，完整版更長——下載 DSL 自己跑就看得到全部）
心動了嗎？這一切背後只是十個節點的協作，而且不用寫完整程式。接下來我們就從零把它一格一格做出來、再發布成上面這個網頁。
30.1先看全貌：十個節點怎麼串
建立應用時選「工作流」。整條流程是：開始 → 查詢天氣 API → 解析天氣 → 是否多雨 →（雨天／晴天兩條路線）→ 彙整行程 → 實用建議 → 組裝行程手冊 → 輸出。
兩種方式：（1）把游標移到兩個節點之間的連線上，會出現一個「＋」，點它就能在中間插入節點；（2）點某個節點右側的「＋」，選擇下一個節點的類型。跳出的清單裡就有 LLM、知識檢索、問題分類器、條件分歧、程式碼執行、HTTP 請求、範本轉換、變數聚合器等。選好類型後，點該節點即可在右側面板設定內容。以下逐一示範。
30.2節點① HTTP Request：讓流程連上外部世界
新增一個「HTTP 請求」節點，接在「開始」之後。它負責去打天氣 API 拿即時資料。
- 方法與網址方法選
GET；網址填https://wttr.in/，接著在網址中插入變數——輸入/會跳出變數選單，選「開始 / city」，再補上?format=j1（要 JSON 格式）。 - 其他欄位HEADERS、PARAMS、BODY 這個範例都不需要（BODY 選
none）。 - 失敗重試外部 API 偶爾會抽風，把「失敗時重試」打開、設 3 次，穩定度大增。
開始/city 變數膠囊——它會把使用者輸入的城市即時代入網址。下方還有 BODY 型別、SSL 驗證、超時與失敗重試設定。這個節點的輸出變數是 body（API 回傳的內容）。30.3節點② Code：把 API 的 JSON 變成好用的資料
天氣 API 回來的是一大包 JSON，直接給 LLM 讀太浪費。新增一個「程式碼執行」節點來解析它。
- 語言Language 選
python3。 - 程式碼在 Code 欄位貼上 Python：用
raw = """{{查詢天氣API/body}}"""接住上一個節點的輸出（同樣用/插入變數），再json.loads解析，取出目前溫度、天況與未來幾天降雨機率，最後print出整理好的文字，並輸出一個旗標FLAG=RAINY或FLAG=CLEAR。
raw = """…body…""" 就是把 HTTP 節點的回傳接進來；後面用標準 Python 解析 JSON。這段程式在 Dify 沙箱裡真的被執行，輸出變數同樣是 text。把「給人看的天氣摘要」和「給機器判斷的 FLAG」都印出來，下游要哪個都方便。30.4節點③ 條件分歧：晴天走一條路、雨天走另一條
新增「條件分歧（IF/ELSE）」節點。它會依 Code 輸出的旗標決定往哪走。
- 設定 IF 條件在 IF 區塊，變數選「解析天氣 / text」，運算子選「包含」，值填
FLAG=RAINY。 - 接上兩條路線面板下方的「下一步」會出現 IF 與 ELSE 兩個接點：IF 接「雨天行程規劃」LLM、ELSE 接「晴天行程規劃」LLM。（需要更多條件可按 ELIF。）
雨天／晴天兩個 LLM 節點的設定方式，跟前面各章的 LLM 節點一樣：在提示詞裡放不同指示（雨天偏室內景點、晴天偏戶外），並用
/ 插入「開始」的城市天數偏好與「解析天氣」的結果當作依據。30.5節點④ 變數聚合：把兩條路線收攏成一條
分岔出去總要收回來。新增「變數聚合器」節點，把雨天／晴天兩個分支的輸出合併成一股，後面才好接續處理。
30.6節點⑤ 範本轉換：把零件組裝成成品
最後用「範本轉換」節點，把天氣、行程、建議拼成一份漂亮的旅遊手冊。
- 設定輸入變數在「輸入變數」區把要用到的來源一一對應成好記的名字：
city←開始/city、days←開始/days、weather←解析天氣/text、plan←彙整行程/output、tips←實用建議/text。 - 寫模板在「模板程式碼」用 Jinja2 語法排版，用
{{ city }}、{{ weather }}、{{ plan }}這種雙大括號引用剛才命名的變數。
{{ city }} {{ days }} 日行程手冊 這種寫法自由排版。範本節點不呼叫 AI、純粹組裝字串，快又穩，是彙整多個節點結果的最佳工具。輸出變數是 output。30.7測試：看資料流過十個節點
節點都設好後，按右上「測試運行」，填入「京都、3 天、美食與文化古蹟」。切到「追蹤」分頁，就能看到資料實際流經每一個節點。
30.8發布：把它變成一個能分享的網頁
做好了，怎麼讓別人用？點右上角「發佈」，會看到一個選單——這就是把應用分享出去的所有方式。
30.9別人拿到連結後，實際使用的樣子
點「運行」拿到的網址（形如 http://你的網域/workflow/xxxx），可以做成 QR Code 貼在官網、傳給客戶或同事。他們不需要登入 Dify、也不用懂任何技術，打開就是一個乾淨的表單。
使用者填好按執行，右側會顯示工作流各節點依序完成（含 HTTP 抓天氣），最後就吐出章首那份完整的行程手冊（圖 30-0）。對使用者來說，這就是一個好用的旅遊小工具；沒有人知道背後是十個節點在協作。這，就是你從零打造、再一鍵分享出去的成果。
你不只做出一個會看天氣的行程規劃器，更把它變成一個任何人都能用的網頁服務——傳個連結就能分享，對方零門檻上手。串接外部 API 不必寫後端、發布不必架伺服器。同一套骨架換個 API，就能做匯率試算、庫存查詢、內部系統整合。
30.10結語：三十章之後，創造由你開始
從第 11 章的一段提示詞，到這一章逐節點打造、再發布分享的十節點流程，我們走過了十五個核心技巧、二十個產業場景。你會發現：再複雜的應用，拆開來都是這些「型」與「工具」的排列組合——分類器分流、條件分歧、知識檢索、Code 精算、工具串接、平行執行、Agent 自主、HTTP 對外、發布分享。
真正的能力，不是記住這三十個範例，而是看到一個業界痛點時，能在腦中把它拆解成 Dify 的節點組合，做出來、再一鍵分享給需要的人。工具已經交到你手上，剩下的，是你要用它解決什麼問題。祝你創造愉快。
30.11本章回顧
- 新增節點：點連線上的「＋」或節點右側的「＋」，選類型後在右側面板設定。
- HTTP 節點連外部 API、Code 節點解析資料、條件分歧做決策、變數聚合收攏分支、範本轉換組裝成品——各司其職。
- 「發佈 → 運行」即得一個免登入的分享網頁；別人打開就是你「開始」節點設計的表單。
- 三十章的技巧，本質是可自由組合的積木——看懂痛點、拆成積木、做出來、分享出去。