World entries
Balance
技术 与 生活
Recent finds
Epiphany
一些灵感
从 GitHub Pages 到 Cloudflare Pages：一次静态博客部署迁移
这次把博客的部署链路从 GitHub Pages 迁到了 Cloudflare Pages。 说是从 GitHub 迁移到 Cloudflare，其实更准确的说法是：GitHub 继续作为代码仓库和触发源，真正负责构建、发布、域名接入、缓存和 TLS 的部分交给 Cloudflare Pages。这样一来，GitHub 不再承担静态站点托管的职责，而是回到它更擅长的位置：保存源码、记录变更、触发部署。 这篇记录一下迁移的背景、具体改动、部署时踩到的坑，以及迁移之后能得到什么好处。
- Published on
关于 SDD 的一些分享
从 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
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
用 Sentry Skills 完成一次线上错误排查
后端服务接入 Sentry 或 GlitchTip 后，线上错误通常并不缺数据，真正缺的是一条稳定的排查路径：如何从 issue 进入，拿到事件详情、请求上下文、breadcrumbs 和异常栈，再回到代码里验证根因。 这次实验的重点不是 Grafana。关键证据全部来自 Sentry Skills 对 GlitchTip 事件的读取，因此这里记录一套通过 Sentry Skills 独立完成错误排查的方法。Grafana MCP 的使用可以参考 用 Grafana MCP 排查 Redis 配置问题与迭代监控。
- Published on
Latest articles
Journal
我的冒险日志
