工程方法提出以后,首先要明确一个问题:
用什么证据评价这个方法?
如果一种方法最终用于制造、设计或系统工程,很容易直接用生产指标、效率或最终收益来判断它有没有价值。
但工程设计方法研究通常会把不同评价对象分开处理。方法结构是否一致、表示是否清楚、能否按预定步骤工作、能否在目标情境中使用,以及最终是否产生预期效果,并不是同一个问题,也不依赖同一种证据。
因此,评价一个工程分析方法时,首先要明确:
当前要评价的是方法的哪一层能力?
对于以分析结构、信息组织和判定规则为主要贡献的方法,结构是否成立、能否稳定表达目标问题、核心定义在不同案例中是否保持一致,以及方法使用前后工程信息的组织方式发生了什么变化,本身就是评价对象。
本文结合已有工程设计方法研究,整理这类评价关系,并说明案例对照能够支持什么类型的结构性证据。
1. 方法结构与最终效果是不同的评价对象
Blessing 与 Chakrabarti 提出的设计研究方法体系,将设计支持的评价区分为不同层次,包括:
- 支持评价(Support Evaluation):确认方法或支持结构本身是否满足预定要求,各组成部分是否按预期工作;
- 应用评价(Application Evaluation):确认方法能否在目标情境中被理解、使用和正确应用;
- 成功评价(Success Evaluation):进一步评价方法是否产生预期的实际收益。
这三个问题需要分别评价:
方法结构是否成立、方法是否可以应用、方法最终产生了什么实际收益。
Pedersen 等人提出的 Validation Square 也区分结构有效性与性能有效性,并分别讨论理论层面和经验层面的验证。
其中包括:
- 理论结构有效性;
- 经验结构有效性;
- 理论性能有效性;
- 经验性能有效性。
结构有效性关注方法的构成、逻辑关系和内部一致性;性能有效性关注方法产生的结果是否满足预期。
因此,如果一个方法当前提出的主要主张是:
- 增加新的分析对象;
- 建立新的信息组织结构;
- 区分原本混杂的状态关系;
- 形成可以重复执行的分析步骤;
那么首先需要评价这些结构主张本身,再讨论最终绩效结果。
2. 方法评价要与方法主张对应
Gericke、Eckert 与 Stacey 在 2022 年对工程设计方法的描述与评价进行了系统整理。
他们指出,一个设计方法除了步骤,还需要明确:
- 核心思想;
- 信息表示;
- 执行过程;
- 使用目的;
- 适用范围;
- 预期作用;
- 使用条件。
不同方法元素对应不同类型的主张,因此需要选择与主张相匹配的评价方式。
数学计算方法可以对计算过程进行严格证明;工程分析方法则更常通过逻辑检查、案例应用、使用过程和结果对照逐步积累证据。
Gericke 等人也指出,工程方法通常难以通过一次验证得到“绝对有效”的结论。更实际的做法是在明确适用范围内积累证据,确认方法能否按预期工作,并明确其使用条件和限制。
所以,方法评价应先确认方法究竟提出了什么主张,再决定需要什么证据。
如果一个方法的主张是“能够把某类工程信息组织得更加明确”,那么评价重点就是:
使用这个方法以后,原有问题的表示结构发生了什么变化?
3. 表示能力本身可以被评价
工程方法不仅进行计算,也决定哪些现实对象和关系需要被表示,以及这些对象之间如何建立关系。
在信息系统和概念建模研究中,表示能力本身就是长期存在的研究对象。
Wand 与 Weber 从本体表达能力的角度讨论建模语言,关注一个表示体系能否完整、清楚地描述现实中的相关现象。后续相关研究也讨论了表示完整性、概念混淆、冗余和表达清晰性等问题。
这里评价的是:
现实中具有不同工程意义的对象和关系,是否在表示结构中被明确区分并保留下来。
例如,现场已经能够记录:
机器人已经就绪
视觉系统已有识别结果
安全许可成立
抓取动作没有开始
如果围绕“进入抓取阶段”这一明确入口继续分析,可以确定:
- 视觉结果在当前抓取入口中属于 C;
- 视觉结果已经超过有效时间;
- 当前问题属于 D;
- 形成 CAE-SDB 结果 C-D。
这里没有增加新的视觉数据。
增加的是原有状态在本次状态迁移中的功能角色和判定性质。
因此,方法使用前后的信息表示结构,可以作为这类工程分析方法的评价对象。
4. 案例能够提供什么证据
案例不能证明一个工程方法在所有情境中都成立。
Gericke 等人指出,单个应用实例只能说明某种方法在该实例中可以工作,不能据此推出它在所有情境中必然成立。
对于以结构化分析为主要贡献的方法,案例可以检查:
- 同一个分析结构能否进入不同工程对象;
- 核心定义是否需要修改;
- 相同分析步骤是否仍然成立;
- 是否能够形成预期的结构化输出;
- 方法使用前后的信息表示有什么差异。
如果多个性质不同的案例都能在不修改核心定义的情况下完成同一分析过程,这些案例可以为方法的结构一致性和适用范围提供进一步证据。
实际整理时,可以直接比较:
| 比较对象 | 需要确认的内容 |
|---|---|
| 原有现场信息 | 现场原本已经能够确认什么 |
| 方法使用后的信息 | 进一步明确了什么 |
| 核心定义 | 为适应案例是否发生变化 |
前两项用于观察方法使用前后的信息表示差异,后一项用于确认方法在不同工程对象中是否保持相同的分析定义和基本结构。
这种证据能够支持的结论是:
该结构在这些明确情境中能够保持一致,并形成预期输出。
它不能自动推出该方法适用于所有系统。
案例的价值在于逐步确认:
- 方法结构是否稳定;
- 哪些对象能够被映射;
- 哪些信息能够被明确表达;
- 哪些情况无法处理;
- 方法的实际适用范围在哪里。
5. TPCA / PCN 公开案例中的前后对照在评价什么
目前 TPCA / PCN 的三个公开案例分别面向自动化执行单元、群控协同和制造 DX 跨系统状态迁移。
三个案例的工程对象不同,但都使用同一组基本对象和处理关系:当前状态、目标状态入口、C / A / E 状态映射、S / D / B 判定、CAE-SDB 结果、控制仲裁、多路径控制、当前入口控制结果、执行结果和状态迁移判定履历。
案例中的“原有现场能够确认 / 通过案例进一步明确”对照,不用于证明 TPCA / PCN 已经获得最终性能收益。
它主要检查:
采用目标状态入口和 CAE-SDB 结构以后,原本分散、隐含或混杂的信息是否被进一步明确。
三个案例分别表现为:
| 案例 | 原有现场能够确认 | 进一步形成的结构化信息 |
|---|---|---|
| 自动化执行单元 | 机器人已经就绪,但抓取没有开始 | 明确抓取入口,并形成 C-D:视觉结果失去动态时序有效性 |
| 群控协同 | 任务存在、主体在线,但多个主体持续等待 | 形成 A-D:资源锁状态不同步,同时识别资源竞争型群体停滞 |
| 制造 DX | 自动加工完成、质量合格、设备就绪,但组装没有开始 | 形成 A-B:作业人员资格超过有效期,明确关键许可约束 |
这三个案例不能单独证明 TPCA / PCN 的全部有效性。
它们能够说明:
- 相同的目标状态入口分析结构可以用于不同工程对象;
- C / A / E 与 S / D / B 的核心定义在三个案例中保持一致;
- 原本分散的状态可以被组织为明确的状态迁移判定关系;
- 判定结果可以继续连接控制方向和状态迁移判定履历;
- 不同案例形成不同 CAE-SDB 结果时,不需要修改基本定义。
因此,这些公开案例主要展示方法的结构一致性、表示明确性和跨情境应用情况。
需要回答的问题是:
用了这套分析结构以后,原有工程问题被进一步明确到了什么程度?
6. 案例证据需要保持边界
案例运行成功以后,不能把案例能够支持的结论继续扩大。
例如,一个案例能够完成映射,只能说明该方法在这个明确案例中能够完成预定分析。它不能直接证明方法普遍有效,也不能进一步推断一定会改善所有现场指标。
Gericke 等人的方法评价研究强调,评价要回到方法声明的适用范围和具体主张。
公开案例可以支持以下结论:
- 这个工程对象可以按该方法进行分析;
- 这个分析结构能够形成预期输出;
- 方法使用前后的信息表示存在明确差异;
- 多个异质案例中核心结构保持一致。
以下结论需要另外的证据:
- 方法适用于所有工程系统;
- 方法必然产生某种最终绩效;
- 方法一定优于所有既有方法;
- 某个案例中的结果可以直接推广到其他对象。
保留这种边界,可以把已经获得的证据和仍然缺少的证据分开。
结语
工程方法没有一个统一的单一评价指标。
已有工程设计方法研究已经区分结构有效性、应用、性能和实际收益等不同评价对象;表示能力研究也把表示完整性和清晰性作为独立分析问题。
对于以结构化分析为主要贡献的方法,可以先确认:
- 方法结构是否一致;
- 分析对象是否明确;
- 相关信息能否稳定组织;
- 方法使用前后的表示结构是否发生明确变化;
- 同一结构能否在不同明确情境中保持一致。
案例提供的是有限但直接的证据。
它不能证明方法在所有场景中成立,但可以说明:
在明确的工程情境中,这套结构是否增加了可以被表达、区分和组织的工程信息。
TPCA / PCN 当前三个公开案例的作用也限定在这个范围内。
案例需要回答的问题是:
面对同一个工程问题,这套方法让我们进一步看清了什么?
这也是“应用案例与工程价值”页面采用前后信息对照的原因。
本文不讨论 TPCA / PCN 的完整方法论,也不评价最终工程绩效。本文只讨论一个问题:当方法当前提出的主要主张是结构性和表示性时,应使用什么类型的证据评价这些主张。
参考依据
本札记只保留与本文论证直接相关的四项参考,不做文献综述。
1. Blessing & Chakrabarti:设计研究方法中的分层评价
Blessing, L. T. M., Chakrabarti, A. DRM, a Design Research Methodology. Springer, 2009.
DOI: https://doi.org/10.1007/978-1-84882-587-1
本文使用这一研究的内容:
该研究把设计支持的评价区分为不同层次,包括对方法本身的支持评价、实际应用评价以及进一步的成功评价。
本文采用其中的分层思想:
方法结构是否成立、方法能否被实际使用、方法最终是否产生预期收益,是不同层次的评价问题。
这一点用于支撑第 1 节对结构性主张与最终绩效主张的区分。
2. Pedersen 等:结构有效性与性能有效性的区分
Pedersen, K., Emblemsvåg, J., Bailey, R., Allen, J. K., Mistree, F. “Validating Design Methods & Research: The Validation Square.” ASME Design Engineering Technical Conferences, 2000.
DOI: https://doi.org/10.1115/DETC2000/DTM-14579
本文使用这一研究的内容:
Validation Square 区分结构有效性与性能有效性,并进一步讨论理论层面和经验层面的验证。
本文采用这一框架说明:
方法结构是否合理,与方法最终带来了多少实际效果,是两个不同的验证问题。
这一点用于说明为什么案例中的结构一致性、信息组织方式和输出关系可以单独评价。
3. Gericke、Eckert 与 Stacey:工程设计方法应该评价什么
Gericke, K., Eckert, C., Stacey, M. “Elements of a design method – a basis for describing and evaluating design methods.” Design Science, 8, e29, 2022.
DOI: https://doi.org/10.1017/dsj.2022.23
本文使用这一研究的内容:
该研究整理了工程设计方法的组成要素,包括核心思想、表示方式、过程、适用范围、预期作用等,并强调方法评价需要与具体主张和适用范围对应。
本文采用两个观点:
- 方法评价不能只看步骤是否完成,还要看表示、输出、适用范围和整体结构;
- 多个应用实例可以逐步增加对方法的信心,但不能由有限案例推出普遍有效性。
这一点用于支撑第 4~6 节对案例证据边界的讨论。
4. Wand & Weber:表示能力本身可以成为评价对象
Wand, Y., Weber, R. “On the ontological expressiveness of information systems analysis and design grammars.” Information Systems Journal, 3(4), 217–237, 1993.
DOI: https://doi.org/10.1111/j.1365-2575.1993.tb00127.x
本文使用这一研究的内容:
该研究从信息系统表示的角度讨论建模语言能否充分、清晰地表达现实中的相关对象和关系。
本文采用其中与本札记直接相关的观点:
表示结构本身的完整性与明确性,可以作为独立评价对象。
这一观点用于支撑第3节对案例前后表示结构的比较,即原本隐含、混杂或分散的工程关系是否被进一步显式组织出来。
相关内容
应用案例与工程价值
通过自动化执行单元、群控协同和制造 DX 三个公开案例,对照说明原有现场信息与采用 TPCA / PCN 后进一步形成的工程信息结构。
为什么是 CAE-SDB?——目标状态入口前的双轴结构化分析方法
说明 C / A / E 状态迁移功能角色与 S / D / B 判定性质的双轴结构。
状态迁移如何形成可分析的工程数据?——从 Target State Entry、CAE-SDB 到 PCN Trace
说明一次真实状态迁移如何从目标状态入口开始,形成结构化判定、控制和状态迁移履历。
文档信息
题目:工程方法评价中的结构有效性与案例证据
文档类型:技术札记
版本:Public Note Version 1.0
首次发布日期:2026-09-20
最后更新:2026-09-20
作者:全野南政 / Nansei Zenno
当前 URL:https://zennns.com/zh/notes/engineering-method-structural-validity/
本文属于 TPCA / PCN 状态迁移前置控制体系的公开说明内容。