本文永久链接 – https://tonybai.com/2025/12/20/ai-coding-era-productivity-leap-2025-developer-ecosystem-report

大家好，我是Tony Bai。

“如果你觉得今年的 PR (Pull Request) 变大了，你的感觉是对的。如果你觉得代码写得更快了，这也是对的。事实上，整个软件开发的节奏，正在被 AI 全面重塑。”

近日，Greptile 发布了《2025 年 AI 编码现状报告》(The State of AI Coding 2025)。这份基于大量真实开发数据的报告，为我们描绘了一个令人兴奋，同时也充满挑战的新世界。AI 不再是一个锦上添花的辅助工具，它正在成为驱动工程效能指数级增长的核心引擎。

本文将带你深入解读这份报告的核心发现，看看在 AI 的加持下，软件工程正在发生怎样的巨变。

生产力的“大跃进”——数据不会说谎

报告中最直观、也最令人震撼的，是关于工程效能 (Velocity) 的数据。AI 工具的普及，正在让开发者以一种前所未有的速度产出代码。

代码产出量激增 76%

数据显示，开发者的平均代码产出量，从 年初的 4,450 行/人，飙升到了年底的 7,839 行/人。

这是一次 76% 的惊人增长。AI 就像是一个不知疲倦的“外挂”，让每一位开发者都变成了“高产作家”。

PR 变得更大、更密集

这种生产力的提升，直接反映在代码提交的形态上：

• PR 规模变大：PR 的中位数大小从 57 行增加到了 76 行 (+33%)。
• 信息密度更高：每个文件的修改行数增加了 20%。

这意味着，开发者不再是小心翼翼地修补代码，而是更有底气进行大刀阔斧的重构和功能开发。AI 赋予了我们处理更大上下文、更复杂逻辑的能力。

中型团队受益最大

有趣的是，6-15 人的中型团队成为了这场变革的最大赢家，其人均产出增长了 89%。这或许暗示了，在这个规模下，沟通成本尚在可控范围，而 AI 带来的单兵作战能力提升被最大化地释放了出来。

工具链的“军备竞赛”——谁是赢家？

在 AI 工具的生态位之争中，我们也看到了一些明显的赢家和趋势。

AI 记忆 (Memory) 的崛起

随着 AI 应用变得越来越复杂，如何让 AI “记住”上下文成为了关键。报告显示，mem0 以 59% 的市场份额，在 AI 记忆基础设施领域占据了绝对的统治地位。这表明，开发者正在从简单的“问答式”交互，转向构建具有长期记忆和个性化能力的智能体。

向量数据库的“战国时代”

与记忆领域的“一家独大”不同，向量数据库市场呈现出群雄逐鹿的态势。Weaviate 虽然以 25% 暂时领先，但还有 6 个竞争对手（如 Pinecone, ChromaDB, pgvector 等）的市场份额都在 10%-25% 之间。这场关于 AI “长期存储”的战争，远未结束。

SDK 的爆发式增长

在 LLM 提供商的 SDK 下载量上，OpenAI 依然以 1.3 亿次下载量遥遥领先。但 Anthropic (Claude 的母公司) 的增长速度令人咋舌——自 2023 年 4 月以来增长了 1547 倍！两者之间的差距正在迅速缩小，这反映了 Claude 系列模型（尤其是 Sonnet ）在编码能力上的卓越表现，正在赢得越来越多开发者的青睐。

模型之战——速度、成本与智能的权衡

对于开发者来说，选择哪个模型作为“副驾驶”至关重要。报告对几大主流模型进行了详尽的基准测试。

速度之王：OpenAI

在吞吐量 (Throughput) 方面，OpenAI 的 GPT-5 Codex 和 GPT-5.1 依然是无可争议的王者，能够维持每秒 50-60 个 token 的生成速度。这意味着在需要快速生成大量代码或进行即时交互的场景下，OpenAI 依然是首选。

响应之王：Anthropic

然而，在 首字延迟 (TTFT) 上，Anthropic 的 Claude Sonnet 4.5 和 Opus 4.5 实现了反超。它们能在 2.5 秒内返回第一个 token，比 OpenAI 的模型快了一倍以上。这种“秒回”的体验，对于维持开发者的心流状态至关重要。

成本的考量

在价格上，GPT-5 Codex 和 GPT-5.1 设定了基准线 (1.00x)。相比之下，Claude Sonnet 4.5 的价格是其 2 倍，而 Opus 4.5 更是达到了 3.3 倍。

这就需要开发者在“极致的智能/响应速度”与“成本”之间做出权衡。对于复杂的逻辑推理任务，Claude 的高溢价或许是值得的；而对于日常的代码补全，OpenAI 的模型可能更具性价比。

前沿探索——从 RAG 到 Agent

报告的最后，还梳理了近期学术界和工业界的几项关键突破，指明了未来的方向：

• DeepSeek-V3：证明了通过稀疏混合专家 (MoE) 架构，可以在不牺牲性能的前提下，大幅降低推理成本。
• Beyond RAG：新的研究 (RetroLM) 提出，对于长上下文任务，直接利用 KV 缓存进行检索，可能比传统的 RAG (检索增强生成) 更有效。
• Agent 的进化：从 Search-R1 (让模型学会像人一样使用搜索引擎) 到 SFR-DeepResearch (全自动的深度网页研究智能体)，AI 正在从单纯的“回答问题”，进化为能够自主规划、执行复杂任务的智能体。

小结：拥抱变化，成为“超级个体”

2025 年的 AI 编码报告，向我们展示了一个正在加速奔跑的世界。代码的生产成本正在极速趋近于零，但这并不意味着程序员将要失业。相反，这标志着“超级个体”时代的到来。

在这个时代，一个工程师所能撬动的杠杆，比以往任何时候都要大。我们不再仅仅是代码的“搬运工”，而是 AI 智能体的“指挥官”。

面对这 76% 的产出增长，我们不仅要问“怎么写得更快”，更要问自己：“我们该用这些多出来的生产力，去构建什么更伟大的东西？”

资料链接：https://www.greptile.com/state-of-ai-coding-2025

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

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

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.

本文永久链接 – 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 从雏形到最终形态的演进过程。

核心原则：安全与一致性

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

1. 安全优先： 标准库实现必须是纯 Go版本，不使用 unsafe 或汇编。dsnet 强调：“Go 社区调查一致显示，安全性比性能更重要。” 这意味着标准库版本追求的是可审查性、可维护性和跨平台的一致性，而非极致的性能。
2. 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团队审查。

小结：一次迟到但意义非凡的升级

compress/zstd 的加入，对 Go 生态而言，是一次迟到但意义非凡的升级。它不仅仅是增加了一个功能包，更是一次：

• 技术的现代化： 用一个在性能和效率上全面超越 Gzip 的现代算法，武装 Go 的标准库。
• 生态的成熟： 将社区经过千锤百炼的最佳实践，以安全、稳健的方式融入官方标准。
• 模式的探索： 展示了在核心团队资源有限的情况下，如何通过与社区领袖的协作，共同推动语言生态向前发展。

对于广大 Go 开发者来说，未来已来。不久之后（或许在 Go 1.27），我们将能以最简单、最 Go-like 的方式，为我们的应用插上 Zstandard 的翅膀，轻松实现性能提升与成本节约。这无疑是 Go 社区协作精神的又一次伟大胜利。

参考资料

• https://github.com/golang/go/issues/62513
• https://blog.cloudflare.com/container-platform-preview
• https://discord.com/blog/how-discord-reduced-websocket-traffic-by-40-percent
• https://www.rfc-editor.org/rfc/rfc8878

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

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

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

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

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

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/11/02/6-months-47-microservices-architecture-disaster

大家好，我是Tony Bai。

“我们有一个运行了 8 年的 Python 单体应用，20 万行代码，工作得很好，很少崩溃，8 分钟就能部署。现在，新来的首席架构师，入职仅 3 个月，就要我们在 6 个月内，把它拆分成 47 个微服务。”

近日，在 r/softwarearchitecture 社区，一篇充满绝望与困惑的帖子引发了近百条评论的热议。这不仅仅是一个团队的技术困境，更像是一部在软件行业中反复上演的戏剧：一个稳定但“不时髦”的遗留系统，遭遇了一位满怀“宏大愿景”（和一堆时髦 buzzwords）的新领导。

发帖人描述的场景，让无数经历过类似“折腾”的工程师感到脊背发凉：

