- Tony Bai

2025年十一月月发布的文章

还在当“上下文搬运工”？我写了一门课，帮你重塑AI开发工作流

十一月 20, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/11/20/ai-native-dev-workflow

大家好，我是Tony Bai。

最近半年，我发现我的开发日常，正被一种新的“工作流摩擦”所困扰。

我猜，你可能也感同身受。

我们在一块屏幕上沉浸于IDE中的Go代码，在另一块屏幕上，则像一个勤奋的“学生”，不断向AI大模型提问。我们从代码库中精心挑选上下文，复制，切换窗口，粘贴，然后带着AI给出的答案，再复制，切换，粘贴回来。

我们成了AI时代的“上下文搬运工”和“提示词调优师”。

IDE插件的出现，让AI离我们更近了一步，它像一个“副驾驶”，能为我们提供实时的建议。但它依然无法真正地“动手”——它不能为你运行一次测试，不能帮你执行一次git commit，更无法理解你那套复杂的Makefile里到底藏着什么玄机。

我们拥抱了AI，却发现自己陷入了一个新的“效率怪圈”。我们与AI的协作，始终是割裂的、被动的、充满摩擦的。

我一直在思考，这真的是AI时代软件开发的终极形态吗？一定有更好的方式。一定有一种方法，能让AI不再是一个外部的“辅助工具”，而是成为我们开发流程中一个原生的、可指挥的、能动手干活的“核心成员”。

正是为了系统性地解决这个问题，并把我过去大半年时间的思考、踩坑、实践与沉淀分享出来，我与极客时间合作，倾力打造了一门全新的专栏——《AI原生开发工作流实战：重塑新一代软件工程范式》。

为什么要写这个专栏？

因为我相信，软件开发的范式，正在经历一场深刻的革命。

我们正从“人机协作”的1.0时代，迈向“AI原生”的2.0时代。在这场变革中，开发者的核心价值，将不再仅仅是“写出代码”，而是“设计出能让AI写出高质量代码的工作流”。

而承载这场革命的最佳载体，正是以Claude Code为代表的新一代命令行AI智能体（Command-line Coding Agent）。它们让AI的能力，以前所未有的深度，“活”进了我们最熟悉的开发环境——终端里。

但是，拥有强大的工具，和懂得如何驾驭它，是两回事。

下面是一个AI-开发者集成成熟度模型，你看看你处在哪一层？

我看到的太多开发者，依然在用L1、L2的思维模式，去使用一个为L3、L4工作流设计的强大智能体。这就像开着一辆F1赛车去买菜，不仅没发挥出它的全部性能，还觉得它“不好开”。

这个专栏的目标，就是为你提供那本缺失的“F1赛车驾驶手册”。它不是一本简单的工具说明书，而是一套完整的AI原生开发方法论。我将带你一起，从“第一性原理”出发，重新思考和构建我们在AI时代的软件工程实践。

在这个专栏里，我为你设计了怎样的学习路径？

为了让你能系统性地完成这次思维和技能的升维，我将专栏精心设计为四个层层递进的模块，它就像一张清晰的“升级打怪地图”：

模块一：概念篇 · 建立AI原生世界观
在这一模块，我们将首先统一认知。你将深入理解什么是“规范驱动开发（Spec-Driven Development）”，这一AI原生开发的核心引擎。我们还会一起扫描整个命令行AI Agent的生态，并最终明确，我们为什么选择Claude Code作为核心的实战载体，以及如何通过接入国产大模型（如智普AI）来解决国内开发者的成本与可用性问题。
模块二：基础篇 · 掌握与AI伙伴协作的通用语言
我们将从零开始，手把手带你掌握与AI Agent协作的核心交互模型。你将精通上下文的艺术（CLAUDE.md, agents.md, constitution.md），学会如何为AI注入“长期记忆”和项目“宪法”。你还将掌握强大的自定义指令（Slash Commands），开始将你自己的工作流封装为AI可以执行的命令。学完此模块，你将能为任何项目快速定制一套AI‘说明书’，让它秒懂你的代码库。
模块三：进阶篇 · 将Agent锻造成你的专属神器
这是专栏的“硬核”部分。我们将进入AI Agent的“引擎室”，为你揭示其所有高级特性的工作原理和实战技巧。从安全基石（权限、沙箱、快照回滚），到能力扩展矩阵（Hooks, Skills, Sub-agents, MCP），再到自动化接口（Headless模式），你将学会如何将一个通用AI，彻底“魔改”成一个懂你项目、听你指挥的“专属神器”。学完此模块，你将拥有‘魔改’AI Agent的能力，让它从‘通用模型’变成你的‘专属战友’。
模块四：实战篇 · 在真实项目中重塑工程实践
这是整个专栏的“毕业大戏”。我们将把前面所有学到的理论和技巧，全部应用到一个从零到一的Go项目构建中。在通过顶层设计建立好你的AI驾驶舱后，你将亲历一个功能，是如何在AI原生工作流的加持下，被一步步地设计（spec.md）、规划（plan.md, tasks.md）、编码（TDD）、审查、交付（CI/CD），乃至最终维护与重构的。这将是你把知识转化为能力的最佳演练场。

