我見過太多站長每天把時間浪費在重復勞動上。寫一篇Z-Blog文章從后臺登錄、填標題、粘貼正文、傳圖、設置分類標簽、點發(fā)布到回頭發(fā)現(xiàn)圖片裂了、摘要沒填、分類選錯再重新編輯一輪二十分鐘就這么沒了。我自己以前也是這么干的直到我花了一個周末用WorkBuddy給自己搭了一個“一鍵發(fā)布”技能才真正體會到什么叫“把工具當人用”——現(xiàn)在我從寫完草稿到文章上線兩分鐘以內搞定中間還能順手干點別的事。這篇就聊聊我是怎么做到的踩了哪些坑以及為什么你也能照著重現(xiàn)一套。這個技能解決的其實是一個很樸素的問題Z-Blog的后臺操作鏈路太固定、太冗長而人的精力不應該花在這種環(huán)節(jié)上。我把“發(fā)布一篇標準文章”這件事拆成了幾個固定動作然后用WorkBuddy把它們串成了一條自動化流水線。整篇文章會按這樣的順序展開先拆解手動發(fā)布到底慢在哪再說我為什么選中WorkBuddy來做這件事接著是技能從零到一的具體搭建過程然后是發(fā)布接口對接時的幾個關鍵處理和實測效果最后聊聊這套思路還能往外擴多遠。如果你也在運營基于Z-Blog的站點手上又恰好有一堆寫好的內容等著上線這篇文章應該能幫你省下不少時間。1. 發(fā)一篇文章為什么需要二十分鐘被忽略的固定動作清單先說個反直覺的結論大多數(shù)人的二十分鐘并不是花在“寫”上而是花在“搬運和核對”上。我觀察過自己很長一段時間的發(fā)布流程記錄下來的動作大致是這些打開瀏覽器輸后臺地址、登錄、進文章管理、點新建、把標題從文檔里復制過去、把正文從編輯器里復制過去、逐張插入圖片、填寫摘要、選分類、打標簽、設置定時發(fā)布還是立即發(fā)布、點擊提交。提交之后呢還要再預覽一遍看看排版有沒有亂、圖片顯不顯示、分類對不對。這一套下來手快的人十分鐘手慢的人二十分鐘真不夸張。1.1 二十分鐘里真正有“價值”的動作不到三分鐘我把自己的操作錄屏回放過一遍發(fā)現(xiàn)真正需要人來做判斷的其實只有三件事這篇文章發(fā)到哪個分類、打什么標簽、摘要怎么寫才能吸引點擊。剩下的動作全是機械重復——復制、粘貼、選擇、確認。這些動作的共同特點是規(guī)則固定沒有任何隨機性只要給足條件誰來做結果都一樣。這就引出了一個判斷標準一個操作如果連續(xù)重復三次以上而且每次的決策邏輯完全一樣那它就應該被自動化。手動發(fā)布之所以慢不是因為操作者手速慢而是因為人在重復執(zhí)行這種零腦力動作時注意力會不自覺地渙散一散就出錯一出錯就要回頭修正于是時間又被翻倍消耗。1.2 手動發(fā)布最容易翻車的三個環(huán)節(jié)結合我自己的經歷和我身邊幾個運營Z-Blog站點的朋友反饋手動發(fā)布翻車率最高的地方長期集中在三個位置一是圖片。很多人寫文章時用的是編輯器里的插入圖片按鈕圖片傳上去了正文里的鏈接是沒問題的但如果你是從Word或者別的地方直接粘貼富文本過來圖片地址往往是本地的或者指向了舊域名的絕對地址。文章發(fā)布出去之后要么圖片在別人電腦上裂掉要么幾年后域名換了他還指向舊地址。這個問題靠手檢查十次有八次會漏。二是摘要和標簽。Z-Blog的文章摘要如果不手動填寫它默認會截取正文前一段文字但截出來的內容往往斷在很奇怪的位置完全沒有吸引力。標簽就更不用說了Z-Blog后臺雖然有自動獲取關鍵詞的功能但準確率不穩(wěn)定經常抓出一堆無關詞。手動發(fā)布時這兩項特別容易被跳過發(fā)布完看到前臺效果才追悔莫及。三是分類歸屬。多分類站點尤其容易出問題——文章該放A分類還是B分類如果后臺默認記憶了上次操作手一抖就選錯了。而且Z-Blog的分類在發(fā)布后修改雖然也能改但改完URL規(guī)則、靜態(tài)頁面的聯(lián)動都是麻煩事。這幾件事恰恰都是可以做成規(guī)則化處理的。圖片可以限定協(xié)議和路徑摘要可以按模板截取加手工改寫兜底標簽可以映射關鍵詞表分類可以按標題內容的關鍵詞自動匹配。把這些規(guī)則寫死讓機器去執(zhí)行人只負責處理規(guī)則覆蓋不到的邊緣case時間和出錯率就都下來了。2. 為什么我選WorkBuddy而不是寫一個獨立腳本方向明確了接下來說選型。我當時的備選方案有三個寫一個獨立的命令行腳本、用現(xiàn)成的發(fā)布工具、用WorkBuddy搭技能。最后選了后者原因很實在維護成本低而且能隨時改。2.1 獨立腳本的問題不是寫不出來是改不起寫一個Python腳本調用Z-Blog的接口從技術上講完全可行核心代碼可能兩百行不到。但問題是腳本寫完之后它的生命周期才剛剛開始。Z-Blog版本升級了接口參數(shù)要調服務器換了IP要改配置網站遷移了域名要更新白名單甚至某一次登錄憑證的加密規(guī)則變了腳本就罷工了。每次出了問題你都得把腳本翻出來重新讀一遍再加上測試半天時間就沒了。而且腳本只能解決“發(fā)布”這一個點。發(fā)布前的內容準備環(huán)節(jié)比如從草稿里提取標題、生成摘要、匹配分類標簽這些還得另外搞一套流程來處理。碎片化的工具鏈維護起來比手動發(fā)布更費精力。2.2 WorkBuddy的核心思路把步驟變成可以對話的任務WorkBuddy吸引我的地方是它把“自動化”這件事的門檻拉到了很低。它不要求你先寫一個完整的程序而是允許你把流程拆成一個個步驟每個步驟可以是固定動作也可以是帶判斷邏輯的規(guī)則甚至可以調用外部接口。這些步驟組合起來就成了一個“技能”。這就像你雇了一個實習生你不需要教他理解整個業(yè)務體系你只需要告訴他看到標題字段就填進標題欄看到正文就填進正文區(qū)看到圖片地址就替換成站內的然后點發(fā)布。實習生不需要聰明只需要嚴格按照步驟執(zhí)行不出錯就行。WorkBuddy這個“實習生”的另一個好處是你教過一次之后它永遠不會忘也永遠不會擅自發(fā)揮。2.3 低代碼不等于沒代碼該寫的接口邏輯還是得寫說句公道話WorkBuddy的低代碼是指流程編排層面的低代碼真到了關鍵位置該寫代碼的地方一點都躲不開。比如調用Z-Blog的XML-RPC接口去發(fā)布文章這個動作本質上還是發(fā)一個HTTP請求、拼一段XML、解析返回結果。WorkBuddy能做的是幫你把“調用接口”這個動作嵌進流程里但接口參數(shù)怎么拼、返回怎么解析還是需要你自己按Z-Blog的協(xié)議來寫。這正好符合我的需求。我不需要從零搭一套系統(tǒng)我只需要在現(xiàn)成的框架里填上我的業(yè)務邏輯。流程的部分交給WorkBuddy接口的部分自己寫各干各擅長的效率最高。3. 從零到一發(fā)布技能的分步搭建過程下面進入正題我把整個搭建過程按實際操作順序拆開講每一步里該注意什么我會穿插著說。我用的環(huán)境是WorkBuddy桌面版本流程編輯器的操作邏輯和主流低代碼平臺差不多你只要是第一次跑通任何一個流程都會對這套邏輯有體感。3.1 第一步整理輸入?yún)?shù)明確技能要接收什么任何自動化技能的第一步不是寫代碼而是定義輸入。我的這個發(fā)布技能輸入?yún)?shù)一共六個文章標題、正文內容、分類ID、標簽列表、摘要、置頂開關。這六個參數(shù)里標題、正文、摘要、標簽是內容層面的分類ID是規(guī)則層面的置頂開關是策略層面的。我建議你在設計輸入?yún)?shù)的時候寧多勿少——比如是不是要支持“定時發(fā)布”要不要支持“原文鏈接”用來做轉載來源標注這些現(xiàn)在看似用不上等站點業(yè)務跑起來之后你會發(fā)現(xiàn)當初多設計一個參數(shù)是多么明智。參數(shù)定好了之后在WorkBuddy里把它們聲明成這個技能的入?yún)⒑竺嫠械牟襟E都可以引用這些變量。這一步沒有什么難度但有一點要提醒正文內容的格式建議統(tǒng)一成Markdown或純文本不要混用。Z-Blog的編輯器本身支持富文本但如果你發(fā)布的正文里既有HTML標簽又有Markdown標記渲染出來的頁面會非常難看。3.2 第二步做標題規(guī)范化和分類匹配規(guī)則標題看起來不用處理實際上值得加一道清洗工序。我遇到的真實問題是草稿箱里的標題格式五花八門有的是“xxx已修改”有的是“【草案】xxx”還有的帶著日期前綴。如果直接把這些臟標題發(fā)到線上前臺文章列表會顯得很不專業(yè)。我在技能里加了一個規(guī)范化步驟規(guī)則是去掉標題兩端的空白字符去除括號內的“已修改”“草案”“待定”等狀態(tài)標記如果標題為空則自動截取正文前30個字作為兜底標題。這套規(guī)則用正則表達式就能實現(xiàn)WorkBuddy里可以直接配置文本處理插件不需要額外寫代碼。分類匹配是我做得比較重的一環(huán)。我的站點分類固定包括行業(yè)動態(tài)、技術教程、產品公告、客戶案例、團隊隨筆五個大類。我的匹配邏輯是維護一個關鍵詞映射表每個分類下面掛一批觸發(fā)詞。比如標題或正文里出現(xiàn)“教程”“安裝”“配置”“報錯”之類的詞就往技術教程歸出現(xiàn)“簽約”“服務”“實施”就往客戶案例歸。每篇文章可以按權重命中多個分類權重最高的作為主分類。這套邏輯跑在編輯腳本里不復雜但效果很穩(wěn)定。我跑了一百多篇歷史文章做回測分類準確率大約在九成左右剩下的兩成是長尾內容人工介入處理完全能接受。3.3 第三步正文清洗和圖片鏈接的站內化處理正文清洗是內容自動化的核心環(huán)節(jié)也是容易被忽視的環(huán)節(jié)。Z-Blog對文章正文的處理是相對寬容的它允許你傳HTML但如果你傳的是純文本它會自動轉義。所以我在技能里統(tǒng)一約定正文先按HTML處理也就是保證傳入的是合法的HTML片段由編輯腳本負責做清洗和轉換。清洗規(guī)則有這么幾條刪掉空段落和無意義的div包裹標簽把樣式屬性全部去掉避免內聯(lián)樣式破壞前臺主題的觀感圖片標簽強制加上alt信息Alt默認取圖片文件名去掉后綴如果標題里有對應關鍵詞自動替換成帶關鍵詞的描述外鏈圖片統(tǒng)一轉成站內相對路徑。圖片鏈接這塊要重點說。如果文章是從別的平臺復制來的圖片地址很可能指向第三方圖床或者原站域名。我需要先下載這些圖片到本地服務器再替換成Z-Blog站內的相對地址。這個過程我在技能里用了一個“圖片采集”子步驟提取正文所有img標簽的src屬性過濾掉站內鏈接對站外鏈接逐一發(fā)起下載請求保存到站點的upload目錄再把src替換成新的相對路徑。實測下來只要目標圖床沒做防盜鏈這個子步驟的成功率相當高。3.4 第四步編排流程把步驟按發(fā)布順序串起來以上幾個環(huán)節(jié)都確定之后就可以回到WorkBuddy的流程編輯面板把它們串成一個完整的執(zhí)行序列。我的流程編排順序是接收參數(shù) → 清洗標題 → 匹配分類 → 清洗正文和圖片 → 拼接摘要和標簽 → 調用發(fā)布接口 → 校驗發(fā)布結果 → 輸出線上文章鏈接。這里有個體驗上的細節(jié)WorkBuddy的每個步驟最好都加上執(zhí)行狀態(tài)輸出。也就是每一步跑完之后把執(zhí)行結果的關鍵信息回顯出來如果出錯能直接定位到是哪一步出了什么問題。這跟寫代碼打日志是一個道理沒有日志的系統(tǒng)出了故障連排查的入口都沒有。3.5 第五步做人工確認的兜底環(huán)節(jié)自動化最怕的是全自動。尤其是發(fā)布動作直接操作線上數(shù)據(jù)萬一規(guī)則寫錯了一批文章被發(fā)到錯誤分類或者帶病格式發(fā)布出去后果是災難性的。所以我在技能流程的最后一步加了一個人工確認節(jié)點。這個節(jié)點做的事情是在你點“執(zhí)行”之后流程會先把清洗后的標題、匹配到的分類、生成的摘要列出來給你看你確認無誤之后再真正調用發(fā)布接口。整個確認過程不超過十秒鐘但能擋住大部分規(guī)則誤判造成的意外。我寧愿每次發(fā)布多花這十秒也不愿承擔一次批量事故的善后成本。4. 對接發(fā)布接口我踩過的XML-RPC的坑和解決方式Z-Blog提供了一套標準的XML-RPC接口跟Typecho、WordPress的發(fā)布方式有相似之處但細節(jié)上又不大一樣。我在這塊踩了不少坑單獨拉一節(jié)出來講講能給你省不少排查時間。4.1 接口地址和鑒權方式要先確認別憑經驗猜Z-Blog的XML-RPC接口路徑通常指向zb_users/目錄下的某個處理器文件具體路徑每個版本可能不同。我第一版對接時想當然地按記憶里的地址去調用結果一直返回404后來翻了當前版本的手冊才找到正確路徑。鑒權這塊用的是用戶名加密碼的方式密碼不是登錄后臺的明文密碼而是要經過特定編碼處理的密文。我一開始直接傳明文密碼接口返回認證失敗排查了好一陣子才明白是這個機制。這段經歷給我的教訓是對接任何系統(tǒng)之前先花十分鐘把對端系統(tǒng)的接口文檔完整讀一遍比踩完坑再回頭讀要劃算得多。4.2 文章內容的XML拼接容易出錯建議用模板加轉義XML-RPC的調用過程本質上是向服務端發(fā)送一段XML結構的請求體。Z-Blog要求文章正文放在一個特定節(jié)點下標題、分類、標簽各占一個節(jié)點。如果正文里包含了特殊字符比如“”“”“”直接拼接XML會導致請求體解析失敗接口返回一個難以理解的錯誤碼。我的解決方式是不在流程里手工拼XML字符串而是維護一個請求模板把標題、正文、分類這些字段作為變量填進去同時對正文內容做一次XML轉義處理。特殊字符轉成對應的實體編碼這樣無論正文里有什么內容請求體結構都不會被破壞。4.3 分類ID不是分類名這個對應關系要維護好Z-Blog的分類在接口調用時用的是分類ID而不是分類名稱。我的分類匹配規(guī)則返回的是分類名稱比如“技術教程”但接口要求傳的是類似“2”這樣的數(shù)字ID。這中間需要一個名稱到ID的映射關系。我剛開始做的時候漏了這個映射直接傳分類名稱進接口發(fā)布結果全部默認進了未分類。后來我在技能里加了一個“分類ID映射表”的數(shù)據(jù)文件把站點后臺每個分類的名稱和ID對應關系都維護進去匹配完成之后先查映射表再傳入接口。這一處修正之后分類歸屬就再也沒出過差錯。4.4 接口返回結果的解析策略Z-Blog的XML-RPC接口發(fā)布成功之后返回的是新文章的ID號。解析這個返回結果也有講究要按XML結構逐層取到目標節(jié)點而不是簡單判斷請求是否返回了200。因為有時候HTTP層面是200但返回的XML結構里其實是錯誤信息這種情況如果直接當成功處理會漏掉真正的發(fā)布失敗。我在技能里對返回結果做了兩層校驗第一層請求是否正常完成網絡層面有沒有超時或連接被拒絕第二層返回的XML里是否包含合法的文章ID節(jié)點ID是否為數(shù)字。兩層都通過才判定為發(fā)布成功然后順手把前臺文章鏈接拼出來輸出到執(zhí)行結果里。5. 實測數(shù)據(jù)從二十分鐘到兩分鐘時間都省在哪了技能搭好之后我做了連續(xù)兩周的實測把手動發(fā)布和技能發(fā)布的數(shù)據(jù)做了個對比。結論很直接平均一篇文章的發(fā)布耗時從原來的二十二分鐘壓縮到了一分四十秒左右效率提升了十倍以上而且發(fā)布后的返工率從三成降到了基本為零。下面拆開說說時間都省在了哪些環(huán)節(jié)。5.1 耗時對比的四個環(huán)節(jié)我按“登錄和新建”“內容填裝”“選項配置”“檢查發(fā)布”這四個環(huán)節(jié)分別計時手動組和技能組的數(shù)據(jù)大概是這樣的環(huán)節(jié)手動平均耗時技能平均耗時說明登錄后臺并新建文章約4分鐘約5秒技能直接帶憑證調用免登錄標題、正文、圖片填裝約10分鐘約30秒正文清洗和圖片采集全自動分類、標簽、摘要設置約4分鐘約20秒規(guī)則匹配加人工確認檢查預覽并發(fā)布約4分鐘約45秒接口發(fā)布加自動校驗這個數(shù)據(jù)里最夸張的是“標題、正文、圖片填裝”這個環(huán)節(jié)手動要十分鐘是因為圖片要一張一張地插正文還要清一遍格式。技能把這個過程壓縮到了半分鐘內因為我只需要把草稿內容喂進去剩下的清洗、采集、替換都是機器自動完成的。5.2 不只是快出錯率的變化更值得關注我統(tǒng)計了一下這兩周內的發(fā)布數(shù)據(jù)手動發(fā)布時期大約有三分之一的文章發(fā)布后需要重新編輯一次原因不外乎圖片裂了、分類錯了、摘要丟了。技能發(fā)布之后這個返工率降到了零——不對其實有一次是我自己確認分類的時候手滑點錯了但這屬于人工插手造成的不是流程本身的缺陷。這一點才是自動化的真正價值所在。時間節(jié)省是表面收益穩(wěn)定性才是底層收益。手動操作時人的注意力水平是波動的下午三點和晚上十一點的操作質量完全不同而技能執(zhí)行時每一步的質量標準是一致的不會因為操作者累了就變差。5.3 實際發(fā)布流程中技能無法覆蓋的部分我必須誠實地說這套技能并不是萬能的。它適合的發(fā)布場景是你已經有了一篇結構完整的草稿標題、正文、圖片都準備好了只需要按流程發(fā)表。但如果你的需求是“從零構思一篇熱點文章”技能幫不上忙那是內容創(chuàng)作環(huán)節(jié)的事不是分發(fā)環(huán)節(jié)的事。另外如果文章里包含大量自定義短代碼、需要手工調整排版的特殊模塊或者要綁定特定專題頁這類非標準的內容還是建議走手動編輯。技能的定位是把標準化的那部分做到極致非標準的部分留給人自己處理這才是合理的分工。6. 這個技能還能怎么擴展自動采集、多站點分發(fā)和定時發(fā)布這套發(fā)布技能跑順之后我自然開始琢磨它還能往哪兒延伸。下面這幾個方向是我已經動手驗證過或者正在規(guī)劃中的給大家做個參考。6.1 擴展一聚合自動采集讓文章從“整理好再發(fā)”變成“采集完就發(fā)”如果能接一個RSS采集或者批量導入的模塊那這套技能就能實現(xiàn)更完整的“信息流自動化”。比如我每天要匯總一批行業(yè)資訊原來得逐條去各站點找、復制、重新排版?，F(xiàn)在可以做成這樣采集模塊定時運行把最新內容抓回來按關鍵詞過濾和去重生成干凈的標題和正文然后傳給發(fā)布技能自動上線。當然純自動采集發(fā)布的內容建議還是保留一個人工抽檢的環(huán)節(jié)。平臺算法和技術規(guī)范都強調內容質量不能因為追求效率就把把關環(huán)節(jié)全砍掉。我的做法是讓采集內容匯總到一個待審列表我每天固定花十五分鐘掃描一遍確認沒有問題的才批量放行。6.2 擴展二一套內容同時發(fā)到多個站點我身邊好幾個朋友手上都不止一個Z-Blog站點主題不一樣定位也不一樣。同一篇文章可能需要同時發(fā)到兩個站或者在不同站上設定不同的分類和標簽。這套技能的參數(shù)化設計天然適合做多站點分發(fā)——把站點的接口地址、賬號憑證、分類映射表都做成獨立配置執(zhí)行時按目標站各跑一遍發(fā)布流程就行。這塊我還在做重點要解決的是各站之間的內容差異化問題。比如A站用戶喜歡技術深挖B站用戶更關注行業(yè)視角那同一篇文章在發(fā)布前可能需要各自生成不同的摘要和標簽。WorkBuddy里的“分支判斷”節(jié)點可以派上用場按目標站點走不同的內容處理分支。6.3 擴展三定時發(fā)布和定時任務編排還有一種高頻需求是定時發(fā)布。Z-Blog后臺本身支持定時發(fā)布但設置起來要逐篇去改時間。配合WorkBuddy的定時觸發(fā)能力我可以提前把一批文章都排好設置成每天早八點固定發(fā)布一篇周末和節(jié)假日的發(fā)布節(jié)奏還可以單獨配置。這套機制跑起來之后別說是自己發(fā)文章就是給整個團隊配置內容日歷也不過是填一張表的事。我在實際使用中發(fā)現(xiàn)定時任務的穩(wěn)定性比預期還好——只要WorkBuddy所在的主機不斷電斷網定時任務就能穩(wěn)定觸發(fā)不會出現(xiàn)后臺編輯器里常見的那種“到點了沒發(fā)布”的情況。當然如果你跑定時任務的機器是企業(yè)內網的Windows機器記得把電源計劃改成不休眠別讓系統(tǒng)自動睡眠毀了你精心編排的發(fā)布計劃。7. 常見問題和排查思路照著這份清單能解決八九成的問題最后再整理一個排查清單。工具搭好之后出問題不可怕可怕的是不知道從哪查起。按照這個清單的順序排查大部分問題都能在十分鐘內定位到根因。7.1 文章發(fā)布成功但前臺看不到先看接口返回的文章ID是否有效有效的話去后臺文章管理列表里查這篇文章是否存在。如果后臺存在但前臺不顯示多半是緩存問題。Z-Blog有靜態(tài)頁緩存機制發(fā)布成功后需要觸發(fā)一次緩存更新。我的技能里專門加了一個“刷新緩存”的步驟發(fā)布完成后自動請求一次首頁緩存刷新接口。如果你沒有加這一步發(fā)布后手動去后臺刷新一次頁面緩存也能解決問題。7.2 圖片全部無法顯示優(yōu)先檢查圖片相對路徑是否正確。一個常見的坑是圖片保存到本地之后路徑可能帶了磁盤符號或者前綴多了幾層目錄導致前臺拼接出來的地址404。排查方式是直接在瀏覽器地址欄里打開圖片的最終URL看返回什么狀態(tài)碼。如果是403多半是目錄權限問題如果是404路徑拼接邏輯大概率有誤去流程里檢查圖片保存位置的根目錄定義即可。7.3 分類匹配結果與預期不符先確認站點后臺的分類ID有無變動。Z-Blog偶爾在分類重建之后ID會和新增時的記錄對不上。另外就是關鍵詞映射表本身的維護問題——如果新分類上線了而映射表里沒有對應關鍵詞那新內容就永遠不會被分到那個分類去。建議每次調整站點分類結構時同步更新映射表并把檢查映射表完整性作為日常維護的一部分。7.4 接口報錯認證失敗Z-Blog的登錄憑證有有效期過期之后接口會返回認證失敗。WorkBuddy里存儲的憑證是固定的一次性配置不會自動刷新。如果你發(fā)現(xiàn)某一天發(fā)布突然開始報認證錯誤大概率就是憑證過期了去后臺重新生成一次更新到技能配置里就好。這個坑我第一次遇到時排查了兩個小時寫在這里希望你能十分鐘內搞定。我自己現(xiàn)在每天的工作流已經變成了上午寫內容把草稿扔到待處理目錄下午一鍵執(zhí)行發(fā)布技能十分鐘內處理完當天全部文章晚上看反饋數(shù)據(jù)再調整第二天的選題。發(fā)布這件事已經徹底退出了我的“操心范圍”。你在看完這篇文章之后如果也打算搭一套我的建議是從最小可用版本開始先只接標題、正文、分類三個參數(shù)跑通之后再逐步加圖片處理、摘要生成這些進階功能。骨架搭好了后面長肉只是時間問題。