• 宏大的计划：47 个微服务，每个都有独立的 repo、数据库、Sidecar 代理，通过服务网格和事件总线进行异步通信，前端由 API 网关统一聚合。
• 脆弱的理由： 领导的理由也含糊不清，主要是“单体无法扩展”、“我们需要团队自治”，并不断引用“Google 和 Amazon 就是这么做的”。
• 荒谬的资源：一个 25 人的团队，意味着平均不到半个人负责一个服务。团队中绝大多数人没有任何分布式系统经验。
• 不可能的时间线：6 个月内完成，同时还要并行交付新功能。

发帖人绝望地问道：“这究竟是合法的、富有远见的架构设计，只是我太愤世嫉俗无法看清；还是我所见过的、最明目张胆的‘简历驱动开发’(Resume-Driven Development)？”

而社区的回答，几乎是压倒性的一致。在这篇文章中，我们就来看看架构师社区对这个帖子中问题的诊断过程与结论，以及给出的建议“药方”。

诊断一：典型的“简历驱动开发”(RDD)

这是社区给出的最普遍、也最尖锐的诊断。一位评论者一针见血：“你的架构师正在为他的下一份工作，填充他的简历和技能。” 另一位则补充道：“他会在项目成功‘实施’（但还未开始崩溃）后立刻离职，把烂摊子留给你们。”

RDD 的典型特征是：

• 解决方案在寻找问题：架构师带来了一整套时髦的技术栈（微服务、服务网格、事件总线、Kafka、K8s），却并没有清晰地论证当前系统到底遇到了什么非用这些技术不可的问题。
• 理由空洞，诉诸权威：“单体无法扩展”是一个未经证实的断言。当前系统（50k req/day, 即平均 < 1 rps）真的有扩展性问题吗？瓶颈在哪里？“Google 模式”更是典型的“货物崇拜编程”(Cargo Cult Programming)——盲目模仿成功者的表象，却不理解其背后的约束和权衡。
• 忽视成本与团队能力：完全无视一个 25 人的、缺乏经验的团队，在 6 个月内驾驭如此复杂的技术栈所需要付出的巨大成本，以及几乎 100% 会失败的风险。

诊断二：“拆掉洗碗机，重建整座房子”

发帖人的这个比喻，得到了社区的高度认同。一个运行了 8 年的系统，必然存在技术债，就像房子里的洗碗机可能坏了。但理智的做法是修理或更换洗碗机，而不是因此拆掉整座房子。

社区的资深工程师们纷纷指出，一个负责任的架构师，在提出如此激进的计划前，必须回答一系列基础问题：

• 问题是什么？ 当前单体应用最大的痛点是什么？是部署困难？代码耦合严重？还是特定模块的性能瓶颈？
• 现状如何？ 是否有基准测试数据？当前的性能极限在哪里？50k req/day 的负载真的需要 47 个服务来分担吗？（“我的树莓派都能处理 1 req/sec，”一位评论者讽刺道。）
• 价值何在？ 拆分后，业务上能获得什么具体的好处？是加快特定功能的交付速度，还是提升系统的可用性？这些收益是否值得付出巨大的重构成本？

这位新任架构师显然跳过了所有这些关键的分析步骤，直接给出了一个“终极答案”。

微服务的“正确姿势”：它解决的是“组织”问题，而非“技术”问题

许多评论深刻地指出了一个关于微服务的核心真相：

微服务主要解决的，不是技术扩展性问题，而是组织扩展性问题。 (康威定律的推论^_^)

当你有数百甚至数千名开发者在同一个单体应用上工作时，代码冲突、发布协调、团队依赖会成为巨大的瓶颈。此时，将系统按业务领域（Domain）垂直切分成独立的、可独立部署的服务，让每个小团队（“双披萨团队”）拥有自己服务的完全所有权，才能解放生产力。

对于一个只有 25 人的团队，强行拆分成 47 个服务，不仅不能实现“团队自治”，反而会因为引入了复杂的分布式系统依赖和运维开销，导致更多的沟通摩擦和更慢的开发速度。正如一位经历过类似重构的工程师所言：“我们因为‘团队自治’而拆分了所有单体，现在又因为无法忍受的运维开销而试图将它们合并回来。”

社区的“药方”：如何在这场风暴中幸存？

面对这位“愿景宏大”的架构师，社区给出了两条截然不同但同样充满智慧的建议：

药方 A：“向上管理”与“增量演进”

这条路径的核心是尝试挽救项目。一位来自 FAANG 的工程师分享了他们团队的真实做法：

1. 肯定意图，质疑方案：首先，肯定架构师“着眼未来”、“提升系统能力”的良好意图。
2. 提议 POC (概念验证)：建议从一个最小、最独立的业务领域开始。“让我们先用一周时间，只拆分一个服务作为 POC，来证明我们团队有能力构建和运维这样的系统，并验证它是否真的能解决我们的某个具体问题。”
3. 用数据说话：一个理智的领导者，会接受这个数据驱动的、风险可控的提议。如果架构师拒绝，并坚持“大爆炸”式的重构，那么他的动机就非常可疑了。
4. 寻求增量演进：倡导一种渐进式的“绞杀者无花果模式”(Strangler Fig Pattern)，逐步将单体中的功能，一块块地、有选择地、在确认有净收益的前提下，剥离成更小的服务（或者叫“宏服务”/“迷你服务”）。最终，你可能会得到一个“迷你单体” (Minilith) 和一圈环绕它的服务，而不是一个由 47 个碎片组成的“分布式单体”。

药方 B：“上车，刷简历，然后跳车”

这条路径充满了犬儒主义的智慧，但也反映了许多工程师在类似困境中的无奈选择。

“我的建议是：做我曾经做过的事。既然这是个注定失败的项目，那就登上这趟炒作的列车，用这些时髦的技术把你的简历填满，然后在它崩溃之前赶紧跳车。”

这虽然听起来不负责任，但当面对一个无法沟通、刚愎自用的领导，并且申诉无门时，保护自己的职业生涯，有时就成了唯一的理性选择。

小结：架构的本质是权衡，而非信条

这个故事，之所以能引发如此广泛的共鸣，是因为它触及了软件架构的本质：架构，是一系列关于权衡 (Trade-offs) 的决策，而不是一套可以盲目套用的信条或模式。

一个优秀的架构师，会像一名侦探一样，深入理解现有的系统、业务的约束和团队的能力，然后提出一个恰如其分的解决方案。而一个糟糕的架构师，则像一个手持锤子的人，看什么都像钉子——尤其是当那把锤子是印有“微服务”、“服务网格”等时髦字样的“黄金锤”时。

最终，这个故事提醒我们，在软件工程中，最危险的，往往不是过时的技术，而是脱离了现实约束的“宏大愿景”，以及那些打着“谷歌范儿”旗号，却对工程现实一无所知的“海鸥架构师”——飞进来，拉一堆屎，然后飞走。

资料链接：https://www.reddit.com/r/softwarearchitecture/comments/1o6re10/lead_architect_wants_to_break_our_monolith_into/

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

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

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

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

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

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/07/31/periodic-table-of-system-design

大家好，我是Tony Bai。

近日，一篇名为《系统设计的元素》（Elements of System Design）的论文引发社区热议。它的目标宏大且吸睛：通过梳理上百篇横跨操作系统、数据库、分布式系统等领域的经典论文，提炼出一套通用的系统设计原则“元素周期表”。

这份“周期表”的价值，不在于提供一套死板的规则，而在于为我们提供一套共享的词汇和心智模型。它能帮助我们更清晰地思考、更精确地沟通、更深刻地理解不同系统设计背后的内在联系。

下面便是该论文的中译版，希望能给大家带去启发。

系统设计通常通过特定领域的解决方案来传授，例如数据库、操作系统或计算机体系结构，每个领域都有其自成一派的方法和术语。虽然这种多样性是一种优势，但它也可能掩盖了跨领域反复出现的共通原则。本文提出了一个从计算机系统多个领域中提炼出的系统设计原则的初步分类法。其目标是提供一套共享、简洁的词汇，以帮助学生、研究人员和实践者对系统结构和权衡进行推理，跨领域比较设计，并更清晰地沟通设计选择。

引言

投身于计算机系统领域的一大乐趣在于其纯粹的多样性，它涵盖了操作系统、数据库、计算机体系结构、分布式系统、编程语言、网络等众多分支，每个分支都有着丰富的历史。对于初学者来说，由于传统和词汇的多样性，要发现不同领域之间的联系可能颇具挑战：相同的设计原则可能会以不同的面貌出现在不同的领域中。