学完这门课，你将获得什么？

一套前沿的开发方法论： 真正掌握“AI原生开发”与“规范驱动开发”的核心思想，而不仅仅是工具的零散技巧。
一套通用的Coding Agent驾驭技能： 精通上下文注入、自定义工具和技能、自动化编排等核心技巧，无论未来出现什么新的Coding Agent工具，你都能快速上手。
一套可落地的工程实践： 获得AI在需求、设计、TDD、CI/CD、重构等软件工程全流程中的最佳实践和Go语言实战代码。
一次思维模式的升级： 完成从“AI工具使用者”到“AI工作流指挥家”的角色转变，构筑在AI时代的个人核心竞争力。

写在最后：一份“抛砖引玉”的邀请

在策划这门课时，我始终保持着一种敬畏之心。

Claude Code是2025年2月才正式进入大众视野的，至今也不过大半年的时间。整个命令行Coding Agent领域，都还处在一个高速演进、日新月异的“黎明时代”。我们所有人，包括我在内，都还在“摸着石头过河”。

因此，这个专栏的内容会更偏向于基础和入门，我希望通过最详尽的示例，为你直观地展现AI原生工作流的巨大潜力。我为你呈现的，更多是我个人在当前阶段探索出的一种可行的工作流，它未必是放之四海而皆准的“最优解”，更谈不上是“终极银弹”。

我更希望这个专栏，能成为一个“抛砖引玉”的平台。

我把我这块“砖”抛出来，是希望能引出你——每一位身处一线的优秀开发者——那块更宝贵的“玉”。我非常期待你在课程的评论区，分享你的思考、你的工作流、你的“最佳实践”。

我相信，关于AI原生开发的未来，最终的答案，一定不是由我一个人，也不是由任何一个AI公司定义的。它将由我们所有拥抱变革、勇于实践的开发者，共同书写。

让我们一起，成为定义这个新时代开发范式的第一批人。

现在，这门凝结了我大半年心血的课程 《AI原生开发工作流实战》 已经在极客时间正式上线了！

专栏为图文形式，共22讲。我为你准备了早鸟优惠 ¥59（原价 ¥99），仅限首周。

扫描下方二维码，立即订阅

用一两杯咖啡的钱，投资一次面向未来的思维和技能升级。

如果你想先了解更详细的课程内容，可以点击「这里」查看专栏的详细目录。

期待在课程中，与你相遇，共同精进！

如果本文对你有所帮助，请帮忙点赞、推荐和转发！

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

一次 unwrap() 引发的全球宕机：Cloudflare 故障报告背后的 Rust 安全反思

十一月 19, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/11/19/cloudflare-18-november-2025-outage

大家好，我是Tony Bai。

2025 年 11 月 18 日，世界标准时间(UTC) 11:20，支撑着全球大量互联网流量的 Cloudflare 网络开始出现严重故障。无数网站和应用的用户，开始频繁地看到那令人心悸的“Internal Server Error (500)”页面。一场席卷全球的互联网宕机事件，就此拉开序幕。

事后，Cloudflare 发布了一份极其详尽、坦诚的故障复盘报告。报告揭示了一个令人震惊、也极具讽刺意味的事实：这场灾难的最终扳机，竟然是新一代代理引擎FL2 中(这里仅针对文中提及的新引擎FL2，受影响的旧引擎FL文中并未提及具体原因)，一段本应代表“内存安全”的 Rust 代码中的 unwrap() 调用。

这起事件，如同一颗投入平静湖面的巨石，激起了关于 Rust 安全模型、系统复杂性、以及“快速失败”哲学的层层涟漪。它迫使我们重新审视一个根本性问题：我们所追求的“内存安全”，真的能让我们高枕无忧吗？

故障的多米诺骨牌：从一个权限变更开始

Cloudflare 的报告清晰地描绘了一条如多米诺骨牌般精准倒下的故障链。令人惊叹的是，这一切的源头，并非黑客攻击，也不是硬件故障，而是一次看似无害的内部变更：

