你不会因为手动输入 Git 命令就成为更好的工程师

原文 ↗ Hacker News 讨论 ↗

对这篇文章立场的总体反应

  • 很多人觉得标题像是在挑衅或给人下命令（“你在燃烧自己的生命”），这反而把人推远了，而不是说服他们接受 AI。
  • 一些评论者同意把枯燥、机械的任务交给 AI，但反对这种绝对化的人生建议式的表述。
  • 也有人觉得文章缺少具体例子或证据来支持诸如“AI 做这项工作更好”之类的说法，过于依赖“相信我多年经验”这一套。

用于 Git 操作和 PR 工作流的 AI

  • 一些工程师大量把 git 工作（rebase、merge、分支清理、PR 标记、检查清单更新）委托给代理，称其中大部分都是机械性开销。
  • 另一些人则因为信任和安全顾虑，不让 LLM 直接执行 git，只把它们用于建议或一次性命令。
  • 一个反复出现的观点是：如果你已经理解 rebase、merge 和 fast-forward 这类概念，AI 驱动的 git 是安全且有效的；如果你不理解，就很危险。

提交信息、评论与沟通

  • 对 AI 生成的提交信息和 PR 描述有强烈反对：
    • 往往冗长、无关，没能抓住真正意图。
    • 会削弱 git 历史，让 bisect 和代码考古更困难。
  • 反方观点：LLM 在认真提示下是很出色的总结器，而且可以在团队内强制统一内部文风。
  • 还有几个人认为，手写提交会迫使你理解并对变更负责，从而提升整体技术质量。

把思考外包 vs. 抽象层

  • 有人担心把太多工作交给 AI 会导致技能退化、对自己代码的理解变少；也就是“把思考外包” vs. “用工具消除繁琐”。
  • 其他人回应说，抽象是认知上的必需；AI 只是另一层抽象，类似更高层语言或 IDE 重构。
  • 常见的折中观点：
    • 你至少应该理解自己所处层级下面一层。
    • 如果你仍然会看 diff、跑测试并做判断，那么把苦力活交给 AI 也没问题。

技能、生产力与工程的未来

  • 有人表示，重度使用 AI 的工作流并不会显著加快功能交付，但能腾出时间做设计、安全和数据建模，而且 bug 更少。
  • 也有人担心，如果一个岗位可以简化为在 AI/IDE 上不断点“下一步”，那这个岗位就很容易被替代或商品化。
  • 对低层知识（git、CLI、Linux）的维护被认为很有价值，因为系统出问题时这些知识派得上用场；不过也有人预测，模型最终连恢复任务也能处理。

元讨论：AI 内容与检测

  • 对于不断有人指控每篇文章都是“AI 垃圾”，以及对 AI 检测器的过度依赖，很多人明显感到沮丧。
  • 有人建议的规范是：根据内容是否有用、是否清晰来判断，而不是看它是否经过 AI 辅助。