一句话总结
IC工程师在AI时代的自我评估，不是把你参与过的项目清单列三页纸，而是让评估者看完之后相信：没有你，这个系统的某个关键路径会断掉。系统性影响不是喊出来的，是用因果链和可量化指标撑起来的。
适合谁看
这篇文章的预设读者是在中国科技公司做IC（集成电路）设计、验证、架构相关工作的工程师，你可能已经在某个AI芯片或AI相关系统团队里工作了一到三年，正在准备年度绩效评估、晋升答辩，或者只是想在下一轮绩效谈话前把自己的工作整理清楚。
你不是来看“如何写简历”的——那套东西你早会了。你来看的是：怎么把自己做的那些技术活儿，翻译成评估体系能读懂的语言。具体来说，你想知道怎么把“我负责了这个模块的验证”变成“我设计的验证方案让这个模块的defect escape rate从0.8%降到0.15%，支撑了项目提前两周流片”。
如果你现在手头正好有一份draft的自我评估，打开文档对着这篇文章一条一条过，你会知道哪些地方要重写，哪些地方要加数据，哪些地方要砍掉重练。
为什么你的自我评估看起来像项目流水账
每年绩效季，我会在内部debrief里看到几十份自我评估。有一种典型症状我称之为“项目列表病”：工程师把过去一年做过的项目按时间顺序排列，每个项目写三行，结尾加一句“完成了预期目标”。这种评估的问题不是写得不好，而是它完全没有回答一个问题——为什么是你，为什么是这个结果。
评估者读这种文档的感受是：换任何一个人做同样的项目，文字描述可以一模一样。系统不知道你在这个项目里的不可替代性在哪里。不是说你要吹牛，而是你的文字没有把那些只有你才知道的因果链条翻译出来。
系统性影响的核心不是强调“我做了什么”，而是强调“因为我做了X，所以Y发生了”。这里的Y必须是一个可以被验证的、可观测的结果，而不是“提升了团队效率”这种模糊表述。
你要做的第一件事是把过去一年所有的工作列出来，然后问自己一个灵魂问题：每一项工作，如果没有我，换一个人做，99%相同的结果，还是可能有30%以上不同的结果？后者的内容才是你应该放进自我评估的。
> 📖 延伸阅读：BlackRockAI产品经理岗位职责与面试要点2026
系统性影响的三层结构
描述系统性影响不是一句话说完就完事了。你需要构建一个三层结构：输入层、中间层、输出层。
输入层回答的是“你面对的是什么问题”。不是技术问题本身，而是这个问题被忽视或者没被解决会造成什么后果。一个好的输入层描述会让评估者立刻进入情境——“当时这个模块的功耗问题导致整个芯片的热设计功耗超标，面临推迟三个月流片的风险”。
中间层是你做了什么，为什么是你，以及你是怎么做的。这一层最忌讳的是只写“负责XX模块的验证”。你要写的是你的方法论选择、你在团队里的独特作用、你和别人的协作方式。同一件事，用不同的方式做，结果可能完全不同。
输出层是可量化的结果以及这个结果对更大范围的影响。这里要避免的是只写“功耗降低了20%”，你要写的是“功耗降低20%意味着在同等电池容量下，终端产品续航从8小时提升到9.6小时，直接支撑了客户下个月的产品发布”。
不是描述任务，而是描述因果链
很多工程师写自我评估时，会不自觉地用动词描述任务：“完成了XX模块的设计”“参与了XX项目的验证”“负责了XX技术的调研”。这种写法的问题在于，它描述的是你的动作，而不是你的动作产生的结果。
正确的写法是因果链导向：描述你面临的条件、你采取的行动、以及这个行动带来的可观测变化。
一个具体的场景是：你在一个AI加速器项目里负责某个计算单元的验证。错误的写法是“负责计算单元A的验证工作，发现并解决了20个bug”。
正确的写法是“计算单元A是整个加速器的核心数据通路，其验证质量直接决定流片后功能正确的概率。我设计了随机约束验证和形式验证结合的方案，针对边界条件增加了300个test case，使该单元在芯片回来后的first-silicon测试中零defect，支撑了整个加速器按时点亮”。
注意这两个写法的区别：前者描述的是你做了什么，后者描述的是你的工作对整个系统的意义，以及你用了什么方法达到了什么结果。
> 📖 延伸阅读：Amazon PMday in life指南2026
你的技术贡献如何变成可衡量的数字
IC工程师有一个常见的误区：认为自己的工作很难量化，因为很多产出是“质量”而不是“数量”。这种想法在评估体系里是致命的。
质量本身就是可以量化的。你要找到的是你工作的输出质量对下游的影响。
比如验证工程师可以用的指标包括：defect escape rate（逃逸到后端的缺陷率）、first-pass silicon success rate、验证覆盖率、发现的critical bug数量及影响。设计工程师可以用的指标包括：PPA（功耗、性能、面积）的具体改善、模块面积节省了多少平方毫米、时钟频率提升了多少MHz、对后续设计流程的复用价值。
一个更具体的例子是：你在AI芯片的内存子系统里做优化，让带宽利用率从65%提升到78%。你要写的不是“优化了内存带宽利用率”，而是“内存带宽利用率从65%提升到78%，使得同样任务下芯片整体性能提升12%，功耗下降8%，在竞品对标测试中从落后变成领先”。这种写法让评估者立刻理解你的工作在整个产品竞争力里的位置。
如果你确实找不到直接的量化数字，那你要做的是建立间接关联。比如你的工作提升了某个流程的效率，让团队其他人可以少加班两周。这个“少加班两周”在评估体系里不是软指标，而是可以换算成工程人月的成本节约。
怎么写团队协作和跨部门影响
IC工程师的自我评估还有一个常见缺陷：只写自己手头的技术活，完全不提跨团队协作。但系统性影响恰恰需要你展示自己的工作如何和其他人产生了正向关联。
这里不是说你要把跨部门沟通写成像销售一样，而是要展示你建立的“连接点”如何让整个系统更高效地运转。
一个具体的场景是：你在做AI芯片的编译器团队和硬件设计团队之间的接口定义工作。你写的不是“参与了跨团队协作”，而是“编译器团队和硬件团队在接口定义上存在信息不对称，导致每次RTL freeze后编译器需要两周时间做适配。
我在项目中期主动牵头组织了每周一次的接口同步会，建立了文档化的接口规范，使后续版本适配时间缩短到三天，编译器团队可以把省出来的时间用于性能优化”。
这种写法展示了你的主动性和对整个系统效率的影响，而不是简单地说“我沟通能力很强”。
不是写你学了什么，而是写你用了什么改变了什么
很多工程师在自我评估里会花很多篇幅描述自己学了什么新技术、看了什么论文、参加了什么培训。这种内容在评估体系里属于“输入”而不是“输出”。
不是说学习不重要，而是你要展示的是你的学习如何转化成了工作成果。
正确的写法是：“我系统学习了先进的低功耗设计方法论，并将其应用到XX模块的重构中，使该模块动态功耗降低35%，同时保持了原有的性能指标”。这里学习只是引子，核心是你用这个学习成果做了什么。
还有一个更隐蔽的问题：有些工程师会写“我主导了XX技术的落地”。但如果你仔细追问，他其实只是参与实现了自己的那部分，并没有主导方向选择、方案设计、团队协调。评估者对这种过度包装非常敏感。
你写“主导”意味着你要对结果负全责，包括方向错误、进度延误、团队分歧的解决。如果你的实际情况是你提出了一个想法，被老板采纳，然后你负责实现，你可以写“我提出了XX方案，被采纳用于XX项目，负责了该方案的核心实现”，这是准确的，也是有说服力的。
自我评估的常见结构陷阱
我见过很多自我评估的结构是：开头写一句“这一年我主要在XX方向工作”，然后列三到五个项目，每个项目写一段，最后加一句“在新的一年我会继续努力”。这种结构在评估者眼里是零分，因为它没有重点。
好的自我评估结构是“漏斗型”：开头用一句话建立你在整个团队里的定位，让评估者知道你是做什么的，然后聚焦到最重要的两到三项贡献，每一项都用足够多的细节来展示你的影响力和方法论，最后可以简短提一下未来方向。
不要试图覆盖所有工作。评估者不期望你一年做了十件大事，他期望你做了两到三件有足够深度的大事。如果你一年真的做了十件大事，那你更应该筛选，因为评估体系看的是深度不是广度。
另一个陷阱是“对比陷阱”。有些工程师会在自我评估里花篇幅写“我之前的方案A不好，后来改成了方案B”。除非这个对比对展示你的判断力和学习能力有直接帮助，否则不要在自我评估里暴露你走过的弯路。评估体系不是复盘文档，它只看你最终交付的结果和你的方法论。
绩效评估季的时间安排
如果你现在距离绩效评估还有六到八周，时间安排应该是这样的：
第一周，收集数据。你要把过去一年所有的工作记录整理出来，包括项目里程碑、邮件记录、文档贡献、任何可以证明你工作的客观材料。不要相信你的记忆，六个月前做的事你最多记得30%。
第二周，建立因果链。对每项工作问自己：如果没有我，这项工作会怎样？换一个人做，结果会有什么不同？我用了什么方法让结果变得更好？
第三周，撰写初稿。按照漏斗型结构写，不要管字数，先把核心内容写出来。
第四周，精简和润色。把每一句不是“因为我做了X所以Y发生了”的句子删掉，把每一个模糊的形容词换成具体数字。
第五周，请信任的同事或者老板过一遍。让他们告诉你哪些地方读完之后不知道你做了什么。
第六周，定稿提交。
这个时间安排的关键是：不要在最后一周才开始写自我评估。你需要足够的时间来让你的文字变得精准，而精准需要时间。
准备清单
第一，整理所有项目文档和里程碑记录。打开你的邮件搜索、Confluence页面、Git提交记录，把过去一年所有和你的工作相关的客观材料整理出来。你会惊讶于自己忘了多少东西。
第二，为每个主要项目回答三个问题：这个问题为什么存在？我的方案是什么？结果如何？每个问题用三到五句话回答，如果回答不了，这个问题可能不是你真正有贡献的项目。
第三，找到你工作的可量化指标。如果你是设计工程师，去找你的PPA数据；如果你是验证工程师，去找你的覆盖率数据和defect escape数据；如果你是架构工程师，去找你的方案被采纳比例和后续影响。
第四，写出你和其他团队的连接点。列出你在哪些地方影响了其他团队，他们因为你做了什么不同的事。
第五，用因果链语言重写每一项贡献。不是“我负责XX”，而是“因为我的XX工作，XX结果发生了”。
第六，请团队里信任的同事读一遍你的草稿。他们的反馈会告诉你哪些地方写得不清楚。
第七，精简到两到三项核心贡献。你写得越聚焦，评估者记得越清楚。
第八，检查是否有可以量化的地方没有量化。任何“提升了XX”的表述都要改成“提升了XX（从A到B）”。
第九，确认你的自我评估和你老板的观察一致。如果你写了一件你没跟老板汇报过的事，他可能会质疑你的判断。
第十，系统性拆解评估结构（PM面试手册里有完整的[绩效评估写作]实战复盘可以参考）——这个细节提醒你，评估写作和面试准备是同一个底层能力的不同应用场景。
常见错误
错误一：把自我评估写成招聘简历
BAD版本：“2024年在XX公司担任IC设计工程师，负责AI芯片XX模块的设计工作，参与了XX项目，完成了XX任务。”
GOOD版本：“AI芯片的NN Engine模块在初代产品里存在严重的面积问题，同等算力下面积比竞品大40%。我在架构层面重新设计了数据通路，通过引入时间复用和存储优化，在保持算力不变的前提下将面积降低28%，相当于在12nm工艺下节省了0.8平方毫米的die size，直接降低了每颗芯片$2.3的制造成本。”
问题分析：第一种写法描述的是任务，评估者看完不知道你的贡献在哪里。第二种写法建立了问题背景、你的方案、量化结果和对商业的影响，这才是系统性影响。
错误二：只写个人贡献，不写团队价值
BAD版本：“我独立完成了XX模块的验证工作，发现了15个bug，确保了模块质量。”
GOOD版本：“XX模块是整个AI加速器的数据入口，其验证质量决定了后续所有模块的测试基础。我设计的验证方案采用了以数据流为核心的随机验证方法，发现了15个bug，其中3个为影响数据正确性的critical bug。这些bug如果在流片后被发现，将导致至少六周的重新验证周期和$200K的掩模成本。”
问题分析：第一种写法只展示了你完成了任务，没有展示你的工作对整个系统和团队的价值。第二种写法建立了你的工作和他人的关系，评估者立刻理解了你的工作在整个项目风险控制里的位置。
错误三：使用模糊的形容词而不量化
BAD版本：“我的工作显著提升了团队效率，为项目按时交付做出了重要贡献。”
GOOD版本：“在XX项目的RTL freeze前两周，团队发现了一个关键的时序收敛问题，可能导致推迟一个月。我通过分析发现问题根源在于内存控制器的时钟树设计，提出了简化版时钟分配方案，在不影响性能的前提下使时序收敛时间缩短了40%，支撑项目按时流片。”
问题分析：“显著提升”是没有任何信息量的表达，评估者不知道你是真的提升了还是只是觉得自己提升了。“40%”和“按时流片”这样的具体数字和结果，让评估者可以判断你的贡献大小。
FAQ
Q1：我的工作很难量化，比如我只是做了一些技术调研和方案设计，没有直接产出，怎么写？
方案设计和调研的价值不在于产出本身，而在于你的方案被采纳后带来的结果。即使你的工作最终没有被采纳，你也可以描述你的方案解决了什么问题，以及为什么最终选择了其他方案。关键是展示你的判断力和方法论。
比如你做了AI芯片内存带宽的调研，发现了一个架构优化方向，虽然最终因为时间原因没有实现，但这个调研结论帮助团队在下一代产品里避免了同样的设计陷阱。你要写的不是“我做了调研”，而是“我的调研识别了XX风险，使团队在下一代产品里改变了XX设计方向，避免了可能的价值$500K的重新流片风险”。技术调研的价值在于它影响了后续的决策，而不是它本身产出了什么。
Q2：如果我今年做的项目大部分是维护性的工作，没有什么新项目，怎么写出有影响力的自我评估？
维护性工作的价值在于它防止了问题的发生，而不是它创造了新的产出。但“防止了问题”是可以被量化的。关键是你要找到你的工作避免了什么样的后果。比如你负责维护一个已经量产的AI芯片模块，今年修复了三个潜在的可靠性问题。
如果这些问题没有被发现就量产，可能会导致每百万颗芯片里有XX颗需要返修。你要算的是：这些芯片的返修成本是多少，你的工作避免了多少损失。一个更具体的角度是：维护工作往往意味着你对这个模块的理解超过了任何人，这种深度知识在团队里是一种稀缺资源。你可以描述你在团队里承担的“模块守护者”角色，以及这种角色如何支撑了其他项目的顺利推进。
Q3：我的老板今年给我的项目分配比较随机，不是我主动选择的，怎么在自我评估里体现我的主动性？
主动性不体现在你选择了什么项目，而体现在你如何在给定的项目里创造超额价值。即使项目是分配的，你仍然可以在执行过程中发现问题、提出改进、优化流程。关键是找到你在项目执行过程中的关键决策点，描述你在这些节点上做了什么选择，以及为什么这个选择带来了更好的结果。
比如你被分配去做一个模块的常规验证，但你发现原来的验证方法效率很低，于是你花了额外的时间引入了一种自动化脚本，把验证时间从两周缩短到四天。这个额外的投入没有人在项目计划里要求你做，但它体现了你的主动性。你要写的不是“我完成了分配的任务”，而是“我在执行分配任务的过程中识别了XX效率瓶颈，引入了XX改进，使项目提前XX天完成”。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。