用手敲Git命令并不能证明你是更好的工程师

背景

2026年7月10日，一位拥有27年编程经验的工程师在Hacker News上发表了一篇反思文章，指出许多开发者仍然坚持手动执行Git命令、编写提交信息、维护代码注释等繁琐任务，并认为这是“工匠精神”的体现。然而，作者认为这种行为在AI时代已成为一种低效的“仪式”，不仅浪费大量时间，还消耗了工程师本该用于解决核心问题的精力。文章强调，AI代理已经能够以更高的一致性处理这些工程杂务，而拒绝接受这一趋势的团队正在“烧钱”和“烧命”。

核心内容

作者回顾了自己在27年编程生涯中逐渐放弃的一系列“小而痛苦”的工程任务。如今，AI代理负责处理提交信息、拉取请求描述、代码注释、命名规范、Git卫生、问题追踪和发布流程，且一致性远超大多数手动管理的团队。

提交信息与PR描述：作者曾花费无数小时撰写高质量的提交信息和PR描述，但大多数同事几乎不写有意义的提交信息。结果在代码审查时，大家又得花更多时间从代码中猜测意图。现在作者将这项工作委托给AI，AI能以作者期望的精确度生成这些信息，让他可以专注于应用本身，而不是为那些可能只会在喝咖啡时扫一眼的开发者写“小书”。

代码注释：作者对注释持平衡态度——既不想用人类可读的英语重写整个代码库，又希望注释遵循特定规则：无表情符号、无装饰性废话、与语言匹配的格式、一致的文件头、包含文件路径（对LLM有用）、单行事实描述、说明所属架构层等。过去维护这些细节要花数百小时，每次变更都要手动更新。现在大部分自动化了，仓库保持良好描述，而作者不再需要耗费脑细胞。有趣的是，最看重这些结构化信息的受众现在是LLM——它们喜欢这种上下文，能利用规则、注释、路径、意图和架构描述，甚至会对作者提出质疑：“你之前写了这条规则，但现在你要求我做相反的事，我们该如何协调？”这种互动让AI辅助工程流程更流畅，仓库不再是源码堆，而是携带了足够明确的意图，让代理能挑战不一致性。

命名：命名文件、类、函数、模块等曾是作者耗费大量时间的工作。他写过几十份开发指南，包括命名约定、目录结构、后缀前缀、抽象、例外以及例外的例外。AI能做得更好：项目一年后不会出现30~40种不同的文件命名风格，命名冲突减少，不再需要花10分钟回忆六个月前某个紧急检查对应的文件名。即使改变主意也变得几乎无关紧要——只需说“不要用class PostgreSQLClient {}，改用通用名称如class DatabaseClient {}”，代理就能执行重构、更新引用、运行测试、修复遗漏点，并在ticket中勾选相关复选框。改变主意过去很昂贵，现在对很多更改来说只是一个指令。

Git管理：作者不再手动处理Git。以前常犯的低级错误——在dev、main或无关特性分支上开始工作——现在由代理检查：“你在dev上，我将创建合适的分支并继续工作。”代理还能创建带有[WIP]的PR、应用正确标签、指定评审人、编写有意义的描述、添加复选框并在任务完成时更新。它可以创建GitHub Issue，移动到正确的项目列，链接Issue与PR，应用标签，编写描述。作者不再需要思考这些细节，可以专注于找到问题的最佳解决方案。

交付流程：作者通过调用/definition-of-done技能来检查实现是否覆盖PR和计划中的内容，检查测试和其他验证。一切正常后再调用/pr-check-release技能，更新标签、移除[WIP]、添加[RFC]、更新描述。如果一天内团队无人审查，则合并。代理跟踪条件，作者运行/pr-merge-dev即可完成合并、删除远程和本地分支、拉取最新dev。每个步骤都不难，但正是这些微小的任务积少成多。

作者总结：这些微小、痛苦的任务有成千上万个，它们消耗的不是几分钟，而是数小时，乘以每个工程师、每个PR、每个发布、每个分支错误、每个遗忘的复选框、每个过时的描述、每个命名讨论、每个未正确链接的Issue、每个过时的注释、每个需要有人记住的仓库维护细节。作者仍然关心所有这些事情，但不再认为必须亲手完成每一个机械步骤才能算作专业工作。2026年，如果你不把这类工程开销委托给AI，你就是在烧钱，更重要的是，在烧自己的生命。

关键要点

• 手动执行Git命令、撰写提交信息和PR描述并非“更高阶的工匠精神”，而是一种低效的习惯，浪费了大量时间。
• AI代理能持续、一致地完成这些枯燥任务，且质量往往超过大多数团队手动维护的水平。
• 代码注释的结构化对LLM（AI代理）极有价值，能帮助代理理解意图并指出不一致性，从而提升人机协作效率。
• 命名规范、文件结构等细节可完全交由AI管理，避免了项目后期风格混乱、命名冲突等问题，且改变主意成本极低。
• Git操作（分支管理、PR创建与更新、Issue关联等）可通过AI代理自动化，消除人为错误，减少上下文切换。
• 交付流程可分解为一系列可检查的步骤，由代理按条件执行合并、标签更新、分支清理等操作，无需手动操作。
• 微小任务的累积成本极高，不仅消耗个人时间，还乘以团队规模，导致巨大的隐性开销。
• 拒绝AI辅助的工程师可能高估了手工操作的价值，实际上正在浪费公司的金钱和自己的生命。

意义与影响

这篇文章反映了2026年AI辅助编程领域的一个显著趋势：从“帮助写代码”扩展到“帮助管理工程流程”。它挑战了传统观念中“手写Git命令、手动维护PR描述”等于专业性的认知，认为这些机械性工作不应成为衡量工程师能力的标准。作者的观点具有双重意义：

1. 对个人工程师：提醒他们重新评估时间分配，将精力从重复性杂务转移到真正需要创造性、判断力和系统思考的任务上。拒绝AI辅助可能意味着在竞争中落后，因为AI能够更高效地处理这些“隐形工作”。

2. 对团队和组织：暗示了工程效率的新度量标准——不再是人手完成多少任务，而是能否通过AI代理将工程开销降到最低。文章指出“烧钱”和“烧命”的警告，意味着那些坚持手工管理的团队可能在成本、交付速度和员工满意度上全面落后。

此外，作者特别提到LLM如何成为“最欣赏代码结构化”的受众，这一观察值得深思：随着AI代理越来越多地参与代码审查、重构和生成，代码的可读性不再仅仅服务于人类同事，还要服务于AI。这可能会推动新的编码规范和文档标准，使代码库既对人友好，也对机器友好。最终，AI辅助工程可能从“可选”变成“标配”，而手工执行这些任务将逐渐被视为一种不必要的怀旧行为。