很多人一提到“第一性原理”，就会想到创业、商业或者很抽象的大词。但我这段时间在真实项目里越来越强烈地感觉到，它其实没那么玄。对我来说，它更像是一种很朴素的提醒：事情一复杂，就别急着顺着经验和惯性往下冲，先回到目标、约束和事实，再决定下一步到底该怎么做。
以前我其实挺相信经验的。
做项目久了以后，脑子里会慢慢长出很多“差不多就该这么做”的默认反应。
比如：
- 老项目里加新需求，顺手把旧结构也整理一下
- 一个问题既然定位清楚了，那就尽快改掉
- AI 既然已经能往下写，那就让它继续写到底
这些反应都很正常。
而且说实话，很多时候它们确实也帮过我。
但我这段时间在真实项目里反复碰到一类时刻：
事情一复杂，我如果只靠经验往下走，最后很容易越做越偏。
不是因为经验完全错了，
而是因为经验太容易让人忽略眼前这件事真正的目标、真正的约束、和真正已经成立的事实。
后来我回头再看，才慢慢意识到：
我最近越来越在意的这套思考方式，其实已经很接近我现在理解的“第一性原理”了。
它没有那么玄，也不是什么“大神专用词”。
说得直接一点，它更像是：
别急着沿着习惯往下做，先回到底层问题本身。
1. 我后来发现，很多人不是不会分析，而是太容易顺着惯性往下走
我现在越来越觉得，项目里很多判断失误，不是因为人不认真，也不是因为技术不够。
更常见的原因其实是：
一看到熟悉的问题，就顺着熟悉的经验下去了。
这件事特别容易发生在老项目里。
比如一个需求下来，你看一眼代码，脑子里马上会跳出很多“标准动作”：
- 这里结构不太理想，顺手重构一下
- 这个页面正好可以一起整理
- 这段逻辑看着不够优雅，不如这轮一起收掉
这些想法单独看都不荒谬。
问题在于，很多时候你其实还没先问清楚：
- 这轮最重要的目标到底是什么
- 哪些地方是当前不能碰的
- 用户真正感受到的变化到底发生在哪一层
如果这些问题没先问，经验越多，反而越容易顺着熟悉的路径一路走偏。
这也是我为什么后来越来越警惕“凭感觉直接动手”。
因为很多时候，不是你不会做，而是你太快进入了“我知道该怎么做”的状态。
2. 对我来说，第一性原理不是推翻经验，而是先把经验按住一下
我现在如果要用最普通的话去解释“第一性原理”，我会这么说：
先不要急着沿用现成做法，先把这件事最基本的目标、约束和事实重新看一遍。
我自己现在会固定先看 3 件事：
1. 目标是什么
不是“我想顺手做什么”，而是：
- 这轮到底要交付什么
- 什么是这轮必须成立的东西
2. 约束是什么
比如：
- 主链路不能乱动
- 回归范围不能一下子放大
- 当前验证资源有限
- 这轮不是结构整改轮次
3. 事实是什么
不是推测，不是习惯，而是：
- 哪条链路已经稳定
- 哪个问题只在调试态明显
- 哪个变化真的接近用户感知
- 哪部分只是我自己觉得“不够好看”
等这三层看清楚以后，你再决定下一步是：
- 先加一层壳
- 先把问题记下来
- 先补文档
- 还是这轮真的值得往下改
这时候动作会稳很多。
所以对我来说，第一性原理不是“推翻经验”，而是：
别让经验抢在判断前面。
3. 我是在真实项目里，慢慢把这件事想明白的
这不是我某天突然想通的。
它其实是最近这段时间，我在真实项目里被很多具体问题一点点逼出来的。
例子 1：为什么我后来越来越倾向于“低风险加壳”
以前遇到老项目加新模块时，我也会有一种冲动：
- 反正都要动了
- 顺手把旧结构一起收一下
- 一次做干净，后面更省事
但真实项目里，这种“顺手一起收”很多时候是很危险的。
因为你表面上在做一个需求，实际上却顺手引入了另一轮结构变动：
- 入口改了
- 页面层级改了
- 状态流改了
- 验证范围也一起扩大了
后来我才越来越明确：
如果回到底层问题去看，这类任务最核心的目标往往不是“把结构也顺便做漂亮”，而是：
先把新需求低风险地接进去。
约束通常也很明确：
- 已跑通的主链路不能轻易打穿
- 这轮验证资源有限
- 业务上更需要稳定闭环，而不是顺手大重构
事实则是：
- 用户最先感知到的变化，很多时候发生在入口、页面壳子、流程编排和展示层
一旦回到这三层去看，很多原本看起来“更彻底”的方案，立刻就不再是最优先的了。
这也是为什么我后来越来越偏向：
- 先保留主链路
- 先在外层接
- 先低风险交付
这不是保守，而是我后来觉得更接近问题本身的做法。
例子 2：为什么有些问题定位清楚了，我最后还是选择不改
这件事对我触动也很大。
很多时候我们默认：
- 问题找到了
- 原因也清楚了
- 那下一步当然就是改
但真实项目里，这个逻辑并不总成立。
比如有些卡顿、发闷、点击不顺的问题，在调试态下看特别明显。
你一路查下去，确实也能找到一些热点：
- 某段初始化偏早
- 某个回调在主线程上
- 某块共享逻辑看起来还能优化
如果只顺着经验往下走，你很容易就会进入“那就接着优化”的状态。
但如果停一下，先回到底层问题去看，很多事情就不一样了。
你会先问：
- 这到底是调试态问题，还是用户真实问题
- 这轮最重要的目标是不是解决它
- 真要改，会不会碰到订阅、广告、共享启动链这些高风险区域
一旦这几层看清楚，结论有时候就会变成：
这轮先不改，反而更成熟。
这也是我最近越来越明确的一件事：
定位清楚，不等于立刻动手。
真正成熟的判断，是知道什么时候该动，什么时候先别动。
例子 3：为什么我后来越来越重视 handoff、记忆文档和模板
这件事放到 AI 协作开发里也一样。
一开始很多人会把重点放在：
- AI 能不能多写一点代码
- 生成结果快不快
- 能不能替我做更多实现
这些当然重要。
但我后来越来越觉得，这还不是最底层的问题。
如果回到底层去看，AI 协作开发真正更基础的问题其实是：
- 关键判断能不能保住
- 边界会不会在长对话里慢慢漂掉
- 下一轮还能不能顺着今天继续往下走
也就是说，真正稀缺的可能不是“多生成几段代码”，而是：
- 让上下文别丢
- 让边界别散
- 让判断能留下来
一旦这么看，很多原本容易被当成“附加工作”的东西，性质就变了：
- handoff 不是附加动作
- 记忆文档不是形式主义
- 模板也不是为了显得专业
它们其实都在做同一件事：
把最重要的判断固定下来。
而这件事，本身就很像我现在理解里的第一性原理。
因为你不是在围着“AI 多厉害”打转，而是在问：
到底什么才是真正影响连续交付效果的东西？
4. 我现在会怎么用这套方式
如果把它翻得更工程一点，我现在其实会把“第一性原理”用成一组固定问题。
每次事情开始变复杂时，我会先问自己：
1. 这轮最重要的目标到底是什么？
不是“最好顺手把什么也做了”，而是：
- 这轮必须交付什么
- 哪个结果最不能丢
2. 这轮最硬的约束是什么？
比如：
- 主链路不要乱动
- 回归范围别失控
- 当前不是做结构治理的时候
3. 当前真正已经成立的事实是什么？
比如：
- 哪条链路已经稳定
- 哪个问题只在调试态放大
- 哪个体验问题是真实用户一定能感知到的
4. 从这些目标、约束和事实出发，最合理的动作到底是什么？
这时候你再去决定：
- 是先加一层壳
- 还是先不改
- 是先补文档
- 还是先收一个更小、更稳的边界
到这里，动作就不再是惯性反应，而更像是从问题底层推出来的选择。
5. 为什么我觉得这件事会越来越重要
因为工具会越来越强，建议会越来越多，现成答案也会越来越唾手可得。
尤其现在 AI 已经开始进入真实开发流程之后，它特别擅长：
- 给你方案
- 给你替代路径
- 给你一整套看起来都说得通的做法
这反而会让人更容易掉进另一种风险里：
- 技术上每一步都像是合理的
- 但项目上却越来越偏
所以我现在越来越觉得，后面真正稀缺的，不一定是“谁会用更多工具”，而是：
- 谁还能在复杂情况下回到底层目标
- 谁还能守住真正的约束
- 谁还能把判断建立在事实之上，而不是建立在惯性之上
如果一定要说“第一性原理”到底有什么用，我现在会觉得，它最大的价值不是让人显得更聪明，而是：
让你在事情一复杂的时候，不那么容易被惯性带着跑。
6. 最后
如果今天再让我用一句最普通的话解释“第一性原理”，我不会再讲什么大词。
我更愿意把它说成一句很朴素的话：
别急着顺着经验直接动手，先回到底层问题本身。
我这段时间在真实项目里反复碰到的很多判断：
- 先低风险加壳
- 已定位但这轮先不改
- 用 handoff、记忆文档和模板把判断托住
表面看不是一回事，底层其实都在做同一件事：
先不被习惯推着走，先把目标、约束和事实重新看清楚。
这就是我现在更愿意相信的“第一性原理”。
