我一直看到一些帖子，讲述某人如何构建出复杂的工作流，以让人工智能编写生产代码，而这个工作流获得的认可远远超过它应得的。真正做工作的两样东西是模型正在写入的堆栈和开发者在其职业生涯中积累的经验：品味、模式识别和对代码走向的感觉。所有那些在这两者之上的东西都是装饰。我从试图遵循这些工作流的人那里听到的通常听起来就是这样：在这个上花了一个小时，Claude仍然无法做到。这是我给了它整个文件，列出了每个边缘案例，告诉它确切需要触及哪个函数，指定了命名约定。它还是搞砸了。在这种情况下，提示本身就是问题，因为每个约束的添加都限制了模型可以做的事情，而当你堆叠了五六个约束时，视野变小到模型必须在你一路上打包的假设中穿针引线。任何时候这些假设中的一个是错误的，而通常至少有一个是错误的，输出看起来像是失败，尽管模型正在做你所要求的事情。我的方法通常是两个回合。第一个回合指向我已经本地拥有的上下文，第二个回合说明要构建的内容：这两者都有效，因为单独的准备步骤打勾了过度提示者试图一次击中的许多框。模型在阅读参考时，已经符合了约定、命名模式、函数的结构以及错误处理等所有人们通常试图一个个详细说明的内容。一旦你接受模型可以编写代码，就剩下如何与之合作的选择。这是大多数开发者自食其果的地方。让模型运行感觉像是放弃控制，而发明一个工作流则似乎是负责任的举动，即使这通常在更多的时间内产生更糟的工作。感觉失去控制的原因比代码本身要深刻得多。开发者花了二十年将自身的价值感与他们所产出的内容联系在一起，无论是聪明的解决方案、其他人看不到的抽象，还是终于奏效的深夜修复，而这一切都是行业对你的衡量标准，以及你对自己的衡量标准。当一个模型能够为你产生工件，往往是一个更好的模型时，创造一个新的工作层，使其尚未能够处理的方式可以让你继续处于中心，但这一层不断缩小，无法放手的人最终将更多的时间花在仪式上，以便他们仍然感到重要。开发者剩下的是工作的更艰巨部分，即选择堆栈，具备品味，捕捉输出开始偏离的时刻，围绕这一切构建的复杂过程大多是忙碌的工作，让你在避免更艰难、模糊的事情时感到有生产力。让人工智能来做饭。