w-sing-hung/dsh-resume：AI 按崗位重寫簡歷，拒絕編造

前言¶

DeepSeek Harness（DSH）的設計理念是「一切皆插件」。開發者在構建智能體時，往往需要針對不同場景組合工具：有的負責解析指令，有的負責檢索知識，有的負責生成內容。當內容生成環節涉及用戶提供的敏感或關鍵信息時，工具本身的可靠性就變得至關重要。

求職簡歷屬於敏感內容。投遞時每個崗位都要微調簡歷：對齊 JD 關鍵詞、調整經歷順序、強化表述。人工做這件事，一個崗位要花 20-30 分鐘；不改，又會在 ATS（簡歷篩選系統）裏沉底。現有網頁版簡歷工具的問題在於：簡歷要上傳到第三方服務器、切換平臺會割裂工作流、且無法保證”不編造”——很多工具會主動替用戶加經歷。

w-sing-hung/dsh-resume 是一個 DSH 插件，它的核心價值在於：把簡歷重寫放進你已有的 AI 工作流，並且從機制上不可能編造。

插件定位¶

• 名稱：dsh-resume
• 維護者：W-SING-HUNG
• 分類：模型推理
• 定位：求職簡歷工坊：粘貼 JD，AI 按崗位重寫簡歷，只基於真實內容，不編造

插件在會話裏接收崗位描述（JD）與簡歷原文，模型會調用 rewrite_resume 工具，按崗位定製簡歷。交付結果包含四部分：優化後簡歷、改動說明、待補充清單、校驗結果，並可導出爲可直接投遞的 .docx 文件。

核心功能¶

1. JD × 簡歷 → 定製簡歷¶

模型根據崗位描述調整簡歷內容，包括 ATS 關鍵詞對齊、經歷權重重排。

2. 反虛構代碼守衛¶

這是插件的核心特性。它不是一句提示詞約束，而是確定性代碼校驗——判定由代碼執行，不依賴模型的態度。改寫完成後，verify_rewrite 工具會逐項比對簡歷原稿與改寫結果。

守衛檢查項包括：

• 出現原文沒有的數字
• 出現原文沒有的機構/具體技術名
• 職責強度被升格（如”參與”變”主導”）
• 時間點被改動
• 整條內容憑空新增
• 關鍵詞覆蓋虛報
• 原文數字在改寫後丟失
• 原文技術名消失且無其它技術名接替
• 容量單位大小寫被改動
• 出現原文沒有的通用概念縮寫/普通英文詞
• 英文全稱 + 其縮寫並列
• 頭部行/表格單元格里的職責主張或新增文字
• 合併條目掩蓋了職責變化

3. 一鍵導出可投遞 .docx¶

調用 export_resume 會直接產出文件，不用手動複製。生成的 .docx 是零依賴手寫 OOXML，單欄版式、A4 頁邊距、項目符號段落，Word / WPS / Google Docs 均可直接打開。版式刻意保持簡潔，避免複雜排版導致 ATS 解析失敗。

4. 改動說明與待補充清單¶

每處改動對應 JD 哪條要求（5 條以內），並明確列出 JD 要求但簡歷缺失的能力，而非編造。

5. 會話內工具調用¶

插件裝載後自動註冊 rewrite_resume 工具，向系統提示詞注入求職意圖感知。Agent 可自動識別意圖並調用。

6. 中英雙語¶

支持 language: 'zh' | 'en'。

安裝與啓用¶

安裝¶

# 裝進目標 profile（把 <repo> 換成你的本地倉庫路徑或 npm 包名）
dsh plugin --profile web add "file:<repo>"

# 重啓
dsh web

一條命令即可：CLI 會自動把插件寫進 profile 的 dependencies 與 dsh.profile.bundles 兩處。

注意事項：
- 路徑含空格時 pnpm 會報錯（Could not install from "D:/..."）。這是 pnpm 對 file: 路徑的限制，不是本插件的問題。解法：把倉庫放到不含空格的路徑（如 C:\dsh-resume）後再裝，或改用 npm 包名安裝。
- 需滿足 Node >=20，dsh >=0.1.5-rc.2 <0.2.0-0。

使用¶

插件裝載後，直接在會話裏說：

幫我根據這個崗位要求優化一下簡歷。

【JD】 …崗位描述原文…

【我的簡歷】 …簡歷原文…

模型會自動調用工具，交付四部分內容，並可按需導出爲可直接投遞的 .docx 文件。

驗證機制¶

插件包含兩道防濫用設計：

1. 不能”自證清白”：original（簡歷原文）是必填參數，導出前代碼會再執行一次確定性校驗，不通過則拒絕寫出文件。這讓”編造的簡歷投不出去”成爲機制保證。
   - original 與 resume 實質相同（含僅空白/換行差異）→ 拒絕導出。
   - original 只比 resume 多出少量文字（疑似”副本 + 裝飾”）→ 不拒絕，但 verified 降級爲 false 並在摘要裏說明原因。

2. 不謊報校驗範圍：includeAppendix: true 時，附錄（改動說明/待補充清單/校驗結果）屬元信息，不參與校驗。

適用場景與注意¶

• 適合誰：需要頻繁投遞不同崗位的開發者、希望用 AI 輔助簡歷優化但擔心編造的用戶。
• 注意：插件以當前 DSH 進程權限運行。安裝前應檢查源碼與許可證（MIT）。
• 安全邊界：不覆蓋已存在的文件、不自動創建目錄、拒絕目錄路徑。可用環境變量 DSH_RESUME_EXPORT_ROOT 限定導出根目錄。

示例驗證¶

運行 npm run demo:guard 可以看到真實攔截效果：

假設簡歷裏原本寫着：

## 項目經歷
校園二手交易平臺（前端負責人）
- 使用 Vue2 編寫主要展示頁面和商品列表模塊
- 對接後端 REST 接口，完成登錄與購物車功能
- 通過懶加載商品圖片與合併請求，將首屏加載時間從 2.4s 縮短至 1.8s

• 情況一：模型順手加了個數據（如”接口響應時間優化 60%”）→ 被攔住，返回 FABRICATED_NUMBER。
• 情況二：模型把”負責”升格成”主導” → 被攔住，返回 RESPONSIBILITY_INFLATED。
• 情況三：模型憑空多寫了一條經歷 → 被攔住，返回 RESPONSIBILITY_INFLATED 和 NOVEL_CONTENT。
• 情況四：合法改寫（只強化措辭、事實分毫未動）→ 通過校驗，返回 ok = true。

結尾¶

w-sing-hung/dsh-resume 把”不編造”從提示詞約束變成了確定性代碼校驗。開發者可以放心地把簡歷優化放進自己的 DSH 工作流，每一處改動都必須在事實邊界內——而且這件事由代碼判定，不靠模型自覺。

• 目錄頁：https://www.skillhub.cn/plugins/W-SING-HUNG/dsh-resume
• GitHub：https://github.com/W-SING-HUNG/dsh-resume