dsh-resume · Resume Studio

粘贴 JD，AI 按岗位重写你的简历 —— 只基于真实经历，绝不编造。

一个 DeepSeek Harness (DSH) 插件。 在会话里粘贴岗位描述与简历原文，模型会调用 rewrite_resume 工具，按岗位定制简历。

---

目录

• 为什么需要它
• 快速开始
• 核心特性
• 反虚构铁律
• 工作原理
• 开发与验证
• 架构与硬约束
• 常见问题
• 贡献
• License

---

为什么需要它

投递时每个岗位都要微调简历：对齐 JD 关键词、调整经历顺序、强化表述。 人工做这件事，一个岗位要花 20-30 分钟；不改，又会在 ATS（简历筛选系统）里沉底。

现有网页版简历工具的问题：

• 简历要上传到第三方服务器
• 切换平台，割裂工作流
• 无法保证"不编造"——很多工具会主动替用户加经历

本插件把这件事放进你已有的 AI 工作流，且从机制上不可能编造。

快速开始

安装

# 装进目标 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 包名安装。

使用

插件装载后自动注册 rewrite_resume 工具，并向系统提示词注入求职意图感知。 直接在会话里说：

帮我根据这个岗位要求优化一下简历。

【JD】 …岗位描述原文…

【我的简历】 …简历原文…

模型会自动调用工具，交付四部分：优化后简历 / 改动说明 / 待补充清单 / 校验结果， 并可按需导出为可直接投递的 .docx 文件——不用自己复制排版。

它实际拦住了什么

不需要安装任何东西——下面全部输出由 npm run demo:guard 真实运行产生。

假设你的简历里原本写着：

## 项目经历
校园二手交易平台（前端负责人）
- 使用 Vue2 编写主要展示页面和商品列表模块
- 对接后端 REST 接口，完成登录与购物车功能
- 通过懒加载商品图片与合并请求，将首屏加载时间从 2.4s 缩短至 1.8s

情况一：模型顺手加了个数据

- 对接后端 REST 接口，完成登录与购物车功能
+ 对接后端 REST 接口，完成登录与购物车功能，接口响应时间优化 60%

verify_rewrite → ok = false
  FABRICATED_NUMBER  evidence: ["60"]

那个 60% 是你没写过的。面试官问"怎么测的"，你答不上来。

情况二：模型把"负责"升格成"主导"

- 负责使用 Vue2 编写主要展示页面
+ 主导使用 Vue2 编写主要展示页面

verify_rewrite → ok = false
  RESPONSIBILITY_INFLATED

这类改动最容易被放过——它没编任何数据，只是把语气抬高了。 但面试官会问"你是怎么主导的"，而你只是参与实现。

情况三：模型凭空多写了一条经历

  - 通过懒加载商品图片与合并请求，将首屏加载时间从 2.4s 缩短至 1.8s
+ - 负责用户增长策略，主导社群运营体系搭建，实现月活翻倍

verify_rewrite → ok = false
  RESPONSIBILITY_INFLATED
  NOVEL_CONTENT

这条与原文任何一条都对不上，所以被逐条内容比对抓住（NOVEL_CONTENT）。 注意它同时还触发了 RESPONSIBILITY_INFLATED：这条凭空新增的经历里写着"主导"， 而原文中没有任何一条与之对应的职责主张——数字与机构检查抓不住它 （没有新数字、也没有新机构名），但职责强度检查会命中，两个检查互为兜底。

情况四：合法改写——只强化措辞、事实分毫未动

- 使用 Vue2 编写主要展示页面和商品列表模块
+ 负责使用 Vue2 完成主要展示页面与商品列表模块的开发

verify_rewrite → ok = true   （findings 数量：0）

这就是这个项目想做到的事：让模型可以放心地帮你把简历写得更好， 但每一处改动都必须在事实边界内——而且这件事由代码判定，不靠模型自觉。

先看看它长什么样

无需安装 DSH 即可运行示例：

npm install
npm run example      # 完整流程演示
npm run demo:guard   # 只看守卫拦住编造的过程

