最佳实践 - Tony Bai

标签最佳实践下的文章

还在当“上下文搬运工”？我写了一门课，帮你重塑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），仅限首周。

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

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

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

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

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

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

Go 标准库将迎来 Zstandard：性能超越 Gzip，让你的应用更快、更省

十一月 8, 2025
2 条评论

本文永久链接 – https://tonybai.com/2025/11/08/proposal-zstd

大家好，我是Tony Bai。

在 Go 的世界里，一项被社区翘首以盼的提案在沉寂一年后，终于迎来了决定性的进展。2024 年，将 Zstandard 压缩算法纳入标准库的提案（#62513）被正式 Accept，但在那之后便鲜有动静。直到最近的 Go 编译器与运行时会议纪要中透露，这项工作将由社区的明星开发者 Klaus Post 主导推进。

这意味着，在未来的 Go 版本中，开发者将能开箱即用地获得一个官方维护、安全可靠且性能卓越的压缩工具。这不仅是对 Go 生态的一次重要补强，更将直接为无数 Go 应用带来性能提升、带宽节约和成本削减，真正实现“更快、更省”的承诺。

同时，这个提案背后曲折的历程——从激烈的技术选型辩论，到精雕细琢的 API 设计，再到因核心团队资源紧张而搁置，最终由社区力量重新激活——本身就是一幅展现 Go 生态演进的生动图景。

在本文中，我们将探讨 Zstandard 脱颖而出的技术优势，剖析其在工业界的成功案例，并揭示 compress/zstd 标准库从提案、API 设计到最终由社区力量重启的完整历程。

Zstandard：为何是它，而非其他？

在决定为标准库引入新的压缩算法时，Go 团队面临着众多选择。提案发起者 dsnet 在讨论中进行了一次精彩的“选美”，清晰地阐述了为何 Zstandard (Zstd) 能够脱颖而出：

Zstandard (Zstd): 由 Facebook (现 Meta) 开发并开源，拥有极佳的压缩/解压速度和出色的压缩比。更重要的是，它有正式的 RFC 规范（RFC 8878），这对于标准库实现的“正确性”至关重要。
Brotli: 同样优秀，但在设计上更偏向 Web 静态内容，且其庞大的静态字典（约 120KiB）与 Go 追求小体积静态二进制文件的哲学相悖。
XZ (LZMA): 拥有极高的压缩比，但代价是极其缓慢的压缩和解压速度，不适合通用场景。且缺乏正式的、明确的规范。
Snappy / LZ4: 追求极致的速度，但在压缩比上做出了巨大牺牲，应用场景相对小众。

Zstd 巧妙地结合了 LZ77 算法和一种名为 ANS (Asymmetric Numeral Systems) 的现代熵编码技术，在性能、压缩比和资源消耗之间取得了近乎完美的平衡，使其成为替代 Gzip 的“天选之子”。

注：截至Go 1.25.3版本，Go compress目录下提供了多种压缩算法的实现：bzip2实现了Burrows-Wheeler变换及霍夫曼编码；flate提供了DEFLATE算法核心，结合了LZ77和霍夫曼编码；gzip和zlib则分别将DEFLATE算法封装为gzip文件格式和zlib数据流格式；lzw实现了Lempel-Ziv-Welch算法。这些包共同为Go语言提供了多样化的数据压缩与解压缩能力。

注：Zstandard最新RFC规范为RFC 9659。

工业界验证：Discord 与 Cloudflare 的性能飞跃

理论上的优势必须经过实践的检验。Zstd 在工业界的应用早已硕果累累。

**Discord 的 40% 带宽削减：** 通讯巨头 Discord 在将其实时网关的压缩算法从 zlib (Gzip) 迁移到流式 Zstandard 后，获得了惊人的收益。对于核心的 MESSAGE_CREATE 事件，压缩时间缩短了一半以上，负载体积也显著减小。这直接转化为更低的服务端 CPU 占用和客户端带宽节省，最终实现了 整体 Websocket 流量降低 40% 的壮举。
**Cloudflare 的容器镜像加速：** 在其全球容器平台上，Cloudflare 需要快速分发巨大的 AI 模型镜像（常超过 15GB）。通过将镜像层压缩算法从 Gzip 更换为 Zstd，一个 30GB 镜像的拉取时间从 8 分钟骤降至 4 分钟，速度翻倍，极大地提升了全球调度的灵活性和响应速度。

