2026-04-01 08:29:37
本文永久链接 – https://tonybai.com/2026/04/01/rewrote-jsonata-in-golang-with-ai
大家好，我是Tony Bai。
过去的几年，我们见证了 AI 编程工具从“玩具”到“神器”的进化。无数开发者都在分享自己效率翻倍的喜悦。
你有没有想过，用 AI 来完成一次“外科手术式”的精准重构，一天之内，就能帮你把公司每年烧掉的 50 万美元（约 360 万人民币）的服务器成本，直接砍到零？
这听起来像天方夜谭，但它真实地发生了。
就在前几天，以色列安全公司 Reco 的工程师 Nir Barak 发表了一篇极其硬核的博客。他详细复盘了自己是如何在一天之内，花费了仅仅 400 美元的 Token 费用，利用 AI 将一个用 JavaScript 编写的核心组件 JSONata，完美地重写为了纯 Go 版本，最终为公司节省了每年 50 万美元的开销，并带来了 1000 倍的性能提升。
这不仅仅是一个“AI 真牛逼”的简单故事。它背后揭示的，是一套足以改变我们未来架构选型和技术债偿还方式的“AI 驱动重构（AI-Driven Refactoring）”实用方法。
要理解这次重构的意义有多么重大，首先得看看 Nir Barak 的团队曾经陷入了多深的泥潭。
他们的核心业务是一个用 Go 编写的高性能数据管道，每天处理数十亿的事件。但其中有一个环节，需要用到一个名为 JSONata 的查询语言（你可以把它想象成带 Lambda 函数的 jq）来执行动态策略。
尴尬的是，JSONata 的官方实现是 JavaScript 写的。
这就导致了一个极其痛苦的架构：他们的主业务 Go 服务，为了执行这些规则，不得不去远程调用（RPC）一个专门部署在 Kubernetes 上的庞大的 Node.js 服务集群。
这个“小小的”跨语言调用，给他们带来了三大噩梦：
Nir Barak 的团队当然也尝试过各种小修小补：优化表达式、加缓存、甚至用 CGO 把 V8 引擎直接嵌进 Go 里……但这些都只是“头痛医头”，无法根治“跨语言”这颗毒瘤。
转机发生在前几周。Nir Barak 看到了 Cloudflare 那篇刷爆全网的文章《我们如何用 AI 在一周内重构 Next.js》。
Cloudflare 的做法极其“暴力”且有效：他们没有让 AI 去创造新东西，而是把 Next.js 现成的spec，以及包含几千个 case 的官方测试套件（Test Suite）直接扔给大模型，然后对 AI 下达了一个简单粗暴的指令：
“我不管你怎么实现，给我写一个能在 Vite 上跑通所有这些测试的 API 就行！”
Nir Barak 看到这里，瞬间被点醒了：“我们面临的问题一模一样！我们也有 jsonata-js 官方那套包含 1778 个测试用例的完整套件啊！”
与其让 AI 去搞创新，不如把它变成一个任劳任怨、24 小时待命的“代码翻译工”！
于是，他花了一个周末，用 AI 制定了一个极其清晰的“三步走”作战计划：
第二天，他按下了“开始键”。
接下来的故事，充满了令人肾上腺素飙升的极客快感。
Nir Barak 坐在电脑前，看着 AI Agent 像一台失控的缝纫机一样，疯狂地生成 Go 代码、运行测试、读取报错、然后自我修正。
整个过程被划分成了几个“波次（Waves）”：先实现核心解析器，再实现内置函数，最后处理各种边缘 case。
在 AI 与测试用例的左右互搏之下，仅仅 7 个小时 后，奇迹发生了：
一个包含 13,000 多行纯 Go 代码的、名为 gnata 的全新 JSONata 实现诞生了。它完美通过了官方所有的 1778 个测试用例。
而这整个过程的成本呢？
400 美元的 Token 费用。
Nir Barak 在博客中晒出了一张截图，数据显示，在重构 gnata 的那一天，AI 生成的代码占比高达 91.7%！
当他把这个 PR 提交到公司内部时，立刻有人质疑 ROI（投资回报率）。而他的回答简单粗暴：
“上个月，jsonata-js 集群的成本是 2.5 万美元。现在，是 0。”
成本降为零已经足够震撼，但性能上的收益更是堪称“恐怖”。
这还只是开始。由于 gnata 是纯 Go 实现，Nir Barak 团队得以进行更深度的“魔改”：他们设计了一套两层评估架构。对于简单的字段查找，gnata 直接在原始的 JSON 字节流上操作，实现了 零堆内存分配（Zero Heap Allocations）！只有遇到复杂表达式时，才会启动完整的解析器。
在接下来的两周内，他们乘胜追击，用 gnata 的批量处理能力，替换掉了主数据管道中另一个极其臃肿、靠启动上万个 Goroutine 来并发处理规则的旧引擎。 结果：又省下了每年 20 万美元。
短短两周，两次“外科手术式”的重构，总共为公司节省了每年 50 万美元的开销。
最让人意想不到的是，这次重构还带来了组织层面的“意外之喜”：
gnata 是公司内部第一个完全由 AI Agent 大规模参与生成的 PR。在 Code Review 的过程中，团队成员被迫去学习如何分辨“AI 真正发现的并发 Bug”和“AI 瞎操心的代码格式问题”。这次经历，为他们后续制定全公司的 AI Code Review 规范积累了宝贵的实战经验。
在文章的结尾，Nir Barak 提到了 AI 大神 Andrej Karpathy 最近的观点，大意是：
“编程正在变得面目全非。在底层，深厚的技术专长正成为比以往任何时候都更强大的‘乘数效应放大器’。”
Nir Barak 感慨道，直到最近，他自己都对那种完全由 AI Agent 生成代码的“氛围编码（Vibe coding）”持怀疑态度。但 2026 年 2 月，成为了一个连他这样固执的开发者都无法忽视的“拐点”。
gnata 的诞生，标志着我们不再只是用 AI 去写一些无关紧要的玩具项目。在拥有明确测试用例和边界规范的前提下，AI 已经具备了对生产环境核心组件进行“手术刀式重构”的惊人能力。
你准备好拿起这把名为“AI”的手术刀，去切掉你系统里那些最昂贵、最臃肿的“技术肿瘤”了吗？
资料链接：https://www.reco.ai/blog/we-rewrote-jsonata-with-ai
今日互动探讨：
在你的公司里，是否存在类似的“异构技术栈”调用导致的性能瓶颈或成本黑洞？你有没有想过，可以用 AI + 测试用例的方式，对某个核心组件进行“代码翻译”式的重构？
欢迎在评论区分享你的架构痛点与大胆构想！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-03-31 07:26:51
本文永久链接 – https://tonybai.com/2026/03/31/go-minimalism-vs-cpp26-epic-new-features
大家好，我是Tony Bai。
在这个 Go、Zig 等“小而美”新语言颇受青睐的时代，如果你去技术社区里问一句：“C++ 这门语言怎么样？”
你大概率会得到一堆充满戏谑的回答：“太复杂了，别学”、“从入门到放弃”、“面试造火箭，工作拧螺丝”。
C++，这门诞生于上世纪 80 年代的编程语言，似乎早已被贴上了“老旧、臃肿、极其反人类”的标签。在很多新生代开发者眼里，它就像一头步履蹒跚的史前巨兽，理应被时代所淘汰。
但就在前天（2026年3月29日），这头“史前巨兽”不仅没有倒下，反而亮出了它那足以撕裂天空的獠牙。
C++ 标准委员会主席、C++ 界的“教父级”人物 Herb Sutter 亲自在博客上宣布：C++26 标准的技术工作，已正式完成！
Herb Sutter 还用极其兴奋的口吻将其定义为“自 C++11 以来最具冲击力的一次发布”。而这次更新的核心，是四个被他称为“Fab Four”（神奇四侠）的史诗级新特性。
当我耐着性子看完全部内容后，我脑子里只剩下四个字：叹为观止。
当 Go 语言的开发者还在为“是否要给语言增加一个三元表达式”，或泛型方法而激烈辩论时，C++ 却反其道而行之，给自己又加装了四门“宇宙级”的重型武器。这到底是 C++ 吹响的绝地反击号角，还是压垮骆驼的最后一根稻草？
今天，我们就来硬核扒开 C++26 这四大“金刚”，看看它们到底有多强，以及它们将如何影响将来程序员对编程语言的选择。
Herb Sutter 将反射放在了四大特性之首，并称之为“自模板（Templates）发明以来 C++ 最重要的升级”。
什么是C++ 的反射？简单来说，就是让代码在编译期拥有了“自我审视”和“自我创造”的能力。
在 C++26 之前，如果你想实现一个通用的 JSON 序列/反序列化库，你必须写大量重复的模板代码，或者用各种丑陋的宏来“欺骗”编译器。
但在 C++26 中，你可以像这样写出充满“神性”的代码（代码示意）：
这段代码，在编译的时候就能根据编译时的输入(test.json)自动分析JSON构造，并生成编译时用于计算的一个新类型。这在 Go 语言里，需要借助 reflect 包在运行时（Runtime）以牺牲性能为代价才能做到。而 C++，直接在静态编译期（Compile-time）零成本搞定了！
Herb Sutter 将其形容为“C++ 的十年火箭引擎”。这意味着，未来 C++ 社区将涌现出无数极其强大、但又极其复杂的元编程（Metaprogramming）库。C++ 的学习曲线，将再次被拉到一个新的高度。
如果说反射让 C++ 的上限变得更加遥不可及，那么内存安全的提升，则是 C++ 在向 Go 和 Rust 的核心优势区发起的正面冲锋。
C++ 常年被诟病的核心痛点是什么？内存不安全。悬垂指针、未初始化变量读取（导致未定义行为）……这些噩梦困扰了 C++ 程序员几十年。
C++26 给出了一个极其诱人的承诺：你的老代码一行都不用改，只要用 C++26 模式重新编译，就能自动获得大幅度的安全提升！
这主要来源于两个方面的改进：
Herb Sutter 引用了 Google 的内部数据：
“仅在 Google，这项技术就已经修复了超过 1000 个 Bug，预计每年可以预防 1000 到 2000 个新 Bug 的产生，并将整个生产环境的段错误（Segfault）率降低了 30%。”
这简直是在对 Go 说：“你用 GC 换来的那点可怜的安全性，我 C++ 现在也能做到了，而且依然是零成本的！”
如果你写过 Go，你一定对满屏的 if param == nil { return errors.New(…) } 感到厌烦。这种防御性编程，虽然有效，但极其啰嗦。
C++26 正式引入了语言级的契约编程。
你可以像签合同一样，为你的函数制定严格的法律条文：
这些 pre 和 post 是编译器和运行时可以理解并强制执行的“法律”。如果调用者违反了前置条件，程序可以在开发阶段就立刻崩溃并给出明确的报错，而不是等到数据被污染后才在某个奇怪的地方爆炸。
虽然 Go 社区也在讨论类似的泛型断言，但 C++26 已经先行一步，将其做成了语言标准。
在 C++20 中，虽然引入了 co_await 协程，但它只是一个语法糖，并没有提供一个统一的调度框架。
C++26 终于补上了这块短板，正式推出了 std::execution，也被称为 Sender/Receiver 模型。
这是一个极其强大、统一的异步模型框架。它让你能以一种声明式的方式，去描述、组合和调度复杂的并发任务流。
下面是一段使用std::execution的代码示例：
// This is an example of a custom algorithm for starting work
// without allocations. This algorithm is also available in
// <exec/start_now.hpp>. (Users that don't write custom sender
// algorithms will not need to use receivers or call connect
// or start.)
template <stdexec::sender_in<stdexec::empty_env> Sender>
struct start_now {
start_now(Sender sndr)
: _op(stdexec::connect(std::move(sndr), _sink_rcvr())) {
stdexec::start(_op);
}
private:
// start_now is implemented in terms of this custom receiver,
// which is used to discard Sender's results.
struct _sink_rcvr {
using receiver_concept = stdexec::receiver_t;
void set_value(auto&&...) noexcept {}
void set_error(auto&&) noexcept {}
void set_stopped() noexcept {}
};
stdexec::connect_result_t<Sender, _sink_rcvr> _op;
};
int main() {
// A run loop is a fifo queue of work and a loop to execute the
// work. It needs to be driven by calling its .run() member fn.
stdexec::run_loop ctx;
auto event_loop = ctx.get_scheduler();
// Create two tasks that cooperatively multitask.
auto task1 = stdexec::just()
| stdexec::then([]{ std::puts("hello from task 1! suspending..."); })
| stdexec::continue_on(event_loop) // suspend
| exec::repeat_n(5)
| stdexec::then([]{ std::puts("task 1 is done!"); });
auto task2 = stdexec::just()
| stdexec::then([]{ std::puts("hello from task 2! suspending..."); })
| stdexec::continue_on(event_loop) // suspend
| exec::repeat_n(8)
| stdexec::then([]{ std::puts("task 2 is done!"); });
// Start both tasks. This enqueues them for execution on the run loop.
auto op1 = start_now(stdexec::start_on(event_loop, std::move(task1)));
auto op2 = start_now(stdexec::start_on(event_loop, std::move(task2)));
ctx.finish(); // tell the run loop to stop when the queue is empty
ctx.run(); // tell the run loop to start executing work in the queue
}
这可以被看作是 C++ 对 Go 的 Goroutine + Channel 模型，以及 Rust 的 async/await + tokio 模型的终极回应。
它让 C++ 开发者第一次拥有了一套语言原生的、能够轻松编写“无数据竞争（Data-race-free by construction）”并发程序的“亲儿子”工具。
反射、安全、契约、并发。C++26 的这四大金刚，每一个都足以在其他语言中引发一场大地震。
我们看到的是一头苏醒的巨兽。它没有选择像 Go 那样“断舍离”，也没有像 Rust 那样“偏执于安全”，而是极其贪婪地选择了：“我全都要！”
它既想要极致的表达能力和零成本抽象（反射、模板），又想要与 Rust 媲美的内存安全（加固标准库），还想要不输 Go 的并发表达力（std::execution）。
C++26 给老兵们提供了前所未有的强大武器，但也把本就陡峭的学习曲线，又向上抬升了一个令人惊叹的高度，宇宙第一复杂的编程语言，实至名归！
当 Go 的开发者还在为“是否要加个三元表达式”而争论不休时，C++ 已经头也不回地奔向了“万神殿”。
或许，编程语言的终局，真的不是“大一统”，而是“两极分化”：一极是像 Go 一样追求极致简单的“工程师语言”；而另一极，则是像 C++ 这样，专为那 1% 的、追求极致性能和控制力的“宗师级”开发者准备的、布满荆棘的封神之路。
C++26，欢迎来到神的世界，也欢迎来到神的炼狱。
今日互动探讨：
看完 C++26 的这四大“神仙”特性，你是感到兴奋，还是感到了深深的绝望？你觉得 C++ 的这种“大而全”的演进路线是对的，还是 Go 的“小而美”更代表未来？
欢迎在评论区分享你的看法！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-03-30 08:10:00
本文永久链接 – https://tonybai.com/2026/03/30/reduced-p99-latency-by-request-hedging-in-go
大家好，我是Tony Bai。
在微服务和分布式系统的世界里，我们常常会遇到一个令人头疼的现象：服务在大部分时间（如 P50 或 P90 指标）表现得非常丝滑，但总有那么一小撮请求（P99 甚至 P99.9 指标）慢得令人发指。
近日，在 Reddit 的 r/golang 社区中，一位开发者分享了他将 Go 服务的 P99 延迟降低了 74% 的经验。令人惊讶的是，他所使用的绝招并非升级硬件或重构业务逻辑，而是引入了一个名为 Request Hedging（请求对冲） 的策略。
面对高延迟，我们本能的反应是“重试（Retry）”。但正如这位开发者所发现的：单纯的重试不仅无助于解决长尾延迟，反而可能在系统高负载时雪上加霜。真正有效的方法是处理“落后者”，而不是“失败者”。
本文将带你重温 Google 关于分布式系统的经典论文，深入剖析 Request Hedging 的原理，并手把手教你如何仅使用 Go 标准库，为你的 HTTP 客户端插上“对冲”的翅膀。
在深入 Hedging 之前，我们必须先理解什么是尾延迟（Tail Latency）。
2013 年，Google 的两位大神 Jeffrey Dean 和 Luiz André Barroso 在《Communications of the ACM》上发表了一篇神级论文：《The Tail at Scale》。在这篇Paper中，他们详细阐述了在大规模分布式系统中，为什么长尾延迟是不可避免的。
哪怕你拥有世界上最优秀的工程师，底层硬件的物理特性（如 CPU 降频、网络拥塞）、操作系统的后台任务（如 IO 调度）、以及语言运行时的特性（如 Go 的 GC 停顿），都会导致某些请求的处理时间远高于平均值。
当你的服务需要并行调用多个下游服务时，这种局部的延迟波动会被急剧放大。 假设一个服务需要调用 100 个叶子节点，如果单个节点响应时间超过 1 秒的概率是 1%，那么整个请求超过 1 秒的概率将飙升至 63%！
注：节点总数 n = 100 ，已知单个节点响应时间超过 1 秒的概率 为1%。单个节点响应时间不超过 1 秒（即正常响应）的概率为1-1% = 99% = 0.99。由于 100 个请求是并行的且相互独立，整个请求“正常”的前提是所有 100 个节点都必须在 1 秒内返回。这种概率为0.99^100=0.366。这样只要这 100 个节点中有任何一个掉链子，整个请求（作为整体）的耗时就会超过 1 秒。其概率为1-0.366≈0.63=63%。
这张图直观地展示了随着服务器数量（Fan-out）增加，哪怕单机变慢的概率极低，整体响应时间变慢的概率也会陡峭上升。
面对超时的请求，传统的做法是实施超时重试（Timeout & Retry）。但重试存在致命缺陷：
为了解决长尾延迟，Google 论文中提出了一种极具工程智慧的策略：Hedged Requests（请求对冲/对冲请求）。
其核心思想非常简单直白：
客户端首先向目标服务器发送一个请求。如果该请求在预期的时间（即“对冲延迟阈值”，Hedging Delay）内没有返回，客户端不会等待其超时或失败，而是立即向另一个副本（或者同一个负载均衡器后的其他实例）发送一模一样的备份请求。客户端将使用最先返回的那个成功响应，并主动取消其余的未决请求。
这种方法之所以有效，是因为导致请求变慢的因素通常是瞬时的且与特定机器相关的（如某台机器刚好在做 GC，或者刚好被一个大查询阻塞了队列）。第二个请求很大概率会被路由到一台健康的、空闲的机器上，从而快速返回。
Hedging 与 Retry 的本质区别：
虽然这听起来像是在浪费服务器资源，但 Google 的实践证明，如果将 Hedging Delay 设置为 P95 延迟（即 95% 的请求都能在这个时间内完成），那么只有 5% 的请求会触发对冲。这仅仅增加了 5% 的系统负载，却能将 P99 或 P99.9 的长尾延迟削减大半！
在现代微服务生态中，gRPC 已经在 Service Config 中原生支持了 Hedging 策略，但对于广泛使用的 HTTP/REST 接口，我们通常需要自己实现。
为了验证 Hedging 的威力，我们将使用 Go 原生标准库，从零实现一个带有对冲机制的 http.RoundTripper，并构建一个完整的压测实验环境。
首先，创建一个新的 Go 项目：
mkdir go-hedging-demo
cd go-hedging-demo
go mod init hedging-demo
我们将创建三个文件：
go-hedging-demo/
├── go.mod
├── hedge.go
├── server.go
└── main.go
我们将通过实现 http.RoundTripper 接口，优雅地将对冲逻辑无缝注入到 Go 标准库的 http.Client 中。
// hedge.go
package main
import (
"context"
"errors"
"net/http"
"sync"
"time"
)
// HedgedTransport 实现了 http.RoundTripper 接口
type HedgedTransport struct {
Transport http.RoundTripper // 底层真正的 Transport
MaxAttempts int // 最大并发请求数（包括最初的1次）
HedgeDelay time.Duration // 触发对冲的延迟时间
}
func (ht *HedgedTransport) RoundTrip(req *http.Request) (*http.Response, error) {
// 如果没有设置，使用默认行为
transport := ht.Transport
if transport == nil {
transport = http.DefaultTransport
}
attempts := ht.MaxAttempts
if attempts <= 0 {
attempts = 1
}
// 使用带有取消功能的 context 控制整个对冲生命周期
ctx, cancel := context.WithCancel(req.Context())
defer cancel()
// 结果通道，用于接收第一个成功的响应或错误
type result struct {
resp *http.Response
err error
}
resCh := make(chan result, attempts)
var wg sync.WaitGroup
// 启动一个请求的闭包函数
doRequest := func() {
wg.Add(1)
go func() {
defer wg.Done()
// 克隆请求，防止并发修改
cloneReq := req.Clone(ctx)
resp, err := transport.RoundTrip(cloneReq)
// 只有当请求不是因为 context 取消而失败时，才尝试写入结果
if !errors.Is(err, context.Canceled) {
select {
case resCh <- result{resp: resp, err: err}:
default:
// 通道已满或已不再需要，直接丢弃（如果 resp 不为空，需要关闭 Body 以防泄露）
if resp != nil && resp.Body != nil {
resp.Body.Close()
}
}
}
}()
}
// 1. 发起第一个请求
doRequest()
// 2. 控制对冲的定时器和尝试次数
timer := time.NewTimer(ht.HedgeDelay)
defer timer.Stop()
errs := make([]error, 0, attempts)
requestsSent := 1
for {
select {
case res := <-resCh:
// 收到结果
if res.err == nil {
// 成功！立即取消其他还在飞行的请求
cancel()
// 等待后台 goroutine 清理完成 (可选，这里为了简单不阻塞)
return res.resp, nil
}
// 如果这个请求失败了，记录错误
errs = append(errs, res.err)
// 如果所有发出的请求都失败了，且已经达到最大尝试次数，返回错误
if len(errs) == attempts {
return nil, errors.Join(errs...)
}
// 如果一个请求失败了，且还没达到最大尝试次数，我们不应该死等 Timer，
// 而应该立刻触发下一个对冲请求（这里为了简化逻辑，依然依赖下一次 Timer 或失败循环）
// 实际生产级实现可以在这里直接触发 doRequest()
case <-timer.C:
// 对冲延迟到达
if requestsSent < attempts {
// 触发对冲请求
doRequest()
requestsSent++
// 重置定时器，准备下一次可能的对冲
timer.Reset(ht.HedgeDelay)
}
case <-ctx.Done():
// 整个请求超时或被调用方取消
return nil, ctx.Err()
}
}
}
这里，我们使用了 req.Clone(ctx) 来复制请求，确保并发安全。通过 context.WithCancel 控制所有的下游请求，一旦有一个请求成功返回（res.err == nil），立即调用 cancel() 取消其余正在运行（in-flight）的请求。
为了看到效果，我们编写一个简单的 HTTP 服务。它在 90% 的情况下在 50ms 内快速响应，但在 10% 的情况下会遇到长达 500ms 到 1s 的长尾延迟。
// server.go
package main
import (
"fmt"
"math/rand"
"net/http"
"time"
)
func startServer() {
http.HandleFunc("/data", func(w http.ResponseWriter, r *http.Request) {
// 模拟 10% 的长尾延迟
if rand.Float32() < 0.1 {
// 长尾延迟：500ms - 1000ms
delay := 500 + rand.Intn(500)
time.Sleep(time.Duration(delay) * time.Millisecond)
} else {
// 正常响应：10ms - 50ms
delay := 10 + rand.Intn(40)
time.Sleep(time.Duration(delay) * time.Millisecond)
}
fmt.Fprintln(w, "OK")
})
go func() {
err := http.ListenAndServe(":8080", nil)
if err != nil {
panic(err)
}
}()
time.Sleep(100 * time.Millisecond) // 等待服务器启动
}
最后，我们编写压测代码，分别使用普通 Client 和 Hedged Client 发送 1000 个并发请求，并统计 P99 延迟。
// main.go
package main
import (
"fmt"
"io"
"net/http"
"sort"
"sync"
"time"
)
const RequestCount = 1000
func main() {
startServer()
fmt.Println("开始压测普通 HTTP Client...")
normalClient := &http.Client{
Timeout: 2 * time.Second,
}
normalLatencies := runBenchmark(normalClient)
fmt.Println("\n开始压测 Hedged HTTP Client...")
hedgedClient := &http.Client{
Timeout: 2 * time.Second,
Transport: &HedgedTransport{
Transport: http.DefaultTransport,
MaxAttempts: 3, // 最多发送3个请求
HedgeDelay: 80 * time.Millisecond, // P95 延迟设为触发点（我们服务器正常响应 < 50ms）
},
}
hedgedLatencies := runBenchmark(hedgedClient)
// 打印统计结果
printStats("Normal Client", normalLatencies)
printStats("Hedged Client", hedgedLatencies)
}
func runBenchmark(client *http.Client) []time.Duration {
var wg sync.WaitGroup
latencies := make([]time.Duration, RequestCount)
for i := 0; i < RequestCount; i++ {
wg.Add(1)
go func(index int) {
defer wg.Done()
start := time.Now()
resp, err := client.Get("http://localhost:8080/data")
if err != nil {
fmt.Printf("Request failed: %v\n", err)
return
}
io.Copy(io.Discard, resp.Body)
resp.Body.Close()
latencies[index] = time.Since(start)
}(i)
}
wg.Wait()
return latencies
}
func printStats(name string, latencies []time.Duration) {
// 去除可能的失败请求（0值）
valid := make([]time.Duration, 0, len(latencies))
for _, l := range latencies {
if l > 0 {
valid = append(valid, l)
}
}
sort.Slice(valid, func(i, j int) bool {
return valid[i] < valid[j]
})
if len(valid) == 0 {
fmt.Printf("No valid responses for %s\n", name)
return
}
p50 := valid[len(valid)/2]
p95 := valid[int(float64(len(valid))*0.95)]
p99 := valid[int(float64(len(valid))*0.99)]
fmt.Printf("\n=== %s 统计 ===\n", name)
fmt.Printf("请求总数: %d\n", len(valid))
fmt.Printf("P50 延迟: %v\n", p50)
fmt.Printf("P95 延迟: %v\n", p95)
fmt.Printf("P99 延迟: %v\n", p99)
}
在本地 MacBook Pro 的终端上执行 go run .，我得到了以下真实的性能对决：
$go run .
开始压测普通 HTTP Client...
开始压测 Hedged HTTP Client...
=== Normal Client 统计 ===
请求总数: 1000
P50 延迟: 115.226929ms
P95 延迟: 850.768537ms <-- 注意看这里
P99 延迟: 1.045720114s <-- 长尾效应严重
=== Hedged Client 统计 ===
请求总数: 1000
P50 延迟: 138.930108ms <-- P50 轻微损耗
P95 延迟: 360.607686ms <-- 巨大的改善！
P99 延迟: 376.98949ms <-- P99 降低了将近 70%！
正如你所见：
结论：在典型的分布式系统中，这种权衡是极度划算的。我们用极小的平均延迟上升，换取了尾部延迟的高稳定性。
Request Hedging 虽好，但绝非能随意滥用的“银弹”。在将其部署到生产环境之前，你必须考虑以下几个核心约束：
软件工程是一门关于权衡的艺术。在追求极致性能的道路上，我们往往将目光局限于优化数据库索引、压缩 JSON 序列化，却忽视了分布式系统固有的宏观不确定性。
Request Hedging 是从宏观架构层面给出的一记漂亮的防守反击。通过上面几百行的 Go 代码，我们成功复现了 Google 级别的架构优化。下一次，当你的监控大盘上 P99 曲线再次异常抖动时，不妨收起单纯的“超时重试”，尝试给你的 Go 客户端加一点“对冲”的魔法吧。
本文中涉及的代码可以在这里下载。https://github.com/bigwhite/experiments/tree/master/go-hedging-demo
资料链接：
你的 P99 达标了吗？
尾延迟是分布式系统中最难缠的对手。在你的项目中，主要的长尾延迟来源是什么？你会为了降低那 1% 的极端慢请求，而接受 5% 的额外系统负载吗？
欢迎在评论区分享你的性能调优“必杀技”！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-03-29 08:46:41
本文永久链接 – https://tonybai.com/2026/03/29/stop-mindless-ai-coding-we-are-heading-to-a-dead-end
大家好，我是Tony Bai。
过去的一年，大概是所有程序员肾上腺素飙升最快的一年。
从早期的 Copilot、Cursor到如今的Claude Code、Codex，再到各种号称能“全自动开发”的 Agent Swarm（智能体集群）。只要在周末花上几个小时，敲几句 Prompt，你就能把以前想做却没时间做的 Side Project 全部干出来。
甚至，连微软 CEO Satya Nadella 都在四处宣扬“微软现在有多少代码是 AI 写的”。仿佛在一夜之间，“一个人就是一家公司”、“一天撸完一个 SaaS 平台”成了技术圈的标配。
但在这场速度的狂欢中，你有没有感觉到一丝不对劲？
最近，国外资深开发者 Mario Zechner 写了一篇极其辛辣的文章《Thoughts on slowing the f**k down》。他毫不客气地戳破了这层“繁荣”的窗户纸：
当我们把 AI 智能体（Agent）全面引入生产代码库后，我们并没有迎来软件工程的乌托邦，反而正在以惊人的速度，制造着前所未有的“屎山”和灾难。
今天，我想结合他的反思，以及我最近在使用 AI 原生开发时的一些切身痛点，给大家浇一盆冷水。在被大模型彻底“惯坏”之前，我们必须看清，过度依赖 Agent 正在如何毁掉我们的系统，甚至我们的职业生涯。
很多公司和独立开发者喜欢标榜：“我的产品 100% 是由 AI 写的。”
他们以为这是高科技的证明，但在行家眼里，这简直是灾难的代名词。
那些号称“完全脱手、让 Agent 自己去写”的代码库，往往充斥着你能想象到的最糟糕的垃圾：
高达几个 G 的内存泄漏、莫名其妙的 UI 闪烁、完全没有一致性的设计模式，以及一碰就碎的核心逻辑。
为什么会这样？难道现在的 AI 不够聪明吗？
原因在于：Agent 是“没有痛感”的，而人类有。
在传统的手工编码时代，人类程序员是一个天然的“物理瓶颈”。你一天最多只能写 500 行高质量代码。如果你在这个过程中犯了错（比如引入了某个不良的抽象，或者写了一个极其恶心的嵌套），你会立刻感到“痛苦”。
为了避免这种痛苦，你会花时间去重构，去梳理架构，或者因为被 Reviewer 骂了一顿而痛改前非。
痛苦，逼着人类去学习和进化，逼着系统保持在一个“可维护”的边界内。
但 Agent 呢？它是一台没有感情的打字机。
它可以在几分钟内拉出两万行代码。如果其中包含了一个微小的设计缺陷，它不会感到痛苦。相反，它会在你看不见的地方，将这个缺陷以成百上千倍的速度“复利式地放大（Compound）”。
等你回过神来，想要在这个 100% 由 AI 生成的系统上加一个新功能时，你会绝望地发现：你连它长什么样都不知道，而且它已经烂到连 AI 自己都改不动了。
有人可能会说：“既然 AI 能写屎山，那我再派一个高级 Agent 去重构这堆屎山不就行了？”
这就是当下最可怕的“平替思维”陷阱。
现实是：当代码的复杂度和体积膨胀到一定程度后，AI 的“召回率（Recall）”会呈现断崖式下跌。
这不仅仅是上下文窗口大小（Context Window）的问题。在拥有百万行代码的迷宫中，Agent 根本不知道该去哪里找相关的依赖，不知道哪些旧代码可以复用。它只能基于极其局部的视野（Local View）去做决策。
这就导致了极度荒谬的现象：Agent 在重构时，不仅找不到病根，反而会发明出更多为了抽象而抽象的垃圾代码，让屎山开出更加绚丽的“奇葩”。
人类制造企业级的屎山，需要几十个程序员耗费好几年的时间来堆砌；
而你，只需要带上 2 个 AI Agent，几个星期就能搞出一个连上帝都看不懂的废墟。
当你发现连号称 100% 覆盖率的 AI 测试用例都在撒谎时，除了手动去点产品、祈祷它别崩溃，你已经失去了对系统的任何掌控力。
难道我们要砸烂电脑，退回到手敲汇编的时代吗？当然不是。
Agent 就像古希腊神话中的海妖塞壬（Sirens），用极速的快感诱惑着你。我们必须在它摧毁我们的工程纪律之前，重新夺回主动权。
真正的顶级开发者，绝不会对 AI 说：“嘿，帮我把这个系统全干了。”
他们与 Agent 的协作，遵循着极其严苛的边界：
1. 坚决把控“系统的整体结构”
什么是系统的整体结构？那是你的核心架构设计、API 的边界、数据库的实体关系，以及整个系统跑起来时的“手感”。
这些东西，必须由你亲手来写，或者通过 Pair Programming（结对编程）一行一行地推敲。
只有亲手写过，感受到那份“摩擦力”，你才能在脑海中建立起对系统的上帝视角。这是目前任何 SOTA（最先进）大模型都无法替代的品味与经验。
2. 让 AI 去干“不用动脑子”的脏活
Agent 最适合的场景，是那些不需要全局视野的局部任务：写一段正则、爬个数据、写几条枯燥的单元测试，或者是写一个就算坏了也不影响公司赚钱的内部临时脚本。
把时间花在“决定做什么”和“决定不做什么”上。学会对需求说“不”，本身就是最高级的特性。
3. 强制减速
这是最反直觉，也是最重要的一条建议。
不要为了追求那虚荣的“代码生成量”而沾沾自喜。给自己设定一个限制：每天 AI 生成的代码量，绝对不能超过你“能够深入 Review 和理解”的极限。
你必须确保，如果明天所有的 AI 公司突然破产，你依然能从容地接管这个系统，因为它的每一根骨架，都在你的掌控之中。
在过去的一年里，我们把太多的权力让渡给了机器，以至于我们忘记了软件工程的本质。
在这个鼓吹“快、更快、再快一点”的癫狂时代，慢下来，反而成了最稀缺的竞争力。
你的代码可能不再是纯手工敲出来的了，但你的架构品味、你的工程纪律、你在出 Bug 时能一针见血找到根源的敏锐直觉，才是你在这个时代安身立命的根本。
一切自动化，最终都需要人类的纪律（Discipline）与主体性（Agency）来兜底。
机器可以写代码，但只有人类，才能为系统注入灵魂。
资料链接：https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down
今日互动探讨：
在日常开发中，你有没有遇到过被 AI 生成的“看似完美、实则藏雷”的代码坑得很惨的经历？你是怎么发现并解决的？
在 AI 编程的浪潮中，你觉得人类程序员最不可被替代的核心能力是什么？
欢迎在评论区分享你的血泪史与思考！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-03-28 08:18:15
本文永久链接 – https://tonybai.com/2026/03/28/ai-engineer-gpu-introduction-course
大家好，我是Tony Bai。
就在最近，科技界发生了一件极其戏剧性的事情。本周三美股开盘，全球存储产业巨头——美光、西部数据、希捷的股价遭遇了“黑色时刻”，普遍明显下跌（3%~6%）。
引发这场资本市场大地震的，不是什么贸易战，也不是财报暴雷，而仅仅是谷歌（Google Research）发布的一篇技术论文：《TurboQuant: Redefining AI efficiency with extreme compression》。
这篇论文宣称，他们发明了一种极端的压缩算法，能在几乎零损耗的情况下，将大模型推理时的 KV 缓存（KV Cache）暴降 6 倍，并让注意力机制的计算速度狂飙 8 倍！
很多传统的后端程序员看到这条新闻，可能一头雾水：
在这些雾水和疑惑背后，隐藏着 AI 大模型时代最核心、也最残酷的技术真相：内存墙（Memory Wall）。
在传统的软件开发中，我们习惯了用 CPU 的思维去思考性能。我们认为程序跑得慢，是因为“计算太复杂”，我们需要更强的算力（更快的 CPU 频率）。
但在大语言模型（LLM）的世界里，逻辑变了。
大模型在生成文本时，是逐字生成（自回归）的。为了不每次都把前面说过的话重新计算一遍，模型会把之前所有上下文的内部特征（Key 和 Value 矩阵）全部保存在显存里。这份庞大的“运行记忆”，就是 KV Cache。
随着上下文越来越长（比如从 4K 飙升到 128K 甚至百万级），这份 KV Cache 会像滚雪球一样膨胀。
这就是为什么业界说：KV Cache 是大模型推理名副其实的“吞金兽”。
更要命的是，每次生成一个新的字，GPU 都必须把这份庞大的 KV Cache 从显存（HBM）完整地搬运到计算核心（SRAM）里过一遍。
这就好比你有一个世界上切菜最快的厨师（GPU 算力），但他每次切一片肉，都要跑到 10 公里外的仓库（显存）去取。厨师的手速再快也没有用，整体速度完全被运货卡车的速度（显存带宽）锁死了。
这就是困扰所有 AI 工程师的 “内存墙”。也是为什么各大公司疯狂抢购高显存、高带宽的 H100 显卡的原因。
而谷歌的 TurboQuant 之所以引发地震，正是因为它通过极致的数学算法（极坐标变换 + 1-bit 残差误差校验），直接在软件层面把搬运的数据量压缩了 6 倍！这意味着，同样的硬件，现在能跑更长的上下文、支持更高的并发。存储巨头们能不慌吗？
你可以说：“我只是个调 OpenAI 兼容API 的后端工程师，硬件底层关我什么事？”
在过去的一年里，这是行得通的。但随着开源模型（如 GLM、Qwen、MiniMax、DeepSeek、KIMI等）的全面爆发，以及企业对数据隐私、成本控制的极致追求，“本地化/私有化部署大模型” 也正在成为一些中大型企业的刚需。
当你作为架构师或后端主力，被老板要求把一个 70B 的大模型部署到公司的服务器上时，真正的挑战才刚刚开始：
如果你把 GPU 当成一个“跑得更快的 CPU”来用，你将会在上述每一个问题上栽大跟头。
你需要建立一套全新的“硬件心智模型”，这也是我编写这门《AI 工程师的 GPU 入门课：从硬件视角看大模型推理》微专栏的主要目标。
市面上关于 GPU 和 CUDA 的教程很多，但大多是教你如何写出复杂的 C++ 图形渲染代码，或者如何在学术上推导矩阵乘法。
这门微专栏与众不同。它是专为后端/软件工程师打造的“白盒化” GPU 入门课程。
我们不教图形渲染，不深究复杂的 C++ 语法。我们将直接切入大模型推理的痛点，带你一步步从物理架构走到前沿的 AI 工程技术。
为了让你对这趟旅程有一个清晰的预期，以下是本专栏的完整地图：
第一阶段：硬件心智模型
* 第 01 讲 | 硬件解剖：为什么 CPU 是“法拉利”，GPU 是“大巴车”？（含 5090 vs H100 对比）
* 第 02 讲 | 内存金字塔：HBM、SRAM 与不可逾越的“内存墙”
第二阶段：编程模型与工具链
* 第 03 讲 | CUDA 编程模型：指挥“千军万马”的线程艺术
* 第 04 讲 | 性能侦探：性能侦探：拆解 Hello World Kernel 与 Profiling 实战
第三阶段：AI 工程进阶
* 第 05 讲 | 显存管理革命：从 KV Cache 到 PagedAttention (vLLM)
* 第 06 讲 | 算子融合魔法：FlashAttention 的底层原理
* 第 07 讲 | 精度与量化：精度与量化：INT8/FP8 为什么既快又省？
* 第 08 讲 | 分布式推理：Tensor Parallelism (TP) 与通信墙
* 第 09 讲 | 终极指南：如何科学计算 AI 算力需求与硬件选型？
特别加餐：Gopher 的专属浪漫
* 第 10 讲 | 加餐：Go 语言的 GPU 编程——Gopher 的逆袭
在算力的装备竞赛里，最锋利的武器未必是更昂贵的芯片，而是深刻理解软硬件边界的人。
正如谷歌 TurboQuant 证明的那样：懂底层的工程师，只需改写一行底层逻辑，就可能撬动万亿级别的市场价值。
算力时代，不要只做“调包”的局外人。
准备好跨越 CPU 的舒适区，跟我一起深入算力的硅基心脏了吗？
点击这里或扫描下方二维码，开启你的GPU与AI推理工程的入门之旅：
我将在第一讲等你。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
