Cynefin框架

Cynefin框架是一种识别复杂性的方式。限定在知识管理和知识传递的场景里，归类为有因果关系定义的五个“领域”。分别为：清晰（Clear）、庞杂（Complicated）、复杂（Complex）、混乱（Chaotic）、困惑（Confused / Aporetic），混乱和困惑都是我们平时需要极力避免的，可以不用深入探索。

不可言说知识的应用会产生清晰（Clear）和庞杂（Complicated）认知模式，而不可言说知识的学习会产生复杂（Complex）认知模式。

认知行为模式	表现	举例	对应的知识活动
清晰模式	感知（sense）-归类（categorize）-响应（respond）	到银行办理业务	传递和消费显式知识和已经充分掌握了的不可言说知识。
庞杂模式	感知（sense）-分析（Analysis）-响应 (respond)	医院诊疗常见病症	和清晰模式的不同在于分析行为依赖于不可言说知识
复杂模式	探测（probe）-感知（sense）-响应 (respond)	创业或产品创新	不可言说知识传递和学习时主要依据的模式
混乱模式	行动（action）-感知(sense)-响应 (respond)	-	一个反模式，不是基于知识反应而是应激反应，需要避免
困惑模式	无法理解要解决的问题，不能进行任何有效处理	-

• 清晰（Clear） 在清晰模式下，问题和解决方案之间的因果关系是明确且稳定的。我们遵循的是已知的“最佳实践”（Best Practice）。

  认知行为表现为：感知 (Sense) - 归类 (Categorize) - 响应 (Respond)。

  • 感知（Sense）：产品经理提出需求：“用户需要能够通过用户名和密码登录我们的网站”，这是一个非常普遍和明确的需求。
  • 归类（Categorize）：开发人员立刻讲这个需求归类为”标准用户登录模块”。这个类别有成熟的、行业公认的最佳实践方案，例如
    • 密码必须进行哈希加盐存储（不能存明文）。
    • 使用 HTTPS 防止传输过程中被窃听。
    • 提供“忘记密码”功能。
    • 对登录尝试次数进行限制，防止暴力破解。
  • 响应（Respond）：开发人员根据这些既定规则和流程进行响应。他们可能会选择一个广泛使用的、安全的认证库（如 Passport.js for Node.js 或 Spring Security for Java），然后按照库的文档和安全核对清单（Checklist）来编写代码。整个过程就像是遵循一本操作手册，高效且出错率低。

  在这个模式下，知识的消费主要是显式知识（安全协议、库的文档）和已经内化的不可言说知识（熟练的编码技巧）。

• 庞杂（Complicated） 在庞杂模式下，问题和解决方案之间存在明确的因果关系，但可能不是所有人都看得到，需要专家进行分析。这里可能存在多个正确的解决方案，我们需要寻找“良好实践”（Good Practice）。

  处在庞杂模式时，认知行为表现为：感知（Sense）- 分析（Analysis）-响应（Respond）。具体来说，要首先感知是什么问题，然后通过分析寻找可能的解决方案，并使用这个解决方案进行响应。

  • 感知（Sense）: 运维团队通过监控系统感知到服务器响应时间飙升，用户反馈网站卡顿。问题是明确的：“应用性能下降”。
  • 分析（Analysis）：性能问题的原因可能是数据库查询慢，代码算法效率低等。这时需要有经验的专家介入分析。这个过程依赖专家的隐性知识—他们的经验和深入的技术理解。不同的专家可能会提出不同的优化方案：比如：
    • 方案 A：优化几条核心的 SQL 查询，并为相关数据表添加索引。
    • 方案 B：引入 Redis 缓存，将热门商品信息缓存起来，减少数据库读取。
    • 方案 C：优化算法
  • 响应（Respond）：专家团队在修改权衡了修改成本、风险和预期效果后，选择一个或多个方案进行响应，比如决定先实施成本最低的数据库优化。

  庞杂模式和清晰模式的最大区别在于解决方案的寻找，也就是分析这个行为。这个行为依赖的是个人的专业和能力，属于典型的不可言说知识。从而导致导致认知效率远低于清晰模式。

  清晰模式与庞杂模式也被称作有序模式，是知识在消费和应用中产生的认知行为模式。不论是清晰模式中的归类还是庞杂模式中的分析，知识都是被掌握和学习了的，并不存在知识的学习、获取和传递。一旦需要学习新的知识，则进入无序模式中。

