一组尴尬的数字

上一个博客，前后折腾了两周多，最后留下的是这些：

  • 代码约 6.6 万行
  • 文档约 2.4 万行
  • 架构决定 92 条
  • 线上文章：2 篇

而你现在看到的这个博客，用的是 Hugo 加一个很流行的模板，基本上两三分钟就上线了。

同样是"能发文章的博客"，一个花了两周多、重构两次还没真正能用，一个两三分钟。这篇是新博客的第一篇文章，我想把中间到底错在哪讲清楚，也算给自己立个规矩。

当初想要什么

旧博客的架构长这样：

浏览器
  │
  ▼
Cloudflare Worker ── 精确路径 + HTTP 方法白名单，未列出的请求 404/405
  ├─ 静态 GET/HEAD ───────► Cloudflare Pages（Astro 构建产物；每个响应按 manifest 校验 sha256）
  ├─ /media/* GET/HEAD ───► R2（只服务 media manifest 中列出、hash 校验通过的对象）
  └─ /api/public/comments* ► 受限 Laravel API ──► PostgreSQL
                                              └► Redis ──► Horizon（队列）
后台（Filament + Livewire）：仅通过 Tailscale 内网访问
内容真相：Git 内容仓库；数据库只存可重建索引、用户、审计与工作流

一个个人博客，做成了这样。当时的目标有五个：

  1. 内容随时可迁移到无成本的静态托管平台（Markdown + frontmatter 是最终的事实源格式）
  2. 验证"单人 + 弱 Agent"高效开发 SaaS 的能力
  3. 展示 Agent 开发流的成果
  4. 展示作者的技术能力
  5. 完整的后台管理 + AI Native 能力（长期目标是 Agent 能像人一样通过 API 操作整个系统）

现在回头看，第 2 条是一切问题的根源。

一条每一步都"合理"的推导链

为什么一个博客会用上 Laravel、Octane、队列、缓存？是这么一步步推出来的：

要验证"弱 Agent 高效开发" → 全能框架能提升效率 → 但 Ruby on Rails 的元编程太多，弱 Agent 出错时不知道错在哪；Python 又太乱，我需要检查时看不懂 → PHP 能提供完整的错误输出，没有魔法 → 选 PHP 技术栈 → PHP 性能是个问题 → 上托管平台、数据库缓存、队列、常驻内存的 Octane 去优化 → 效果未知 → 做实验 → 发现性能还行

每一步单独拿出来都说得通，但不止第一步错了。

“弱 Agent 高效开发"这个出发点本身就不成立，后面会细说。“Rails 元编程让弱 Agent 不知道错在哪"也就跟着不成立了。

“需要检查时 Python 太乱看不懂"是另一个独立的错误：代码量到了几万行，我根本不会再有机会亲自去读了。有问题也是让 Agent 去读、去总结。在 Agent 面前，什么语言的代码都一样。

这两个前提一倒，“PHP 没有魔法"就没有意义了，后面那一串也就不用再推了。

实际上经历了什么

第一次重构：OpenCode

项目一开始是在 OpenCode 上做实验，验证 PHP 这套技术栈能不能达到我要的性能。那段时间一天能用掉 10 亿 token，大部分都花在实验上，有产出，但不多。实验结论是能走通，可实验出来的东西不能直接用，于是开始第一次重构。

我在 OpenCode 上跑的是一套自己写的工作流，深度嵌入 Superpowers，明确要求每一步都必须用它：

  1. 用 brainstorming 头脑风暴、定规格，中途问我几个问题；
  2. 用 writing-plans 写计划；
  3. 用 subagent-driven-development 执行，每个任务做完都要 review；
  4. 最后用 verification-before-completion 自己检查一下，差不多就上线了。

我在上面加的规则是：review 必须交给另一个系列的模型做。每个任务有好几次"机会”。一次机会里，先实现，再 review；有问题就改，改完再 review。两次 review 还不过，就进入下一次机会，交给更强的模型，比如 Claude Opus 或者 Sol。而且不是换一个写代码的模型，是直接给 reviewer 写权限让它自己改，改完再 review。这么设计是为了性价比。

最坑的地方在于：review 发现问题之后，到底谁来修，是没有定义的，交给调度者自己决定。我观察到它通常看难度：小改交给普通模型，大问题交给强模型。

这种固定编排本身就是错的。有时候 review 两次、问题差不多解决了，就应该继续往下走；有时候应该直接升级；有时候升级完反而出新问题。哪些问题必须修、哪些可以不修，写死的规则判断不了，没写死的部分又全看调度者当下怎么想。结果就是一个任务改了又 review、review 了又改，来回很多轮才能开始下一个任务，效果也不好。

第一个成果是一个静态页：不能编辑文章，也不能上传，却有上万行代码。

现在想想都不可思议，这个流程这么复杂又这么不可控，当时我却很自信地用了它。

除此之外还有这些问题：

  • 没有动态调度。一轮开三个任务，其中一个完成了、后面的任务依赖它，也得等三个全做完才能继续。某个任务失败了，它也不能马上知道。
  • 看不到真实进度。计划里有勾选框，但没有任何东西强制它去勾。OpenCode 自己的 to-do 粒度又很粗，“上线一个版本"“上线评论功能”，你根本看不到它做到哪了。
  • 不敢打断。一打断，上下文就乱了。
  • worktree 不可靠。它没有被锁在一个工作目录里，愿意听你的就待着，不愿意就跑去别的目录。

那时候用的是 Claude 20 美元的订阅，我还专门让它在规划完之后写一份 handoff 提示词，开新窗口执行，免得后面每个任务都背着规划阶段 40% 的上下文。这个技巧有点用，但解决不了根本问题。

进度太慢，我也完全掌握不了开发进展。我需要一个能动态调度任务的工具，于是转到了 Codex。

在 Codex 上接着写，然后额度耗尽

到 Codex 上没有重构，是接着写。先用 Superpowers 做发布链，然后为了解决并发和任务块太大的问题，开始用 Speckit，建了一个 68 个任务的 spec，用 Linear 跟踪，多路子代理并行。

一天之内完成了 40 个任务，200 美元套餐一周的额度用掉了 80%。

剩下 20% 的时候，我开始想办法省着用：强制子任务都用 Terra 执行。一个晚上用掉 10% 的额度，Linear 上一个任务都没完成。

最后 10%，主模型换成 Sol，执行模型 Luna、DeepSeek 都试过。还是一个任务都完成不了，光 Luna 就用掉大约 2 亿 token。

这段时间还写了大量没真正落地的代码：备份、权限、OneDrive 同步……整个项目彻底乱掉了。

第二次重构：Claude Code

转到 Claude Code，不是因为我觉得它强，而是 Codex 额度耗尽，被迫的。我想起几个月前用 Claude 20 美元的套餐，能用很久；又去社区翻了一圈帖子，普遍的说法是中重度用户更推荐 Claude Code，能跑更长、更多的任务。

用上之后才发现它是真的强。如果说 OpenCode 像一个 MVP，是一个普通的 loop 缝缝补补出来的；Codex 是一个产品；那 Claude Code 才是我觉得真正生产级的东西。这个留到下一篇细说。

9 月 16 号晚上，我在 Claude Code 里新开一个会话，用 Fable 5.1、最高推理强度，第一句话就是"将这项目彻底净化”。

它删掉了大量实验代码，把经验总结成文档，写了 AGENTS.md、宪法和架构文档，最后定了一份 roadmap，分成 A、B、C、D 四个 spec：

  • A：静态站上线
  • B：清理之前已经部署上线的实验产物，再加上生产数据的备份（包括要不要上传到 Google Cloud）
  • C：后台
  • D：还没开始。C 做完，我就停下来开始整体复盘了

回头看，Fable 这一步本身推进不了任务，但它有意义：它让我看清了问题在哪。

然后我在干净的仓库上一个一个做。每个 spec 都从零起草，再 plan、再 tasks、再执行，每个都用了八九个小时。

做到 C，后台出来了。结果它只是一个类似 mock 的东西：不能真正发布文章，样式也很糙。

A 和 B 做完的时候，后台相关的东西还一样都没有，我还心存侥幸，觉得只是最重要的功能还没上。毕竟之前很多功能都做过实验，我以为它能从旧代码里吸取经验，直接重构。实际上根本不是，基本上是从头重做。

最后我又让 Claude 看了一遍整体架构，才发现：就算把整个 roadmap 都做完，这个东西也达不到能发布的程度。

那它有什么用？

哪个前提先塌了

“SOTA 规划、弱模型执行"是个伪命题

这是最大的问题，前后付出的时间和精力最多。

当初的想法很直接：SOTA 模型的输出价格是弱模型的二十多倍（GPT-5.6 Sol 每百万输出 token 30 美元，DeepSeek V4 Flash 只要 1.32 美元），那就让 SOTA 规划、弱模型执行，成本就降下来了。我当时用的弱模型主要是 DeepSeek V4 Flash。实际上：

Token 反而更多。要让弱模型能执行，你得先把任务切得非常细，这本身就要消耗大量 SOTA 的 token。切得越细，规划越复杂，规划出错的代价也越大。为了验证弱模型做对了，还会生成大量冗余的测试代码，整个系统越来越难改。一旦任务失败，又得回到 SOTA 重新规划。Codex 最后那 10% 额度就是例子：2 亿 token 下去，一个任务都没完成。

弱模型特别费 token。在 Artificial Analysis 上，DeepSeek V4 Flash（0731）跑完整套智能指数测试输出了 2.4 亿 token，V4.1 Flash 是 2.5 亿，而所有模型的中位数只有 1.4 亿。单价便宜二十多倍，不等于完成一个任务便宜二十多倍。

榜单分数会骗人。选模型时我看了 benchmark，大家分数都差不多。后来 Artificial Analysis 把 Terminal-Bench 从 2.1 升到 4.0，测的是同样的编码能力，只是测法更严格，所有模型都大幅下降。比如 Claude Fable 5.1 从 91.4% 降到 55.1%，普遍掉了三四十分，这是正常的；但有的模型，比如 Kimi K3，从 85% 直接掉到 13%，说明它之前针对这个榜做了深度优化。

相对可靠的是激活参数。token 价格和榜单分数都可能骗人。我现在的经验是看激活参数，再对比 API 单价。激活参数大致代表每个 token 要占用多少 GPU 时间，也就是背后消耗多少能源。激活参数越大、单价却越便宜，大概率越有性价比。比如我当时用的 DeepSeek V4 Flash，总参数 284B，激活参数只有 13B；V4.1 Flash 总参数 552B，激活参数也只有 16B。总参数看着很大，每个 token 真正参与计算的却很少。然后再看它实际能完成什么任务，也留意 Artificial Analysis 上这类变化，才能发现问题。

订阅额度不等于 API 价格。在 Codex 上我踩了一个类似的坑：以为 Terra 在 API 上便宜，订阅上也会用得慢。但订阅额度大概率是按实际算力消耗扣的，不是按 API 价格。

时间成本才是最要命的。一开始我觉得并行开发，弱模型慢一点也没关系。但反复试错、冗余代码、返工，一个任务拖得越久，我花在上面的注意力就越多。时间成本几乎是指数级上升的。

Spec 写的是"模块”，不是"结果”

第二个前提是：先规划一个大架构，再用 spec 一个模块一个模块地实现。

问题在于，每个 spec 都把自己的范围定义得很窄，只管自己这一块，没有全局。“静态站上线"就只是上线，没给后面留任何东西；“做备份"就做得过重；“做一个后台、能发布文章”，在执行过程中不知不觉偏成了"能模拟走通发布流程”，而不是真的能发布。

我现在的理解是：可以一部分一部分实现，但每一部分都必须能真实验收。而验收的标准，是用户最终能看到什么。

比如评论，不应该写"上线一个评论模块，实现某某接口，做好鉴权”，而应该写：

用户可以在文章下面评论，可以回复别人的评论，可以给别人点赞，可以登录也可以匿名，可以撤回自己的发言。

就是真实的场景、真实想要的东西。至于接口和鉴权，交给 Agent。

五个目标，现在怎么看

  1. 内容可迁移：这条是对的。旧博客的 2 篇文章本来就是 Markdown + frontmatter，搬到 Hugo 几乎没成本。但当时步子迈得太大，也忽略了优先级：先发文章，比先做一个完美的项目重要得多。
  2. “单人 + 弱 Agent"开发 SaaS：伪命题，上面说完了。
  3. 展示 Agent 开发流的成果：需要展示，但不能是"做一个大的再展示”，而是"做出一点就展示一点”。别人不需要一个完美的员工，但需要了解你在想什么、你有什么潜力。
  4. 展示技术能力：有意义，但 MVP 都没做出来，什么也展示不了。先把博客搭起来、持续发开发日志，才是最有效的技术展示。
  5. 完整后台 + AI Native：有意义，但不是现在。

我学到的五件事

1. 人的注意力是最稀缺的资源。 一切规划都应该围绕"人的注意力有限"来做。一个看不到进度、不敢打断、要反复返工的流程，哪怕 token 再便宜，也是最贵的流程。

2. 有东西就尽快发布，尽快展示和分发。 以前我不是发布得慢，是发布了不分发。crawl4ai-mcp、myanyagent、evidence-search 这几个项目，当时都觉得自己是天才，太有用了，马上就发了，但没做任何推广，也没去看市场反馈。你不知道什么东西真的有用，只有放出去才知道。

3. 博客几乎是承载我价值的唯一渠道。 GitHub 同样重要，但我还没有能说服别人的高 star 项目；X 是次一级的渠道。我需要讲故事，证明自己的潜力。从这个角度看，博客下线的这段时间，我在外部视角里的价值其实是在退化的。

4. 全部用 SOTA。 SOTA 编排、弱模型执行没有意义。现在的 SOTA 已经足够高效，也足够便宜。

5. 不要钻技术栈，也不要为了迁就 Agent 放弃高效的技术栈。 当初为了让弱 Agent 看得懂，一路从 Rails 退到 PHP，再为 PHP 的性能补一堆优化，这是本末倒置。用宪法把技术栈限定下来（V2 我会限定用 Rust 这类高效的技术栈），然后就别再管技术细节了。在 spec 里写清楚"最终效果是什么样”，剩下的全权交给 Agent。

这次怎么做

新博客分两步：

MVP，就是现在这个：Hugo + PaperMod，只做最基本的文章发布。两三分钟上线，旧文章直接迁移。目标只有一个：能发文章，不挡住其他正事。

V2，之后再说：用 Speckit 按规格驱动开发，宪法限定技术栈，spec 只写最终效果，全部用 SOTA 模型。做出一点，就在这里发一篇开发日志。

这次顺序不能再反了。

接下来会写什么

  • 为什么我放弃了 OpenCode
  • 我的 AI 开发工作流迁移史：Claude Code → OpenCode → Codex → 又回到 Claude Code
  • 三个被 AI 订阅"吞掉"的自建项目

6.6 万行代码不算白写，至少换来了这篇文章。

如果你也有一个"快搭好了"的博客，我的建议是：先随便找个模板，把第一篇发出去。