本文永久链接 – https://tonybai.com/2025/06/03/provocation-about-ai-assisted-programming

大家好，我是Tony Bai。

最近，fly.io 博客上该公司开发者 Thomas Ptacek 的一篇题为《My AI Skeptic Friends Are All Nuts》的文章，在开发者社区掀起了不小的波澜，一度登顶HN。Ptacek 以一位自称“严肃开发者”（从C语言到Go、Rust均有涉猎）的口吻，向那些对 AI 辅助编程持怀疑态度的“聪明朋友们”发出了略带“挑衅”的宣言：“即使 LLM 今天停止所有进展，它仍然是我职业生涯中发生的第二重要的事情” 。

这篇文章的观点之鲜明、论证之犀利，让我印象深刻。恰逢 前期Google I/O 2025 大会再次展示了 Gemini 等 AI 模型在编码领域的惊人进展，我们不禁要问：AI 编码工具，究竟是能极大提升生产力的“真香”利器，还是又一轮被过度炒作的“智商税”？作为开发者，特别是 Gopher，我们又该如何看待和应对这场正在发生的变革？

在这篇文章中，我就和大家一起来看看 Thomas Ptacek 对AI辅助编程演进的犀利观点以及他的反思。看看你是否认同他的想法。

误区澄清：现代 AI 辅助编程早已不是“复制粘贴”

Ptacek 在文章开篇就点出了一个关键问题：很多人对 AI 辅助编程的印象，还停留在半年前甚至两年前的水平。他写道：“如果你在6个月前（或者，天哪，两年前用Copilot的时候）尝试使用LLM编码并失败了，那么你并没有在做大多数严肃的LLM辅助编码者正在做的事情”。

那么，现在“严肃的LLM辅助编码者”在做什么呢？Ptacek 强调，他们使用的是 Agent (智能体)。这些 AI Agent 不再仅仅是根据提示生成代码片段让你复制粘贴，它们能够：

• 自主地在你的代码库中进行探索。
• 直接创建和修改文件。
• 运行各种工具， 如编译器、测试框架、linter、formatter 等。
• 与 Git 等版本控制系统交互。
• 根据编译和测试结果进行迭代和修正。
• 通过 MCP 或类似机制调用你设置的任意工具。

Ptacek强调：如果你对 AI 编码的印象还停留在 ChatGPT 网页上简单问答然后手动复制代码，那么你可能真的低估了当前 AI Agent 所能达到的自动化和智能化水平。

AI Agent 如何提升编码效率？Ptacek 的“积极案例”

Ptacek 认为，LLM（通过 Agent）能够极大地提升编码效率，主要体现在以下几个方面：

1. 处理“乏味代码”： LLM 可以编写你需要编写的大部分乏味代码。而大多数项目中的大多数代码都是乏味的。这能让开发者从重复性的工作中解放出来，更快地进入“调整代码并立即看到效果更好”的“黄金时刻 (golden moment)”，获得即时反馈的“多巴胺冲击”。

2. 克服项目启动的“惯性”： 面对一个新项目，繁琐的初始设置、依赖管理、基础架构搭建等往往令人望而却步。LLM Agent 可以被指示去“搞定这些破事，直接将你带到“事情几乎可以工作”的阶段。

3. 自动化“苦差事”： 那些你不想做但又必须做的“脏活累活”，比如大规模的单元测试重构，完全可以交给 AI Agent 在虚拟机里折腾几个小时，然后带着一个 PR 回来。这反而会“逼迫”你去做“真正的工作 (real work)”。

回应常见的质疑：Ptacek 的“辩护”

Ptacek 在文章中也针对开发者对 AI 编码的常见质疑进行了犀利的回击，这些回应也为我们思考 Go 语言在 AI 时代的定位提供了新的视角。

• 关于代码质量与审查责任——“你根本不知道它写的是什么！”

