Go - Tony Bai

标签 Go 下的文章

别读代码了，看着它流过就行：ClawdBot 作者的 AI 开发工作流

一月 28, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/01/28/clawdbot-author-ai-development-workflow

大家好，我是Tony Bai。

在过去的一年里，我们见证了 AI 编程工具的井喷。从 Copilot 到 Cursor，从 Windsurf 到 Claude Code、Gemini CLI和Codex，每个人都在寻找那个“完美的开发助手”。

最近，爆火的个人AI助理开源项目 ClawdBot 和 PSPDFKit 的创始人 Peter Steinberger 发布了一系列关于他AI 开发工作流的深度博文。他以一种近乎“未来主义”的视角，描述了一个令传统程序员既兴奋又恐惧的景象：

“I stopped reading code and started watching it stream by.”
（我不再读代码了，我只是看着它流过。）

这可真不是一句狂言，而是一种全新的且现实可行的工程范式。

当 AI 的可靠性达到临界点，软件交付的速度不再受限于人类的打字速度，而是受限于模型的推理速度（Inference Speed）。

今天，我们结合 Peter 的最新实践，为你拆解这套“以人为核心、AI 为手脚”的顶级开发工作流。

质变时刻：学会了“深思熟虑”的模型+工具链的“极简回归”

根据 Peter 的观察，真正的质变发生在 GPT-5.2 这一代模型发布之后。

早期的模型（如 Claude 3.5 Sonnet），虽然聪明但急躁，往往“顾头不顾腚”。而新一代的 Codex 模型学会了“沉默”。

在面对一个复杂的重构任务时，模型可能会静默阅读代码长达 10 到 15 分钟，一言不发。这种“Think before Act”的特性，让它能够构建出极其完整的上下文图谱。结果就是：它能一次性（One-shot）搞定跨越数十个文件的大型重构，且几乎零 Bug。

这也宣告了 Plan Mode（规划模式）的消亡。以前我们需要强制 AI 先写计划再写代码，那是为了给旧模型的智商打补丁。现在，开发者可以直接与 AI 对话，像与一位资深架构师协作一样流畅。

此外，在尝试了市面上几乎所有工具（VS Code, Zed, Cursor, Gemini）之后，Peter 最终回归了一套极简的组合：
Ghostty + Claude Code + Minimal Tooling。

为什么？因为 “Less is More”。

终端的复兴： 他抛弃了不稳定的 VS Code 终端，全面回归 Ghostty。因为在 AI 时代，终端才是最纯粹的交互界面。
屏幕即战场： 他使用 Dell 40寸带鱼屏（3840×1620），同时平铺 4 个 Claude 实例 + Chrome。他不需要切换窗口，他像监控仪表盘一样监控着 4 个并发任务的进展。
摒弃复杂 MCP： 他甚至反主流地删除了大部分 MCP（Model Context Protocol）。因为 AI 有时候会自作聪明地启动 Playwright 去抓取网页，而直接读取代码反而更快、更准、更省 Token。

Peter的这些实践告诉我们：不要被花哨的工具迷了眼。一个稳定、高性能的终端，加上一个聪明的 CLI Agent，就是最强大的武器。

像工厂一样生产：并行工程学

当“写代码”不再占用人类的脑力带宽时，Peter 的工作方式从“工匠”变成了“工厂厂长”。

并行处理 (Parallel Processing)

他通常同时推进 3 到 8 个项目。

窗口 1：重构后端架构；
窗口 2：优化前端交互；
窗口 3：跑全链路测试。

开发者只需要在这些 Session 之间切换，确认结果，给出下一个指令。

线性推进，绝不回滚 (Never Revert)

“软件开发就像登山，走错路了就绕回来，而不是读档重来。”

他几乎不再使用 git reset。如果 AI 写歪了，直接告诉它“换个思路”，它会在现有基础上自我修正。甚至连 Plan Mode（规划模式） 都变得不再必要，就像前面提到的，新一代模型（GPT-5.2等）学会了“深思熟虑”，能一次性搞定复杂重构。

跨项目“抄作业” (Cross-Referencing)

代码复用从未如此简单。他不再写 Prompt 描述需求，而是直接说：

