本周我把苏尼尔·帕伊（Sunil Pai）写的《高级工程师的死亡螺旋》反复读了几遍，写得非常好，没读过的话可以先从这里开始。它让我很有共鸣，因为几乎每位高级工程师都体会过某种形式的卡住：你把擅长的事做熟了，环境却变了，积累的经验反而让你难以换一种方式看待问题。帕伊谈到要关注动能而非结果，我完全同意。

这周我把 Sunil Pai 的《资深工程师的死亡螺旋》重读了几遍，写得很好，没读过的建议先去读。

它引起我的共鸣，因为我觉得几乎每个资深工程师都曾某种程度感到困住。你擅长了手头的事，然后情况变了，积累的经验反而让你难以换种方式处理。

Pai 谈到要专注动力而非结果，我完全同意。当我卡住时，会把工作拆解成最小的可完成单元。做成一件事通常能帮我弄清下一步。

读完他的文章后，我不断回到第一性原理思维。

我很幸运能和许多出色的资深工程师共事或管理他们。想到他们出色的原因，我总落到同一件事：他们似乎知道该做什么。那种直觉一直让我钦佩。

其中一些最厉害的来自客户支持或服务岗，另一些自学编程，或从设计、创业转来。入行路径不同，但都习惯第一性原理思考。

他们会问为什么要做某个东西、对用户有什么用，能把代码库内发生的事和外部联系起来。这种理解帮他们保持简单。

我认为这正是建立 Pai 所说动力的另一种方式。先考虑能做的最简单的事，往往就足够了。

转向智能体时代

我和朋友同事聊过很多关于转向智能体开发的转变。那些适应得很好的人，通常本来就是这么思考的。

这是我经历的第一个重大“模拟环境切换”，让我真正认识到自己不懂的有多少。那些跟得上进展的工程师，愿意在和智能体协作时把已知暂时装进盒子，在假定旧限制仍适用之前先去尝试。

把它装进盒子

这对我来说最难。把经验、学到的东西和当下认为对的事放一边，足够久地去重新看问题。

我仍想借鉴经验，但很容易让过往项目或熟悉的技术局限在理解问题前就定了答案。

当我退一步问清究竟要做什么、为何重要、各部分如何关联，通常会发现比预期更多的出路。

关于 AI 哪些真实哪些夸大有很多讨论。我认为若把经验搁一边用新眼光看，有很多值得欣赏和重新思考的。第一性原理就是从目标出发问 AI 如何助力，很容易在回答这个问题前就对技术兴奋。

这又回到 Pai 说的动力。第一性原理让这种工作法很自然。真正理解目标后，更容易小步前进、学习并继续。若做得对，和智能体协作能让这种来回快得多，得到更快学习循环和更深理解驱动的动力。对我来说，这就是新的心流状态。

人类思考万岁。

讨论整体对原文不太买账，多数人嫌它空泛、把「第一性原理」当成一个谁都能挂在嘴边却说不清的词；真正的分歧在于：有人主张激进的第一性原理会把技术人带进死胡同，有人则认为它稀缺且必须靠实战摔打出来，而把 AI agent 拉进架构决策的一派则担心判断力被悄悄让渡。

觉得原文篇幅很长但没什么信息量

• 认为通篇是概念堆砌，读完仍不清楚作者到底想主张什么；也有人坦言一直搞不清「第一性原理思维」的边界，不知道代码里要容忍到什么程度才算数（较多人） > 篇幅很长，信息量却很少，这篇文章到底在讲什么？（@cyclopeanutopia）

认为脱离约束的第一性原理会把技术人带进死胡同

• 有人主张更高阶的思考比第一性原理更重要：只从「此刻是否正确」出发，容易走向战略和意识形态的死角，应该看最终结果的整体收益，而不是某一瞬间的正确（较多人）
• 也有人指出第一性原理常被过度神化，因为它会无视关键的非技术约束——比如要求全系统重构、所有功能开发停摆一年，或违背康威定律而需要重组（较多人） > 我最关心的是曲线下的总面积，而不是某一瞬间的值。（@bob1029）

认为用 agent 做架构决策是在让渡经验判断

• 有工程师表示很难和 agent 一起做架构决策：当你已经有一些现成的碎片时，它倾向于接管全部思考，最后变成你把自己的经验判断外包出去（较多人）
• 更严重的是同事层面——有人观察到同事逐渐丧失独立推理能力，因为既然 agent 会做完整个模块、还会审查甚至推翻自己想的方案，他们索性觉得没必要自己想（较多人） > 我见过同事渐渐无法脱离 agent 思考，因为反正整块工作最终由它完成。（@trwhite）

认为人类主导设计、agent 只做评审和头脑风暴才行

• 有人用 Codex 做带跨设备同步的常规应用，结论是必须自己在高层设计上投入大量精力，agent 更像评审、偶尔一起发散；一旦让它按需求自由设计，就会跑出不具可持续性的架构，因此怀疑网上多数 vibe coding 战绩的真实性（较多人）
• 由此得出的操作结论是：计划模式的时间要远多于构建模式的时间，这跟执行者是人还是 agent 无关（较多人） > 多花时间在计划模式，少花在构建模式——不管动手的是 agent 还是你自己，这一点都成立。（@Hasz）

认为追求「更有野心的设计」本身就是复杂度来源

• 有人抓住作者博客里「我要尝试设计更有野心的东西」这句话反驳：最好的工程师不是设计得更宏大，而是把看似复杂的东西做简单；问题在于这种简洁并不被评价机制奖励（少数人） > 最好的工程师不追求「设计得足够有野心」，而是追求尽可能简单的设计。（@flowerlad）

认为它的稀缺恰恰来自无法靠考试和权威习得

• 有人指出第一性原理人人会说，真做起来完全不同，通常只有在被问题逼到墙角时才逼得出来；学术界和公众常把它误解成应试记忆或「外包给权威」的加强版，这反倒让真正跟硬问题搏斗过的人获得了稀缺优势（少数人） > 真正做起来完全不同，它通常来自你不得不跟某个问题死磕。（@elendilm）

有价值的补充

• 反对第一性原理的声音给出了两个具体反例：某方案要求全量重构并推迟所有功能开发一年；另一方案破坏康威定律，需要重组，而重组又会撞上其他组织约束——因此有时人类学式的观察比第一性原理更合用（@ebiester）
• 有人用一句老话概括这场争论的底色：常识并不常见（@h02）