王永刚，英湃科技Inspire（原Thoughtworks）资深研发工程师，拥有多年企业级系统研发与大型团队交付经验，擅长复杂业务建模、系统设计与工程化实践，当前聚焦 AI 工程化与研发效能方向。
从认知到实践
在某大型制造客户项目的一次实践中，我们在一个报表需求中发现一个非常典型的问题：当 AI 去尝试将代码中由 Flyway 管理的迁移脚本去理解数据表时，由于信息过于碎片化，AI 很难建立稳定的整体认知，生成的分析结果也往往是局部的、错误的。
但当我们将数据库 Schema 通过 SQL 进行结构化导出，并以更清晰的整体视图提供给 AI 后，它对业务结构、字段关系以及核心规则的理解质量明显提升。
这个对比让我们意识到一个关键点：问题不在于 AI 能不能理解系统，而在于我们给它的“系统表达方式”是否具备结构性。
还有一个案例是，我们需要基于现有代码，反向为客户生成一份完整的业务操作手册，这本质上是在还原系统的核心业务规则，并以业务可理解的方式表达出来。这也让我们开始思考，如果 AI 可以高效维护代码，是否也可以帮助我们维护业务认知。
基于这一思考，我们逐渐形成了一套新的实践方向：将零散的业务知识拆分为可独立理解的“认知单元”，并通过统一载体进行集中管理，不再以“变更过程”为主线，而是以“当前状态”为核心进行表达。无论是数据库结构、业务流程，还是核心规则，都围绕“现状”进行系统化沉淀。在后续开发中，我们也逐步补充表间关系、业务流程图与状态机模型，让 AI 与团队成员能够在统一上下文中理解系统。这一系列实践最终验证了一点：真正支撑 AI 高效工作的，并不是零散的 Spec，而是结构化的“现状型认知资产”。
根据使用场景给 Spec 分类
踩过无数坑，历经无数次复盘沉淀，我们终于收获了一个最核心的认知：SDD 落地的关键，从来不是“写好每一份 Spec”，而是“分清 Spec 的类型，做好取舍与平衡”。我们无需强求所有 Spec 都尽善尽美、滴水不漏，因为 Spec 本质上可分为两类，它们的价值定位与维护成本，有着较大的区别，核心是在维护成本与业务价值间找到平衡，无需追求所有 Spec 完美无缺。
过程型 Spec：为高效完成任务
这便是我们如今最常用的类型，它绑定单张需求卡，面向单次开发任务，生命周期短暂，更像是一个 Plan 文档或是规划类文稿。而过程型 Spec，本质上只是一次性的任务执行说明。它的核心价值，在于给 AI 提供清晰的指令，规范 AI 的输出方向，通过打磨它，帮助团队完成单次开发任务的认知对齐，一如过去的 UserStory，可随着我们对需求的认知不断深化，逐步完善优化，强调快速反馈验证。
这类 Spec，无需高成本维护，因为它的价值，仅体现在单次开发任务中。诸如紧急 Bug 修复分析文档、临时需求开发，我们只需让 AI 快速撰写一份简易 Spec、Plan 文档，当然也可以是 Vibe Coding。确保 AI 生成的代码符合当前需求即可，后续无需持续更新维护。毕竟，它终究只是一个“执行工具”，核心使命是解决单次开发的效率问题，即便零散，也无需过度苛责，不必强求它承载过多的价值，甚至可以被 gitignore 掉。
资产型 Spec：沉淀可复用的认知
这是我们过去长期缺失的，也是 SDD 真正能够落地的核心所在。
在经历了大量过程型 Spec 的反复打磨之后，我们逐渐意识到：很多问题并不只是“任务规划不够详细”，而是在于团队始终缺少一份稳定、可共享的系统现状认知。过程型 Spec 更多服务于单次开发任务，它绑定需求卡或某次具体变更，核心是帮助 AI 理解“这次需求要怎么做”。为了让 AI 生成正确代码，我们往往需要不断补充上下文、修正理解、校对细节，在人与 AI、开发与 BA 的多轮来回中，逐渐形成对业务的完整认识。但这类 Spec 粒度非常细，描述的是“这次如何修改”，而不是“系统当前到底是什么”。随着需求不断迭代，它很容易碎片化，维护成本也会持续升高，很多内容在任务结束后便逐渐失效。
也正是在这个过程中，我们开始意识到：真正长期影响 AI 理解质量的，往往不是这些一次性的过程描述，而是另一类更加稳定、更粗粒度的内容，例如系统当前的业务结构、核心规则、领域边界、关键状态流转，以及数据库之间真实存在的关系。这些内容变化频率相对更低，却构成了后续所有 To-Be 演进的基础。于是，我们逐渐形成了“资产型 Spec”的概念。它不绑定具体需求卡，而是面向业务核心规则与系统整体现状，长期存在、可复用、可迭代。一如我们案例中的“当前 DB Schema”那般，它更像是一种“现状型”的认知表达，是勾勒业务技术全貌的“全景图”。如果说过程型 Spec 更像施工计划，那么资产型 Spec 更像地图，前者关注“这次路怎么修”，后者关注“整个城市现在长什么样”，只有有了现在城市长什么样子，我们再去制定施工计划的时候，才能更多地发挥 AI 和人的主观能动性，去确认这次的计划是不是在受约束的现状下，是不是最优的，是否有更好的解决方案。
更重要的是，资产型 Spec 的价值，并不只属于开发者。过去很多 Spec，本质上是开发者为了驱动 AI 生成代码而编写的执行上下文，BA（业务分析师）、产品甚至其他团队成员由于缺少代码背景，很难真正参与其中，Spec 最终变成了一种开发者内部语言。但资产型 Spec 不同，它的核心目标不是描述“如何开发”，而是表达“系统当前是什么”。这意味着，它天然更适合作为开发、BA、产品、测试乃至客户之间的共享认知载体，也第一次真正补齐了过去长期缺失的一块：对系统现状（As-Is）的稳定输入。而这种输入，恰恰是后续定义 To-Be 与识别 Gap 的关键前提。直到这个阶段，我们才真正理解：资产型 Spec 的意义，从来不只是“给 AI 更多上下文”，而是在团队内部，构建一套能够长期沉淀、共享与演化的认知基础设施。
客户的反馈，验证了我们的判断
在某电商履约系统项目的实践中，更让我们坚定了“Spec 需分两类”的认知。当时我们的研发模式采用的便是 SDD 的端到端开发，项目交付节奏非常紧张，我们严格按照 SDD 流程推进，将重点放在过程型 Spec 的撰写上，核心目标是快速完成开发交付，确保每一个开发任务都能精准落地。就在项目临近上线时，客户主动提出要查看我们的 Spec，想了解项目的业务逻辑和系统现状。那一刻我们突然意识到，我们和客户对 Spec 的期待，从一开始或许就截然不同。
站在开发视角，我们写的 Spec，核心是指导 AI 把具体开发任务做对、做准、做全面。比如某个接口的参数、某个逻辑的分支判断，都是围绕单次开发任务展开，只为适配 AI 生成代码和团队内部对齐，这正是我们所说的过程型 Spec。但客户翻完这些 Spec 后，却一脸困惑：他们或许不关心我们具体怎么开发、AI 怎么生成代码，更想知道的是当前系统的业务现状是什么、核心业务规则有哪些、边界在哪里，这恰恰是我们缺失的资产型 Spec。
维护资产型 Spec 的一些实践
在明确资产型 Spec 的价值之后，我们也逐渐意识到：这类 Spec 本身就是一种需要长期投入与持续治理的资产。如果缺乏结构、维护机制以及稳定的认知输入，它同样会迅速失效，甚至反过来污染系统认知。而资产性 Spec，也不是一天就能建成的，而业务还在继续。下面从两个维度，个人维度和团队维度，给出一些资产型 Spec 的实践建议。
图片来自网络
个人实践
在个人实践层面，我们后来逐渐形成了一个非常重要的习惯：面对复杂需求时，不再一上来就直接让 AI 基于 To-Be 去生成方案或代码，而是优先围绕“现状（As-Is）”进行充分调研与诊断。
尤其是在一些涉及核心链路、历史逻辑较重、甚至需要“给系统动手术”的需求场景下，如果开发者自己都没有真正理解当前系统状态，仅凭一份目标描述便直接交给 AI，自然很容易放大认知偏差。因为 AI 能生成的，本质上只是基于当前输入做出的推导，它并不知道系统过去为何演化成现在这样，也无法天然理解那些隐藏在代码、配置、数据以及历史妥协中的真实约束。
因此，我们现在更倾向于先借助 AI 去“理解系统”，而不是急于“修改系统”。
在拿到需求后，我们会围绕当前业务与技术现状，主动进行更完整的上下文调研。例如结合代码、数据库、日志、历史需求以及业务流程，让 AI 辅助生成模块相关的时序图、状态图、领域关系图以及文字化描述，帮助我们逐步还原当前系统的真实运行方式。这个过程本质上并不是为了“画图”，而是在不断校准我们对系统现状的认知，并让 AI 逐渐建立更完整的上下文理解。
当 As-Is 被逐渐厘清之后，我们才会再结合目标需求（To-Be），与 AI 反复讨论方案是否合理、边界是否完整、改动是否会影响已有链路。在这一阶段，AI 更像是一个参与推演与分析的协作者，而不只是一个代码生成工具。
而在拥有了足够完整的上下文之后，再进入最终的开发实现阶段，AI 的输出质量往往会稳定很多。相比于一开始只给出一个“我要做什么”的结论式需求，让 AI 在模糊上下文中自由发挥，这种“先理解现状，再推进演进”的方式，虽然前期看起来更慢，但整体返工成本、方案偏差以及后期修复成本，反而会低得多。
团队实践
在团队实践中，我们将资产型 Spec 抽象为一个从宏观到微观的三层结构，使系统认知能够形成清晰层次：
-
L1：全局视图（The Map），定义系统边界与整体业务技术架构
-
L2：领域/模块视图（The Area），沉淀领域规则、关键数据模型与核心约束
-
L3：活动/流程视图（The Flow），描述业务流程、状态流转与隐式规则
这些内容共同构成团队的认知基座。一旦偏离真实系统状态（As-Is），影响便会被 AI 持续放大。因此，资产型 Spec 的核心，从来不只是记录信息，而是持续逼近真实。
在某客户的一个商城项目中，我们采用了一种渐进式的沉淀路径。面对 80 多个长期演进的代码库、零散的业务逻辑以及大量隐式规则，AI 与新成员若直接从代码入手，往往需要在海量信息中反复检索与推测，成本极高。基于此前在另一个行业客户项目中“AI 生成 + 人工校准”的经验，我们结合业务调研、代码与数据库分析，优先梳理产品蓝图、核心业务领域、关键规则与技术架构，逐步构建起最小可用的资产型 Spec，形成基础认知体系。
同时我们也发现：资产型 Spec 的稳定性，并不只取决于“文档是否维护”，还与研发任务本身的组织方式密切相关。
过去在敏捷模式下，我们习惯将需求拆分为大量细粒度卡片，由不同开发者分别处理。这样的模式虽然提升了并行开发效率，但在 AI 与 SDD 场景下，也会天然削弱开发者对业务整体的理解。Agent 看到的往往只是局部逻辑、单个接口或一次小范围修改，很难真正形成端到端的业务认知，而资产型 Spec 所需要维护的，恰恰是更高层级的系统现状与领域规则。
因此，在后续实践中，我们开始有意识地调整任务分发方式。对于一些核心业务场景，不再严格按照卡片维度切分，而是 TL（Tech Lead）与 BA （业务分析师）对这部分的内容进行前置打磨，设计确认后，交给开发同学承担相对完整的业务模块开发，例如将多个关联需求打包后统一处理***。这种方式虽然降低了部分并行度，但开发者能够在实现过程中持续接触完整链路，对业务规则、状态流转以及系统边界形成更稳定的理解，而这些认知，也更容易沉淀为长期可复用的资产型 Spec。
与此同时，我们也逐渐避免让所有人同时维护同一批核心 Spec，而是由少量长期参与该领域的开发者协同维护。这并不是为了形成知识壁垒，而是因为资产型 Spec 更像“领域地图”，它需要维护者对业务演化历史、系统现状以及隐式规则具备持续认知。如果维护主体频繁切换，Spec 很容易重新退化为零散的过程描述，最终失去“认知基座”的价值。
然而，真正的挑战仍然在于如何对抗熵增。
从行业趋势来看，我们已经能看到一些令人兴奋的探索，例如 LLM Wiki、 Understanding Anything 及 CodeGraph 这类代码库理解与问答系统。它们正在尝试借助 AI 自动解析代码结构与依赖关系，帮助开发者快速建立系统认知。从本质上看，这些方向与资产型 Spec 所要解决的问题是一致的，都是在为复杂系统构建一层可被理解、可被消费的认知表达。
但在当前阶段，这类能力在复杂系统中的稳定性与可控性仍有待验证。尤其是在遗留系统、隐式规则以及长期演进痕迹大量存在的场景下，单纯依赖 AI 仍然难以建立可靠的认知基座。因此，在可预见的一段时间内，我们的策略并不是“让 AI 替代维护”，而是先由人建立认知，再通过流程与治理机制将其稳定下来：一方面，通过结构化的资产型 Spec 主动沉淀系统认知；另一方面，通过持续更新、实际使用以及研发流程约束，对抗认知与代码之间的偏移。在此基础之上，再逐步引入 AI，辅助提取、校验与补全认知，而不是将其作为唯一依赖。
基于这一思路，我们最终将资产型 Spec 纳入类似技术债的治理体系，通过一套持续运转的闭环机制来对抗熵增：
-
使用驱动（Use it） 在引入新 Feature 时，将相关 Spec 作为上下文输入，与 AI 做背景对齐，辅助问答、方案设计与功能开发。Spec 不只是被“维护”，而是被持续“使用”，从而保持其活性与现实相关性。
-
增量更新（Update it） 在功能实现完成后，由 TL 判断变更是否触达资产型 Spec（重点关注 L1、L2 层，L3 可由开发同步更新），并及时修订，确保认知随代码同步演进。
-
上线校验（Check it） 在功能上线阶段，基于实际实现结果，对需求与 Spec 进行反向校验：通过人工确认关键差异，并结合 AI 辅助修正，使 Spec 与真实系统状态重新对齐。
这套流程的核心，并不是单点优化，而是通过“使用—更新—校验”的持续闭环，让资产型 Spec 始终与系统保持同步，从而具备长期可信度与可用性。某种意义上，我们后来也逐渐意识到：AI 时代真正需要被持续维护的，或许不只是代码，而是团队对于系统真实状态的共同认知。
构建认知系统
从 2025 年至今，在服务客户 AI 应用的业务转型中，让我们逐渐意识到：我们一开始就问错了问题。过去，我们不断追问“Spec 应该怎么生成，那个工具好，咋样能让 AI 生成更好的代码”。但回头看，这只是一个表层问题。Spec 从来不是目的，它只是承载认知的载体。真正关键的是：我们是否建立了一套能够持续表达、校验并更新系统认知的机制。总结来看，本文的内容，是经过我们的探索与实践进行的总结，可能还有一些不完美之处，希望能得到大家的理解与包容，同时也非常欢迎大家的交流与建议。
当从认知管理的视角重新审视 SDD，很多问题就变得清晰了：团队的瓶颈，往往不在于 Spec 写得好不好，而在于这些内容是否被纳入一套可运转的认知体系。无论是一次性的过程型 Spec，还是长期沉淀的资产型 Spec，亦或是 Schema、流程图等现状表达，本质上都在回答同一个问题，当前业务下的真实状态是什么。
一旦这种“真实”能够被稳定表达，AI 带来的效率提升就会成为自然结果，而不再是需要刻意优化的目标。SDD 要解决的，也从“如何让 AI 写代码”，转变为一个更本质的问题：如何让团队始终对系统的真实状态保持一致认知。
从这个角度看，开发过程本身也发生了变化不再只是实现功能，而是在不断修正与演化这套认知系统。Spec 也不再是孤立的文档，而是认知系统中的一个节点。这个系统并不是抽象概念，而是由资产型 Spec、结构化 Schema、以及持续更新机制共同构成的具体体系。
这或许才是 AI 时代研发方式真正的转变：从“围绕代码交付”，走向“围绕知识资产运作”。或许 SDD 并不是终点，它只是一个起点，一个将研发重心，从“实现功能” 转向 “管理认知与系统真相”的起点。
References
英湃科技
Inspire
英湃科技（Inspire）是一家致力于将前沿 AI 技术与顶尖工程能力相融合，帮助企业实现数智转型的新一代科技服务商，源于 Thoughtworks 中国核心团队，2025年9月由高瓴资本收购，不仅拥有世界级的架构设计与敏捷交付底蕴，更具备深刻的行业洞察。英湃科技围绕企业核心价值链，聚焦研发、供应链、销售与服务等领域，重塑关键能力与组织模式，服务领域包括银行金融、消费电子、具身智能、智能汽车、制造业、医疗&制药、消费品&零售等各行各业130+家全球500强企业，业务中心遍布新加坡、香港、上海、北京、深圳、成都、西安、武汉。
