Appearance
老旧项目二次开发流程总结（二）
今天和朋友聊到知识库工具，发现 Trilium 也做了 MCP 适配。我尝试用它做跨领域知识问答，效果仍取决于最初对知识关系埋点和树形结构的维护。如果知识结构完全是点状的，AI 很难把相关知识串起来。
这说明两点： 第一，AI 并不能替代人在知识整理上的投入，想“偷懒”行不通； 第二，知识的结构化积累在 AI 时代依然有价值，而且价值很大。
但这也并不意味着人的整理就不可替代。知识整理本身是有系统方法和经验的，再零散的内容，只要真想整理，也能快速找到切实有效的大分类方式，再逐步细分。至少在 AI 陌生的领域，人制定和总结方法的能力仍然远超 AI——这才是经验的复利。
AI 时代，执行层方法的重要性在下降，但决策层经验仍占主导。无论是在方案定制还是持续优化中，人都起主导作用。而这又牵涉到对工作、生活中所有事件 的复盘与抽象；优化方法的方法，就是“元方法”能力。这才是 AI 时代真正值得反复锤炼的竞争力。
回到正题。上一篇复盘了整个二次开发工作流，本篇要针对每一步找到关键信息，最终输出一条可反复反馈、持续改进的优化后工作流。
一个前提：识别关键产出，避免信息过载
每一步的产出都要先做关键识别——信息不是越多越好。要找到真正的关键点，提炼关键信息，防止注意力被次要细节分散。
第一步：现状还原
核心信息
业务入口信息 业务的发起点，也是多个团队的共识点，需要重点审查。
设计类图 代码静态结构的核心描述，即代码映射后的类图。
衍生信息
设计序列图 针对关键业务入口，描述从输入到输出、以类的方法串联起来的完整流程。
业务术语 → 入口 / 类图 / 序列图的映射 方便后续使用，尤其是面对缺少注释的代码时，能让人和 AI 快速定位到业务语义。
复杂规则描述 作为类图和序列图的补充，可用类图、状态机图或思维导图等形式，描述复杂方法或业务判断逻辑。
第二步：问题定义
核心信息
功能解决的问题与核心涉众利益 明确这个功能到底为谁解决什么问题。
按场景细分的系统用例 包括输入、响应等关键要素。
非功能需求的刚性约束 必须满足的硬性条件。
衍生信息
弹性约束 可权衡、可折中的非刚性要求。
保障涉众利益的设计原则 例如“所见即所得”“优先保证易用性”等，由具体场景和涉众利益推导而来。
第三步：分析设计
核心信息
规则调整描述 基于原有规则做了哪些调整。这是关键点，能快速定位逻辑上的增量。
基于原有设计类图和序列图拓展的新类图、序列图 在既有结构上进行增量设计。
第四步：实施实现
核心信息
整体架构风格与编码规约 统一团队实现口径。
UT 审查点 明确单元测试需要覆盖的关键点。
以上仅覆盖二次开发中“从接收需求到完成编码”这一工作流。代码质量保证等后续环节，由其他工作流负责。