2025-12-17 15:15:40
本文永久链接 – https://tonybai.com/2025/12/17/ai-programming-90-percent-trap-generation-vs-bug-fix
大家好，我是Tony Bai。
在 AI 辅助编程普及的第三年，我观察到一种奇怪的现象，我称之为“AI 时代的开发疲劳”。
很多开发者跟我抱怨：
“一开始觉得 AI 简直是神，几秒钟就能生成一个模块。但用久了发现，它生成的代码总是‘乍一看很完美，一跑全是坑’。
简单的逻辑还能应付，一旦涉及到复杂的业务重构，它写的代码往往是 90% 可用，剩下 10% 充满了隐蔽的 Bug、过时的库引用和糟糕的结构。
结果是：AI 帮我省了 30 分钟敲代码的时间，我却花了 2 小时去 Review 和填坑。”
这就是典型的“90% 陷阱”。
很多人将其归咎于“模型还不够强”，期待下一代 GPT 或 Claude X Opus 能彻底解决问题。
但作为一名长期研究 AI 原生工作流的架构师，我要告诉你一个残酷的真相：
问题不在模型，而在你的工作流。
大多数人还在用“抽盲盒”的方式在通过聊天框（Chat）写代码——这叫 Vibe Coding（氛围编程），而不是 Engineering（工程）。
要跨越这最后 10% 的死亡谷，我们需要把 AI 开发从“聊天”升级为“工程”。以下是我总结的三个核心法则。
为什么 AI 总是记不住你的代码规范？为什么它总是喜欢用 any 类型，或者引入你明令禁止的第三方库？
因为你把 AI 当成了“搜索引擎”，而不是“新入职的员工”。
每次开启一个新的 Chat Session，对 AI 来说都是第一天入职。如果你不给他发一本“员工手册”，它当然会按照通用的（平庸的）标准来写代码。
破局之道：固化上下文（Context Pinning）。
在 AI 原生开发中，项目根目录下的 规则文件（如 .cursorrules 、CLAUDE.md或constitution.md等）是项目的灵魂。
这不是简单的 Prompt，这是你的架构宪法。
把规则文件看作是 Live Documentation（活文档）。它是你项目架构、代码风格和最佳实践的“唯一真理来源”。有了它，AI 就不再是那个健忘的实习生，而是懂你习惯的资深搭档。
许多人使用 AI 的方式是：直接把一坨复杂的代码扔进去，说“帮我重构它”。
这违背了软件工程的分治思想。LLM 的推理能力是有限的，当它同时兼顾“理解旧逻辑”、“设计新架构”和“编写具体代码”时，它的注意力（Attention）会发散，导致逻辑坍塌。
破局之道：Plan Mode（规划模式）。
高效的 AI 工作流必须将 Planning（规划） 和 Coding（编码） 物理分离。
阶段一：架构师模式（The Architect）
阶段二：泥瓦匠模式（The Builder）
不要试图 One-shot（一次性）解决复杂问题。 把大任务拆解为小任务，用文档（Markdown）作为上下文传递的介质，这才是工程化的正解。
“我怎么知道 AI 写的代码有没有隐藏 Bug？”
答案是：你永远不应该信任 AI 写的代码，除非它通过了测试。
在传统开发中，TDD（测试驱动开发）可能显得繁琐。但在 AI 时代，TDD 是性价比最高的“电子围栏”。
破局之道：Spec-Driven TDD。
通过 TDD，我们将对 AI 输出质量的“人工主观判断”，转化为了“计算机客观验证”。你不需要肉眼盯着每一行代码，你只需要盯着绿色的 PASS。
AI 编程的门槛正在急剧降低，但交付高质量软件的门槛并没有变。
那种“凭感觉”随便聊两句就能搞定项目的 Vibe Coding 时代即将过去。未来属于那些懂得如何用文档约束上下文、用规划拆解复杂度、用测试兜底质量的 AI 工程师。
不要沉迷于 AI 的生成速度，要掌控系统的工程质量。
深度实战：构建你的“AI 原生工作流”
理念已经清晰，但落地还需要工具和技巧的支撑：
如果你不想再被“90% 陷阱”折磨，希望从“拼运气的聊天者”进化为“掌控全局的架构师”，欢迎关注我的极客时间专栏《AI 原生开发工作流实战》。
这不仅仅是一门工具教程，更是一套面向 AI 时代的软件工程方法论。我将带你把这些工程法则转化为可落地的 SOP，真正实现 10x 效率跃迁。
扫描下方二维码，让 AI 真正为你所用。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-17 08:25:45
本文永久链接 – https://tonybai.com/2025/12/17/cloudflare-2025-report-go-language-api-traffic-ai-surge
大家好，我是Tony Bai。
近日，互联网基础设施巨头 Cloudflare 发布了其备受瞩目的《2025 年度互联网回顾报告》。这份基于其全球庞大网络数据的报告，如同一面镜子，映照出全球互联网在流量、技术、安全和 AI 等领域的最新脉搏。
而对于我们 Go 开发者而言，今年的报告带来了两个极其振奋人心的消息：
本文将为你深度解读这份报告中，与我们 Gopher 息息相关的核心亮点。
在现代应用架构中，自动化 API 请求（即服务与服务之间的机器通信）早已成为流量的主体。而构建这些 API 客户端的编程语言，其流行度直接反映了该语言在后端和基础设施领域的真实“统治力”。
Cloudflare 的报告再次确认了一个我们早已熟知，但看到数据后依然会心潮澎湃的事实：Go 是自动化 API 客户端最受欢迎的选择。
关键数据解读：
五分之一的天下：在 2025 年，全球 20% 的自动化 API 请求，都是由基于 Go 的客户端发出的。这意味着，每五个飞驰在互联网上的自动化 API 请求中，就有一个是用 Go 编写的！
惊人的增长势头：这一数字，相较于 2024 年的 12%，实现了超过 66% 的惊人增长。Go 不仅是第一，而且正在以“断层式”的速度，进一步拉开与追赶者的差距。
竞争格局：Python 紧随其后，份额从 9.6% 增长到 17%。而去年排名第二的 Node.js，其份额则跌至 8.3%，被 Java (11.2%) 超越。
为什么是 Go？
这份数据雄辩地证明了 Go 在构建网络服务和客户端方面的核心优势：
如果说 Go 在 API 领域的领先是“意料之中”，那么报告中关于 AI 流量的爆炸式增长，则为 Go 的未来描绘出了一个更加激动人心的新战场。
报告指出，连续第三年，来自 Google IP 段 66.249.64.0/20 的流量，成为 Cloudflare 网络上最大的请求来源。这背后的“巨兽”，正是 Googlebot。
值得注意的是，Googlebot 已经演变成一个双重目的的爬虫：它不仅为传统搜索引擎建立索引，更在为 Google 的 AI 模型（如 Gemini）进行大规模的数据抓取和训练。
2025 年，Googlebot 贡献了超过 28% 的“已验证机器人”流量，其爬取量远超 OpenAI 的 GPTBot (7.5%) 和微软的 Bingbot (6%)。
报告将 AI 爬虫流量分为三类：训练 (training)、搜索 (search) 和用户行为 (user action)。其中，“用户行为”指的是当用户在 ChatGPT 等应用中提问，AI 为了回答问题而去实时访问外部网站所产生的流量。
2025 年，这类“用户行为”驱动的 AI 爬取流量，增长了超过 15 倍！
这预示着一个全新的互联网范式正在形成：越来越多的流量，将不再由人类直接发起，而是由 AI 智能体，为了服务于人类的需求而发起。
这对 Go 开发者意味着什么？
AI 模型本身或许由 Python 主导，但支撑这些模型进行大规模数据爬取、数据处理、模型服务（API serving）的庞大基础设施，正是 Go 语言大显身手的领域。
当你看到 ChatGPT、Perplexity 等服务的流量排名在“生成式 AI 服务”榜单中不断攀升时，可以想见，其背后必然有无数由 Go 编写的高性能 API 网关、数据管道和后端服务在默默支撑。
Cloudflare 的 2025 年度报告，为我们描绘了一幅激动人心的画卷。在这幅画卷中，Go 语言不仅是当前云原生和 API 经济的绝对王者，更是即将到来的 AI 时代不可或缺的核心基础设施构建者。
“五分之一的 API 请求由 Go 发出”——这个数据，不仅仅是一个值得骄傲的里程碑，更是对 Go 语言设计哲学——简单、高效、并发——在真实世界中取得巨大成功的最有力证明。作为 Gopher，我们正站在时代的潮头。
资料链接：
你的“体感”如何？
数据告诉我们，Go 正在制霸 API 领域。在你日常的工作中，是否也感受到了 Go 在微服务、网关或 AI 基础设施中的统治力？或者，你观察到了 Python 或 Rust 在哪些特定领域正在发起挑战？
欢迎在评论区分享你的一线观察，让我们一起拼凑出更真实的技术版图！
如果这篇文章让你对 Go 的未来更有信心，别忘了点个【赞】和【在看】，并转发给你的团队！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-16 08:33:57
本文永久链接 – https://tonybai.com/2025/12/16/go-1-26-foresight
大家好，我是Tony Bai。
随着2025年11月末 Go 1.26 开发分支的功能冻结（Feature Freeze），这份预计于 2026 年初发布的版本终于揭开了神秘面纱。
回望刚刚过去的两年，Go 语言经历了一段密集的“能力扩容期”。从 Go 1.21 对结构化日志与泛型库的标准化整合，到 Go 1.22 彻底修复循环变量语义，再到 Go 1.23 正式引入迭代器（Iterators）机制，Go 团队一直在致力于构建现代化的语言基础设施。这些改动虽然必要，但也让Go生态经历了一段漫长的消化与适配期。
而即将到来的 Go 1.26，则是一次回归工程本质的胜利。
这个版本没有引入重塑编程范式的颠覆性语法，而是将目光聚焦于那些开发者日夜相伴的痛点——在“看得见”的编码体验和“看不见”的底层性能上，进行了大刀阔斧的精细化打磨。
从彻底解决长期 GC 延迟痛点的 “Green Tea” 引擎，到大幅降低 Cgo 开销的底层优化，再到千呼万唤始出来的 new(expr) 语法糖。Go 1.26 用实际行动证明：在“后泛型时代”，Go 依然在追求极致性能与开发者幸福感的道路上狂飙。
本文将基于最新的发布说明，从语法、运行时、标准库及工具链四个维度，为你全景解读 Go 1.26 的核心变化，带你提前领略下个版本的技术魅力。
Go 语言在语法层面一向克制，但 Go 1.26 引入了一项极具实用价值的改动：内置函数 new() 现在支持表达式（Expression）作为操作数。
痛点场景：
在处理 JSON、Protobuf 或数据库 ORM 映射时，为了区分“零值”和“未设置”，我们经常使用指针（如 int、bool）。但在 Go 1.26 之前，创建一个指向常量的指针非常繁琐：
// Old (Go 1.25 及之前)
age := 18
u := User{
Name: "Alice",
Age: &age, // 必须先定义变量，因为无法对字面量取地址
}
Go 1.26 新体验：
现在，new 函数不仅分配内存，还允许直接利用表达式进行初始化。这让代码变成了声明式的“一行流”：
// New (Go 1.26)
u := User{
Name: "Alice",
// 直接传入字面量或函数返回值，返回对应类型的指针
Age: new(18),
// 甚至可以是计算结果
Days: new(calculateDays(startDate)),
}
这一改动极大地提升了编写配置结构体和序列化代码时的流畅度，消除了大量无意义的中间变量。更多详情，请参见《从 Rob Pike 的提案到社区共识：Go 或将通过 new(v) 彻底解决指针初始化难题》一文。
Go 1.26 在“看不见的地方”下了苦功，不仅引入了代号为“绿茶”的新一代 GC，还解决了 Cgo 和 Goroutine 泄露的两大难题。
在 Go 1.25 作为实验特性登场后，Green Tea GC 在 1.26 正式转正，成为默认垃圾回收器。
关于Green Tea GC的实现原理，可以参考《Go 官方详解“Green Tea”垃圾回收器：从对象到页，一场应对现代硬件挑战的架构演进》一文。
对于依赖 SQLite、图形库或其他 C 库的 Go 应用，这是一个巨大的利好。Go 1.26 将 Cgo 调用的基准运行时开销（Baseline Runtime Overhead）降低了约 30%。这意味着跨语言调用的成本进一步被摊薄，Go 在系统编程领域的竞争力再次提升。
注：我尚未从Go 1.26的milestone的issue列表中找到对应的该cgo提速所对应的issue。
Goroutine 泄露一直是 Go 并发编程中隐蔽且棘手的难题。虽然社区已有 uber-go/goleak 等优秀工具，但它们大多局限于单元测试场景，难以在复杂的生产环境中捕捉那些长期运行的“僵尸” Goroutine。
Go 1.26 引入的 goroutineleak Profile 则是这一领域的降维打击。该特性源自 Uber 的内部实践，旨在解决学术界称为“偏死锁（Partial Deadlocks）”的问题。
与传统工具简单统计 Goroutine 数量不同，该功能基于 GC 的可达性分析，复用了 Go 垃圾回收器（GC）的标记能力，但逻辑相反：
这种检测机制在理论上保证了零误报（No False Positives）。Uber 在内部对 3111 个测试套件进行了验证，相比传统工具多发现了 180 至 357 个不同类型的泄露；在某生产服务的 24 小时监控中，成功捕获了 3 个不同类别的真实泄露（共计 252 次报告）。
由于该功能涉及运行时的深层改动，目前作为实验特性发布：
这一特性意味着开发者终于拥有了在生产环境“在线”诊断 Goroutine 泄露的听诊器。
更多内容，可以参考《Goroutine泄漏防不胜防？Go GC或将可以检测“部分死锁”，已在Uber生产环境验证》一文。
编译器现在会生成针对特定大小的内存分配例程（Size-specialized memory allocation）。对于小于 512 字节的小对象，分配成本最高降低 30%。这对高并发、大量小对象的微服务场景有着普适性的性能提升（约为 1% 的端到端提升）。
更多关于Go内存管理演进的内容，可以参考《从arena、memory region到runtime.free：Go内存管理探索的务实转向》一文。
对于 Go 开发者而言，“栈分配（Stack Allocation）”由于无需 GC 介入，其效率远高于堆分配。
Go 1.26 的编译器进一步增强了逃逸分析能力：
更多内容，可以参考《PGO 驱动的“动态逃逸分析”：w.Write(b) 中的切片逃逸终于有救了？》一文。
标准库的更新主要集中在对新特性的适配（如迭代器）以及安全能力的补全。
紧随 Go 1.23 引入的 iter 包，反射库在 1.26 也迎来了现代化改造。
集成测试中产生的截图、日志或 Dump 文件终于有了官方的存放位置。
更多详情，请参考《Go testing包将迎来新增强：标准化属性与持久化构件API即将落地》一文。
这是高性能计算与密码学领域期待已久的功能。Go 1.26 引入了实验性的 simd 包，允许 Go 代码直接访问 CPU 的向量指令。
更多详情，请参考《解锁CPU终极性能：Go原生SIMD包预览版初探一文。
errors.As 一直是 Go 错误处理中容易“踩坑”的 API（需要传递指针的指针，否则会 Panic）。Go 1.26 引入了泛型版本的 errors.AsType，彻底解决了这个问题。
写法对比：
// Old: 容易写错，运行时反射
var pathErr *fs.PathError
if errors.As(err, &pathErr) { ... }
// New: 类型安全，性能更好
if pathErr, ok := errors.AsType[*fs.PathError](err); ok { ... }
更多背景详情，请参考《泛型重塑Go错误检查：errors.As的下一站AsA？》一文。
日志“扇出（Fan-out）”是常见需求（例如同时输出到控制台和文件）。
更多详情，请参考《slog 如何同时输出到控制台和文件？MultiHandler 提案或将终结重复造轮子》。
虽然 Dialer.DialContext 早已普及，但针对特定协议的拨号方法一直缺乏 Context 支持。
go tool pprof -http 打开的 Web UI 界面，现在默认展示火焰图 (Flame Graph)。这一改动反映了火焰图已成为性能分析的事实标准，开发者不再需要多点一次菜单切换视图。
Go 1.26 展现了 Go 团队在“后泛型时代”的工程重心：精细化打磨。
对于业务开发者，new(expr) 和 ArtifactDir 提供了触手可及的便利；对于平台工程师，Green Tea GC 和 Cgo 的优化则意味着免费的性能午餐；而对于库作者，反射迭代器和安全包的加入则拓展了能力的边界。
Go 1.26 预计将于 2026 年 2 月正式发布，现在即可使用 gotip 或Go playground尝鲜体验。
本文基于 Go 1.26 Draft Release Notes 整理，具体特性以最终发布版本为准。
聊聊你的期待
Go 1.26 看起来是一个“实惠”的版本，不仅有免费的性能提升，还有贴心的语法糖。在你看来，哪个新特性对你的日常开发帮助最大？或者，你对 Go 语言未来的发展还有什么更迫切的期待？
欢迎在评论区留下你的看法，让我们一起期待 Go 1.26 的正式到来！
如果这篇文章让你对 Go 的新版本有了更清晰的认识，别忘了点个【赞】和【在看】，并分享给身边的 Gopher 朋友！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
想系统学习Go，构建扎实的知识体系？
我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-15 07:42:30
本文永久链接 – https://tonybai.com/2025/12/15/go-language-anti-patterns-10-donts
大家好，我是Tony Bai。
“有哪些‘不要做’的教训，是你花了好几年才学会的？”
近日，在 r/golang 社区，这个简单的问题，引爆了一场关于 Go 语言“反模式”与“最佳实践”的集体反思。帖子下数百条评论，汇集了无数 Gopher 在真实项目中用“血与泪”换来的宝贵经验。这些教训，往往不是关于某个高深的算法，而是关于那些看似“理所当然”，却在不经意间为代码埋下地雷的日常习惯。
这篇文章，正是对这场集体智慧的一次系统性梳理。我们从中提炼出 10 条最核心的“不要做”法则，它们如同一份“避坑指南”，能帮助你绕开那些最常见的陷阱，更快地从一名“会写 Go 的程序员”，成长为一名“懂 Go 的工程师”。
Don’t overpackage things
初学者往往有一种冲动，想把代码组织成“语义化”的、层层嵌套的包结构。internal/models, internal/services, internal/repositories…… 这种源自其他语言（如 Java）的模式，在 Go 的世界里，往往是一种过早的、不必要的复杂性。
社区忠告：从一个 main.go 文件开始。努力思考，是否真的有必要将代码拆分到多个文件/包中。Go 的包，其主要目的是封装和依赖管理，而不是单纯的文件夹分类。在小型或中型项目中，一个清晰的、扁平的包结构，远比一个复杂的“企业级”目录树更易于维护。
Don’t just add in channels
并发是 Go 的“名片”，这使得许多开发者（尤其是新手）有一种“锤子心态”——看到任何问题，都想用 goroutine 和 channel 来解决。然而，不必要的并发，是复杂性和 bug 的温床。
社区忠告：
Don’t be zealous about DRY
DRY 是编程的基本原则，但在 Go 的哲学中，它有一个更重要的“上级”——清晰性。为了消除几行重复代码，而引入一个复杂的接口或一个晦涩的辅助函数，往往得不偿失。
社区忠告：“一点点复制，胜过一点点依赖 (a little copy-paste is better than a little dependency)。” 当你发现自己在为了 DRY 而绞尽脑汁时，请停下来问问自己：这份重复，是否真的带来了维护上的痛苦？如果不是，那么接受它，可能是一个更明智的选择。
Don’t refactor and add features in the same PR
在添加一个新功能时，顺手“优化”一下周围的代码，这看起来很高效。但实际上，这会让 Code Review 变得异常痛苦。Reviewer 无法清晰地分辨，哪些改动是为新功能服务的，哪些是纯粹的重构。这不仅增加了审查的难度，也提高了引入新 Bug 的风险。
社区忠告：遵循“童子军军规”——“让营地比你来时更干净”——是好的。但请将它分解为两个独立的、目标明确的 PR：一个只做重构，另一个（基于重构后的代码）只添加新功能。
Don’t skip writing tests “just this once”
这是所有开发者都曾屈服过的诱惑。“这个改动太小了”、“我百分之百确定它是对的”、“项目赶时间”…… 每一次“就这一次”的妥协，都在为未来的“技术雪崩”添砖加瓦。
社区忠告：将测试视为代码不可分割的一部分。在 Go 中，编写测试是如此简单和自然，以至于没有任何借口可以跳过它。你今天节省下来的 10 分钟，可能会在未来，让你或你的同事，花费数天时间去调试一个本可避免的生产问题。
channel 非常强大，但它并非解决所有并发同步问题的“银弹”。社区中有一种“反 sync”的情绪，认为所有同步都应该用 channel 来完成。
社区忠告：sync.Cond 是一个被低估了的、极其强大的并发原语。当你需要基于某个特定条件来唤醒一个或多个等待的 goroutine 时（例如，一个任务队列的消费者在队列为空时等待），sync.Cond 往往比用 channel 实现的复杂信令机制，要更简单、更高效。不要因为不熟悉，就回避它。
Returning interfaces. Don’t do it.
在函数签名中返回一个接口，看似遵循了“依赖倒置”的高级原则，甚至觉得这样更“灵活”。但实际上，这往往是一种过早的、有害的抽象。它剥夺了用户访问底层具体类型特有功能的能力，并且如果未来需要添加新方法，接口的变更会极其痛苦。
社区忠告：遵循 Go 的经典谚语：“接收接口，返回结构体 (Accept interfaces, return structs)。”
经典范例：
看看标准库中的 os.Open，它返回的是 *os.File（具体结构体），而不是 io.Reader（接口）。
* 为什么这样做？ 因为 *os.File 不仅能读（Read），还能关闭（Close）、获取状态（Stat）、甚至改变权限（Chmod）。
* 灵活性：如果它返回的是接口，用户就无法使用 Chmod 等特有功能了。而返回结构体，用户既可以使用其全部功能，也可以在需要时，轻松地将其赋值给 io.Reader 接口来使用。这就是“返回结构体”带来的自由。
(注：只有当返回的类型是包内私有的、不希望外部直接访问的实现细节时，返回接口才是有意义的，例如 context.WithCancel 返回的是 Context 接口。)
Don’t add dependencies without vetting
为了解决一个小问题，而引入一个庞大的、闪亮的第三方库。这在 Node.js 生态中很常见，但在 Go 社区，这通常被视为一种“危险信号”。
社区忠告：
Don’t do [or not do] something simply because an authoritative voice recommended it
盲目地遵循某个“大神”、某篇“爆款”博客文章、或者某个“权威”推荐的模式，而没有结合自己的具体场景进行批判性思考。
社区忠告：上下文决定一切。YAGNI (You Aren’t Gonna Need It) 是一个好原则，但有时你确实需要提前设计。微服务很好，但有时单体就是最佳选择。没有银弹。最好的实践，是那些在你的团队、你的项目中，被证明行之有效的实践。
忘记了代码的最终读者是人类，而不是编译器。编写只有自己能看懂的“聪明”代码，或者忽略文档和注释的重要性。
社区忠告：
这份清单，远非全部。社区的讨论中还充满了诸如“不要用 singleton 来做 mock”、“不要滥用 init 函数”、“不要在疲劳时 Review 代码”等无数宝贵的经验。
它们共同指向了一个核心思想：成为一名优秀的 Go 工程师，其过程不仅仅是学习语言的特性，更是一个不断反思、不断“踩坑”、并从“坑”中总结出属于自己“不要做”清单的修炼过程。希望这份来自社区的集体智慧，能让你在这条路上，走得更稳、也更远。
资料链接：https://www.reddit.com/r/golang/comments/1pib68y/whats_a_dont_do_this_lesson_that_took_you_years/
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-14 08:02:02
本文永久链接 – https://tonybai.com/2025/12/14/dont-let-ai-put-your-brain-cpu-in-wait
大家好，我是Tony Bai。
先问一个扎心的问题：当你给 ChatGPT、Cursor 或 Claude Code 发送了一个复杂的 Prompt 之后，接下来的 30 秒到 1 分钟里，你在干什么？
我观察过很多开发者，90% 的人是这样的：
双手离开键盘，甚至抱在胸前，眼睛死死盯着屏幕上那个闪烁的光标，看着文字一个字一个字地蹦出来。心里默默念叨：“快点，再快点……”
在计算机科学里，这叫什么？
这叫 I/O 阻塞（Blocking I/O）。
在这个场景里，AI 是那个慢速的 I/O 设备（就像早期的磁带机或机械硬盘），而你——拥有几十亿神经元、算力无法估量的人类大脑（CPU），却因为等待这个 I/O 响应，被迫挂起（WAIT），处于完全闲置的状态。
这不仅仅是时间的浪费，这是算力的极大浪费。
很多开发者抱怨：“AI 有时候太慢了，打断了我的思路。”
但事实的真相可能是：不是 AI 慢，而是你的“调度算法”还停留在单核时代。
随着 AI 能力的普及，代码生成的质量差距正在缩小。未来的竞争壁垒，将从“你会写什么 Prompt”转移到“你如何管理与 AI 的并发交互”。
这导致了两种工作模式的分化，我们可以通过下面这张 “大脑CPU” 调度时序图来直观对比：
模式 A：单核工作者（同步阻塞）
* 特征： 就像单核 CPU 跑单线程程序。发完指令后，必须盯着屏幕等结果，算力被强行挂起（Wait）。
* 痛点： 图中红色的区域就是被浪费的生命。只要 AI 稍微卡顿，你的工作流就被切断了。
模式 B：多核工作者（异步并发）
* 特征： 就像现代操作系统的分时调度（Time-sharing）。人脑作为 OS Scheduler，维护着多个任务的状态。
* 优势： 图中绿色的区域显示，当 AI 在后台“搬砖”时，你的大脑立刻切换（Switch）到下一个任务（编写 Spec B）。
* 收益： 在 AI 响应延迟短期内无法消除的前提下，模式 B 的产出效率是模式 A 的 2 倍甚至更多。
既然“多核模式”效率极高，为什么 99% 的人做不到呢？
核心难点在于“上下文切换（Context Switching）”的成本。
做过底层开发的都知道，CPU 在切换线程时，必须执行一个昂贵的操作：Save Context（保存现场）和 Restore Context（恢复现场）。
人脑也是一样，甚至更弱。
根据认知心理学的“米勒定律”，人类的工作记忆（Working Memory，相当于 CPU 的 L1 Cache）容量极小，只有 7±2 个单位。
当你从“编写 Go 后端”切换到“调试 Vue 前端”时，你的 L1 Cache 会瞬间被清空。等你切回来时，你需要重新阅读代码、重新回忆变量名——这个过程就是“冷启动”，极度消耗能量。
所以，要实现高效的“人脑并发调度”，我们不能靠死记硬背，必须利用第一性原理优化我们的交互协议。
计算机如何解决内存不足的问题？虚拟内存（Swap）。 把不用的数据换出到硬盘里。
我们要模仿这个机制。不要试图在脑子里维持与 AI 的对话状态。
凡是发给 AI 的任务，必须是一个“全量的、自包含的数据包”。在这个数据包里，包含了 AI 完成任务所需的所有背景、约束和目标。
一旦发送出去，你的大脑应当能彻底遗忘（Forget）这个任务，清空 L1 Cache 去处理下一个线程，直到收到“完成”的中断信号。
目前的“Chat 模式”是典型的有状态（Stateful）交互。你必须记得上一句说了什么，下一句才能接得上。这是并发的天敌。
高效的调度算法要求我们采用无状态（Stateless）交互。
每一次与 AI 的交互，都应该是一次独立的 API 调用。我不关心你记不记得上下文，我会在这一次指令中把上下文重新传给你。
我们可以用一张系统架构图来理解这种“大脑调度优化”：
结论很明显：
要让大脑 CPU 不阻塞，关键不在于你思考得有多快，而在于你是否拥有一个“外部存储（External RAM）”机制。
你需要一种介质，能够帮你低成本地固化上下文，让你敢于放手（Fire），也方便你随时捡起（Resume）。
那么，在软件工程领域，这种“固化上下文的介质”叫什么呢？
答案就是 Spec（规范说明书）。
而这种全新的开发范式，我们称之为 SDD (Spec-Driven Development，规范驱动开发)。
目前主流的“Chat-based Coding”本质上是同步且有状态的。
你输入：“把这个函数改一下。”
AI 问：“改成啥样？”
你回：“像上次那个一样。”
这就完了。 你的大脑被迫挂载了海量的历史上下文，你必须在线，必须记得“上次”是指哪次。一旦去回个邮件，回来你就断片了。
在 SDD 工作流中（特别是配合像 Claude Code、Gemini Cli 这样的新一代 CLI 编码智能体工具），交互模式发生了质变：
让我们看下这张 SDD 并发工作流时序图：
Spec，就是你发给后台进程的“异步数据包”。它让你的大脑从“内存条”变成了高效的“调度器”。
除了思维的升级，你必须掌握一套支持“异步并发”的开发工具链。
如果你还在用浏览器里的聊天窗口写代码，你依然很难摆脱“I/O 阻塞”。
真正的解法，是构建一套基于 Claude Code/Gemini Cli… 的 SDD 工作流。
这不仅是工具的改变，更是软件工程的回归——从“堆砖头（Coding）”回归到“画图纸（Architecting）”。
这才是多核工作者的终极形态：你负责定义世界（Spec），AI 负责构建世界（Code）。
如果你想彻底掌握这套方法论，从“单核等待”进化到“多核并发”，欢迎关注我的极客时间专栏《AI 原生开发工作流实战》。
在这个专栏里，我将带你深入基于工具和新范式的实战：
别再盯着光标发呆了。写好 Spec，剩下的交给 AI。 扫描下方卡片，开启你的多核开发之旅。
聊聊你的“并发”状态
你是否也曾陷入过那种“盯着光标发呆”的单核陷阱？在你的日常工作中，你是如何处理AI响应那几十秒的“真空期”的？ 是切屏摸鱼，还是有自己独特的“上下文切换”技巧？
欢迎在评论区分享你的“多核”心得或“阻塞”吐槽！ 让我们一起寻找最高效的人机协作模式。
如果这篇文章让你对AI编程有了全新的认知，别忘了点个【赞】和【在看】，并转发给身边那个还在“单核”工作的朋友！
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