例如，思考一下 Jim Gray 等人关于数据库隔离级别的经典论文。它仔细阐述了并发控制机制以及在正确性和性能之间的权衡。然而，如果没有在操作系统或计算机体系结构领域接触过类似问题，这些思想可能看起来仅仅是狭隘地“关于数据库”的。实际上，相同的设计原则，“放宽一致性”，以不同的形式在各种系统中反复出现，从弱顺序内存层次结构到分布式系统中的最终一致性协议。当每个社区都使用自己的术语和范例时，初学者可能很难识别出底层的设计原则。这种碎片化增加了认知开销，因为同一个权衡必须在每个上下文中重新学习。

这是一个更广泛的模式：系统研究富含实践洞见，但在共享的概念性支架上则较为薄弱。在各个领域中，类似的挑战反复出现，如管理并发、确保一致性和适应变化，而其框架和词汇却常常不同。因此，看似毫不相关的领域之间的深层联系可能仍然相对模糊。

本文是朝着弥合这些差距迈出的一小步。借用门捷列夫的比喻，我们提出了一个反复出现的系统设计原则的“元素周期表”。其目标并非一个僵化的分类法，而是一个可用的词汇表：一种用以标注论文、讲座和设计文档中所采用的基本原则的简洁方式。其目的是揭示计算机系统中已经存在的结构，以便学生能形成更连贯的心理地图，研究人员能精确定位其贡献，而实践者能以更高的清晰度跨领域讨论设计选择。

方法论

我们通过回顾操作系统、计算机体系结构、数据库、网络、编程语言、安全以及计算机系统其他领域的 100 多篇有影响力的论文来识别这些原则。这些论文因其历史意义和持续的相关性而被选中，例如关于并发控制 和共识 的经典论文，以及关于在系统内部使用机器学习 和为云设计系统 的近期工作。

对于每篇论文，我们都问：其底层的高层设计原则是什么？在不同领域中，独立的系统常常不是在机制上趋于一致，而是在共享的设计原则上：例如，通过放宽一致性来提高性能，或通过提升抽象来增强可用性。

要被认定为一条系统设计原则，它必须满足两个条件：

1. 抽象性 – 该原则必须独立于具体的技术或实现。
2. 通用性 – 该原则必须在不同领域中出现（例如，数据库系统、操作系统、编程语言）。

本分析旨在梳理出许多具有持久、通用价值的原则，而非对所有原则进行编目。

设计原则表

我们整理了一套结构化的、包含 40 多个从系统文献中提炼出的通用设计原则。如下图所示，它们被组织成反映了系统设计中常见维度的不同主题组。

图例： Code = 唯一短符号, Name = 原则名称, Intent = 简短描述。

每个原则都带有一个简短的符号（例如，Co 代表可组合性，Op 代表乐观设计）以便快速参考。我们强调设计意图而非规定具体机制：这些原则阐述的是诸如“在并发下保持正确性”或“优先处理普遍情况”等目标，而不是“使用此锁定协议”或“优化此查询计划”，具体的实现则留给特定领域。

目录

• Group 1: 结构: 如何用清晰的边界和扩展点来切分和连接组件。
• Group 2: 效率: 通过将精力集中在有回报的地方，来减少工作或降低成本。
• Group 3: 语义: 精确地指定行为和接口。
• Group 4: 分布: 在分布式架构中协调工作和数据。
• Group 5: 规划: 根据目标、成本和约束自动选择方案。
• Group 6: 可操作性: 在最小化中断的情况下观察、适应和演进运行中的系统。
• Group 7: 可靠性: 在故障、并发和部分失效下保持正确性。
• Group 8: 安全性: 约束权限和强制隔离以保护安全和完整性。

Group 1: 结构

Si – Simplicity (简单性)

选择满足当前需求的最简单的系统设计；抵制复杂性，例如“以防万一”而增加的额外层次、服务或通用性，直到有证据表明其有益。

示例： 避免对系统进行过早的架构优化。

Mo – Modularity (模块化)

将系统划分为具有最小化接口的高内聚单元，以便每个单元都可以被独立地推理、替换或演进。该原则专注于分解：选择边界以促进关注点的清晰分离，使每个职责都位于一个模块内。

示例： OSI 模型将通信分解为具有明确边界的标准化层次，允许独立开发和替换。

Co – Composability (可组合性)

设计可被安全、灵活地重新组合的组件；依赖显式的合约和类型约束的接口，以使每个合法的组合都保持正确，让组件能像可互换的积木一样被组装。与模块化不同，该原则专注于重新组合：确保组件可以安全、灵活地结合。

示例： Unix 程序（如 grep, sort, uniq）从标准输入读取并写入到标准输出，让用户可以组合复杂的文本处理管道。

Ex – Extensibility (可扩展性)

设计系统以允许安全的用户自定义扩展，例如插件，而无需修改系统核心。当扩展来自不受信任方时，通过沙箱进行隔离以保护安全。

示例： Unix 也体现了可扩展性：用户可以添加新程序而无需更改内核。

Pm – Policy/Mechanism Separation (策略与机制分离)

通过暴露一个通用接口，将“应该做什么”（策略）与“如何执行”（机制）分离开来，使得多种策略可以插入到同一个机制中。

示例： Hydra 拥有一个通用机制的内核（调度、分页、保护），并将资源分配策略移至用户级模块。

Gr – Generalized Design (通用化设计)

设计一个具有明确变化点（如类型、可调参数或插件）的单一核心，使其可以在不产生重复的情况下服务于多种用例，但当特化能带来性能、准确性或清晰度的显著提升时，则进行特化。

示例： C++ 标准模板库是一组通过模板参数化的容器、迭代器和算法的集合。Postgres 允许用户向核心数据库系统添加类型和操作符。

Group 2: 效率

Sc – Scalability (可伸缩性)

设计系统以应对数据、流量或节点的增长，同时保持成本或延迟的近线性增长。

示例： MapReduce 通过将工作分解为并行任务并以最小的协调来聚合结果，从而在节点间进行扩展。

Rc – Reuse of Computation (计算复用)

通过缓存、物化中间结果（例如索引），或在重复或稍作修改的输入上增量更新输出来避免冗余工作，从而节省计算。

示例： B+树复用其已排序的键顺序：查找遵循现有的搜索路径，而不是每次重新扫描整个数据集，从而复用了计算。

Wv – Work Avoidance (工作规避)

跳过不会改变外部可观察结果的计算。例子包括惰性求值和谓词短路。

示例： 惰性求值将工作推迟到值被需要时才执行，从而消除了无用的计算。

Cc – Common-Case Specialization (普遍情况特化)

检测主导运行时的执行路径或数据项（“热点”），并专门为它们创建一个精简的快速路径，同时用一个较慢的通用路径来正确处理所有情况。

示例： 在首次调用时缓存接收者类的目标方法，这样后续对该普遍接收者的调用将命中快速路径；不常见的类则回退到完整的方法查找例程。

Bo – Bottleneck-Oriented Optimisation (瓶颈导向优化)

对端到端性能进行剖析，定位最紧张的资源约束，并在此处集中改进，直到另一个阶段成为限制因素。

示例： 罕见的第99百分位延迟的长尾请求是延迟瓶颈，而复制请求有助于削减尾部响应时间。

Ha – Hardware-Aware Design (硬件感知设计)

根据底层硬件的延迟、带宽、并行性和持久性特性（例如缓存层次、NUMA、SSD、GPU）来塑造算法和数据结构。

示例： BLAS 定义了经过缓存和向量优化的内核，使线性代数代码能高效利用硬件。

Op – Optimistic Design (乐观设计)

假设普遍情况会成功并继续执行，跳过协调，仅在假设被证明错误时才依赖一个（可能昂贵的）恢复路径。

示例： 乐观并发控制无锁地运行事务，然后在提交时进行验证，仅在检测到冲突时才回滚。

La – Learned Approximation (学习式近似)

用在数据上训练的模型替换手工制作的算法，以牺牲有界的不精确性来换取效率或灵活性。

示例： 感知器分支预测器在线学习权重以预测分支结果，其性能优于固定的两位计数器，且无需扩大表的大小。

Group 3: 语义

Al – Abstraction Lifting (抽象提升)

将底层操作封装在一个更高层的接口或领域特定语言之后，该接口表达的是意图而非步骤。这使得内部优化成为可能，也允许单一的定义能针对不同的后端。

示例： SQL 查询声明要检索的结果；DBMS 自动选择访问路径、连接顺序和物理操作符。

Lu – Language Homogeneity (语言同质性)

在核心组件和扩展中采用单一、良定义的中间表示（或语言），从而使语义对齐、工具可组合，并以最小的努力实现跨层优化和复用。