Ptacek强调，开发者始终对合并到 main 分支的代码负责，无论是否使用 LLM。 LLM 生成的代码是“可知的”，你需要阅读它，甚至花时间将其调整为你自己的风格。如果连 LLM 生成的“乏味、重复”的代码都难以理解和消化，那可能是开发人员的“技能问题”。

• 关于“幻觉 (hallucination)”问题——“它会编造不存在的API！”

Ptacek 认为，对于编程而言，Agent 通过工具链（linting、编译、运行测试）形成的闭环反馈，已经（或多或少地）解决了“幻觉”问题。“如果它们的LLM编造了一个新的函数签名，Agent会看到错误。它们将其反馈给LLM，LLM会说‘哦，是的，我完全是编造的’，然后重试”。这里不能不提到** Go 语言的快速编译特性，使得这种“试错-反馈-修正”的闭环能够非常高效地运转。同时，Go 强大的标准库和清晰的 API 设计，是否也能减少 LLM“编造”API 的概率，或者使其更容易被工具链检测出来。

• 关于“代码像初级开发者写的”——“质量太差！”

Ptacek 回应：“一个实习生一个月要花20美元吗？因为 Cursor.ai 就是这个价钱”。他认为，高级开发者的职责之一就是让能力稍逊的编码者（无论是人类还是“智能体”）变得高效。使用好 Agent 本身就是一项技能和一项涉及提示、索引和（尤其是）工具链的工程项目。 LLM 只有在你允许的情况下才会产生劣质代码。

• 关于“不擅长特定语言 (如 Rust)”——“它写不了我的 Rust！”

Ptacek 认为这更多是语言生态和工具链成熟度的问题，而非 LLM 能力的根本缺陷。他特别指出：“我主要用 Go 工作……Go 恰到好处的类型安全、广泛的标准库以及推崇（通常是重复性）惯用法的文化。LLM 在生成 Go 代码方面表现出色。” 想必很多Go开发者也有着与Ptacek相同的感受，这是 Go 语言在 AI 辅助编程时代的一个显著优势！ Go 的简洁性、明确性、强大的标准库覆盖、以及社区对代码规范和惯用法的重视（例如 Effective Go），使得 Go 代码的模式相对统一和可预测，这为 LLM 的学习和生成提供了极大的便利。

对“手工艺精神”与“平庸代码”的再思考

Ptacek 对软件开发中的“手工艺精神”和对“平庸代码”的过度排斥也提出了批判。

• 他认为：专业软件开发者的工作是用代码为人们解决实际问题。在日常工作中，我们不是工匠。过度追求代码的“优雅”而忽视实际产出，可能是“自我安慰的yak-shaving（指做无关紧要的琐事）”。

• 对于“平庸代码”，他认为：开发者都喜欢对代码自吹自擂。他们担心LLM降低了质量的“天花板”。也许吧。但它们也提高了“地板”。LLM 生成的“平庸但彻底”的代码，可能比人类开发者“抖机灵”但引入缺陷的代码更有价值。

这也引发我们思考：在追求卓越工程的同时，我们是否也应该更务实地看待不同场景下对代码质量的不同要求？LLM 是否能帮助我们更高效地处理那些“允许平庸”但又耗时耗力的部分，从而让我们能将精力投入到真正需要人类智慧和创造力的核心工作中？

Go 开发者如何拥抱 AI Agent 的时代？

Ptacek 的文章，无论你是否完全认同其所有观点，都为我们描绘了一个 AI Agent 深度参与软件开发的未来图景。作为 Gopher，我们应该如何应对？

1. 更新认知，拥抱变化： 首先要认识到，现代 AI 辅助编程已经远超简单的代码补全。应该主动去了解和体验基于 Agent 的编码工具。
2. 学习与 AI Agent 高效协作： 掌握提示工程技巧，学会如何清晰地向 Agent表达需求、提供上下文、引导其生成和修改代码。
3. 发挥 Go 语言的优势： 利用 Go 的简洁性、强大的标准库、快速的编译和测试工具链，为 AI Agent 构建高效的开发和反馈环境。思考如何让 Go 代码对 AI 更“友好”。
4. 提升自身的核心价值： 将精力更多地投入到 AI 难以替代的领域：复杂系统设计、架构决策、需求理解与抽象、创新思维、以及对 Go 底层原理和并发模型的深刻理解。
5. 参与构建 Go 的 AI Agent 生态： Go 语言本身非常适合构建 CLI 工具和后端服务。我们是否可以利用 Go 来创建更强大的、针对 Go 开发的 Agent 辅助工具或平台？

