Spec-Driven Development Backlash

What is it（这是什么）

Spec-Driven Development Backlash 指的是开发者社区对"规格驱动开发"（Spec-Driven Development，SDD）方法论的反扑情绪。SDD 的核心主张是：在 AI 编码时代，开发者应该先写详细规格（spec），再让 AI 按规格生成代码，把"写规格"当作新的核心工作。Matt Pocock 的相关视频把这个方法论推到台前，随即在 GitHub、V2EX 等社区引发争论。反对方的核心论点很直接：规格文档本身就是新的技术债，写 spec 的时间成本被严重低估，而且 AI 生成的代码与 spec 的偏差会让"规格"迅速腐化。商业意义在于：这是一个 DX（开发者体验）层的摩擦点，围绕"如何管理 AI 时代的规格与代码一致性"存在工具化空间。

Why now（为什么现在出现）

时间点由三件事叠加决定。第一，2025 年下半年到 2026 年初，Claude Code、Cursor、Codex 等 agentic 编码工具进入主流工作流，"先写 spec 再让 AI 实现"从个人实验变成团队规范，方法论争论随之而来。第二，AI 生成代码的规模上来了，团队发现 spec 与实现的漂移速度远超传统文档，维护成本开始显性化。第三，Matt Pocock 作为 TypeScript 社区高影响力教育者，其视频成为导火索，把一个分散的抱怨聚合成一个有名字的反弹浪潮。一年前 agentic 编码还没普及到团队级，讨论缺乏素材；一年后这个话题要么被工具解决、要么被吸收进主流实践，反弹窗口会收窄。2026 年 10 月首次被信号系统捕获，正处于争论刚成形的阶段。

Market Evidence（市场证据）

信号数据很薄但方向清晰：2 个独立信源（github、v2ex）、2 次提及、增长率 100%、阶段为 nascent。V2EX 是中国开发者社区里对方法论争论最敏感的地方，GitHub 侧的出现说明讨论已经落到具体仓库和 issue 层面，而不只是论坛口水。2 次提及意味着这还不是趋势，是一个"刚被命名的争论"。增长率 100% 在基数极小时没有统计意义，只能说明从 0 到 1 的跃迁已经发生。判断：这是真实的市场摩擦，但当前只是摩擦的"命名时刻"，不是需求爆发时刻。真正的需求信号要等两类事件出现——有团队公开抱怨 spec 维护成本导致回滚 SDD，或者出现专门解决 spec 漂移的开源工具并获得 star 增长。现在下注的是"争论会催生工具需求"这个二阶判断。

Who's Behind It（谁在推动）

推动方分三层。第一层是方法论倡导者：Matt Pocock 是引爆点，其视频和教程把 SDD 包装成 AI 时代的最佳实践，代表"规格优先"阵营。第二层是反弹阵营：V2EX 和 GitHub 上的实践派开发者，多为已经在团队里跑过 SDD 流程、踩过 spec 腐化坑的一线工程师，他们没有统一组织，但共识是"spec 不是免费的"。第三层是工具厂商：Cursor、Anthropic（Claude Code）、GitHub Copilot 等在产品层面隐含推动"先描述后生成"的交互范式，是这场争论的隐性庄家——他们的产品设计决定了 spec 以什么形式存在。目前没有公司专门为"反 SDD"或"spec 治理"站台，这是空白。

TAM & Market Size（市场规模）

潜在用户是全球使用 agentic 编码工具的工程团队。按 GitHub Copilot 与 Cursor 合计数百万付费开发者估算，其中真正在团队级推行 SDD 流程的比例保守取 10%-15%，即数十万开发者、数万个团队。付费意愿存在但要打折：开发者对"文档工具"的付费意愿历来低于"能省时间的执行工具"，spec 治理类产品必须证明自己能减少返工而不是增加流程。市场规模处于增长中——agentic 编码渗透率还在上升，spec 漂移问题会随代码生成量线性放大。但当前机会分 0/100、需求分 0/100 是诚实的：需求尚未被验证为可付费，现在进场是在教育市场而非收割市场。

Competitive Landscape（竞争格局）

现有玩家分两类。一类是文档与知识管理工具（Notion、Confluence、Linear 的文档功能），它们承载 spec 但不解决 spec 与代码的一致性，是"存储层"而非"治理层"。另一类是 AI 编码工具自身（Cursor 的 rules、Claude Code 的 CLAUDE.md），它们把 spec 简化为提示上下文，反而加剧了"spec 不严肃"的问题。明显的空白：没有产品做"spec 与代码漂移检测"——即持续比对规格文档与实际实现，标记偏离并生成差异报告。大公司会不会做？GitHub 和 Cursor 有动机把轻量版做进产品，窗口期估计 6-12 个月。独立开发者的差异化机会在于做深、做垂直（特定语言栈或特定合规场景），而不是做通用 spec 编辑器。竞争分 0/100 说明现在几乎没有直接对手，这是早期红利也是需求未验证的另一面。

Business Model（商业模式）

推荐订阅制 + 免费增值。理由：spec 治理是持续性工作（漂移每天发生），一次性买断不符合使用节奏；免费层用于降低"又一个流程工具"的抵触。建议定价：个人免费（单仓库、每月 50 次漂移检测）；团队版 $19/人/月（无限仓库、CI 集成、漂移报告）；企业版 $49/人/月（SSO、审计日志、合规导出）。定价依据是开发者工具的心理锚点——低于 $25/人/月属于"不用审批"区间。12 个月收入预测：保守 $3k MRR（50 个团队付费），基准 $12k MRR（200 团队），乐观 $35k MRR（含 2-3 个企业单）。用户获取成本估算：通过 GitHub Action 市场和技术博客获客，CAC 约 $40-80，回本周期 2-4 个月。关键前提是先做出可被 CI 调用的核心检测能力。