核心特性

特性	状态	说明
JD × 简历 → 定制简历	✅	ATS 关键词对齐、经历权重重排
反虚构代码守卫	✅	确定性校验，不依赖模型自觉，见下节
一键导出可投递 .docx	✅	零依赖生成，单栏 A4，ATS 可解析
改动说明	✅	每处改动对应 JD 哪条要求，5 条以内
待补充清单	✅	JD 要求但简历缺失的能力，明示而非编造
会话内工具调用	✅	agent 可自动识别意图并调用
中英双语	✅	language: 'zh' | 'en'
多版本管理	计划中	每个 JD 一版
独立双栏 UI 面板	计划中	client half

导出的文件长什么样

调用 export_resume 会直接产出文件，不用手动复制：

verify_rewrite → ok = true
export_resume  → 已导出 DOCX 文件（2211 字节）到 ./投递版简历.docx

生成的 .docx 是零依赖手写 OOXML（本项目运行时依赖为 0）： 单栏版式、A4 页边距、项目符号段落，Word / WPS / Google Docs 均可直接打开。 版式刻意保持简洁——复杂排版会导致 ATS 解析失败，这在简历领域是已知问题。

上方的字节数是 npm run demo:export 的真实输出。DOCX 是压缩包， 字节数随简历长度变化，不必与你的实际输出一致。

两种导出模式：

模式	内容	用途
默认	只有简历本体	投递给 HR（不带改动说明等内部内容）
includeAppendix: true	附改动说明 / 待补充清单 / 校验结果	自己留档、复盘

安全边界：不覆盖已存在的文件、不自动创建目录、拒绝目录路径—— 避免误毁你已有的简历文件。三类边界都有测试覆盖。 另可用环境变量 DSH_RESUME_EXPORT_ROOT 限定导出根目录， 把"模型被注入语料诱导后在任意位置建文件"这一面收窄（详见 SECURITY.md）。

交付关（反虚构的最后一环）：original（简历原文）是必填参数， 导出前代码会再执行一次确定性校验，不通过则拒绝写出文件。 这让"编造的简历投不出去"成为机制保证，而不是对模型自觉的期待—— 跳过 verify_rewrite 直接导出这条捷径已被堵死。

两道防滥用设计，都有回归测试：

• 不能"自证清白"，但也不靠"拒之门外"来假装安全：original 是模型传入的参数、 并非可信源，把改写结果回填进去会让校验退化为自反比对，任何编造都"有据可依"—— 这种"伪装成已校验"比不做校验更危险。代码按两种情形分别处理：

  • original 与 resume 实质相同（含仅空白/换行差异）→ 拒绝导出。 两份完全相同必定是传错参数，无歧义，提示后能立刻改正。
  • original 只比 resume 多出少量文字（疑似"副本 + 装饰"） → 不拒绝，但 verified 降级为 false 并在摘要里说明原因。

  为什么第二档不直接拒绝：纯文本层面无法区分"尾部加了装饰"与 "模型删掉了一条经历"——两者都表现为「original = resume + 一小段」。 硬拒绝会误伤合法精简，让用户拿不到文件（这正是本项目最严重的一类缺陷）。 既然不存在可靠判据，就不该用它假装有保证：不谎称已校验，也不阻断交付。

  残留边界（不夸大）：若模型刻意伪造一份措辞不同、或删掉大半内容再回填的 original，代码识别不了。因此 verified: true 的准确含义是 "已对照传入的 original 校验通过"，而不是"original 必定真实"。

• 不谎报校验范围：includeAppendix: true 时，附录（改动说明/待补充清单/校验结果） 属元信息、不参与校验（待补充清单列出 JD 要求而简历缺失的技能是设计意图， 拿去校验必然误报）。此时返回值会明确声明"校验范围仅限简历本体"。

反虚构：从"提示词约束"到"代码校验"

只能重排与强化简历中真实存在的信息。禁止编造任何新经历、新数据、新技能。