• 复杂（Complex） 在复杂模式下，因果关系只能在事后才能被发现，我们无法预先分析出正确的答案。解决方案是从不断的试错和学习中“涌现”出来的，没有现成的实践方案。

  处在复杂模式时，认知行为表现为：探知（Probe）-感知（Sense）-响应（Respond）。只有通过探测收集必要的信息，再通过反思感知，最后借助必要响应，调整之前的方案。

  • 探知（Probe）：一个社交媒体想要增加一个”动态内容推荐”功能，目标是最大化用户的日活和使用时长。但是没人知道什么样的推荐算法对这个平台的用户最有效，也不可能先花大量时间”分析”和”设计”一个完美的系统。那么可以先开发一个非常简单的 MVP，给 1% 的客户优先使用。
  • 感知（Sense）：发布后，团队开始感知用户的反应。他们密切关注数据：这 1% 用户的停留时长是否增加了？他们是否会对推荐内容感兴趣？
  • 响应（Respond）：基于感知到的信息，团队进行响应和调整。他们发现简单的点赞推荐效果不佳；也许结合用户的地理位置和当地热门话题更好。于是他们修改算法，发布新版本，再次进行小范围测试。整个循环会不断重复下去。

  这个过程就是敏捷开发（Agile）和精益创业（Learn Startup）的核心思想。团队通过快速迭代和反馈循环，逐步靠近正确的解决方案。这本身就是一个学习和发现的过程，认知负载是最高的。

  整个过程和使用 AI 时的 Question (Human) - Answer (LLM) - Check (Human) 完全一致，可以说 LLM 天然适合的是学习工具，而非生产力工具

• **理想的认知行为模式：

  • 基于明确用户故事的开发，会进入有序模式 当工程师拿到一个验收条件清晰的用户故事，并对现有架构和测试策略有充分了解时，他便进入了高效的有序工作流：通过感知（阅读和理解验收条件），到分析（依据标准测试工序，将需求分解为具体的开发任务），最后到响应（按照分解结果编写代码与测试）。
  • 在缺乏知识储备下进行开发，会进入复杂模式 如果工程师对项目架构或测试策略缺乏理解，其工作很容易退化到低效的复杂模式。他只能通过“探测”（随意编写一个功能或测试），然后“感知”（不确定这种方式是否有效或正确），再“响应”（反复修改和调整），整个过程充满了不确定性。
  • 采用TDD（测试驱动开发）编写生产代码，会进入清晰模式 TDD 通过其“红—绿—重构”的固定循环，强制开发者在编写每一行生产代码前，都有一个明确、失败的测试作为指引。这个过程将复杂的编码任务分解为一系列机械、可重复的简单步骤，使开发者始终处于认知负荷极低的清晰模式下。
  • 审查AI生成的代码，要求工程师处在清晰模式 即使代码由 AI 生成，工程师在创建合并请求（Pull Request）时也必须强制自己进入清晰模式。他必须能够清晰地理解、解释并验证代码的逻辑、边界和潜在影响，并为其配备完善的测试，对最终代码质量负全责。
  • 依赖自动化测试检查软件质量，是清晰模式 当质量检查主要依赖自动化测试时，整个过程就变得非常清晰。对质量的判断被简化为对测试报告的解读：感知（查看失败的测试用例），归类（定位到对应的功能模块），响应（判定质量不合格并创建缺陷报告）。这消除了主观性和不确定性。
  • 进行手动或探索性测试，是庞杂模式 在少数情况下，如验证用户体验或进行探索性测试时，需要引入手动测试。由于这类测试依赖测试人员的专业经验、直觉判断，且过程难以精确重复，因此它属于需要专家知识的庞杂模式。
  • 通过失败的自动化测试定位问题，是诊断中的清晰模式 在问题诊断中，最理想的情况就是一个失败的自动化测试直接暴露了问题代码。测试用例本身就是对问题的精确描述，其失败信息直接指明了问题的根源，这是一个清晰、直接的因果关系。
  • 为线上Bug编写复现测试，是诊断中的庞杂模式 当需要诊断一个线上出现的Bug时，最佳实践是先构造一个新的自动化测试来稳定地复现它。这个“如何构造测试”的过程，需要工程师进行分析、推理和选择，属于需要专家能力的庞杂模式。一旦测试完成，问题本身就转化为了清晰模式。
  • 直接进行Debug调试，是诊断中的复杂模式 当问题无法通过前两种方式定位，工程师不得不进行Debug时，这标志着他已进入复杂模式。此时，他缺乏明确的假设，只能通过设置断点、观察变量、分析调用栈等探索性行为来寻找线索，这个过程耗时且充满不确定性，应尽量避免。
  • 建立团队知识门户和完善领域模型，是从无序到有序的转化机制 这些活动本身不属于某个单一模式，而是推动团队认知模式持续优化的关键手段。无论是通过团队知识门户（沉淀业务上下文、架构知识、代码等），还是通过领域驱动设计（DDD）不断完善和统一领域模型，其核心目标都是将个人在“复杂模式”下探索出的知识，转化为团队可在“庞杂模式”下复用的经验，并最终固化为“清晰模式”下的标准流程。