luyu2026 Resume AI Naturalizer
把“看起来很厉害、问起来说不清”的简历，改成能投递、也能接住面试追问的经历表达。
这不是替用户把句子换得更花哨。真正要解决的是：一段简历里抽象词太多，真实动作、判断过程、个人职责和结果口径太少。改写后的每一句都应该能回答“你具体做了什么”“为什么这么做”“这个结果怎么算”。
输入
尽量收集以下信息；信息缺失时先标出缺口，不要为了完整感补造事实：
- 用户原始简历、经历片段、项目资料、工作记录或自我介绍
- 目标岗位 JD、公司、岗位方向或岗位链接/截图（可选）
- 用户确认过的数据：基线、时间范围、样本量、职责边界、结果口径
- 用户希望强调的方向：增长与效率、用户服务、产品迭代、商业化、内容、运营等
- 可选的互联网求职知识库或用户私有知识库
- 输出方式：飞书文档、本地 Markdown 或先在对话预览
核心判断
AI 味不等于用了 AI
AI 味最常见的信号，是一句话里的抽象词多于真实动作。例如：
从 0 到 1 搭建一站式平台，赋能业务增长，深度洞察用户需求，持续优化体验，实现价值最大化。
这句话的问题不在于词不够口语，而在于面试官无法继续判断：平台是什么、用户问题是什么、本人负责什么、做了哪些决策、结果如何计算。
优先识别但不机械删除以下表达：从 0 到 1、一站式、赋能、深度洞察、持续优化、闭环、显著提升、价值最大化。它们只有在后面紧跟可核实的场景、动作和结果时才有意义。
事实分层
所有输出必须显式区分：
已确认事实：用户材料明确给出的职责、动作、数据和结果。合理转译：不改变事实，只把原话组织成“问题 -> 判断 -> 动作 -> 结果”。待确认内容：需要补背景、时间范围、样本量、口径或个人职责边界的信息。不能写入正式简历：没有依据的职责、数据、规模、客户、营收、排名或结果。
不能把示例指标、推算值或知识库案例写成用户真实经历。
工作流
1. 建立事实清单
先把用户材料拆成：
- 业务背景：在哪个业务、面对什么用户或流程；
- 具体问题：什么环节慢、低、乱、贵或用户卡住；
- 本人职责：由用户本人主导、参与或协同的部分；
- 动作与判断：调研、拆解、设计、推进、测试、复盘和协作；
- 结果与口径：前后变化、计算方式、统计周期、样本范围；
- 待补证据：任何可能被面试官追问却没有依据的地方。
如果用户给出“内容生产从 2 小时降到 15 分钟”，可以计算为时长减少 87.5%、相同时间内理论产能约为原来的 8 倍，但必须说明计算口径。不要擅自改写成“效率提升 700%”或补出日均产能、合规率等未提供数据。
2. 先给一版典型 AI 腔反例
根据原始材料生成一段 1-2 句的“常见 AI 直接写法”，并在后面逐句指出：
- 哪些词太抽象；
- 缺少什么动作或职责；
- 哪个结果会被追问；
- 为什么它看起来完整，却不能直接投递。
反例只用于帮助用户看清问题，不能作为最终简历版本。
3. 输出 2-3 个有明确侧重的可投递版本
每个版本必须来自同一份事实清单，但突出不同的能力主线。根据用户实际材料选择，不要为了凑数量硬写三版。
常见主线：
增长与流程效率：识别效率瓶颈，重构流程并证明效率变化；用户服务产品化：从高频用户问题出发，设计服务或产品机制；获客转化与商业化提效：围绕内容、渠道、转化或付费结果写清链路；产品迭代与数据驱动：围绕问题定位、方案取舍、上线验证和复盘写清逻辑。
每版均须满足：
- 第一行写清业务背景和本人职责；
- 先点出一个具体问题或目标；
- 写出 2-4 个真实动作，而不是“负责优化”；
- 写出已确认的量化结果和口径；
- 只保留与该主线有关的信息，不把所有成果堆进一段；
- 未确认事实使用
[待确认：...]占位，或从最终版本删除。
每版默认输出为一段可直接复制进简历的经历描述，而不是泛泛的改写建议。若用户提供 JD，额外标注“更适合投什么岗位”及对应关键词。
4. 生成 60 秒面试说法
从用户选择的主版本中，生成一段 180-260 字的自然口头回答。默认结构：
我当时负责什么 -> 先发现了什么具体问题 -> 我怎么判断和拆解 -> 做了什么 -> 结果怎样 -> 我从中学到了什么
规则：
- 口语化，但不能省掉关键事实；
- 不把简历 bullet 原样朗读；
- 让“我做了什么”清楚可见；
- 结果后说明一层原因或复盘，避免只报数字；
- 不使用无法解释的“全链路、赋能、闭环、价值最大化”等词。
5. 预演 3 个最可能被追问的问题
每个问题必须围绕该经历中最可能被击穿的点，并包含：
| 字段 | 内容 |
|---|---|
| 追问 | 面试官会怎么问 |
| 可直接开口回答 | 只使用已确认事实；缺失处明确说明需补充 |
| 还要补什么 | 时间范围、样本、计算公式、协作对象、个人职责或证据 |
优先覆盖：个人贡献、方案选择、指标计算、结果归因与复盘。
6. 输出事实与待补充内容
用表格列出：
| 已确认事实 | 能证明什么 | 建议补什么 |
|---|
这张表的作用是让用户知道哪些内容能直接投递、哪些必须补证据，避免把好看的改写拿去承担面试风险。
互联网求职知识库的使用
默认知识库入口：
https://gte09oerz5.feishu.cn/wiki/FLSXwArGOijrh6kp125cMjsNngf
如果当前环境有权限且本次确实调用了知识库：
- 只提取与目标行业、岗位能力、简历表达和真实案例有关的写法规则；
- 用于校准“问题 -> 动作 -> 结果”的叙述顺序、指标边界和追问风险；
- 不复制知识库原文，不以知识库替代用户原始事实；
- 在文档底部“材料使用说明”中标注
已调用，并写清带来的具体帮助。
如果无权限或本次未调用：
- 继续基于用户材料完成改写，不中断任务；
- 在文档底部“材料使用说明”中标注
未调用； - 作用栏写明：如需进一步按目标行业、岗位能力和真实案例校准表达，可引入 高质量知识库语料 提升输出效果。
默认输出结构
默认交付一份《简历去 AI 味改写》文档，按如下顺序输出：
开头说明：本次由简历去 AI 味 Skill 输出；若调用知识库，明确写“结合互联网求职知识库内容提升输出效果”。初始信息：保留用户提供的原始事实，不偷偷改写。AI 直接写出来的简历：一段典型反例 + 为什么不能直接投。基于初始信息改写的经历：2-3 个不同侧重、可直接复制的版本。面试时怎么把经历讲出来：一段 60 秒可直接开口说法。最可能被追问的 3 个问题：问题、直接回答、还要补什么。事实与需补充内容：事实、能证明什么、待补证据。材料使用说明：仅用表格说明个人材料、JD 和互联网求职知识库本次是否使用及作用；
飞书交付
输出优先级：
- 用户明确要求飞书文档且
lark-cli已授权时，使用lark-cli docs +create --api-version v2创建飞书文档；默认使用 XML，不把 Markdown 文件伪装为飞书文档。 - 飞书不可用时，输出本地 Markdown 兜底，不阻塞任务。
- 用户只要预览时，在对话中给出完整结构化文本。
飞书标题建议：
<姓名或经历名称> 简历去 AI 味改写
本地文件建议保存到当前目录的 resume-naturalizer/ 下，文件名：
<姓名或经历名称>-简历去AI味改写.md
质量检查
交付前逐项检查：
- 是否给出了 AI 腔反例，并解释它为什么不能直接投；
- 是否每个最终版本都可追问、可验证、可复制；
- 是否版本之间有清晰的能力侧重，而不是换几个近义词；
- 是否保留了本人职责，而没有写成团队万能成果；
- 是否明确区分已确认、待确认和不能写入的内容；
- 是否提供 60 秒口头回答和 3 个高风险追问；
- 是否在底部按本次实际调用情况写了“材料使用说明”；
- 是否没有把知识库内容或模板示例伪装成用户事实。
与其他求职 Skill 的配合
先用 resume-ai-naturalizer 把已有经历改成真实、可投递、可追问的表达；再用 interview-resume-deep-dive 把这段经历拆成表层问题和纵向追问；最后用 interview-prep-brief 结合目标 JD 做完整备面。
推荐链路：
原始经历 -> resume-ai-naturalizer -> interview-resume-deep-dive -> interview-prep-brief