这不是一句宣传语，而是本项目的存在理由。编造的经历会在面试第一轮就被问穿， 用户因此丢掉 offer，插件也因此被差评——编造等于项目自杀。

为什么提示词不够

把铁律写进提示词，只能表达意图，无法提供保证：模型一旦违反， 没有任何机制能发现，用户会拿着编造的内容去面试。 因此本项目把反虚构做成确定性代码校验——判定由代码执行，不依赖模型的态度。

守卫检查什么

改写完成后，verify_rewrite 工具会逐项比对你的简历原稿与改写结果：

检查项	级别	说明
出现原文没有的数字	必须修正	简历里风险最高的编造类型（"提升 40%"、"服务 8 万用户"）
出现原文没有的机构/具体技术名	必须修正	换了公司名（某互联网公司 → 字节跳动公司）、加了没做过的项目、凭空多写一行技能（- 熟悉 Redis；）；技术栈替换也算（Vue2 → React、CSS → SCSS、JavaScript → Java）
职责强度被升格	必须修正	把"参与"写成"主导"、"协助"写成"负责"——比编数字更隐蔽，面试追问时才暴露
时间点被改动	必须修正	起止日期属事实字段，改动会与背调不符
整条内容凭空新增	必须修正	与原文任何一条都对不上的表述（如凭空多出一段没做过的经历）
关键词覆盖虚报	必须修正	声称已对齐 JD 关键词，但该词并未真的写进简历
原文数字在改写后丢失	建议检查	真实量化结果被无意删掉
原文技术名消失且无其它技术名接替	建议检查	如 CSS → 层叠样式表，或直接删掉 CSS。没有凭空增加主张（不算编造），故不阻断；但也不会被静默放过——若只是把技术名换成模糊的中文表述以规避检查，请改回原文写法。"消失"按全文判定，折行/拆分不会误报
容量单位大小写被改动	建议检查	2MB ↔ 2Mb。b/B 是比特/字节（相差 8 倍），而 KB/kb 等是常见同义混写——纯文本无法判定意图，故只提示
出现原文没有的通用概念缩写/普通英文词	建议检查	CI/CD、SDK、API、HTTP 等泛指概念。它们常是中文术语的等价写法（超文本传输协议（HTTP），ATS 关键词对齐），也可能是新增技能——纯文本无法判定，故只提示不阻断
英文全称 + 其缩写并列（Google Analytics (GA)、GA (Google Analytics)）	建议检查	中文简历写 中文术语（HTTP），英文简历没有中文可并列，只能写成全称与缩写直接相邻——同一个 ATS 对齐动作（两种书写顺序都认）。放行要求该全称必须在原文中逐词存在，故 Fake Skill (FS)、Tableau (Google Analytics) 仍被拦
头部行/表格单元格里的职责主张或新增文字	建议检查	头部行（求职意向、联系方式行）与"被当作表格表头剥掉的行"都不参与逐条比对，曾是检查盲区。现对这两处单独做兜底告警。取提示不取阻断：头部可能是在陈述求职目标而非经历，表头位也无法与真列名区分，纯文本判不了
合并条目掩盖了职责变化	建议检查	两条合成一条时，被合并掉那条的职责强度变化无法可靠比对，需人工确认

判定"新增/替换技术名"用的是文本结构而非词表： 原有技术名消失=替换（必须修正）；处于括号/斜杠注记位=等价写法（仅提示）； 原文有一条中文显著更多的句子、且它已被本行替换掉=中文换缩写的收缩写法（仅提示）。 词表式的做法已被证伪——"中文术语↔英文缩写"是开放集合，枚举必然滞后 （实测：20 个最常见的 ATS 对齐动作里曾误拒 13 个，即用户改好了却拿不到文件）。

因此两种写法都会被正确对待：

• - 熟悉超文本传输协议； → - 熟悉 HTTP； —— 可以（原句被缩写替换掉）
• 原句保留、另加一行 - 熟悉 HTTP； —— 会被拦（原文仍在，属纯增量； 且该写法与编造技能 - 熟悉 Redis； 在文本上无法区分）

