AI 改变软件工具：vibe coding 让程序无需多余中间层

人们反对通过 vibe coding 生成程序，主要理由听起来往往相当专业：这个方案能应付某一项具体任务，但换到别的项目、别的数据、负载加大之后还能不能跑，就不好说了。这个疑问背后，是大家熟悉的软件观念——软件是一项长期资产，必须维护、发展，条件允许时还要复用。不过，在讨论这种方案的可移植性之前，先该弄清楚：它到底有没有第二次使用的打算，为复用所做的准备成本又是否值得。

如果一个人只需要调整图像颜色、把它裁到合适的比例、再存成某种格式，那么完成这些动作的程序就可以算是成品了。它不必成为图像编辑器，不必支持几十种场景，也不必变成未来某项服务的基础。只有当真需要这些能力时，缺少它们才算缺陷。否则，对通用性的要求，就等于拿另一套生产情境下的条件来苛求一个本地工具。

Vibe coding——通过向生成模型写提示词来创建程序——让这种区分变得格外明显。它的意义不止于加快写代码的速度：制作小工具的成本降低后，人们可以重新考虑工作的边界、技术流程的安排，以及一项任务凭什么从一个专业人员手里交到另一个专业人员手里。

在传统开发中，对复用的追求有明确的经济基础。如果创建一个程序需要大量投入，人们自然希望把这份投入分摊到多个任务、项目或客户上。于是才有对架构、可扩展性、库和通用接口的重视。今天多花的钱，靠的是预期明天能少花。

但这套逻辑取决于成本的比例关系，而不是通用方案有什么无条件的优越性。当做一个窄用途工具的成本足够低时，为假想的未来做准备，可能比未来本身还贵。与其事先造一套能处理任何图像的系统，有时更合理的做法是造一个处理特定一组照片的工具，需求变了再换一个。

这并不意味着开发成本真的降到了零。剩下的还有：界定任务的时间、算力开销、结果验证、可能的错误，以及错误使用带来的后果。真正变化的是成本结构：在某些情况下，写代码不再是大头，不再值得为了省这一项而把其他一切都搞复杂。

因此，一个程序寿命很短，可能不是草率的标志，而是有意的设计决定。为单一操作打造的工具，没有义务具备那种由多个团队维护多年的系统才有的属性。它的质量首先取决于：它能否可靠地完成它被设计来做的工作，以及它的作用范围是否被安全地限定住。

同样重要的是，负载增加与用途改变是两回事。把更多同质化的照片处理好，和从处理照片转向设计一套复杂的发布流程，是不同的任务。在后一种情况下，不惜代价保留原有方案可能毫无经济意义。正如工程中改变工作范围可能需要不同的设计，编程中新的情境也不总是旧方案的天然延续。

关于小工具的讨论，很容易被简化成“所有工作都必须拆成最小的操作”。但真正重要的不是动作的大小，而是能否单独接受它的结果。

裁剪图像可以是一项独立任务，前提是所需比例已知，并且清楚画面里必须保留什么。但同一个操作，在图像需要与标题、文字位置和页面构图相协调时，就变成了更复杂方案的一部分。这种情况下，一个格式上正确的文件，并不等于工作已经完成。

因此，更有用的做法是从事务的完整性和可验证性来定义原子性。一项任务有初始条件、预期结果，以及一个能判断结果是否达成的标准。有时这些条件对应单个技术操作，有时对应由共同目标联合起来的若干动作。

例如，“为版面中这个位置准备一张图”这条指令，可能包含调整尺寸、裁剪、扩展背景和导出。用户不必事先逐一选择每个操作，只要工具能提出合适的方法并遵守约束即可。被订购的不再是一串预定命令的执行，而是结果对特定用途的适用性。

这里出现了一个重要的区分：生产可以拆成小动作，但构思本身不必拆。执行的局部性，并不要求一个人把自己的工作看成一堆互不相干的碎片。

通用程序提供的不只是功能，它还影响围绕它形成的活动组织方式。掌握一套复杂环境需要时间；它的各项能力会变成专业分工的领域；工作在不同专业人员之间的交接，会形成规则、格式和审批流程。

在工作室的流程里，这看起来可能完全自然。排版人员需要一张图形底图，就给设计师写一份需求；设计师做出几个方案，选中的图像再回到排版环节。必要时其他专业人员加入这条链，技术基础设施则保证文件传输和行动一致。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）