ARTICLE · 1060443
量潮软件工程教程v0.1.0
当前软件工程最突出的矛盾，是 AI 日益增长的垃圾代码和人类有限的认知带宽之间的矛盾。AI 的产出速度已经超过了人的理解速度，代码量不再稀缺，能被理解的结构才稀缺。
本教程的读者，是已经掌握「氛围编程」基础的开发者：项目规模增长到无法继续迭代，技术债务开始拖住每一次改动。这时候加人或加算力都解决不了问题，问题出在代码的结构和规范上。
目标
本教程要达成两件事。
第一件是人的能力。读者从事后重构起步，逐步建立事前设计的能力，最终能够引导 AI 做出准确的设计。
第二件是 AI 的约束。规范要可执行、可检查，让 AI 在人类制定的规范内写代码，而不是各行其是。
两者是同一件事的两面：建立反脆弱的软件工程规范，使代码规模的增长不再吞噬人类的认知带宽。
方法
课程围绕代码分析工具与重构技巧展开。工具负责把既有代码的真实结构暴露出来，重构负责把结构拉回预期，规范负责约束后续产出，三者依次收紧。
教程按三个阶段展开。
生命周期
按三个阶段展开：评审（Review）、反思（Reflect）、重构（Refactor）。三个阶段合称 3R。
评审检查已有成果与承接下一段工作的上下文。常见的习惯是在一段长对话里做完整个工程，对话越长，隐含的上下文越多，越不便回看与交接；更合用的做法是不断开新对话，每完成一段工作就评审它、整理它、发现问题，再以评审干净的对话作为下一段工作的起点。
反思用依赖图等深度分析工具看清代码的真实结构，再与预期架构逐条对照。差异归为四类：AI 自行发明的结构、违反架构原则的实现、人类预想错误之处、人类盲区带来的新发现。模块设计与模块边界是差异的重灾区。
重构把差异转化为改动。差异只说明现状与预期不符，不说明该怎么改；一种做法是路径推演，从当前版本向若干可能性推演，再反过来看还存在哪些可能性，推演交给 AI，权衡留给人。
三个阶段不是一次性的流水线。反思会发现新的问题，重构会改变代码的面貌，于是又回到评审；循环收敛，规范也从假设沉淀为可执行的约束。
评审
第一阶段是评审，它同时贯穿后两个阶段。
常见的习惯是在一段长对话里做完整个工程。对话越长，隐含的上下文越多，既不便回看，也不便交接。更合用的做法是不断开新对话：在一段对话里完成一段工作，随即评审它、整理它、发现问题，再以评审干净的对话作为下一段工作的主要起点。需要评审时，再开一段新对话。
评审的对象是每一段工作的成果，既包括代码，也包括承接下一段工作的上下文。
上下文治理的检验
开新对话时，如果 AI 能迅速拿到全部上下文，说明这个仓库的上下文治理已经足够干净整洁；反之，需要靠人复述仓库里已有的信息，说明治理还有欠账。
反思
第二阶段是深度分析，任务是看清代码的现状。人对自己代码的印象，往往停留在设计之初；AI 参与之后的代码，早已偏离很远。这一阶段要把实际结构暴露出来，再与预期架构逐条对照。
依赖图分析是本阶段的方法总纲。对照分三步，差异归为四类：AI 自行发明的结构、违反架构原则的实现、人类预想错误之处、人类盲区带来的新发现。
重点
模块设计与模块边界是差异的重灾区。分层看上去正常，但某个模块该落在哪一层、边界划在哪里，往往是 AI 为了把项目做出来而自行发挥的结果。对照时要把注意力放在这些位置。
依赖图分析
依赖图把模块之间、以及模块内部类与函数之间的依赖关系准确画出来。这个工具本身非常古早，真正新的是它要回答的问题：代码的骨架是否仍然在人类的理解之内。我们把针对这个问题的依赖图分析称为「智能依赖图分析」——不只看结构，还要看结构背后的语义。
必要性
AI 生成的代码已经又多又乱，人类无法逐行理解。在「古法编程」时代，依赖图是可选项，甚至是鸡肋，因为人类对自己的代码还有主导权。现在不行了，必须用工具去跟工具斗争，用魔法打败魔法。
方法
画依赖图有两条技术路线。一条是纯规则引擎，用标准的静态分析规则推导依赖关系；另一条是用大模型扫描代码。我们正在探索把两者结合起来的分析工具和流程，目标是更经济地拿到准确的依赖图。
拿到依赖图之后，比对分三步进行。
由人类画出合理的架构图，这一步可以由 AI 辅助表达。 根据代码的实际表现画出详细的依赖图。 比较依赖图与架构图的差异，逐条归类。
比对结果归为四类：
AI 自行发明的结构，设计中并不存在； 违反人类制定的架构原则的实现； 人类的预想本身错了，需要修改预期架构； 人类的盲区，由此带来新的发现。
目标
理想状况下，依赖图建立的结构应当与人的理解完全一致。骨架对了，人类与 AI 的协作就可以下沉到每一个模块、每一个类、每一个函数的设计是否科学合理——认知带宽留给设计，不再消耗在还原代码事实上。
重构
第三阶段是把反思得到的差异转化为改动。
从分析到重构之间隔着一段不小的距离，这段距离需要专门的设计。差异只说明现状与预期不符，不说明该怎么改；同一个差异通常对应多条可行的改法，各自的代价与影响面并不相同。这一步交给 AI 尤其困难，所以值得单独设计。
路径推演
一种做法是路径推演：从当前版本出发，向若干个可能性推演，再从推演结果反推还存在哪些可能性。可能性不断展开，最终会得到不同的路径与不同的结果。
推演交给 AI，权衡留给人。AI 协助判断各条路径的代价与影响，人综合取舍，定下最终方案。
专家与新手
在这个模式下，专家与新手的差距会被放大：专家的判断力与引导能力更强，能在岔路口更快收敛。
缩小差距的办法是让方法本身可传递：
把更多方法封装成可复用的形态； 让 AI 能够遵循这些方法； 让新手结合项目经验学习方法。
方法可传递之后，从新手到专家的学习路径会更短。