示例： LLVM 暴露了一个基于类型和SSA的IR，许多前端以此为目标，许多后端也共享它，从而实现了跨语言优化和相同中间端遍的复用。

Se – Semantically Explicit Interfaces (语义明确的接口)

精确地指定一个接口（涵盖效果可见性、顺序、持久性等），以便用户可以对调用的真实外部可观察状态进行推理，而无需猜测隐藏的缓冲或复制。

示例： SQL 隔离级别指定了精确的异常语义，并明确了可见性保证。

Fs – Formal Specification (形式化规约)

使用数学模型或逻辑来描述系统行为，以支持严格的推理、验证或综合。实现此原则的机制包括时序逻辑、状态机以及其他使系统属性可分析的形式化方法。

示例： TLA+展示了如何使用逻辑和集合论来规约和检查系统，以便在编码前捕获设计错误。

Ig – Invariant-Guided Transformation (不变量驱动转换)

使用形式化声明的不变量来驱动安全的重构、优化或重新配置。

示例： 在编译器中，SSA 将“每个名称只有一个定义”视为 IR 不变量；各个遍在重写代码时保持语义，然后重新建立 SSA。在查询优化器中，关系代数等价（例如，选择/投影下推）保持结果的语义。

Group 4: 分布

Lt – Location Transparency (位置透明)

隐藏资源的物理位置，以便客户端通过统一的名称或句柄进行交互。

示例： 程序可以像调用本地过程一样调用远程过程，从而掩盖了主机的地理位置。

Dc – Decentralised Control (去中心化控制)

将决策权分散到多个节点，以避免单点故障或瓶颈。

示例： Dynamo 通过一致性哈希对数据进行分区，并使用基于 gossip 的成员关系，从而避免了任何中央协调器。

Fp – Function Placement (功能放置)

将功能放置在拥有必要上下文和资源的地方，以实现正确性和效率，避免在别处进行冗余工作。

示例： 端到端论证表明，像可靠性检查这样的功能只有在端点才能实现其正确性。

Lo – Locality of Reference (引用局部性)

将相关的数据和操作在时间和空间上彼此靠近，以保持访问模式并最小化计算与状态之间的分离。

示例： 工作集模型形式化了时间局部性，以将热点页面保留在内存中。

Group 5: 规划

Ep – Equivalence-based Planning (等价规划)

在保持语义等价的通用IR上应用代数/逻辑重写规则；将最终选择推迟到后续的成本/约束阶段。

示例： Starburst 的基于规则的重写系统应用关系等价（例如，谓词下推）来生成逻辑上等价的查询。

Cm – Cost-based Planning (成本规划)

当系统必须在备选的设计、配置或执行策略中做出选择时，使用成本模型来指导搜索，以找到低成本的解决方案（能源、金钱等），而无需枚举整个空间。

示例： Selinger 查询优化器在一个成本模型下选择成本最低的计划。

Cp – Constraint-based Planning (约束规划)

将决策和硬性或软性约束进行编码，并依赖一个求解器（ILP/SMT等）来找到一个可行或最优的分配方案。

示例： Quincy 将集群调度问题建模为带有局部性和公平性约束的最小成本流问题，并求解以获得分配方案。

Gd – Goal-Directed Planning (目标导向规划)

接受对期望最终状态的声明性描述，并自动合成一个具体的操作序列来达到它，从而将用户与实现细节隔离开来。

示例： Cascades 查询优化器通过基于规则的转换和成本引导的搜索，将一个 SQL 查询（目标）转化为一个可执行的计划。

Bb – Black-Box Tuning (黑盒调优)

当分析性的成本模型不可用时，通过在目标系统上测量候选方案来搜索计划/配置空间，迭代地选择更好的方案（例如，启发式或贝叶斯搜索），并缓存胜出者。

示例： ATLAS 在目标 CPU 上凭经验对候选的 BLAS 内核配置进行计时，并固定性能最佳的参数，而无需分析性的成本模型。

Ah – Advisory Hinting (建议性提示)

提供非强制性的提示，系统可以利用这些提示来提高性能，但不会改变正确性或需要强制执行。

示例： Lampson 提倡使用可选的“提示”，这些提示有助于提高性能，但如果被忽略，绝不能影响正确性。

Group 6: 可操作性

Ad – Adaptive Processing (自适应处理)

监控运行时条件，并自动调整参数或策略。

示例： Eddies 根据反馈在运行时持续地对查询操作符进行重新排序，在不停止执行的情况下进行适应。

Ec – Elasticity (弹性)

根据不断变化的需求和成本目标，自动调整资源分配。例子包括预测性自动伸缩和负载整形。

示例： Chase 等人根据负载和效用动态地配置服务器，体现了弹性资源管理。

Wa – Workload-Aware Optimisation (负载感知优化)

持续观察工作负载的形态（倾斜、局部性、访问频率等），并调整数据布局、算法选择或资源分配以匹配当前模式。

示例： 数据库“cracking”技术根据查询谓词增量地重组列数据，从而使数据布局持续地适应观察到的工作负载。

Au – Automation and Autonomy (自动化与自治)

让系统无需人工干预即可执行常规或响应式任务，通常通过从追踪或用户提供的示例中学习来实现。

示例： AutoAdmin 从工作负载追踪中自动推荐索引/物化视图 [7]。通过示例编程的系统通过从少数用户提供的示例中进行泛化来自动化任务。

Ho – Human Observability (人类可观测性)

暴露系统的内部状态，如指标、追踪、计划，以使系统有意地变得透明；这种透明度提高了可观测性、调试、内省和控制能力。

示例： Paxson 的端到端互联网数据包动态分析展示了丰富的测量和追踪如何实现有根据的调试和调优。

Ev – Evolvability (可演进性)

设计系统使其能在最小化停机时间或重写成本的情况下进行变更，且不破坏现有客户端的外部合约或可观察行为。与让外部人员通过定义的钩子点添加新行为而不触及核心的可扩展性不同，可演进性让系统内部随时间变化而不会破坏现有的外部合约。

示例： Parnas 展示了模块化设计如何使系统更容易在不进行颠覆性重写的情况下进行扩展。

Group 7: 可靠性

Ft – Fault Tolerance (容错性)

设计系统使其在组件故障时仍能继续运行，尽管可能以一种降级的形式。

示例： Gray 对计算机为何停止运行的分析表明，复制和自动重启让服务能够在硬件和软件故障中持续运行。

Is – Isolation for Correctness (隔离以保正确)

防止组件间的意外干扰，从而使局部推理保持有效。

示例： 两阶段行级锁定阻止一个事务读取或覆盖另一个事务未提交的数据，从而保持隔离保证。

At – Atomic Execution (原子执行)

将多个操作组合在一起，使其表现为不可分割的，要么全部生效，要么全不生效。

示例： 使用事务性内存，事务内的内存操作会进行推测性执行，然后原子性地提交；如果发生任何冲突或故障，整个块将中止，不留下任何部分状态。

Cr – Consistency Relaxation (一致性松弛)

为提高性能、可用性或并发性，在有文档记录的边界内，刻意放宽强一致性或顺序约束。

示例： Bayou 允许移动客户端在断开连接时更新副本，并保证在副本重新连接时最终会趋于一致，这是用严格的一致性换取离线可用性。

Group 8: 安全性

Sy – Security via Isolation (隔离以保安全)

强制执行严格的边界，使故障或恶意代码无法影响其他组件。

示例： 一个正确的虚拟机监视器为每个客户机呈现一个完整、隔离的机器，并拦截特权操作，防止一个客户机危及其他客户机或宿主机。

Ac – Access Control and Auditing (访问控制与审计)

定义权限，并记录每次访问以备问责。

示例： Lampson 对访问控制列表、能力（capabilities）和审计追踪的分类法是现代安全机制的基础。

Lp – Least Privilege (最小权限)

只授予完成任务所必需的最小权限，以缩小爆炸半径。

示例： 对1988年互联网蠕虫的尸检报告显示，过度的权限让蠕虫得以传播，并促使了最小权限守护进程的广泛采用。

Tq – Trust via Quorum (法定人数信任)

依赖多个独立参与者的一致同意，而非单一权威。

示例： Paxos 算法将状态复制到一个多数法定人数中，这样即使少数节点崩溃或行为恶意，服务也能保持正确。

Cf – Conservative Defaults (保守默认值)

发布时采用限制性的、安全的设置；让专家选择性地进入风险更高、速度更快的模式。

示例： 采用“默认无访问”策略，每个保护机制都应只在明确授予时才允许访问。

Sa – Safety by Construction (构造即安全)

