天天写业务代码，如何成为技术大牛？

没有业务的技术，犹如无源之水无根之木。成为技术大牛的前提，是搞懂业务的本质。

 业务：一个组织、公司或个人所从事的商业活动、服务或工作，相应的流程和规则。

 业务相关活动所涉及的问题范围，即问题域，通常也是公司为其客户提供的服务。

 产品，通常是指对应的业务背景下为相关问题域提供的解决方案，即为用户/目标组织所提供的系统或服务。

 产品是对解决方案的包装，支撑起解决方案的实现即系统（业务系统）。

 业务开发，冠以“业务”前缀，要的是在技术通识的基础上，更要熟悉业务。

 业务开发团队，要承接并交付出“好”的业务系统，挑战在两点：

 从0到1阶段：洞察用户痛点，解决核心用户问题。

 1到100阶段：业务系统能轻松、高质量地动态进化，在不断发展中支持业务攻城略地。

 洞察痛点：本质在于理解业务，能够定义边界/聚焦重点

 【面向需求】要开发什么样的产品？
【面向业务】为什么要开发这个产品？要解决什么问题，达成什么目标？

 动态进化：本质依托于业务系统的设计和实现

 【面向设计】如何做才能契合业务形态应对变化、减少制约以更好的达成目标？

 对于技术要承载的业务，要跳出单一代码视角，从两种视角拆开看：

 问题空间：即问题域，探讨关注有什么问题要解决，存在什么痛点要消除，也即需求；

 解空间：也称解决方案域，考虑有哪些方案去解决问题；最终用哪个方案做到了，称为实现。

 提问题比解决问题更重要。

 初识业务，或者成熟业务上扩展出新需求，需要主动思考：

 业务现状，为谁服务？全景如何，上下游如何合作？核心价值，利润来源？最重要待解决问题？……

 有全局认识，才能建立足够的判断力，帮助高效对接/厘清业务，放大价值贡献。

 业务建模是一个体系化主题，不同的场景有其合适的用法。只有当有更多角色直接参与，并有更多不同业务信息由该系统处理时，业务建模才会增加更多价值。例如，纯技术领域的问题中，与业务无关，可以无须业务建模，你的代码和数据结构就是你的模型抽象

 当 LLM 掀起巨浪，Prompt Engineering的本质也是“如何理解业务并结构化陈述业务需求”，这与业务建模方法为业务开发赋予的理解问题域能力正好契合，“声明式的方法+结构化抽象并逐步分解问题”的思维不会过时，AI时代甚至有机会赋予业务开发新价值。

 延展阅读：

各位彦祖亦菲，你对本篇命题的答案是？