王永刚，英湃科技inspire（原thoughtworks）资深研发工程师，拥有多年企业级系统研发与大型团队交付经验，擅长复杂业务建模、系统设计与工程化实践，当前聚焦 AI 工程化与研发效能方向。
## 引言

基于 2025 年服务智能汽车、制造业、消费、医疗等多个行业的 AI 项目实践，我们曾试图分析 AI 介入后研发效能的本质变化，并提出了一个核心观察：AI 正在彻底重构研发的时间结构。随着 AI 不断压缩了原本编码这个长周期，研发的瓶颈发生了结构性位移，我们观察到原本作为衔接环节的前置“认知对齐”与后置“自测验证”，反而被意外拉长，演变成了新的矛盾。
![image](https://developer.qcloudimg.com/http-save/yehe-7590158/47868ee3e775ec473efd021a40a0899f.webp)
这一变化的背后，潜藏着一个极易被忽视的问题。在传统模式下，长的编码期其实是人类开发者对需求的“二次打磨”过程。我们基于[敏捷 3C 原则](https://link.zhihu.com/?target=https%3A//guides.visual-paradigm.com/cn/mastering-user-stories-techniques-templates-and-the-3cs-for-agile-development/)（Card、Conversation、Confirmation）与 Customer Focus（以客户价值为中心）   价值导向，利用个体的主观能动性，通过与 BA（业务分析师，后文简称 BA） 保持高频沟通对齐，深度探索、理解和洞察业务的真实本质的需求，在编码开发的同时，同步完成业务隐性意图的纠偏。然而，当 IDE 的战场从实现工具转向以 Agent 主导的对话界面，这层人的把控被弱化了。AI 缺乏识别模糊意图的能动性，若无确定性的上下文支撑，快速生成只会让初始的偏差不断放大，最终在验证阶段爆发为需要不断调整的效率黑洞。
摘自《Harness Engineering 橙皮书：AI 编程时代的工程方法论》： 模型对自己的第一个可行方案有天然偏好。它不是不会做得更好，是太容易满足于「看起来可以」。为了填补这一认知真空，我们开始尝试将模糊的意图转化为可资产化的确定性输入。本文将聚焦于 前置上下文工程 ，分享我们在 SDD（规范驱动开发）领域的实战反思；而关于如何提升后置环节的“验证信心”，我们也在同步进行一系列自动化探索，将在未来的文章中与大家另行讨论。
## SDD 是一种面向 AI 时代的软件开发方式，核心是将需求理解、系统设计、代码实现与验证反馈等环节进行结构化表达，使 AI 能够在更清晰的工程上下文中参与到开发流程中。它并不是一个完全成熟或统一定义的标准，而是当前在 AI 辅助软件工程实践中逐步形成的一类方法探索。SDD 的开始

在 2025 年，我们逐步的从 Vibe Coding 逐步转向 SDD（Spec-Driven Development，后文简称 SDD），但这个过程并不顺利。随着 Cursor、Claude Code 等 AI 编程工具在团队的普及，我们一度以为：只要把需求写成 Spec，AI 就能自动生成高质量代码，从而彻底摆脱过去开发中的混乱与效率瓶颈，于是几乎没有犹豫就拥抱了 SDD，尝试用“需求卡 + Spec + AI 生成代码”的方式重构开发流程。
初期的效果确实令人兴奋：过去需要半天完成的接口开发，AI 几分钟即可生成，我们一度认为自己找到了拉齐开发经验差异、高效交付的秘密，可这种高效并没有持续太久。
直到这时我们才意识到：问题似乎并不在于 SDD 的使用方式，而在于我们是否真正理解了 Spec 在软件系统中的本质，它究竟是用来驱动代码生成的输入，还是用来承载系统认知的结构。更核心的是，我们后来发现，资产型 Spec 从来不是静态文档，而是一种系统治理的载体，它不是写出来的，而是打磨出来的，且具有极高的维护熵增风险。
## SDD 里遇到的问题

![image](https://developer.qcloudimg.com/http-save/yehe-7590158/76a807ba54e61e79a003754befa5eba2.webp)
图片来自网络我们曾满心期许，一份 Spec 便能终结 Vibe Coding 时代的混乱与低效，化解团队协作中的沟通壁垒。但真正落地之后才发现，SDD 不仅没有根除这些老问题，反而在很多场景下，将原本隐藏较深的矛盾进一步放大。回头看，这些问题几乎都指向同一个核心那就是认知对齐，而 AI 的加入，并没有解决这个问题，反而在很多时候，成为了它的放大器。某种意义上，SDD 并不是让开发变简单了，而是把问题从“代码阶段”，前移到了“认知阶段”。
### 认知对齐了吗？

团队协作的核心，或许从来不是“谁来写代码”，而是“能否对同一份需求、同一种业务逻辑形成一致认知”。这句话听起来简单，但在实际落地中却异常困难，而这正是我们在 SDD 过程中首先遇到的阻力。
我们接手的很多系统，并不是全新的绿地项目，而是运行多年的复杂系统。核心业务规则从未被系统性记录：有些藏在历史代码或配置中，有些散落在 Bug 修复记录里，还有一些只存在于老员工的经验中。在人员流动频繁、业务变化较快的组织里，甚至连“当前业务到底是什么”，都很难被清晰描述。在这样的背景下，Spec 的撰写不可避免地变成了一种“信息拼图” 我们只能基于零散碎片去推测、补全和拼凑，很难形成真正一致的认知，偏差几乎是必然结果。
更关键的是，我们逐渐意识到一个非常容易被忽略的事实： 代码并不等于业务真相 。在遗留系统中，代码往往是被扭曲过的结果，其中混杂着历史妥协、临时补丁、紧急修复和人为操作的痕迹，它记录的是系统的现状，而不一定是“业务应该如何运作”。如果把这样的代码直接当作认知依据，那么从一开始，Spec 就已经建立在一个不稳定的基础之上。
### AI 让错误更快发生

在没有 AI 的时代，开发拿到需求之后，很少能一步到位写出完全正确的实现，而是会在落地过程中持续遇到问题、修正对需求的理解。这个迭代校正的过程，本身就是一种被动的需求打磨、认知校准机制。
但引入 AI 之后，这个天然的校准过程被大幅压缩了。看到不少同事拿到需求后，没有和 BA（Business Analyst）进行充分的来回确认，就基于当下的个人理解，直接将需求交给 AI 生成实现。简单场景尚且可控，但在复杂业务场景下，敏捷 3C 原则中，原本依靠人与人之间反复校对、逐步完成的认知对齐，渐渐被替换成了人与 AI 的一次性交互。
2025 年底，我们在讨论 AI 辅助研发时，我们也聊到一个话题：***AI 是否会弱化大家对需求本身的深度思考？***当时我并没有太深的感触。经过团队这一年 AI 辅助研发的落地实践，我慢慢发现：当开发者编写代码的成本大幅降低时，变更、修改代码的成本也随之变得更低。
从前，我们会尽全力先吃透、搞懂完整的需求，核心目的，是为了减少我们在代码上来来回回的修改，因为是人在写代码，这个成本是你需要去承接的。。
而现在的问题在于：在我们描述的有限上下文里，AI 并不会主动质疑、反问需求本身的合理性与隐藏问题。它更倾向于扮演一名 “产出看起来合理结果” 的 To-Be 目标生成器，而非立足业务本身、结合真实世界的约束，反向推演可落地路径的架构思考者。
放眼行业前沿，无论是 Anthropic 的工程师团队，还是 OpenAI 公开的技术博客，在 Harness Engineering 的落地实践中，都发现了同一个规律：真正支撑系统持续演进的关键需求、底层决策逻辑，往往并不会完整留存于代码仓库当中，而是散落在 Google Docs 的文档推导、甚至 Slack 频道里那些转瞬即逝的聊天记录里。
而我们又何尝不是呢？ 那些最核心的业务约束、复杂的边界判断，往往藏在会议室的白板上，拍照后存在手机的相册里，和产品的讨论沟通中，藏在开发者与 BA 之间那些没有记录的面对面沟通中，在深深的脑海里。甚至藏在某次为了应急而临时妥协的“潜规则”里。
在这种情况下，AI 不是在帮你理解需求，而是在放大你当前的理解。无论这个理解是否准确。即便现在的 AI 能通过 Agentic Search 去研究部分代码库现状，但由于它触达不到那些弥散在代码之外的“库外共识”，它的生成逻辑就成了无根之木。
结果就是，生成的代码在表面上完全符合需求描述，但在真实系统中却存在偏差，最终仍然需要花费不少时间去修正，甚至造成返工。今天就能 DC（  Desk Check），也因此成了一句常被挂在嘴边的调侃，但这个“搞定”，往往只是代码生成动作的终结，而不是问题真正被解决。
这种变化还带来了一个微妙但关键的转变：自测的本质发生了变化。
过去，代码是一行一行写出来的，需求是在实现过程中逐步被吃透的，开发者对细节非常清楚，自测更多是在验证功能是否正确，而现在则更多的像是在检查 AI 做了什么。同时，现有 Spec 工具大多偏向开发者视角，BA 由于缺乏代码上下文，很难深度参与，Spec 逐渐演变为开发者的“单向表达”，进一步加剧了认知错位，也就是说当 BA 无法进入 Spec 语境时，Spec 就不再是人和人的对齐工具，而只是开发者的工具。在这种模式下，OPC（One Person Company）类的开发者感觉可能会觉得很自在。但在团队协作的模式下，Spec 由谁来写（BA？Dev？Agent），为什么要写？写了之后给谁看？需求的载体是什么，就会遇到一些问题。
### Spec 的投毒效应

另一个我们踩过的坑，是后来在团队内部被戏称为“给 AI 投毒”的问题，Spec 的质量直接决定了 AI 生成代码的成色，但在实际开发中，这一核心环节的问题却常常被忽视，最终引发了一系列连锁反应。
![image](https://developer.qcloudimg.com/http-save/yehe-7590158/605cc93f1aec147cbbbb7b37232fb001.webp)
图片来自：Learnings from a No-Code Library: Keeping the Spec Driven Development Triangle in Sync在 Spec 撰写的实际过程中，问题几乎不可避免：有人为了追求速度，对 Spec 打磨不够、遗漏关键信息；也有人在初版 Spec 中就存在业务认知偏差，却没有在后续迭代中及时修正。而在最初阶段，我们并没有对这些问题给予足够重视，总抱着“写错了，改代码就好”的侥幸心理，忽视了 Spec 作为 AI 生成代码的核心依据，其错误会被不断放大。
直到一次依赖卡开发的经历，让我们直观感受到了问题的严重性。当时我接手了一段前同事反复修改过的逻辑，表面上代码已经稳定，但推进过程中总觉得哪里不对劲，逻辑虽能运行却不符合业务直觉。深入追溯后才发现，问题根源并非当前代码实现，而是我的 AI 依赖了其他人最早的一版 Spec，最初的那份 Spec 它本身就存在关键业务理解偏差，后续所有修改都只是围绕这个偏差“修补”，而非从根源纠正，这种现象在依赖他人 WIP （Work in Progress） 的代码中也会有这样的问题。这种感受十分反直觉：我们不是在修复实现错误，而是在错误的认知基础上，不断叠加“正确”的代码。最终，我们选择回溯梳理业务规则，修正 Spec 后重新搭建实现路径，也正是这次经历，让我们深刻意识到：错误 Spec 一旦进入开发流程并被反复引用，就会从“局部偏差”变成系统性的隐性前提。
而这一问题的背后，还有一个更现实且普遍的痛点 Spec 的维护往往被忽视。
我和其他几个团队也交流过这个话题：需求变化之后，你们会回头修改 Spec 吗？
坦白讲，在迭代交付的压力下，大家往往会选择成本最低的路径：代码修改完成就视为交付，Spec 要么不同步更新，要么只是零散补充，甚至堆叠出一堆不同维度、逻辑混乱的内容。我们与其他团队交流后发现，这几乎是一种普遍现象，而这种对 Spec 维护的忽视，恰恰是“投毒效应”不断加剧的根源之一。项目上下文了解不深的开发者无法有效判断，会基于错误依据生成更多错误代码，甚至可以说，Spec 维护的缺失，比 Spec 本身写错更具破坏性。
## 问题或许不在 SDD

 
![image](https://developer.qcloudimg.com/http-save/yehe-7590158/a2ec0675727ecb380e63e7f95a6e3f03.webp)
图片来自网络被这些坑反复打磨了大半年，我们才终于静下心来复盘：究竟是 SDD 本身存在缺陷，还是我们的落地方式，从一开始就偏离了方向？
几番梳理之后，我们逐渐得出了一个有些反直觉的结论：
问题的根源，一部分来自传统敏捷模式的路径依赖，一部分来自在现实交付约束下对规范维护的持续让步，而未必在于 SDD 本身。我们长久以来，一直沿用“需求卡驱动开发”的模式。User Story 的设计初衷，是为了适配批量开发场景、提升整体交付效率。但一个容易被忽略的事实是：单张需求卡，从来都不等同于完整需求。一份完整的业务真相，往往需要拼接所有需求卡、梳理历史变更，甚至逐行核对代码，才能勉强呈现。
需求卡本质上只是管理过程，对业务的局部表达，而不是全局认知。
而在转向 SDD 之后，我们几乎是无意识地把这套模式原封不动地迁移了过来，一张需求卡对应一份 Spec，使得 Spec 同样陷入零散化困境，无法沉淀为完整的业务资产。某种意义上，我们并没有在做 Spec-Driven Development，而是在做“Spec 版的需求卡开发”。
另一半问题，则来自更现实也更难规避的一点：在高频交付与不确定性变更的压力下，团队往往很难持续投入成本去维护 Spec 的一致性。
在实际工作中，突发 Bug、临时需求、紧急上线几乎是常态。在交付压力面前，很少有人会严格遵循 SDD 流程去完善 Spec、反复对齐认知。更常见的选择，是复用已有逻辑、弱化流程约束，先解决眼前问题，并将 Spec 更新延后处理。
这些看似高效的捷径，让 Spec 逐渐流于形式，开发重新滑回零散化状态，认知不断脱节，并与“需求卡模式”的惯性叠加，形成一个自我强化的循环。
某种程度上，SDD 并不是一个设计错误的模型，它的问题在于，它对团队提出了一个非常高的隐含前提：必须持续维护一致的系统认知，而这件事本身，是有较高的成本的，尤其是细粒度变化频繁的 Spec。
但当我们把“问题不在 SDD”这一点逐渐看清之后，一个更难的问题也随之浮现出来：
如果问题不在于工具和流程，那我们真正缺失的，到底是什么？
## 对问题的深入分析

但当我们逐渐接受“问题不在 SDD”之后，一个更具体的问题也随之浮现出来：如果不是流程出了问题，那我们在开发过程中，究竟缺失了什么？
回头看这些反复出现的现象，认知难以对齐、Spec 不断偏移、AI 放大理解偏差，它们表面上各不相同，但背后却指向同一个更底层的空白：我们始终没有一个稳定、清晰、可共享的“系统现状表达”。
我们习惯拆分需求、记录变更、描述目标，却很少真正去回答一个更基础的问题：当前系统到底是什么样？业务规则的真实边界在哪里？哪些是稳定存在的约束，哪些只是历史演化的结果？这些本该作为起点的内容，往往散落在代码、数据库、配置和人的经验之中，从未被系统性表达出来。
在这样的前提下，无论是需求卡、Spec，还是 AI 生成代码，本质上都是建立在一份并不完整的认知之上。我们以为自己在推进开发，实际上却是在一个模糊的“现状”之上不断叠加新的变化。
也正是在这个阶段，我们开始意识到：与其继续优化流程、打磨 Spec 的写法，或许更应该先回答一个更基础的问题，如果连“现在是什么”都说不清楚，我们如何能更好地引导 AI，更多的 Skill？精心维护的 Promot？或许都不是。我们也同步地发现，拥有更多项目背景的人在完成 Story 开发和 DC 的时候，效率及完成度会更高一些，在对他们进行观察之后，几乎都回到了一个逃避不开的话题，到位的需求理解。
那我们口中的“需求”，究竟指的是什么？
过去，我们习惯将需求理解为 To-Be，客户提出的目标、功能，或拆分后的 User Story。但这种理解，其实隐含了一个前提：我们已经清楚“当前系统是什么样”，只需要讨论“要做什么”。
而现实恰恰相反。
在大多数客户那里，业务的现状是复杂不清晰的，IT 系统也是“现状”不清晰的：它分散在代码、数据库、配置、历史需求以及业务人员的经验之中，没有任何一个单一载体可以完整表达。这意味着，在很多时候，我们甚至还没有搞清楚 As-Is，就已经开始讨论 To-Be。
这也解释了为什么，在 SDD 过程中，即使 Spec 写得再详细，AI 生成的代码依然可能偏离实际，因为整个推导的起点，本身就是模糊的。
基于这样的反思，我们也认识到真正的需求，或许并不是目标本身，而是从现状到目标之间那段被忽略的差距。
![image](https://developer.qcloudimg.com/http-save/yehe-7590158/5f5d20189aa3e6638fd960eb05fd3e64.webp)
As-Is（现状） + To-Be（目标） + Gap（差异）
                 ● As-Is，是对当前系统与业务的真实还原，是一切的起点
                 ● To-Be，是在现状基础上的合理演进方向
                 ● Gap，才是开发真正需要解决的问题
在复杂系统中，最大的问题不是我们想做什么，而是我们根本说不清现在是什么。如果 跳过 As-Is，直接定义 To-Be ，AI 只是忠实地执行了这个不完整的输入。
但真正困难的，并不是定义 To-Be，而是还原 As-Is。
我们不得不通过翻代码、查配置、追溯历史、与业务人员反复确认，去拼凑出尽可能接近真实的系统状态。这个过程，我们做的，其实是一场业务考古。从零散信息中提取线索，通过不断对齐与验证，还原系统的真实运行逻辑。
而一旦 As-Is 能够被清晰表达，To-Be 的设计与 Gap 的识别，反而变得更加自然。
在下一篇文章中，我将结合大型制造业与电商履约等复杂项目实践，进一步展开我们在 SDD 落地过程中的治理方式，以及如何在真实工程场景中提升其可用性与稳定性。



王永刚，英湃科技inspire（原thoughtworks）资深研发工程师，拥有多年企业级系统研发与大型团队交付经验，擅长复杂业务建模、系统设计与工程化实践，当前聚焦 AI 工程化与研发效能方向。

你的 SDD 还好吗？认知重塑篇

基于 2025 年服务智能汽车、制造业、消费、医疗等多个行业的 AI 项目实践，我们曾试图分析 AI 介入后研发效能的本质变化，并提出了一个核心观察：AI 正在彻底重构研发的时间结构。

人工智能

开发工具

职业发展

资深研发工程师王永刚分享AI时代研发效能的深刻洞察。文章指出AI编程正在重构研发时间结构，编码周期被压缩的同时，需求对齐与测试验证环节成为新瓶颈。通过英湃科技的多行业实践，揭示传统开发中"编码即打磨"的隐性认知机制在AI时代面临的挑战，并探索规范驱动开发（SDD）如何将模糊业务意图转化为确定性工程输入。文章聚焦前置上下文工程，为AI辅助开发提供实战方法论。

软件工程

软件开发

数据库

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

资深研发工程师王永刚分享AI时代研发效能的深刻洞察。文章指出AI编程正在重构研发时间结构，编码周期被压缩的同时，需求对齐与测试验证环节成为新瓶颈。通过英湃科技的多行业实践，揭示传统开发中"编码即打磨"的隐性认知机制在AI时代面临的挑战，并探索规范驱动开发（SDD）如何将模糊业务意图转化为确定性工程输入。文章聚焦前置上下...

你的 SDD 还好吗？认知重塑篇-腾讯云开发者社区-腾讯云

你的 SDD 还好吗？认知重塑篇

你的 SDD 还好吗？认知重塑篇

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