本文永久链接 – https://tonybai.com/2025/07/20/mitchell-hashimoto-agentic-engineering

大家好，我是Tony Bai。

在云计算Infra和云原生工程领域，Mitchell Hashimoto 是一个如雷贯耳的名字。作为 HashiCorp 的创始人，他一手打造了 Terraform、Vagrant、Consul 等一系列定义了现代 DevOps 和基础设施即代码（IaC）的工具。如今，这位大师级程序员正在开发他的新项目——一个用小众语言 Zig 编写的高性能终端模拟器 Ghostty。

最令人关注的是，在开发这样一个严肃、底层的系统软件时，Mitchell 正深度使用 AI Agent 来辅助编程。这并非简单的 Web 应用开发，而是对 AI 赋能开发在“硬核”场景下的终极考验。

最近，我有幸读到一篇对 Mitchell 的深度访谈，其中详细阐述了他的 Agentic Engineering 实战心法。这些经验并非空谈理论，而是充满了可以直接应用的、来自一线的真知灼见。今天，我想把这些宝贵的“干货”分享给你。

核心哲学：“我是架构师，AI 是初级工程师”

当被问及如何使用 AI 时，Mitchell 提出的核心理念，足以给当下狂热的“AI 全自动编程”思潮泼上一盆冷水：

“我感觉自己更像是软件项目的架构师。我仍然会构思代码的结构、应用的数据流、状态的存放位置等。我将这些指导信息提供给 AI 工具……我发现这能带来最大的成功。”

他从不直接向 AI 抛出一个模糊的问题，比如“修复这个 Bug”。相反，他会在脑中构思好解决方案的“形状”（Shape），然后将 AI 视为一个初级工程师来分配任务。

他用了一个绝妙的比喻：给 AI 派任务，就像带一个初级工程师，你需要提供清晰的范围和明确的“护栏”（guardrails），就像给保龄球道装上保险杠，确保球能击中目标。

这种“人机协作”的模式，并非对 AI 的不信任，而是一种深刻的工程智慧：将开发者的精力从“如何实现”的繁琐细节中解放出来，聚焦于“应该怎样实现”的顶层设计。

AI 的“甜点”与“禁区”：知其长，避其短

要成为 AI 的“架构师”，首先要清晰地认知 AI 这个“初级工程师”的能力边界。Mitchell 在访谈中分享了他眼中 AI 的“甜点区”与“禁区”。

AI 的“甜点”（可以大胆授权）

1. 代码重构：提炼函数、重命名、调整代码结构等机械性工作。Mitchell 的评价是：“我几乎不用给任何修改意见，它总是做得很完美。”

2. UI 复刻：这是一个杀手级应用。他曾直接给 AI 一张 Zed 编辑器命令面板的截图，让它用 Swift UI 复刻出来。Ghostty 的这个功能，其视图部分 90% 以上都是 AI 直接从截图生成的。

3. 注释维护（一个反直觉的惊喜）：在传统观念里，“好的代码应自解释，无需过多注释”。但 Mitchell 的做法恰恰相反，他推崇重度注释：“我做每件事都做两遍：一次用代码，一次用英语。如果注释和代码不匹配，那说明有一方是错的。” 在 AI 时代，这种看似“冗余”的习惯发挥出了惊人的价值：

   • 提供上下文：丰富的注释是 AI Agent 理解代码意图的最佳养料。
   • 成为“校验和”：AI 能通过对比代码和注释的不一致，发现潜在的 bug 或过时的文档。
   • 跨文件洞察：最令人惊叹的是，AI 能在一个文件的修改后，发现另一个完全不相干的文件里，有一行相关的注释变得不准确了——这是人类代码审查时极易忽略的盲点。

   在 Mitchell 的工作流中，注释不再仅仅是文档，它升级成为了人与 AI 高效协作的“接口协议”。

AI 的“禁区”（需要人工接管）

1. 高层架构设计：AI 无法进行有远见的顶层设计。
2. 复杂的、定制化的高性能数据结构：AI 不理解性能约束。Mitchell 举了 Ghostty 的例子，为了极致的性能和缓存亲和性，他们设计了基于虚拟内存页和 16 位偏移指针的复杂数据结构。“没有任何一个 LLM 能理解这里面发生了什么”。
3. 小众语言（如 Zig）的熟练编写：由于训练数据不足，AI 编写 Zig 代码时举步维艰。他的变通方法是：让 AI 用它擅长的语言（如 C 或 Rust）生成逻辑，然后自己手动移植到 Zig。

Mitchell 的实战工作流：一套大师级的“组合拳”

除了哲学思想，Mitchell 还分享了一系列具体、可操作的战术，堪称一套大师级的“组合拳”。

• 并行竞赛：为同一个任务，在多个代码库副本上（ghosty, ghosty2, ghosty3…）同时运行不同的 AI 模型（Claude, Gemini 等），然后选择做得最好的那个。他开玩笑说：“你可以让它们‘战斗至死’，这是对机器才能做的事。”