小结：保持开放，主动实践，与 AI 共舞

AI 编码工具究竟是“真香”还是“智商税”？或许答案因人而异，也因我们如何使用它而异。但 Thomas Ptacek 的“挑衅”至少提醒我们，不能用静止的眼光看待飞速发展的技术。

AI 辅助编程的浪潮已然到来。对于我们 Gopher 而言，Go 语言的特性使其在这波浪潮中具有独特的优势。与其固守过去的经验和偏见，不如保持开放的心态，主动去实践和探索，让 AI Agent 成为我们提升自身能力、加速项目交付、并最终能专注于更有创造性工作的强大伙伴。

毕竟，正如 Ptacek 所说，当他那些“聪明的怀疑论朋友们”最终接受并开始使用这些工具时，他们将会让编码 Agent 比今天强大得多。

而我们，又怎能置身事外呢？

聊一聊，也帮个忙：

• 你目前在工作中使用 AI 辅助编程工具（如 Copilot, Cursor.ai, Gemini Code Assist，Trae等）的体验如何？它在哪些方面帮助了你，又有哪些不足？
• Ptacek 文章中对 AI 编码的哪个观点让你印象最深刻？你同意还是反对？为什么？
• 你认为 Go 语言在 AI 辅助编程时代，还有哪些可以进一步优化的方向，以更好地与 LLM Agent 结合？

欢迎在评论区留下你的思考和经验。如果你觉得这篇文章提供了一个值得探讨的视角，也请转发给你身边的开发者朋友们，一起参与这场关于 AI 与编程未来的讨论！

想与我进行更深入的 Go 语言、AI 赋能开发与技术趋势交流吗？ 欢迎加入我的“Go & AI 精进营”知识星球。

我们星球见！

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

本文永久链接 – https://tonybai.com/2025/04/24/conventional-commits-guide

告别混乱Commit Log！用规范指引你写出有意义的提交！

大家好，我是Tony Bai。

Git的Commit Log (提交日志) 是项目演进的脉络，也是开发者之间沟通变更、追溯历史、理解代码演变的关键载体。然而，在实际开发中，我们常常面对杂乱无章、意义不明的提交信息——”fix bug”、”update code”、”wip” 等屡见不鲜。这些模糊的记录不仅让代码审查、问题排查和版本追溯变得异常困难，也阻碍了自动化流程的实施。Conventional Commits (约定式提交) 规范提供了一套清晰、简洁的指引，旨在将每一次提交都转化为有意义、结构化的信息单元，从而显著提升 Commit Log 的价值和可利用性。

在这篇文章中，我们将探讨Conventional Commits如何作为一项关键指引，帮助开发者和团队构建更清晰、更一致、更具信息量的提交历史。

1. Commit Log的困境：为何需要指引？

缺乏明确指引的Commit Log往往会陷入以下困境：

• 信息熵高，有效信息少: 大量模糊、随意的提交信息混杂在一起，难以快速定位关键变更或理解特定提交的目的。
• 沟通效率低下: 团队成员需要花费额外时间去解读他人的提交意图，代码审查效率降低。
• 历史追溯困难: 当需要回溯某个功能或 Bug 的引入/修复历史时，无结构的日志如同大海捞针。
• 自动化阻碍: 不一致、不可预测的提交信息使得自动化生成 Changelog、语义化版本控制（SemVer）等流程难以实现。

