jerry-ai-dev Resume Writer
基于"写作原则 + 项目亮点 + 包装边界 + 用户画像 = 定制化简历"模型生成智能预约系统项目经历。默认中文输出，用户要求时提供英文版。
工作流程
Phase 1: 加载知识
开始写简历前读取：
- references/resume_principles.md - 四段式结构、技术标签、亮点挖掘策略、常见误区
- references/project_highlights.md - 智能预约系统技术亮点、源码锚点、量化角度
- references/packaging_reference.md - Agent 记忆、反思、父子 Agent、RAG/MCP 包装方向与边界
- 按需读取
project_packaging_report.md、README.md或对应源码文件补充实现细节
如果用户明确要求突出"接入自研 Modular RAG MCP Server"，再读取同工作区 Modular RAG MCP Server 项目的 README.md、DEV_SPEC.md 或 .github/skills/resume-writer/references/project_highlights.md 中相关内容。
Phase 2: 用户画像采集
用 vscode_askQuestions 一次性收集，最多 4 个问题：
问题 1 - 目标岗位（单选）：
- Agent Engineer / LLM Application Engineer / RAG Engineer / Backend Engineer / MLE / 全栈 AI / 产品型 AI 工程
- 决定：关键词策略、亮点筛选优先级、包装强度
问题 2 - 业务背景（自由文本）：
- 必须主动引导用户提供真实背景，用于生成"背景"段。
- 问题文本示例：
简历背景段需要真实业务场景。请描述这个项目想对应的业务背景：门店规模、前台排班痛点、预约量、技师管理复杂度、用户咨询/预约流程中最麻烦的问题。若想使用默认按摩门店智能预约场景，也可以直接写"默认场景"。 - 默认场景：按摩/推拿门店前台需要同时处理客户咨询、技师排班、项目选择、偏好记录、预约确认和回访推荐，人工处理容易漏信息、重复询问、推荐不稳定。
问题 3 - 技术侧重（多选）：
- Multi-Agent 编排 / 预约状态机与技师匹配 / 用户记忆与偏好学习 / 自我沉淀与反思 / RAG 咨询与知识库 / MCP 知识层接入 / FastAPI 流式响应 / 分层架构与数据库 / 测试与工程化
- 如果用户选择 Agent Engineer，建议默认勾选：Multi-Agent 编排、用户记忆与偏好学习、自我沉淀与反思、MCP 知识层接入。
问题 4 - 特殊要求（自由文本）：
- 示例："往 Agent 方向靠"、"别写太虚"、"中英双版本"、"控制 5 条 bullet"、"帮我给量化指标建议"、"包装大胆一点但面试要能圆回来"。
Phase 3: 内容生成
3.1 亮点匹配
从 project_highlights.md 按岗位和用户侧重选择 3-5 个亮点：
| 岗位方向 | 优先亮点 |
|---|---|
| Agent Engineer | 亮点1(Multi-Agent 编排) -> 5(用户记忆) -> 6(反思闭环) -> 9(RAG/MCP 知识层) -> 8(流式体验) |
| LLM Application Engineer | 亮点1(Multi-Agent) -> 2(预约状态与匹配) -> 4(RAG 咨询) -> 7(模型 Provider/Embedding) -> 8(流式响应) |
| RAG Engineer | 亮点4(FAISS 知识库) -> 9(Modular RAG MCP 接入) -> 7(Embedding/Provider) -> 10(测试与评估) -> 3(分层架构) |
| Backend Engineer | 亮点3(分层架构) -> 2(预约业务流) -> 8(Async/Streaming) -> 10(工程化测试) -> 5(数据模型) |
| 产品型 AI 工程 | 亮点2(预约自动化) -> 5(长期偏好) -> 6(回访推荐) -> 4(知识咨询) -> 1(统一入口 Agent) |
用户的技术侧重优先覆盖默认排序。若用户要求"包装"，必须同时参考 packaging_reference.md 的允许/禁止边界。
3.2 四段式内容生成
严格遵循 resume_principles.md 的四段式结构：背景 -> 目标 -> 过程 -> 结果。
段 1：背景
描述业务场景、服务对象和痛点。必须基于用户在问题 2 提供的背景；如果用户写"默认场景"，使用按摩门店智能预约默认场景。
默认背景示例：
- "针对按摩/推拿门店前台在高频预约、技师排班、客户咨询和偏好记录中高度依赖人工的问题，设计智能预约 Agent 系统，服务于门店客户咨询、预约确认、技师匹配和回访推荐流程。"
段 2：目标
说明技术目标和改进方向，体现技术判断力。模式：为解决[业务问题]，目标构建[系统定位]，实现[核心能力]，达成[预期效果]。
示例：
- "目标构建一个面向本地服务业的多 Agent 智能预约系统，通过任务分类、预约状态管理、RAG 咨询和用户偏好记忆，降低前台重复沟通成本并提升预约推荐准确性。"
段 3：过程（Bullet Points）
以 4-6 条 bullet 展示关键技术方案和工程实现。每条遵循：
- 动词开头：设计 / 实现 / 构建 / 优化 / 集成 / 抽象 / 主导
- 三段式：做了什么 -> 用了什么技术 -> 达成什么效果
- 夹带关键词：LangChain、Multi-Agent、RAG、FAISS、Embedding、MCP、FastAPI、SQLAlchemy、Streaming、Repository Pattern
- 量化收尾：尽量附带指标；没有真实数字时标注"建议值，请按实际调整"
段 4：结果
用独立段落总结项目成果，集中展示 3-5 个核心量化指标。结果段可以使用建议值，但必须显式提醒用户确认。
3.3 量化指标
如用户提供真实数字，优先使用。未提供时，可建议合理值并标注"建议值，请根据实际压测/测试结果调整"。
| 指标类型 | 建议范围 | 说明 |
|---|---|---|
| 意图路由准确率 | 85%-95% | 预约/咨询/无关问题分类 |
| 预约信息抽取完整率 | 80%-92% | 项目、时间、时长、技师偏好、性别偏好 |
| RAG Top-3 命中率 | 80%-90% | 服务项目、价格、门店规则等知识咨询 |
| 知识检索延迟 | 300ms-1000ms | FAISS 本地索引检索，需本地验证 |
| 首 token 延迟 | 500ms-1500ms | FastAPI + AsyncGenerator 流式响应 |
| 重复询问减少 | 20%-40% | 依赖长期偏好记忆，需业务日志验证 |
| 测试用例数 | 30 个测试函数 | 当前 tests/ 下 4 个核心 Agent 测试文件 |
| 知识库规模 | 10+ 默认知识条目 | 可根据实际业务扩展 |
| 技术模块数 | 5 层架构 + 3 类核心 Agent | Web/API/Agents/Services/DB + 预约/咨询/行为分析 |
Phase 4: 输出格式
严格按以下模板输出：
**[项目名称]** | [时间段] | [角色]
**背景**：[2-3 句描述业务场景、服务对象、痛点]
**目标**：[1-2 句说明技术目标、核心能力、预期效果]
**过程**：
• [Bullet 1：Multi-Agent/架构/业务主线] - 动词开头 + 技术细节 + 效果
• [Bullet 2：预约状态机/技师匹配/偏好记忆] - 动词开头 + 工具/方法 + 量化
• [Bullet 3：RAG/知识库/MCP] - 动词开头 + 检索方案 + 可信知识上下文
• [Bullet 4：工程化/流式/数据库] - 动词开头 + 实践 + 数据
• [Bullet 5：可选扩展：反思闭环/评估/测试] - 动词开头 + 指标 + 影响
**结果**：[2-3 句汇总核心量化指标；若使用建议值，标注需要确认]
**技术栈**：[按岗位权重排列的关键词列表]
约束：
- 背景、目标、过程、结果缺一不可。
- 过程段默认 4-6 条 bullet，除非用户指定。
- 每条 bullet 不超过 90 字。
- 结果段必须包含至少 3 个量化指标或建议指标。
- 项目名称默认"智能预约与服务咨询 Agent 系统"，用户可改。
- 不要把尚未生产化的规划写成已完全落地。
Phase 5: 迭代与面试准备
- 展示初稿，询问用户是否调整岗位方向、包装强度、量化指标或篇幅。
- 根据反馈生成第二版、短版、英文版或 ATS 关键词版。
- 主动提供 3-5 条面试追问预测，例如：
- "TaskClassificationAgent 如何维护多轮状态？AgentRouter 如何避免状态混乱？"
- "预约 Agent 怎么从自然语言里提取时间、时长、技师偏好？失败时怎么追问？"
- "用户偏好记忆写在哪里？如何避免把一次偶然选择当成长期偏好？"
- "RAG 当前用 FAISS 怎么存、怎么更新、怎么评估命中质量？"
- "你说接入 Modular RAG MCP Server，当前项目已有基础是什么，增强规划是什么？"
放大策略
| 维度 | 允许 | 禁止 |
|---|---|---|
| 业务场景 | 包装为真实按摩/本地服务业智能预约落地 | 编造公司名、真实营收或不存在客户 |
| Agent 架构 | 强调中心化多 Agent 编排、任务拆解、统一入口 | 声称已有复杂 P2P 子 Agent 通信 |
| 记忆功能 | 说已有会话状态和用户偏好数据基础，并按分层记忆方向设计 | 声称完整实现成熟商用级长期记忆系统 |
| 自我沉淀 | 说基于用户行为分析做复盘和推荐闭环设计 | 空泛写"Agent 会自主学习"且无法解释数据来源 |
| RAG/MCP | 说当前有 FAISS 知识库基础，可接入自研 Modular RAG MCP Server 作为知识层 | 把 RAG 说成 Agent 框架本身，或声称已完整生产集成 |
| 量化指标 | 给合理建议值并要求用户确认 | 编造无法压测或无法解释的生产级规模 |
反模式检查
输出前检查简历不包含：
- 泛化描述："负责 AI 系统开发"、"参与 Agent 项目"。
- 工具堆砌：只列 LangChain、FAISS、FastAPI，不解释作用。
- 缺失业务场景：看不出为什么按摩预约需要 Agent。
- 过度包装：成熟框架、反思、记忆、MCP 全部说成已经完整上线。
- 缺失量化结果或建议指标。
- 被动语态过多："参与"、"协助"、"了解"。
- 面试中无法用源码锚点解释的声称。