“Look at ../vibetunnel project, and implement the same logging system here.”

AI 会自动跨目录读取代码，提炼模式，并完美适配到当前项目。

基础设施的重构：CLI First

为了配合这种极速开发，Peter 彻底重构了他的技术栈选择逻辑。

拥抱 CLI (Command Line Interface)

“Whatever you build, start with a CLI.”

无论做什么 App，先做 CLI 版本。因为 Agent 调用 CLI 最方便，测试 CLI 最容易。GUI 只是 CLI 的一层皮。只要内核跑通了，让 AI 套个 React 壳只是分分钟的事。

Oracle（预言机）

当 Agent 遇到知识盲区（比如最新的 API 变动）时，它会自动调用 Oracle ——一个Peter开源实现的、联网的、专门负责爬取文档并总结答案的“元智能体”。知识获取的闭环，彻底自动化了。

文档驱动 (Docs-Driven)

他不再维护复杂的 Prompt 库，而是维护项目的 docs/ 目录。

想规范 AI 的行为？写一个 docs/architecture.md。

想让 AI 学会用 Vercel？在 CLAUDE.md 里加一行：logs: axiom or vercel cli。

文档，就是 AI 的“长期记忆”和“员工手册”。

给开发者的启示：核心竞争力迁移

在 Peter 的工作流中，我们看到了程序员核心竞争力的转移：

系统设计 (System Design) 是王道：
当前的 AI 搞不定分布式系统设计，搞不定数据库 Schema 的前瞻性规划。这些“硬骨头”，才是人类的领地。
选择 AI 友好的生态：
TypeScript (Web), Go (CLI), Swift (App)，这三者是 AI 掌握得最好的。Peter 特别提到了 Go——以前他并不感冒，但后来发现 AI 写 Go 写得极好。为什么？因为 Go 简单的类型系统让 Lint 检查极快，AI 能迅速修正错误。相比之下，那些类型系统过于复杂或编译检查极其严格的语言，可能会增加 AI“一次做对”的难度，拖慢你的推理速度。
自动化一切 (Automate Everything)：
不要手动注册域名，写个 Skill 让 AI 去做。不要手动发推特，写个 CLI 让 AI 去发。为你自己，也为你的 AI 员工，构建大量的自定义基建。

小结：享受创造

有人担心 AI 会让程序员失业，但 Peter 的实录告诉我们：这可能是程序员最好的时代。

在这个时代，限制你产出的不再是你的手速，也不再是你对某个库的熟悉程度，而仅仅是你的想象力。

当你可以以推理速度交付软件，当你看着代码像瀑布一样流过屏幕时，编程就不再是枯燥的搬砖，而是一场纯粹的、创造性的游戏。

资料链接：

https://steipete.me/posts/2025/optimal-ai-development-workflow
https://steipete.me/posts/2025/shipping-at-inference-speed

你的“未来工作流”

Peter 的工作流让我们看到了未来的一角。你敢想象自己“不再读代码”的那一天吗？在你的理想中，AI 应该帮你接管哪些“脏活累活”，让你能专注于更高维度的创造？

欢迎在评论区分享你的脑洞或对未来的担忧！让我们一起定义属于自己的 AI 工作流。

如果这篇文章点燃了你对 AI 编程的全新想象，别忘了点个【赞】和【在看】，并转发给你的极客朋友，邀请他们一起见证未来！

还在为“复制粘贴喂AI”而烦恼？

Peter 描述的“看着代码流过”的未来并非遥不可及。我的新专栏 《AI原生开发工作流实战》 将带你提前掌握这套高效范式：

告别低效： 摒弃“聊天式编程”，重塑以文档和 CLI 为核心的开发范式。
驾驭 Agent： 深入实战 Claude Code，像 Peter 一样构建自动化工作流。
角色进化： 从“手动写代码”进化为“规范驱动开发”的工作流指挥家。

扫描下方二维码，开启你的 AI 原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

TypeScript 编译器 Go 重写版提速 10 倍：微软团队深度揭秘幕后工程细节

一月 27, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/01/27/typescript-compiler-go-rewrite-10x-speed-microsoft-details

大家好，我是Tony Bai。

“JavaScript 是一门很棒的语言，但它并不是为了编写编译器而设计的。”

