AI时代的变更到底怎么管？（抛砖引玉版）

项目管理 #AI开发 #SpecCoding

A feature 做到一半，产品说"这个接口的参数要改一下"。就这么一句话。

放在传统项目里，教科书上有一套标准流程：提变更单，CCB 评审，影响分析，更新文档，通知相关方。繁琐，但清晰。每个人都知道变更从哪来、影响谁、当前状态是什么。

但现实里，能完整跑这套流程的企业是少数。大多数企业的做法落在两个极端之间：稍微规范一点的，建一个变更清单，列一列改了什么，然后就开始动手；再随意一些的，直接改，文档改不改看心情。最后的结果都一样，文档和代码越来越对不上，下游产物的一致性全靠人的记忆力兜底。只不过规范程度越低，对不上得越快。

这还没到 AI 时代，纯人的协作就已经这样了。

AI 不读变更日志

传统变更管理的核心工具是 CCB、变更日志、版本基线。这些工具之所以有效，因为人有能力在脑子里做跨模块的关联推理。变更日志写得再乱，人读一遍就能理出头绪：A 改了，B 受影响，C 需要同步。人甚至可以不依赖变更日志，靠对项目的整体理解来补全缺失的信息。

但是，大模型不行。

当前大模型的注意力窗口有限，它不能同时"看到"所有受影响的模块。变更信息散落在不同的文档、不同的对话里，AI 读着读着就忘了前面的内容，更别提做跨文档的关联推理。

所以在 AI 时代，变更管理从"人的流程问题"变成了"上下文工程问题"。你不仅要记录变更，还要把变更信息组织成 AI 能直接消费的结构。

两条路，都有代价

在我们自己设计的一套 SDD（Spec-Driven Development）体系里，每个 feature 是一个独立的目录，有自己的需求文档、接口设计、测试用例、开发计划。目前行业里没有所谓标准的 SDD 体系，各家都在摸索，这套是我们自己踩坑踩出来的。变更发生时，面临一个基本选择：这个变更怎么安放。

我试过两种方式。

第一种，每个变更都起新 feature。好处是隔离干净，变更和原 feature 互不干扰。代价是碎片化严重。一个模块改了三次，就多出三个 feature，追溯哪个变更是基于哪个基线的，很容易搞混。尤其是几个月后回头看，一堆 feature 散在那里，没有清晰的 lineage。

第二种，把变更挂在原 feature 下面当子项。好处是归属清晰，A 模块的变更都在 A 下面。代价是层级嵌套太深，同一个模块的变更叠了好几层，目录结构变得很难看。而且跨模块变更不好处理：一个认证方案的调整影响三个模块，变更文档放哪个 feature 下面？

两条路都能用，用起来都不舒服。

当前的方案：结构化锚定

现在我们的做法是用"需求变更"技能来管理。每次变更发生时，技能会扫描已有的 feature 列表，让用户确认变更的基线和影响范围。

核心机制是两个字段：base_on 和 change_group。

base_on 把变更 feature 指向它的原始 feature，建立一条追溯链。B 是 A 的变更版本，B 的 base_on 就是 A。顺着这条链，AI 可以从变更版本追溯到原始需求，理解变更的来龙去脉。

change_group 解决跨模块问题。一个认证方案调整影响用户认证、个人中心、审批管理三个模块，三个模块分别创建变更 feature，但共享同一个 change_group ID。这样在项目级视图里，这三个本不相关的 feature 被捆绑在一起，可以看到它们属于同一次变更。

pm （项目管理）技能会自动把所有 feature 按 base_on 关系聚合成树状结构展示，change_group 标注在行尾。跑一下 pm status，当前项目的变更全貌一目了然。

追溯搞定了，一致性没搞定

这套机制解决了"变更能不能被追溯"和"AI 能不能找到正确上下文"的问题。作为初期方案，方向是对的。

但它只管了需求这一层。每个 feature 的目录里还有接口设计、数据库模型、测试用例、开发计划，变更发生时，新 feature 有自己的全套产物，那原来的 feature 呢？这些产物怎么办？

举个例子：A feature 定义了一个 API 接口，测试用例也按这个 API 写好了。后来需求变了，创建了一个新的变更 feature B，把 API 的参数改了。B 的测试用例按新 API 写，跑出来没问题。但 A 的测试用例还是按老 API 写的，系统已经按新 API 跑了，A 的测试用例一定会报错。

那 A 的测试用例应该怎么处理？按新 API 更新，它就不再是对 A 原始设计的记录。不更新，它就是"过时但未被标记"的状态，变成噪音。

不只是测试用例。接口文档、数据库模型、开发计划，所有下游产物都面临同样的问题。

更有意思的是，这种"不一致"有时候是对的。A 的测试用例反映的是 A 当初的设计意图，它本来就应该和当前系统不一样，因为系统已经往前走了。但你说不清它到底是"合理的历史记录"还是"遗漏了没更新"。没人分得清，AI 也分不清。

人和 AI 想看的东西不一样

往深处想，会发现这里有一个绕不过去的矛盾。

人需要看到完整的、有历史脉络的信息。人想知道这个 API 最初长什么样，被谁改过，改了几次，为什么改。人的阅读习惯是线性的，可以反复跳转，能在脑子里构建时间线。

AI 需要的是精简的、当前有效的上下文。AI 不关心历史版本，它关心的是现在这个系统是什么状态，要改的这一行代码依赖哪些接口，这些接口的当前定义是什么。它的注意力窗口有限，每多加载一份历史文档，能分配给当前任务的理解力就少一分。

目录结构想要清晰，但变更带来的多版本产物天然就是混乱的。管理过程想要简单，但变更的连锁反应天然就需要大量人工干预来校准。当前方案试图同时让两个人满意，但他们的胃口其实是冲突的。

远没到终点

这事儿没解决。

base_on 加 change_group 解决了变更追溯这个子问题，但捅出了另一个更大的篓子：人和 AI 到底能不能共用一套文档体系。变更的基线锚定和影响范围管理找到了一个可用的方案，但改完之后原来的接口文档要不要同步更新、测试用例按哪个版本跑、项目全景里该显示哪个状态，这些事到现在我们也没想清楚。

我也没在行业里找到标准答案。

我能确定的是方向：变更管理在 AI 时代必须变成上下文管理的一部分，结构化的锚定机制是必要的。但人和 AI 怎么在同一套体系里各取所需、互不干扰，还需要继续摸索。

回过头看，传统时代变更管理是个大麻烦，AI 时代还是个大麻烦。只不过换了一副面孔而已。