- 背景：
软件是载体，并不是真正的产品，真正的产品是包含在其中的知识。软件开发的核心不是产生知识，而是知识的获取与学习。编码这个行为本身，掩盖了我们工作中最有价值的部分：获取、学习并传递知识。LLM 的最大意义就在于此，它虽然可以自动化一部分编码工作，但软件工程师这一职位并不会消失，我们可以专注于提取“功能需求、业务知识、架构知识、测试策略”等关乎“生产代码”的重要信息，并借助 LLM 高效地传递、沉淀并迭代。
- 推荐书籍：《The laws of software process: a new model for the production and management of software》
- 团队开发中的隐性知识：
- 从软件交付的整体流程看：隐性知识是软件是否满足业务价值，这个需要让业务方参与进来，更高频次地验证需求。
- 从当前迭代的角度上来看：隐性知识是如何实现某个功能的 ROI 最高，这个是如何定义问题的事情，也许不需要技术就能解决，也许需要选择一个崭新的技术才能处理（极限编程 spike）。
- 从构造软件的角度上来看：隐性知识是在当前架构和最佳实践下如何实现功能，也就是要把架构师的架构能力提取出来，并进行有效的传递。
- 软件工程中的行为认知模式
- 从宏观过程来看，软件开发过程是一个基于业务知识学习的过程，是 Complex 模式。我们可以利用 LLM 缩短反馈周期，提前验证对于业务知识的理解。
- LLM 辅助业务理解：构造 Mermaid 类图，并添加注释。
- 进入到交付流程之前，我们需要将业务知识转化为软件功能需求，这时目标解决方案的应用，是一个隐性知识应用的过程，是Complicated 模式。我们可以通过将目标方案转化为 CoT，辅助业务知识到软件功能的分解。
- LLM 辅助建模：
- 基于 TQA 模式，对用户故事提取验收条件。
- 按照领域驱动设计中的各种建模方法构造 CoT，建立概念词典。
- 根据概念词典进行建立模型→检查模型→更新模型的反馈循环。
- 架构知识也可以看做是从技术视角出发的解决方案。按照架构构造软件的过程，是隐性知识应用的过程，是 Complicated 模式。通过将架构转化为 CoT，辅助研发任务的分解。
- LLM 基于测试策略进行任务分解。前提是存量系统有统一的架构模式