备受瞩目的 TypeScript 编译器 Go 重写版（代号 TypeScript 7.0）已经取得了惊人的 10 倍性能提升。在最近的 GopherCon 2025 上，来自 Microsoft TypeScript 团队的 Jake Bailey 带来了一场干货满满的分享，深度揭秘了这场跨语言大迁徙背后的工程挑战与技术细节。

为什么最终选择了 Go？庞大的 AST 如何在 Go 中高效表达？又是如何通过并发设计打破 Node.js 的性能枷锁的？本文将带你深入编译器内部，一探究竟。

img{512x368}

缘起：当 JavaScript 触碰到天花板

TypeScript 自 2012 年发布以来，一直采用“自举” (Self-hosting) 的方式，即用 TypeScript 编写 TypeScript 编译器。这带来了巨大的好处：团队能第一时间吃自己的狗粮，社区贡献也极其方便。

然而，JavaScript 并不是为了编写高性能编译器而设计的。随着代码库规模的爆炸式增长（如 VS Code 的 150 万行代码），基于 Node.js 的编译器逐渐触碰到了性能天花板：

单线程与内存限制：JavaScript 无法高效利用多核 CPU，且 Node.js 构建环境（如 Electron）常常面临 4GB 内存上限，导致大型项目编译时频繁 OOM。
昂贵的对象模型：JavaScript 的对象模型开销巨大，而编译器需要创建数以百万计的 AST 节点，这对内存和 GC 都是沉重的负担。
异步的代价：async/await 虽然方便，但带来了著名的“函数着色”问题，且 Promise 对象的分配本身就有非零的运行时开销。

尽管团队已经用尽了 JIT 优化、缓存、单态化 (monomorphization) 等高级手段，但性能提升的边际效应越来越小，OOM 问题依然挥之不去。移植到另外一种语言，成为了打破僵局的唯一选择。

明确目标：新编译器的硬性指标

既然决定要移植到新语言，那么新语言必须解决 JavaScript 的痛点，同时不能丢失现有的优势。团队列出了几条不可妥协的硬性指标：

极致速度：必须编译为原生机器码 (Native Code)，摆脱解释器和 JIT 的预热开销。
共享内存并发：这是性能翻盘的关键。新语言必须对多线程共享内存有强力支持，以便充分压榨多核性能。
跨平台支持：必须能运行在所有主流操作系统上，最重要的是——必须能编译为 WebAssembly，以确保在浏览器环境（如 vscode.dev）中的体验。
无缝移植：鉴于 TypeScript 没有正式的语言规范（Spec），现有的编译器实现就是事实上的规范。因此，新语言必须能够最大程度地保留原有代码的结构和逻辑，以确保行为的一致性。

正是这几条苛刻的标准，将选型的范围迅速缩小。

选型：为什么是 Go？

在考察了 Rust、C#、Zig 等语言后，Go 脱颖而出。Jake 透露了核心的决策逻辑：

带 GC 的内存管理：编译器涉及大量复杂的、循环引用的数据结构（如 AST 节点），“手动”管理内存（如 Rust）会带来巨大的心智负担和开发成本。Go 的 GC 完美契合这一需求。
结构相似性：TypeScript 的代码风格（无类、大量函数和接口）与 Go 非常相似。这使得“移植”而非“重写”成为可能。
学习曲线平缓：团队中大部分是 TypeScript 专家而非系统编程专家。Go 的简单性让团队能迅速上手。
跨平台与性能：Go 编译为原生机器码，天生支持高并发，且能轻松跨平台（包括编译为 WASM）。

Go完美地契合了TypeScript编译器移植的需求！

早期验证：手写原型与意外惊喜

在决定全面转向 Go 之前，团队并未贸然行动，而是采取了稳健的“原型验证”策略。

他们从编译器的最底层——扫描器 (Scanner) 和解析器 (Parser)——开始，尝试手工将 TypeScript 代码逐行“翻译”为 Go 代码。与此同时，为了确保决策万无一失，还有几位成员试探性地尝试了其他语言方案。

结果令人振奋：即使是初步的手写 Go 代码，解析速度也达到了原版的 5 倍左右！

