(本文由 Claude Sonnet 4.6 辅助完成，来自于博主与 GPT-5.2 的对话)
“第一性原理"这个词，我第一次听到是在中科大读本科的时候。理工科环境里，这个说法偶尔被提起——从事物最底层的本质出发来推导，而不是沿用经验或类比。当时只当是一个听起来很酷的说法，没有认真用过。直到最近听了《硅谷101》采访 AppLovin CTO 葛小川的节目，他也是科大学长，聊决策逻辑时提到这个框架；又陆续刷到几个 Anthropic 相关的访谈，发现硅谷科技圈有越来越多人在认真对待这件事。AI 时代信息量实在太大，大脑随时处于过载状态，很多东西根本分不清对错。这时候特别需要一个能帮你找到"问题本质"的工具。于是我重新想起了第一性原理，拿它来梳理一下自己混沌的职业焦虑。
工作到第六年，突然发现自己处于一个奇怪的夹层里。
往上，Staff 和 TL 的位置看得见摸不着；往下，AI 开始吃掉你曾经引以为傲的那部分产出；身份上，H1B 把很多路都堵死了。所有人都在说"要拥抱变化”，但没人告诉你，当所有约束同时拉扯的时候，怎么冷静地想清楚下一步。
我把这些焦虑丢给 AI，用第一性原理拆了一遍，又开口讲了讲最近真实经历过的事。把这些整理下来。
问题换了，答案才会变
我原本以为自己面对的问题是"要不要跳槽"，但拆到底之后发现，真正的问题是：在身份约束还在的情况下，怎么最大化未来几年的可选性？
这两个问题的决策框架完全不同。前者容易陷入"跳了会不会更糟"的焦虑循环；后者逼着你问：什么选择能给我留最多退路？目标不是找最优解，是找最不后悔的解。
AI 吃掉的是哪种工程师
这条结论让我安静了一会儿。
AI 优化的不是"会写代码的人"，而是"可被明确规格化的工程劳动"——给你一个 spec，你把它写完的那种角色。不被吃掉的是定义问题的人、设计系统的人、决定写什么的人。
所以真正的问题不是"我还要不要写代码"，而是：我现在是在调度 AI，还是在等着被 AI 调度？
大厂把 scope 切得很细
我做了个自我检验——组里新人有问题找谁、跨组合作谁第一个被 ping、出了问题谁先被 call——这三条目前算是做到了。但这没让焦虑消失，反而更清楚地看到了下一层问题：大厂的 ownership 天然被切得很细，你解决的问题再精准，scope 也只是大系统里的一小块，不像 startup 能从头到尾扛一个完整的东西。
还有同学对比。读书时大家起点差不多，五六年之后，有人做到了 CTO、有人带着团队做出了有真实用户的产品——那种"发光发热"的感觉从外面看特别直接，会让你开始怀疑自己是不是在大厂待傻了。
Hackathon 教会我的事
24年参加了 org 的 hackathon，做了一个用 AI 大模型帮 engineer 解决 oncall 问题的工具，拿了第一名。反馈都很好，我当时觉得这个东西得推进到生产环境去。然后就撞墙了。
Team member 各有本职 team，hackathon 期间可以冲一把，长期维护就没人愿意持续投入业余时间。去跟别的 org 和 team 聊完才发现，公司里有好几个团队都在做差不多的事，这个项目到底还值不值得推就成了问题。再加上大公司要真正上线一个东西，审核、design review、各种流程走下来……项目最后搁置了。本地模型跑得好好的，oncall 问题也验证能解决，但就是没能上线。
这件事让我想通了一件事：大厂里，从 0 到 1 的验证你可以做，但从验证到上线之间有一堵墙，不是一个人的 ownership 能穿透的，是一个组织问题。想清楚这个，就不会再把"项目没上线"算成自己的失败了。
现在在做的事
策略清晰之后，我在做两件事。
一是组里刚分出来一个新的 sub-team 做比较新的方向，我跟 manager 说了我想 lead 这个。不是为了 title，是为了在一个可控范围内真正拥有决策权——架构怎么搭、技术方案怎么选。
二是把自己在新技术上踩过的坑和学到的东西整理成文档，在组里做分享或 hands-on session。不是为了表现，是因为这件事逼你把理解真正说清楚，同时也让 manager 和 team 更清楚地看到"你在哪个领域是认真的"。
这两件事都不大，但都是在往"定义工作，而不是执行工作"的方向推。
焦虑是结构问题，不是心理问题
最后一点：信息爆炸时代，焦虑几乎是不可避免的结构性状态——高不确定性、高风险、低可控同时拉满，不是你抗压差。“别人都在进步"这种感受大概率是幸存者偏差，你看到的是 1000 人里最激进的那一个。
给自己的定锚：不需要跑赢时代，只需要不被甩下。每年确认一次方向没走反，比每个月焦虑地追热点，有用得多。