SDD，指的就是AI编程工程范式的规范驱动开发（Spec-Driven Development，SDD）。为什么SDD在一些存量项目难以落地？主要源于以下三点原因：
1. 语境缺失与知识隐式化
“活知识”在人脑中：项目的核心逻辑、历史决策原因、特定“黑话”式的变量名含义，都存在于资深成员的头脑中，从未被系统化记录。
AI的“信息孤岛”：AI模型无法接入这些隐式知识，有些变量命名都毫无意义。例如当它面对一个名为 handleFoo() 的方法时，它无法理解这个“Foo”在业务上的精确定义和边界条件，导致生成的代码或规范南辕北辙。
2. 结构混乱与模式不一致
“屎山”代码：经过多年多人修改，代码结构可能已经腐化，同一功能在不同地方有多个实现，缺乏统一的设计模式和架构约束。
AI学习的噩梦：AI需要从现有代码中学习项目的模式和风格。如果代码本身是混乱且自相矛盾的，AI要么学不会，要么会学会并复制这些坏模式，从而加剧混乱。
3. 脆弱的依赖与隐式契约
模块间耦合紧密：依赖关系没有明确定义，大量通过全局变量、隐式参数或数据库状态进行通信。
AI重构的高风险：当AI试图根据新规范修改一个模块时，极易破坏这些隐式契约，引发难以预料的连锁反应，使得测试和验证成本极高。
那么，在这些存量老项目，应该怎么做？渐进式引入SDD的破局策略
正因为“不规范”是现状，所以“一步到位”的全盘SDD化是不现实的。更可行的是一种 “包围城市” 的渐进式策略：
1. 从“锚点”开始，而非全面重构
选择切入点：不要试图为整个系统编写规范。而是从当前迭代中新增的功能模块或需要重构的独立服务入手。
建立“规范飞地”：为这个新模块严格采用SDD流程。这样，你就创建了一个干净、符合SDD规范的“飞地”。随着时间推移，这些“飞地”会逐渐连成一片。
2. 利用AI进行“考古”与“逆向工程”
AI辅助文档化：可以将晦涩难懂的代码块扔给AI，并指令它：“分析这段代码，为它生成一份清晰的功能规格说明。” 这是一个低成本的知识提取过程，生成的文档可以作为编写正式规范的初稿。
识别模式与坏味道：让AI分析代码库，识别出重复代码、不一致的命名等，为重构提供具体目标。
3. 制定并固化“最小可行规范”
在存量项目中，追求完美、详尽的规范是不现实的。应该定义一套本项目级别的“最小可行规范”模板。
这个模板可能只包含最关键的要素：功能描述、输入/输出接口、关键业务规则、成功/失败场景。先确保新增和修改的部分至少满足这个最低标准，逐步提升代码库的整体规范性。
4. 工具链的轻量级集成
将规范检查集成到CI/CD的关键环节。例如，要求所有与新模块相关的Pull Request必须关联一个规范文档的链接或ID，由AI助手或资深开发者进行简单的一致性检查。这能将文化变革转化为可执行的流程。
心态转变：将SDD视为“还债”与“保值”的工具
最关键的是，团队需要重新认识SDD在存量项目中的价值：它不仅是开发新功能的方法，更是一个治理技术债、提升代码库长期可维护性的战略工具。
每一次为存量代码编写规范，都是一次“知识显式化”的过程，都是在为代码资产“保值”。虽然前期有额外投入，但它能显著降低后续的理解、修改和协作成本。
总结来说，在存量项目引入SDD，更像是一场“考古”与“新城建设”并行的战役。 挑战巨大，但通过选择正确的战术（渐进式、工具辅助、聚焦价值点），完全可以将SDD的理念逐步注入不友好的现有环境中，最终扭转局势，让庞大复杂的存量代码库变得对人和AI都更加友好。