更重要的是，团队惊喜地发现，手写的 Go 代码在结构和逻辑上与原始的 TypeScript 代码惊人地相似。这种代码形态上的高度一致性，不仅验证了 Go 是正确的选择，更为后续大规模自动化工具的开发注入了强心剂。

移植实战：从 ts-to-go 到并发革命

1. 自动化移植工具：ts-to-go

为了加速迁移，Jake 编写了一个 ts-to-go 工具，能将 TypeScript 代码“直译”为 Go 代码。

TS 的 interface -> Go 的 interface
TS 的 class -> Go 的 struct + methods
复杂的位运算和逻辑判断 -> 自动转换为 Go 的等价写法

虽然不能 100% 完美转换，但这让团队在初期就能获得一个“虽然丑但能跑”的版本，极大加速了进程。

2. 数据结构的重新设计

在 JavaScript 中，对象是动态的；在 Go 中，一切皆有类型。团队不得不对 AST 的数据结构进行大刀阔斧的改革。

消除 interface 滥用：最初的移植版本大量使用 interface 来模拟 TS 的多态，导致了巨大的内存开销（胖指针）和 nil 检查地狱。
拥抱 struct 嵌入：最终，他们设计了一个基础 Node 结构体，并将其嵌入到所有具体的 AST 节点中。这不仅减少了内存占用，还彻底解决了 nil 接口的问题。

3. 并发：性能提升的核心引擎

这是 Go 带来的最大红利。旧的 TS 编译器是单线程的，解析、绑定、检查、生成都在一条线上排队。

而在 Go 版本中：

解析 (Parsing)：每个文件可以独立解析，完全并行。
绑定 (Binding)：每个文件的符号绑定也是独立的，完全并行。
类型检查 (Type Checking)：这是最难的部分，因为文件间存在复杂的依赖。团队采用了“独立检查器” (Independent Checkers) 的模式，为每组文件分配一个独立的检查器，虽然会有少量重复工作，但实现了高度的并行化。

结果是惊人的：VS Code 的编译时间从 80 秒缩短到了 7 秒，速度提升超过 10 倍！

踩坑与优化：Go 也没那么简单

当然，移植过程并非一帆风顺。Jake 分享了几个典型的“水土不服”案例：

影子变量 (Shadowing)：Go 允许在内层作用域遮蔽外层变量（如 err、result等），这导致了无数隐蔽的 Bug。Jake 甚至为此专门写了一个静态分析工具(https://jakebailey.dev/posts/go-shadowing)来抓这些虫子。
方法值的分配：在 Go 中，将方法作为值传递（如 parser.LookAhead）会产生一次内存分配。在一个频繁调用的紧密循环中，这带来了 17% 的性能损耗。解决方案是改回显式的函数调用。
字符串拼接：JavaScript 引擎对字符串拼接有深度优化（Cons-string），而 Go 的 + 操作符则是实打实的内存拷贝。这导致初期的移植版本在处理大量字符串时性能惨不忍睹。

遗憾与取舍：那些我们怀念的 TypeScript 特性

正如 Jake 在演讲中所言，这次迁移是一场巨大的工程胜利，但也是一次充满妥协的旅程。从表达力丰富的 TypeScript 转向“极简主义”的 Go，团队不得不忍痛割爱，放弃了许多令人怀念的语言特性：

编译期空值安全 (Compile-time nil safety)：这是团队最怀念的特性。在 Go 中，空指针异常（Panic）依然是悬在头顶的达摩克利斯之剑，而在 TypeScript 中，null/undefined 是类型系统的一部分，能被编译器严格检查。
空值合并与链式调用 (??, ?.)：Go 缺乏这些语法糖，使得代码中充斥着冗长的 if x != nil 检查，远不如 TypeScript 优雅。
联合类型与类型收窄 (Union types, narrowing)：TypeScript 强大的联合类型让数据建模极其灵活，而在 Go 中，这不得不退化为接口或带有大量字段的结构体。
泛型方法与三元运算符：这些“现代化”特性的缺失，让从前端背景转过来的工程师们颇感不适。

然而，对于编译器团队来说，为了性能，这一切“阵痛”都是值得的。他们用语法的繁琐换取了运行时的极速，这正是工程世界中最经典的“等价交换”。