通过代码或数据的结构设计，使整类错误变得不可能发生，而不仅仅是被检测到。

示例： Rust 的所有权和借用检查器在编译时就防止了数据竞争和悬垂指针。

案例研究

为了说明多个设计原则在实践中如何交织在一起，我们以关系数据库系统中从逻辑操作符计划到物理操作符计划的映射为例。

• 数据库系统将声明性意图转化为可执行步骤（策略与机制分离）。
• SQL 表达了“做什么”（抽象提升），并具有精确的语义（语义明确的接口）。
• 优化器首先使用代数等价来重写查询（等价规划）。
• 然后它使用成本模型来选择具体的物理操作符（成本规划）。
• 物理操作符通常针对底层硬件特性进行优化（硬件感知设计）。
• 谓词下推体现了工作规避，而索引则实现了计算复用。
• 建议性提示可以指导优化器，而较新的数据库系统增加了运行时重优化（自适应处理）、学习模型（学习式近似）和采样（Probabilistic Design，注：原文表格未列出此原则，但案例中提及）。

因此，数据库系统中从逻辑到物理操作符的映射，体现了多个设计原则如何共同作用，以高效处理声明性的SQL查询。

局限性

任何试图组织像计算机系统这样广泛的领域的尝试都涉及到权衡。此表不是一份检查清单或一个普适的理论；它是一个共享的词汇表，旨在突出反复出现的原则并鼓励进行结构性反思。话虽如此，仍有几个局限性：

• 正交性：原则之间可能重叠、相互加强或部分冲突；设计就是关于平衡这些张力。
• 主观性与粒度：推导和映射原则涉及判断；边界是模糊的，不同的读者可能会以不同的方式标记同一个系统，或以不同的方式解释同一个原则。
• 非形式化分类法：这不是一个完整或最小的设计原则集合。没有尝试从一个最小的核心推导出这些原则。

最终，此表是一种帮助学生更清晰地看到反复出现的设计原则，协助系统设计师更精确地沟通权衡，并帮助研究人员认识到他们的思想在更广阔的系统设计蓝图中所处位置的手段。

结论

系统设计横跨不同的领域和词汇，这可能使共享讨论变得更加困难。我们继承机制，研究权衡，并建立直觉，然而用于描述底层思想的简洁术语并不总是唾手可得。这里提供的设计原则“元素周期表”旨在提供一种适度的通用语言，通过命名反复出现的思想，使其更容易被传授、比较和在其上进行构建。

参考文献

[1] Ron Avnur and Joseph M. Hellerstein. Eddies: Continuously Adaptive Query Processing. In SIGMOD, 2000.
[2] Rudolf Bayer and Edward McCreight. Organization and Maintenance of Large Ordered Indexes. Acta Informatica, 1972.

… (请参考原文中的详细参考文献列表) …

[48] Hubert Zimmermann. OSI Reference Model – The ISO Model of Architecture for Open Systems Interconnection. IEEE Transactions on Communications, 1980.

如何引用

如果您觉得本分析有用，请按如下方式引用：

Joy Arulraj. Elements of System Design arXiv preprint arXiv:TBD, 2025.

论文地址：https://github.com/jarulraj/periodic-table

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/07/25/writing-is-thinking

大家好，我是Tony Bai。

最近，全球顶级的科学期刊《自然》(Nature) 发表了一篇社论，标题仅有三个词：“Writing is thinking” (写作即思考)。

这篇社论探讨的是大语言模型时代人类生成的科学写作的价值，其核心观点，对于我们技术领域的开发者、工程师和内容创作者来说，不啻为一记振聋发聩的警示。它在 AI 浪潮席卷一切的今天，迫使我们重新审视一个被我们日渐忽视，却又至关重要的行为——我们自己的思考过程。

开发者版本的“写作即思考”

对开发者而言，“写作”的形式多种多样：
* 编写一份详尽的技术设计文档 (Design Doc / RFC)。
* 撰写一篇分享经验的技术博客。
* 甚至，是构建一个结构清晰、逻辑严谨的复杂软件模块。

这些行为的本质，都和《自然》社论的观点一致：它不仅仅是“报告结果”，更是一个强迫我们将脑中混乱、非线性的想法，梳理成结构化、有意图的叙事的过程。

当你无法用清晰的语言（或代码）写下来时，通常意味着你对这个问题还没有想清楚。这个“写”的过程，本身就是发现逻辑漏洞、提炼核心思想、明确最终影响力的思考过程。正如社论所引述的科学依据：书写行为本身，就能增强大脑的连接性，并对学习和记忆产生积极影响。

AI 带来的“隐形危机”：思考外包

现在，强大的 LLM 出现了。我们似乎可以轻易地“外包”掉这个艰苦的思考过程。

“帮我生成一份关于XX系统的微服务架构设计文档。”
“为我刚才的 Go 函数编写一份详细的单元测试。”

AI 瞬间就能产出看似完美的“结果”。但在这个过程中，我们失去了什么？

1. 效率的假象： AI 会产生幻觉。你可能需要花费更多的心力去验证、修正和编辑一份由 AI 生成的、你并不完全理解的复杂文档或代码，其成本甚至可能超过从零开始亲自撰写。
2. 思想的归属： 社论提出了一个尖锐的问题——如果“写作即思考”，那么当你在阅读一篇由 LLM 生成的论文时，你读到的究竟是研究者的思想，还是 LLM 的“思想”？同理，当你的同事向你展示一份由 AI 生成的设计文档时，这背后真的有他深入的思考和权衡吗？
3. 核心能力的侵蚀： 这是最危险的一点。我们跳过了最宝贵的思考整理过程，直接获取了“结果”，却失去了将知识和经验内化为自身能力的宝贵“过程”。我们放弃了锻炼自己核心思维能力的机会。

从“外包者”到“放大器”：AI 的正确使用姿势

那么，我们应该抵制 AI 吗？当然不。《自然》的社论也明确指出，AI 是一个极其有价值的辅助工具。问题的关键，不在于用不用，而在于怎么用。

我们应该警惕成为一个“思考外包者”，转而努力成为一个“思考放大器”的使用者。

这意味着，永远由人类掌握“思考”的主导权，而在特定的、非核心思考的环节，利用 AI 来提升效率。以下是一些高效的“放大器”模式：

• 语法与可读性优化器： “这是我写的一段技术描述，请帮我润色，使其更易于理解，并修正语法错误。”
• 信息检索与综述助理： “帮我总结一下最近关于 QUIC 协议的三篇关键论文的核心观点。”
• 头脑风暴伙伴： “我正在设计一个高可用的缓存系统，请帮我列出可能需要考虑的 10 个潜在故障点。”
• “破冰”与“思路转换”工具： “我对于如何向非技术人员解释‘幂等性’感到卡壳，请提供三种不同的比喻或解释方式。”

在这些场景中，AI 是你的研究助理、语法老师、灵感催化剂，但绝不是替你完成核心思考的“枪手”。

未来已来：从“代码实现者”到“思想叙事者”

这场关于“写作与思考”的讨论，最终引向了一个更宏大的问题：当 AI 越来越擅长“写作”（即编码实现）时，我们人类工程师的不可替代价值到底在哪里？

答案或许就在《自然》社论的结尾：“将整个写作过程外包给 LLM，会剥夺我们反思和塑造引人入胜的叙事的机会”。

未来工程师的核心竞争力，正在从单纯的技术实现，向上游转移。以下三项“元技能”将变得至关重要：

• 深度反思能力: 对技术领域、业务场景进行深刻的洞察和反思，理解“为什么”远比“怎么做”更重要。
• 创造性任务处理能力: 定义正确的问题，做出关键的架构取舍，进行富有创造力的系统设计。
• 思想叙事能力: 能够将复杂的技术决策、系统设计，用清晰、有说服力的“故事”（设计文档、技术演讲、甚至代码结构本身）讲述出来，影响和说服他人。

你看，这三项无法被 AI 替代的核心能力，恰恰都是通过“写作即思考”这个艰苦而宝贵的过程来培养和强化的。

小结：别让 AI 替你思考

AI 是一场革命性的技术浪潮，它正在重塑我们的工作方式。但我们必须保持清醒：AI 是我们手中的工具，而不是我们大脑的替代品。

我们可以，也应该，让 AI 成为我们强大的“副驾驶”，帮我们处理繁琐的事务，为我们提供新的视角。但方向盘，必须始终握在我们自己手中，谨慎和正确使用带有深度思考和推理功能的AI大模型。

因为我们写下的每一行代码，每一份文档，不仅仅是交付物，更是我们思考过程的凝结与沉淀。这个过程，才是我们作为工程师，最宝贵的财富。

