投了三十份简历没有回音，项目栏写的是"负责后端开发，使用 Spring Cloud 完成订单系统开发"。问题不在不够详细——是它没有给出任何一个可以追问的点。筛简历的人在三十秒里只判断一件事：这个人值不值得聊十分钟。
所以判据不是"写全"，而是"让人想追问"。写全了没人问等于白写；写窄但每句带钩子，反而进面试。这一栏是提问的种子，不是流水账。
1. 判据：读者读完会不会产生一个具体问题
| 项目栏的写法 | 读者读到什么 | 会不会追问 | 追问的深度 |
|---|---|---|---|
| "负责订单模块开发" | 一个岗位名 | 不会 | —— |
| "使用 Spring Boot、MyBatis、Redis、Kafka" | 一份技术清单 | 可能，但只问"用过吗" | 名词层 |
| "订单查询 P99 从 1.2s 降到 240ms，靠改分页与预热" | 一个有因果的改动 | 会 | 方法层：怎么改、代价是什么 |
| "把结算从 T+1 改成准实时，代价是放弃跨日重算" | 一个带取舍的决策 | 一定会 | 取舍层：为什么敢放弃、边界在哪 |
四行的差别不在文采，在信息结构：前两行只传递"我存在"，后两行传递"我做过判断"。面试官的时间只愿意花在第二种人身上。
反推方法：把目标岗位的 JD 抄下来，逐条问"这条要求对应我哪一处证据"。找不到证据的条目删掉，或换成真有证据的那条。堆一个用不上的名词，只换来一个答不上的问题。
─── 从 JD 反推追问点：一条 JD 要求 → 一处项目证据
要求 熟悉高并发下的缓存设计
证据 商品详情 QPS 峰值期走两级缓存，热点 key 打散 ← 会被问：怎么发现热点
要求 有分布式事务处理经验
证据 下单扣库存走本地消息表 + 定时补偿，接受秒级不一致 ← 会被问：补偿失败呢
// 每条证据后面都要能接住一个"然后呢"，接不住的先不写
2. 四件事：做了什么、难在哪、你怎么做、结果如何
| 要回答的 | 写不出来的信号 | 一句话模板 |
|---|---|---|
| 做了什么 | 只能说出职位，说不出系统边界 | "为 X 业务方提供 Y 能力，覆盖 Z 类请求" |
| 难在哪 | 说"没什么难的"或"就是量比较大" | "难点在 A 与 B 冲突：要 A 就得牺牲 B" |
| 你怎么做的 | 只说用了什么框架 | "用 A 换 B，代价是 C，用 D 兜住 C" |
| 结果如何 | 只有"上线了""运行稳定" | "指标从 P 到 Q，口径是 R" |
"难在哪"最能区分人，而多数人恰好省略它：写难点等于暴露当时的挣扎，而简历天然想显得干净。可对读者来说，没有难点的项目没有信息量——顺利完成的活，谁做都一样。
难点要写成冲突，不要写成"工作量"。以下三种写法只有第三种有钩子：
| 写法 | 为什么无效 |
|---|---|
| "项目复杂度高，涉及多个系统" | 复杂度是感受，不是事实 |
| "日均处理百万级请求" | 是规模，不是难点；规模大但逻辑简单的事很多 |
| "库存扣减要求强一致，但下单接口的 SLO 是 200ms，二者只能选一个" | 冲突明确，取舍可讨论 |
─── 一条项目条目的骨架：四行就够，多写是稀释
project: 订单结算链路重构
scope: 3 个服务、2 张核心表，我负责结算与对账
hard: 对账要求日终一致，而结算要准实时；只能放弃跨日重算
did: 本地消息表 + 幂等键 + 定时补偿；把重算挪到离线批
result: 结算延迟从 T+1 缩短到分钟级，补偿失败率按周统计 < 0.1%
// 每条都要能被追问三次；被问第二次就空的那条，删掉
3. 数字：比例优于绝对值，区间优于单点
数字是双刃剑。给对了是可信度的锚；给错或给不出处，比不给更糟——每个数字都会招来一句"怎么测的"。
| 数字形态 | 可信度 | 什么时候用 |
|---|---|---|
| 比例（"失败率从 3% 降到 0.2%"） | 高 | 有基线、有同口径对比时 |
| 区间（"P99 在 200–300ms 之间"） | 高 | 波动本身是事实的一部分时 |
| 单点绝对值（"响应时间 250ms"） | 低 | 除非同时给出环境与口径 |
| 总量（"支撑百万用户"） | 低 | 极少数场景，且要能说清是注册量还是日活 |
| 无归因数字（"性能提升 40%"） | 最低 | 不给 |
三条硬规则：
- 比例优于绝对值。绝对值离开环境就没有意义，比例自带对照。
- 区间优于单点。单点数字暗示你只测过一次，区间暗示你知道分布。
- 不给归因的数字不如不给。"提升 40%" 提升的是什么指标、在什么负载下，缺一个就不成立。
─── 改写：从不可验证到可验证
- 我优化了系统性能，接口响应速度提升明显
+ 订单列表接口在 500 并发下 P99 从 1.2s 降到 240ms
+ （口径：同一压测脚本、同规格机器、缓存预热后 5 分钟均值）
- 负责缓存改造，QPS 提升 3 倍
+ 详情页读请求命中率从 62% 提到 91%，回源量降到原来的四分之一
// 拿不出基线的，就写"改造后回源量下降"，不写倍数
"我优化了性能"要变成可验证的，只需要补三样：指标名、基线、口径。补不出来，说明当时没量过，那就老实写改了结构，别写效果。
4. 动词与人称：主导、参与、配合的边界
| 句式 | 隐含主张 | 追问后的风险 |
|---|---|---|
| 负责 X | 你是这块的 owner，出了事你兜 | 说不清边界与技术细节，整段失效 |
| 参与 X | 你在团队里干了一部分 | 低，但信息量也低 |
| 协助/配合 X | 你是辅助角色 | 低，且容易被读成"没主导过" |
| 主导 X | 你定的方案，你推的落地 | 最高，必须能答"当时还有别的方案吗" |
问题不在哪个更高级，在主张与证据是否匹配。写了"主导"却答不出"为什么不选另一个方案"，损失的不是这一句，是整份简历的可信度。
| 主张 | 需要能答的三件事 |
|---|---|
| 主导 | 备选方案有哪些、为什么否掉、谁反对过 |
| 负责 | 边界在哪、和谁对接、出问题谁先知道 |
| 参与 | 你具体动了哪几个文件、哪段逻辑 |
| 配合 | 你交付了什么给谁、验收标准是什么 |
团队规模也要写准，但不要写成团队成果。"在 20 人团队中负责结算模块"是清楚的；"完成了日订单百万的结算系统"如果实际是十个人的活，面试官多问两个人名就散了。
─── 动词替换：把"做过"改成"做过判断"
负责 → 设计/定下/推动 // 后面必须跟一个被否掉的备选
参与 → 承担其中 X 部分 // 后面跟具体边界
协助 → 提供了 X 给 Y // 后面跟交付物
配合 → 与 Z 约定契约并实现 // 后面跟接口或协议
// 一句里出现两个"负责"，通常意味着两个都不深
5. 顺序、详略与项目类型
跳槽频繁时，项目按与目标岗位的相关度排，不按时间。时间序会让最近那段短命经历占据最贵的版面，而它往往既没深度也不好解释。
| 项目距今 | 该写多细 | 理由 |
|---|---|---|
| 6 个月内 | 四件事全写，含难点与代价 | 最可能被追问，必须接得住 |
| 1–2 年 | 写难点与结果，省掉实现细节 | 细节已模糊，写细了答不上 |
| 3 年以上 | 一行，只留系统规模与你的角色 | 占比越低越好，除非它是你的代表作 |
| 短于 6 个月且已离职 | 一行，或并入相邻项目 | 单独成段会引出"为什么走" |
不同类型的项目，写法差得很远：
| 类型 | 该写什么 | 不该写什么 |
|---|---|---|
| 开源项目 | 你提的 PR 解决了什么问题、被不被合并、维护者怎么评价 | star 数（不是你的贡献） |
| 内部系统 | 使用者是谁、替代了什么手工流程、SLA 多少 | 内部系统名与部门黑话 |
| 外包/乙方 | 交付了什么能力、你的技术决策、复用几次 | 甲方名字、合同金额 |
度量这一栏，用来自检而不是写进简历：
| 度量 | 怎么量 | 参考 |
|---|---|---|
| 面试追问率 | 对方主动就项目提问的比例 | 低于一半说明钩子不够 |
| 技术轮通过率 | 进入技术二面的比例 | 与追问率同向变化 |
| 被要求解释的比例 | 有多少条被问"这个数字怎么来的" | 高说明数字写得可疑 |
| 单份定制成本 | 为一家公司改简历要多久 | 超过半小时说明结构有问题 |
6. 排错与边界
| 现象 | 更可能的原因 | 处理 |
|---|---|---|
| 投了很多没回音 | 项目栏没有可追问点，不是学历问题 | 把第一条改成"冲突 + 取舍"式 |
| 有面试但总在项目轮挂 | 写了主导，答不出备选方案 | 降级动词，或补上被否掉的方案 |
| 面试官只问技术名词 | 名词堆太多，没有因果 | 每段只留两个名词，其余换成动作 |
| 被质疑数字 | 缺基线或口径 | 补口径，或改成区间与方向 |
| 一段经历反复被问为什么走 | 短项目单独成段 | 合并进相邻项目，或缩成一行 |
名词堆砌的反效果值得单列：每个技术名词都是一次提问授权。写了 Kafka 就要能答分区与顺序，写了分库分表就要能答路由与扩容。列五个只会答两个，剩下三个会把前两个的可信度一起拖下去。
| 场景 | 这套写法要换的地方 | 理由 |
|---|---|---|
| 校招 | 用课程项目/竞赛，重点写学习曲线与动手量 | 没有生产结果可量化 |
| 跨行转岗 | 把旧行业的领域知识写成"业务理解"证据 | 技术证据薄弱时，领域是差异点 |
| 非技术岗（产品/运维管理） | 写决策与协调结果，不写实现细节 | 读者不评估代码能力 |
| 管理层 | 写团队规模变化与机制建设 | 个人产出不再是主轴 |
─── 投递前十分钟自检
1) 每条项目后面，我能不能接住三个"然后呢"
2) 每个数字，我能不能说出口径与基线
3) 每个动词，等不等于我实际的角色
4) 每个名词，我能不能答到第二层
// 有一条答不上，就删掉那条，不要赌对方不问
7. 自测
- 你的项目栏第一句，能引出哪三个具体问题？
- "难点"写成工作量而不是冲突，读者会怎么理解？
- 为什么"提升 40%"不如"62% 到 91%"？
- 写了"主导"，你需要准备好回答哪三件事？
- 三段都不到一年的经历，按什么顺序排、各自写多细？
- 校招时这套"结果导向"的写法哪一部分要整段换掉？