MVP Blueprint（MVP 蓝图）

核心功能只保留三件：1）连接 GitHub 仓库，读取仓库内的 spec 文件（Markdown/YAML）；2）用 LLM 对每个 spec 条目做"实现存在性检查"，输出漂移清单（缺失、部分实现、偏离）；3）生成一份可贴进 PR 的漂移报告。砍掉：编辑器 UI、多人协作、历史版本对比、自定义规则引擎。技术栈：Next.js + Vercel 部署，Postgres（Supabase）存仓库与报告，GitHub App 做仓库接入，LLM 调用用 Claude 或 GPT 的批处理接口控制成本。最快上线路径：用 GitHub App 模板起步，先只支持"手动触发检测"，不做 webhook 自动跑；用 Stripe 的 Payment Link 收钱，不做完整计费系统。预估开发天数数据为 0 不可信，实际按 5-7 天排期，第 1-2 天接入 GitHub，第 3-5 天做检测管线，第 6-7 天出报告页和收款。

Commercial Opportunities（商业化机会）

方向一：Spec Drift Detector（规格漂移检测 SaaS）。目标用户是已推行 SDD 的 10-50 人工程团队，预期月收入 $5k-15k。优于其他方向的原因是它直接命中反弹情绪的核心——不是反对 spec，而是反对 spec 失控，立场与争论双方都不冲突。

方向二：SDD 落地咨询 + 模板包。目标用户是刚引入 AI 编码、想建立流程的技术负责人，一次性收费 $500-2000/团队，预期月收入 $2k-6k。优势是零开发成本、能快速验证需求真实度，还能反哺产品方向。

方向三：CI 插件（GitHub Action）按仓库收费。目标用户是个人开发者和开源维护者，$9/仓库/月，预期月收入 $1k-4k。优势是分发靠 GitHub Marketplace 自然流量，劣势是客单价低，适合作为漏斗入口而非主营收。

Product Ideas（产品创意）

🥇 SpecGuard — 一句话：在每次 PR 里自动标出"规格说了但代码没做"和"代码做了但规格没写"的条目。目标用户是推行 SDD 的中型工程团队，场景是 code review 前的自动检查。时机对的理由：反弹情绪正盛，团队需要的是"让 spec 可维护"而不是"放弃 spec"，这个产品站在争论的解决侧。

🥈 SpecLint — 一句话：像 lint 代码一样 lint 你的规格文档，检测歧义、不可测试表述和与代码库的引用断裂。目标用户是技术写作者和平台团队，场景是文档提交前的 CI 检查。时机：spec 文档数量正在爆发，质量工具是自然下一步。

🥉 Backlash Watch — 一句话：追踪 SDD 相关社区讨论与工具动态的简报服务。目标用户是开发者工具厂商的产品经理和独立开发者，场景是每周一封趋势邮件。时机：争论刚命名，信息差最大，$5/月的简报能低成本验证整个赛道的关注度。

SEO Opportunity（SEO 机会）

搜索量趋势：上升，但基数极小，属于"术语刚被命名"的早期。有价值的长尾关键词："spec driven development 缺点"、"AI 编码 spec 维护"、"spec drift detection"、"CLAUDE.md 最佳实践"、"规格驱动开发 反方"。SEO 难度 0/100 意味着几乎无竞争，任何一篇结构清晰、有真实案例的长文都能排上去。内容策略：优先做"对比型"和"踩坑复盘型"页面——开发者搜索的是"别人怎么失败的"，而不是"方法论介绍"。在 GitHub README 和 V2EX 回帖里布关键词，比纯 SEO 更有效。

Risk Assessment（风险评估）

判断会错的情形：SDD 争论在一个季度内被工具厂商吸收（比如 Cursor 直接内置 spec 一致性检查），独立产品的空间被压扁。三大风险：技术风险——漂移检测依赖 LLM 判断，误报率高会让工具失去信任，这是最可能杀死产品的一条；市场风险——开发者对"流程工具"的天然抵触，付费转化可能远低于估算；执行风险——GitHub App 审核、LLM 调用成本控制、报告质量调优都会拖慢 5-7 天的排期。最低成本验证：先不发产品，写一篇"我们检测了 20 个开源仓库的 spec 漂移"的分析文章，看 GitHub star 和邮件订阅转化。放弃信号：文章发布 4 周内订阅少于 100，或 3 个试用团队中没有一个愿意付 $19/人/月。

Action Plan（行动建议）

第一步（今天）：在 GitHub 搜索带 spec 目录的活跃仓库，手动挑 5 个，用 Claude 跑一遍"spec 条目 vs 实现"的比对，把结果整理成一篇带数据的帖子发到 V2EX 和 Hacker News。这一步零开发，直接测试需求真实度。低成本验证：帖子下面留一个"想要自动化这个检查"的邮件收集表单。信号确认后的第二步：用 GitHub App 模板搭 MVP，只做手动触发的漂移报告，接 Stripe Payment Link。时间线：第一周完成手动检测和发帖验证；第一个月上线可用的 GitHub App 并拿到前 10 个试用团队；第三个月做到 $3k MRR 或明确放弃，把资源转向 SpecLint 这类邻近方向。

Related Terms（相关趋势）

• Spec-Driven Development — 本趋势的直接母体，反弹情绪依附于该方法论存在
• Agentic Coding — 上游驱动力，AI 生成代码规模决定了 spec 漂移问题的严重程度
• Context Engineering — 互补关系，两者都在解决"如何把意图准确传给 AI"，存在方法论竞争