不知为啥，我有那种有点无法自控的爱管闲事儿的臭毛病，因而在有的微信群中把自己群昵称改成了「热心网友」。
最近有些同行在找工作，刷八股文，问某种面试题该怎么回答，诸如此类。
看到他们那样，我心里就急得上蹿下跳的——明明前方是火坑，咋还接二连三看似心甘情愿地往里跳呢？？？
在当下这个时间点，我的同行绝大部分是以 HTML、CSS、JavaScript 等为核心的「Web 前端」，他们之中绝大部分是业务前端，这些人中绝大部分做中后台类应用。
中后台的「势」
中后台类应用有两个重要特点——
第一，业务流程和数据安全远远优先于产品体验，与所谓的「产品力」、花里胡哨的视觉设计等相比，让业务流程顺利地走下去，使数据保持完整要重要得多，其他的只是锦上添花。
尤其是在面向制造业等实体行业时，就算没有数字产品，业务也照样跑，只不过是效率低了些；数字产品只为提效而存在，无权改变既有业务规则，不能本末倒置。
所以说，做中后台类应用的公司或部门不需要 to C 的那种「产品经理」，需要的是能够梳理明白业务方（主要是行业或领域专家）需求且准确传达的「需求经理」。
第二，中后台类应用前端部分高度模式化，又由于是业务与数据优先，在整个系统层面可以更好地建模，并抽象出以模型为源头向应用成品自动推导的构建管线。
也就是说，只要从业务中提取出了模型，基于某种机制在描述出各种关系后，就能够直接看到应用可操作的最终效果。
描述关系的方式可以是：
- XML、JSON、JS 纯对象等类编程体验的 DSL；
- 在页面中拖拉拽的可视化操作；
- 让 AI 理解需求文档后转译。
其中，最后一种便是我所提倡并追求的「知识驱动的、智能的产研一体化平台」所具备的能力。
至于那个「机制」是什么，目前我看好的有两个：
但他们都缺少纯前端部分的支持，我的「反混沌前端工程」会把这个空位补上。
工程师的「命」
在 ChatGPT 出现在大众视野之前，我们就认为在中后台类应用研发流程中设计师与前端工程师会被干掉，由「需求经理」与后端工程师协作就能胜任。
而 ChatGPT 及类似产品的出现，让大部分后端 CRUD 工程师被干掉也成为了可能，「需求经理」仅需编写详实的需求文档即可。
既然业务研发工程师会被知识驱动的、智能的产研一体化平台所替代是「势」，那我们何不去加快这个进程？！
在我们看来从事此类研发的岗位是没有未来的，但有些人并不如此觉得——或以现状的眼光去思考，或认为人类比 AI 强。
然而事实是——科技的迭代与增长速度从来不是线性的，其发展所带来的影响之一就是要求人们革新自己的知识与技能；人类最愚蠢的地方就是自以为是。
结语
虽然本文中主要聊的是中后台类应用的业务研发工程师会「死伤惨重」，不代表 to C 的就「毫发无损」，只不过比例不会那么大。
与我所秉持的设想相比，师兄的一个说法更夸张了点——没准儿哪天 AI 大力出奇迹，直接生出由源码构成的应用，而不是那种经过层层抽象的。
这种应用是个黑盒，从软件工程角度来看是不可维护的，任何最佳实践、优化手段都将失效——既没意义，又没必要——就像有了车之后，关于骑马的知识与技能都没用了。
很多时候我觉得自己像是那种人——告诉别人几天后大家会迎来灾难，要赶紧逃亡，然而一个个却觉得我是在胡说八道，看我笑话。
所以，这是我最后一次的劝诫，希望看到且看懂的人能有所行动，别再往火坑里跳。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。