用AI写你的晋升材料：把技术成果翻译成晋升语言
你觉得你的晋升材料写得不够好，是因为你英语不够native，还是因为你不够自信？
很多湾区的华人工程师，工作到第八年、第十年,技术上已经在做L6的活儿了，但晋升材料递上去，committee的反馈总是：impact不够clear，contribution不够compelling。你回头看自己写的东西，该写的都写了，STAR格式也用了，数据也有，但就是过不了。
你以为问题出在语言上。于是你找native speaker帮你改语法，用Grammarly查拼写，甚至报个写作班。改完之后，句子确实更流畅了，但committee的反馈还是一样：还是不够compelling。
这时候你开始怀疑，是不是自己性格的问题——我不够aggressive，我不会吹牛，我在美国职场就是吃亏。
但如果我告诉你，这个问题根本不是语言能力或者性格问题，而是一个文化翻译问题呢？
你写的每一个句子，在技术上都是对的，在英语语法上也没错，但你用的是一套中国工程师文化里的叙事逻辑，去应对一个美国公司晋升委员会的评估框架。这两套系统，从底层就不在同一个频道上。
这期我们就一起拆开看，这个文化错位到底发生在哪儿，以及AI怎么帮你做这个翻译——不是改语法的那种翻译，是把"我做了什么"翻译成"世界因此变了什么"的那种翻译。
第一层：你以为你写的是晋升材料，其实你写的是performance review
先说一个很多人没意识到的事实：晋升材料和performance review，不是一回事。
Performance review是证明你这一年干得不错，达到了你这个level该有的标准。晋升材料是证明你已经在用下一个level的方式工作了，而且持续了足够长的时间。
但很多华人工程师写晋升材料的时候，用的还是performance review的逻辑。他们会写：
> "我深入学习了分布式系统的设计原理，在项目中解决了多个高并发场景下的技术难题，通过这个过程提升了自己在系统架构方面的能力。"
你看，这段话在技术上没问题，effort也很明显——学习、解决、提升，这是一个典型的工程师成长叙事。放在中国的技术团队里，这样写绝对没问题，甚至会被认为是"踏实、上进"。
但在美国公司的晋升委员会眼里，这段话的信号是："这个人还在学习阶段，还在证明自己能做这个level的工作。"
晋升委员会要看的不是"你学会了什么"，而是"组织的能力因为你的存在扩展了什么"。
同样的技术工作，如果用晋升的逻辑写，应该是这样：
> "将关键API的响应时间从2秒优化到0.5秒,直接解决了用户投诉排名第一的问题，使结账转化率提升了3%，相当于每年增加200万美元收入。这个优化方案后来被推广到其他三个服务，成为团队的标准实践。"
这两段话，描述的可能是同一个技术工作。但第一段在说"我变强了"，第二段在说"因为我，系统变强了，团队的能力边界扩大了"。
这就是问题的第一层：你以为你在写晋升材料，但你的叙事框架还停留在"证明我够格做这个level"，而不是"证明我已经在做下一个level该做的事"。
第二层：中国工程师文化里的"好"，在美国晋升体系里可能是"弱信号"
那么，为什么会出现这个错位？这不是哪个人的问题，这是两套文化系统在评价competence的时候，用的标准不一样。
在中国的工程师文化里——不管你是清华、中科大还是哪儿毕业的——证明你技术强，靠的是这几个东西：
1. 你攻克了多难的问题（难度）
2. 你学习了多深的知识（深度）
3. 你投入了多大的努力（effort）
4. 你个人的能力提升了多少（成长轨迹）
这套标准的背后，是儒家文化里对"学习"和"修为"的重视。在中国的语境里，说"我克服了很多困难，通过这个项目学到了很多"，是一种正面的、值得肯定的叙事。
但在美国公司的晋升框架里，评价一个engineer是否ready for next level，看的是：
1. 你的工作给组织带来了什么measurable的变化（business impact）
2. 有多少人的工作因为你的工作变得更高效（org-level influence）
3. 你解决的问题是不是公司层面的优先级（alignment）
4. 如果你不在，这个问题会不会有别人解决（你是否是不可替代的那个人）
注意，这套标准里，"你学会了什么"、"你投入了多少effort"，根本不在评估范围内。
不是说effort不重要，而是effort是table stakes——大家默认你肯定很努力，不然你也做不出这个结果。但晋升委员会要判断的是，你的effort产生的leverage是不是够大。
举个具体的例子。很多华人工程师会在晋升材料里写：
> "我花了三个月时间重构了legacy代码，把原来2000行的模块优化到800行，代码质量显著提升，可维护性大幅改善。"
这在中国的技术团队里，绝对是值得认可的工作——重构legacy code吃力不讨好，但对系统健康很重要。
但在晋升委员会看来，这段描述缺少最关键的信息：这个重构的business impact是什么？
- 重构之后，onboarding新人的时间从两周减少到三天了吗？
- bug rate下降了多少？
- 这个模块现在能支持的feature velocity提升了吗？
如果这些都没有量化，那么这个工作在晋升材料里的信号就是："我做了一件技术上正确但business value不明确的事。"更糟糕的是，"我花了三个月"这个表述，在effort文化里是加分项，在impact文化里反而可能是扣分项——committee会想，为什么一个本该两周完成的重构，你花了三个月？
这就是第二层错位：中国工程师文化里优化的维度，和美国晋升系统评估的维度，根本不重合。
第三层：STAR格式为什么救不了你
到这儿你可能会说，等等，我明明用了STAR格式啊——Situation, Task, Action, Result。公司training的时候也讲过，写self-review要用STAR。为什么还是不行？
因为STAR只是一个框架，但你往里面填什么内容，才是决定性的。
很多华人工程师用STAR的时候，是这么填的：
- Situation: 系统遇到了性能瓶颈
- Task: 我负责优化数据库查询
- Action: 我学习了索引设计和查询优化，重写了关键查询，改进了数据结构
- Result: 查询时间从2秒降到了0.5秒
你看，这个STAR在格式上完全正确。但它的叙事核心还是在Action——"我做了什么，我学了什么"。Result虽然有数据，但它只是技术指标（2秒到0.5秒），没有连接到business outcome。
同样的工作，如果用impact-framing的STAR填法，是这样：
- Situation: 用户投诉最多的问题是checkout页面加载慢，导致abandoned cart rate高
- Task: 优化checkout flow的关键查询，目标是把加载时间降到1秒以内
- Action: 重新设计了query pattern和database indexing strategy
- Result: 查询时间从2秒降到0.5秒，checkout页面加载时间达标，使结账转化率提升3%，相当于每年200万美元收入增长
看到区别了吗？第一个STAR的Result停在了技术指标，第二个STAR的Result把技术指标翻译成了business metric。
更重要的是，第二个版本的Situation不是从技术问题出发（"系统遇到性能瓶颈"），而是从business problem出发（"用户投诉多，conversion rate受影响"）。这个细节传递的信号是：你在用business context思考问题，而不是在技术孤岛里优化技术指标。
这就是STAR格式救不了你的原因：框架是对的，但你填充内容的思维方式还是effort culture的。
第四层：这是个翻译问题，不是写作问题
现在我们可以把问题说得更清楚了：
你的晋升材料写不好，不是因为你英语不够好，也不是因为你不会用STAR格式，更不是因为你不够自信。
是因为你需要做一个文化翻译：把"我做了什么"的叙事，翻译成"世界因此变了什么"的叙事。
这个翻译有多难？我们来看一个对照：
Effort register (中国工程师的自然表达):
"我深入研究了Kubernetes的调度机制，解决了多个资源竞争问题，优化了pod的调度效率，通过这个过程提升了我在容器编排方面的能力。"
Impact register (晋升委员会期待看到的):
"重新设计了Kubernetes集群的资源调度策略，使CPU利用率从40%提升到75%，节省了每月12万美元的云计算成本，同时将服务部署时间从20分钟缩短到5分钟，加速了整个工程团队的iteration速度。"
这两句话，如果从技术事实的角度看，可能在说同一件事。但它们传递的信号完全不同：
第一句话的主语是"我"，动词是"研究、解决、优化、提升"，宾语是"能力"。这是一个个人成长叙事。
第二句话的主语也是"我"（隐含），但动词是"重新设计"，宾语是"集群策略"，然后连接到的是一系列组织层面的结果——成本节省、团队velocity提升。
如果你是native English speaker，或者在美国长大，这个翻译可能是自然而然的——你从小到大接受的教育就是"你做了什么事、产生了什么影响"这套叙事逻辑。
但如果你是在中国接受教育、在中国开始职业生涯的工程师，你的自然表达就是effort register——因为在中国的文化里，这才是证明你competent的正确方式。
这就是为什么这是个翻译问题，不是写作问题。
你不需要学更fancy的英语词汇，你需要的是一个能把"effort narrative"翻译成"impact narrative"的工具。
而AI，恰好可以做这件事。
第五层：AI不是帮你写，是帮你翻译
现在到了这期最实用的部分：怎么用AI做这个翻译。
首先要明确一点：AI不是帮你写晋升材料，AI是帮你把你已经写的东西，从一种文化register翻译成另一种。
这意味着，你还是要自己先写出技术事实——你做了什么，解决了什么问题，数据是多少。AI能做的，是帮你重新组织这些事实的叙事方式。
具体怎么做？我给你一个可以直接copy的prompt template：
```
我是一名在[公司名]工作的软件工程师，正在写从L5到L6的晋升材料。
下面是我写的一段话，描述我的一个项目。这段话在技术上是准确的，
但它是用effort-framing写的（强调我做了什么、学了什么）。
请帮我把它改写成impact-framing（强调组织层面的结果和业务影响），
同时保持所有技术事实不变。
原文：
[粘贴你的段落]
```
举个实际例子。假设你原来写的是：
> "我负责优化推荐系统的模型训练pipeline。通过学习分布式训练框架，我将训练时间从8小时缩短到2小时，并且在这个过程中深入理解了模型并行和数据并行的权衡。"
把这段话给AI，用上面那个prompt。AI可能给你这样的改写：
> "重新架构了推荐系统的模型训练pipeline，将每日模型更新周期从8小时缩短到2小时。这使得我们能够实现day-over-day的模型迭代（之前是week-over-week），推荐点击率提升了4%，相当于每月增加30万美元广告收入。这套pipeline设计后来成为ML团队的标准架构，被应用到其他三个模型。"
看到区别了吗？
第一段的核心是"我学习了X，缩短了时间，提升了理解"——这是effort + growth narrative。
第二段的核心是"因为我，系统的迭代速度变快了，business metric改善了，而且这个方案scalable到其他场景"——这是impact + leverage narrative。
但这里有个critical的注意事项：AI可能会编造数据。
比如，如果你原文里没有提到"推荐点击率提升4%"或者"30万美元广告收入"，AI可能会自己加上这些数字，让故事更compelling。
所以你必须做两件事：
1. Check every number — AI生成的任何数据，你都要确认是真实的。如果AI编了一个你没说过的数字，删掉它，或者替换成你实际知道的数字。
2. Scope the impact correctly — AI有时候会overstate你的contribution。比如，如果这个优化是你和另外两个人一起做的，AI可能会写成"我重新架构了整个pipeline"。你需要改成"我主导了pipeline的架构redesign"或者"我负责其中的分布式训练部分"。
再举一个反例。假设你原文写的是"我优化了核心算法"，AI给你这样的改写：
> "通过优化核心算法，我使整个公司的系统性能提升了30%，为公司节省了数百万美元成本。"
这段话听起来很impressive，但有两个严重问题：
1. 过度归因 — 你优化了一个模块，但AI把它扩大成了"整个公司的系统性能"。这不是你的scope。如果committee里有人问"which systems were impacted?"，你答不上来，这个claim就崩了。
2. 虚构数据 — 如果你原文里没有提到"30%"或"数百万美元"，这是AI编造的。Committee一问具体数字怎么算出来的，你说不出methodology，这就是fact risk。
遇到这种output，你应该直接删掉，重新给AI更precise的context："我优化的是recommendation engine里的ranking算法，影响范围是homepage feed，性能提升的指标是latency reduction"。
AI的价值不是帮你夸大，而是帮你把你真实做的事情，用impact narrative的方式重新表达。
第六层：从一个段落到整个晋升packet
用AI翻译一个段落，和用AI重写整个晋升packet，不是一回事。
一个完整的晋升packet，通常有3到5个major projects或者contributions。每个project你可能写2到3段。如果你把每一段都扔给AI，让AI重写，最后拼在一起，你会发现两个问题：
问题1：AI会重复类似的句式和表达。 比如，每个项目都是"我重新设计了X，使Y提升了Z%"，读起来很mechanical，像是模板生成的。
问题2：你的voice消失了。 晋升材料还是要听起来像你写的，而不是像AI写的。
所以正确的用法不是"让AI帮我写完整个packet"，而是"让AI帮我翻译我最不确定的那几段"。
具体策略：
1. 先自己写完整个packet的初稿 — 用你自然的方式写，不要一开始就想着怎么impressive。把技术事实、数据、timeline都写清楚。
2. 自己标出哪些段落是effort-framing — 读你写的每一段，问自己：这段话的重心是在"我做了什么"，还是在"结果是什么"？如果是前者，mark it.
3. 只把effort-framing的段落给AI翻译 — 用上面那个prompt，一段一段地翻译。
4. 拿AI的output当参考，不是直接替换 — AI给你的改写，可能有些表达很好，有些over了。你要做的是从中挑出有用的部分，merge进你自己的版本。
5. 最后通读一遍，确保连贯性 — 晋升packet是一个narrative，不是一堆project descriptions的堆砌。你需要确保从第一个project到最后一个project，有一个清晰的progression——你在不同的时间点解决了什么层次的问题，你的scope是怎么扩大的。
这个过程，AI是个工具，但judgment还是你的。
第七层：为什么要学会这个翻译，而不是每次都依赖AI
到这儿你可能会想：既然AI能帮我翻译，那我每次写晋升材料都用AI不就行了？
可以，但这只是第一步。
真正的问题是：晋升材料写完了，不是结束，是开始。
因为在很多公司，晋升流程里有一个环节叫promo committee presentation或者calibration meeting。你的manager会拿着你的packet，到committee面前，给其他managers和senior leaders讲你的story。
这时候，如果你的packet写得是impact narrative，你的manager就有material去讲一个compelling的story。
但如果你的packet还是effort narrative，你的manager就很难帮你argue。因为committee里的其他人会问："So what? This person did a lot of work, but what's the org-level impact?"
更重要的是，如果你晋升之后，你需要开始做的一件事就是在更大的场合讲你的work——all-hands、tech talk、跨团队的design review。
如果你还是用effort narrative去讲，你会发现别人听不进去。不是因为你的工作不重要，而是因为你的叙事方式没有给听众一个clear的"why should I care"的答案。
所以，用AI翻译你的晋升材料，其实也是在训练你自己的思维方式——从effort culture切换到impact culture。
这不是说effort不重要，也不是说你要变成一个只会吹牛的人。而是说，在美国的职场里，如果你想让你的工作被看见、被认可、被rewarded，你需要学会用impact narrative去框定你的contribution。
这是一个文化适应的过程，也是一个工具问题。AI能帮你度过这个transition。
结尾
回到开头那个问题：你的晋升材料写不好，是因为英语不够好，还是因为不够自信？
都不是。
你的问题是，你在用一套文化逻辑（effort + growth），去应对另一套评估框架（impact + leverage）。这两套系统，从底层就不在一个频道上。
好消息是，这是个翻译问题，而翻译是有工具可以解决的。
AI不是magic，它不能把一个平庸的project变成impressive的contribution。但如果你的工作本身是solid的，只是你不知道怎么把它表达成impact narrative，AI可以帮你做这个翻译。
具体的prompt我已经给你了，下次写self-review或者晋升材料的时候，试试看。
记住两个原则：
1. AI帮你翻译，不是帮你编造 — 所有数据你都要verify，所有claim你都要确保scope正确。
2. AI给的是参考，不是答案 — 你要从AI的output里挑出有用的表达方式，merge进你自己的narrative。
从"我做了什么"到"世界因此变了什么"，这个翻译，可能就是你从L5到L6之间，最需要跨过的那道gap。
我是莎姐，我们下期见。