从 2025 年下半年开始，我陆续在真实项目里实践 SDD（Spec-Driven Development，规格驱动开发）。其中有两个很有代表性的项目：一个是把历史悠久（Tornado + Jinja2）的某历史平台重构到当前技术栈，另一个是开发面向非研发同学、承载多种业务需求的某新平台。这两个项目恰好代表了两种完全不同的开发场景：某历史平台是典型的棕地项目，已有业务复杂、历史约束很多，重构时最重要的是不要破坏原有逻辑；某新平台则更接近绿地项目，需要从零开始梳理需求、设计边界，并控制项目在快速演进中的复杂度。 SDD 确实解决了过去使用 AI 开发时遇到的许多问题。但随着实践深入，我也逐渐意识到：SDD 并不是写几份 spec、plan 和 tasks 文档就结束了。它真正要解决的，是如何让 AI 在长时间、跨会话、复杂代码库的开发过程中，始终理解我们的意图、遵守系统约束，并且能够证明自己的工作是正确的。这篇文章想结合两个项目的实践，聊一聊我对 SDD 的理解、它目前的局限，以及它接下来可能演进的方向。本文所说的 SDD，是一种以可验证规格作为开发主线的工作方式。规格不只描述需求，还应包含业务约束、非目标、验收条件和验证方式，并持续参与任务拆分、实现、审查与交付。它与 TDD、BDD、ADR/RFC、API-first 等方法并不冲突：这些方法分别提供行为验证、决策记录和接口契约，SDD 则负责把它们组织到同一条从意图到交付的主线上。

Published on: 2026-06-15

ARTICLE

Codex 调用 Notion 失败：从 wham/apps 报错定位网络链路

最近在 Codex 里调用 Notion 插件时遇到一个容易误判的问题：Notion 搜索失败，报错指向的却不是页面权限、数据库或查询语法，而是 Codex App 与插件 worker 之间的传输链路。典型错误如下： textHTTP request failed: https://chatgpt.com/backend-api/wham/apps 这个报错看起来像 Notion 不可用，但从失败地址判断，请求很可能还没有进入 Notion 查询逻辑，而是卡在了 Codex / ChatGPT 的插件通道上。

Published on: 2026-06-10

ARTICLE

用 Sentry Skills 完成一次线上错误排查

后端服务接入 Sentry 或 GlitchTip 后，线上错误通常并不缺数据，真正缺的是一条稳定的排查路径：如何从 issue 进入，拿到事件详情、请求上下文、breadcrumbs 和异常栈，再回到代码里验证根因。这次实验的重点不是 Grafana。关键证据全部来自 Sentry Skills 对 GlitchTip 事件的读取，因此这里记录一套通过 Sentry Skills 独立完成错误排查的方法。Grafana MCP 的使用可以参考用 Grafana MCP 排查 Redis 配置问题与迭代监控。

Published on: 2026-05-20

ARTICLE

用 Grafana MCP 排查 Redis 配置问题与迭代监控

最近借 Grafana MCP 做了两次排查。一次是定位内容采集链路里的 Redis 配置问题，另一次是从 Playwright 服务的 zombie 进程告警出发，补齐监控面板和告警规则。这两次经历给我的感觉是，Grafana MCP 的价值不只是“让大模型能查日志”，而是把日志、指标、代码和部署配置放到同一个排查上下文里。问题不是靠猜出来的，而是沿着 task_id、trace_id、stacktrace 和 Prometheus 指标一步一步收窄出来的。

Published on: 2026-05-20

Journal

我的冒险日志

开发关于 SDD 的一些分享

Published on: 2026-06-15

开发Codex 调用 Notion 失败：从 wham/apps 报错定位网络链路

Published on: 2026-06-10

开发用 Sentry Skills 完成一次线上错误排查

Published on: 2026-05-20

开发用 Grafana MCP 排查 Redis 配置问题与迭代监控

Published on: 2026-05-20

开发Vibe coding - 常见问题、工具扩展与持续迭代

Published on: 2026-03-04