在大语言模型时代保持编程的乐趣

大语言模型（LLM）的兴起为开发者带来了一个悖论：虽然生产力可能提高，但编程的内在乐趣——即通过代码表达思想的行为——往往被审查 AI 生成的“垃圾内容”这一枯燥任务所取代。为了避免 AI 倦怠和技术能力的退化，开发者必须从 AI 代理的“肉身代理”转变为将 LLM 作为规划和研究的高杠杆支持工具。

“氛围编程”的风险与技能退化

过度依赖 LLM 生成的代码会导致代码库和程序员认知能力的双重退化。当开发者停止编写代码，转而依赖代理生成整个文件时，他们就有可能创造出一个“LLM 荒原”——这些代码库对人类来说难以阅读，且只能由其他代理来维护。

除了代码库之外，人类付出的代价是技能退化。正如社区成员所指出的，当将架构设计或在编程语言中进行深度思考的任务外包给 LLM 时，这些能力会迅速消失。

“我亲眼目睹了这种情况发生在我自己身上，突然间我在规划一个小项目的架构时遇到了困难……我意识到，当我向 Claude 询问一堆想法，然后根据我的经验选择最好的一个时，我是在锻炼那项技能。我并没有锻炼从零开始提出解决方案的技能。” — @handle

可持续的工作流：以人为本的 AI 辅助

为了保持职业成长和个人乐趣，最有效的工作流是共同规划，独立编码。在这种模式下，LLM 处理附带的、枯燥的、大批量的工作，而人类保留对实现的掌控权。

1. 用于规划和记录的 LLM

不要让 LLM “构建这个功能”，而是将其用作自然语言记录工具。利用它来：

• 将领域专家的对话转换为可执行的待办事项列表。
• 将测试结果整理成修复缺陷的结构化计划。
• 在 Markdown 文件中跟踪规划项，以避免上下文窗口丢失。

关键规则： 永远不要让 LLM 做出关键的架构决策。当它到达决策点时，强制它向你寻求指导。

2. 用于研究和探索的 LLM

使用代理来收集信息，但不要将其结果视为绝对事实。AI 研究的目标是消除“让我为你谷歌一下”的摩擦，而不是取代开发者对领域的理解。

• 要求代理提供资源链接。
• 通过询问代理具体是哪个资源支持该主张来验证奇怪的提议；这通常会触发模型发现自己的幻觉。
• 与搜索引擎并行研究，以确保你对领域的理解与代理相当或更好。

3. 人类作为主要编码者

拒绝“先规划，再让代理编码”的诱惑。相反，让 LLM 研究代码库，识别必要的编辑点，并警告你潜在的陷阱，但由你来编写实际的代码。这种方法有几个优点：

• 所有权： 你始终了解代码库的确切状态。
• 早期检测： 你可以在实现阶段识别出糟糕的计划，而不是在代理花费一小时生成一个有缺陷的解决方案之后。
• 技能维护： 你可以继续磨练你的编码能力。

实施自动化审查周期

为了确保质量，任何 LLM 生成的产物（包括计划）在没有经过自动化审查周期的情况下都不应被接受。这模仿了生成对抗网络（GAN），其中一个“生成器”代理产生工作，而一个“判别器”代理对其进行审查。

这个周期对于以下情况特别有用：

• 代码审查： 使用单独的代理来查找你自己手写代码中的错误或遗漏。
• 计划验证： 使用审查代理来发现逻辑漏洞（例如，一个计划在第 2 步需要一个函数，但直到第 7 步才编写该函数）。

管理技术和心理限制

处理令牌耗尽

令牌限制应被视为服务中断，而不是购买不足。为了防止工作陷入停滞，请维护一份切实可行的待办事项列表，以便在离线时进行工作。这确保了当“技术封建领主”限制你的访问权限时，你仍然可以独立地持续创造价值。

避免“LLM 乱码”

过度消耗 LLM 生成的文本可能会在精神上令人疲惫。为了保护心理健康，请限制对原始 LLM 输出的消耗，并优先考虑人与人之间关于高层愿景和架构讨论的沟通。避免向同事发送完全由 AI 生成的 PR 正文，因为这是工具输出，而不是真正的沟通。

对职业未来的展望

社区讨论揭示了开发者在看待编码自动化方面存在深刻的分歧：

• 业余爱好者的观点： 一些人认为编程正在从一种职业转变为一种爱好，类似于铁匠或制琴师——在经济上不切实际，但在个人层面上令人满足。
• 效率观点： 另一些人则认为，主要目标是解决业务问题，如果 LLM 加快了这一过程，那么敲击代码的“手艺”就是一种不必要的感伤依恋。
• 混合观点： 许多人通过使用小型、快速的模型来处理日常任务（例如创建具有特定不变量的领域类），同时牢牢掌握架构控制权以避免“代理蜂群”的开销，从而取得了成功。