最近在效率工具和 AI 工作流相關(guān)的幾個社區(qū)里WorkBuddy 雙模型限免的消息討論度確實高。簡單概括就是Hy4 preview 限免開放兩周Hy3 直接免到 9 月底。很多人第一反應(yīng)是“又是個營銷噱頭”但我把客戶端完整裝了一遍、兩個模型都實際跑過之后發(fā)現(xiàn)這次值得關(guān)注的不是“免費”兩個字而是它背后那套模型切換和工作流搭建的完整鏈路。這篇文章我會把這個活動講透包括 WorkBuddy 到底是什么、和 CodeBuddy 的區(qū)別在哪里、從下載安裝到本地部署和接入模型的完整操作、拿到限免模型后建議先做的幾件事以及我實測中踩過的坑。無論你是正在搭個人工作臺還是想把釘釘同步、消息推送這些重復(fù)勞動交給工具都建議花幾分鐘把這篇文章看完。1. 這次的限免信息先幫你把賬算清楚1.1 Hy4 preview 和 Hy3 到底是什么定位這里的“雙模型”不是同一代產(chǎn)品換了個名字。根據(jù)我這兩周的實際使用體感Hy4 preview 和 Hy3 在任務(wù)特性和可用性上有非常明顯的分工。Hy4 preview 更像是一個“探索型”模型。它在長上下文理解、指令跟隨和復(fù)雜任務(wù)拆解上表現(xiàn)更積極尤其是當(dāng)你在一條消息里同時丟給它多個子任務(wù)、需要它自己規(guī)劃先后順序的時候Hy4 preview 給出的步驟明顯比 Hy3 靈活。我拿一批真實的工作流需求做了對比比如“把整周的聊天記錄整理成待辦并按優(yōu)先級排序”Hy4 preview 會先識別出哪些是需要行動的、哪些只是信息同步然后自己設(shè)計一套分類規(guī)則而 Hy3 會更傾向于保守地逐條羅列把判斷留給我做。所以需要模型“多動腦子”的場景Hy4 preview 的優(yōu)勢更明顯。Hy3 則是一個“生產(chǎn)型”模型。它的輸出風(fēng)格更收斂行為更可預(yù)測不太會因為提示詞里多寫了一段背景就開始自由發(fā)揮。這一點對跑定時任務(wù)和重復(fù)性流程非常關(guān)鍵因為自動化場景最怕的就是模型“腦補”出不存在的需求。我自己的體驗是同樣一條“每天上午 9 點生成昨日工作總結(jié)”的指令Hy3 連續(xù)跑一周的輸出結(jié)構(gòu)都很穩(wěn)定很少出現(xiàn)格式漂移。所以要給這兩個模型定個位的話我的結(jié)論是Hy4 preview 是拿來“試”的Hy3 是拿來“用”的兩者不是替代關(guān)系而是互補關(guān)系。這個認知會直接影響下面使用節(jié)奏的安排先記著。1.2 時間窗口怎么安排更劃算兩周和到9月底這兩個時間窗其實已經(jīng)暗示了模型的不同用途。兩周的限免含義很明確官方希望你集中測試、快速反饋趁這個窗口把 Hy4 preview 的能力邊界摸清楚。我建議把接下來一個月想試但一直沒動手的個人項目、自動化流程和復(fù)雜提示詞實驗全部趁這個窗口丟進去跑一遍。之前見過不少朋友把限免窗口浪費在閑聊和簡單問答上等窗口過了才想起來有正事沒試回頭看基本等于白拿這次機會。Hy3 到9月底就從容得多。這個時間足夠把一套完整的工作臺搭起來并且把它固化成一個每天都會打開使用的習(xí)慣。我個人現(xiàn)在的節(jié)奏是每周日晚上用 Hy3 批量整理下一周的待辦模板日常工作里的文本整理、周報初稿、數(shù)據(jù)匯總這類重復(fù)性任務(wù)都掛在 Hy3 上跑。臨時冒出來的新需求、拿不準(zhǔn)的復(fù)雜問題才切到 Hy4 preview 去試。另外可以做個簡單的安排表第一周用 Hy4 preview 測你最高頻的5個場景記錄下來哪些表現(xiàn)超出預(yù)期、哪些還需要人工兜底第二周根據(jù)測試結(jié)果把其中2到3個場景沉淀成固定的 skill 或自定義指令切回 Hy3 跑。這樣兩周結(jié)束后你得到的不是一次“用過就忘”的體驗而是一套已經(jīng)跑起來的工作流。1.3 “限免”兩個字背后要注意什么限免不等于無限制。從我了解到的情況看這類模型限免一般都會配合一定的使用額度或者頻率限制具體以客戶端里的提示為準(zhǔn)。所以在 Hy4 preview 限免期內(nèi)我建議把它當(dāng)成“測試資源”而不是“默認模型”。如果把所有請求都指向它很可能提前觸發(fā)額度上限反而影響你驗證新想法。還有一點容易被忽略限免結(jié)束后的切換。Hy3 免到9月底意味著9月底之后模型策略可能調(diào)整如果你把核心業(yè)務(wù)完全綁死在某個模型上到時候會比較被動。比較好的做法是從現(xiàn)在開始就把提示詞寫得盡量模型無關(guān)讓同一套指令在 Hy4 preview 和 Hy3 上都能跑出可接受的結(jié)果。這樣不管后面模型策略怎么變你的工作臺都不會塌。2. WorkBuddy 是個什么工具為什么這次值得裝2.1 智能體工作臺的核心構(gòu)成skill、連接器、自定義指令WorkBuddy 的定位不是“又一個聊天機器人”而是一個圍繞個人工作臺搭建的效率智能體。把它拆開看有三個核心概念skill、連接器和自定義指令有的版本里也叫 instructions。skill 是能力封裝相當(dāng)于給智能體裝了一個“專項技能”。比如“把聊天記錄整理成待辦清單”“從網(wǎng)頁或文檔里抽取結(jié)構(gòu)化數(shù)據(jù)”“生成符合特定格式的周報”這些都可以封裝成 skill。用的時候不用每次都把規(guī)則說一遍直接調(diào)用 skill 名就行這一點在重復(fù)性任務(wù)里非常省事。我自己第一次用 skill 跑通一個從網(wǎng)頁抽取表格并生成 Markdown 文檔的流程時最大的感受是以前要寫腳本做的事現(xiàn)在用自然語言定義一遍規(guī)則就能反復(fù)調(diào)用。連接器connector負責(zé)打通外部服務(wù)。經(jīng)常有人問 WorkBuddy 的連接器到底是什么其實就是一組現(xiàn)成的集成能力釘釘多維表、企業(yè)微信、文檔平臺、消息推送服務(wù)、數(shù)據(jù)庫等都能通過連接器接進來。一個典型的場景是每周一早上自動從釘釘多維表里拉取項目狀態(tài)經(jīng)過模型總結(jié)后推送到消息渠道。沒有連接器的話這一步需要自己寫腳本調(diào)接口而現(xiàn)在只要配置好授權(quán)和觸發(fā)規(guī)則即可。自定義指令則是行為規(guī)則層。它決定了智能體在什么場景下用什么語氣、按什么格式輸出、遇到邊界情況怎么處理。比如你可以規(guī)定“輸出報告時先給結(jié)論再給數(shù)據(jù)”也可以規(guī)定“默認使用中文專業(yè)術(shù)語保留英文原詞”。三個概念合在一起才構(gòu)成 WorkBuddy 和普通對話助手的本質(zhì)區(qū)別普通助手是一問一答WorkBuddy 是你自己搭的一個“數(shù)字員工”。2.2 和 CodeBuddy 到底有什么區(qū)別這個問題在社區(qū)里的熱度一直很高我在不同群里也被問過很多次。CodeBuddy 的側(cè)重點在代碼場景核心是代碼生成、補全、倉庫級上下文理解和開發(fā)流程輔助應(yīng)用場景基本集中在開發(fā)工具鏈里。WorkBuddy 的覆蓋面要寬得多它更關(guān)注工作流本身定時任務(wù)、消息推送、多表同步、業(yè)務(wù)數(shù)據(jù)處理、跨平臺連接器等等。舉個實際分工的例子我有個項目需要每天拉取業(yè)務(wù)數(shù)據(jù)、清洗后生成圖表描述再定時推送到工作群。代碼部分我會在 CodeBuddy 里寫數(shù)據(jù)處理和定時推送的流程編排則放在 WorkBuddy 里。兩者配合使用的體驗是CodeBuddy 負責(zé)“寫”WorkBuddy 負責(zé)“跑”。如果你只做純開發(fā)、不碰業(yè)務(wù)流轉(zhuǎn)那 CodeBuddy 可能已經(jīng)夠用但一旦你的工作里涉及大量跨平臺的信息同步、定時任務(wù)和重復(fù)文案處理WorkBuddy 的價值就會體現(xiàn)出來。它不是一個替代 CodeBuddy 的升級版而是一個不同維度的工具兩者互補。2.3 企業(yè)落地的配套從業(yè)者認證與團隊復(fù)用除了個人使用WorkBuddy 在企業(yè)方向上也有一些配套我注意到官方在這塊已經(jīng)有成體系的布局比如效率智能體的從業(yè)者認證。它的意義在于當(dāng)你想把工作臺方案從個人使用擴展到團隊或者作為服務(wù)交付給客戶時認證體系能提供一個相對標(biāo)準(zhǔn)的能力基線。不過我的建議是如果你是個人用戶前期不用太在意認證這件事先把 skill、連接器、自定義指令這三個核心概念玩明白。等你的工作臺方案真的穩(wěn)定跑了一陣子再考慮要不要往團隊復(fù)用和認證方向走。工具的價值在于先把流程跑通剩下的都是加分項。3. 從零把 WorkBuddy 跑起來含 Linux / 麒麟版注意事項3.1 下載安裝與基礎(chǔ)配置安裝這塊不復(fù)雜但有幾個細節(jié)值得注意。常規(guī)做法是去官方渠道下載對應(yīng)系統(tǒng)的安裝包Windows 和 macOS 的直接裝即可。這里要單獨說的是 Linux 環(huán)境尤其是國產(chǎn)麒麟系統(tǒng)的適配這兩個版本社區(qū)里問的人不少。如果你用的是 x86 架構(gòu)的 Linux 發(fā)行版直接下官方 Linux 包一般沒問題但運行時依賴需要自己確認一下。常見的缺庫問題大多集中在圖形界面組件上報錯的話補裝對應(yīng)依賴就行。麒麟版主要是兼容性適配建議優(yōu)先選擇官方針對該平臺發(fā)布的安裝包不要用通用包硬裝否則可能出現(xiàn)界面顯示異?；蛘卟糠止δ懿豢捎玫那闆r。首次啟動后先別急著用把三件事做掉登錄或注冊賬號、檢查客戶端版本是否為最新、確認一個專門的工作目錄。工作目錄這個概念很容易被新用戶忽略默認配置里會有一個以點號開頭的隱藏目錄很多人找不到自己的配置和技能文件其實就是被“目錄前面有個點”這種命名方式帶偏了。建議從第一天就把工作目錄建到顯眼位置后面排查問題會省很多力氣。3.2 在客戶端里啟用限免模型登錄之后在模型選擇區(qū)域應(yīng)該能看到當(dāng)前可用的模型列表。限免期間Hy4 preview 和 Hy3 都會有明確標(biāo)識直接選中即可。這里要提醒的是模型列表的顯示依賴客戶端版本如果你看不到對應(yīng)的限免模型優(yōu)先檢查是不是版本過舊升級到最新版再刷新。限免是否生效最直接的判斷方式是用一條帶明確結(jié)構(gòu)要求的指令測試比如讓它生成一份特定格式的周報然后觀察輸出質(zhì)量和響應(yīng)速度。另外我建議在啟用模型前先看清客戶端里關(guān)于額度的提示文字把限免模型當(dāng)生產(chǎn)模型全量跑很可能提前觸發(fā)限額。我在實際測試中遇到過一個問題切換模型后之前的會話上下文不會自動帶過去。如果你想讓 Hy4 preview 基于之前 Hy3 的對話繼續(xù)工作需要手動確認上下文繼承的方式。不同版本的交互入口不太一樣但邏輯是一樣的先確認上下文再繼續(xù)對話。這個細節(jié)官方文檔里寫得不明顯屬于實操中很容易忽略的點。3.3 本地模型與第三方模型的接入思路除了官方模型WorkBuddy 也支持接入 OpenAI 兼容接口這對喜歡自己折騰模型的人來說很實用。基本思路是在設(shè)置里找到模型服務(wù)配置填入 base URL 和 API Key然后新建一個自定義模型條目。這樣可以把 WorkBuddy 的 skill 和連接器能力與你自己選的模型結(jié)合起來用。關(guān)于本地模型很多人問千問這類開源模型本地部署后能不能接入 WorkBuddy答案是可以的官方也留了兼容接口。效果方面如果本地跑的是 8B 級別的量化模型日常文本整理、摘要生成、定時任務(wù)腳本這些場景表現(xiàn)夠用但復(fù)雜推理和長文檔理解跟官方大模型還有明顯差距。所以我的建議是本地模型適合處理隱私敏感或離線場景的簡單任務(wù)涉及到復(fù)雜理解和高質(zhì)量生成還是優(yōu)先用官方限免模型。接入步驟上先確認本地模型的推理服務(wù)已經(jīng)啟動并暴露了兼容接口然后在 WorkBuddy 自定義模型里填地址、密鑰和模型名稱即可。這里最容易踩的坑是 base URL 末尾的路徑寫不對不同推理框架要求的路徑不一樣一般以框架提供的文檔為準(zhǔn)填錯了會一直報連接失敗。4. 拿到限免模型后我建議你先試這幾件事4.1 定時發(fā)送微信消息把工作流搬到手機外很多人設(shè)置好模型后的第一件事是問“能怎么玩”我的建議是先做定時消息推送因為這是最快能感受到“工作臺”價值的功能。用連接器或定時任務(wù)配置能讓 WorkBuddy 在每天早上固定時間把日報、待辦、提醒消息推送到微信或類似的消息渠道。具體操作上先建一個定時任務(wù)指定要執(zhí)行的動作比如“總結(jié)昨天的進展并生成今日待辦”再綁定消息推送渠道。我第一次跑通這個功能的時候最大的感受不是“智能”而是“省心”——每天早上不用自己回憶昨天干了什么消息自己就來了。不過有一點要提醒定時任務(wù)依賴客戶端或服務(wù)端的持續(xù)運行如果你用的是本地客戶端記得保持它在后臺運行否則定時任務(wù)不會觸發(fā)。這個功能特別適合兩類人一類是每天要寫日報的同學(xué)一類是經(jīng)常漏掉待辦事項的朋友。把一個固定提示變成自動推送之后整個工作節(jié)奏會明顯不一樣。我自己現(xiàn)在每天早上的第一條待辦消息就是它推過來的已經(jīng)變成習(xí)慣了。4.2 釘釘多維表定期同步這類重復(fù)勞動交給skill釘釘多維表定期同步這個需求我在社區(qū)里看到過不少人在問說明它是一個真實且高頻的場景。我自己的測試場景是項目進度表放在多維表里每周有成員更新我需要每周一把變動同步到另一個匯總表里再做簡單分析。手動做的話每次大概10分鐘頻率一高就會覺得很煩。用 WorkBuddy 之后這套流程被拆成了兩步第一步通過連接器授權(quán)多維表的讀寫權(quán)限第二步建一個 skill 描述同步規(guī)則包括源表字段、目標(biāo)字段、去重邏輯、沖突處理方式。之后每次只要觸發(fā)這個 skill模型會按規(guī)則完成字段映射、內(nèi)容比對和增量同步。我實測下來簡單場景的同步準(zhǔn)確率是很高的但如果表結(jié)構(gòu)經(jīng)常變skill 里的映射規(guī)則可能需要跟著維護這是沒法完全避免的。這個場景其實是 WorkBuddy 最有代表性的用法它不是幫你“寫代碼實現(xiàn)同步”而是讓你用自然語言定義一條業(yè)務(wù)規(guī)則然后由智能體去執(zhí)行。對于不會寫腳本的同事來說門檻低很多這也是它能進入業(yè)務(wù)流程領(lǐng)域的核心原因。4.3 UI自動化和業(yè)務(wù)流程的簡單落地再往深一點走WorkBuddy 還能做 UI 自動化和業(yè)務(wù)流程編排。不少人在社區(qū)里問過怎么用 WorkBuddy 做 UI 自動化我理解主要指的是用它的自動化能力代替人去做重復(fù)的界面操作比如批量填寫表單、點擊按鈕、數(shù)據(jù)抓取。我的建議是從小處入手先選一個每天重復(fù)的界面操作把過程錄下來或?qū)懗芍噶钭屗€(wěn)定跑一周再說。不要一上來就搭一個橫跨十幾個步驟的大流程因為中間任何一步出問題排查成本都會很夸張。業(yè)務(wù)流程也是類似的邏輯我見過有人用 WorkBuddy 搭了一套從數(shù)據(jù)收集、清洗、匯總到生成報告的完整流程非常漂亮但那是建立在前期把每個小環(huán)節(jié)都驗證過的基礎(chǔ)上的。從行業(yè)角度看WorkBuddy 在建筑、基金這類垂直場景里也有實際案例。建筑行業(yè)可以用它做材料清單整理和進度信息匯總基金相關(guān)場景可以做凈值數(shù)據(jù)和公告的結(jié)構(gòu)化整理。這些本質(zhì)上都是“數(shù)據(jù)獲取 結(jié)構(gòu)化輸出 定期執(zhí)行”的組合恰好是 WorkBuddy 擅長的區(qū)域。如果你所在的行業(yè)也有這種固定流程完全可以參照這個思路來搭。5. 我實際測試后的一些提醒和參數(shù)建議5.1 限免到期判斷與切換策略限免到期這件事客戶端一般會有提示但提示不一定顯眼。我建議不要等系統(tǒng)提示自己在日歷上設(shè)個提醒Hy4 preview 兩周窗口到期前三天做一次集中測試的收尾9月底前一周再檢查一次 Hy3 相關(guān)的定時任務(wù)是否正常。等到活動結(jié)束才想起來很有可能被打個措手不及。切換策略上我堅持一個原則工作流不綁死單一模型。具體做法是在 skill 和定時任務(wù)的配置里盡量用模型無關(guān)的描述比如“把這段文字按優(yōu)先級整理成清單”而不是依賴某個模型的特殊格式指令。這樣即使限免結(jié)束后模型策略調(diào)整最多只影響輸出風(fēng)格不會讓整個工作臺癱瘓。5.2 skill/連接器使用中的常見坑第一個坑是權(quán)限范圍。連接器授權(quán)時默認拿到的權(quán)限可能比你預(yù)想的大也可能比預(yù)想的小。大權(quán)限意味著安全性風(fēng)險小權(quán)限則可能導(dǎo)致同步任務(wù)執(zhí)行到一半報錯。我建議每個連接器在配置完成后先用一條最小指令測試讀寫邊界確認它只能訪問該訪問的內(nèi)容再放開正式任務(wù)。第二個坑是版本匹配。客戶端升級后個別第三方 skill 或插件可能因為接口變化而失效現(xiàn)象是調(diào)用時報錯或者靜默失敗。遇到這種情況別急著懷疑模型的錯先看 skill 或插件的版本是否兼容當(dāng)前客戶端版本大部分問題都是這里出來的。第三個坑是上下文污染。同一個工作區(qū)里如果配置了多個自定義指令指令之間可能互相影響。比如一條指令規(guī)定“回答盡量簡短”另一條規(guī)定“輸出必須包含完整說明”同時生效時模型行為會變得不可控。我的建議是全局指令只放通用規(guī)則場景化規(guī)則放到 skill 內(nèi)部縮小生效范圍。5.3 自定義指令的幾條推薦寫法最后分享幾條我自用的自定義指令寫法都屬于“直接抄就能用”的級別。第一條是角色前置比如“你是一名項目經(jīng)理助理負責(zé)把零散信息整理成結(jié)構(gòu)化任務(wù)清單”角色確定后模型后續(xù)輸出會穩(wěn)定很多。第二條是格式約束比如“所有輸出必須以 Markdown 列表呈現(xiàn)每項不超過一行”這類約束能有效防止模型自由發(fā)揮。第三條是兜底指令比如“如果信息不足請明確列出缺失項不要猜測”這條對自動化任務(wù)尤其重要能顯著減少“一本正經(jīng)編數(shù)據(jù)”的情況。參數(shù)方面如果客戶端暴露了溫度、最大輸出長度等選項我的經(jīng)驗值是事實整理類任務(wù)溫度調(diào)低到 0.3 左右創(chuàng)意生成類任務(wù)可以調(diào)到 0.7 到 0.8。最大輸出長度要看具體場景周報建議給足 2000 字消息推送類指令給 500 字以內(nèi)就夠了避免模型為了湊字數(shù)輸出一堆廢話。這些參數(shù)不一定要照搬但可以作為你調(diào)試時的起點。