• “Jiu-Jitsu 快照”：他使用 Jiu-Jitsu（一个现代化的 Git 替代品）的版本快照功能。当 AI 走错路时，他会直接回滚到上一个状态，然后给出新的、更精确的指令，而不是让 AI “撤销”或“重试”，这样更干净、更可控。

• 人机并行工作：在 AI “思考”时，他从不干等。他会利用这段时间去做更需要人类智慧的工作，比如对上一个版本进行 QA 测试，或者观看 WWDC 视频学习新技术。这实现了人机效率的最大化。

• “复制-粘贴式”重构法：这是一个他坚持了十多年的习惯，在 AI 时代变得尤为强大。重构时，他会先复制旧的实现，在新副本上进行修改，让新旧两版代码在项目中并存，直到新的版本完全就绪。这样做能为 AI 提供极其清晰的“before”和“after”上下文，让 AI 更准确地理解重构的意图和模式。

结论：重新定义“高效”，而非放弃思考

听完 Mitchell 的分享，我最大的感触是：Agentic Engineering 不是为了“偷懒”，而是为了重新定义“高效”。

它将开发者从繁琐、重复的劳动中解放出来，让我们能将宝贵的精力聚焦于架构设计、性能调优、代码审查这些真正体现工程师价值的创造性工作上。它不是要替代我们，而是要成为放大我们能力的杠杆。

最后，我想用 Mitchell 的一句话来结尾，以此回应那些对 AI 效果感到失望的人：

“你用过什么新工具是让你立刻就变快的吗？”

无论是学习一门新语言，还是切换到一个新的版本控制系统，我们总要经历一段学习和适应的阵痛期。AI 也不例外。

我们需要学习的，是如何成为一名优秀的“架构师”，去引导和驾驭我们手下这位不知疲倦、潜力无限的“初级工程师”。这，或许就是 AI 时代对我们所有开发者提出的新要求。

原视频链接：https://www.youtube.com/watch?v=XyQ4ZTS5dGw

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/07/19/go-understand-the-zen-of-python-better-than-python

大家好，我是Tony Bai。

最近，在国外的 Go 语言社区（Reddit r/golang）上，一个帖子引发了热烈的讨论。标题颇具“引战”意味：“Go似乎比Python更好地实现了Python之禅”。

这听起来像个悖论，甚至有点冒犯。用一个语言的哲学去评判另一个语言，就像用“太极”的理念去评价“咏春”，似乎风马牛不相及。但仔细看完社区的讨论，你会发现这并非无稽之谈，反而是一个极其刁钻又深刻的视角，能帮助我们重新审视 Go 语言设计的底层逻辑。

作为一名在 Go 的世界里摸爬滚打了多年的老 Gopher，我也不止一次有过类似的感觉。今天，我们就借着这场社区热议，一起聊聊这个有趣的话题。

重温“Python之禅”

首先，让我们重温一下那首著名的“Python之禅”（The Zen of Python）。在任何一个 Python 解释器里输入 import this，你都能看到它：

The Zen of Python, by Tim Peters
Python之禅，作者：蒂姆·彼得斯

Beautiful is better than ugly.
优美优于丑陋。

Explicit is better than implicit.
显式优于隐式。

Simple is better than complex.
简单优于复杂。

Complex is better than complicated.
复杂优于繁杂。

Flat is better than nested.
扁平优于嵌套。

Sparse is better than dense.
稀疏优于密集。

Readability counts.
可读性至关重要。

Special cases aren't special enough to break the rules.
特例不足以特殊到足以打破规则。

Although practicality beats purity.
虽然实用性胜过纯粹性。

Errors should never pass silently.
错误绝不能悄无声息地被忽略。

Unless explicitly silenced.
除非显式地使其沉默。

In the face of ambiguity, refuse the temptation to guess.
面对歧义，拒绝猜测的诱惑。

There should be one-- and preferably only one --obvious way to do it.
应该有且最好只有一种显而易见的实现方式。

Although that way may not be obvious at first unless you're Dutch.
虽然这种方式一开始可能并不那么明显，除非你是荷兰人。

Now is better than never.
现在优于永不。

Although never is often better than right now.
虽然，永不去做常常比“马上”动手要好。

If the implementation is hard to explain, it's a bad idea.
如果实现很难解释，那么它是个坏主意。

If the implementation is easy to explain, it may be a good idea.
如果实现很容易解释，那么它可能是个好主意。

Namespaces are one honking great idea -- let's do more of those!
命名空间是个绝妙的主意——让我们多多地使用它吧！

这不仅仅是代码风格指南，更是一种编程哲学的宣言。而奇妙的是，当我们手握 Go 这把锤子时，会发现很多钉子恰好就是按照这份宣言的图纸来设计的。