资料链接：https://www.nature.com/articles/s44222-025-00323-4

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/07/12/insanely-productive-in-go

大家好，我是Tony Bai。

在软件开发的世界里，我们总被灌输一种观念：选项越多，工具越强，生产力就越高。于是，我们追求功能最全的框架、最灵活的配置、以及最新潮的库。

但最近，在 Reddit 的 r/golang 社区，一篇名为《我感觉用 Go 的效率高得离谱》(I feel insanely productive in Go) 的帖子引发了近百条热议。一位曾坚信 TypeScript 和 Python 是“快语言”的开发者，在亲手尝试 Go 之后，发出了“真香”的感叹。

他发现，之前在 Node.js 生态中，光是技术选型——选择哪个运行时 (Bun? Deno?)、哪个 Web 框架 (Express? Fastify?)、哪个 ORM (Prisma? Drizzle?)——就足以耗费他整整一周的时间。他称之为“分析瘫痪” (Analysis Paralysis)。

而在 Go 中，他一天之内就搭建起了项目，开始编写业务逻辑。

这个故事并非孤例，它触动了无数从其他语言生态“迁徙”而来的开发者的心弦。它揭示了 Go 语言一个常常被误解，却又极其强大的超能力：正是那些看似“无聊”的、更少的选项，才赋予了我们惊人的生产力。

告别“分析瘫痪”：Go 的“默认路径”之力

为什么选项更少反而更快？因为 Go 的设计哲学从一开始就在极力避免“分析瘫痪”，为开发者提供一条清晰、低阻力的“默认路径”。

1. 强大的标准库：你的第一选择，也是最好的选择

Reddit 上的高赞评论一针见血：“在 Go 中，你不需要从一个框架开始，标准库已经提供了你需要的大部分东西。”

想写一个 Web 服务？net/http 就是你的起点。想操作数据库？database/sql 就在那里。想处理 JSON？encoding/json 已为你备好。

这些标准库不仅功能强大、性能卓越，更重要的是，它们是 Go 团队维护的、最稳定、最符合 Go 哲学的实现。这意味着，当你遇到问题时，你面对的是整个 Go 社区的集体智慧，而不是某个特定框架的小圈子。

2. “小工具”生态：组合优于继承

当然，标准库并非万能。但当你需要第三方库时，你会发现 Go 的生态也与众不同。这里没有像 Java Spring 或 JavaScript React 那样“统治一切”的庞大框架)。

取而代之的，是一个由无数“小而美”的、可组合的库构成的生态系统。比如，你需要一个更强大的路由？chi 或 gorilla/mux 可以无缝地与标准库的 http.Handler 配合。你需要一个配置库？Viper 可以专注于做好这一件事。

这种模式的好处是显而易见的：你只引入你需要的，你的项目不会被一个臃肿的、你只用了 10% 功能的框架所绑架。

“语言开发者” vs. “框架开发者”：Go 的纯粹之路

这种生态哲学，引出了一个更深层次的问题：你到底是一个“语言开发者”，还是一个“框架开发者”？

在许多其他生态中，框架的存在感甚至超过了语言本身。
* 一个 Java 工程师的简历上，写着“精通 Spring Boot”，这比“精通 Java”本身可能更具分量。
* 一个前端工程师，很可能对 React 的生命周期了如指掌，却对 JavaScript 的原生事件循环感到陌生。

这是因为，那些庞大的框架往往会重新定义语言的工作方式，引入大量“黑魔法”般的抽象和依赖注入。你写的是框架的 API，遵循的是框架的范式。你的技能，与这个框架深度绑定。一旦需要更换框架，或者脱离框架工作，你可能会发现自己几乎要重新学习一门“新语言”。

而 Go 社区，自始至终都在走一条“纯粹之路”。

这里的目标，永远是成为一个更好的 Go 开发者。因为标准库的强大和生态的“小工具”特性，无论你在哪个公司、哪个项目，你所依赖的核心思维和工具集都是一致的。你学到的 context 包的用法、interface 的设计模式、goroutine 的并发模型，这些知识具有极高的可移植性。

你不是在学习一个框架的“方言”，而是在掌握一门通用语言的“普通话”。这不仅提升了你个人的职业安全感，也极大地保障了项目的长期可维护性。

小结：在“约束”中寻找自由与效率

Go 的生产力优势，根植于其看似“固执”和“无聊”的约束之中。

它通过一个强大的标准库和一套约定俗成的惯例，为你铺设了一条清晰的道路，让你免于在无穷无尽的选择中耗尽心力。

它通过一个由小工具组成的、可组合的生态，让你专注于学习语言本身，而不是被某个庞大的框架所束缚，从而保护了你最宝贵的资产——你的知识和技能。

最终，Go 通过减少不必要的外部认知负荷，将你最宝贵的资源——注意力——解放出来，让你能真正地聚焦于业务逻辑，聚焦于创造价值。

这或许就是为什么，那么多开发者在体验过 Go 的“少即是多”之后，再也回不去了。因为他们发现，真正的自由与效率，恰恰来自于“恰到-好处”的约束。

资料链接：https://www.reddit.com/r/golang/comments/1lx52vz/insanely_productive_in_go_rethinking_everything/

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.

关于我的工作原则，感觉之前的那篇总结的还不够，这两天通过观察自己的所言所行，又有了些思绪，这里记录下来。

* 重塑标准

简单来说就是根据组织实际情况，重新建立各种标准 – 技术标准、人员标准和产品标准。 个人认为这恰是一种实事求是的积极态度。避免陷入技术泥潭中无法自拔，不用Google的人才和做事标准来要求组织内部的人和招聘新人上，认识到存在的差 距。恰如当年钱学森根据国内人力、物力以及实际技术水准重新制定了标准，而不是照搬美国的标准，否则造导弹就会变成一个不可能完成的任务，对团队 士气也将会是一个极大的打击。

* 问题理解要透彻

很多时候，干完了才知道白干了，这往往缘于起初对问题理解的不够透彻，没有抓住焦点，导致Solution不是最合适的，引发不必要的返工。但很 多问题往往无法一次性透彻地理解，这就需要在工作方法上有所调整，以尽可能少的工作消耗去理解和摸索，对工作内容进行阶段性的反思和重构。这样在 1.0, 2.0以及3.0等后续版本的演进过程中，你会发现问题将变得逐渐清晰，焦点也会越来越清楚。而一旦问题被看透，最正确的Solution自然就会在大脑 中形成。

* “眼见为实”还不够

俗语讲：眼见为实。但在工作中，有些时候“眼见为实”还不够，因为很多时候眼中看到的是假象，这在调试和查找技术问题时显得尤为突出。无数次的问 题调查告诉我：始终要保持头脑清醒和逻辑清晰，不能人云亦云，不能轻易相信亲眼所见的“事实”。要追求逻辑的全局合理性，一丝的不 合理都要刨根问底，不遗漏任何蛛丝马迹。

* 把事情做在前面

以推进知识管理为例，在发布知识库之前就应该把发布后可能遇到的各种问题、阻碍想清楚，提前就这些可能的问题给出方法、答案的指导或以Q&A的形 式与知识库一并发布。这些要做在前面的事情包括几类：解放思想的（帮助大家突破原有思维禁锢）、最佳实践的（告知以何种方式去做收到的效果最好）、基本知 识技巧普及的（以大家最易接受的方式对基本知识技巧做出诠释）、服务运维的（还以知识库为例，发布后，你要始终保证其运行稳定可靠，不能让其他人操心于此 事）等。 

© 2013, bigwhite. 版权所有.

工作了若干年，不经意间就形成了自己的行事和决策风格，这里权且称之为工作原则吧。这些原则引导我制定工作目标、实施过程改善、作出方案决策、选择和培养团队人员以及进行自我改进等。我也相信这些原则是主观的、具有时间和环境局限性的。也许若干年后，随着我的角色和工作的变化，许多原则将 不再适用，但这不妨碍我现在将其总结和分享出来。

* 对工作原则的认知

原则就像定理一样，是你在决策以及行事前要参考的东西，它将对你的思维施加强大的因果影响，指引你一步一步的得到最终的结果。个人工作原则的行成 是一个逐渐认知、逐渐丰富的过程，与个人角色的影响力多寡有一定关系。最初入职场，你所能影响的范围较小，无非就是你所负责的那个一小块区域，更 多是与事儿打交道，似乎没有什么可以决策和选择的。你要做的就是按时保质地完成一个接着一个的任务。随着影响圈的扩大，你的行为将受到更多因素的 影响，你的思维计算开始变得复杂，你的潜意识告诉你这么做是正确的。久而久之，这种思维和行事方式就固化到你的大脑中了，形成了你的工作原则，并 且原则随着你的工作年头的增加而逐渐丰富。

