简介这份PDF文献聚焦信息时代作战体系的概念模型与描述方法面向军事理论研究者、指挥决策人员及C4ISR技术方向的科技工作者帮助读者理解信息化战场中作战体系由传统层级模式向网络化、自同步模式转变的内在逻辑。资源包内仅含1个PDF文件约391KB篇幅紧凑适合作为体系建模与作战仿真的理论参考。文献将作战体系拆解为使命任务、作战单元与信息网络三类基本元素并系统梳理任务序列、任务分配、单元协作、指挥控制、任务信息流与信息网络拓扑六种关键关系给出可操作的描述途径为作战体系的自同步构建与重组提供建模基础。目前已有73人学习适合需要快速把握信息化作战体系框架、开展相关课题研究或论文写作的读者研读。1. 从一份 PDF 标题说起作战体系概念模型到底在建模什么“信息时代作战体系的概念模型及其描述.pdf”这个标题第一次看到的人多半会愣一下它既不像纯军事理论也不像纯技术文档更像一份把“体系”这件事讲清楚的建模说明。信息时代最直接的变化不是武器本身而是节点变多、链路变密、决策周期被压缩于是“作战体系”不再是若干装备的简单相加而是一个由感知、判断、决策、行动、保障等要素耦合而成的整体。概念模型要做的就是把这个整体用一套可讨论、可描述、可验证的语言固定下来让后续的仿真、评估、需求分析有共同底座。它适合做体系论证、装备体系规划、指挥信息系统设计的人也适合想把复杂系统建模方法落到具体领域的研究者。标题里的“描述”二字尤其关键——模型建完不能只停在框图必须能被形式化表达、被工具读取、被不同角色复现。2. 概念模型的理论底座要素、关系与视图怎么定2.1 为什么先定“要素—关系—视图”三层结构做体系概念模型最容易翻车的地方是一上来就画大图。图很漂亮但每个人理解的箭头含义都不一样最后变成玄学。稳妥的做法是先立三层结构要素层回答“体系里有哪些东西”关系层回答“它们之间靠什么连接、按什么规则交互”视图层回答“从哪个角度把前两层呈现给谁看”。要素通常包括作战单元、感知节点、指挥机构、保障资源、信息基础设施等关系包括指挥控制、信息交互、协同支援、时序约束等视图则按作战视角、系统视角、技术视角切分。这样做的价值在于任何一张图都能追溯到它属于哪个视图、用了哪些要素和关系避免“一张图打天下”。2.2 从 DoDAF 到领域裁剪选型不是照搬体系建模框架里DoDAF、MODAF、UPDM 是常被提到的参考。但直接照搬会有一个现实问题这些框架面向的是大型采办体系视图数量多、元模型重落到一个具体作战体系的概念模型上很容易把精力耗在填视图而不是想清楚问题。我一般的做法是“框架裁剪”保留全景视图、作战视图、系统视图三类核心把标准视图和技术视图按需精简。裁剪的依据是建模目的——如果目的是需求论证就强化作战活动与能力关系如果目的是系统集成就强化接口与信息流。裁剪不是偷懒而是让模型服务于决策而不是让决策迁就模型。2.3 元模型让“描述”有语法可依概念模型要能被描述底层得有一套元模型也就是“描述模型的语言”。常见做法是定义元类、属性、关联和约束。比如把“作战节点”定义为一个元类它有名称、类型、所属域、能力属性把“信息交互”定义为关联它有方向、内容类型、时延要求、置信度。元模型一旦定下来后续所有实例都必须按这套语法填写模型才具备一致性和可校验性。下面这段 Python 用 dataclass 搭了一个最小元模型骨架目的是让读者看到“概念模型不是画出来的是先有语法再填实例”。from dataclasses import dataclass, field from typing import List, Optional dataclass class OperationalNode: 作战节点体系中的基本功能单元 node_id: str name: str node_type: str # 如 sensor / command / shooter / support domain: str # 所属作战域 capabilities: List[str] field(default_factorylist) dataclass class InformationExchange: 信息交互节点之间的关系载体 exchange_id: str source_id: str target_id: str content_type: str # 如 track / order / status latency_ms: Optional[int] None # 时延要求单位毫秒 confidence: float 1.0 # 信息置信度 0~1 dataclass class OperationalView: 作战视图要素与关系的集合 view_name: str nodes: List[OperationalNode] field(default_factorylist) exchanges: List[InformationExchange] field(default_factorylist) def validate(self): 最小校验交互的源和目标必须存在于节点集合中 ids {n.node_id for n in self.nodes} for ex in self.exchanges: if ex.source_id not in ids or ex.target_id not in ids: raise ValueError(f交互 {ex.exchange_id} 引用了不存在的节点) return True这段代码的逻辑很直白先定义节点和信息交互两个核心元类再用视图把它们聚合起来最后给一个校验方法。参数上node_type决定节点在体系中的角色latency_ms和confidence是后续做体系效能评估时最常用的两个量化维度。实际项目中元模型会比这复杂得多但骨架就是这个思路——先有语法再有实例最后才有图。3. 把概念模型描述出来从结构化表格到可执行校验3.1 描述方式的选择表格、矩阵还是形式化语言概念模型建好后描述方式直接决定它能不能被复用。常见有三条路结构化表格、关系矩阵、形式化语言。表格适合给管理层和论证人员看直观但表达力有限矩阵适合做关系分析比如用 N² 矩阵表示节点间信息交互密度便于发现关键节点形式化语言适合交给工具做校验和仿真。我的经验是三者并用表格做基线矩阵做分析形式化做校验。下面这张表是一个作战视图的节点描述示例字段就是元模型里定义的属性。节点编号节点名称节点类型所属域关键能力备注N01前沿感知节点sensor陆域目标探测、跟踪高机动N02区域指挥节点command陆域态势融合、决策核心节点N03火力打击节点shooter陆域精确打击受 N02 指挥N04综合保障节点support后方补给、维修支撑 N01-N03表格的价值在于它强迫你把每个字段填满填不满的地方往往就是概念没想清楚的地方。比如“关键能力”一栏如果写不出来说明这个节点在体系中的定位还模糊。3.2 用矩阵找关键节点信息交互密度分析关系矩阵是概念模型描述里被低估的工具。把节点作为行列矩阵元素表示两个节点之间的信息交互强度可以快速看出谁是这个体系的“枢纽”。下面这段 Python 用邻接矩阵计算每个节点的交互密度并排序输出。import numpy as np # 节点顺序N01 感知, N02 指挥, N03 打击, N04 保障 # 矩阵元素表示信息交互强度0~1对角线为 0 adj np.array([ [0.0, 0.9, 0.2, 0.1], [0.8, 0.0, 0.7, 0.4], [0.1, 0.6, 0.0, 0.2], [0.2, 0.5, 0.3, 0.0] ]) node_names [N01 感知, N02 指挥, N03 打击, N04 保障] # 交互密度 该节点出度与入度之和 density adj.sum(axis1) adj.sum(axis0) ranking sorted(zip(node_names, density), keylambda x: x[1], reverseTrue) for name, d in ranking: print(f{name}: 交互密度 {d:.2f})运行后 N02 指挥节点的密度最高符合直觉但矩阵能给出量化依据。参数上矩阵元素怎么定是关键可以用专家打分也可以用历史数据统计。我一般会要求打分者给出依据否则矩阵就成了拍脑袋。这个分析结果可以直接支撑“关键节点识别”和“体系脆弱性分析”——密度高的节点一旦失效体系连通性下降最快。3.3 可执行校验让模型自己暴露矛盾概念模型最常见的质量问题是“图上有、逻辑上无”。比如某个节点声称能提供某类信息但没有任何交互关系支撑或者两个节点之间的交互方向互相矛盾。解决办法是把校验规则写成可执行代码每次模型更新后跑一遍。下面这段代码在之前元模型基础上增加了规则校验。def check_orphan_nodes(view: OperationalView): 检查孤立节点没有任何信息交互的节点 connected set() for ex in view.exchanges: connected.add(ex.source_id) connected.add(ex.target_id) orphans [n.node_id for n in view.nodes if n.node_id not in connected] return orphans def check_latency_consistency(view: OperationalView, threshold_ms500): 检查时延超限的交互 warnings [] for ex in view.exchanges: if ex.latency_ms and ex.latency_ms threshold_ms: warnings.append(f{ex.exchange_id} 时延 {ex.latency_ms}ms 超过阈值) return warnings # 构造一个含问题的视图做演示 view OperationalView( view_name示例作战视图, nodes[ OperationalNode(N01, 感知节点, sensor, 陆域), OperationalNode(N02, 指挥节点, command, 陆域), OperationalNode(N03, 打击节点, shooter, 陆域), ], exchanges[ InformationExchange(E01, N01, N02, track, latency_ms200), InformationExchange(E02, N02, N03, order, latency_ms800), ] ) print(孤立节点:, check_orphan_nodes(view)) print(时延告警:, check_latency_consistency(view))这段代码输出会显示 N03 不是孤立节点但 E02 时延 800ms 超过阈值。参数threshold_ms需要根据具体作战场景设定比如指挥指令的时延要求通常比态势信息更严。把校验规则代码化之后模型就不再是静态文档而是可以持续迭代的工程对象。4. 避坑与排查概念模型落地时最容易翻车的五件事4.1 现象模型图画了几十张评审时没人能说清整体逻辑原因视图之间没有统一的元模型约束每张图各画各的要素命名和粒度都不一致。解决先冻结元模型再画图。所有视图必须从同一套要素和关系里取禁止临时造词。评审时先看元模型一致性报告再看具体视图。4.2 现象模型建得很完整但一做仿真就报错原因概念模型只描述了“有什么”没有描述“怎么动”。仿真需要行为逻辑、触发条件、时序约束这些在纯概念模型里往往是缺失的。解决在概念模型阶段就预留行为描述接口比如给每个节点定义可执行的活动列表给每条交互定义触发事件。哪怕先填占位符也比后期硬补强。4.3 现象不同部门对同一个节点的能力描述互相矛盾原因概念模型没有版本管理和变更记录各部门基于不同版本各自修改。解决模型入库用版本号管理每次变更记录变更人、变更内容和影响范围。校验规则里增加“能力冲突检测”比如同一节点被标记为 sensor 又标记为 shooter 时给出告警。4.4 现象交互矩阵打分结果每次都不一样原因打分标准没有量化锚点专家凭感觉给分。解决给每个强度等级定义明确锚点比如 0.9 表示“实时连续交互”0.5 表示“周期性交互”0.1 表示“偶发交互”。打分前先对齐锚点打分后做一致性检验偏差过大的重新打分。4.5 现象模型交付后没人用变成归档文件原因模型描述方式不友好业务人员看不懂形式化语言技术人员不愿意看表格。解决同一模型输出多种视图——给管理层看全景图和能力清单给技术人员看形式化描述和校验报告给仿真人员看可执行接口。描述方式服务于使用场景不是越形式化越好。5. 进阶技巧用场景推演验证概念模型的完备性概念模型建得对不对最终要靠场景推演来验证。我常用的方法是“三场景压力测试”选一个典型作战场景、一个边界场景、一个降级场景把模型放进去跑一遍看它能不能支撑推演。典型场景验证基本逻辑边界场景验证能力上限降级场景验证体系韧性。下面这张表是我做场景推演时用的检查清单每个场景至少覆盖这五类问题。检查项典型场景边界场景降级场景节点是否齐全所有节点参与关键节点满负荷部分节点失效交互是否可达信息链路通畅时延接近阈值链路中断后的替代路径决策是否闭环感知到行动完整决策周期压缩指挥节点降级后的授权保障是否跟上保障资源充足保障资源紧张保障节点失效模型是否暴露缺口无告警时延告警孤立节点告警推演时我会把模型校验代码挂到推演流程里每推进一步就跑一次校验把告警当成推演输出的一部分。这样做的好处是模型的问题会在推演中自然暴露而不是等到评审时被人挑出来。参数上边界场景的阈值设定很关键比如时延阈值设得太松边界场景就测不出问题设得太紧又全是误报。我的习惯是先按经验设一版跑三轮推演后根据告警分布调整让告警集中在真正需要关注的地方。还有一个容易被忽略的技巧把概念模型和实际数据做一次“对账”。比如模型里声称某节点具备某能力就去查实际系统中这个能力有没有对应的数据支撑。对不上的地方要么是模型写错了要么是实际系统缺数据两种情况都值得记录。我吃过一次亏模型评审全票通过结果做能力评估时发现三个关键节点的交互数据根本采不到最后只能回头改模型。从那以后我养成了一个习惯概念模型交付前先拿最小数据集跑一遍对账对不上的地方标红宁可交付前多花两天也不要在评估阶段返工。希望帮到你。本文还有配套的精品资源点击获取 信息时代作战体系概念模型：从元模型到可执行校验的建模方法
简介这份PDF文献聚焦信息时代作战体系的概念模型与描述方法面向军事理论研究者、指挥决策人员及C4ISR技术方向的科技工作者帮助读者理解信息化战场中作战体系由传统层级模式向网络化、自同步模式转变的内在逻辑。资源包内仅含1个PDF文件约391KB篇幅紧凑适合作为体系建模与作战仿真的理论参考。文献将作战体系拆解为使命任务、作战单元与信息网络三类基本元素并系统梳理任务序列、任务分配、单元协作、指挥控制、任务信息流与信息网络拓扑六种关键关系给出可操作的描述途径为作战体系的自同步构建与重组提供建模基础。目前已有73人学习适合需要快速把握信息化作战体系框架、开展相关课题研究或论文写作的读者研读。1. 从一份 PDF 标题说起作战体系概念模型到底在建模什么“信息时代作战体系的概念模型及其描述.pdf”这个标题第一次看到的人多半会愣一下它既不像纯军事理论也不像纯技术文档更像一份把“体系”这件事讲清楚的建模说明。信息时代最直接的变化不是武器本身而是节点变多、链路变密、决策周期被压缩于是“作战体系”不再是若干装备的简单相加而是一个由感知、判断、决策、行动、保障等要素耦合而成的整体。概念模型要做的就是把这个整体用一套可讨论、可描述、可验证的语言固定下来让后续的仿真、评估、需求分析有共同底座。它适合做体系论证、装备体系规划、指挥信息系统设计的人也适合想把复杂系统建模方法落到具体领域的研究者。标题里的“描述”二字尤其关键——模型建完不能只停在框图必须能被形式化表达、被工具读取、被不同角色复现。2. 概念模型的理论底座要素、关系与视图怎么定2.1 为什么先定“要素—关系—视图”三层结构做体系概念模型最容易翻车的地方是一上来就画大图。图很漂亮但每个人理解的箭头含义都不一样最后变成玄学。稳妥的做法是先立三层结构要素层回答“体系里有哪些东西”关系层回答“它们之间靠什么连接、按什么规则交互”视图层回答“从哪个角度把前两层呈现给谁看”。要素通常包括作战单元、感知节点、指挥机构、保障资源、信息基础设施等关系包括指挥控制、信息交互、协同支援、时序约束等视图则按作战视角、系统视角、技术视角切分。这样做的价值在于任何一张图都能追溯到它属于哪个视图、用了哪些要素和关系避免“一张图打天下”。2.2 从 DoDAF 到领域裁剪选型不是照搬体系建模框架里DoDAF、MODAF、UPDM 是常被提到的参考。但直接照搬会有一个现实问题这些框架面向的是大型采办体系视图数量多、元模型重落到一个具体作战体系的概念模型上很容易把精力耗在填视图而不是想清楚问题。我一般的做法是“框架裁剪”保留全景视图、作战视图、系统视图三类核心把标准视图和技术视图按需精简。裁剪的依据是建模目的——如果目的是需求论证就强化作战活动与能力关系如果目的是系统集成就强化接口与信息流。裁剪不是偷懒而是让模型服务于决策而不是让决策迁就模型。2.3 元模型让“描述”有语法可依概念模型要能被描述底层得有一套元模型也就是“描述模型的语言”。常见做法是定义元类、属性、关联和约束。比如把“作战节点”定义为一个元类它有名称、类型、所属域、能力属性把“信息交互”定义为关联它有方向、内容类型、时延要求、置信度。元模型一旦定下来后续所有实例都必须按这套语法填写模型才具备一致性和可校验性。下面这段 Python 用 dataclass 搭了一个最小元模型骨架目的是让读者看到“概念模型不是画出来的是先有语法再填实例”。from dataclasses import dataclass, field from typing import List, Optional dataclass class OperationalNode: 作战节点体系中的基本功能单元 node_id: str name: str node_type: str # 如 sensor / command / shooter / support domain: str # 所属作战域 capabilities: List[str] field(default_factorylist) dataclass class InformationExchange: 信息交互节点之间的关系载体 exchange_id: str source_id: str target_id: str content_type: str # 如 track / order / status latency_ms: Optional[int] None # 时延要求单位毫秒 confidence: float 1.0 # 信息置信度 0~1 dataclass class OperationalView: 作战视图要素与关系的集合 view_name: str nodes: List[OperationalNode] field(default_factorylist) exchanges: List[InformationExchange] field(default_factorylist) def validate(self): 最小校验交互的源和目标必须存在于节点集合中 ids {n.node_id for n in self.nodes} for ex in self.exchanges: if ex.source_id not in ids or ex.target_id not in ids: raise ValueError(f交互 {ex.exchange_id} 引用了不存在的节点) return True这段代码的逻辑很直白先定义节点和信息交互两个核心元类再用视图把它们聚合起来最后给一个校验方法。参数上node_type决定节点在体系中的角色latency_ms和confidence是后续做体系效能评估时最常用的两个量化维度。实际项目中元模型会比这复杂得多但骨架就是这个思路——先有语法再有实例最后才有图。3. 把概念模型描述出来从结构化表格到可执行校验3.1 描述方式的选择表格、矩阵还是形式化语言概念模型建好后描述方式直接决定它能不能被复用。常见有三条路结构化表格、关系矩阵、形式化语言。表格适合给管理层和论证人员看直观但表达力有限矩阵适合做关系分析比如用 N² 矩阵表示节点间信息交互密度便于发现关键节点形式化语言适合交给工具做校验和仿真。我的经验是三者并用表格做基线矩阵做分析形式化做校验。下面这张表是一个作战视图的节点描述示例字段就是元模型里定义的属性。节点编号节点名称节点类型所属域关键能力备注N01前沿感知节点sensor陆域目标探测、跟踪高机动N02区域指挥节点command陆域态势融合、决策核心节点N03火力打击节点shooter陆域精确打击受 N02 指挥N04综合保障节点support后方补给、维修支撑 N01-N03表格的价值在于它强迫你把每个字段填满填不满的地方往往就是概念没想清楚的地方。比如“关键能力”一栏如果写不出来说明这个节点在体系中的定位还模糊。3.2 用矩阵找关键节点信息交互密度分析关系矩阵是概念模型描述里被低估的工具。把节点作为行列矩阵元素表示两个节点之间的信息交互强度可以快速看出谁是这个体系的“枢纽”。下面这段 Python 用邻接矩阵计算每个节点的交互密度并排序输出。import numpy as np # 节点顺序N01 感知, N02 指挥, N03 打击, N04 保障 # 矩阵元素表示信息交互强度0~1对角线为 0 adj np.array([ [0.0, 0.9, 0.2, 0.1], [0.8, 0.0, 0.7, 0.4], [0.1, 0.6, 0.0, 0.2], [0.2, 0.5, 0.3, 0.0] ]) node_names [N01 感知, N02 指挥, N03 打击, N04 保障] # 交互密度 该节点出度与入度之和 density adj.sum(axis1) adj.sum(axis0) ranking sorted(zip(node_names, density), keylambda x: x[1], reverseTrue) for name, d in ranking: print(f{name}: 交互密度 {d:.2f})运行后 N02 指挥节点的密度最高符合直觉但矩阵能给出量化依据。参数上矩阵元素怎么定是关键可以用专家打分也可以用历史数据统计。我一般会要求打分者给出依据否则矩阵就成了拍脑袋。这个分析结果可以直接支撑“关键节点识别”和“体系脆弱性分析”——密度高的节点一旦失效体系连通性下降最快。3.3 可执行校验让模型自己暴露矛盾概念模型最常见的质量问题是“图上有、逻辑上无”。比如某个节点声称能提供某类信息但没有任何交互关系支撑或者两个节点之间的交互方向互相矛盾。解决办法是把校验规则写成可执行代码每次模型更新后跑一遍。下面这段代码在之前元模型基础上增加了规则校验。def check_orphan_nodes(view: OperationalView): 检查孤立节点没有任何信息交互的节点 connected set() for ex in view.exchanges: connected.add(ex.source_id) connected.add(ex.target_id) orphans [n.node_id for n in view.nodes if n.node_id not in connected] return orphans def check_latency_consistency(view: OperationalView, threshold_ms500): 检查时延超限的交互 warnings [] for ex in view.exchanges: if ex.latency_ms and ex.latency_ms threshold_ms: warnings.append(f{ex.exchange_id} 时延 {ex.latency_ms}ms 超过阈值) return warnings # 构造一个含问题的视图做演示 view OperationalView( view_name示例作战视图, nodes[ OperationalNode(N01, 感知节点, sensor, 陆域), OperationalNode(N02, 指挥节点, command, 陆域), OperationalNode(N03, 打击节点, shooter, 陆域), ], exchanges[ InformationExchange(E01, N01, N02, track, latency_ms200), InformationExchange(E02, N02, N03, order, latency_ms800), ] ) print(孤立节点:, check_orphan_nodes(view)) print(时延告警:, check_latency_consistency(view))这段代码输出会显示 N03 不是孤立节点但 E02 时延 800ms 超过阈值。参数threshold_ms需要根据具体作战场景设定比如指挥指令的时延要求通常比态势信息更严。把校验规则代码化之后模型就不再是静态文档而是可以持续迭代的工程对象。4. 避坑与排查概念模型落地时最容易翻车的五件事4.1 现象模型图画了几十张评审时没人能说清整体逻辑原因视图之间没有统一的元模型约束每张图各画各的要素命名和粒度都不一致。解决先冻结元模型再画图。所有视图必须从同一套要素和关系里取禁止临时造词。评审时先看元模型一致性报告再看具体视图。4.2 现象模型建得很完整但一做仿真就报错原因概念模型只描述了“有什么”没有描述“怎么动”。仿真需要行为逻辑、触发条件、时序约束这些在纯概念模型里往往是缺失的。解决在概念模型阶段就预留行为描述接口比如给每个节点定义可执行的活动列表给每条交互定义触发事件。哪怕先填占位符也比后期硬补强。4.3 现象不同部门对同一个节点的能力描述互相矛盾原因概念模型没有版本管理和变更记录各部门基于不同版本各自修改。解决模型入库用版本号管理每次变更记录变更人、变更内容和影响范围。校验规则里增加“能力冲突检测”比如同一节点被标记为 sensor 又标记为 shooter 时给出告警。4.4 现象交互矩阵打分结果每次都不一样原因打分标准没有量化锚点专家凭感觉给分。解决给每个强度等级定义明确锚点比如 0.9 表示“实时连续交互”0.5 表示“周期性交互”0.1 表示“偶发交互”。打分前先对齐锚点打分后做一致性检验偏差过大的重新打分。4.5 现象模型交付后没人用变成归档文件原因模型描述方式不友好业务人员看不懂形式化语言技术人员不愿意看表格。解决同一模型输出多种视图——给管理层看全景图和能力清单给技术人员看形式化描述和校验报告给仿真人员看可执行接口。描述方式服务于使用场景不是越形式化越好。5. 进阶技巧用场景推演验证概念模型的完备性概念模型建得对不对最终要靠场景推演来验证。我常用的方法是“三场景压力测试”选一个典型作战场景、一个边界场景、一个降级场景把模型放进去跑一遍看它能不能支撑推演。典型场景验证基本逻辑边界场景验证能力上限降级场景验证体系韧性。下面这张表是我做场景推演时用的检查清单每个场景至少覆盖这五类问题。检查项典型场景边界场景降级场景节点是否齐全所有节点参与关键节点满负荷部分节点失效交互是否可达信息链路通畅时延接近阈值链路中断后的替代路径决策是否闭环感知到行动完整决策周期压缩指挥节点降级后的授权保障是否跟上保障资源充足保障资源紧张保障节点失效模型是否暴露缺口无告警时延告警孤立节点告警推演时我会把模型校验代码挂到推演流程里每推进一步就跑一次校验把告警当成推演输出的一部分。这样做的好处是模型的问题会在推演中自然暴露而不是等到评审时被人挑出来。参数上边界场景的阈值设定很关键比如时延阈值设得太松边界场景就测不出问题设得太紧又全是误报。我的习惯是先按经验设一版跑三轮推演后根据告警分布调整让告警集中在真正需要关注的地方。还有一个容易被忽略的技巧把概念模型和实际数据做一次“对账”。比如模型里声称某节点具备某能力就去查实际系统中这个能力有没有对应的数据支撑。对不上的地方要么是模型写错了要么是实际系统缺数据两种情况都值得记录。我吃过一次亏模型评审全票通过结果做能力评估时发现三个关键节点的交互数据根本采不到最后只能回头改模型。从那以后我养成了一个习惯概念模型交付前先拿最小数据集跑一遍对账对不上的地方标红宁可交付前多花两天也不要在评估阶段返工。希望帮到你。本文还有配套的精品资源点击获取