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