知识工程

• 背景： 软件是载体，并不是真正的产品，真正的产品是包含在其中的知识。软件开发的核心不是产生知识，而是知识的获取与学习。编码这个行为本身，掩盖了我们工作中最有价值的部分：获取、学习并传递知识。软件开发的核心不是产生代码，而是知识的获取与学习。只有先有效获取知识，才能准确体现在软件里。

  因此我们平时工作的关注点本身并不是如何构造软件，而是强调知识作为核心产品，不断让团队成员共享知识，消化知识，从而稳定迭代知识。结对编程，TDD，极限编程等敏捷开发软件方法就是源自于这种理念的实践。

  LLM 可以自动化一些编码工作，却无法替代我们对知识的获取与传递。和 LLM 的协作的中心，变成了如何提取组织知识，让知识变成 LLM 能够理解的形式。

  LLM 下的提示词工程（Prompting Engineering）的关键并不在提示词，而在如何组织其中的知识。因而知识工程（Knowledge Engineering）是一个更合理的名字。

• 个人的变化：自己编码变成指导 LLM 编码 LLM 相当于一个编码助理，为了用好这个助理，我们知识总结、知识传递、任务分解等技能的要求变高了。虽然编码技能要求降低了，但是对于知识的消化与学习，依旧需要重复且刻意的编码实践。

• 团队的变化：大量知识能被 LLM 有效沉淀

  • 从软件交付的整体流程看：知识是软件是否满足业务价值，以领域模型和统一语言的形式，让业务参与进来，避免方向性的错误
  • 从当前迭代的角度上来看：知识是如何实现某个功能的 ROI 最高，这个是如何定义问题的事情，也许不需要技术就能解决，也许需要选择一个崭新的技术才能处理。
  • 从构造软件的角度上来看：知识是在当前架构和最佳实践下如何实现功能，也就是要把架构愿景提取出来，并让新人更快地掌握，以上手工作。

• 软件工程中的行为认知模式

  • 从宏观过程来看，软件开发过程是一个基于业务知识学习的过程，是 Complex 模式。我们可以通过 LLM 快速绘制 Mermaid 类图，并添加注释，借此快速验证对业务的理解
  • 进入到交付流程之前，我们需要将业务知识转化为软件功能需求，这时目标解决方案的应用，是一个隐性知识应用的过程，是Complicated 模式。我们可以通过将目标方案转化为 CoT，辅助业务知识到软件功能的分解。
    • LLM 辅助建模：
      • 基于 TQA 模式，对用户故事提取验收条件。
      • 按照领域驱动设计中的各种建模方法构造 CoT，建立概念词典。
      • 根据概念词典进行建立模型→检查模型→更新模型的反馈循环。
  • 架构知识也可以看做是从技术视角出发的解决方案。按照架构构造软件的过程，是隐性知识应用的过程，是 Complicated 模式。通过将架构转化为 CoT，辅助研发任务的分解。
    • LLM 基于测试四象限进行任务分解。前提是遗留系统有统一的架构模式，如果没有，则需要对遗留系统进行现代化改造。