这些案例雄辩地证明，Zstd 是为现代高吞吐量、低延迟应用而生的。

API 设计的艺术：一场关于简洁、安全与未来的辩论

将新包引入标准库，API 的设计是重中之重。#62513 的讨论串完整记录了 compress/zstd API 从雏形到最终形态的演进过程。

核心原则：安全与一致性

提案伊始，就确立了两大基石：

安全优先： 标准库实现必须是纯 Go版本，不使用 unsafe 或汇编。dsnet 强调：“Go 社区调查一致显示，安全性比性能更重要。” 这意味着标准库版本追求的是可审查性、可维护性和跨平台的一致性，而非极致的性能。
API 一致性： 新 API 应与 compress/gzip、compress/flate 等现有包保持风格统一，降低开发者的学习和迁移成本。

社区的声音：Klaus Post 的关键输入

在讨论中，github.com/klauspost/compress 系列库的作者 Klaus Post 扮演了关键角色。他的库是 Go 社区公认的最高性能压缩实现，其丰富的实战经验为标准库的设计提供了宝贵视角。

Klaus 指出，他自己的库 API 相对复杂，是因为支持多线程、异步等高级特性。他赞同标准库应剥离这些复杂性，提供一个完全同步的、线程安全的 API。同时，他也对字典（Dictionary）功能的 API 设计提出了深刻见解，强调了字典预处理的开销问题，这直接影响了后续 API 的设计。

最终定稿的 API

经过多轮讨论，由 Russ Cox (rsc) 总结并最终被接受的 API 形态如下(并非最终版)：

package zstd

const (
    NoCompression      = 0
    BestSpeed          = 1
    BestCompression    = 9
    DefaultCompression = -1
)

type Dict struct { /* ... */ }
func ParseDict(enc []byte) (*Dict, error)
// ... 可能还包含 Marshal/Unmarshal 方法

type Reader struct { /* ... unexported fields ... */ }
func NewReader(r io.Reader) (*Reader, error)
func (z *Reader) Reset(r io.Reader) error
func (z *Reader) AddDict(*Dict)
func (z *Reader) SetRawDict([]byte)
func (z *Reader) Read(p []byte) (int, error)
func (z *Reader) Close() error

type Writer struct { /* ... unexported fields ... */ }
func NewWriter(w io.Writer) *Writer
func (z *Writer) Reset(w io.Writer)
func (z *Writer) SetLevel(int) error
func (z *Writer) AddDict(*Dict)
func (z *Writer) SetRawDict([]byte)
func (z *Writer) Write([]byte) (int, error)
func (z *Writer) Flush() error
func (z *Writer) Close() error

这个设计体现了 Go 标准库的哲学：

Setter 模式： 采用 SetLevel、AddDict 等方法进行配置，而不是更复杂的构造函数重载或函数式选项，兼顾了灵活性和简洁性。
独立的 Dict 类型： 将字典抽象为 Dict 类型，通过 ParseDict 进行预处理。这解决了 Klaus 提出的“重复解析字典开销大”的问题，允许用户一次解析，多次复用。
错误处理： 关键配置（如 SetLevel、ParseDict）返回 error，增强了 API 的健壮性。

漫长的等待与社区英雄的登场

提案于 2024 年被接受，为何直到 2025 年底才真正启动？这背后反映了 Go 核心团队面临的现实挑战。Go 团队规模精简，核心成员的精力需要分配给语言、编译器、运行时等更高优先级的任务。提案发起者 dsnet 也深度参与了 json/v2 等重大项目，无暇分身。

在此期间，Klaus Post 主动请缨，表示愿意贡献一个精简版的、符合标准库要求的实现。然而，这个提议在当时并未得到明确的推进信号。

转机出现在 2025 年 11 月的 Go 团队内部会议。纪要显示，团队终于有带宽来审查社区对 compress/flate 和 compress/zstd 的贡献。会议明确提到：“很高兴有社区审查。我们能去问问 k8s 的人吗？”（意指寻求更多社区的反馈和测试）。这标志着官方正式为 Klaus Post 的贡献打开了大门。随后Klaus Post也给出了自己的贡献时间表，大约在2026年Q1提交第一版实现给Go团队审查。