工程方法提出以后，经常会遇到一个问题：

应该用什么证据评价这个方法？

如果一种方法最终用于制造、设计或系统工程，很容易把“方法有没有价值”直接等同于“最终生产指标有没有改善”。

但工程设计方法研究并不是这样处理的。

成熟研究通常会把不同类型的评价问题分开：方法本身的结构是否一致，表示是否清楚，能否按照预定步骤工作，能否在目标情境中使用，以及最终是否产生预期效果，并不属于同一种主张，也不依赖同一种证据。

因此，在评价一个工程分析方法时，需要先明确：

当前究竟要评价方法的哪一层能力？

对于以分析结构、信息组织和判定规则为主要贡献的方法，结构本身能否成立、是否能够稳定表达目标问题、在不同案例中是否保持相同定义，以及使用前后工程信息的组织方式发生了什么变化，本身就是重要的评价对象。

本文从已有工程设计方法研究出发，整理这种评价逻辑，并说明案例对照为什么可以形成工程方法的结构性证据。

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

本文引用这一研究的原因：

该研究把设计支持的评价区分为不同层次，包括对方法本身的支持评价、实际应用评价以及进一步的成功评价。

本文借用的不是 DRM 的完整研究流程，而是其中一个基本思想：

方法结构是否成立、方法能否被实际使用、方法最终是否产生预期收益，是不同层次的评价问题。

这一点用于支撑本文第 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

本文引用这一研究的原因：

该研究系统整理了工程设计方法的组成要素，包括核心思想、表示方式、过程、适用范围、预期作用等，并强调方法评价应与其具体主张和适用范围对应。

本文主要借用两个观点：

  1. 方法不能只看“步骤有没有跑完”，还需要评价它的表示、输出、适用范围和整体结构；
  2. 多个应用实例可以逐步增加对方法的信心，但不能由有限案例推出普遍有效性。

这一点直接支撑本文第 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 状态迁移前置控制体系的公开说明内容。