跬步 On Coding

在AI时代，我终于了却了那个离开鹅厂时的PaaS执念

Sep 3 2026

一晃到了 2026 年的 9 月初。

坐在珠海的办公室里，翻看着终端里的会话统计数据，才猛然发觉这大半年过得有多魔幻。如果在 2024 年底我刚开始折腾 Cursor 的时候，有人跟我说：“老朱，再过一年半，你自己基本上不用动手写代码了，一个人一个星期就能把一个分布式 PaaS 平台从零拉起来”，我大概率会觉得他在扯淡。

但翻开后台的数据，现实就是这么冷冰冰又热腾腾地摆在面前：从 6 月初到现在，仅仅 3 个月的时间，我本机加远程两台机器，跑了 1400 多个 Coding Agent 会话，消耗了超过 60 亿 的 Token。

这大半年里，我的主力工具从 Cursor 全面切到了 Pi，硬啃了无数国产模型的坑，把以前写得臃肿的 Agent 工作流砍到只剩骨架，甚至顺手做完了当年离开鹅厂时埋在心底的一个夙愿。

今天有些空闲，就按照惯例，絮絮叨叨地复盘一下这半年的折腾历程。

一、 工具链迁徙：为什么我从 Cursor 跳船到了 Pi？

熟悉我的朋友都知道，去年在金山办公，我已经全面进入了以 Cursor 为主的 Vibe Coding 模式。但到了今年 6 月底，事情起了一些变化。

首先是公司的政策调整，AI 网关提供的 Coding Plan 开始主推国产模型。当时 Cursor 对国产模型的支持以及按 Token 计费的模式，用起来让人非常肉疼；加上后来我尝试用了一阵子 Opencode，但在配合公司网关时，配置极其不灵活，动不动就长连接中断且死活找不到原因，写自定义扩展更是痛苦。

6 月底的时候，Pi 在 X (Twitter) 上爆火。我看了一眼它的扩展设计，果断选择跳船。事实证明，这次跳船是我今年做过的最正确的决定之一。

为什么选 Pi？核心就两点：极度轻量 与 可编程性。

面对各家模型参差不齐的接口特性，Pi 允许我根据不同的模型定制配置参数。更关键的是它的扩展机制，让我能像写普通脚本一样写插件。这几个月下来，我给 Pi 攒了一套趁手的扩展，全部开源在 zhu327/pi：

.pi/agent/
├── APPEND_SYSTEM.md       # 针对文件发现与编辑可靠性的底层提示词
└── extensions/            # 自定义扩展
    ├── question.ts        # 结构化多问题 UI（支持 chips、多选、交互预览）
    ├── token-rate.ts       # 终端实时看吞吐速度（tok/s）
    ├── todo.ts            # 四状态任务看板 + overlay widget（/todos）
    ├── web-fetch.ts       # 网页抓取直接转 Markdown，带 SSRF 防护
    └── win-notify.ts      # 切出终端后台跑完时的系统气泡通知

另外，社区基于 Claude Code 风格打造的 @gotgenes/pi-subagents，让 Pi 在隔离会话中并行起任务变得极爽。

但凡用过开源 Agent 框架接三方模型的人都知道，最恶心的就是 Tool Call 兼容性。同一种工具调用协议，在 A 模型上跑得飞起，在 B 模型上可能就疯狂抛格式错误。

我是怎么解决的？让 Agent 查自己的 Bug。

Pi 会把每次会话记录完整存下来。当某个工具在特定模型下频繁报错时，我就直接把会话历史塞给 Pi，让它自己去分析报错原因，然后反手修改对应的 TypeScript 扩展代码。通过这种“自己调试自己”的螺旋进化，这套工具链在不同模型间的颠簸被我一点点抹平，用得越来越顺手。

二、 60 亿 Token 的洗礼：国产模型从“拉”到“夯”

拉了一下 6 月到 9 月这 3 个月的后台统计：

  • 会话总数：1,413 个
  • Assistant 交互消息：~5.67 万条
  • 总 Token：~6.19 B（当然，长上下文 Cache 占了 93.5% 左右，实际新输入没这么夸张）
排名 模型 消息数 Total Tokens 占比
1 glm-5.3 8,854 1,209.3M 19.5%
2 deepseek-v4-pro-0813 5,679 1,135.0M 18.3%
3 gpt-5.6-sol 8,081 909.9M 14.7%
4 deepseek-v4-flash-0731 4,085 587.0M 9.5%
5 qwen3.7-max 6,614 390.1M 6.3%

