我如何用 LLM 写软件：一套实用的多模型工作流 - Toolsify AI Blog

2026年3月10日，Stavros 发表了一篇可能是关于用大语言模型构建软件最诚实、最实用的指南。不是炒作文章。不是"看 AI 在10分钟内做出了什么"的演示。而是一套经过多个已交付项目验证的真实工作流，并清晰地指出了它的适用场景和失败模式。

这篇文章之所以重要，是因为大多数关于 AI 辅助开发的写作都落入两个阵营：狂热的拥护者或不屑的怀疑者。Stavros 落在了更有用的位置——他大量使用 LLM，乐在其中，同时精确地描述了失败模式。

起点：做东西，而不是写代码

Stavros 用一个区分重新定义了整个对话。他不把编程本身当作目的。他在乎的是做出东西来。LLM 改变了这个等式，让编程感觉更接近直接构建——花更少的时间与语法搏斗，花更多时间塑造软件的实际功能。

这很重要，因为它改变了价值主张。如果你的目标是编码手艺，LLM 可能感觉像作弊。如果你的目标是交付可用的软件，LLM 就是力量倍增器。Stavros 明确站在第二阵营，他的工作流反映了这个优先级。

他用这种方法构建和维护了多个项目：一个叫 Stavrobot 的个人助手、一个语音笔记录制设备、一个艺术时钟项目，以及一个叫 Pine Town 的小镇模拟。这些不是玩具演示。它们是有真实用户和真实需求的、在持续演进的代码库。

Stavros 工作流的核心是将关注点分离到三个模型角色中。每个角色使用不同的模型，根据具体任务选择。这不是要找到"最好的"模型，而是将模型优势与工作流阶段匹配。

第一个模型扮演架构师角色。Stavros 在写任何代码之前，会花最多30分钟与这个模型对话。讨论覆盖目标、权衡、边界情况和架构决策。关键指令是：在我明确批准之前不要开始实现。

这个约束至关重要。LLM 渴望生成代码。没有硬性门槛，规划对话会在设计确定之前就滑入实现阶段。通过执行"批准前不写代码"规则，Stavros 把思考和打字分开了。

规划模型需要在推理和权衡分析方面足够强。这是你最应该使用最强模型的环节。薄弱的规划阶段会产生下游问题，无论实现多强都无法弥补。

规划批准后，一个更便宜的模型负责实现。这个模型的自由度有限——它执行计划，而不是重新设计。指令是具体的：遵循架构，实现描述的变更，不经过允许不引入新模式。

使用更便宜的模型有两个目的。第一，对实现所需的高量级 token 生成来说更划算。第二，约束实现模型降低了偏离既定架构的风险。

Stavros 明确提到了自由度的限制。自由度过大的实现模型会以破坏整体设计一致性的方式"改进"你的架构。计划是合同。实现者的工作是履行合同，而不是重新谈判。

实现完成后，Stavros 让代码通过多个审查模型。他明确提到了使用 Codex、Gemini 和 Opus 进行审查。多样性很重要——不同的模型捕捉不同的问题。

一个模型可能标记性能问题。另一个可能捕捉错误处理中的边界情况。第三个可能发现命名或 API 设计中的不一致。使用单一审查者给你一个视角。使用多个审查者创造重叠覆盖。

这与人类代码审查的原则一致：单一审查者，无论多强，都有盲点。模型也一样。多元化审查者是低成本的保险，防止遗漏任何单个模型可能忽视的问题。

一个将 Stavros 方法与"让 AI 做一切"阵营区分开来的细节：他手写 agent 指令。他不让 LLM 生成自己的技能文件或配置。人类定义约束。模型在约束内执行。

这个选择有清晰的理由。当你让 LLM 写自己的指令时，它优化的是它认为你想听的东西，而不是真正有效的东西。生成的指令往往冗长、通用，且与实际用例微妙地错位。手写的指令更短、更具体、更诚实地说明了模型该做什么和不该做什么。

当 Stavros 已经理解他正在使用的技术栈时，多模型工作流效果最好。当他了解框架、模式和预期行为时，他可以对照清晰的心智模型评估模型的输出。他能发现实现何时偏离了计划。他能判断审查者的建议是否真的是改进。

在这种情况下，LLM 充当生产力倍增器。人类提供判断力和架构愿景。模型提供速度和机械实现。分工有效是因为各方贡献了各自最擅长的部分。

Stavros 坦率地指出了局限性：在不熟悉的领域，工作流效果差得多。当你不深入理解技术时，你无法有效评估模型的输出。错误决策会累积。代码库堆积出人类直到为时已晚才认识到的技术债务。

这才是真正的运营风险，而不是人们通常担心的个别 bug 或幻觉。一个错误的输出容易修复。一系列微妙的错误架构决策——因为人类无法评估而被接受——创造了一个修复成本高昂的代码库。

设计错误累积的问题比听起来更严重。早期决策设定的模式会被后续代码遵循。如果初始架构因为人类在没有足够理解的情况下接受了模型的建议而薄弱，每一次后续的添加都会强化这些弱点。等到问题变得可见时，纠正的成本可能已经超过当初使用 LLM 节省的时间。

Stavros 的工作流指向了软件开发中一个更广泛的转变。人类角色正从代码行级编码转向架构级监督。日常工作从写函数转向定义约束、评估权衡、维护整体设计的一致性。

这不意味着人类变得不那么重要。它意味着人类的判断力更重要了，而不是更不重要了。写函数是一个有明确成功标准的有界任务。为项目定义正确的架构需要理解需求、预见未来需求、做出模型无法完全评估的权衡。

在这个环境中脱颖而出的开发者不是编码最快的。而是能定义清晰约束、尽早识别薄弱抽象、并执行有纪律的多模型流程而不让任何单个模型主导设计的人。

分离规划与实现。设计确定之前不要让模型开始编码。规划对话中花的30分钟能节省数小时的返工。

为不同角色使用不同模型。最强的推理模型不一定是最好的实现者。将模型优势匹配到工作流阶段。

多元化审查者。多个模型捕捉不同的问题。单一审查者，无论是人类还是 AI，都有盲点。

自己写指令。不要让模型定义自己的约束。人类制定规则，模型遵守规则。

保持在熟悉领域。用 LLM 放大你已有的技能。在不熟悉的领域，先投入学习再投入自动化。

警惕错误累积。如果早期决策感觉不对，在继续构建之前调查清楚。来自被误解的架构的技术债务是最昂贵的。