resume-backend-project-optimizer

name	resume-backend-project-optimizer
description	将中文后端项目经历改写为高质量、可面试追问、强数据化的简历要点。适用于用户提供“项目经历/主要工作/职责描述”后，要求按统一模板输出“负责xxx功能 + 关键技术细节组合 + 解决问题 + 数据化结果”的场景；适用于 Java 后端求职、简历优化、面试前项目复盘，且需要对齐面试高频考点（Java 集合与并发、MySQL、Redis、Spring、消息队列、系统设计等）时使用。

Resume Backend Project Optimizer

按以下流程处理用户输入的项目经历，并输出可直接粘贴到简历的中文要点。

1) 严格输出目标

将每条项目经历改写为下面模板（优先使用模板A，数据不完整时可用模板B）：

模板A（数据化）：

负责{业务功能}，基于{技术细节组合}实现{关键机制}，解决了{具体问题}，将{指标1}从{before}提升至{after}（{变化幅度}），并将{指标2}从{before}降至{after}（{变化幅度}）。

模板B（工程治理）：

负责{业务功能}，基于{技术细节组合}实现{关键机制}，解决了{具体问题}，实现了{功能解耦/负载治理/一致性保障/防丢失/防重复/防超卖}，并通过{可观测信号或验证方式}完成上线验证。

格式要求：

输出中的技术关键词与数据指标统一使用 Markdown 加粗（**...**）。

可选扩展句：

沉淀了{可复用资产/规范/平台能力}，支撑{场景规模}并通过{稳定性指标}验证。

2) 硬性约束

• 只写后端相关内容，不写前端技术与页面交互细节。
• 禁止使用空泛词：显著、大幅、明显、较好、很多、海量 等。
• 禁止只写宽泛技术名：Java、MySQL、Spring、MyBatis。
• 必须写到技术细节层级，例如：
  • Java: ArrayList、HashMap、ConcurrentHashMap、CompletableFuture、CAS、ThreadPoolExecutor
  • MySQL: B+Tree覆盖索引、最左匹配、MVCC、行锁/间隙锁、Undo/Redo/Binlog
  • Spring: AOP、事务传播行为、自定义注解、三级缓存、Bean 生命周期
  • Redis: Lua 脚本、ZSet、Pipeline、过期策略、缓存一致性方案
• 每条经历优先包含 2 个可量化指标（性能、时延、吞吐、错误率、成本、资源占用、SLA 等）。
• 若用户数据不完整，允许“1 个量化指标 + 1 个工程治理结果”组合；若暂无量化数据，必须保留待补字段并写清工程治理结果。
• 指标必须绑定到具体对象（接口/链路/任务），示例：防伪验证查询接口 P99、订单查询链路 P95、邮件投递任务吞吐。
• 禁止写法：接口 P95/P99、Pxx接口、P96接口、性能提升（未指明具体对象）。
• 必须写法：{具体业务对象}{接口/链路/任务}，例如：防伪验证查询接口、售后工单提交流程链路、邮件投递任务。
• 负责xxx可写为功能模块级（如负责售后工单功能），也可写为接口级（如负责防伪验证查询接口）；若写功能模块级，后文至少落到 1 个关键接口/链路。
• 技术关键词与数据指标必须加粗输出，例如：**Redis Lua**、**220 QPS**、**防伪验证查询接口 P99 88ms**。
• 允许且鼓励描述非纯数据成果：实现功能解耦、解决高峰负载过高、保证最终一致性、防止数据丢失、防止重复消费/重复提交、避免库存超卖。
• 工程治理结果必须具体到“对象 + 风险 + 机制”，禁止空泛写法：优化了架构、稳定性更好。
• 每条经历必须可被面试深挖：能回答“为什么这么设计、如何保证一致性、如何压测验证、失败场景怎么兜底”。

3) 改写流程

1. 提取原始信息：业务目标、瓶颈问题、技术手段、结果数据。
2. 将“宽泛技术点”替换为“可追问的实现细节”。
3. 绑定高频面试考点，优先覆盖：
   • Java 集合与并发（线程池参数、CAS、自旋与阻塞取舍）
   • MySQL（索引命中、锁冲突、MVCC 与事务隔离）
   • Redis（缓存模型、热点与穿透治理、Lua 原子性）
   • Spring（AOP 注解编程、事务边界、IOC 生命周期）
   • MQ（重试、幂等、削峰、最终一致性）
   • 系统设计（限流、熔断、降级、观测性）
4. 结果重写（数据化 + 工程治理）：
   • 优先使用用户给出的真实数据。
   • 用户未给数据时，输出待补字段，禁止虚构绝对值。
   • 可输出“计算公式 + 待补基线”，示例：P99 延迟由 {待补:ms} 降至 {待补:ms}（降幅 = (before-after)/before）。
   • 若该条核心价值是治理类成果，可写：将订单写入与库存扣减解耦为异步事件链路，防止下游抖动导致主交易超时，并通过重试成功率/死信堆积/补偿闭环验证。
5. 自检每条经历是否满足：
   • 有业务价值
   • 有技术深度
   • 有量化结果或工程治理结果
   • 有可追问点

4) 技术细节组合范式（优先复用）

• 限流治理：
  • Spring AOP + 自定义注解 + Redis Lua 动态令牌桶 + 网关层灰度开关
• 查询加速：
  • 冷热数据分层 + Redis 缓存近 7 天 + MySQL 覆盖索引 + 异步预热
• 并发优化：
  • CompletableFuture 编排 + ThreadPoolExecutor 参数隔离 + CAS 减锁竞争
• 一致性保障：
  • 本地事务 + Outbox 表 + MQ 重试 + 幂等键去重
• 库存与扣减：
  • Redis 预扣减 + Lua 原子校验 + 异步落库 + 补偿任务
• 大促稳定性：
  • 漏斗限流 + 熔断降级 + 隔离线程池 + 链路监控告警

5) 输出格式

先给“简历版要点”，再给“面试追问准备”。

A. 简历版要点

每个项目输出 3-6 条，单条长度控制在 45-90 字（中文）。 每条要点中的技术关键词与数据指标必须使用**加粗**标注。

B. 面试追问准备

每条要点后补 1 个可追问问题（用于面试复盘），格式如下：

可追问：为什么选择{技术方案A}而不是{方案B}？在{失败场景}下如何保证{一致性/可用性}？

6) 输入信息不完整时的处理

若用户缺少关键数据，先继续改写并标注待补字段，不中断流程。统一附加：

待你补充：QPS 峰值、关键接口/链路当前 P95/P99（如防伪验证查询接口、订单查询链路）、错误率、资源成本、上线前后对比周期。

7) 快速示例

原始描述（差）： 负责订单查询优化，使用 Redis 缓存，性能显著提升。

改写后（合格）： 负责订单查询功能，基于**冷热数据分层**（**Redis** 缓存近 7 天订单）+ **MySQL 覆盖索引** + **异步缓存预热**，解决高峰期慢查询与数据库连接池打满问题，将**订单查询接口 P99**从**820ms**降至**140ms**（**-82.9%**），数据库读**QPS**从**1.6w**降至**5.4k**（**-66.3%**）。

可追问： 为什么缓存 7 天而不是 30 天？如何处理缓存与数据库一致性、以及缓存击穿？

治理型示例（合格）： 负责订单履约链路改造，基于本地事务 + Outbox 表 + MQ 重试 + 幂等键去重，实现订单写入与库存扣减解耦，解决高峰期同步调用级联超时与消息重复消费问题，防止库存超卖与数据丢失，并通过死信堆积阈值、补偿任务成功率与对账一致率完成验证。