
hello,大家好,我是人月聊IT。今天聊聊AI大模型时代对软件系统构建带来的新冲击。下面是我B站口播视频转的文字稿内容。
今天在跟客户沟通的时候,触发我相当重要的一个观点,就是随着整个AI大模型的一个快速的发展,包括智能体,包括类似于ClaudeCode,MCP,上下文工程一系列的东西,很有可能会改变传统toB软件IT业务系统的展现形态。
以后很有可能根本就没有IT业务系统这个概念,也不会你一个用用户登录一个系统,一进去就是一级菜单,二级菜单功能点这么一种展现形态。
最近我在跟客户沟通的时候,更多的是在谈业务对象建模。首先我纠正了他一个重要的观点,就是从4A架构里面也在谈业务对象。但是这个业务对象很多时候更多的是在谈你管理的人事物
它更多的是谈数据层面的业务对象。但是在BABok业务架构体系里面,他谈到的业务对象更类似于面向对象分析设计里面的对象建模。这个对象不仅仅有相关的对象属性。同时也包括了对象的行为 ,对象的规则和算法,所有的东西加起来才是完完整整的一个业务对象。
所以我们在去考虑业务对象建模的时候,不仅仅是进行数据架构、数据模型的建模,更多的还要去做相关的行为的建模,规则的建模,算法的建模。
当我说到这个地方的时候,大家是不是感觉和我前面在讲本体论建模的时候的思路是完全一样的?所以上次有一个朋友在我本体论的公众号文章下面留言,就提到了本体论这个思想不是什么新东西。我传统的面向对象分析设计理面, 我对象建模的思路本身就包括了对象属性数据行为规则算法这一系列的东西。
只有这些东西打包,它才是一个完完整整的对象。那为什么我们现在又要重新再考虑对象建模这个事情呢?
因为只有完整的对象建模,你才能够实现数字化的虚拟世界和现实世界之间的双向映射。包括我在最早解释数字化的概念的时候,也谈到了在整个数字化里面本身就涉及到对象的数字化,行为的数字化和规则的数字化。
我要通过虚拟世界去反向模拟现实世界的一个事情的时候,你仅仅有静态数据是不够的。你必须还有相关的业务活动行为,还有相关的规则算法,这些所有的东西打包起来,你才能够真实的去模拟现实世界。(这个实际和我传统IT系统开发中不仅仅有数据库和数据层,还有业务逻辑层一个道理。)
就像我现在要去做一次试验一样,你只是拿着一个试验的模板试验的表单,你是没办法完成整个实验的过程的,你还需要有相关的操作指导指导你还需要有相关的算法库,你还需要有相关的参考模板,所有的东西组装起来就形成一个完整的实现了你经验显性化的这么一个对象。对于我们以后的软件开发也是一样的道理。