“显式优于隐式”：Go 的灵魂，Python 的妥协

这是“Python之禅”中最核心的信条之一，也是 Go 语言最引以为傲（或被吐槽）的特征所在。

想想 Go 语言里最经典的 if err != nil。新手可能会觉得它繁琐、重复，破坏了代码的流畅性。但在经验丰富的工程师眼中，这正是“显式”的极致体现。每一次函数调用，你都被迫直面其可能失败的现实，错误处理的路径清晰得如同一条直线，没有任何隐藏的控制流跳跃。

相比之下，Python 的 try…except 机制虽然优雅，却在某种程度上是“隐式”的。一个 try 代码块里可能有多行代码，任何一行都可能抛出异常，然后被远处的某个 except 捕获。这使得控制流变得不再那么一目了然。一位 Reddit 用户评论说：“自从我见过那些数据科学代码后，‘显式优于隐式’这条让我笑出了声。” 这虽然是句玩笑，却精准地指出了在复杂项目中，隐式处理可能带来的维护难题。

Go 通过把错误（error）设计成普通的值，而不是一个特殊的控制流机制，完美践行了“显式优于隐式”的原则。它是你必须亲手处理的返回值，而不是可以被忽略的“天外来客”。

“简单优于复杂”：Go 的克制与执拗

Go 语言的设计者们（Rob Pike, Ken Thompson 等）深受 Unix 哲学的影响，对“简单”有着近乎偏执的追求。

• 语法克制：Go 只有一个循环关键字 for，没有 while 或 do-while。它没有类和继承，取而代之的是更纯粹的组合与接口。并发模型也异常简单——go 关键字启动一个 goroutine，chan 进行通信，大道至简。
• 工具统一：gofmt 的存在，终结了所有关于代码格式的“圣战”。它体现了“Python之禅”中的另一条原则：“应该有且最好只有一种显而易见的实现方式”。在 Go 的世界里，代码风格不是一个需要讨论的问题，这极大地降低了团队协作的认知负荷。

反观 Python，随着其生态的繁荣和应用领域的扩张，语言本身不可避免地变得越来越复杂。从最初与 Perl、PHP 竞争的简洁脚本语言，到如今涵盖 Web 开发、数据科学、AI 的庞然大物，它引入了 async/await、复杂的元编程能力等。这并非坏事，而是语言成熟和演化的必然结果。但与诞生之初就目标明确（解决 Google 内部大规模工程问题）的 Go 相比，Python 在“保持简单”这条路上，显然背负了更沉重的历史包袱。

客观看待：Go 的“禅意”并非没有代价

当然，我们不能一边倒地吹捧。Reddit 的讨论中也充满了理性的声音。Go 为了实现这种“禅意”，也付出了相应的代价。

• “优美优于丑陋”（Beautiful is better than ugly）：美是主观的。很多人认为 Go 的语法过于朴素，if err != nil 更是“丑陋”的代名词。但正如一位评论者所言：“我喜欢它，正是因为它在美学上很中庸（aesthetically mid）。” Go 的美，更多是一种“工程之美”，是结构清晰、易于维护、性能可靠的美，而非语法糖堆砌出的“华丽之美”。
• “模板代码”（Boilerplate）：Go 的“显式”和“简单”，直接导致了更多的模板代码。这是为了可读性和可维护性做出的权衡。社区也意识到了这一点，因此 Go 在泛型等方面的引入，以及强大的代码生成工具生态，都是在弥补这一“短板”。

小结：源于血脉的哲学共鸣

那么，为什么 Go 会比它的“老师” Python 更像一个“禅宗信徒”呢？

答案可能在它的“血脉”里。Go 的设计者们是创造了 C 语言、Unix 和 UTF-8 的传奇人物。他们骨子里流淌的是系统编程的血液，追求的是在数十、上百乃至上千工程师协作的大型项目中，如何保证代码的长期可读性、可维护性和稳定性。

这种背景决定了 Go 的设计哲学必然倾向于：明确、简单、组合、正交。

它不追求用最少的代码行数表达最复杂的逻辑（那是 Python 的强项），而是追求让任何一个中等水平的工程师都能在最短时间内读懂并安全地修改代码。

从这个角度看，Go 并非“碰巧”契合了“Python之禅”，而是它的核心设计目标——工程化与可维护性——恰好与“Python之禅”所倡导的清晰与简洁产生了深刻的共鸣。可以说，Go 是在用一种更底层、更工程化的方式，对“Python之禅”进行了重新演绎。

所以，回到最初的问题：“Go 比 Python 更懂‘Python之禅’吗？”

或许，更准确的说法是：Go，在它所专注的领域里，以一种更为决绝和纯粹的方式，活成了“Python之禅”希望的样子。

对此，你怎么看？欢迎在评论区留下你的想法。

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

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

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

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

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

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

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