判断一个岗位会不会被吃掉，看的不是它属于哪个技术栈，而是它做的事有没有被标准化、工具化。已经解决过的问题、按模板反复产出的那层工作，交给 AI 和工具是合理的，别人拿着你的 skill 也只能替代你过去做的浅层部分，替代不了你今天正在看的东西。反过来，如果一直守着已经解决的那层不放，不愿自动化、不愿交给 AI，那才是真正被取代的原因——因为你没有往下一个更重要的问题走⁠1。对 NX CAD 这类商用功能开发，可以先问自己：我日常产出的哪些部分，其实已经是可复制的模板工作？把它们交出去之后，我手上还剩什么。

AI 时代单一 skill 的可替代性在提高，越能靠近业务结果、对结果负责的人越难被取代。AI 可以写代码、生成方案，但最后仍然需要有人做决定、跟客户一起把事情做成，方案是谁提的并不重要⁠2。这个逻辑对 CAD 开发同样成立：如果工作只是实现已定义好的功能，价值集中在写代码；如果工作包含理解用户真实的设计流程、判断哪些需求值得做、对功能上线后的结果负责，那部分很难被 AI 单独接走。一个可试的做法是，挑一个你手上真实的功能需求，试着用 AI 把实现部分做掉，看自己省下的时间能不能用在需求判断和结果验证上——这能帮你判断自己现在离业务结果有多远。

一个被反复提到的方向是 FDE（Forward Deployed Engineer，前场工程师）：既能跟客户打交道，又能自己上手改生产代码，是产品的一部分而不是客服的一部分。因为产品还在快速演化，客户现场就是产品定义的一部分，能把客户需求翻译成产品改动、并且自己把改动做出来的人，会比传统支持角色更关键⁠3。对 NX CAD 的 SDE，可迁移的关系是：从只接内部需求，转向直接接触用 CAD 的工程师和设计师，理解他们卡在哪，并自己把改动做出来。另一个更普遍的要求是放弃执行者思维、拥抱架构师思维——哪怕只是写代码，也要有从需求到部署的全局视野，因为公司砍人时，剩下的人必须是能独立闭环的⁠4。

初级工程师常以为难的是学 React、学 Kubernetes，学会框架就能写好软件；只有在复杂系统里被架构问题反复毒打之后，才会意识到框架从来不是瓶颈，设计才是。好的方法论在起作用时是隐形的：项目做成了，大家归功于工具或团队；做崩了，归因于工具不好用或需求太复杂，没人会说是因为上下文管理没做好。所以人们总在为可见的问题买单，不为不可见的问题买单。方法论没有“学之前不会、学之后会了”这种清晰的检查点，它更像一种在实践中逐渐生长的判断力⁠1。

过去很多软件工程的最佳实践，前提是写代码太贵：所以代码要 scalable、要能复用、要模块化。当写代码便宜了以后，很多东西不需要那么做。这里的关键不是抛弃方法论，而是能不能从原理去看它——不是因为它被当成软件开发的圣经就一定对，而是先问它在旧环境下为什么对，再看新环境下还成不成立。把自我价值绑在写代码质量上的人，会很难接受 AI 写得更好这件事；能接受、愿意重新挑战未经检验的最佳实践，才是第一位的⁠2。

你之前问的是商用 NX CAD 的 SDE 会不会被取代。一个可能的检验方式是：拿你手上正在做的一个功能，用 clean architecture 或某个 design pattern 的视角，写下它到底在解决谁的什么问题、这个问题值不值得被解决。如果问题本身不值得解，把技术做得再好也没有意义；真正在企业里被重用的人，是能有效解决商业问题的人⁠3。这个动作不要求你重构代码，只是让你看清自己现在花时间的那层工作，是在解问题，还是在给技术立纪念碑。

OCP、SOLID、clean architecture 这些做法，在旧环境下成立，很大程度是因为写代码太贵：代码要 scalable、要复用、要模块化，所以值得为扩展性提前付出结构成本。写代码变便宜后，这个前提松动了，很多地方不再需要那么做。真正该问的不是“这样符不符合 SOLID”，而是“我这里的瓶颈是写代码贵，还是改错代码贵、验证贵、多人协作贵”。如果瓶颈已经不在写代码，照搬分层和抽象反而增加维护面。有人把自我价值绑在代码质量上，就很难接受 AI 写得也不错这件事，也就更难从原理上重新判断哪些旧实践还成立⁠1。

你担心的“改 A 坏 B”“需求一变就大范围重写”，本质是改动成本和验证成本，不是代码贵不贵。这两项成本高时，边界清晰、职责单一仍然划算，因为一次改动的影响面可预测，external behavior 也更容易被守住。反之，如果这段代码只跑一次、错了重生成就行，为它设计扩展点就是在为不存在的需求付费。判断标准可以落到一个具体动作：挑一处你最近改过、又怕改坏的地方，先不重构，只写一条能验证 external behavior 的检查，再让 AI 做这次改动。看它是否在不动这条检查的前提下完成——能，说明当前结构够用；不能，才说明这里需要边界。

出处 2

SOLID 里的每一条都带条件。开闭原则说的是“当变化真的会反复发生时，让扩展不必改动已有代码”，而不是“任何地方都要预留扩展点”。没有扩展需求时硬加抽象层，反而增加阅读和改动成本。所以你和那段推演其实不冲突：推演反对的是“无条件套用”，不是 SOLID 本身。真正需要说清的是，什么时候这个取舍值得往“可扩展”那边偏。

出处 1

过去模块化、可复用之所以几乎总是划算，是因为写代码本身贵，多写一层抽象换来的是省下大量重复劳动。现在生成代码便宜了，这条理由变弱，但另外两项成本没降：改动的影响面是否可预测，以及 external behavior（对外行为）是否容易被验证。这两项高的时候，边界清晰、职责单一依然划算，因为一次改动不会牵动别处，也更容易守住原有行为。反过来，如果这段代码只跑一次、错了重生成就行，为它设计扩展点就是在为不存在的需求付费。判断可以落到一个动作：挑一处你最近改过、又怕改坏的地方，先不重构，只写一条能验证对外行为的检查，再让 AI 做这次改动，看它能否在不动这条检查的前提下完成。

出处 2 3