工作原则是个体的，主观的，也可能是错的，也许只适合你的角色，但不一定适合他人。如果两个人的工作原则一模一样，那估计是电视剧中的情形，纯属 巧合。

有原则的工作观的行成时间因人而异，有的人初入职场就有，有的人要花上个几年时间，我就属于后者，缓慢型。

有了原则，还要会使用原则，这或多或少与情商有关。有时候，折中或妥协不一定是最坏的结果。

* 做事的原则

   【要结果，也要过程】

    现代企业更强调结果导向，业绩为先。在组织与个人的绩效考核中，结果确是极其重要的指标因素，这些都无可厚非。但我坚持的原则是要结果，也要过程。个人不 是临时工，不是完成一个任务后就要离职；团队也不是打一杖就要解散的，因此每打一杖，我们既要胜利，也要打得一个比一个漂亮 – 投入少，损伤少，战果卓著，我们的人民子弟兵不就是这么发展壮大起来的么 – 鸟枪换炮了。一成不变的过程损失的是个人以及团队未来 的竞争力。因此对于软件开发团队而言，要实施积极的过程改善，改善是融于任务的过程中的。没有代码评审的，整个 Reviewboard玩玩；打包构建不规范的，弄个maven或buildc试试；测试还靠人肉的，堆个自动化的测试框架（比如 robotframework）试试。过程的改善带来的是整体能力的提升，这就是我们除了结果之外所想要得到的。

   【从痛点出发】

    这是一条寻觅过程改善点的原则，很多人也都能意识到过程的一成不变，但却始终找不到下手改进的切入点；
    这也是一条组织内开启微创新的原则。在“创新”一词被用烂的今天，真正能找到组织内创新之路起点的人却少之又少。

    什么是痛点（pain point）？顾名思义，引发痛苦的点。放在组织以及过程范围内来说就是让员工或组织在内部活动过程中产生别扭、不爽以及痛苦的点。比如：每次搭建一个产 品模拟环境都要半天时间、每次都要两人/天才能完成新版本的接收测试、TMD谁提交的代码让工程编译不过去了。

    我的原则是努力去发现痛点，深入理解痛点，并尝试缓解或解决痛点。

    发现痛点的一个方法就是降低自己的忍受力，这样痛点才能得以放大。否则中国人都是极具耐性且勤奋的，一点点挫折或别扭之处或浪费时间的事情都不会被列为痛点 的。

    解决痛点的一个前提是对其深入的理解。有的痛点，我们感受到的只是其外在的表象，其深层次的东西是需要深入地理解和挖掘的。只有挖掘到深层次，才能对症下 药，药到病除。

    客户的痛点，往往是一种很好的引导产品演化或服务提升的途径。比如：到海底捞吃饭要排队，显然大家都不喜欢排队。海底捞的团队发现了客户们的这个痛点，向 排队客户提供了超出客户预想的服务。之后的事情大家都有所耳闻了：这一痛点的解决居然变成了海底捞的“招牌“。

   【事先谋划布局】

    我们知道要下好围棋，谋划布局是必不可少的。最佳布局是取得胜利的基石。要完成最佳的布局，需要棋手有对全盘的整体把握能力以及准确的时机判断能力。做事如下棋，尤其是在要完成一些重要且复杂的事情时，务必事先针对现状谋划出最佳的布局。

    在组织内部，资源和时间永远是有限的。要去完成一件不紧急但重要事情的时候，往往不能立即得到全部的资源以及充足的时间，甚至得不到其他人的认可（因意 识、眼光等种种原因）。一些自下而上发起的改善措施，甚至是得不到任何资源的。只能充分评估已有的资源和时间，以设定好的节奏稳步前进，取得一些阶段性的 成果。当时机成熟时，公开成果以获得领导的首肯以及各种资源来完成后面的计划。我在组织内部推行知识管理时就是这样布局的，而这个局花了两年多时间才基本 完成。

    大局大作，小局小作。关键是以敏锐的眼光准确的判断形势，以确定是否该落下下一颗棋子以及落在何处。
   
   【不违背工作节奏规律】
   
    人不是机器，无法始终绷紧神经开全挂埋头苦干。人工作效率的高低和产出成果多寡符合一定的规律曲线，大致分为三个阶段：充电期、发光期与衰减期。

    不同年龄段的人的充电期、发光期、衰减期的长短不同，这个很好理解。年轻人发光期相对长，充电和衰减相对短。随着年龄的增加，发光期缩短，充电和衰减期变长。

    每个人要对属于自己的那个工作节奏做好充分认知。让发光期更有效率（每天高效利用8小时），让充电期集聚更多能量（身体上的、精神上的和知识技能上的），调整衰减期的工作内容。

    下班后尽量做与工作无关的事情（例如做自己的开源项目、融入家庭生活），努力追求工作与生活的平衡，是有利于提升充电效率的。

    长久违背这一自然规律，将使得节奏变得紊乱，而紊乱后的代价还是蛮高的。

    组织由个体组成，组织也因此呈现出一定的工作节奏，我们在考虑组织的工作负荷时不要忘了这一点。

   【时刻抱有危机感】

    危机感让人警醒，并保持持续向前的动力和热情。

    时刻问自己：如果你离开当前公司，是否能瞬即得到其他同等或更好的公司的青睐。这种危机感让你会主动追随技术潮流的发展方向，武装自己，提升自己，让自己的受欢迎度维持在高位。

    组织也是一样，没有永恒不落的公司，没有永恒不落的行业。即便是百年老店IBM，也是在沙场中几经沉浮。危机感让组织持续寻找新的业务方向、积累新鲜的技术食粮，为将来残酷的竞争做着准备。

    【通过提升平台能力，提升整体能力】
   
     与逐个培训和激励个体提升相比，组织整体能力的提升是更具性价比的。人是最复杂的动物，基因的万千变化使得自然界的人类个体差异十分巨大，这表现在智商、 兴趣、理想、热情等多个方面。用内容一致的课程对员工进行所谓的培训，收到的效果自然千差万别，整体提升有限。

     但如果将个体所在的平台的能力进行提升，就好比将传统的人工生产线换成机器人流水线，员工们要做的只是改变一下自己的行为，新的行为甚至比之前的操作更为简单，我们就可以得到整体的能力提升。

     这种方法的划算之处还在于即便在人员流失的情况下，新进的人员在这套平台或规程下段时间内也能达到相同的生产力，即便新人在各个方面都远逊色于离开的老员工。

* 用人的原则

     【但求最适合，不求最优秀】
      
      理想情况下，所有组织都希望能招到世界上最优秀的员工 – 能力最强，效率最高。但事实上在IT行业里，世界范围内集聚牛人的公司也就那么几家，绝大多数公司的员工都是很平凡的，我所在的公司更是如此。中国的IT 牛人多聚集在北上广等一线城市，那里的IT环境好，待遇优越。但没有牛人不代表无法完成工作。在现有的可用资源下，我要找的是最适合的人 – 他们在技术方面不要求十分优秀，也许只是可以胜任，但却与其工作角色十分匹配。甚至于有些角色还真的不适合牛人去做，或大才小用，或热情耐心不足（要知道 牛人一般都很自负的，对某些工作不屑一顾，自然也不会投入热情和耐心）。
      
     【充分授权，服务到位】

      实战是考验一个人的最好工具。通过实战，人员能力还将能得到最快的提升。因此从人员能力培养的角度上去看，我更愿意给予下属充分的授权，让他们放手去做。当然伴以检查与辅导，尽量减少他们走弯路的可能。

      在授权前，还要充分考虑到他们即将遇到的各种困难。并事先协调资源，给他们提供周到的服务，以帮助他们顺利完成工作任务。这些服务有可能是一些基础设施平台，也有可能是一些预研储备的技术方案。就好比武侠小说中的妙计锦囊，在关键时候可以帮助下属度过难关。  

© 2013, bigwhite. 版权所有.

从大的方面来看，提高效率的策略不会很多，万变不离其中，关键是落实，措施要与自己的组织实际情况匹配。两年前自己曾经写过一篇博文“提升效率不是口 号”，个人觉得那时的观点依旧不过时，长期适用。两年过去了，我们虽然取得了一些成绩，但还远远不够，尤其是当组织情况在持续发生变化的情况下。这里再对 观点做些诠释，plus一些新的想法。

