做 DeepSeek Harness 插件開發(fā)這個方向我是從一系列尷尬時刻開始的。團(tuán)隊把 Harness 部署到內(nèi)網(wǎng)之后發(fā)現(xiàn)官方自帶能力根本喂不飽業(yè)務(wù)需求模型輸出要按公司規(guī)范定制格式、代碼審查要對接內(nèi)部評審流程、幾個高頻操作想一鍵觸發(fā)。翻遍官方文檔插件機(jī)制是唯一能走通的路但針對新手的中文教程幾乎為零只能對著 SDK 源碼和示例工程硬啃?，F(xiàn)在我把自己踩過的坑、總結(jié)出的套路、沉淀下來的排查清單全部攤開講。這篇文章適合已經(jīng)裝好 DeepSeek Harness、想用插件解決實際問題但不知從哪下手的同學(xué)也適合準(zhǔn)備在 Linux 服務(wù)器或離線局域網(wǎng)環(huán)境里深度使用 Harness 的團(tuán)隊參考。我盡量不用晦澀詞該上的代碼和配置直接給。1. 先搞懂 DeepSeek Harness 插件體系再談寫代碼1.1 插件機(jī)制到底解決了什么問題DeepSeek Harness 本質(zhì)上是一個面向 AI 編碼和任務(wù)自動化的執(zhí)行框架模型負(fù)責(zé)理解與生成Harness 負(fù)責(zé)把模型能力接到真實工作流里。但工作流千差萬別官方不可能內(nèi)置所有場景于是插件體系就成了連接點(diǎn)和擴(kuò)展點(diǎn)。我自己的理解是可以把 Harness 當(dāng)作一個操作系統(tǒng)插件就是上面跑的應(yīng)用程序。沒有插件Harness 就是一套固定的對話和代碼補(bǔ)全工具有了插件它可以變成你的團(tuán)隊專屬的代碼審查機(jī)器人、內(nèi)部文檔生成器、運(yùn)維命令執(zhí)行網(wǎng)關(guān)。這跟 VS Code 有擴(kuò)展市場、Chrome 有擴(kuò)展商店是同一個邏輯。很多人剛開始有個誤區(qū)以為插件開發(fā)是給 Harness 裝別人寫好的東西自己不用寫。實際上團(tuán)隊落地過程中真正好用的工具絕大多數(shù)是圍繞內(nèi)部流程寫的私有插件。這件事繞不過去早學(xué)早省事。1.2 三種插件形態(tài)本體插件、IDE 插件、瀏覽器插件DeepSeek Harness 的插件開發(fā)熱度一直很高但從搜索詞來看大量新手把三種完全不同的插件混在一起問。這里先做個明確區(qū)分。插件形態(tài)運(yùn)行位置主要用途開發(fā)語言典型場景本體插件Harness 進(jìn)程內(nèi)部增強(qiáng)模型能力、接入工具鏈Python / TypeScript自定義命令、提示詞優(yōu)化、代碼回退檢查IDEA 插件JetBrains IDE 內(nèi)編輯器與 Harness 交互Java / Kotlin代碼審查面板、一鍵提交、斷點(diǎn)聯(lián)動Chrome 插件瀏覽器內(nèi)抓取頁面上下文喂給模型JavaScript前端 bug 分析、頁面截圖、控制臺日志采集三者不是競爭關(guān)系而是配合關(guān)系。我團(tuán)隊的常用組合是本體插件處理核心邏輯Chrome 插件抓取線上頁面報錯IDEA 插件負(fù)責(zé)本地代碼上下文注入。開發(fā)難度上本體插件最低Chrome 插件次之IDEA 插件最高。如果你是第一次接觸強(qiáng)烈建議從本體插件入手先把 Harness 自身的能力摸透再往 IDE 方向擴(kuò)展。1.3 插件的生命周期和運(yùn)行機(jī)制任何插件框架都有生命周期概念DeepSeek Harness 也不例外。理解生命周期調(diào)試問題會快很多。一個本體插件從加載到卸載大致經(jīng)歷五個階段加載Harness 啟動時掃描插件目錄讀取 manifest 配置做依賴檢查。注冊插件向 Harness 注冊自己監(jiān)聽的事件和提供的命令。激活當(dāng)插件對應(yīng)的事件觸發(fā)或被用戶顯式調(diào)用時Harness 調(diào)用插件的 activate 入口。執(zhí)行插件核心邏輯運(yùn)行調(diào)用 SDK 提供的上下文對象和外部能力。卸載Harness 關(guān)閉或插件被禁用時調(diào)用 deactivate 做資源清理。新手最容易忽略的是第 2 步和第 5 步。注冊階段如果事件名寫錯插件不會報錯只是永遠(yuǎn)不觸發(fā)排查起來非常隱蔽卸載階段不釋放文件句柄或定時器在 Windows 上經(jīng)常引發(fā)后續(xù)的文件鎖定和權(quán)限問題。我現(xiàn)在寫插件第一步永遠(yuǎn)是先畫清楚哪個事件觸發(fā)哪段邏輯再動手寫代碼。2. 開發(fā)環(huán)境準(zhǔn)備與插件骨架搭建2.1 環(huán)境清單與版本選擇開發(fā) DeepSeek Harness 插件我建議的環(huán)境配置如下操作系統(tǒng)Windows 10/11、Ubuntu 20.04、macOS 12 均可但部署到內(nèi)網(wǎng)服務(wù)器優(yōu)先選 Linux。運(yùn)行時Node.js 18TS 插件必需、Python 3.10Python 插件必需。如果兩個都裝建議用 nvm 和 pyenv 管理版本避免系統(tǒng)級沖突。Harness 版本優(yōu)先使用與目標(biāo)部署環(huán)境一致的版本。開發(fā)時用最新版部署前在目標(biāo)服務(wù)器上跑一遍兼容性測試。SDKHarness 官方提供的 Python SDK 或 TypeScript SDK安裝命令一般是pip install deepseek-harness-sdk或npm install deepseek/harness-sdk。版本選擇上有兩個很實在的建議。第一個不要在生產(chǎn)環(huán)境用最新版 Harness插件 API 在版本升級中偶有破壞性變更我的經(jīng)驗是生產(chǎn)環(huán)境鎖定次新版本開發(fā)環(huán)境跟隨最新版。第二個SDK 和 Harness 主程序的版本必須匹配否則經(jīng)常出現(xiàn)API 不存在這類似是而非的報錯。2.2 用官方腳手架創(chuàng)建插件工程我見過太多人一上來就手寫目錄結(jié)構(gòu)和配置文件結(jié)果連最基本的事件鉤子都寫錯位置。正確做法是使用官方腳手架。# 安裝 CLI 工具 npm install -g deepseek/harness-cli # 初始化插件工程 harness plugin init my-first-plugin --lang python # 進(jìn)入目錄并安裝依賴 cd my-first-plugin pip install -r requirements.txt腳手架生成的結(jié)構(gòu)大致如下my-first-plugin/ ├── manifest.yaml # 插件元數(shù)據(jù)最重要的文件 ├── plugin.py # 插件主入口 ├── requirements.txt # Python 依賴 ├── tests/ # 測試目錄 │ └── test_plugin.py └── README.md這里有個細(xì)節(jié)manifest.yaml 的文件名不要隨意改Harness 掃描插件目錄時按固定文件名識別。曾有個同事把 manifest 改名成 config.yaml插件怎么裝都裝不上排查了半小時。2.3 插件配置文件逐項解讀manifest.yaml 是插件的身份證我直接貼一個最小可用配置name: my-first-plugin version: 0.1.0 description: 我的第一個 Harness 插件 author: your-name runtime: python entry: plugin.py hooks: - event: on_user_message handler: handle_user_message - event: on_command handler: handle_command commands: - name: /hello description: 測試命令返回問候語 handler: cmd_hello permissions: - read: workspace - write: temp逐項解釋關(guān)鍵字段runtime聲明插件運(yùn)行環(huán)境是 python 還是 node。寫錯會導(dǎo)致 Harness 用錯誤的解釋器去跑報錯信息還不明顯。entry插件入口文件Harness 啟動時會加載這個文件。hooks事件鉤子數(shù)組每個鉤子綁定一個事件名和一個處理函數(shù)。事件名必須以官方 SDK 文檔為準(zhǔn)不同 Harness 版本支持的鉤子集合有差異。commands注冊斜杠命令。用戶輸入/hello時觸發(fā)對應(yīng) handler。permissions插件需要申請的能力范圍。這里有個硬性要求插件讀工作區(qū)文件前必須聲明read: workspace否則運(yùn)行時會直接被拒絕訪問。這個設(shè)計是為了安全但新手經(jīng)常忽略后面啟動時報權(quán)限錯誤一臉懵。3. 手寫第一個實用插件代碼審查助手3.1 插件需求與接口設(shè)計光講概念沒用直接帶大家寫一個真實能用的插件。我選擇代碼審查助手作為示例因為這是搜索熱詞里出現(xiàn)頻率最高的場景也是團(tuán)隊落地時幾乎必做的功能。需求定義如下當(dāng)用戶發(fā)起/review命令并附帶文件路徑時插件讀取該文件的 diff 或完整內(nèi)容調(diào)用 Harness 內(nèi)置的模型接口做靜態(tài)審查輸出問題清單、風(fēng)險等級和修改建議。接口設(shè)計上插件需要三個能力接收命令參數(shù)解析文件路徑。通過 SDK 的文件 API 讀取工作區(qū)內(nèi)容。調(diào)用模型服務(wù)并把審查結(jié)果以結(jié)構(gòu)化消息回傳給用戶。這里我要特別說一句不要把模型 API 地址硬編碼在插件里。Harness 提供了模型調(diào)用抽象層插件直接通過 SDK 調(diào)用即可具體走哪個模型由 Harness 全局配置決定。這樣插件在離線局域網(wǎng)環(huán)境、接入內(nèi)部模型服務(wù)的情況下也能正常工作。3.2 核心代碼實現(xiàn)下面是 plugin.py 的核心代碼我做了必要的精簡但保留完整邏輯import re from harness_sdk import ( HarnessPlugin, event_handler, command_handler, FileSystem, ModelClient, ) class ReviewPlugin(HarnessPlugin): command_handler(review) def cmd_review(self, context, args): 處理 /review file_path 命令 if not args: return context.reply(用法: /review 文件路徑) file_path args.strip() # 校驗路徑安全性防止目錄穿越 if .. in file_path: return context.reply(錯誤: 路徑中包含非法字符) try: content FileSystem.read_workspace_file(file_path) except PermissionError: return context.reply(f錯誤: 無權(quán)讀取 {file_path}請在 manifest 中聲明 read: workspace 權(quán)限) except FileNotFoundError: return context.reply(f錯誤: 文件不存在 {file_path}) # 調(diào)用模型做代碼審查 prompt self._build_review_prompt(file_path, content) result ModelClient.chat( messages[{role: user, content: prompt}], max_tokens2048, temperature0.2, ) review_text result[content] summary self._parse_risk_levels(review_text) return context.reply(self._format_output(file_path, summary, review_text)) event_handler(on_user_message) def handle_message(self, context, message): 監(jiān)聽用戶消息識別內(nèi)置代碼片段并自動提示 if message.startswith() and not message.startswith(review): return context.reply(檢測到代碼塊試試用 /review 文件路徑 做一次代碼審查) return None def _build_review_prompt(self, file_path, content): return f請對以下代碼進(jìn)行審查按嚴(yán)重程度分級輸出問題列表包括 1. 潛在 bugP0 2. 安全性問題P1 3. 代碼規(guī)范和性能問題P2 每個問題需要給出行號范圍、問題描述、修復(fù)建議。 文件名: {file_path} 代碼: {content[:12000]} def _parse_risk_levels(self, text): levels {P0: 0, P1: 0, P2: 0} for level in levels: levels[level] len(re.findall(rf\b{level}\b, text)) return levels def _format_output(self, file_path, summary, review_text): header f### 代碼審查報告: {file_path}\n summary_line f問題統(tǒng)計: P0{summary[P0]}, P1{summary[P1]}, P2{summary[P2]}\n return header summary_line \n review_text幾個實現(xiàn)要點(diǎn)供參考路徑安全校驗是必做的Harness 插件運(yùn)行在本地進(jìn)程里如果不校驗..惡意指令可能讓插件讀取任意文件。雖然插件是自用的但這個習(xí)慣必須養(yǎng)成。模型調(diào)用參數(shù)里temperature0.2是刻意設(shè)置的。代碼審查是確定性任務(wù)希望模型輸出更穩(wěn)定溫度越低輸出越保守。如果是寫創(chuàng)意文案的插件溫度可以調(diào)到 0.7 以上效果差異很大。內(nèi)容截斷content[:12000]是為了控制輸入長度。模型上下文窗口有限大文件全量塞進(jìn)去不僅浪費(fèi) token還容易讓模型忽略重點(diǎn)。實際項目中我一般配合 diff 信息一起喂給模型優(yōu)先審查變更行。3.3 本地調(diào)試與日志觀測插件開發(fā)完不是直接丟到生產(chǎn)環(huán)境先本地調(diào)試。Harness 提供了一個非常有用的調(diào)試模式harness plugin run ./my-first-plugin --debug調(diào)試模式下插件以獨(dú)立進(jìn)程運(yùn)行所有日志輸出到控制臺還有以下幾類觀測信息事件觸發(fā)記錄哪個事件在什么時間被觸發(fā)handler 是否被調(diào)用。調(diào)用鏈追蹤插件調(diào)用 SDK 每個接口的耗時。模型調(diào)用詳情prompt 和 response 的完整內(nèi)容。權(quán)限檢查結(jié)果每次文件訪問是否通過權(quán)限校驗。我調(diào)試時最常用的手段是在 handler 里加日志觀察事件是否到達(dá)。如果事件沒觸發(fā)優(yōu)先查 manifest 里的事件名拼寫如果觸發(fā)了但邏輯沒走查 handler 函數(shù)的簽名和參數(shù)對象結(jié)構(gòu)。曾經(jīng)遇到一個詭異問題插件在 Windows 上一切正常部署到 Linux 上報模塊找不到最后發(fā)現(xiàn)是 requirements.txt 里某個依賴只發(fā)布了 Windows 版本。所以跨平臺部署前一定在 Linux 環(huán)境下把插件先跑一遍測試。4. Skill 文件的編寫與內(nèi)網(wǎng)部署4.1 Skill 文件格式與規(guī)范除了插件DeepSeek Harness 還有一個很多人沒搞清的概念Skill。從搜索熱詞看deepseek harness 附帶 skill 怎么部署到內(nèi)網(wǎng)服務(wù)器是高頻問題。這里說明一下二者的關(guān)系。插件是代碼邏輯的載體Skill 是讓模型學(xué)會特定工作流的知識包。Skill 通常包含一個描述文件YAML 或 JSON和一組示例/指令文本。插件的命令可以理解為手動觸發(fā)Skill 則是模型自動決策時按規(guī)范執(zhí)行。一個標(biāo)準(zhǔn)的 Skill 描述文件長這樣name: code-review-workflow version: 1.0.0 trigger: type: keyword keywords: [code review, 代碼審查, 審查] steps: - name: collect_diff type: command value: git diff --stat - name: review_content type: model prompt_template: | 基于以下 diff 信息執(zhí)行代碼審查輸出格式為 Markdown 表格 風(fēng)險等級 | 文件 | 行號 | 問題描述 | 修復(fù)建議 - name: send_report type: plugin plugin: my-first-plugin entry: cmd_reviewSkill 的價值在于把模型的行為格式化。團(tuán)隊內(nèi)部如果有固定的代碼規(guī)范、文案模板、運(yùn)維檢查清單都可以做成 Skill。模型觸發(fā)到對應(yīng)關(guān)鍵詞時會自動按規(guī)范執(zhí)行穩(wěn)定性比裸提示詞好得多。4.2 內(nèi)網(wǎng)服務(wù)器部署流程開發(fā)好的插件和 Skill 要部署到內(nèi)網(wǎng)服務(wù)器流程分四步打包插件在插件工程目錄執(zhí)行harness plugin pack生成.hp格式的插件包。上傳到服務(wù)器用 scp 或內(nèi)網(wǎng)文件服務(wù)把插件包和 Skill 文件傳到目標(biāo)機(jī)器。安裝插件在服務(wù)器上執(zhí)行harness plugin install my-first-plugin-0.1.0.hp。驗證加載執(zhí)行harness plugin list確認(rèn)插件出現(xiàn)在列表里且狀態(tài)為 enabled。Skill 的部署更簡單本質(zhì)上是把 YAML 文件和關(guān)聯(lián)的資源文件放到 Harness 的 skills 目錄下。我團(tuán)隊的規(guī)范是所有 Skill 文件由 Git 倉庫管理通過 CI 流水線自動分發(fā)到各服務(wù)器避免人工復(fù)制導(dǎo)致版本不一致。內(nèi)網(wǎng)部署最大的坑是依賴缺失。插件在開發(fā)機(jī)上有 Python 環(huán)境、有 SDK但內(nèi)網(wǎng)服務(wù)器通常是純凈環(huán)境。建議部署前在服務(wù)器上跑一遍pip install -r requirements.txt并且確認(rèn)內(nèi)網(wǎng)有 PyPI 鏡像源可用。沒有鏡像源的在開發(fā)機(jī)上把所有依賴打包離線安裝這一步不做部署現(xiàn)場多半要手忙腳亂。4.3 離線局域網(wǎng)環(huán)境下的運(yùn)行要點(diǎn)deepseek harness 可以在離線局域網(wǎng)使用嗎這個問題后臺經(jīng)常出現(xiàn)我直接給結(jié)論可以但前提是你要有可用的模型服務(wù)。Harness 本身是一個執(zhí)行框架不綁定特定的模型來源。離線局域網(wǎng)環(huán)境下有兩類方案本地模型服務(wù)在局域網(wǎng)服務(wù)器上部署 vLLM、Ollama 或自研推理服務(wù)模型用 DeepSeek 開源權(quán)重或國產(chǎn)開源模型Harness 通過配置項指向內(nèi)部模型地址。客戶端直連模式每臺開發(fā)機(jī)本地跑一個小型模型Harness 跟本地模型進(jìn)程通信。離線模式下有兩點(diǎn)必須注意。第一插件內(nèi)所有外部依賴都要考慮離線可用性凡是插件運(yùn)行時要訪問的外部 API必須換成內(nèi)網(wǎng)地址或本地實現(xiàn)否則模型能力再強(qiáng)插件也會在調(diào)用第三方服務(wù)時卡死。第二日志和數(shù)據(jù)上報機(jī)制要獨(dú)立設(shè)計離線環(huán)境沒有中央日志系統(tǒng)的話插件的錯誤排查會非常痛苦。我的做法是在插件里內(nèi)置一個本地日志滾動機(jī)制按天分文件保留 7 天排查問題時直接看日志目錄。至于接入免費(fèi)模型的說法我的建議是謹(jǐn)慎對待平衡性。所謂免費(fèi)模型通常指開源權(quán)重模型自行部署部署成本其實不低需要 GPU 服務(wù)器、推理框架、顯存規(guī)劃。如果是個人學(xué)習(xí)用本地小模型完全可以跑通如果是團(tuán)隊生產(chǎn)環(huán)境還是得評估推理性能和穩(wěn)定性別被免費(fèi)兩個字誤導(dǎo)。插件開發(fā)時把模型調(diào)用走 SDK 抽象層后期想換模型服務(wù)改 Harness 全局配置即可插件代碼不用動。5. 常見問題排查實錄與插件生態(tài)推薦5.1 高頻報錯速查表我把開發(fā)調(diào)試過程中遇到的典型問題整理成速查表下面這些都是真實踩過的坑很多跟熱詞搜索里的問題完全對應(yīng)。報錯表現(xiàn)可能原因排查思路插件已安裝但事件不觸發(fā)manifest 事件名拼寫錯誤或版本不匹配用harness plugin run --debug觀察事件日志讀取文件報 PermissionError未聲明 read: workspace 權(quán)限檢查 manifest 中 permissions 聲明module not found缺少依賴或依賴存在平臺差異在目標(biāo)環(huán)境重新安裝依賴檢查依賴清單插件加載慢或卡死入口文件有頂層副作用代碼把初始化邏輯移到 activate 階段執(zhí)行SetNamedSecurityInfoW failedWindows 文件 ACL 設(shè)置失敗見 5.2 節(jié)詳細(xì)分析插件安裝時報校驗失敗manifest 格式有誤用 YAML 校驗工具檢查縮進(jìn)和字段類型模型調(diào)用總是超時模型服務(wù)地址不可達(dá)或并發(fā)過高檢查網(wǎng)絡(luò)連通性和服務(wù)負(fù)載5.2 Windows 權(quán)限問題深度分析熱詞里有一個問題非常典型skill 讀取文件報權(quán)限問題setnamedsecurityinfow failed (win32)。這個錯誤不少 Windows 用戶都遇到過我花了不少時間才徹底搞明白。SetNamedSecurityInfoW 是 Windows 底層 API用于設(shè)置文件或目錄的安全描述符ACL。Harness 在 Windows 上運(yùn)行時如果需要對文件做權(quán)限調(diào)整比如給 Skill 文件設(shè)置訪問控制就會調(diào)用這個 API。報錯 failed 通常意味著設(shè)置失敗但真正的原因往往不是 Harness 本身的問題而是下面幾種文件被占用目標(biāo)文件正被另一個進(jìn)程打開Windows 不允許修改它的安全屬性。最常見的就是 IDE 或編輯器鎖定了 Skill 文件。解決方案是把相關(guān)編輯器全部關(guān)閉后再操作。文件系統(tǒng)不支持 ACL如果 Skill 文件放在 FAT32 或 exFAT 格式的 U 盤/移動硬盤上這些文件系統(tǒng)本身不支持安全描述符API 必然失敗。檢查一下文件所在分區(qū)的文件系統(tǒng)格式如果是 FAT32把文件復(fù)制到 NTFS 分區(qū)即可。權(quán)限不足Harness 進(jìn)程沒有足夠的權(quán)限修改該文件的 ACL?？梢試L試以管理員身份運(yùn)行 Harness但我不推薦為了繞過問題長期用管理員權(quán)限運(yùn)行正確做法是給運(yùn)行用戶授予目標(biāo)目錄的修改權(quán)限。殺毒軟件攔截某些安全軟件會攔截對文件 ACL 的修改操作。這種情況需要把 Harness 的目錄加入安全軟件的白名單。排查順序我建議先看文件系統(tǒng)格式和文件是否被占用這兩個原因占比最高。另外每次遇到這種底層錯誤先檢查 Harness 的日志文件它會把 win32 API 的詳細(xì)錯誤碼打出來對照文檔能更精準(zhǔn)地定位。5.3 值得關(guān)注的插件方向與擴(kuò)展思路聊完排查再說說插件生態(tài)。從搜索熱詞看大家最關(guān)心這幾類插件提示詞優(yōu)化插件、代碼回退相關(guān)插件、實用工具類插件。我根據(jù)自己的使用經(jīng)驗給一些方向性建議具體實現(xiàn)可以舉一反三。提示詞優(yōu)化類插件這類插件的核心是攔截發(fā)給模型的消息在原始內(nèi)容前追加系統(tǒng)級提示詞或改寫提問方式。實現(xiàn)上就是一個on_user_message鉤子拿到消息后做規(guī)則匹配或模板注入。我的經(jīng)驗是提示詞優(yōu)化的收益上限很高但千萬別做成萬金油——針對不同任務(wù)類型代碼生成、代碼審查、文檔撰寫配不同模板效果遠(yuǎn)好于一個通用模板打天下。代碼回退類插件代碼回退不只是 git reset 那么簡單。實際場景里模型生成的一長段代碼如果中途出錯我希望回退到生成前狀態(tài)而不是整個文件回滾。插件可以做的是在模型輸出前自動創(chuàng)建文件快照如果命令執(zhí)行被中斷或用戶明確回退就把快照內(nèi)容恢復(fù)到文件系統(tǒng)。這個功能做起來不復(fù)雜但對開發(fā)體驗的提升非常明顯。工具類插件我團(tuán)隊目前用得最多的是日志采集插件、代碼格式化工裝、內(nèi)部 API 調(diào)試助手。一個原則是凡是團(tuán)隊里有人每周手動做超過三次的操作就值得寫個插件自動化。插件生態(tài)的思路我強(qiáng)烈建議先從解決自己最痛的 2 到 3 個場景開始不要一上來追求大而全。插件開發(fā)最忌諱的是 T 型陷阱高度依賴 Harness 的內(nèi)部實現(xiàn)細(xì)節(jié)結(jié)果 Harness 一升級插件就廢掉。保持插件的邊界清晰、通過官方 SDK 交互、少碰內(nèi)部私有 API這三點(diǎn)做到位后續(xù)維護(hù)成本會低很多。最后再分享一點(diǎn)個人體會插件開發(fā)這件事代碼量其實不大真正花時間的是理解 Harness 的事件模型和權(quán)限體系。我初期寫插件踩的坑十個里有七個是沒搞清事件的觸發(fā)時機(jī)或權(quán)限聲明不完整。另一個容易忽視的點(diǎn)是文檔習(xí)慣——團(tuán)隊內(nèi)多人協(xié)作開發(fā)插件時manifest 里的 description 字段寫清楚命令行注冊的命令設(shè)計得規(guī)范些后續(xù)的溝通成本能省一大截。如果你準(zhǔn)備在團(tuán)隊里推廣 Harness先把這篇文章提到的插件骨架和 Skill 規(guī)范跑通再逐步擴(kuò)展這條路我自己驗證過走得很穩(wěn)。