怎样写一份可核验的项目案例

项目完成了，作品集却只剩一句“效果很好”。读者能够看到结果，却不知道你做了什么、为什么这么做，也不知道结果能说明多大范围的能力。一份可核验的案例，应把任务、个人贡献、观察结果和证据连接起来。

这里提供案例整理方法。它适合求职作品集、项目交接和服务复盘；没有真实材料时，应把内容写成练习方案，不能补成亲历故事。

从问题与责任开始

写清项目发生的时间、目标与条件。不要先堆行业背景，再让读者猜任务是什么。说明哪些资料可以使用，有哪些时间或资源限制，以及你对什么负责。

团队项目尤其需要区分个人与团队的工作。你设计了表单，不等于你完成了整个业务系统；你参与讨论，不等于最终方案由你独立决定。

解释一次真正的选择

挑出一个影响结果的选择，写明当时有哪些选项，采用哪一个，依据是什么。依据可以是不完整的，但要承认当时不知道什么。

下面是虚构教学场景：一个报名表单收到较多“提交不了”的反馈。负责者先检查错误提示和必填项，而没有立即重做整页。理由是先复现阻断提交的问题。这个场景用来展示叙述结构，不代表 IPVU 的实际项目或调查结果。

写案例时，可以把“优化用户体验”改成“发现手机号格式错误时没有可见提示，于是增加字段旁的说明”。后一句让读者知道你识别和处理了什么。

把结果与解释分开

如果调整之后完成率提高，先写观察到的变化，再讨论可能原因。样本变化、流量来源、活动内容等，都可能影响结果。仅有前后比较，通常不足以把变化完全归于一个改动。

没有量化数据时，可以写出已完成的验收与未完成的检查。不要为了让案例看起来专业而编造百分比。截图也可能经过挑选；过程记录本身并不自动证明因果、真实性或可重复性。

让读者能够核对，又不暴露别人

证据应当可定位，例如版本号、测试日期或公开链接。公开客户材料之前取得相应授权，移除个人信息与商业敏感信息。如果只能展示脱敏片段，解释脱敏范围和因此无法公开的部分。

案例可以以一个尚未解决的问题结束。读者从中看见你的判断过程，比读到一个没有漏洞的成功故事更有参考价值。

方法说明

本文为 IPVU 的项目表达建议，教学场景为虚构；没有声称过程记录比结果展示必然更可信。修订时合并了旧稿“能力证据链”和“过程记录”主题，删除了把连续成果、截图或单次验证当作充分证明的判断。