这不是一篇经验分享，更接近一份进行中的个人记录。很多想法还不够成熟，但正因为是进行时，记下来才有意义。等到「想明白了」再写，过程中那些有价值的困惑大概早就忘了。
从「会用工具」到「会设计工程」
大多数开发者的成长路径差不多：学语言、学框架、学工具链，在项目里积累经验。到了某个阶段，需求能翻译成代码，工具也用得顺手了，但面对技术选型、架构拆分这类决策时，总觉得缺了点什么。
这个「缺了点什么」，我后来意识到是两件事。
一个是从「能不能做」到「该不该这样做」的跳跃。工具层面的问题大部分有标准答案，但工程决策是开放的，没有唯一正确的方案，只有在特定约束下相对合理的取舍。
另一个是从「解决眼前问题」到「设计可持续方案」的跳跃。一段代码能跑和一个系统能维护，完全是两回事。工程化思维要做的事情，是把工具、流程、规范组合成一个可重复、可复制的体系。
这就是工程化思维要解决的事：把工具嵌入开发流程，让它稳定、可重复地跑起来。
工程化思维是什么
给工程化思维下定义很容易陷入抽象，我倾向于用一个公式来拆解：
工程化思维 = 约束 + 权衡 + 标准化
约束，在限制条件下做选择。时间有限、人力有限、技术栈有限、团队认知有限。工程决策永远是在框框里做事，承认约束的存在，才谈得上合理判断。
权衡，接受没有完美方案。选 A 方案牺牲灵活性换稳定性，选 B 方案牺牲短期效率换长期可维护。问题不是「哪个更好」，而是「在当前约束下，哪个代价更值得承受」。
标准化，工程化的最终目的。一个方案如果只有你能跑通，那它只是个人技巧，不是工程方案。工程化追求的是把个人经验沉淀成团队能力，让方案可重复、可复制。
但实践中我发现，这三个要素都依赖一个前置技能：问题建模。问题没想清楚，后面的约束、权衡、标准化都是在错误的地基上盖楼。
问题建模：工程化思维的前置技能
这是我目前最大的卡点。
日常开发中，我已经在做一些工程化的事情：定位需求、方案选型、方案评估、落地执行。但每次遇到需要做判断的节点，总有一种说不清的犹豫。不是不知道有哪些选项，而是很难确信自己理解了问题的本质。
个人真实例子：用 ai agent 开发需求，工具跑起来没有障碍，但需求描述得模糊，agent 就会在它自己理解的问题上生成一个完全合理的方案——而这个问题未必是你真正要解决的。等代码出来发现不对，再去调试，时间反而比自己写多花了一倍。省下来的不是思考时间，是打字时间。
如果当时先把问题写清楚：我要解决的是什么、约束是什么、什么叫做对，agent 的产出大概率不会跑偏。建模这步没做好，工具效率越高，偏离越快。
从「需求没实现对」到「问题到底是什么」，这个转化过程就是问题建模。
问题建模说白了就是：把一个现象（发生了什么）转化为一个可操作的问题定义（真正需要解决什么）。
看起来简单，做起来很难。
一个难点是，现象和本质之间往往隔了好几层。你看到的「跑偏了」、「没达到预期」、「不知道哪里出了问题」都是症状。从症状追溯到病因，需要不断追问「为什么」，而每一层追问都可能走岔。
另一个是，问题的边界不是天然存在的。同一个「没实现对」，你把它定义成需求描述问题、方案评估问题、还是执行过程问题，后续的处理方向会完全不同。边界画错了，后面的努力可能都在偏离方向。
还有一点常被忽略：建模需要领域知识托底。见过足够多的模式，才能在遇到新问题时快速归类。这个能力只能在真实项目中反复踩才会长出来。
问题建模不只是工程化的前置技能。探索思维要判断「什么值得探索」，产品思维要搞清楚用户需求的本质，本质上都是同一个动作：把模糊的现象转化成可操作的问题定义。
工程化思维的局限
理解了问题建模之后，回头看工程化思维，会发现它有明确的适用边界。
探索思维（Exploration） → 找方向 工程思维（Engineering） → 稳定系统 产品思维（Product） → 创造价值
工程化思维擅长的是「已知问题的系统化解决」。它的前提假设是问题已经被定义清楚了，接下来要做的是在约束下找最优解并标准化落地。
但现实中，问题本身往往还没被定义清楚。方向对不对不确定、需求是不是真实的不确定、当前假设能不能成立也不确定。这时候需要的是探索思维：快速验证、容忍不确定，而不是急着标准化。
工程化思维的另一个盲区是价值判断。它关心「怎么做」，不关心「做不做」。一个技术方案在工程角度完全合理，但如果解决的问题对用户没有价值，它就不应该存在。
三种思维不是阶段性切换的，是在日常开发中交替出现的。探索思维发现和定义问题，工程思维设计和稳定系统，产品思维判断这件事值不值得做。
刻意练习
知道「问题建模很重要」和真的能做到之间，差的是大量练习。以下是我目前在尝试的几个方法，效果还在观察。
方法一：强制「问题重写」
遇到问题时，强迫自己按四个维度重新描述一遍：
- 现象：发生了什么？事实层面，不带主观判断
- 本质问题：真正的问题是什么？从现象往下挖一到两层
- 目标：我想解决什么？区分「想做」和「该做」
- 约束：有哪些限制？时间、技术、团队、业务
这个方法的价值不在于写下来的东西，而在于「重写」这个动作会逼你重新审视自己的理解。写到一半经常会发现，之前以为的「问题」其实只是「现象」。
方法二：决策日志
每次做技术决策时，简单记录：选了什么、放弃了什么、为什么。几句话就够。
目的是事后可追溯。过一段时间回头看，有些决策的理由在当时很充分，事后看完全站不住脚。这些就是需要重点复盘的地方。
方法三：反向思考
不想「这个方案为什么好」，反过来问「这个方案会怎么失败」。提前想失败路径，能帮你发现隐藏的约束和被忽略的边界条件。
方法四：渐进式工程化
别试图一步到位。先用最简单的方式把问题解决了，观察哪些地方出现了重复、哪些地方开始变脆弱，再针对性地引入工程化手段。过早标准化和过度设计一样，都是陷阱。
训练闭环
上面四个方法拼起来是一个循环：
- 描述问题（现象）
- 抽象本质（问题建模）
- 明确目标 + 约束
- 选方案（权衡）
- 落地（标准化）
- 复盘（哪里选错了）
这个闭环的关键不在于每一步做得多完美，而在于每次做决策时都有意识地走一遍。走得多了，结构化思考慢慢就变成了习惯。
写在最后
回到开头：怎么从「会用工具的人」变成「会设计工程的人」？
我现在的理解是，这个转变的核心不在于学更多工具或框架，而在于建立面对问题时的思考结构。工具会过时，框架会迭代，但「在约束下定义问题、权衡方案、沉淀标准」这个能力不会过时。
目前给自己的定位：
- 工具认知和工具使用，已完成
- 工程理解，进行中
- 工程决策，正在突破
- 工程直觉，未来目标
这篇文章本身也是练习的一部分。把模糊的感受整理成结构化的文字，本身就是一次问题建模。半年后回头看如果觉得很多地方理解错了，那反而说明有进步。
