用 Claude Code + Sub-agents 的全栈实测：国产四模的“流程力”胜负手

背景与方法

在真实全栈任务中评估 AI 编程模型，才能看清“能否交付”。本次以 Astro + TypeScript + Tailwind + WordPress Headless（REST）为技术栈，目标交付公司站与独立 Blog（列表、详情、搜索、分页、SEO）。统一提示词、统一约束（严格 TS、pnpm、响应式与性能指标），并通过 Claude Code 的 sub‑agents 自动协同，完整跑通前后端链路，记录时延、修复成本与账单数据。

工作流与子代理设置

采用五个子代理：项目协调、UI/UX、前端、WordPress 集成、博客开发。项目协调负责里程碑、质量门与跨代理交接；UI/UX 给出设计系统与组件规范；前端落地页面骨架与交互；WP 集成负责 API、分类/搜索、缓存与错误处理；博客开发完成动态路由、渲染与 SEO。危险模式自动执行，过程以“错误复述 + 期望行为 + 最小复现 + 日志片段”形成闭环，避免长链路失控。

实测结果：速度/完成度/成本

• 完成度与稳定性：GLM‑4.5 最稳，流程遵循好，端到端闭环顺畅；DeepSeek V3.1 稳健，偶发 CSS/路由瑕疵，修复后可用；Kimi K2 交互与审美好，但构建与修复耗时高；Qwen3‑coder 易偏离流程（包管理、代理调用），需强约束。

• 速度：Qwen ≈ 16–20 分钟出样；GLM ≈ 1.5 小时可交付；DeepSeek ≈ 3 小时；Kimi ≈ 6 小时。快不等于省心，返工会吞噬名义速度优势。

• 审美与一致性：Kimi > GLM > DeepSeek > Qwen。组件一致性与响应式细节，影响首屏观感与转化。

• 成本与返工：账单综合与返工成本加总后，GLM 最优，DeepSeek 次之；Kimi 与 Qwen 取决于你能否容纳“慢/快带来的返工”。

一句话总结：GLM 把活干全；Kimi 把活干美；Qwen 把活干快；DeepSeek 把活干稳。

常见坑点与对策

• WordPress 并非“装好即用”。若首轮安装与固定链接（/%postname%/）未就绪，前端 Blog 将呈现“无内容”。
  对策：把安装状态、固定链接、CORS、REST 路由通断、示例文章，列为预检清单。

• 接口联调易散点化。
  对策：统一“联调脚本”：复述错误 → 明确期望 → 最小复现 → 提供日志 → 回归验证；将数据访问层抽象为单点，统一加载/错误态。

• 包管理与指令偏航。
  对策：在提示词与 package.json 脚本中双重固化 pnpm；将 CI 预检集成到代理任务首步。

工程启示

• 先组织，后生成。流程拆解与角色分工，决定代码质量与节奏稳定性。
• 泳道化交付：信息架构 → 设计系统 → 页面骨架 → 数据接入 → SEO/性能，配套质量门逐段验收。
• 以日志为锚。让代理围绕日志与复现路径迭代，减少“上下文走丢”。
• 把“修复话术”标准化，代理即可批量化处理常见故障。
  本质上，开发者正从“编码者”转向“AI 工作流架构师”，边界在工作流，而非模型单点能力。

选型建议与结论

• 综合交付/省心优先：GLM‑4.5。
• 视觉呈现优先：Kimi K2（预留构建与修复时间）。
• 极限速度优先：Qwen3‑coder（必须强化流程与依赖约束）。
• 稳健与可调优：DeepSeek V3.1。

结论：单点“写代码”已非胜负手，流程设计与协作编排才是上限。当流程清晰、质量门明确，模型只是“换刀”，不是“换厨师”。