软件是载体，并不是真正的产品，真正的产品是包含在其中的知识。
- 软件开发的本质：知识的创造、传递、消费
- 创造：
- 显性知识 (Explicit Knowledge)：能够被清晰表达、记录和共享的知识。如设计良好的组件文档、沉淀下来的领域知识库、清晰的架构图、自动化测试用例等。。
- 隐性知识（Tacit Knowledge）：可以被显性化，但当前尚未被记录或自动化的知识。如一个依赖手动操作但可被自动化的验证流程、一个只存在于少数人脑中但可被文档化的部署技巧。
- 不可言说知识（Implicit Knowledge）：也被称为”部落知识”/“经验知识”，是那些难以用语言或文字精确描述的个人经验、直觉和技能。比如
- 资深工程师在代码审查中对“坏味道”的直觉；
- 面对复杂问题时选择技术方案的权衡能力；
- 跨团队协作的高效沟通方式； 是新成员快速融入团队、提高工作效率和质量的关键。
- 传递：在被创造的知识中，不可言说知识是价值最高的知识，也是最难传递的知识。它无法通过阅读文档学会，只有通过高频互动的社会化活动。以新人入职时的结对编程或者代码审查为例：
- 新成员首选基于已经获取的显性知识（文档、代码）来阐述思路或编写实现。
- 随后资深成员凭借丰富的不可言说知识（经验、直觉）提供指导和纠编。
- 这个互动形成了一个快速的”构建 (Build) - 衡量 (Measure) - 学习 (Learn)“，直至新成员将隐性知识内化为自身能力。
- 整个学习过程，处于认知行为模式下的 Complex 模式
- 消费：当知识被彻底掌握后，则会上升为认知行为模式的有序（Complicated 和 Clear）知识由此从”学习对象”转变为”生产力工具”。
- 理解问题：基于内化的业务和架构知识，快速理解新的业务需求。
- 解决问题：熟练地运用已掌握的知识体系，将问题分解为不同架构组件下的具体任务
- 产出价值：高效、高质量地完成开发任务。在这个过程中，往往会催生新问题、新洞见，从而开启新一轮知识创造。
- 创造：
- AI 时代的软件工程师
- 隐性知识显性化；
- 显性知识尽可能工程化；
- 加速不可言说知识的社会化传递；
- 从知识传递的角度，重新看待全流工程师
- 理解真实的业务问题
- 不可言说知识是：如何理解业务方（或用户）表达的需求背后，用户的真实意图
- 对应的社会化活动是：用户故事讨论会、需求探索会议等
- 找出合适的解决方案
- 不可言说知识是：如何在众多技术或业务方案中，选出 ROI 最高的一套。
- 对应的社会化活动是：方案评审会、架构设计讨论会等
- 分解更小的任务列表：
- 不可言说知识是：如何将一个复杂的用户故事，拆分成一组既能独立交付、又能验证价值，并且技术依赖清晰的最小任务
- 对应的社会化活动是：任务拆分会议、迭代计划会议或 TDD 等
- 依次解决任务清单
- 不可言说知识是：在处理一系列任务时，如何根据紧急性、依赖关系等外部因素，动态调整任务的优先级和实现顺序，以确保最高效的交付流程。
- 对应的社会化活动是：每日站会和持续的非正式沟通等（比如通过微信等工具进行快速对齐）
- 理解真实的业务问题
- AI 落地的困境
- 业务知识管理：提炼、传递不可言说知识，迭代式增量交付
- 不可言说知识的提炼：基于 ReAct，借助 LLM 的推理能力，由 LLM 根据业务上下文的提问，通过人的回答，验证整体解决方案是否完整清晰。
- 不可言说知识的传递：借助凝练业务知识的模型，和文字表达的业务进行相互转化，交叉验证其中的偏差。
- 有哪些知识应该被有效提取：
- 从认知行为模式，思考如何应用 AI，加速知识传递
- Clear 模式：传递和消费显式知识和已经充分掌握了的不可言说知识
- 显式知识：多数显式知识不需要重复传递，比如部署流程、代码格式上的规范等等，这类知识往往通过统一的工程化脚本沉淀，ai 可以加速脚本实现。
- Complicated 模式：
- TDD：TDD 需要将一个复杂的这个过程将复杂的编码任务分解为一系列机械、可重复的简单步骤，以便每一个步骤都进入 Clear 模式。在这一步可以通过 reason-acting 的方式，对任务边界场景进行补充。
- 为线上 bug 编写复现测试案例
-
Complex：
- Clear 模式：传递和消费显式知识和已经充分掌握了的不可言说知识