这组数据不仅见证了我的高强度开发，更直观记录了这三个月国产大模型的突飞猛进：

  1. 6 月初到中旬：主要是探索期，用着 DeepSeek-v4 系列早期版和 Qwen3.7，此时国产模型写复杂工程还是会经常犯迷糊，如果说 7 月前的体验跟 Cursor 里的前沿模型比还有档次差距；
  2. 7 月到 8 月中：GLM-5 系列和 DeepSeek 0813 的推出彻底改写了局面。模型对代码架构的理解和长上下文指令遵循大幅提升，配合针对性的引导（比如用 pi-dsh-minimal 引导 DeepSeek 进入 We need… / I need… 思考模式），推理表现极其强悍；
  3. 8 月底至今：我和远程服务器火力全开，单日经常跑出几百兆 Token。国产模型不仅在性能上跟外部顶尖模型平起平坐，甚至在长代码审查和高并发重构下，性价比完全碾压。

三、 极致瘦身：少即是多的开发流重构

在上一篇写 Loop Engineering 的博客里，我曾探索过一套相对严密的 Prompt 和 Skill 流程。但随着两边工具都走向 Token 计费，加上模型本身的基座能力越来越强——很多以前需要写在外部 Skill 里的开发常识，现在的模型参数里早就吃透了——以前那一套重型工程，反而变成了累赘。

为了省 Token，更是为了去除不必要的摩擦，我开始给开发流程做减法。

这套最新的理念落在了开源模板 zhu327/go-clean-arch 里面。没有花里胡哨的复杂链条，全靠一个 AGENTS.md、4 个精简的 Skill，以及 2 个专注的 Subagent 驱动：

1. 架构宪章：AGENTS.md

给项目定下绝对不可动摇的边界：

  • 领域与分层（Domain -> Usecase -> Adapter，严格向内依赖）。
  • 绝不手工改生成代码（wire_gen.go、mocks、Swagger），违者必须从源头重新生成。
  • 设定了明确的“验证阶梯（Verification Ladder）”：改了逻辑先写红灯用例再修代码，改了外部协议必须跑 make e2e。

2. 精炼后的 4 个 Skill

  • code-review-expert：只遵循“症状 -> 后果 -> 补救措施”三要素。没有后果就是噪音，没有补救方案就是抱怨。追求“Code Judo（代码柔道）”——能通过删除复杂度解决的，绝不通过堆砌抽象来掩盖。
  • grill-me：在设计方案存在重大分歧或高风险时开启。像一个严苛的架构师一样跟我对齐边界，只问 material decision，一旦形成 Handover 就不再反复拉扯。
  • plan-execute：只针对跨层或高危变更，把活切成纵向切片（Vertical Slice），按波次（Wave）推进。
  • improve-codebase-architecture：只在需要全局重构时手动触发，利用“删除测试”寻找那些食之无味弃之可惜的浅层模块。

3. 两个极简角色

  • code-reviewer：只读不改，专挑架构走样、逻辑空洞和边界泄露。
  • code-simplifier：绝不发散，在保持既有外在行为不变的前提下，专门负责把 AI 吐出来的冗长嵌套和面条逻辑拍平。

这套流最舒服的地方在于：不再需要人肉去判断什么时候调什么 Skill，模型根据任务复杂度和文件边界自己决定。 人退到后面，负责定边界和做裁决。

回顾这大半年的编码心路：

  • 最开始：不信任 Agent，每一行代码都要人肉过目才敢合入；
  • 中期：自己退出来只管出方案，安排模型之间交叉 Review；
  • 现在：我只负责跟 Agent 把需求和边界磨清楚，剩下的实现、校验、单测、对齐，全权交给 Agent 自己搞定。

四、 治愈执念：一个人、一个星期，做完一套 Firecracker PaaS

放下了写具体语法的包袱，我终于敢去碰一些以前一直想做却不敢涉足的领域。

以前在腾讯 IEG，虽然身处 PaaS 平台组，但由于各种分工限制，我并没有真正从底层写过一套完整的 PaaS 调度面。这些年我一直是 Fly.io 的重度拥趸，打心眼里喜欢他们基于轻量级虚拟机 Firecracker 搭建的那套极速启停的平台架构。

但这一套工程量太浩大了。Firecracker 生态在开源界一直比较分散，要把 Docker 镜像剥开转成 rootfs，还要管虚拟机的生命周期，再加上跨节点的调度网络……以往在团队里，这种规模的项目没三四个资深工程师死磕小半年，根本别想看到可运行的原型。所以这个念想在脑子里落了灰，一放就是好几年。

