我大概花了兩周時(shí)間做了一個(gè)叫“魔力工作臺(tái)”的開源項(xiàng)目本質(zhì)上是想給 workbuddy 這類偏閉源、偏重量的 AI 工作臺(tái)工具提供一個(gè)更輕、更可控、也更符合我自己使用習(xí)慣的替代方案。說(shuō)實(shí)話最初只是自己在用后來(lái)發(fā)現(xiàn)身邊不少同事也在折騰類似的東西就順手把代碼整理了一下放了出來(lái)。沒想到反響比我預(yù)期好不少GitHub 上已經(jīng)有不少人 star 和提 issue 了。這個(gè)項(xiàng)目不是簡(jiǎn)單地“仿一個(gè) workbuddy”而是重新思考了“AI 編程工作臺(tái)”到底應(yīng)該長(zhǎng)什么樣。它不是一個(gè) IDE 插件也不是一個(gè)聊天機(jī)器人外殼而是一個(gè)介于 AI Agent、任務(wù)編排、知識(shí)管理這三者之間的工作臺(tái)框架。如果你平時(shí)用 Cursor、CodeBuddy、WorkBuddy 這類工具但又覺得它們太重、太黑盒、或者功能綁得太死那我這篇東西應(yīng)該能給你一些完全不同的思路。1. 為什么我不直接用 workbuddy而要自己造一個(gè)輪子先說(shuō)說(shuō)我的真實(shí)處境。我之前是 workbuddy 的重度用戶用它的 skill 機(jī)制做代碼生成、做項(xiàng)目腳手架、甚至做文檔管理剛開始確實(shí)覺得挺驚艷但用著用著就發(fā)現(xiàn)幾個(gè)繞不開的問題。第一個(gè)問題是定制成本太高。workbuddy 的核心邏輯是跑在它自己的運(yùn)行時(shí)里你想改一個(gè)底層行為往往只能通過寫 skill 去“繞”一旦 skill 寫得多了整個(gè)系統(tǒng)就像在沙子上蓋房子牽一發(fā)而動(dòng)全身。我有一段時(shí)間光維護(hù)自己的 skill 集合就花了很多精力這完全偏離了“用工具省時(shí)間”的初衷。第二個(gè)問題是數(shù)據(jù)不透明。我的對(duì)話歷史、上下文、甚至代碼片段都存儲(chǔ)在它的私有格式里想要導(dǎo)出到別的地方或者自己做個(gè)數(shù)據(jù)分析幾乎不可能。作為一個(gè)習(xí)慣 everything as text 的人這種封閉性是很難接受的。第三個(gè)問題也是最直接的導(dǎo)火索是它越來(lái)越重。裝一個(gè)工作臺(tái)動(dòng)輒幾百 MB啟動(dòng)還慢而且很多功能我根本用不到。我需要的其實(shí)是一個(gè)足夠輕的骨架然后我把自己的工具鏈、模型接口、知識(shí)庫(kù)都掛進(jìn)去就像搭積木一樣而不是別人把積木拼好了再讓我用錘子砸開重拼。所以“魔力工作臺(tái)”最初的定位就一句話一個(gè)以本地優(yōu)先、文本優(yōu)先、可自由替換各組件、能跑通 AI 編程全流程的最小化工作臺(tái)骨架。這個(gè)定位決定了后續(xù)所有的技術(shù)選型和架構(gòu)設(shè)計(jì)。后面我會(huì)逐個(gè)拆。2. 整體架構(gòu)和設(shè)計(jì)思路——它是怎么做到“輕”的2.1 核心設(shè)計(jì)原則一切皆文件這是我整個(gè)項(xiàng)目最核心的一條原則。魔力工作臺(tái)不搞私有格式不搞數(shù)據(jù)庫(kù)存儲(chǔ)所有的配置、上下文、技能、任務(wù)狀態(tài)全部是純文本文件用 Markdown、JSON、YAML 來(lái)承載。這樣做帶來(lái)的直接好處是你可以用 grep 搜配置用 git 管歷史用任何編輯器改內(nèi)容甚至寫一段 Python 腳本就能批量處理自己的任務(wù)記錄。這套思路和 Emacs 的 org-mode 理念類似但實(shí)現(xiàn)起來(lái)更輕。舉個(gè)例子一個(gè) skill也就是工作臺(tái)里的一個(gè)技能在 workbuddy 里可能是一個(gè)需要安裝的插件包但在我這里就是一個(gè)目錄skills/ ├── code-review/ │ ├── SKILL.md # 技能說(shuō)明包含觸發(fā)條件和執(zhí)行邏輯 │ ├── templates/ │ │ └── review.md # 輸出模板 │ └── hooks/ │ └── post-run.sh # 執(zhí)行完可以跑的輔助腳本這意味著什么意味著你分享一個(gè)技能只需要發(fā)一個(gè)目錄你備份整個(gè)工作臺(tái)只需要git push。對(duì)于一個(gè)開發(fā)者工具來(lái)說(shuō)這種透明感能帶來(lái)極大的安全感和可控性。2.2 插拔式運(yùn)行時(shí)模型和后端可以隨便換現(xiàn)在的 AI 工具基本都綁定了自己的模型通道但我的想法是模型本身不應(yīng)該和工作臺(tái)強(qiáng)耦合。魔力工作臺(tái)的運(yùn)行時(shí)層做了一個(gè)抽象所有模型的調(diào)用都走同一個(gè)接口不管你是用 OpenAI 兼容接口、本地跑 Ollama、還是接公司內(nèi)部的模型網(wǎng)關(guān)都只需要改一個(gè)配置文件。# config/llm.yaml provider: openai_compatible base_url: http://localhost:11434/v1 model: qwen2.5-coder:14b temperature: 0.3 max_tokens: 8192這個(gè)配置的意義在于你可以為不同任務(wù)配置不同的模型。寫代碼用代碼模型做總結(jié)用通用模型做 OCR 用多模態(tài)模型它們之間通過工作臺(tái)的任務(wù)路由自動(dòng)分發(fā)。這比在一個(gè)模型里反復(fù)切換要高效得多。有人可能說(shuō)這不就是搞了個(gè)模型聚合網(wǎng)關(guān)嗎對(duì)本質(zhì)上就是這個(gè)思路但區(qū)別在于我把它做成了工作臺(tái)的內(nèi)置能力而不是一個(gè)獨(dú)立服務(wù)所以部署成本幾乎為零。2.3 Agent 編排從“聊天”升級(jí)為“流水線”用過 workbuddy 的應(yīng)該知道它的 agent 能力更像是一個(gè)“加強(qiáng)版聊天框”你給它一個(gè)任務(wù)它自己決定怎么拆解步驟并執(zhí)行。但問題在于它不擅長(zhǎng)多任務(wù)并行和狀態(tài)維護(hù)。魔力工作臺(tái)引入了一個(gè)“任務(wù)流水線”的概念。每個(gè)任務(wù)可以拆成多個(gè)步驟步驟之間支持串行、并行、條件分支三種結(jié)構(gòu)。步驟的輸出會(huì)緩存成中間文件后續(xù)步驟可以直接引用而不需要整個(gè)任務(wù)重新跑。下面這個(gè)例子是一條完整的“從需求到代碼到測(cè)試”的流水線定義# workflows/feature.yml name: feature-dev steps: - id: parse-req type: llm prompt_file: prompts/parse-req.md output: output/req.md - id: gen-code type: llm prompt_file: prompts/gen-code.md input: output/req.md output: output/code.diff - id: run-tests type: shell command: pytest tests/ -q depends_on: gen-code這樣做的好處是每一步都可見、可重跑、可單獨(dú)調(diào)試而不是靠模型自己“隨緣”執(zhí)行。對(duì)于生產(chǎn)環(huán)境的使用這種確定性非常重要。3. 核心功能拆解——每個(gè)模塊解決什么實(shí)際問題3.1 Skill 系統(tǒng)技能不是插件是“方法論封裝”Skill 這個(gè)詞被 workbuddy 帶火了但很多人的理解還停留在“一個(gè) prompt 模板”。我覺得 skill 應(yīng)該解決的是一個(gè)問題如何把一個(gè)人的生產(chǎn)流程變成另一個(gè)人可以直接調(diào)用的工具。在魔力工作臺(tái)里一個(gè) skill 由三部分組成第一部分是說(shuō)明文件 SKILL.md描述這個(gè)技能解決什么問題、觸發(fā)條件是什么、需要什么輸入。這個(gè)說(shuō)明文件同時(shí)也是模型理解技能的入口相當(dāng)于一個(gè) function calling 的說(shuō)明書。第二部分是模板和對(duì)齊說(shuō)明決定了輸出的格式。比如代碼審查技能我內(nèi)置了“問題嚴(yán)重程度 → 對(duì)應(yīng)行號(hào) → 修改建議 → 代碼示例”的輸出模板這樣模型每次輸出都是結(jié)構(gòu)化的結(jié)果直接可以接后續(xù)自動(dòng)化流程。第三部分是輔助腳本 hook。比如代碼生成技能跑完之后自動(dòng)觸發(fā)一個(gè) git diff 統(tǒng)計(jì)腳本告訴你這次生成改了多少行、新增了什么。這個(gè)腳本是用戶自己寫的自由度極高。我在項(xiàng)目里提供了幾個(gè)開箱即用的 skill 作為示例包括代碼審查、技術(shù)方案生成、README 生成、SQL 優(yōu)化建議、API 文檔抽取。它們的設(shè)計(jì)目標(biāo)都是“短小精悍”讓用戶可以很快讀懂然后改造成自己的東西。3.2 上下文管理讓 AI 記住該記住的忘掉該忘掉的這是很多 AI 工具做得很爛的地方。上下文窗口越來(lái)越大沒錯(cuò)但不代表你應(yīng)該什么都往里面塞。魔力工作臺(tái)做了一個(gè)“上下文分層”的機(jī)制。第一層是項(xiàng)目級(jí)上下文存在項(xiàng)目根目錄的.magic/context.yml里包括項(xiàng)目結(jié)構(gòu)說(shuō)明、技術(shù)棧、編碼規(guī)范等。這一層相對(duì)靜態(tài)每次會(huì)話加載一次。第二層是會(huì)話級(jí)上下文存在于當(dāng)前對(duì)話的 session 文件中記錄的是本次任務(wù)中產(chǎn)生的關(guān)鍵決策和中間結(jié)果。會(huì)話結(jié)束時(shí)可以選擇是否寫回項(xiàng)目級(jí)上下文。第三層是“臨時(shí)記憶”只存在于單個(gè)步驟中步驟結(jié)束后就清空避免無(wú)用的信息污染后續(xù)流程。這樣做的一個(gè)直接效果是模型的 token 利用率大幅提升。我做過一個(gè)簡(jiǎn)單實(shí)驗(yàn)同樣一個(gè)代碼生成任務(wù)裸寫 prompt 一次要消耗大約 12k token用上下文分層之后只要 6k而且輸出準(zhǔn)確率明顯更高。3.3 緩存與增量省錢的核心武器如果你是重度 API 用戶一定會(huì)懂 chat 類工具的 token 消耗有多快。魔力工作臺(tái)做了兩層緩存來(lái)緩解這個(gè)問題。第一層是請(qǐng)求級(jí)緩存相同的 prompt、相同的模型參數(shù)在有效期內(nèi)直接命中緩存不再發(fā)起網(wǎng)絡(luò)請(qǐng)求。這個(gè)對(duì)于“調(diào)整業(yè)務(wù)代碼但 prompt 模板沒變”的場(chǎng)景尤其管用。第二層是步驟級(jí)緩存流水線里某個(gè)步驟的輸入沒有變化時(shí)直接復(fù)用上一次的輸出不重新執(zhí)行模型調(diào)用?，F(xiàn)在項(xiàng)目里跑一次完整的需求開發(fā)流水線大約 40% 的 token 消耗能被緩存抵消。我知道很多服務(wù)端框架都有這個(gè)機(jī)制但在本地 AI 工作臺(tái)里做這么細(xì)的緩存目前確實(shí)還比較少見。4. 從零開始搭建20 分鐘跑起來(lái)的完整流程4.1 環(huán)境準(zhǔn)備與安裝項(xiàng)目目前支持 macOS 和 LinuxWindows 可以通過 WSL 的方式跑。依賴也很簡(jiǎn)單只需要 Python 3.10 和 Node.js 18后面有些工具鏈需要。安裝方式我做了盡量簡(jiǎn)化git clone https://github.com/yourname/magic-workbench.git cd magic-workbench pip install -r requirements.txt cp config/llm.yaml.example config/llm.yaml然后編輯config/llm.yaml填上你的模型接口地址和密鑰。如果你有本地跑 Ollama直接填http://localhost:11434/v1就能通。這是我認(rèn)為這個(gè)項(xiàng)目體驗(yàn)比較好的地方不需要安裝龐大的桌面應(yīng)用不需要注冊(cè)賬號(hào)不需要復(fù)雜的初始化引導(dǎo)一個(gè)終端 一個(gè)編輯器就能干活。4.2 初始化一個(gè)項(xiàng)目工作臺(tái)魔力工作臺(tái)是面向“項(xiàng)目”維度的。進(jìn)入任何一個(gè)項(xiàng)目目錄后執(zhí)行magic init它會(huì)在當(dāng)前目錄生成.magic文件夾里面包含默認(rèn)的配置文件、技能目錄、工作流目錄。然后執(zhí)行magic scan它會(huì)掃描你的代碼倉(cāng)庫(kù)結(jié)構(gòu)自動(dòng)生成一個(gè)project_context.md這個(gè)文件就是前面提到的項(xiàng)目級(jí)上下文的底稿。你還可以手動(dòng)補(bǔ)充編碼規(guī)范、模塊說(shuō)明進(jìn)去這些信息會(huì)拼進(jìn)每次 prompt 的 system message 開頭。實(shí)際用下來(lái)的感覺是這個(gè)scan環(huán)節(jié)特別值得花點(diǎn)心思做完整。項(xiàng)目上下文寫得越清晰模型生成代碼和回答問題的準(zhǔn)確率提升得越明顯。我甚至見過有人把整個(gè)架構(gòu)文檔都精簡(jiǎn)后塞進(jìn)去效果確實(shí)不一樣。4.3 跑通第一個(gè)任務(wù)安裝配置完成后官方倉(cāng)庫(kù)里自帶了一個(gè)示例技能叫doc-generator作用是自動(dòng)給代碼文件生成文檔。用法很簡(jiǎn)單magic run doc-generator --input src/main.py內(nèi)部執(zhí)行流程是這樣的讀取文件內(nèi)容 → 讀取項(xiàng)目上下文 → 拼 prompt → 調(diào)用配置好的模型 → 按模板輸出文檔 → 自動(dòng)寫入同目錄下的main.py.md。這一步跑通了說(shuō)明整個(gè)鏈路沒問題。從此你就有了一個(gè)完全屬于自己掌控的 AI 工作臺(tái)。5. 實(shí)際使用場(chǎng)景和效果——它到底解決了什么具體問題5.1 場(chǎng)景一日常代碼開發(fā)我現(xiàn)在的主力開發(fā)模式已經(jīng)完全切換到魔力工作臺(tái)上了。比如接到一個(gè)需求“給訂單模塊增加導(dǎo)出 Excel 的功能”我的做法是先在項(xiàng)目根目錄寫一個(gè)簡(jiǎn)單的需求描述文件req.md然后用magic plan命令讓它生成一份技術(shù)方案。方案生成后我會(huì)自己過一遍把不合理的部分改掉再讓它根據(jù)方案生成代碼 diff最后手動(dòng) review 一遍合入。這套流程下來(lái)大概比之前直接打開 AI 聊天工具來(lái)回粘貼要高效 30% 以上。因?yàn)槊恳徊降纳舷挛亩际亲詣?dòng)從倉(cāng)庫(kù)里讀的不需要我手動(dòng)把整個(gè)文件內(nèi)容貼進(jìn)去。5.2 場(chǎng)景二代碼審查團(tuán)隊(duì)里現(xiàn)在用我做的code-reviewskill 來(lái)做 MR 前的自檢。它能識(shí)別出的問題包括但不限于邏輯分支覆蓋不全、異常處理缺失、SQL 注入風(fēng)險(xiǎn)、重復(fù)代碼、資源未釋放等。我自己實(shí)測(cè)的準(zhǔn)確率大約在八成左右關(guān)鍵是它能保持穩(wěn)定的輸出格式直接接到后續(xù)的標(biāo)簽系統(tǒng)里。這個(gè)技能也成了倉(cāng)庫(kù)里被 fork 最多的一份代碼。5.3 場(chǎng)景三舊項(xiàng)目接手維護(hù)接手一個(gè)沒文檔的老項(xiàng)目是最痛苦的。魔力工作臺(tái)在這里最大的價(jià)值是能自動(dòng)生成“項(xiàng)目地圖”。它會(huì)遍歷代碼目錄理解模塊之間的依賴關(guān)系生成一份結(jié)構(gòu)化的說(shuō)明文件。以前要花兩三天捋清的東西現(xiàn)在大概一上午就能出個(gè)七八成。剩下的細(xì)節(jié)再靠 human in the loop 去驗(yàn)證和補(bǔ)充。這不是什么魔術(shù)本質(zhì)上就是把“讀代碼”這個(gè)體力活外包給了模型但效果確實(shí)驚人地好。6. 踩坑記錄和避坑指南——希望你別重走我的彎路6.1 不要把所有東西都交給模型決策我早期版本的流水線是“全自動(dòng)”的模型自己決定要改哪些文件、怎么改、要不要跑測(cè)試。后來(lái)發(fā)現(xiàn)這種模式在簡(jiǎn)單項(xiàng)目上表現(xiàn)得很好但到了復(fù)雜項(xiàng)目上就開始失控會(huì)出現(xiàn)“看起來(lái)很合理但實(shí)際上完全錯(cuò)誤”的操作?，F(xiàn)在的設(shè)計(jì)改成了“半步自動(dòng)”模型生成建議人工確認(rèn)后執(zhí)行。這可能不夠“AI 原生”但更可靠。真實(shí)工程不是 demo穩(wěn)定大于炫技。6.2 技能數(shù)量不是越多越好我一度在倉(cāng)庫(kù)里塞了幾十個(gè) skill結(jié)果維護(hù)成本巨大而且模型在面對(duì)一大堆技能時(shí)選擇困難癥會(huì)被放大經(jīng)常選錯(cuò)技能?，F(xiàn)在的做法是保持默認(rèn)只有六七個(gè)核心技能其余的都放到skills/contrib/目錄按需手動(dòng)添加。這也是一個(gè)很實(shí)用的工程化思路降低默認(rèn)復(fù)雜度保持?jǐn)U展性。6.3 緩存失效是一個(gè)容易忽略的坑前面我說(shuō)緩存能省錢但緩存設(shè)計(jì)不好也會(huì)坑人。典型的問題是代碼文件變了但 prompt 里沒有體現(xiàn)這個(gè)變化導(dǎo)致緩存命中后輸出的內(nèi)容是過時(shí)的。解法是構(gòu)建輸入指紋。魔力工作臺(tái)對(duì)每個(gè)步驟的所有輸入文件做一個(gè)哈希任何一個(gè)文件內(nèi)容變了緩存自動(dòng)失效。這個(gè)機(jī)制已經(jīng)內(nèi)置但如果你自己寫擴(kuò)展模塊時(shí)偷懶沒有接入指紋系統(tǒng)就會(huì)踩坑。6.4 模型選擇的建議如果你只是玩一玩本地用 Ollama 跑一個(gè) 7B~14B 的代碼模型就夠了。但如果要正經(jīng)做生產(chǎn)環(huán)境的代碼生成還是建議用商用 API 的大參數(shù)模型尤其是在復(fù)雜邏輯和長(zhǎng)上下文的場(chǎng)景兩者的差距非常明顯。我的個(gè)人配置是代碼生成主用更大的模型文本總結(jié)和輔助分析走本地小模型兩者搭配覆蓋率最合適。7. 路線圖和我接下來(lái)的計(jì)劃這個(gè)項(xiàng)目我打算長(zhǎng)期維護(hù)下去。目前已經(jīng)在做的方向有幾個(gè)一個(gè)是把前端交互做成 Web 界面讓不習(xí)慣命令行的人也能用一個(gè)是更好的多項(xiàng)目支持正在做項(xiàng)目之間技能和上下文的共享機(jī)制還有一個(gè)是想接更多類型的執(zhí)行后端比如本地 Docker 沙箱讓模型生成的代碼可以在隔離環(huán)境里自動(dòng)跑測(cè)試。說(shuō)實(shí)話這個(gè)項(xiàng)目能引來(lái)多少關(guān)注我沒有特別在意我更開心的是看到有一些人把它用在了自己的實(shí)際工作流里還在 issue 區(qū)分享了他們寫的技能。開源項(xiàng)目最有意思的地方就在這里你搭一個(gè)腳手架然后別人在上面蓋出你完全沒想到的房子。如果你也想折騰一個(gè)自己的 AI 工作臺(tái)或者只是想找一份足夠清爽的工作臺(tái)骨架不妨去倉(cāng)庫(kù)里瞄一眼用不用再說(shuō)參考一下思路也是好的。