如何有效管理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 原始设计的记录。不更新，它就是"过时但未被标记"的状态，变成噪音。 不只是测试用例。接口文档、数据库模型、开发计划，所有下游产物都面临同样的问题。 更有意思的是，这种"不一致"有时候是对的。