* 领导不彷徨

各级员工都要有明确的目标和方向，领导尤甚。组织的最高领导一级要有明确的业务方向、目标以及组织发展策略。领导是主心骨，如果领导都彷徨，那么下面自然 也跟着彷徨，整个组织就不会有战斗力，效率就更无从谈起。尤其是在大环境不好，业务低迷期，领导更应该作出正确的策略和方向方面的决策。

领导要将方向、目标和策略明确的告知一线Leader，让leader们明确重点投入的方向以及可以投入的方向，以便一线leader可以有的放矢，有计划有节奏的去做，也便于一线leader评估各种人和技术的储备，提前做好准备。

* 适当的紧迫感

如果员工已知的工作只有一项，那很可能出现帕金森现象：在工作中，工作会自动地膨胀，占满一个人所有可用的时间，如果时间充裕，他就会放慢工作节奏或是增添其他事情以便用掉所有的时间。看起来每个人都很忙，但组织效率是低下的。

因此务必要做到让每个员工已知的工作保持在3项左右。当员工意识到三项任务摆在面前时，心中自然会有一定的紧迫感，让员工始终绷紧神经，即便是闲遐时刻也会考虑下一个工作任务中用到的技术我是否做好了准备，从而主动学习和准备。

* 基础设施建设上不能太小气

"基础设施"这个字眼常常出现在新闻报端，中国社会目前依旧出于大规模基础设施建设的阶段中。百度百科里说：“基础设施是指为社会生产和居民生活提供公共 服务的物质工程设施，是用于保证国家或地区社会经济活动正常进行的公共服务系统。基础设施建设具有所谓“乘数效应”，即能带来几倍于投资额的社会总需求和 国民收入。一个国家或地区的基础设施是否完善，是其经济是否可以长期持续稳定发展的重要基础”。在组织个人能力无法快速提升的情况下，适当的基础设施建设 会带来可观的组织效率提升，比如统一的服务器管理、自动化测试基础设施、持续交付工具的开发、体验良好内容丰富的知识管理系统等，让组织人员的工作环境上 了一个“档次”，就好比从中国到美国所感受到的一样，或者从印度到中国所感受到的类似。印度和中国差在哪里？都是50年代建国，人口红利相差不多，但目前 中国却要比印度先进若干年，基础设施水平绝对是一个因素。外商投资除了看重中国的低价劳动力之外，更多是中国的基础设施的完备，据说印度的德里现在还经常 停电呢。同样水平的人在印度和在中国的工作效率显然是不同的，同样的工作在中国一天就完成了，而在印度那边可能还在等啥时候能来电呢^_^。类比组织内， 具有自动化测试环境的前提下，一个项目的验收测试可能在2个小时内就跑完了，而相反，在没有自动化测试基础设施的情况下，可能一个人要做两天，效率高低立 见。

*后勤部门也能诞生将军

现代的工作多是团体作战，这就好比军队：要军事过硬的同时，保障也要给力。也就是说一个军事任务的完成，除了依靠一线冲锋陷阵的将士外，后勤子弟兵的努力一样不可缺少，甚至于在如今的现代战争中，后勤保障直接决定了战争的最后结果。

任何一个公司都有核心业务部门，有从事核心业务研发的同事，也有从事基础设施方面（后勤保证）的人员。要想激发工作热情，提升效率，就要对这些人的工作一 视同仁。工作只有分工不同，没有高低贵贱。其实在很多公司，做基础设施其实更是对能力方面要求很高，更有甚者在一些公司只有一流的程序员才有资格参与基础 设施的设计与开发。因此不要因为基础设施没有带来直接效益而忽视对参与基础设施工作人员的重视。

以上话有些糙，但理不糙，希望能给大家在组织效率提升方面带来些启发。

BTW，这两年自己也持续在组织整体能力和效率提升方面做了些工作：先后推动了组织内部知识管理系统、持续集成、自动代码检查、自动化集成和验收测试、打包与交付以及代码评审流程改进等工作的落地。

© 2013, bigwhite. 版权所有.

如果要大家投票表决组织内部最低效地活动环节，估计大多数人会将选票投给会议。关于内部会议的组织和实施，有很多反模式，这里列举一二：

- 会议组织人突然发出会议通知，两个小时后举行某会议；
- 会议通知中没有会议的agenda信息，也没有任何有关会议的资料；
- 会议的干系人选择不恰当，有些人本无需参会；
- 会议实施过程中主持人无准备，无整体思路主线，想到哪里，就说到哪里；
- 所讲内容与会议类型不匹配，无有效价值传达；
- 会议无决议，无后续行动计划，大家无所获 – 三无会议。

这里谈到的会议的效率不仅在于实施时的时间上的长短，更重要的是会议主题内容在单位时间内传递给相关干系人的程度。其实细致高效地组织和实施一次组织内部会议，并非是件多难的事情。一个会议，无非准备、实施、会后跟踪落实三个部分，而每个部分其实又都是有章可循的。

一、准备阶段

* 提前预定好会议室

注意会议室的Size要适宜，别到时侯人多没地儿坐；而人少又显得空旷，显得人气不旺，气氛不足^_^。对于有限时的远程视频会议室，要预留足够长的时间，避免会议超时带来的意外情况。

* 会议通知

在明确会议主题、类型、目标和Agenda之后，可提前数天或更长时间在组织内发出会议通知，这样可以便于干系人安排好自己的任务列表；通知中应说明会议 的主题、目标与Agenda，如果有初步的资料的话，最好能附上，让相关干系人可以更深入了解；会议的干系人选择要谨慎，哪些人必须参会，哪些人需要知道 有这个会议，自由选择参加等等都要明确。

* 会议资料准备

会议的主讲人或主持人(因会议不同而定)需进行精心的资料准备。准备阶段，主讲人应充分考虑会上要向与会者传达哪些信息与价值，要有贯穿会议的清晰的思路 主线。有条件的情况下，可以请相关人评审这份资料，主讲人最好自己做些模拟讲解，以保证在会议上能产生最好的表达效果，以提高与会者的信息接收和理解程 度。另外有些类型会议(如总结会)需要一些第三方提供的资料或需第三方讨论确认的事情，这些务必在会议举行前完成，避免在会上进行细节的讨论，降低效率。

* 参会提醒

会议主持者应提前一天再次发出会议提醒，如果此时已经准备好最新资料了，可将资料附上；但少数主讲人希望保持神秘感，只发提醒也就是了。

二、实施阶段

* 当天的会议提醒

会议举行当天，再次做会议提醒，这次仅一个通知即可。

* 会议室准备

会议的主持人或组织者或主讲人应根据会议类型和具体情况，提前一些时间到达会议室做好各种准备，包括确认会议室的设备完好情况，至少连上投影，插上网线看 看是否可用；若是远程视频会议室，则更是要提早联系管理员做设备调试，确保会议准点开始时，设备是好用的，远程是接通的；类似一些架构讲解会的会议，可能 还需要提前在会议室白板上做板书。总之，这些准备工作目的就是让会议可以准时开始，而不是让与会者坐在那里白白浪费时间。

* 会议进行

不同类型的会议有不同的进行方式。在组织内部，例会、总结会和评审类会议居多。但总体来说，无论哪种会议，如果要高效地进行，都应该按照主持人/主讲人的 思路主线进行，围绕着会议要传达给与会者的主题为中心，详说重点，有理有据，略说细节，避免细节讨论；必要讨论时，主讲人也应引导与会者的讨论，避免跑 题，并及时打断讨论，回到正题上。

* 控制会议时间节奏

在某件事情上，常人保持集中精力于其上的时间是有限度的，超过这个时间，常人肯定会溜号，信息接收和理解的效率自然就会降低。因此为了让与会者可以保持集中精力的投入，主持人需要控制好会议的节奏，适当予以休息。组织内的大部分会议，应不超过一小时为宜。

* 会议要有结论，并与与会者达成一致

会议是以高效地传达某种信息为目的的，这些信息可能是知识、技巧、最佳实践、思路、工具或某种结论，与会者在后续的工作中会用到信息。因此虽然会议类型不同，但会议均应有相关结论，作为后续的行动计划；并且与会者需要这些结论上达成一致。

三、会后跟踪落实

会议的效率更多体现在前两个阶段。最后这个阶段更多是用来检验和评估会议后的信息传达效果。另外会议主持人/主讲人需要通过这些跟踪和落实情况，总结信息传达情况；回顾和反省会议是否组织和实施的足够高效；发掘和发现问题，并做持续改进和改善。

© 2012 – 2013, bigwhite. 版权所有.