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