DeepSeek 横空出世的价值对于中国AI行业而言，无异于2024年8月中国3A游戏行业的“八方云涌，乾元雷动”。以 DeepSeek 为代表的中文原生大语言模型的技术价值是什么？以其为基座又能构建哪些 B/C 端应用？未来的软件研发趋势又将发生哪些变化？
腾讯云近日推出了 HAI 上的一键部署、3分钟可用的 DeepSeek -R1 实例，由于过于火爆，排队等待之余，写一写我对 DeepSeek 的思考。
对于大语言模型 AI 的应用，我属于比较乐观的人群，在2022年9月就在信通院的可信数字化公号里写了一篇对未来应用的预言，2023年5月又在信通院的低无代码峰会上，随着腾讯和百度工程师现场演示的自然语言+大语言模型+低代码三位一体的开发方式，我感慨的提出，未来3年内，程序员行业可能会消失。
随着大语言模型快速迭代，似乎离未来越来越近，但是始终缺乏一个 Aha 时刻。是的，国内大语言模型 AI 生成的内容还是那么容易被识破，幻觉和点状的思维，国外的开源版本对中文支持一般，种种问题，使得 LLM AI 的落地总是差了一口气。如果要形容一下这个感觉的话，就像招聘时面试了十个工程师，虽然都还行，但是总觉得没有让人非常满意的，勉强招进来的话，按他们的水平，说不定啥时候会给自己捅一个大漏子。
直到 DeepSeek-R1 的出现。
我们抛开一切感性，以纯纯的理性的评价一下 DeepSeek-R1，我认为有以下几个特点：
推理能力强
，能够清晰地把“思考过程“展示出来。这一点很关键，没有”思考过程“，他就只是一个黑盒子，有了”思考过程“，意味着我们可以知道他一旦没有输出预期的结果，可能的原因会在哪里。在学校里，数学老师可不会因为你直接给出了答案而给你满分，他需要你的”解题步骤“，没错，DeepSeek 是第一个完整写出解题步骤的开源 AI，这意味着未来可以有更好的磨合与引导，从而可以得到更满意的答案。
性能高
，我甚至在我的苹果 12 ProMax 上安装了一个 2GB 的 1.4B 版本，对于简单的问题执行效果很好也很快。虽然没什么实用性，但是意味着未来广阔的可能。
原生中文训练
，这意味着对中文的理解比所有国外的大语言模型都有优势。
便宜
，百万字的处理，大概是一元钱的样子，不用联外网，不用借用国外信用卡，不用担心 IP 是大陆而被封号，使用门槛极大地降低了。
有了这个几个前提，我们来聊一下，大语言模型的 AI 落地应用，到底会在哪里？
首先，to C 的业务，只要和文字内容有关的，都可以用这个免费高速的工具，例如，有人用它做了一个工具，通过工具的一步步提示，和访谈者互动，DeepSeek 自动润色补足，即使是一个初中生，也能极低成本的帮别人写回忆录，这个业务其实就很有意思。类似的业务很多，我们就不一一列举，今天我们的重点是to B。
我的主业是企业数字化和智能化转型，在 to B 业务中，纯粹的“公共知识”训练出来的AI作用并没有那么大。同时，绝大部分的企业也并没有做好相应的准备，无论是商业模式还是组织架构，都远远没有将 AI 作为2025年的 “必选项” 进行考虑。因为在 DeepSeek R-1 腾空出世前，大部分企业端技术对大模型的认知都和我类似：“离好用还差这么一截“，无论是语言问题、国内外的网络环境问题、还是价格、性能，都有着一点点的不舒服，这一点点的体验差，也让很多传统企业的 CIO 不敢投入，在这方面的思考也多数基于案例学习，浅尝即止。
我的习惯是以终为始，我们先假设未来，一起讨论这样的未来是否正确，然后我们再倒推出如何一步一步实现，这样一旦机会来临，我们往往能第一个抓住。
我对大语言模型 AI 在 to B 业务上的判断如下
宏观：企业将会融合传统数据库、GraphRAG、大语言模型等，统一形成一个新的数据+智能的存储访问形式，我们可以称之为数智库，以示与传统数据库的区别与联系。
介观：围绕这个体系，企业内所有的管理系统、组织结构，都会随之发生变化，企业的需求管理和开发体系也会发生巨大变化。
微观：服务类工作由于需要“真人”存在，暂时不会被替代，但是这些“真人”会受到碎片化的冲击，也就是从长期工变为小时工，随之而来的“服务知识”体系也会被“数智库”重构。
有趣的是，这一系列观点，是我在参与企业的“数据资产化“实践中提出的，时间大约是2024年4~5月间。
后来发现 Oracle 在同年5月发布了 Oracle 23ai，从一线数据库厂商的角度提出了同样的认知，在数据库中专门增加了 “Vectors” 字段类型，试图把向量数据也纳入到 Oracle 的数据结构中；随后的7月份，在微软开源 GraphRAG 后，Oracle 又迅速整合了已有的图数据和向量数据，提供了为 AI 服务的数智 RAG 体系。
众所周知的原因，Oracle 的 23ai 再好，也不能解决我们的问题。如果我们从算力角度来看，我们会发现 23ai 还是太重：集中在“数据”的 CPU 算力，和集中在 AI 的 GPU 算力相比，不是一个量级，那么我为什么要去买一个“数据库附送 AI”？难道不应该是“买AI附送数据库”么？
所以未来更有可能是从某个大语言模型出发，基于 AI 的需要，构建文件结构，然后再延申或包容一个数据库，这将会是新的“数智库”的雏形，也极有可能孕育出和 Oracle 一样的伟大企业。
宏观的概念告一段路，我们回到介观的角度，来看一下企业该如何做？
我们在说明企业在做某件事不能成功的时候，我们往往会说，“这个企业组织结构还没有做好准备”。大家都很清楚，企业是将人组织起来的一个纽带，企业最重要的就是组织，它直接决定了1+1是大于2还是小于1。那么如果要应对AI年代，企业的组织需要如何进化？
以前我有一个观点，如果企业在做了数字化转型以后，商业模式没有发生任何变化，那其实这个数字化转型是失败的，信息化就够了，没必要搞什么数字化。
同样的，AI 智能化首先需要所有人树立一个“数字员工“的概念：将会学习企业的哪些知识（如何连接”数智库“），然后从企业的各个维度去思考“他”能做什么，现在能做什么，未来又能做什么。我们需要建立什么团队与组织来保障这个“数字员工”的工作能够准确、高效、可持续迭代。未来，我们企业都需要增加一个“首席知识官”，建立“知识部门”，来服务于这个有着无限可能，可以无限复制的“数字员工”。
从一个技术管理人员的角度，我随后又问了 DeepSeek 这样一个问题：
在AI辅助编程已经成为肉眼可见的趋势以后，toB软件的开发从组织架构，到业务流程，都应该提前做出什么样的改变来适应未来的趋势呢？以前的成本主要集中在编程，现在是否应该集中在需求和需求价值量化呢？AI加低代码和AI辅助代码生成这些技术会对整个研发产业有什么样的冲击？我们需要提前做什么准备与改变？
已深度思考（用时 28 秒）
在AI辅助编程和低代码技术迅速发展的趋势下，toB软件开发的业务模式、组织架构和行业生态将发生深刻变革。以下是系统性应对策略分析：
### 一、组织架构重构
1. **能力重心转移**
- 成立"需求工程部"：配备业务架构师、价值量化分析师、领域建模专家，构建需求形式化表达体系
- 组建AI训练团队：负责领域知识图谱构建、Prompt工程优化、模型微调，将业务需求转化为机器可理解的语义模型
2. **开发流程再造**
- 建立"双模开发体系"：基础功能采用AI+低代码快速实现，核心业务保留传统开发深度优化
- 引入"AI质检官"角色：负责代码生成质量评估、技术债务监控、AI输出合规性审查
### 二、业务流程变革
1. **需求价值量化体系**
- 开发"需求ROI评估模型"：结合客户LTV、实施成本、技术可行性构建多维评估矩阵
- 构建动态需求池：通过机器学习预测需求优先级，实现需求价值随时间变化的智能排序
2. **AI增强型开发流程**
- 建立"人机结对编程"机制：开发者角色转型为AI训练师和代码审查员
- 实施"需求-代码追溯系统"：通过区块链技术记录需求到代码的完整演变路径
### 三、成本结构重塑
1. **成本分配比例重构**
- 需求工程投入提升至40%：包含业务建模、流程仿真、价值验证
- AI训练成本占比25%：涵盖领域数据治理、模型微调、知识库维护
- 传统编码成本压缩至15%：聚焦核心算法和架构设计
2. **价值验证机制创新**
- 开发"数字孪生沙盒"：在需求阶段通过虚拟环境验证业务价值
- 构建"经济影响模拟器"：量化每个功能点对客户业务指标的预期影响
### 四、技术冲击应对
1. **产业格局预判**
- 催生"AI解决方案设计师"新职业：精通业务抽象和AI工具协同
- 形成"领域模型即服务"新市场：各垂直行业的标准化AI开发基座
- 出现"智能合约式开发"新模式：需求方直接参与AI训练生成定制方案
2. **核心能力建设**
- 构建"三维能力矩阵"：
- X轴：业务理解深度
- Y轴：AI驾驭能力
- Z轴：价值量化精度
- 发展"需求工程学"方法论：融合设计思维、系统动力学和机器学习
### 五、战略准备建议
1. **人才结构升级**
- 培养"π型人才"：同时具备业务纵深、技术视野和数据思维
- 建立AI素养认证体系：从Prompt工程到模型审计的完整能力评估
2. **技术债务防控**
- 开发"AI技术债务检测仪"：实时监控生成代码的架构合理性
