开发者用前沿模型做架构师、小模型写代码，成本显著下降

曾几何时，你可以直接用最强大的前沿模型猛写代码，成本还算合理。那样的日子已经过去了。显而易见的替代方案都有取舍。换用更便宜的模型或在本地运行，意味着要接受质量上的损失，而你可能并不想在所有环节都承受这种损失。所以真正的问题是：如何在关键之处继续使用最好的模型，又不必在所有地方都为它付费？

架构师与工程师 我目前的配置把工作一分为二。我用一个前沿模型担任“架构师”。它掌握全局，决定架构问题，并监督产出。一个更小、更便宜的模型担任“工程师”。工程师负责实际的实现工作。它写代码，但只是按照架构师的交接要求来写。

架构师一行代码都不写。它做设计、向我提问、审查工程师的产出，并合并结果。工程师则完全不必关心全局。大部分 token 消耗发生在更便宜的模型上。前沿模型也参与，但主要是在高层面上。成本显著下降。

还有一个附带好处：上下文腐化。当你深入实现细节时，agent 的上下文会迅速填满。文件内容、diff、错误信息、测试输出。这些都会累积起来，模型开始失去对全局的把握。架构师完全看不到这些。它的上下文保持干净：设计问题、决策、审查意见。你可以运行很长的架构师会话而不会退化。

实际怎么运作 在 Cursor 里，我为每个主题保持两个命名线程：“A: [主题]”给架构师，“E: [主题]”给工程师。我打开架构师线程，完成一个设计。结果是一个 Linear issue（Cursor 通过 MCP 创建），其中以评论形式附上一份自包含的实现计划。如果决策涉及重大的架构选择，还会在仓库里放一份 ADR。那条评论就是交接内容：工程师需要的一切，唯独没有我们的设计对话。

然后我切换到工程师线程，输入“Pickup FOR-134”。agent 直接读取该 issue 及其评论。它找到交接评论，开始实现。完成后我回到架构师：“Review”。架构师读取 diff 并发布发现的问题。然后回到工程师：“Address review comments”。重复直到干净，然后架构师合并。

这些简短命令之所以有效，是因为上下文已经在那里了。工程师知道自己在处理哪个 issue。架构师知道交接了什么。无需重新解释。

把工程师推得更远 一旦你把工程师框定为一个可互换的角色，下一个自然的问题就是：它必须在你的机器上运行吗？

云端 agent 可以直接承担工程师角色。在 Linear 里，你把 issue 分配给 Cursor。agent 接手，读取交接内容，在一个分支上工作，完成后打开 PR。架构师在 GitHub 上审查 PR。如果有问题，你通过 Linear 发回去：@Cursor 附上审查意见，同一个 agent 从上次中断的地方继续。

这是我接下来要去的方向。本地打开多个架构师线程，每个活跃主题一个。所有工程师在云端，接手 issue 并打开 PR。

你还可以更进一步，把架构师也自动化。但我不想，至少现在不想。架构师才是我仍然真正增加价值的地方：塑造要构建什么、提出正确的问题、在实现之前发现问题。保留这个角色，让我对一个基本自主运行的系统保有相当程度的控制。