2026年还有必要手写代码吗

背景

这篇文章来自 Hacker News 上的一篇讨论帖，标题为《Why Write Code in 2026》。作者针对当前 AI 编程助手（Coding Agents）日益普及的背景下，提出一个核心问题：当 AI 已经能生成绝大多数代码时，人类是否还有必要亲自写代码？文章反驳了“只需通过提示词管理软件工厂，不再需要手写代码”的极端观点，主张人类写代码仍然具有不可替代的价值。

核心内容

作者首先描述了一种流行的观点：软件工程师的职责不再是写代码，而是构建“软件工厂”——即搭建能让 AI 智能体成功运行的底层基础设施。工程师通过提示词（技能、AGENTS.md、知识库等）主动引导，通过自动化评估（测试、lint、类型系统、eval、其他 AI 等）被动保护。只要保持智能体在轨道上，即使是一个愚蠢的模型，在新鲜上下文中也能在这些约束下产生足够好的变更。以至于看代码都显得荒谬，写代码更是可笑。

作者明确表示不同意这种观点。他认为，写代码仍然有用。即使人类拥有像“Fable”那样的智能（这里的“Fable-like intelligence”可能是指某种有限或模拟的智能，类似寓言故事中的简单智慧），从写代码中也能获得价值。不是因为智能体比人类编码差，而是因为人类需要直接在执行环境中思考，而不是通过英语代理。

这关乎注意力和理解。为了保持注意力，人类不能仅仅像远距离观察智能体的被动观察者那样“阅读代码”。要真正与系统的架构建立连接，必须亲身体验代码。作者比喻说，他不想要那种扁平的2D差异和补丁系统，而是需要一种带有痛感传感器的完整4DX虚拟现实体验，来感受正在发生的事情。

这并非因为“代码不漂亮”，而是为了体验脆弱性。如果作者自己很难在不破坏代码的情况下在上面构建，那么智能体就更难理解它。如果作者能清理代码，记录一致的架构原则，且没有半打例外，那么软件工厂就能运行得更好。如果作者能调试、发现测试策略薄弱的环节并找到修复方法，就能消除一整类新的 bug。

当然，你也可以不写代码就做到这些。作者表示不会说教，不会称你为“slop-kitty”（意指产出劣质代码的人），也不会说真正体验软件的唯一方式是磁化针和稳定的手。作者自己也被“AI 精神错乱”感染，绝大部分代码是 AI 生成的。尽管如此，他发现写代码仍然是一个有用的工具，并鼓励其他人也这样做。

当作者只是作为一个“反向半人马”（reverse centaur，指人类只做审核、AI 做实际工作）时，他很难保持专注。当他阅读和批准代码时，他发现自己没有同样的主人翁感。劣质代码（slop）会悄悄溜走，更难微调，长期来看，劣质代码也会伤害智能体。脆弱性累积正是因为人类没有关注细节。另一方面，当人类亲自做一些工作，先提出一个方法（spike），然后让智能体按照模式生成代码时，人类就能参与并拥有最终结果。

写代码帮助作者思考。英语是一种规格不足的语言，不是表达计算的精确方式。对于真正算法性的工作，作者希望用可执行的步骤草图和思考，需要校准的精确度。有时是低层级语言，拥有巨大的设计空间；有时是高层级语言，拥有更受限的计算环境。

然而，我们正在转向一种错误的思维模式：把编码智能体当成编译器。这种思维让我们允许自己发布写得糟糕的代码。智能体不是编译器——它们更像是刚入职的实习生。它们阅读部分可能被劣质化的代码，接受一个不精确的变更描述，然后必须生成变更。

人类不能把自己的思考和品味交给一群实习生。亲自动手，而不是作为消费者，是有帮助的。

例如，你见过智能体遵循“童子军规则”（离开时让代码比之前更好）吗？你会希望它们尝试这样做吗？智能体倾向于尽可能安全地完成当前变更。作者曾遇到一个情况：在一个旧代码库中，一天早上还没喝咖啡时，他的人类大脑提到了使用浏览器本地存储。于是一些随机状态被放到了本地存储中，而其他一切通过后端数据库管理。当他查看代码时，为了保留这个愚蠢的人类错误而进行的包装和间接引用，可能使代码行数增加了三倍。智能体通过过于保守，放大了人类一次性的糟糕决策。

通过快乐地删除代码和探索，作者找到了更好的架构，而不是仅仅通过英语代理。他的思考、他的创作权、他引导重构的能力，都因为关心代码而得到了极大增强。

如果我们正在构建一个软件工厂，细节很重要。那些建立架构模式的细节，一直到算法和性能。智能体推动我们去评估、测量和防御。它们让在早期项目中就加入 CI 变得很酷，而不是事后补救。这是对软件状态的巨大改进。

但任何装配线都有其薄弱点。有时在汽车工厂，我们需要拆解装配线，或者深入内燃机的细节以取得 10% 的改进，或者花一整天观察刹车片测试，以找出为什么某个现场问题没有被早期检测到。我们需要这样做，而不是把整个工厂的图景都装在脑子里。我们要将微小细节与大局联系起来。在软件中，人为划定你能触碰的边界会妨碍这种努力。

关键要点

• AI 编码智能体不是编译器，而是实习生：它们无法像编译器那样精确可靠，需要人类提供清晰的指引和约束，否则会放大人类的错误。
• 写代码帮助人类思考：英语不是精确的计算表达语言，通过代码直接思考可以避免歧义，获得校准的精确度。
• 亲身体验代码才能理解系统脆弱性：被动阅读代码或审核 AI 生成的代码会失去对细节的感知，导致脆弱性累积。
• 人类的主人翁感和注意力需要亲手写代码来维持：当人类只做“反向半人马”时，容易失去对代码的拥有感，劣质代码会悄悄溜走。
• 智能体过于保守，会放大人类的一次性糟糕决策：例如为了保留一个错误设计，智能体会生成大量冗余包装代码。
• 细节决定软件工厂的质量：从架构模式到算法性能，人类需要亲手参与调试、清理和重构，才能建立更好的系统。
• 写代码是一种探索和思考工具：有时需要低层级语言，有时需要高层级语言，手动编写可以帮助发现更好的设计方案。
• 人类不应完全放弃品味和判断力：把思考交给一群“实习生”智能体是不明智的，亲身参与能提升最终结果的质量。

意义与影响

这篇文章是对当前 AI 编程热潮中一种极端“自动化”观点的重要纠正。作者并不否认 AI 生成代码的效率，也不主张回到手工编码的原始时代，而是强调人类在软件开发中的核心角色不应被削弱。他提出的“软件工厂”比喻很有启发性：工厂虽然自动化，但工程师仍然需要亲自检查、维护、优化生产线，甚至拆解它来理解根本原因。

在 AI 辅助编程日益成为主流的 2026 年，这篇文章提醒我们：人类写代码的价值不在于“写”本身，而在于通过写代码来思考、理解、感受系统的脆弱性，并建立真正的所有权。这种“主动参与”与“被动审批”之间的差异，将直接影响软件系统的长期健康和可维护性。

对于团队而言，这意味着不能完全依赖 AI 智能体来承担所有编码任务，而应该保留人类在关键