SKILL.md: 复杂设计的认知系统工程
license: Apache-2.0
metadata:
name: 认知系统工程 (CSE)
source: "The Role of Cognitive Systems Engineering in the Systems Engineering Design Process"
authors: Militello, Dominguez, Lintern, Klein
version: 1.0
activation_triggers:
- 设计代理系统或编排架构
- 分析系统为何失败或正在使用户失望
- 为AI或人类执行分解复杂任务
- 从领域专家处获取需求
- 在认知工作中遇到错误或意外行为
- 质疑是否正在解决正确的问题
- 为专家判断、决策支持或自动化进行设计
- 评估解决方案是否解决了陈述的问题与实际问题
何时使用此技能
在以下情况下加载此技能：
- 系统正在被设计以支持人类认知 —— 决策支持、代理编排、信息系统、专业知识自动化
- 需求感觉模糊、存在争议或不断变化 —— 这表明认知需求是不可见的，而不是相关方感到困惑
- 出现错误或失败 —— 将它们视为关于设计假设的诊断，而不是需要修补的缺陷
- 陈述的问题感觉不对劲 —— 当解决方案空间似乎不包含实际答案时
- 需要捕获、复制或支持专业知识 —— 且专家“无法很好地解释他们是如何做到的”
- 分布式团队或系统必须协调复杂的认知工作 —— 多个代理、人类、工具或组织共享认知负荷
- 分析工作的价值受到质疑 —— 当认知贡献在工程交付成果面前不可见时
核心心理模型
1. 认知需求是不可见的
设计师假设工作者需要的和工作者实际需要的有系统性的差异——而且这个差距巨大。专家从业者依赖难以清晰表达的隐性知识、感知线索、模式识别和约束意识，这些无法单靠观察获得。任何不积极挖掘这些需求的设计过程都将为一个想象中的工作者构建系统。
含义：需求获取必须使用专门的方法（认知任务分析、关键决策方法、出声思维协议），而不是访谈或调查。这项工作的产物是实际工作的认知模型，而不是功能列表。
2. 错误是诊断，而非缺陷
认知系统中的错误不是故障——它精确地指示了系统的工作模型与工作实际结构之间的分歧。预期行为与观察行为之间的不匹配是设计师可用的信息密度最高的信号。
含义：当代理、用户或联合系统产生意外输出时，第一个问题应该是“这个错误揭示了我们的设计假设中的什么问题？”，而不是“我们如何消除这个错误？”
3. 设计是对话，而非流水线
顺序设计模型（需求 -> 规格 -> 构建 -> 测试）在教学上很方便，但在操作上是不正确的。复杂问题在你与之互动时会揭示新的信息。你开始时的问题陈述永远不会是应该结束的问题陈述。过早锁定需求会压制复杂问题所需要的发现过程。
含义：迭代不是计划的失败。在项目中期重新审视问题框架不是范围蔓延——这是过程在正确运行。建立明确的重新评估关口。
4. 问题框架是最高杠杆的干预
认知分析能产生的最有价值的东西通常是对问题的重新陈述——不是对所述问题提供更好的解决方案，而是证明所述问题是错误的。核电站案例：通过理解工作的实际认知结构，80多名员工减少到35名，零新技术投入。
含义：在优化任何解决方案之前，先投入精力验证问题陈述。以高质量解决错误问题的成本几乎超过了任何其他设计错误。
5. 联合认知系统，而非工具-用户对
认知复杂性存在于分布式系统中——共同执行认知工作的人类、技术、流程和组织结构。没有哪个单一代理或工具可以孤立设计。跨越整个系统的协调机制、信息流和共享态势感知决定了认知工作的成败。
含义：设计交接点，而不仅仅是节点。明确指定组件之间的共享心智模型需求。分析自动化如何改变联合系统内的认知负荷分布，而不仅仅是自动化是否工作。
决策框架
问题诊断
如果系统产生错误或意外行为
则加载: failure-modes-in-complex-cognitive-systems.md
→ 在提出修复之前先对故障模式进行分类
→ 问：这是自动化的意外、错误的问题、筒仓效应、过度规格还是瓶颈？
如果利益相关者不同意需求或需求不断变化
则加载: cognitive-requirements-are-invisible.md
→ 变化本身就是信息：认知需求尚未被显式化
→ 在进行更多需求收集之前，先部署结构化获取
如果提议的解决方案感觉解决的是错误的事情
则加载: problem-reframing-as-highest-leverage-intervention.md
→ 暂停解决方案工作；先投入问题框架分析
→ 寻找一个使当前解决方案类别变得不必要的重新陈述
设计过程
如果设计代理系统或编排架构
则加载: joint-cognitive-systems-distributed-cognition.md 和 cse-concept-map-for-agent-architecture.md
→ 在设计任何组件之前，先映射完整的联合系统
→ 首先设计协调机制和信息流
如果在获得充分理解之前被迫最终确定需求
则加载: design-as-dialog-not-pipeline.md
→ 区分“锁定需求”与“拥有当前最佳模型”
→ 提出明确的重新评估关口，而不是顺序锁定
如果围绕专家判断或为其进行设计
则加载: expertise-recognition-and-tacit-knowledge.md
→ 应用识别启动决策模型来理解专业知识实际如何运作
→ 在需求工作中规划专家表述差距
评估与价值
如果认知分析工作的价值受到质疑
则加载: value-case-and-invisible-contributions.md
→ 悖论：优秀的CSE工作使其自身变得不可见（更少的失败、更顺畅的运行）
→ 使用先行指标，而不仅仅是事件计数
如果提议的解决方案涉及增加技术或人员
则加载: problem-reframing-as-highest-leverage-intervention.md
→ 检查：是否已使用准确的工作认知模型来验证该解决方案？
→ 核电站基准：问题重构能否消除对提议资源的需求？
参考文件
| 文件 | 加载时机 |
|---|---|
references/cognitive-requirements-are-invisible.md | 需求感觉模糊或有争议；为专家用户设计；开始任何需求获取过程；用户研究方法受到质疑时 |
references/design-as-dialog-not-pipeline.md | 有压力要求尽早最终确定需求；迭代过程因效率低下受到挑战；项目处于中期且需要重新审视问题陈述时 |
references/problem-reframing-as-highest-leverage-intervention.md | 解决方案空间似乎不包含正确答案；提议的解决方案感觉昂贵或不一致；需要证明暂停执行以重新框架的合理性时 |
references/joint-cognitive-systems-distributed-cognition.md | 设计多代理或人机系统；分析协调失败；评估自动化如何改变认知负荷分布时 |
references/expertise-recognition-and-tacit-knowledge.md | 捕获专家知识；设计决策支持；构建系统以复制或辅助专家判断；专家无法表达他们如何工作时 |
references/failure-modes-in-complex-cognitive-systems.md | 诊断系统错误或意外行为；对提议的设计进行预先排查；在响应之前对观察到的故障进行分类时 |
references/cse-concept-map-for-agent-architecture.md | 映射代理系统的能力；在组件间组织认知功能；解决跨框架的术语混乱时 |
references/value-case-and-invisible-contributions.md | 证明认知分析投资合理；CSE工作的价值受到质疑；衡量主要预防失败的系统成果时 |
反模式
这些是CSE特别警告的失败模式。及早识别它们。
1. 为想象中的工作者设计 基于设计师认为专家如何工作（而非专家实际如何工作）来构建系统。想象中的工作者是理性的、拥有完整信息、遵循程序、并像教科书说的那样做出决策。实际工作者完全不是这样。
2. 将错误视为缺陷而非诊断 修补错误而不问它们揭示了什么。一个被修复但不被理解的错误，是错失了纠正底层设计假设的机会——并且保证问题会以不同形式再次出现。
3. 在认知工作完成之前锁定需求 顺序流程模型造成压力要求尽早锁定需求。在认知复杂领域，这保证高效地构建了错误的系统。早锁定需求不是纪律；是过早封闭。
4. 筒仓效应：没有联合系统视图就优化组件 构建一个优秀的工具，却破坏了其周围人类或代理的工作流程。局部优化降低了系统整体性能。经典版本：自动化使人类摆脱了一项任务，但当自动化失败时，却让他们失去了态势感知。
5. 失败分析中的后见之明偏差 事故发生后，仅针对该特定失败进行设计。事后重构的诱人清晰度使失败看起来比实际更可预测——并将设计精力集中于上一次失败，而非下一次失败。
6. 消除适应能力的过度规格 设计系统过于死板，以至于当现实偏离模型时，实践者无法即兴发挥。真正的复杂工作需要适应。过度规格使系统在灵活性最重要的情境中变得脆弱。
7. 设计造成的专家瓶颈 构建一个系统，其中单个专家（人类或AI）是所有关键决策的必要网关。即使该专家非常优秀，这也会产生灾难性的脆弱性。CSE呼吁分配专业知识，而不是集中它。
行家识别标志
如何判断某人是否真正内化了CSE vs 仅仅阅读了摘要：
他们说“错误很有趣” —— 而不是“错误是问题”。已经吸收CSE的人将失败报告视为研究机会，而不是一个待关闭的工单。
他们问“这是正确的问题吗？” 在问“解决方案是什么？”之前——并且他们愿意在即使会延迟可见进展的情况下花真正的时间在这个问题上。他们见过核电站案例，知道答案可能值多少钱。
他们在没有认知分析的情况下抵制需求锁定 —— 这不是出于阻挠，而是因为他们明白，在你理解工作的认知结构之前锁定需求，是一种特定的、有名字的、可预测的构建错误事物的方式。
他们以联合系统思考 —— 分析失败或设计解决方案时，他们本能地问“这在完整的认知系统中处于什么位置？”，而不是“这个组件应该做什么？”。
他们知道隐性知识的成本 —— 他们不期望专家能够告诉他们需要知道什么。他们已内化专业知识在很大程度上是内省无法访问的，并据此规划他们的获取方法。
他们将设计的迭代特性视为信号而非噪音 —— 当问题陈述在项目中期发生变化时，他们将其解读为过程揭示了真实信息，而不是需要管理的计划失败。
他们能说出五种失败模式 —— 自动化意外、错误的问题陈述、筒仓效应、过度规格、专家瓶颈——并能将其诊断性地应用于新情况，而不仅仅是作为核对清单。
他们不会说的是：“我们只需要更好的需求。”“如果我们记录流程，系统就会遵循它。”“用户只需要培训。”“我们可以独立于操作员使用方式评估AI工具。”
在特定情况出现时按需加载参考文件。此技能由此文件激活；更深入的分析需要参考文件。