英文简历是同一个道理的另一种写法。中文用 中文术语（HTTP） 并列， 英文没有中文术语可并列，只能把全称与缩写写在一起：

• Google Analytics → Google Analytics (GA) —— 可以（缩写取自原文已有的全称）
• Google Analytics → Fake Skill (FS) —— 会被拦（全称在原文里不存在， 首字母拼写相符不足以证明它真实）

为什么专门检测"职责升格"：简历造假最常见、也最隐蔽的形态不是编数字， 而是悄悄抬高职责——"参与"变"主导"、"协助"变"负责"。 数字编造容易被追问（"这 40% 怎么算的"），职责升格往往能蒙混过关， 直到面试官问"你是怎么主导的"才露馅，对用户的伤害更大。 许多工具在文档里写了这条纪律，但只作为给模型的提示；本项目把它做成了代码检查。

强制闭环：模型改写后必须调用守卫自检；返回不通过时必须修正后重新校验， 直到通过才能交付。未通过校验就交付视为违反铁律。

核对表：每个数字、名称、时间点都能核对回你的原简历

多数反编造工具只告诉你"有没有问题"，你却无法核对改写后的内容是不是真的。 verify_rewrite 会在结论之后给出核对说明——用你原简历的写法并列，不用自己换算， 每条都带"该怎么办"：

✅ 简历里的 2 处数字都能在你的原简历里找到出处，逐条对照如下：
   · 40（原简历也是这么写的）
   · 8 万 → 80000（改成了另一种写法，数值没变）

❗ 有 1 处名称在你原简历里找不到，请确认是否真实：
   · 「字节跳动公司」— 原简历里没有这个名字
   处理方式：公司名、技术名、项目名都必须是你真实经历过的，
   没有的请删掉；写法和原简历不一致的（比如只写了简称）请改回。

❗ 有 1 处时间点在你的原简历里找不到，请确认：
   · 「2022 年 10 月」— 原简历里没有这个时间点
   处理方式：起止日期是最容易在背调时对不上的字段，务必改回真实的。

原简历里有、改写后丢掉的真实内容也会被提醒（⚠ 原来写的「8 万」现在没有了）， 免得你无意中丢掉了最有说服力的量化成果。没变的内容不会列出来——清单里只有 需要你核对或注意的项，不让噪声淹没真正的问题。

它不改变拦截判定，只是把判定摊开给你看：与检查项用的是同一批判定结果 （不是第二套判据），所以物理上不会出现"守卫说没问题、核对表说没出处"的矛盾。 8 万 → 80000、2.4s → 2400ms、2026.03 → 2026年3月 这类等价写法都会 正确识别为"同一个数/同一个时间点"，不会误报。

已知边界（不夸大能力）

守卫明确声明它能做什么、不能做什么——使用者知道边界在哪，才不会被虚假的安全感误导：

• 只检测带强后缀的机构名（某某公司/大学/银行…，含日韩 株式会社/주식회사 等）；无后缀的机构名（如"字节跳动"）无法可靠识别，需人工确认
• 数字按 token 比对，不做语义判断：把"提升 40%"改成"提升四成"（或"提升两倍"）能被识别为等价写法； 但语义等价而数值不同的写法仍不判定（把"提升 40%"写成"提升了近一半"）
• 时间点被改动包含"绝对日期改模糊"：把"2022 年"改写成"三年前"同样会拦下（模型无从知道当前日期）， 两个方向都查；以内/以来/至今 等形态不在此列
• 零宽字符（​、软连字符等）会被剥掉，用它们拆开数字仍能拦下； 但普通空格也能把数字拆成两个 token（QPS 2 400）——刻意不收紧，因为 2 GB、8 K 是合法单位写法，收紧会误拒正常简历
• 职责升格按"改写条目 ↔ 原文条目"逐对比较，且基于中文动词词表：措辞避开词表的同义升格可能漏检； 另外合并条目时只能比到最相似的那一条，被合并掉那条的职责变化改为 warn 提示，需人工确认
• 逐条比对只覆盖长度 ≥ 8 字的内容单元；标题、姓名等短行不参与（短行相似度噪声大，会制造误报）
• 拉丁专名的识别依赖"行内位置 + 大小写 + 该行是否含汉字"三者： 英文行里的行首词与全小写词不识别；中文行里的全小写技术名（redis、mysql）可以识别
• 整条新增检测按字级相似度判定："把原有经历改写得面目全非"可能被误报为新增，需人工确认
• 本校验只做文本特征比对，不判断内容是否真实——它拦得住"与原文对不上"的编造，拦不住"原文本身就写了假的"
• 汉字数字（含大写"壹佰"）与阿拉伯数字同等比对；但分数式（"三分之一"）与语义等价而数值不同的约数写法不判定
• 职责升格只在四个语种的固定词表上生效（中/英/日/韩，如"负责 → 全权负责"、"主导 → 全面主导"）； 词表外的强度修饰（"深度参与""扛起""操盘"）不检测——这与职责升格同源，枚举必然滞后
• 表格里若有整张"无任何事实特征、且原文找不到出处"的短格内容，只报建议检查而不阻断导出； 只要任一格含数字/机构/技术名/职责动词，即视为正常表格化排版

