从 2025 年下半年开始，我陆续在真实项目里实践 SDD（Spec-Driven Development，规格驱动开发）。其中有两个很有代表性的项目：一个是把历史悠久（Tornado + Jinja2）的某历史平台重构到当前技术栈，另一个是开发面向非研发同学、承载多种业务需求的某新平台。

这两个项目恰好代表了两种完全不同的开发场景：某历史平台是典型的棕地项目，已有业务复杂、历史约束很多，重构时最重要的是不要破坏原有逻辑；某新平台则更接近绿地项目，需要从零开始梳理需求、设计边界，并控制项目在快速演进中的复杂度。

SDD 确实解决了过去使用 AI 开发时遇到的许多问题。但随着实践深入，我也逐渐意识到：SDD 并不是写几份 spec、plan 和 tasks 文档就结束了。它真正要解决的，是如何让 AI 在长时间、跨会话、复杂代码库的开发过程中，始终理解我们的意图、遵守系统约束，并且能够证明自己的工作是正确的。

这篇文章想结合两个项目的实践，聊一聊我对 SDD 的理解、它目前的局限，以及它接下来可能演进的方向。

本文所说的 SDD，是一种以可验证规格作为开发主线的工作方式。规格不只描述需求，还应包含业务约束、非目标、验收条件和验证方式，并持续参与任务拆分、实现、审查与交付。它与 TDD、BDD、ADR/RFC、API-first 等方法并不冲突：这些方法分别提供行为验证、决策记录和接口契约，SDD 则负责把它们组织到同一条从意图到交付的主线上。

最近在 Codex 里调用 Notion 插件时遇到一个容易误判的问题：Notion 搜索失败，报错指向的却不是页面权限、数据库或查询语法，而是 Codex App 与插件 worker 之间的传输链路。

典型错误如下：

HTTP request failed: https://chatgpt.com/backend-api/wham/apps

这个报错看起来像 Notion 不可用，但从失败地址判断，请求很可能还没有进入 Notion 查询逻辑，而是卡在了 Codex / ChatGPT 的插件通道上。

后端服务接入 Sentry 或 GlitchTip 后，线上错误通常并不缺数据，真正缺的是一条稳定的排查路径：如何从 issue 进入，拿到事件详情、请求上下文、breadcrumbs 和异常栈，再回到代码里验证根因。

这次实验的重点不是 Grafana。关键证据全部来自 Sentry Skills 对 GlitchTip 事件的读取，因此这里记录一套通过 Sentry Skills 独立完成错误排查的方法。Grafana MCP 的使用可以参考 用 Grafana MCP 排查 Redis 配置问题与迭代监控。

最近借 Grafana MCP 做了两次排查。一次是定位内容采集链路里的 Redis 配置问题，另一次是从 Playwright 服务的 zombie 进程告警出发，补齐监控面板和告警规则。

这两次经历给我的感觉是，Grafana MCP 的价值不只是“让大模型能查日志”，而是把日志、指标、代码和部署配置放到同一个排查上下文里。问题不是靠猜出来的，而是沿着 task_id、trace_id、stacktrace 和 Prometheus 指标一步一步收窄出来的。

前几篇介绍了模型、Prompt、Rules、Cursor 工作模式、注意事项与项目重构. 最后一篇记录一些使用中的常见问题、仍然值得使用的扩展工具, 以及如何量化和迭代自己的 Vibe Coding 工作流.

项目重构是检验 Vibe Coding 能力的典型场景. 它不只要求模型生成新代码, 还要求模型理解旧逻辑、识别技术债务、保持业务行为并完成验证.

掌握 Prompt、Rules 和 Agent 的基本用法之后, Vibe Coding 的主要问题就不再是“AI 能不能写代码”, 而是如何让它稳定地产出符合项目实际约束的代码, 同时避免错误被快速放大.

这一篇集中记录使用过程中的注意事项与进阶技巧.

Cursor 不只是一个带聊天窗口的编辑器. 它把补全、问答、代码编辑、任务规划和工具调用放在同一个开发环境中. 用好这些模式的关键不是让 Agent 承担所有工作, 而是根据任务规模选择合适的交互方式.

上一篇介绍了 Vibe Coding 的基础: 模型、提示词与上下文. 接下来进一步了解 IDE 中一种特殊的提示词, 即 Rule.

规则的意义在于通过持久化的项目约束将 Agent 特化. 过去需要先说“你是一个 Python 专家, 精通……”, 现在可以将技术栈、代码规范和项目结构写入规则, 日常只需要描述具体任务.