你正滑向 AI 倦怠吗？害怕被那些没什么编程功底、不在乎质量，却手握巨额 Claude 额度的人抢走饭碗？对自己项目里的代码质量感到失望，甚至对「你自己的」代码更失望？这篇文章就是为你写的。
关于大科技公司运营的前沿 LLM，确实存在重大且合理的伦理担忧，这些已被广泛讨论，我知情且认同——但本文不会讨论这些。请别把我误认为是 LLM 拥趸。
另外：由于以前有人误以为我的文字是 LLM 生成的，我在这里先说明：这完全是人类手写，没有任何 AI 协助。
大机器中的灵魂
Sean Mcmullen 的同名精彩小说是我少年时代读过的最爱。乍一看，它描述的情景与我们当下完全相反：一台巨型计算机，其中每个组件都是人类，他们协作组成一台计算单元。而另一方面，LLM 本身则运行在真实的计算机上，假装自己是（超级）人类。但再看一眼，故事与现实其实相去不远：我们在软件生产过程中的角色，正被缓慢地从「演员」降格为「机器中的齿轮」。规范驱动的反乌托邦（spec-driven dystopia）是这样一幅图景——我们只是被分发一份需求规格，把它硬塞进 LLM，然后当 token 用光时痛哭流涕，因为某个技术封建领主决定少发一些给我们。
作为一名 Haskell 程序员，我享受编写 Haskell。是的，我非常喜欢我们在工作中做出来的产品，也喜欢我那些开源库能派上的用场，但我真正享受的，是用这门语言表达自己想法的这个过程。我猜这对你们大多数人来说也是如此，而对许多其他语言来说则未必——这在一定程度上解释了，为什么不同编程语言的爱好者，对 LLM 辅助下的未来会有如此不同的乐观或悲观看法。
当我生成代码时，那种乐趣的大部分便处于危险之中。所以，也许——就别生成吧。我想要继续亲手编写 Haskell 程序中（至少是有趣的那些部分），而不是不得不去阅读和 review（太多）生成的代码。同时，我也想把那些 token 用在一些正经地方，而不是慢慢烧光我的脑子。
我想向你展示一种方法：既能继续享受编程，又能借助 LLM 适度地提高生产力——而不是表面上看起来高效得多，却失去了全部乐趣。
如果你想完全戒断 LLM，那也很好，而且你心里有数该怎么做。但你也许有不那么做的理由，比如：你确实需要为团队带来一些真实的生产力提升，或者你不想被你的团队、你的公司、你的行业甩在身后——他们正在大步迈向深度 LLM 采用。
Keep writing code（持续自己写代码）
如果你想继续保有自己的代码库，你就要持续自己写一些代码。如果你把所有代码都交给模型生成，整个项目就会变成一片只有 AI 编程智能体才能在其中生存的「大模型荒原」。所以你应当坚持自己写代码，否则你的代码库终将彻底失守。
坚持写代码的另一个原因，是让自己保持一名合格的程序员。技能一旦停止练习就会荒废，而在当下这个时代尤其危险，因为放弃亲手编码、把一切都丢给智能体的门槛实在太低了。仅仅几周不亲自编码、把所有事情都交给智能体之后，你就会发现，自己已经很难再回到那种能够亲自动手写代码的状态了。
大模型生成「优质、可读」的代码的能力，远不像宣传中那么强。它们生成自己后续「独占」使用的代码还凑合。但我相信你一定经历过那种绝望：面对一个完全由 AI 生成的文件，你直觉地知道某个地方一定有 bug，却因为整片代码看起来都过于陌生，而觉得自己作为人类根本无从下手。
那么，如果不把编码本身全盘交给智能体，又该如何获得那种生产力的提升呢？答案是：让它们去做几乎所有其它的事情。尤其是那些让你觉得烦的枯燥工作。理想情况下，是那些并不太难做对、同时又很容易验证结果的任务。
Planning（规划）
自从计算机诞生以来，它就一直被当作簿记工具来使用。现在，你可以用同样的方式来用大模型。它本质上就是一个你可以用自然语言、而不是形式化界面来操作的簿记工具。把领域专家之间一大段冗长的讨论，转换成可以执行的待办事项；测试某个东西，把测试结果写下来，让模型把它整理成一份修复缺陷的方案。
你可以使用像 todo 工具这样的东西，更好的做法是使用带有 frontmatter（元数据头）的 Markdown 文件，以便让模型能够正确地追踪规划项。大模型的上下文窗口虽然可以很大，但如果塞得太满，它仍然会在不知不觉中丢失信息。
但千万不要让它做出任何关键决策。让它向你提问。 如果你看不懂它的问题，那是模型的错——它没有把相关的上下文提供给你（或者只是你自己太累了，需要休息一下）。如果你反复回到同样的问题上，那就先从屏幕前退一步，自己好好想一想，等你对想要什么有了清晰的画面之后再回来继续。
Researching（调研）
当你把一项调研任务交给智能体时，很容易出现这三种诱惑：盯着它看它一遍遍地查询和「思考」；顺手在另一个项目里再起一个智能体；或者去冲一杯咖啡。在这三种选择里，冲咖啡是相对最好的一种。更胜一筹的选择是：你自己用一款老牌、好用的搜索引擎并行地去调研。至少要对智能体即将知道的内容有一个大致的掌握。
不要只是让模型去调研某件事，然后就把它给出的结果当作事实，再据此做规划。那样做只会给你留下一屁股尴尬的技术债。
让智能体去做调研的目的，并不是让它把所有相关知识都端到你面前，也不是让它做出比你更高明的决定。真正的意义在于：免得你不得不自己去「帮你 Google 一下」（Let Me Google That For You）。 你对自己正在建模的那个领域的理解，应当不亚于智能体——理想情况下，甚至要超过它。
让智能体把它们的调研结果写下来，并附上它们所用到的资料链接。等到它之后带着一个奇怪的提案回到你面前时，你就问它：你的调研结果是怎么说的？哪份资料是这么说的？有 50% 的概率，它自己就会发现自己的错误。在另外那 50% 的情况下，你就亲自去读一下那份调研资料——此时，你就已经处在一个能够自己做出正确决策的位置上了。
你才是程序员
这才是真正的游戏规则改变者。
常见的编程脚手架总会引诱你“先做规划，再让智能体去写代码”。请拒绝这种做法。共同规划，但由你来写代码。 让大语言模型去研究你的代码库，让它告诉你当前的任务清单，列出所有需要修改的位置，指出潜在的陷阱，提醒你相关的背景资料。
我就是这样工作的，而且乐趣十足。 我享受自己的工作，有时甚至比大语言模型出现之前更甚。我始终有一份清晰的任务清单，无需操心整体计划，能够保持专注，由于规划得当，我也能很快地完成任务。这就像敏捷开发，却少了那些烦人的流程。
让智能体围绕你的工作方式聚集，而不是反过来。 也许你是一位经验丰富的程序员，已经知道自己最擅长怎样的工作方式。那么就把那些你不太喜欢的零碎工作交给智能体吧。
这种工作流有许多优点：
- 你继续做自己喜欢的事。 如果你喜欢编程，那就去写代码。
- 你始终清楚代码库所处的状态。 是否曾对自己“氛围编程”产生的奇怪代码感到惊讶？是否不得不重写大语言模型生成的劣质代码？是否在一次会话中迷失了位置？采用这种做法，这些问题再也不会出现。
- 你能尽早发现糟糕的方案。 智能体程序员可能会一条道走到黑，执着于某个想法，而你很快就能判断出这是不是一个馊主意。
- 你持续打磨自己的技艺。 这是不言自明的——你会一直是一名优秀的程序员，甚至不断精进。
智能体程序员偶尔有用武之地
理想情况下，可用于清理工作、小型任务、日常事务、低风险的重构。代码里留了 FIXME（也许是刻意为之，为了节省时间和精力）？写完了 3 个有趣的用例，剩下 7 个相似的乏味用例没写？心里盘算着一次模块重组，希望它跑跑基准？想用一个更好的库替换掉无人维护的旧库？这些都是合理的用例。而从零开始设计一套复杂的系统，很可能并不适合。
有时你会忙得焦头烂额，却仍希望把手头的事情做完，而计划中剩下的任务又恰好都是明显的低风险工作。那么对主管智能体说一句“我先离开一会儿，把这个收尾吧”，运气好的话，第二天早上回来就能看到一个完整的功能。不过，关键在于大部分编码工作仍要亲力亲为。
这里也有一些细微的陷阱：
-
假设你写完了那 3 个有趣的用例，然后让智能体把剩下 7 个也一并补完，因为它们显然只是你已写用例的简单变体。多半你应该考虑抽象出公共逻辑。 也许你真正在做的事情是套用一个镜头或其他光学概念？也许这正是某个流行类型类（例如
Traversable）的一个实例？众所周知，大语言模型很难识别出这一点，反而会复制大段代码。而作为人类，你应当追求更易读、更合理的代码。 -
“让它指出潜在陷阱”这一点也是如此。没错，大语言模型确实擅长遍历整条调用链，确保交给你的任务清单里列出了所有需要改动的地方。但是，与其依赖它来发现这些耦合关系，你更应该考虑是不是项目组织得不够好，才让你不得不一开始就借助大语言模型来做代码调研。