源头：ClickHouse 数据库权限变更 (11:05 UTC)
为了提升查询安全性和可靠性，Cloudflare 的工程师对 ClickHouse 数据库集群进行了一次权限变更。
第一个意外：重复的元数据
这次变更意外地导致了一个用于生成“特征文件”(feature file) 的元数据查询（SELECT name, type FROM system.columns WHERE table = …）开始返回重复的列名。因为该查询忘记了按数据库名进行过滤，而新的权限让它看到了底层 r0 数据库中的重复表结构。
第二个意外：配置文件体积翻倍
这个“特征文件”是 Cloudflare 机器人管理 (Bot Management) 系统机器学习模型的核心输入。由于元数据查询返回了双倍的行数，最终生成的特征文件体积也翻了一倍，从约 60 个特征，激增到了超过 200 个。
第三个意外：触发预分配内存上限
为了极致的性能，Cloudflare 的核心代理服务（包括基于 Rust 的新一代引擎 FL2）会在启动时，为机器人管理模块预分配一块固定大小的内存，用于加载这个特征文件。这个预分配的上限被设置为 200 个特征。
最终扳机：Rust 代码中的 unwrap() 恐慌 (Panic)
当那个体积翻倍的、包含超过 200 个特征的“毒丸”配置文件，被分发到全球的 FL2 服务器上时，灾难发生了。负责加载特征的 Rust 代码，在尝试将超过 200 个特征塞入预分配的 200 大小的缓冲区时，append_with_names 方法返回了一个 Err 结果。然而，调用这段代码的地方，却简单粗暴地使用了 unwrap()。
```
// Cloudflare 报告中展示的 Rust 代码片段
let (feature_values, _) = features
    .append_with_names(&self.config.feature_names)
    .unwrap(); // <- BOOM!
```
unwrap() 的行为是：如果结果是 Ok(value)，则返回 value；如果结果是 Err(error)，则立即让当前线程 panic（恐慌）。
雪崩：5xx 错误与全球宕机
工作线程的 panic，导致了一个未处理的错误。这个错误迅速向上传播，最终导致核心代理系统无法处理依赖于机器人管理模块的流量，并开始向上游返回大量的 HTTP 5xx 错误。多米诺骨牌全部倒下，全球大范围的互联网服务因此中断。

Rust 安全模型的反思：“内存安全”≠“永不崩溃”

这起事件，是对 Rust 安全模型的一次深刻、也是痛苦的“压力测试”。Rust 最引以为傲的“卖点”——内存安全——在这场灾难中，既是“英雄”，也是“恶棍”。

英雄之处：它精确地阻止了更坏的情况

Rust 在这里所做的一切，完全符合其设计哲学。append_with_names 方法正确地检测到了缓冲区溢出的风险，并通过返回一个 Err，阻止了一次潜在的内存损坏。如果这段代码是用 C++ 编写的，一个类似的错误可能会导致缓冲区溢出、数据损坏、甚至远程代码执行等更严重、更难以追踪的安全漏洞。

Rust 成功地将一个未定义的、危险的内存行为，转化为了一个已定义的、可预测的程序崩溃。

恶棍之处：“快速失败”的哲学真的普适吗？

然而，问题恰恰出在 unwrap() 这个“捷径”上。unwrap() 和它的兄弟 expect()，是 Rust “快速失败”(Fail-fast) 哲学的体现。它们背后的假设是：“我相信这种情况永远不会发生，如果发生了，那就是一个程序员无法恢复的、灾难性的逻辑错误，整个程序应该立刻死掉，而不是带着错误的状态继续运行。”

Cloudflare 的工程师们，显然也相信“特征文件永远不会超过 200 个”。

这次事件血淋淋地告诉我们：

在分布式系统中，你所做的“永不发生”的假设，几乎总会在某个时刻、以一种你意想不到的方式被打破。
unwrap() 是一把极其锋利的双刃剑。它在原型开发、测试代码、或处理那些真正代表“程序不变量被破坏”的场景时非常有用。但将其用于处理任何可能由外部输入（即使是内部系统的“外部输入”）而失败的操作，都是在埋下一颗定时炸弹。
Rust 的内存安全，并不能替代全面的错误处理和系统韧性设计。 它只能保证你的程序“死得干净”，而不能保证它“不死”。

更深层次的教训：超越语言的“系统性失败”

将锅完全甩给 Rust 或 unwrap() 是不公平的。这场宕机，是一次典型的、由多个层面小失误共同导致的系统性失败 (Systemic Failure)。

数据库查询的脆弱性：那个元数据查询，为何如此脆弱，以至于一次权限变更就能使其输出加倍？它缺乏对数据库名的过滤，这是一个早已存在的隐患。
配置发布的“零校验”：一个体积异常的配置文件，为何能在没有任何校验和告警的情况下，被迅速分发到全球网络？配置发布管道缺乏基本的“理智检查”。
边界条件的“想当然”：为什么预分配的内存上限是 200？这个“魔法数字”背后的假设是什么？当假设被打破时，为什么没有一个优雅的降级方案（如拒绝加载新配置，继续使用旧配置），而是直接崩溃？
故障域的耦合：机器人管理模块的一次“错误”的特征文件生成，为何能导致核心代理的瘫痪，并进一步影响到 Workers KV 和 Access 等看似不相关的服务？这暴露了系统各组件之间过紧的故障耦合。