CNSAily 求职投递工作流（通用版）
一套把「真实经历」翻译成「目标岗位听得懂的语言」，并稳定产出可投递文件 + 可追踪记录的工作流。 适配任何支持
SKILL.md的 agent 环境（WorkBuddy / Claude Code / Codex 等）。 全链路复现，不绑定任何特定个人，所有个人化内容通过占位符与首次沟通注入。
一、定位与触发
- 用户发来简历（PDF / Word / 文字）说「梳理经历 / 建经历库 / 盘点背景」→ 走首次建立经历库。
- 用户发来某岗位 JD（截图 / 复制粘贴文字 / 链接）说「改简历 / 定制简历 / 给 JD 改一份」→ 走定向改简历。
- 用户单独说「写个自我评价 / 个人特长」或「登记这条投递」→ 走对应单步。
默认只做「建库 → 收 JD → 改 HTML → 转 docx → 投递时登记」这条链路，不自动扩展网申自动填表。
二、完整链路总览
┌─ 首次使用 ─────────────────────────────────────────┐
│ 和用户沟通盘点经历 → 沉淀「经历库.md」事实证据库 │
└────────────────────────────────────────────────────┘
↓
收 JD（截图 / 复制粘贴 / 链接）→ 拆解岗位要求
↓
查经历库挑素材（事实层真实、表述层美化）
↓
复制母版改 HTML（只改文字，不碰结构）
↓
板块时间倒序 + 措辞强化（不置顶）
↓
技能区 / 求职意向精简
↓
写 JD 匹配矩阵（每次必做）
↓
产出 HTML + docx 投递件（一起交付）
↓
生成自我评价 / 个人特长（每次现生成）
↓
登记投递记录（有用户云文档→自动登记；无表→按标准表头建议建表）
↓
回执 + 记忆
三、首次使用：初始化 + 建立经历库
3.1 初始化工作区
所有资产集中在一个「简历工作区」目录下，路径由用户指定（下文用 <简历工作区> 代指）。首次一次性建好：
| 资产 | 用途 |
|---|---|
<简历工作区>/经历库.md |
事实证据库，所有简历的唯一事实来源（先建这个） |
<简历工作区>/简历模板-母版.html |
所有简历的唯一格式母版，只复制、不直接改动 |
<简历工作区>/<姓名>-<公司岗位>.html |
定向投递版（浏览器编辑 / 打印 PDF 用） |
<简历工作区>/<姓名>-<公司岗位>.docx |
离线投递件（邮箱 / 招聘系统上传用） |
<简历工作区>/gen_docx_<公司>.py |
从母版式内容生成对应 docx 的脚本 |
<简历工作区>/JD匹配矩阵-<公司岗位>.md |
JD 拆解 → 匹配度 → 定制策略 → 风险提醒 |
把占位符换成用户自己的值；docx 生成脚本的运行环境（python venv、python-docx 等）在此处一次性配好并记下。
3.2 建立经历库（和用户沟通，首次必做）
用户第一次用时，先沟通盘点经历，不要直接改简历。方法：
- 收现有素材：请用户提供现有简历（PDF / Word / 文字粘贴）、项目说明、作品集、获奖、证书等一切可用材料。
- 逐段沟通：对每段经历问三个问题——「真做了什么」「有哪些数字 / 证据能讲清」「这段能对位哪些岗位方向」。
- 区分事实与表述：事实（时间、公司、职位、做的事、数字）真实留档；表达角度、排序、措辞等表述层选择另行处理。
- 标记诚实边界：哪些内容不能写进简历（露规模 / 露阶段 / 敏感数字）、哪些留到面试口头讲，逐条记下。
沉淀到 经历库.md，结构模板：
# 经历库
## 经历一：<公司 / 项目名>
- 时间：YYYY.MM – YYYY.MM
- 角色：<岗位 / 角色>
- 类型：实习 / 工作 / 项目 / 校园 / 其他
- 事实（客观做了什么）：
- …
- 证据 / 数字（能讲清的量）：
- …
- 可对位的方向（哪些岗位用得上）：
- …
- 诚实边界（不写进简历 / 留面试讲）：
- …
## 经历二：…
详细沟通方法与结构说明见 references/evidence-bank.md。之后每次改简历都只从经历库取材，不再重新问一遍基础信息。
四、核心原则：事实层留档、表述层美化
- 事实层（经历库）：真实、不造假，是所有简历的唯一事实来源。
- 表述层（简历正文）：允许美化措辞、调整排序、重构表达，但不改变事实。
- 背调硬信息（政治面貌、证书、日期、院校、在职状态、职位名称等会被核实的字段）一个字不能动，改动前必须停下问用户。
- 翻译 ≠ 造假：把做过的真事换个角度讲给目标岗位听，是翻译；把没做的写上去，是造假，面试一追问就崩。
五、执行步骤
第 1 步：收 JD 并拆解
接受 截图、复制粘贴文字、链接 三种形式。提炼：岗位职责、任职条件、加分项、招聘对象（经验 / 专业 / 地点）、DDL、投递方式。记录到待写的匹配矩阵。
- 若只有截图、无文字版：先按能识别的岗位方向 / 职责 / 任职条件写框架，缺的关键条目在回执里提示用户补 JD 原文。
- 若只给公司 + 岗位、没贴 JD：先按公司 + 岗位方向检索同岗 JD 补全，并标注来源置信度。
第 2 步：查经历库定素材
读 经历库.md，挑贴合该岗位的 2–4 段经历 + 技能点做措辞素材。表述层可美化，事实层不得造假。 若经历库还没建，先回「三、首次使用」补建。
第 3 步：复制母版改 HTML
复制 简历模板-母版.html → <姓名>-<公司岗位>.html。只改文字内容（title、联系方式、各板块正文），不碰 CSS / 工具栏 / 脚本 / 结构。
板块排序规则（默认铁律）：
- 所有板块（教育 / 工作 / 项目 / 校园 / 技能等）内部履历一律按时间由近及远排列，不做「匹配度置顶」或跨板块挪位。
- 需要突出某段经历时，用「措辞强化」实现：加粗关键贡献数据、扩写对位 JD 的细节、把该经历最对位 JD 的那条 bullet 提到 bullet 列表的第一条，不通过改板块内整体顺序或跨板块置顶。
- 新增 / 插入一段履历后，必须整段核对一遍该板块的实际输出顺序是否为按开始时间由近及远，不能只「插在母版当前第一项之后」。判断口径：比较各段行首的起始月份（从大到小排）。母版默认顺序可能是错的，从母版复制后第一步就先把各板块排成时间倒序，再继续改措辞，避免最后整块返工。
措辞硬规矩：项目标题一律只写名称本身，不加任何说明性括号或类型标签。突出某经历只通过措辞强化（加粗、扩写、首条 bullet 放对位点），不使用置顶。
第 4 步：技能区 / 求职意向精简
技能与工具区精简规则：
- 技能与工具区只保留两类内容：① 软件使用（Python / Stata / Power BI / Office 等，按岗位需要写清用途）；② 语言能力（含语言证书，如 CET-6 / 雅思 / 托福，写清实际水平）。其余的能力描述条目（「财务分析」「行业研究」「沟通协作」等
××能力：…类措辞）默认删除，把空间让给履历正文。 - 唯一例外：若目标 JD 着重强调某项分析 / 研究 / 业务能力，可把该项能力用 1 条简短总结放回技能区（从对应经历里提炼的能力总结），其余能力描述仍删。
- 同一背景信息只在相应板块写一次，技能区、求职意向等处不再重复。
求职意向精简规则：
- 位置铁律：求职意向行必须放在头部信息区——姓名 / 联系方式之后、教育背景之前，作为头部的一行。绝对不要插进「教育背景」板块内部，否则视觉上会被当成教育背景的内容。
- 求职意向只写：
求职意向：<目标 JD 的方向 / 岗位>。 - 若 JD 明确要求出差或轮岗，则在末尾补一句「接受出差」（视 JD 用词写作「接受出差」或「接受出差与多地轮岗」）；若 JD 未提，则不加。
- 其余一律不写：不写重复的学历信息、不写属地、不写政治面貌、不重复列举多方向——这些信息教育背景处已含，反复提及只会挤占履历空间。
- 头部信息区默认不写地址 / 所在地：姓名 + 联系方式之后只放「求职意向」一行。网申表单里的「现居地 / 户籍」字段照填，与简历正文无关。
第 5 步：产出并交付 docx（HTML 预览 + docx 投递件一起给用户）
docx 是投递必需件（招聘系统 / 邮箱上传用），每次改简历都必须同步产出，并作为交付物一起给用户下载——不能只生成却藏起来不给，更不能跳过。
- HTML 正文每处改动，都必须同步到对应
gen_docx_<公司>.py脚本并重跑，保证.docx与.html内容一致。 - 定稿后一次列出两个交付物：第一位放 HTML（打开预览看排版）、第二位放同名 docx（供下载 / 上传网申系统）。
- 回执里明确写一句「已生成同名 docx（投递件）」，让用户知道 docx 就绪。
第 6 步：写 JD 匹配矩阵（必做，勿跳过）
每次改简历都必须写 JD匹配矩阵-<公司岗位>.md。内容：JD 要求逐条 → 我的证据 → 匹配度（高 / 中 / 低）→ 定制动作 → 短板与风险（诚实提示）。模板见 references/jd-matching-matrix.md。
第 7 步：生成「自我评价 + 个人特长」（每次必做）
- 每次按 JD 改完一份简历，自动生成该公司的「自我评价 + 个人特长」，作为交付物之一，不要等用户开口。
- 关键纪律：自我评价 / 个人特长是独立的网申文字产物，绝不写进简历 HTML / docx 正文。它们在「自我介绍 / 个人评价 / 个人特长」类表单或网申框里单独使用。
- 自我评价：≤200 字（中文实字，不含标点；如需宽松可用 ≤300）。个人特长：≤50 字。
- 只每次现生成、不留档：不为每家公司存一份独立副本。保留 1–2 个示例作风格 / 篇幅参考即可，每次给新 JD 时根据当次 JD + 该定制简历现生成一版，直接交付可复制文本。
- 必含锚点（按该岗侧重取舍）：学历院校、工作 / 项目经历与业绩、核心技能、语言证书、该 JD 特有门槛（如「适应出差」等）。
- 规范详见
references/self-evaluation.md。
第 8 步：登记投递记录（双模式）
每次改完简历，主动登记投递信息。分两种情况：
模式 A：用户已有投递追踪表（飞书多维表格 / 云文档）
- 用户提供自己的表链接 → 解析她的表头字段 → 按她表里已有的字段名自动登记（字段以用户表为准，不强行套标准表）。
- 缺关键字段（投递链接、是否已投等）先按已有信息登记，缺项在回执里提示用户补。
模式 B：用户没有追踪表
- 用 skill 内置的标准投递追踪表头（见
references/application-tracking.md）建议用户直接用这个表结构； - 可直接帮用户在飞书建一张多维表格（按标准表头），之后按此表登记。
登记纪律：状态默认「已投递」；登记后去重（部分通道批量创建会双写）；同公司不同批次 / 地点新增独立记录；附件先复制到简历工作区用稳定路径再上传。
第 9 步：回执 + 记忆
回执要点：改了哪几处（含置顶决策）、自我评价 / 特长文本、投递登记记录 ID、状态与缺项提示、风险提醒（证书 / 政治面貌诚实）。完成后把本次成果追加到项目记忆日志。
六、交付物命名规范
- HTML：
<姓名>-<公司岗位>.html - docx：
<姓名>-<公司岗位>.docx - 生成脚本：
gen_docx_<公司>.py - 匹配矩阵：
JD匹配矩阵-<公司岗位>.md - 自我评价键：
_<公司岗位>后缀
七、纪律红线（务必守）
- 不造假：事实层真实留档；表述层美化仅限措辞。改政治面貌 / 证书 / 日期等背调硬信息前停下问用户。
- 母版只读：从母版复制新文件再改，绝不直接改母版 / 不碰 HTML 结构与工具栏脚本。
- docx 必产出并一起交付：每次改简历都必须同步产出同名
.docx投递件，第一位放 HTML 预览、第二位放 docx 供下载，两个一起给用户。 - 不置顶、靠措辞强化：所有板块内部履历一律时间倒序，不用「匹配度置顶」或跨板块挪位；需要突出时只通过措辞强化。
- 技能区精简：技能与工具区只留「软件使用 + 语言能力」；能力描述类条目默认删，仅当 JD 着重强调某项能力时留 1 条总结。跨领域背景仅在 JD 强调时写一次。
- 求职意向精简 + 位置固定：只写
求职意向：<方向>，JD 要求出差 / 轮岗才补「接受出差」，其余一律不写；位置必须在头部信息区，严禁插进教育背景板块内部。 - 项目标题只写名称本身、不加说明性标签；标题后加角色用竖线「｜」分隔。
- 教育背景归属 + 版式：荣誉 / 奖项等信息挂到对应学历条目下，不跨学历混排；每条学历学校名后紧跟院校层次标签（如「（985）」「（211）」）；学校 / 学院 / 专业 / 学位用
·串成一行，每条学历只占 1 行。 - 投递登记状态默认「已投递」：改完简历即登记，最新状态字段直接填「已投递」，不区分准备 / 待投。
- 不多扩展：不做「网申自动填表」。
- 证书诚实：备考中写「备考中」、未取得写「无」，不勾「已取得」。
- 求职方向主线：投递素材、自我评价优先对位主线方向（由用户在初始化时设定），挑素材时优先对位主线表达。
- 诚实边界：写「原型」不写「体系 / 系统」、写「借助 AI / 工具」不写「独立研发」；简历不写暴露企业规模、阶段、亲属关系的字眼与敏感数字，这些留到面试口头讲。
八、参考既有实例（复制其措辞风格与结构）
- 一份标杆简历 HTML / docx（展示经历措辞强化的写法）
- 一份
JD匹配矩阵-<公司岗位>.md（矩阵模板） - 一份
gen_docx_<公司>.py（docx 脚本参考，含统一处理 list / str 的函数）
示例文件见
examples/（使用完全虚构的身份与经历，仅演示结构与措辞风格）。