当 AI 编程从个人玩具走向团队协作从一次性脚本走向持续交付 我们需要的不只是一个更强的模型而是一套完整的工程纪律。一、Vibe Coding 的甜蜜与痛苦2025 年初Andrej Karpathy 提出了一个概念——Vibe Coding。 不用写设计文档不用画架构图不用定义接口。 对着 AI 说一句帮我写一个会议室管理系统一个下午就能跑起来一个包含登录、CRUD、权限的完整后台。听起来很美。直到三个月后这就是我们说的90 天墙90-Day Wall Vibe Coding 的产出三个月后代码库进入不可维护状态。 不是 AI 不够强——问题在于信息没有结构化。二、SDD从感觉驱动到规范驱动Spec-Driven Development 的起源SDDSpecification-Driven Development并不是新概念。早在 1990 年代形式化方法Formal Methods就在航空航天、金融交易等安全关键领域使用。Z 语言、VDM、B 方法等形式化规约工具曾被用于验证伦敦地铁信号系统和巴黎地铁 14 号线的安全属性。但传统 SDD 的代价太高——写一份完整的形式化 Spec 往往比写代码本身还耗时这导致它在商业软件开发中始终未成为主流。AI 改变了这个等式。当 AI 可以在 5 分钟内从需求文档生成一份结构化的 SpecSDD 不再是成本负担而是效率杠杆。这一转变的本质是将人写 Spec → 人写代码的两段式流程重构为人确认 Spec → AI 写代码 → 人审核的三段式人机协作。从 Vibe Coding 到 Spec Coding 的必然性Vibe Coding 的核心问题是信息熵增。每次与 AI 对话都从零开始没有文档没有规范没有历史约束。代码的增长速度远超理解力的增长速度三个月后没人能说清任何一行代码为什么在那里。而 Spec Coding 的本质是把 AI 的高效从一次性对话延展到整个软件生命周期。它要解决的根本问题不是AI 能不能写出代码而是三个月后AI 还记不记得这段代码是干什么的。SDD 与主流开发方法论的定位方法论关注点主要产出SDD 与之关系TDD测试先行红-绿-重构测试用例SDD 在 TDD 之前先定义测什么BDD行为驱动Given-When-Then验收场景SDD 的 Spec 可直接映射为 BDD 场景DDD领域模型限界上下文领域模型图SDD 的 Spec 保存领域决策DDD 则建模SDD规范驱动Spec 为真结构化 Spec 文档TDD/BDD/DDD 的上游输入源SDD 不是要替代 TDD、BDD 或 DDD而是要为它们提供唯一且精确的输入。在一个 SDD 项目中Spec 定义了做什么TDD 保证做对了BDD 验证做得对DDD 建模怎么做。三条铁律的深层含义铁律含义No Spec, No Code没有规范文档不准 AI 写一行代码。Spec 是代码的准生证。目的不是增加流程而是确保每个决策都有据可查Spec is Truth文档与代码不一致时错的一定是代码。Spec 是唯一事实源。来自 NASA JPL 编码标准——代码可以重构但规范必须稳定Reverse Sync发现 Bug 或需求变更时先修文档再修代码。支持 30 分钟紧急 Hotfix 跳过但 24 小时内强制补录知识永不丢失AI-SDD 的三层意义层次传统开发Vibe CodingAI-SDD知识管理文档与代码分离逐渐过时无文档知识随对话消失Spec 即知识文档与代码同仓版本化变更履历完整可追溯上下文管理靠人脑记忆项目全貌AI 窗口爆满断片重来原子任务2K-5K tokens 精确加载按需注入规范变更管理口头沟通事后补文档直接改代码因果断裂反向同步先改 Spec 再改代码L1/L2/L3 三级冲突裁决SDD 不是让开发变慢而是让 90 天后的你感谢现在写下 Spec 的自己。三、SpecCoreAI-SDD 的工程实现SpecCore 是一套开源的 AI-SDD 工具链。它不替代 WorkBuddy / Trae / Qcoder 等 AI IDE而是在这些宿主 AI 之上提供一套规范化的研发流程。核心理念九个字宪法进规则流程进技能数据放项目。三层分治架构层级内容职责关键文件GLOBAL全局宪法层技术栈、命名规范、API 风格、异常码体系CONSTITUTION.md · INDEX.md · PATTERNS/ITERATION期次规范层需求、分析、计划、拆分——每次迭代的完整过程010-requirements/ · 020-specs/ · 030-tasks/TASK任务落地层原子任务REQ TECH TASK 自包含2K-5K tokensREQ.md · TECH.md · TASK.md六个核心优势分层清晰— GLOBAL/ITERATION/TASK 三层职责不交叉每层只管自己该管的事原子任务— 每个 Task 自包含所有上下文AI 不用加载整个项目就能精准完成任务反向同步— L1/L2/L3 三级冲突裁决代码与文档永不同步支持紧急 Hotfix模式沉淀— 每个 Feature 完成后自动提取可复用模式下次 AI 主动检索复用多端统一— 后台/H5/小程序共用一个需求文档多端联动不改多份Git 原生— 纯 Markdown YAML 驱动零运行时依赖任意 Git 平台可用四、一切走 askAI 与宿主的智能协作SpecCore 的核心设计哲学是不要让用户记命令让 AI 自己拼命令。工作流程用户在 IDE 中说分析 Q1 的任务001然后制定计划speccore ask输出知识库KB所有可用命令和模板宿主 AI 读 KB理解意图拼出两条命令展示计划给用户确认非自动模式每步必确认调用execute_command逐步执行对于复杂意图AI 还会自动拆分为多步骤管道analyze → plan → split → execute并在关键节点暂停等待用户确认。关键的改变是AI 不再猜用户要什么而是拿到精确的 Spec 后去执行。五、自动模式分级精确控制自动化范围SpecCore 的自动模式不是全有或全无。实际工作中很多时候我们希望前几步自动跑到了关键决策节点再停下来确认。模式触发词示例行为手动默认不说自动每步展示结果 → 用户确认 → 下一步部分自动“analyze 和 plan 自动execute 前确认”前两步连续执行execute 前暂停等待全自动“全自动执行” / “一键完成”所有步骤不等确认全流程自动六、按任务类型生成结构化文档十种任务类型SpecCore 定义了 10 种任务类型覆盖软件研发的完整生命周期。AI 根据不同任务类型自动生成不同集合和深度的 Spec 文档既保证关键信息不丢失又避免不必要的文档负担。类型说明示例feature新功能开发最完整的文档集合“用户登录模块”bugfix缺陷修复聚焦问题定位 回归测试“修复支付超时”refactor代码重构关注架构影响 兼容性“迁移到微服务”research技术调研输出调研结论 推荐方案“选型消息队列”review代码审查生成审查清单 问题追踪“安全审计”test测试专项完整测试计划 覆盖率目标“压测双11”docs文档编写API文档/用户手册“生成 OpenAPI 文档”deploy部署上线关注回滚方案 灰度策略“灰度发布 v2.0”security安全加固威胁建模 漏洞修复“修复 OWASP Top 10”performance性能优化压测报告 优化方案“数据库慢查询优化”任务类型 × 文档矩阵不同类型的任务AI 生成的 Spec 文档集合不同。feature 最完整7 篇bugfix 最精简2 篇任务类型文档数ANALYSISTECHTESTREVIEWRISKDEPSMONITOR说明feature7✅✅✅✅✅✅✅全量分析新功能完整交付refactor5✅✅✅✅✅--关注架构影响和回归验证bugfix3✅✅✅----问题定位修复方案回归research2✅------调研结论和推荐方案review2---✅✅--审查清单和风险项test2--✅-✅--测试计划和风险覆盖docs1-------目标文档直接生成deploy5✅✅--✅✅✅部署计划风险依赖监控security4✅-✅✅✅--威胁分析验证审查风险performance4✅✅✅---✅性能画像方案验证监控七种 Spec 文档详解文档定位包含内容对谁有用ANALYSIS.md需求分析报告功能点列表含优先级、接口清单方法路径入参出参、数据模型 ER 图、业务规则状态流转图、异常处理矩阵PM · 架构师 · 后端TECH.md技术方案系统架构图、数据库 DDLCREATE TABLE 含索引、API 设计OpenAPI 3.0 片段、缓存策略Redis Key 设计 过期时间、核心时序图架构师 · 后端 · DBATEST.md测试计划单元测试用例表输入预期输出、集成测试场景、边界测试矩阵空值/超长/并发/超时、性能测试方案QPS 目标压测脚本QA · 后端 · 前端REVIEW.md审查清单安全检查SQL注入/XSS/CSRF/鉴权绕过、代码质量参数校验幂等性索引覆盖事务边界、部署检查迁移脚本可回滚灰度方案Tech Lead · 安全RISK.md风险评估风险矩阵可能性×影响×缓解措施、回滚方案触发条件步骤验证方法、关键路径分析阻塞点备选方案PM · Tech LeadDEPS.md依赖清单上游依赖服务名版本用途SLA、下游影响分析消费方接口影响程度、第三方 SDK 清单许可证漏洞等级架构师 · SREMONITOR.md监控指标业务指标成功率/延迟/吞吐量阈值P级别、告警规则触发条件通知渠道升级策略、大盘看板Grafana 面板定义SRE · 运维 · on-call不是每类任务都需要全部 7 个文档。SpecCore 的理念是该有的一个不少不该有的一个不多——feature 走全套bugfix 只关心问题定位和回归。七、多项目管理从单兵到军团SpecCore 的 GLOBAL 层是跨项目的知识枢纽.speccore/ GLOBAL/ CONSTITUTION.md # 所有项目共享的技术宪法 INDEX.md # 需求跨项目目录 PATTERNS/ # 经验模式库只增不减 ITERATIONS/ Iteration-008-meeting-system/ # 会议室系统 Iteration-003-payment/ # 支付系统每个 Feature 完成后AI 会自动总结可复用模式写入 PATTERNS下次遇到类似场景会说“这个登录功能我们之前做过上次踩了 Redis 超时的坑这次我帮你加上重试机制和降级策略。”八、实战数据在一个会议室管理系统4 个端、30 API、7 张数据表的完整开发中指标Vibe CodingSpecCore SDD分析报告无7 个 Spec 文档 ER 图 SQL任务拆分手动 30 分钟AI 自动拆分上下文 tokens15K-20K / 次2K-5K / 次需求变更追踪不可追踪反向同步 变更履历全记录团队接手成本数天阅读代码读 Spec 文档即可理解九、适用场景强烈推荐不推荐多端项目后台 H5 小程序一次性脚本 / 原型验证团队协作3 人以上单人玩具项目长期维护项目预期 6 个月以上极短期项目2 周内交付企业级项目有合规/安全要求需要知识沉淀的研发团队十、快速上手# CLI 命令npminstall-gspeccore# CLI命令speccore init# CLI命令/spec-ask 创建会议室管理系统的第一个迭代# AI命令 在AI对话框中输入在 WorkBuddy / Trae / Qcoder 等 IDE 中只需在对话中 speccore 、/spec:ask 或使用 /spec-ask 命令。一个典型的工作流对话用户/spec-ask 分析 Q1 的所有需求拆分任务分析计划自动执行开发前让我确认AI我将执行step1-2 自动analyze planstep3execute前暂停确认。是否开始用户开始→ AI 自动完成分析和计划生成 7 个 Spec 文档然后在执行前问继续十一、开源与社区SpecCore 完全开源MIT 协议GitHub: github.com/windfallsheng/SpecCore-tsGitee: gitee.com/windfullsheng/spec-core-ts写在最后Vibe Coding 不会消失——原型阶段它依然是无敌的。但当项目进入第 2 个月、第 3 个迭代、第 5 个开发者加入时Spec Coding 是唯一的解法。不是让 AI 少干活而是让 AI干对活、把活干完、把知识留下。No Spec, No Code.