设计取舍：宁可漏报少数无后缀机构，也不制造大量误报。 一个频繁误报的守卫会被使用者直接忽略——那比没有守卫更糟。 更实际的是：误报会让用户拿不到文件（本项目最严重的一类缺陷）， 因此凡"纯文本无法判定"的情形一律降级为提示，绝不阻断导出。

三重保障

第一重：提示词层 src/prompt.js 内置三条硬规则，并强制要求改写后调用守卫校验。

第二重：代码层 src/guard.js 确定性比对（纯函数、零依赖、可离线测试）， npm run check:guard 做行为级验证——若守卫被改成"永远通过"，脚本立刻失败。

第三重：测试层 npm test 含守卫测试，其中反向验证用例专门确认"编造必须被抓住"， 正向用例确认"合法改写不得误报"。CI 的 guard 任务独立再校验一次。

工作原理

用户会话
   │  「帮我按这个 JD 优化简历」
   ▼
DSH 会话模型 ──识别求职意图──▶ 调用 rewrite_resume 工具
   │                                    │
   │                          ┌─────────┴──────────┐
   │                          │  src/core.js       │
   │                          │  纯函数，零副作用   │
   │                          │  返回改写指令集     │
   │                          └─────────┬──────────┘
   │                                    │
   ▼                                    ▼
模型按指令集重写 ──▶ 调用 verify_rewrite 校验
                          │
                    ┌─────┴─────┐
                    │           │
                 通过        不通过
                    │           │
                    ▼           ▼
              四段式交付    修正后重新校验

两层设计：工具不做重写，只产出改写指令集；真正的重写由会话模型执行。 这样插件的核心逻辑保持纯函数、可离线测试，且不绑定任何模型实现。 反虚构校验作为独立工具介入，形成"改写 → 校验 → 修正"的闭环。

开发与验证

npm install          # 仅装 devDependencies
npm run verify       # 全量验证：语法 + 类型 + 文档检查 + 发布审计 + 守卫行为 + 测试 + 示例

命令	内容	需要 DSH
npm run lint	语法检查	否
npm run typecheck	TypeScript 静态类型检查（JSDoc + checkJs）	否
npm test	全部测试，node:test 标准 runner	否
npm run test:coverage	覆盖率报告	否
npm run check:guard	守卫行为验证（编造必须被拦、合法必须放行）	否
npm run check:docs	文档一致性检查	否
npm run check:secrets	敏感信息扫描	否
npm run demo:guard	只看守卫拦住编造的过程	否
npm run demo:export	端到端：校验 → 导出真实 .docx	否
npm run example	可运行示例（含守卫演示）	否
npm run verify	以上全部	否

测试分七组（test/node/）：