Skills = 对象 + 行为 + 规则算法
我们更多的应该是对于业务流程业务梳场景梳理完成了以后,形成一个个高度可复用的业务对象。这个对象大家就可以理解为它是数据模型、算法模型、行为规则之间的一个融合体。而我们在对这个对象进行定义的时候,完全可以参考上下文工程和Claude Skills技能库的定义方式。我既可以定义相关的业务流程活动, 又可以去定结构化定义它的数据模型,还可以详细的定义它的规则和参考模板。
所有的东西我把它打包到一个对象里面,形成一个技能库。在这个技能库里面,可能还包括了各式各样的代码片段。这个技能库起什么作用?
当面对不同的业务场景的时候,他知道怎么样去用你这个对象。怎么样去裁剪相关的数据模型,怎么样去应用相关的算法,最终得到一个结果。所有东西是不是人在做,很有可能不是,而是AI大模型自动完成的。
原来我在讲软件开发和SOA架构的时候,更多的是在谈通过SOA架构的思想,通过相关的可视化的工具来实现组建的编排和API接口的灵活编排。
但是到了AI时代,大家一定要理解,我谈的不是AI智能体里面的Workflow。我谈的是AI接受到不同的需求以后,它自动化的进行语义加代码片段的编编排。这个东西不需要人工干预,只要你定义完善各个可复用的对象模型,所有的东西全部是可以自动化的组装和编排起来的。
我编排的最小单位已经到了代码片段,而且所有的代码片段它可以是动态调整和动态优化。当我定义的这么一个技能库,它下层可能还集成了相关的MCP Serv的能力。
同时我形成的这么一个对象技能,它又可以发布为一个新的MCP Server。这样就实现了原子对象到符合对象到上层组合对象的层层的嵌到和组装。
所有的事情也是AI大模型可以自己去完成的。所以想象一下我们以后面对的IT应用IT系统。它可能没有一个系统, 也没有一个个你可以点进去的菜单,而类似于早期百度提出来的框计算的概念,我就是一个文本框,你把需求输给我AI去理解了你的需求以以后去自动化的完成语义加对象模型的组装编排,最终输出一个完整的结果给你。
以下是通过AI基于我上面关键思考扩写的完整文章供进一步参考:
最近在与客户沟通业务对象建模时,我产生了一个重要洞察:随着AI大模型、智能体和上下文工程的快速发展,传统toB软件的展现形态可能面临颠覆性变革。未来3-5年,我们很可能不再需要登录系统、点击层层菜单的交互方式,取而代之的是一个智能化的"意图理解+对象编排"系统。
让我用一个场景来说明这种变化:
传统方式:采购经理登录ERP系统 → 点击"采购管理" → 选择"采购订单" → 填写20多个字段 → 选择供应商 → 设置审批流程 → 提交
未来方式:采购经理对AI助手说:"需要紧急采购500个型号XYZ的零件,三天内到货,预算控制在5万以内,帮我找最合适的供应商并创建订单。"系统理解意图后自动完成所有操作。
这不是科幻,而是正在发生的现实。本文将深入探讨这一变革的底层逻辑、技术实现路径以及面临的挑战。
传统IT业务系统存在三大核心痛点:
功能碎片化:业务被拆分成一个个功能点,散落在各级菜单中。用户需要记忆功能位置,学习成本高。一个完整的业务流程往往需要跨越多个模块、多次操作。
流程固化:系统预设了固定的操作路径和审批流程。当业务场景发生变化时,必须通过开发改造才能适应,响应速度慢、成本高。
数据与行为分离:传统系统重数据建模,轻行为建模。数据库存储了大量结构化数据,但业务规则、算法逻辑、操作经验往往分散在代码、文档和人脑中,无法形成可复用的知识资产。
真正的数字化不仅是数据的数字化,更是对象、行为和规则的全面数字化。要实现虚拟世界与现实世界的双向映射,我们需要:
只有这三者结合,才能在虚拟世界中真实模拟现实业务,实现预测、优化和自动化。
在4A架构(应用架构、应用集成架构、应用服务架构、应用基础架构)中,业务对象更多指"管理的人事物":
这些对象侧重于数据层面的定义,主要回答"是什么"的问题。而在BABOK(业务架构知识体系)中,业务对象借鉴了面向对象分析设计的思想,是一个包含四个维度的完整体:
完整业务对象 = 对象属性(数据模型) + 对象行为(业务活动) + 对象规则(决策逻辑) + 对象算法(计算模型)
这种建模方式与 本体论(Ontology) 的思想高度一致。本体论不仅定义实体的静态特征,还定义实体间的关系、约束和推理规则,形成一个可被机器理解和推理的知识网络。
为什么要重提对象建模?因为只有完整的对象建模才能支撑AI时代的三大需求:
需求一:知识显性化
需求二:智能化编排
需求三:持续进化
识别对象的三个层次:
对象定义的四要素:
对象定义 {
属性模型: 结构化数据schema + 非结构化描述
行为模型: 可执行的业务活动流程
规则模型: if-then决策规则 + 约束条件
算法模型: 计算逻辑 + 机器学习模型 + 代码片段
}
对象间关系管理:
┌─────────────────────────────────────────────────────────┐
│ 用户交互层(自然语言接口) │
│ "紧急采购500个XYZ零件,三天到货,预算5万" │
└────────────────────┬────────────────────────────────────┘
│
↓
┌─────────────────────────────────────────────────────────┐
│ AI理解与编排引擎 │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 意图识别模块 │→│ 对象检索模块 │→│ 编排执行模块 │ │
│ │(LLM+NLU) │ │(向量检索) │ │(动态组装) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
└────────────────────┬────────────────────────────────────┘
│
↓
┌─────────────────────────────────────────────────────────┐
│ 对象技能库 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 原子对象层 │ │ 组合对象层 │ │ 复合对象层 │ │
│ │ 供应商/物料 │ │ 采购订单 │ │ 智能补货 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ 每个对象包含: │
│ • 语义描述(自然语言+结构化schema) │
│ • 上下文定义(适用场景、前置条件、输入输出) │
│ • 执行逻辑(工作流+代码片段+API调用) │
│ • 规则算法(决策树+评分模型+优化算法) │
└────────────────────┬────────────────────────────────────┘
│
↓
┌─────────────────────────────────────────────────────────┐
│ 基础能力层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │微服务API │ │数据服务 │ │规则引擎 │ │算法服务 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────┘
模块一:意图识别模块
功能:将自然语言需求转化为结构化的意图表达
关键技术:
输出示例:
{
"intent": "create_purchase_order",
"entities": {
"material": "XYZ零件",
"quantity": 500,
"delivery_time": "3天",
"budget": 50000
},
"constraints": ["紧急", "成本优先"],
"implicit_requirements": ["自动选择供应商", "加急处理"]
}
模块二:对象检索模块
功能:从对象技能库中检索匹配的对象
关键技术:
检索过程:
用户意图 → 语义向量化 → 检索候选对象 → 评估匹配度 → 排序输出
检索结果示例:
1. "紧急采购订单对象"(相关度: 0.95)
├─ 依赖: 物料对象、供应商对象、价格对象
├─ 包含: 供应商智能推荐算法
└─ 适用场景: 紧急采购、成本敏感
2. "标准采购订单对象"(相关度: 0.78)
├─ 依赖: 物料对象、供应商对象
└─ 适用场景: 常规采购
模块三:编排执行模块
功能:动态组装对象并执行
关键机制:
编排过程:
1. 构建对象依赖图
紧急采购订单 依赖→ [供应商推荐, 价格计算, 库存检查]
供应商推荐 依赖→ [供应商对象, 评分算法]
2. 生成执行计划
Step1: 并行执行 [获取物料信息, 查询库存, 加载供应商列表]
Step2: 执行供应商评分算法(输入: 交期=3天, 预算=5万)
Step3: 执行价格计算(输入: 最佳供应商, 数量=500)
Step4: 创建采购订单(输入: 前序所有结果)
Step5: 触发审批流程(自动路由到紧急审批通道)
3. 动态执行与监控
- 实时反馈执行进度
- 遇到异常时提示用户或自动降级
对象封装标准:
参考Claude Skill和上下文工程的设计理念,每个对象包含:
object_id: urgent_purchase_order_v2.1
object_name:紧急采购订单对象
description:
summary:处理紧急采购场景的智能订单创建对象
detailed:|
适用于需要快速响应的采购需求,自动推荐满足交期和成本要求
的供应商,优化审批流程,支持风险预警。
context:
preconditions:
-物料编码已存在
-采购权限已验证
input_schema:
material_code:string
quantity:integer
delivery_days:integer
budget:float
priority:enum[urgent,normal]
output_schema:
order_id:string
supplier:object
total_cost:float
estimated_delivery:date
dependencies:
-object:supplier_recommendation_v1.5
type:required
-object:price_calculation_v2.0
type:required
-object:inventory_check_v1.3
type:optional
behavior:
workflow:
-step:validate_input
action:check_material_code_exists
-step:check_inventory
action:call(inventory_check)
condition:available_stock<required_quantity
-step:recommend_supplier
action:call(supplier_recommendation)
params:
delivery_time:${input.delivery_days}
budget:${input.budget}
-step:calculate_price
action:call(price_calculation)
-step:create_order
action:execute(order_creation_logic)
-step:route_approval
action:call(urgent_approval_workflow)
rules:
-name:budget_constraint
condition:total_cost>budget*1.1
action:alert_and_request_approval
-name:delivery_risk
condition:supplier.lead_time>delivery_days
action:flag_risk_and_suggest_alternatives
algorithms:
-name:supplier_scoring
type:machine_learning_model
model_path:/models/supplier_score_v3.pkl
inputs:[delivery_time,historical_performance,price,capacity]
output:score(0-100)
-name:dynamic_pricing
type:code_snippet
language:python
code:|
def calculate_urgent_price(base_price, quantity, urgency_days):
urgency_factor = 1 + (0.1 / urgency_days)
volume_discount = 1 - min(quantity / 1000, 0.15)
return base_price * urgency_factor * volume_discount
code_snippets:
-snippet_id:order_creation
description:创建采购订单的核心逻辑
code:|
// 伪代码
order = {
material: validated_material,
supplier: recommended_supplier,
quantity: input.quantity,
price: calculated_price,
delivery_date: today + delivery_days
}
order.save()
trigger_event("order_created", order.id)
metadata:
version:2.1
author:supply_chain_team
created_at:2025-01-01
last_updated:2025-12-15
usage_count:1523
success_rate:0.94
对象库的组织结构:
对象技能库
├── 领域层
│ ├── 供应链域
│ │ ├── 采购子域
│ │ │ ├── 原子对象(供应商、物料、价格...)
│ │ │ ├── 组合对象(采购订单、询价单...)
│ │ │ └── 复合对象(智能采购、供应商优化...)
│ │ ├── 库存子域
│ │ └── 物流子域
│ ├── 财务域
│ └── 销售域
├── 通用层
│ ├── 审批流程对象
│ ├── 通知对象
│ └── 数据验证对象
└── 基础层
├── 数据访问对象
└── 系统集成对象
挑战1:语义理解的准确性
解决方案:
挑战2:对象组合爆炸
解决方案:
挑战3:执行性能保障
解决方案:
角色:某制造企业采购经理张经理
场景:生产线上一台关键设备的进口零件突发故障,需要紧急采购替换件,否则将导致生产线停工,每天损失超过50万。
需求:
张经理需要执行以下步骤(预计耗时4-6小时):
问题:
用户交互:
张经理对AI助手说(或语音输入):
"紧急情况!生产线3号设备故障,需要采购型号IMP-2024-X7的进口零件2个,必须48小时内到货,预算单价8万以内,质量要原厂或认证品牌,加急物流费用可以接受,帮我尽快处理。"
AI系统内部处理:
Step 1: 意图识别与实体抽取(耗时2秒)
{
"intent": "urgent_purchase_request",
"priority": "critical",
"entities": {
"material": {
"code": "IMP-2024-X7",
"category": "进口零件",
"quality_requirement": "原厂或认证品牌"
},
"quantity": 2,
"delivery_time": {
"value": 48,
"unit": "hours"
},
"budget": {
"unit_price_max": 80000,
"total_max": 160000
},
"additional_services": ["加急物流", "加急报关"]
},
"constraints": [
"时间优先级高于成本",
"质量不可妥协",
"接受合理的额外费用"
],
"implicit_requirements": [
"自动选择最优供应商",
"自动安排物流",
"走紧急审批通道",
"实时跟踪订单状态"
]
}
Step 2: 对象检索与组合(耗时3秒)
AI从对象技能库中检索到相关对象:
主对象: "紧急采购订单对象_v3.2"(匹配度: 0.97)
依赖对象:
├─ 物料信息对象(获取零件详细规格)
├─ 供应商智能推荐对象_紧急版(考虑库存、交期、质量认证)
├─ 动态定价对象(评估加急溢价的合理性)
├─ 跨境物流对象(计算物流时间和费用)
├─ 紧急审批工作流对象(自动路由到有权限的最近领导)
└─ 订单跟踪对象(实时同步物流信息)
检测到场景特征: "生产线停工风险" → 触发"停工损失计算对象"
自动扩展对象: "风险评估与决策建议对象"
Step 3: 执行编排(总耗时45秒)
[0-5秒] 并行执行:
→ 查询物料档案(已找到,规格确认)
→ 查询当前库存(零库存确认)
→ 加载供应商列表(找到12家潜在供应商)
→ 计算停工损失(48小时潜在损失: 100万)
[5-15秒] 供应商智能评估:
→ 实时调用供应商API查询库存(8家有现货)
→ 调用供应商评分算法:
评分维度 = [历史准时率, 质量合格率, 价格竞争力,
应急响应能力, 物流时效, 认证资质]
→ 输出排序结果:
1. 供应商A(得分92): 有现货2个,单价7.8万,
空运24小时可达,原厂认证,历史合作优秀
2. 供应商B(得分88): 有现货3个,单价7.5万,
陆运+空运36小时,认证替代品,价格优势
3. 供应商C(得分85): ...
[15-25秒] 综合决策:
→ 执行风险评估算法:
if 选供应商A: 成本15.6万, 风险低, 24小时到货
→ 避免停工损失100万, ROI极高
if 选供应商B: 成本15万, 风险中, 36小时到货
→ 可能损失50万, 节省6000元不合理
→ AI决策建议: "强烈推荐供应商A,虽然单价略高6千,
但24小时到货可避免巨额停工损失,ROI显著"
[25-35秒] 自动创建订单:
→ 填充订单所有字段(自动从供应商A获取)
→ 计算总价: 15.6万(含加急物流费1.2万)
→ 配置支付方式: 预付50%,货到付余款
→ 绑定加急物流: 空运直达,专人提货
→ 生成订单合同(自动填充条款)
[35-40秒] 启动紧急审批:
→ 识别场景: 生产线停工风险
→ 路由策略: 跳过常规流程,直达生产副总+财务经理
→ 附加信息: 风险分析报告+成本收益对比
→ 发送实时通知(钉钉+短信+邮件)
[40-45秒] 配置后续跟踪:
→ 创建订单跟踪看板
→ 设置物流关键节点提醒
→ 配置异常预警规则(如延误>2小时自动升级)
Step 4: 用户反馈(实时展示)
AI向张经理展示决策结果:
✅ 已为您完成紧急采购订单创建
【核心信息】
零件: IMP-2024-X7 × 2个
供应商: XX国际零件(供应商A)
单价: ¥78,000
总价: ¥156,000(含加急物流¥12,000)
预计到货: 明天下午14:00(约24小时后)
【为什么选这家】
• 原厂认证,质量有保障
• 现货充足,可立即发货
• 空运直达,时效最快(24h vs 其他36-48h)
• 历史合作优秀(准时率98%,质量合格率100%)
【成本收益分析】
• 比最低价供应商贵¥6,000
• 但可提前12小时到货,避免生产线额外停工
• 避免潜在损失约¥50万
• 投资回报率: 8,233%
【审批状态】
已自动提交紧急审批通道
• 生产副总李总(已推送通知,等待审批)
• 财务经理王经理(已推送通知,等待审批)
预计10分钟内完成审批
【实时跟踪】
您可以随时问我"订单进展如何"查看实时状态
需要我做什么调整吗?
Step 5: 用户确认或调整
张经理回复:"很好,就按这个执行,另外帮我通知生产部做好接货准备。"
AI执行:
✅ 已发送通知给生产部张主管和设备维修组
✅ 已预约明天下午厂区货运入口,预留装卸位
✅ 已提醒仓库准备质检流程
所有安排已就绪,我会持续跟踪并及时向您汇报进展。
维度 | 传统方式 | AI驱动方式 | 提升幅度 |
|---|---|---|---|
处理时长 | 4-6小时 | 45秒 + 10分钟审批 | 减少95% |
操作步骤 | 50+步骤,跨3个系统 | 1次对话 | 简化98% |
决策质量 | 依赖个人经验,可能遗漏最优方案 | AI综合评估12家供应商,量化风险收益 | 全面性提升 |
错误率 | 手工填写易出错 | 自动化处理,结构化验证 | 降低90%+ |
知识传承 | 依赖老员工,新人上手慢 | 经验封装在对象中,即用即会 | 门槛大幅降低 |
可追溯性 | 决策过程主要在人脑和微信 | 完整记录决策依据和过程 | 透明度提升 |
财务价值:
这个场景背后,AI实际上完成了12个对象的智能编排:
对象编排图:
用户意图
↓
意图理解对象 ──→ [紧急采购场景识别]
↓
┌────────────────编排决策────────────────┐
│ │
↓ ↓ ↓
物料信息对象 库存查询对象 停工损失计算对象
│ │ │
└────┬───────────┴───────────────────────┘
↓
供应商推荐对象(集成3个子对象)
├── 供应商评分算法对象
├── 库存实时查询对象
└── 物流时效评估对象
↓
风险收益分析对象
├── 成本对比算法
└── ROI计算对象
↓
采购订单创建对象
├── 合同生成对象
└── 支付配置对象
↓
┌──────┴──────┐
↓ ↓
紧急审批 物流跟踪对象
工作流对象 ├── 关键节点提醒
│ └── 异常预警规则
└────┬────────┘
↓
通知推送对象
└── 多渠道消息分发
关键编排逻辑:
回到文章开头的问题:未来是否还需要传统意义上的"IT系统"?
我的答案是:传统的菜单式系统会逐步消失,但业务能力的数字化会以对象的形式永续存在。
软件的本质是什么?是对现实世界的建模和自动化。早期我们用数据库建模数据,用代码建模逻辑,用UI建模交互。但这些都只是手段,核心目标是将人的知识、经验、判断力数字化,让机器能够辅助甚至替代人完成重复性、规则性的工作。
AI大模型的出现,让我们第一次有可能实现完整的业务对象建模——不仅仅是数据,还有行为、规则、算法,甚至隐性的经验和判断。这些对象组成的技能库,就是企业数字化的核心资产。
未来的软件形态,很可能是:
这个未来,可能比我们想象的来得更快。企业需要做的,不是等待,而是从今天开始,用对象化的思维重新审视业务,用AI的能力重新设计系统。
那些率先拥抱变革、构建起高质量对象库的企业,将在未来的竞争中占据巨大优势。因为他们拥有的不再是一套套僵化的软件系统,而是一个能够持续进化、快速适应的企业智能大脑。
软件的终局,是智能。而通往智能的道路,是完整的业务对象建模。 让我们拭目以待,也让我们积极行动,共同创造这个激动人心的未来。
下面是AI辅助生成的PPT课件内容供参考:











