年终自评先写工作改变了什么，再写自己做了什么。提交记录可以帮你回忆，不能直接代替产出：代码改得多、会议参加得多，都没有回答这件事为什么值得做。
十一月整理材料，先别急着写漂亮句子。把年初目标、年中调整和实际承担的任务放在一起，看哪些交付对应原来的承诺，哪些是后来增加的工作。否则忙了一整年，最后只按印象挑出最近那个项目，前面的维护和协作就被漏掉了。
从一件事的前后状态开始
比如你改了发布检查流程。不要只写「完善发布规范，保障系统稳定」，先交代旧流程有什么具体缺口：配置改动依赖口头提醒，执行人可能遗漏检查。再写你增加了什么校验、由谁确认、遇到异常如何停止，最后说明实际使用到了哪些发布场景。
这段话不一定带百分比。没有同口径的记录，就别补一个「效率提升」。可以陈述已确认的变化：过去要临时找人确认的项目，现在有明确负责人和检查结果；尚未覆盖的特殊发布，仍需要人工处理。结果有边界，比一个来路不明的数字更经得住讨论。
如果确实有数据，要能回答统计的是什么。发布耗时是否包括等待审批，故障数是否只统计本系统，改进前后观察期是否可比。业务量变化、团队人数变化也可能影响结果。不能把同一时期出现的所有好转，都归到自己的那次改动上。
把团队结果和自己的贡献分开讲
团队交付了一个新模块，你负责其中的接口设计和上线验证，就把这两块说清楚。可以先交代整体结果，再解释自己做出的判断、解决的阻塞，以及与别人的接口。把整个系统都写成个人产出，追问时反而很难站住。
协作也不必写成「积极沟通」。比如两个团队对异常状态的含义不同，你整理了状态说明，组织双方走查失败路径，补上验收样例。这能说明协作解决了什么问题。至于谁实现了底层能力、谁做了业务验收，同样保留各自的归属。
对维护工作，可以从反复发生的成本下手。处理了一次告警，是一次响应；发现同类告警总要临时找人，补齐定位入口和轮值说明，是流程改善。两者都值得记录，但含义不同。别为了显得有影响，把日常响应全部包装成体系建设。
没有完成的目标，也要写出当前状态
例如迁移只做完了部分模块。先说明原定范围和实际进度，再解释未完成的原因、已经暴露的风险、接下来需要的资源或决策。不要把「完成方案设计」写成「完成迁移」，也不要因为项目暂停，就把已验证的工作全部抹掉。
原因里区分外部变化和自己的判断。需求被调整，是背景；你发现依赖变化后何时同步、怎样缩小交付范围，是可以复盘的个人动作。自评不是要求你把所有问题揽下来，也不是只列别人造成的阻碍，而是让对方看见你如何处理变化。
有些工作暂时没有业务结果，可以写清已经降低了哪种不确定性。比如验证发现现有方案不能满足某项约束，团队因此停止继续投入。这里的成果是验证结论和决策依据，不能进一步声称已经节省了多少成本，除非有可核实的测算。
带着材料对齐评价口径
初稿整理成几项主要产出后，找负责人确认：本周期更看重交付、质量、协作还是职责扩展，哪些事实还需要补充。评价规则以所在团队实际要求为准，不要从别处抄一套权重套上去。临近评审再争论双方默认的标准，沟通成本会很高。
材料不需要整包复制。内部记录保留在获准的工作环境里，自评中标明能定位到的记录名称和时间即可。涉及客户、账号或业务敏感信息的内容，按内部要求处理。整理个人产出，不等于为自己另存一份公司资料库。
最后通读一遍，删掉那些换个人名字也成立的形容词。每项重要工作至少能讲清起点、动作、结果和不足；篇幅有限时，宁可少放一项，也别把最关键的变化埋在长长的事项列表里。
你今年最想写进自评的那件事，如果删掉「推动」「赋能」「保障」这些词，还能看出什么具体变化？