直到今年，我在刷 X 时注意到了两个关键拼图：

  1. kernel/hypeman：它能直接把普通 Docker 镜像解包并转化为虚拟机所需的 rootfs，天然就是一个绝佳的 MicroVM Runtime。
  2. e2b-dev/infra：现在 AI Agent 跑沙箱（Sandbox）的标杆。他们基于 Nomad 做底层机器生命周期管理，而在虚拟机调度层面吸收了 Kubernetes 的 Reconcile 思想。

底层的思路一下子全串通了。借着 Agent 的产能杠杆，我用了一周时间，把这套平台给手搓了出来：zhu327/firepaas。

一个简化的 K8s-style 控制面，结合了 Firecracker 的高密度隔离，既是一个轻量 PaaS，也是一个面向 AI Sandbox / Serverless 的运行基座。从看懂参考项目、敲定方案，到代码落地、搭仿真集群验证，一个人，7 天搞定。

在调试容器网桥和虚拟网卡通信的那个深夜，看着终端里秒级弹出的虚拟机，心里百感交集。写代码这门手艺，在某种纯粹的生产力层面上，大模型确实已经超越我了。

顺带着，这几个月我还完成了两块重要的拼图：

  • zhu327/pingsix：之前用 Rust 写的一个 API 网关玩具。在大模型的反复 Review、边缘 Case 爆破和重构下，被硬生生拉扯到了具备生产可用度的状态。
  • zhu327/tfengine：一个完全由 Agent 生成交付的 Terraform Engine。

至此，由 PaaS、网关、IaC 构成的平台基础设施矩阵，在我手里算是拼齐了。当年离开鹅厂时心里那点未竟的遗憾，终于在 2026 年的夏天画上了一个圆满的句号。

五、 边际成本归零之后：我对 Serverless 的新思考

在摆弄微服务和容器这么多年后，我越来越喜欢 Cloudflare 的设计哲学。

传统的容器方案或者 Firecracker 尽管隔离性极佳，但冷启动和资源消耗在很多极简场景下依然显得太“重”。Cloudflare 基于 V8 Isolate 搞出的 Workers，通过极度轻量的执行沙箱配合 Durable Objects，把有状态和无状态的边界打碎了。他们甚至在 DO 上做了虚拟文件系统，天然就可以作为一个极致轻巧的 Agent 运行沙箱。

很多人诟病 Cloudflare Workers：“只能写 JS/Wasm，一旦绑死就很难迁移出去。”

如果放在以前，这确实是个致命的工程锁死问题。但我现在完全不在意了——因为在 Coding Agent 普及的当下，代码翻译和重写的边际成本已经无限趋近于零。

我不懂 TypeScript，但这丝毫不影响我指挥 Agent 把几个轻量服务重写并丢到 Workers 上稳定跑着：

退一万步说，就算未来不想用 Cloudflare，开源社区也早有人填平了退路。比如最近发现的 denoland/celld，它用 Rust 和 V8 引擎构建，完全兼容 Cloudflare Workers API，并且底层还集成我非常欣赏的 Litestream LTX 技术来做持久化。你想私有化部署，拉起来就是一个独立可控的 Edge Runtime。

技术选型的逻辑，在这一刻彻底变了：不要去畏惧框架的专有性，只要抽象足够先进、运行效率足够高，转换的脏活累活丢给模型去做就好。

总结

坐在 2026 年的秋天往回看，这九个月的变化比我过去五年经历的都要剧烈。

作为一名非科班出身、做了十几年后端的老兵，从最初手动写单测、到搞懂架构设计、到在大厂里卷各种流程，我曾经以为程序员最核心的壁垒是那些对复杂系统细节的记忆力，以及熬夜 Debug 的耐力。

但现在，当单月几十亿 Token 的吞吐从指缝间滑过，我更加笃信：

  1. 软件工程的核心从“编码”变成了“审美”与“约束”。 模型写得再快，给不了清晰的边界规则（像 AGENTS.md 里的分层约束），它产出的也不过是效率更高的屎山。
  2. 永远不要被自己的技能树所绑架。 不要因为自己是写 Python 或 Go 出身的，就对 Rust 或 TypeScript 望而却步；也不要因为害怕一个平台生态闭门，而放弃最优雅的计算方案。
  3. 把不切实际的执念，化作可交付的代码。 换作三年前，我绝不敢想象自己一个人能把完整的 PaaS 调度链路从底层写一遍。但既然时代给了我们这种单兵成军的杠杆，为什么不去把当年吹过的牛、留过的遗憾，一个一个给填平呢？

系统偶尔会报 500，网络偶尔会丢包，但只要你的 Reconcile 循环还在 Run，环境总会收敛到你想要的终态。

继续保持学习，继续折腾。