先记住这件事
当项目没有明确指标时，用范围、交付、质量、反馈和前后变化写出可信成果。
直接结论： 简历成果不等于必须写百分比。没有可靠数据时，可以写清交付范围、问题前后变化、质量改善、复用范围、用户反馈和风险降低。真实而具体的事实，比无法解释来源的“提升 50%”更有说服力，也更经得住面试追问。
先确认你真正知道什么
回忆项目时，把信息分成三类：
- 确定事实： 上线了哪些功能、支持多少模块、解决了什么故障。
- 可以核实： 发布记录、需求数量、版本周期、使用团队、测试结果。
- 无法确认： 凭印象估算的效率、没有统计口径的百分比、团队口头评价。
简历优先使用前两类。第三类可以描述方向，但不要伪装成精确指标。
五种不依赖虚假数字的成果
1. 交付结果
例如“按计划完成核心流程上线”“将分散页面迁移到统一组件体系”。
2. 覆盖范围
例如“支持客户、订单和权限三个模块复用”“适配桌面和移动端”。
3. 前后变化
例如“从手工配置改为后台可视化维护”“从每页重复实现改为统一能力调用”。
4. 质量与风险
例如“补齐异常兜底和回滚方案”“解决重复请求导致的状态错乱”。
5. 反馈与采用
例如“方案被后续模块沿用”“通过验收并进入日常使用”。反馈必须是实际发生过的。
对照示例
风险较高的写法
优化系统性能，页面速度提升 80%。
如果没有测量环境、指标和记录，这个数字很难解释。
更可信的写法
定位首屏资源过大和重复请求问题，拆分非首屏模块、合并并发请求，并在相同测试环境复测加载过程；上线后持续观察错误率和核心页面加载情况。
如果确实保留了测试数据，可以进一步写明指标名称、测试条件和变化区间。
如何补做合理测量
项目仍可访问时，可以补充一次诚实的复盘：
- 选择与目标相关的指标。
- 固定设备、网络、数据量和测试步骤。
- 记录优化前后多次结果。
- 说明这是测试环境还是线上数据。
- 同时关注副作用，而不是只展示最好的数字。
不要把事后单次测试包装成长期线上成果。
常见问题
没有任何数据会不会显得很弱？
具体事实本身就是证据。说明你解决的问题、承担的范围、采用的方案和最终状态，通常已经比泛泛的“负责、参与、熟悉”更强。
团队结果可以写进个人简历吗？
可以写项目整体结果，但要明确自己的贡献。避免让读者误以为所有成果都由你独立完成。
可以用“大幅、显著、明显”吗？
如果没有清楚的观察依据，尽量少用。可以改成可验证的前后状态。