• guard.test.js — 反虚构守卫：token 提取、反向验证（编造必须被抓住）、 正向路径（合法改写必须放行）、职责升格、时间线一致性、关键词回验、 整条新增检测、防误报、已知局限声明
• export.test.js — 导出：ZIP/DOCX 结构真实性（真实解包校验）、 XML 转义、Markdown 解析、安全边界（不覆盖已有文件等）
• core.test.js — 语言规范化、输出契约、真实场景、失败路径
• contract.test.js — 工具定义形态、schema 关键字白名单、真实 execute
• plugin.test.js — apply(ctx) 装载路径、架构硬约束守卫
• schema.test.js — 调用平台自身的断言函数校验 schema（探测不到 DSH 时优雅跳过）
• publish-audit.test.js — 发布审计元测试

CI 在 Linux / Windows / macOS × Node 20 / 22 / 24 共 9 个组合上重跑同一套命令。

架构与硬约束

src/guard.js    反虚构守卫：确定性校验（零依赖纯函数，可离线测试）
src/export.js   导出：手写 ZIP + OOXML，零依赖生成 .docx
src/core.js     零依赖核心：业务逻辑 + 契约常量（唯一事实来源）
src/index.js    平台装配：section 注入 + 工具注册 + 文件 IO
src/prompt.js   核心资产：简历改写引擎 prompt（含版本号）
test/node/      测试套件
examples/       可运行示例与 fixtures
scripts/        验证工具（文档一致性 / 发布审计 / 守卫行为 / 演示 / 测试运行器）

分层原则：core.js 与 guard.js、export.js 全部是零 IO 纯函数， 因此可在任何环境离线测试；文件系统写入只出现在 index.js（装配层）。 这样契约层永远可测，IO 边界清晰。

两条不容违反的硬约束

这两条都是端到端验证踩坑得出的，纯离线测试发现不了：

1. 插件不可 import 任何 @deepseek-ai/* 包

// ❌ 会让运行时崩溃
import { defineTool } from '@deepseek-ai/dsh-tools'

原因：插件从自身位置会解析到一份独立的 dsh-tools 副本，与宿主运行时形成模块双实例。 两份模块里的 TOOL_RUNTIME_SCHEDULER 是不同的 Symbol，宿主执行工具时取到 undefined， 报 Cannot read properties of undefined (reading 'prepare')。

2. package.json 的 dependencies 必须为空

声明平台包会让 pnpm 在目标 profile 里再装一份，重新制造上述双实例问题。 平台包只放 devDependencies（仅供测试）。

其他契约要点

• schema 关键字白名单：平台只接受 type/oneOf/properties/required/additionalProperties/items/enum/const + 注解
• required 位置：必须是 object 根级的字符串数组，不能写在 property 内部
• 输出 schema 的 additionalProperties:false：execute 返回值字段必须与其严格一致，多一字段即 ToolOutputError
• 参数根节点是开放对象：平台不拦截未知参数，防线是 required 校验 + 白名单解构

常见问题

简历内容会被上传到第三方吗？

不会。插件自身零网络请求。简历只在你的本地会话中流转； 唯一的落盘动作是 export_resume 写出你指定路径的那个文件，此外不写任何东西。

它会不会替我编造经历？

不会。见反虚构铁律——三重机制的保障，且有测试物理锁定。

支持哪些语言？

工具支持中英双语输出（language: 'zh' | 'en'）。

需要什么版本的 DSH？

针对 @deepseek-ai/dsh-tools@0.1.5-rc.2 与 cordis 4.0.2 验证。Node 需 20 以上。

有独立界面吗？

当前是会话驱动形态（工具 + 提示词注入），没有独立图形界面。双栏 UI 面板在路线图中。

为什么工具返回的是"指令集"而不是直接改写好的简历？

因为重写需要理解语义，交给会话模型做质量更高，且让插件核心保持纯函数、可离线测试。 这是刻意的架构选择，不是功能缺失。

贡献

欢迎 PR。动手前请读 CONTRIBUTING.md——里面有两条会直接导致运行崩溃的硬约束， 以及反虚构铁律的不可违反说明。

npm run verify   # 提交前必须全绿

License

MIT