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，而不僅僅是讀過摘要：
他們會說「錯誤很有趣」 — 而不是「錯誤是問題」。一個吸收了 CSE 的人，會將失敗報告視為研究機會，而不是一個需要關閉的工單。
他們會先問「這是正確的問題嗎？」然後才問「解決方案是什麼？」 — 並且他們願意投入真實的時間在這個問題上，即使這會延遲可見的進展。他們見過核電廠案例，知道答案的價值。
他們會抵制未經認知分析就鎖定需求 — 這不是為了阻礙，而是因為他們理解，在你了解工作的認知結構之前就鎖定需求，是一種特定的、可命名的、可預測的建構錯誤系統的方式。
他們以聯合系統的方式思考 — 在分析失敗或設計解決方案時，他們會本能地問「這在完整的認知系統中處於什麼位置？」而不是「這個元件應該做什麼？」
他們知道默會知識的代價 — 他們不期望專家能夠告訴他們需要知道的一切。他們已經內化了專業知識在很大程度上無法透過內省來獲取，並相應地規劃他們的獲取方法。
他們將設計的迭代特性視為訊號，而非雜訊 — 當問題陳述在專案中途改變時，他們將其解讀為流程揭示了某些真實的東西，而不是需要管理的規劃失敗。
他們能說出五種失敗模式 — 自動化驚奇、錯誤問題陳述、資訊孤島、過度規範、專家瓶頸——並能將其診斷性地應用於新情況，而不僅僅當作核對清單。
他們不會說的話：「我們只需要更好的需求。」「如果我們把流程文件化，系統就會遵循它。」「使用者只需要訓練。」「我們可以獨立於操作者使用方式來評估 AI 工具。」
根據具體情況按需載入參考檔案。此技能透過此檔案啟動；更深層的分析需要參考檔案。