面对这些普遍存在的困境，业界亟需一套行之有效的规范来引导开发者记录更有价值的提交信息。这正是 Conventional Commits 规范所要解决的核心问题，它通过引入一套简洁而强大的结构化指引来实现这一目标。Conventional Commits并非强制性的铁律，而是一套强大的指引 (Guidance)，它通过引入轻量级的结构化约定，引导开发者在提交时思考并明确表达变更的性质、范围和影响。

2. Conventional Commits 核心指引：结构化的力量

该规范的核心指引体现在其简洁的提交信息结构上(如下所示)：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

遵循这项指引，每次提交都应包含以下关键要素：

• Type (类型): [必须遵循的指引] 表明提交的性质。规范定义了基础类型：

  • fix:：修复 Bug (对应 SemVer PATCH)。
  • feat:：引入新功能 (对应 SemVer MINOR)。
  • 鼓励扩展: 团队可以根据需要定义其他类型，如 build, chore(用于标记那些不涉及新特性或修复的常规维护工作，比如更新依赖项等), ci, docs, style, refactor, perf, test等，以适应具体工作流。这些扩展类型本身通常不直接影响版本号（除非包含破坏性变更）。

• Scope (范围): [可选但推荐的指引] 明确提交影响的代码库区域或模块，用括号包裹，如 feat(api): 或 fix(parser):。这极大地增强了信息的可定位性。

• Description (描述): [必须遵循的指引] 紧跟冒号和空格，用简洁的语言（推荐使用祈使句现在时）概括本次提交的核心变更内容。这是提交信息的“标题”。

• Body (正文): [可选指引] 当简短描述不足以说明时，提供更详细的上下文、动机和实现细节。与 Description 之间需空一行。

