本文探讨了业务开发工程师如何从日常业务代码中脱颖而出，成为技术大牛。文章强调了理解业务本质的重要性，指出技术是为业务服务的。作者区分了“问题空间”和“解空间”，并指出识别和定义问题比解决问题更关键。文章还提出了业务系统在“从 0 到 1”和“从 1 到 100”阶段面临的不同挑战，即痛点洞察和系统动态进化能力。最后，文章还将业务建模与当前热门的 Prompt Engineering 联系起来，强调了结构化思考和抽象分解问题在 AI 时代的新价值。
2026-01-16 08:46 北京
没有业务的技术，犹如无源之水无根之木。成为技术大牛的前提，是搞懂业务的本质。
业务：一个组织、公司或个人所从事的商业活动、服务或工作，相应的流程和规则。
业务相关活动所涉及的问题范围，即问题域，通常也是公司为其客户提供的服务。
产品，通常是指对应的业务背景下为相关问题域提供的解决方案，即为用户/目标组织所提供的系统或服务。
产品是对解决方案的包装，支撑起解决方案的实现即系统（业务系统）。
业务开发，冠以“业务”前缀，要的是在技术通识的基础上，更要熟悉业务。
业务开发团队，要承接并交付出“好”的业务系统，挑战在两点：
从0到1阶段：洞察用户痛点，解决核心用户问题。
1到100阶段：业务系统能轻松、高质量地动态进化，在不断发展中支持业务攻城略地。
洞察痛点：本质在于理解业务，能够定义边界/聚焦重点
【面向需求】要开发什么样的产品？
【面向业务】为什么要开发这个产品？要解决什么问题，达成什么目标？
动态进化：本质依托于业务系统的设计和实现
【面向设计】如何做才能契合业务形态应对变化、减少制约以更好的达成目标？
对于技术要承载的业务，要跳出单一代码视角，从两种视角拆开看：
问题空间：即问题域，探讨关注有什么问题要解决，存在什么痛点要消除，也即需求；
解空间：也称解决方案域，考虑有哪些方案去解决问题；最终用哪个方案做到了，称为实现。
提问题比解决问题更重要。
初识业务，或者成熟业务上扩展出新需求，需要主动思考：
业务现状，为谁服务？全景如何，上下游如何合作？核心价值，利润来源？最重要待解决问题？……
有全局认识，才能建立足够的判断力，帮助高效对接/厘清业务，放大价值贡献。
业务建模是一个体系化主题，不同的场景有其合适的用法。只有当有更多角色直接参与，并有更多不同业务信息由该系统处理时，业务建模才会增加更多价值。例如，纯技术领域的问题中，与业务无关，可以无须业务建模，你的代码和数据结构就是你的模型抽象
当 LLM 掀起巨浪，Prompt Engineering的本质也是“如何理解业务并结构化陈述业务需求”，这与业务建模方法为业务开发赋予的理解问题域能力正好契合，“声明式的方法+结构化抽象并逐步分解问题”的思维不会过时，AI时代甚至有机会赋予业务开发新价值。
延展阅读：天天写业务代码，如何破局业务开发的本质？
各位彦祖亦菲，你对本篇命题的答案是？
