开发者实测：Opus与国产模型在Agent架构及编码中的效能对比

背景

在五一假期期间，作者深入参与了为期五天的代码开发工作，并基于实际项目经验，对当前主流的大语言模型（LLM）在软件开发工作流中的表现进行了系统性评估。此次实践的核心在于探索如何将不同模型的优势整合进一个标准化的 Agent 工作流中，以解决单一模型在处理复杂架构设计与具体代码实现时能力不均的问题。

核心内容

作者分享了一套基于 CodeStable 框架的 AI 辅助开发工作流。该工作流的核心逻辑是将软件开发过程拆解为三个独立阶段：做计划（架构设计） -> 写代码 -> 验收。这种分离式架构允许将不同阶段的任务分配给最适合的 AI 模型，从而发挥各模型在特定任务上的特长。

在具体模型选型与表现评估方面，作者测试了包括 Opus-4-7、dpsk-v4-pro、mimo-v2.5-pro、glm-5.1 在内的多个模型，并得出以下结论：

1. 架构设计阶段：

   • Opus-4-7 表现最佳。其架构设计稳健、考虑周全，且避免了过度抽象，能够很好地把握需求细节。
   • dpsk-v4-pro 和 mimo-v2.5-pro 紧随其后，虽然整体可用，但在细节处理上偶尔会出现疏漏。
   • 相比之下，glm-5.1 在架构设计方面表现逊色，常出现偷懒或过度抽象的情况。

2. 代码实现阶段：

   • Opus-4-7 在此阶段的表现令人失望，作者评价其“有点弱智”，远不如之前的版本，直接让其编写代码效果不佳。
   • dpsk-v4-pro 和 mimo-v2.5-pro 同样不适合直接用于编写代码。它们的指令遵从度较低，需要多次在 Prompt 中进行提示引导，且解决简单问题的能力不如 glm-5.1。
   • glm-5.1 虽然上下文窗口或原生能力可能不及顶级模型，但在执行具体代码编写任务时表现稳定，能够“一遍过”。

3. 最佳实践组合：

   • 作者发现，最高效的工作流是“分工协作”：由 Opus-4-7 负责前期架构设计，生成清晰的蓝图；随后由 glm-5.1 依据该架构进行具体的代码编写。这种组合效果极佳。
   • 对于复杂需求，必须强制要求架构师模型（如 Opus）将需求拆解为多个小模块，再交由代码模型执行，否则极易导致失败。

关键要点

• 工作流解耦：采用 CodeStable 的“计划-编码-验收”分离流程，允许不同模型各司其职，是提升开发效率的关键。
• 模型能力分化：
  • Opus-4-7：架构设计王者，但代码生成能力衰退，不适合作为单一的全能编码助手。
  • glm-5.1：代码执行能力强，指令遵从度高，适合根据既定架构落地代码，但在架构设计上能力不足。
  • dpsk-v4-pro / mimo-v2.5-pro：介于两者之间，架构设计尚可但有瑕疵，代码生成能力弱且指令遵从度低，需谨慎使用。
• 提示工程策略：对于 dpsk 和 mimo 等指令遵从度较低的模型，必须在 Prompt 中反复强调指令；对于复杂任务，必须通过 Prompt 强制要求拆解需求。
• 推荐组合：Opus-4-7（架构师） + glm-5.1（执行者）是目前作者验证出的最优搭配。

意义与影响

这一实践揭示了当前 AI 编程助手发展的一个重要趋势：单一模型难以同时胜任高阶抽象思维与低阶具体执行。

1. 从“全能模型”到“专家集群”：开发者不再依赖单一模型完成所有任务，而是需要根据任务类型（架构 vs. 编码）选择专用模型，并通过工作流将它们串联起来。
2. 架构与代码的解耦价值：证明了“先设计后实现”的软件工程原则在 AI 辅助开发中依然有效，且能显著降低 AI 产生幻觉或逻辑错误的概率。
3. 对国产模型的启示：glm-5.1 在代码执行层面的优异表现，表明其在特定垂直领域（如遵循既定规范的编码）具有极高的实用价值，可作为顶级模型架构设计的有力补充，形成互补生态。
4. 工作流工程的重要性：提示词（Prompt）和流程设计（Workflow）的重要性超越了模型本身。即使模型存在缺陷（如 Opus 的代码能力下降），通过合理的工作流设计（让其只做架构）也能最大化其价值。