• Footer(s) (脚注): [可选指引] 提供元数据，如关联 Issue (Refs: #123)。特别重要的两个脚注指引：

  • BREAKING CHANGE: ：明确标示不兼容的 API 变更 (对应 SemVer MAJOR)。
  • INITIAL STABLE RELEASE: ：标记项目从 0.y.z 进入 1.0.0。

强调重要变更的简化指引： 规范还提供了 ! (紧跟 type 或 scope 之后) 和 !! 作为标记 BREAKING CHANGE 和 INITIAL STABLE RELEASE 的快捷方式，进一步简化遵循指引的实践。

为了更直观地理解这个结构，以下是一些典型的Conventional Commits示例：

• 简单的 Bug 修复:

fix: correct minor typos in documentation

• 带范围的新功能:

feat(lang): add Polish language support

• 使用 ! 标记破坏性变更:

refactor!(auth): remove deprecated JWT authentication method

注意：这里的 ! 表明这是一个破坏性变更，即使type是refactor。

• 包含详细正文和脚注的提交:

perf(api): improve user query performance significantly

Implemented a new indexing strategy for the users table and optimized
the SQL query execution plan. Initial tests show a 50% reduction
in average query latency under heavy load.

Reviewed-by: Alice <alice@example.com>
Refs: #456, #478

• 使用 !! 标记首次稳定版发布:

chore(release)!!: prepare for 1.0.0 stable release

Finalized documentation, updated dependencies, and ran comprehensive
end-to-end tests to ensure stability for the first major release.

INITIAL STABLE RELEASE: The project is now considered stable for production use.

通过遵循这些简单的指引，原本混乱的Commit Log就被转化为结构清晰、信息丰富的记录。

理解了 Conventional Commits 的核心结构和要素后，我们自然会问：遵循这项指引究竟能为开发者和团队带来哪些实实在在的好处？答案是多方面的，它能让原本静态、难以利用的 Commit Log “活”起来，释放出巨大的潜在价值。

首先，结构化的 type 和 scope 提升了可读性与可理解性，使团队能够快速筛选和定位信息，清晰的 description 和 body 阐述了变更的“什么”和“为什么”。

其次，一致的格式增强了团队沟通与协作，减少了误解，提高了代码审查和协作效率，使每一次提交都成为清晰的沟通。

此外，结构化的日志简化了历史追溯与问题排查，便于查找特定功能引入、Bug 修复或破坏性变更的源头。

最后，一个充满有意义提交的日志自然而然地成为自动化工具的理想输入，能够驱动自动化生成 CHANGELOG、自动化 SemVer 版本判断，以及基于提交类型触发不同的 CI/CD 流程。

认识到 Conventional Commits 带来的显著价值后，如何在日常开发中有效地遵循并最大化其效益，就成了一个关键问题。仅仅了解规范的语法是不够的，掌握一些最佳实践和深入的洞察，能帮助我们更好地将这项指引融入工作流。

3. 遵循指引的最佳实践与洞察

为了更好地应用Conventional Commits指引，以下几点值得关注：

• 原子化提交: 我们鼓励将复杂的变更分解为多个逻辑上独立的、遵循单一type的提交。这本身就是一种良好的 Git 实践，很多大厂的git commit规范以及代码review规范也是这么要求的。Conventional Commits 进一步强化了这一点。

• 选择最合适的Type: 当一次提交包含多种类型的变更时（虽然应尽量避免），选择最能代表其核心意图的 type，并在 Body 中详述其他变更。

• 祈使句现在时: 推荐使用如 “Add feature”、”Fix bug” 的风格撰写 Description，简洁、直接，如同给代码库下达指令。

• 利用工具辅助: 社区提供了丰富的工具（如Commitizen, commitlint等）来帮助开发者遵循规范格式，并在提交前进行校验，降低遵循指引的负担。

• 团队共识与逐步采纳: 引入规范需要团队达成共识。可以通过分享、讨论和使用工具逐步推广。

当然，良好实践的推广离不开工具的支持。幸运的是，围绕 Conventional Commits 已经形成了一个活跃的社区和丰富的工具生态系统，它们极大地降低了开发者遵循规范的门槛，让指引更容易落地。

4. 社区生态：工具让指引落地

Conventional Commits 的流行离不开活跃的社区和丰富的工具支持，它们帮助开发者轻松地将这项指引融入日常工作流：

• Commitizen: 交互式命令行工具，引导用户创建符合规范的提交信息。
• Commitlint: 用于校验提交信息是否符合规范，常与 Git Hooks (如 husky) 集成。
• IDE 插件: 主流 IDE (VS Code, JetBrains IDEs 等) 均有插件提供模板、补全和校验支持。
• 自动化版本与 Changelog 工具: 如 semantic-release, goreleaser/chglog等，它们消费符合规范的提交历史。

这两年基于大模型的辅助生成commit log的工具以及一些代码智能体应用(如Cursor等）也在规范git commit log方面起到了非常积极的作用，对于像我这样英语非母语但又喜欢以英文log提交的选手来说，这些工具大幅降低了我在纠结如何写commit log时的心智负担，给予了我很大的帮助。

5. 小结

总而言之，Conventional Commits 远不止一套冷冰冰的格式规则，它更像是一位贴心的向导，一项旨在将每一次提交都转化为宝贵信息资产的核心指引。它赋予我们结构化的力量，能够将困扰许多团队的混乱、低效的Commit Log，转变为清晰、一致且富有洞察力的项目演进历史——这对于提升代码可维护性、团队协作效率乃至自动化流程都至关重要。

现在，就将这项指引融入你的日常开发吧！ 让每一次git commit不再是随意的记录，而是对项目演进负责任的、有意义的贡献。

那么，你的团队是如何采纳和实践提交规范的？你在使用Conventional Commits或其他规范时，有什么独到的心得或踩过的“坑”吗？

非常期待在评论区看到你的分享与交流！

如果这篇文章让你觉得“提交信息确实应该更有意义”，请分享给你的同事或团队，一起提升代码库的 Commit Log 质量吧!

别忘了关注我，持续获取更多提升研发效能的实用技巧与深度解析。

6. 参考资料

• Conventional Commits v1.0.0 – https://www.conventionalcommits.org/en/v1.0.0/#specification

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格6$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
• Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。