同一个项目同一个需求两个 AI 编程工具产出差距有多大背景最近在做一个资源库语义检索系统Shield Mind Index的从 0 开始的项目。从需求文档到技术方案设计全程用 AI 编程工具辅助完成。正好用了两个工具 ——Trae模型Doubao-Seed-Code和Claude Code模型Opus 4.6在同一个项目上做了对比结果差异令人深思。任务说明项目需求简单概括构建一个 SaaS 模式的智能资源库系统支持多租户、语义检索、自动标识入库等功能。需要完成的工作产品需求文档描述系统功能、流程、架构、数据模型流程图设计将文档中的 Mermaid 流程图转为独立的 SVG 文件技术方案设计从专业技术角度审查需求文档完成完整的技术设计Round 1需求文档 —— Trae 先上给 Trae 一段项目描述让它写产品需求文档。这部分 Trae 完成得不错生成了一份包含功能模块、核心流程、系统架构、数据结构的完整 PRD 文档docs/产品需求文档.md。文档中包含了多个 Mermaid 格式的流程图定义包括语义检索流程用户注册登录流程自动标识入库流程资源管理时序图资源检索时序图系统架构图界面流程图评价这一轮 Trae 表现合格。需求文档结构完整信息密度合理。Round 2流程图 SVG 化 —— Trae 翻车接下来让 Trae 把文档中的流程图从 Mermaid 语法转为独立的 SVG 文件。第一次尝试生成 .mmd .htmlTrae 并没有直接生成 SVG而是生成了.mmd文件和引用 mermaid.js 的.html文件docs/images/trae/ ├── system_architecture.mmd # Mermaid 源文件 ├── system_architecture.html # 需要浏览器渲染的 HTML ├── semantic_search_flow.html ├── resource_search_flow.html ├── resource_management_flow.html ├── auto_tagging_flow.html └── all_diagrams.html.mmd文件只是原始 Mermaid 语法的复制.html需要浏览器 CDN 加载 mermaid.js 才能渲染。这不是 SVG不能直接在 Markdown 中引用。多次沟通仍无法完成反复沟通Trae 始终无法直接生成 SVG 格式的流程图。它似乎不具备将流程图画成原生 SVG 的能力只会依赖第三方渲染引擎。给出参考方案后才完成最终我把之前用 Claude Code 生成 SVG 的方法一个 Vue 文件的参考示例给 Trae它才终于生成了 SVG 文件。但是结果…Trae 生成的 SVG能看但仅此而已以系统架构图为例Trae 的产出问题一览问题说明视觉单调所有节点使用同一种颜色和样式无法区分不同层级信息缺失架构图缺少 Gateway 层、消息队列、Vault 密钥管理等关键组件布局简陋简单的从上到下排列没有分层概念无细节标注节点只有名称没有技术栈说明和职责描述专业度不够更像是 Mermaid 的简单翻译不像架构设计图再看语义检索流程图同样的问题节点排列单一、缺少缓存判断的菱形节点、没有技术细节标注、没有分支路径的区分。Round 3Claude Code 登场因为是 Trae 设计的需求文档所以我给 Claude Code 的指令是“请结合产品需求文档完成技术方案的设计其中包含相关的流程图采用 SVG注意不能完全依靠产品说明文档来需要从专业技术角度来对文档进行审查并完成设计方案”注意关键词“不能完全依靠”、“专业技术角度”、“审查”。产出 1先审查再设计Claude Code 的第一件事不是画图而是审查需求文档。它生成了一份详细的技术审查报告指出了 PRD 中的多个问题问题类别示例架构缺陷缺少 API Gateway 层、缺少多租户模型、缺少消息队列、缺少对象存储数据模型问题API Key 明文存储、模型 API Key 明文、缺少状态机、分类路径低效安全问题无速率限制、无 CORS 策略、无输入校验、JWT 无吊销机制务实的判断明确标注了MVP 阶段可接受的简化计费、SSO、SDK 发布、弹性扩展这份审查本身就很有价值 ——它不是在机械执行任务而是在用技术视角思考。产出 2架构图 —— 天壤之别Claude Code 生成的系统架构图对比一目了然维度TraeClaude Code分层设计无分层节点平铺Client / Gateway / Service / Data / Infra 五层清晰分色组件完整度6 个基础模块包含 Auth、User、Resource、Category、Search、API Key、Model Config、Embedding、Auto-Tagging、Worker、Tenant、Audit Log 等完整服务技术标注无每个组件都有技术栈和职责说明如 “Token Bucket Redis”视觉设计单色方块多色分层、阴影效果、圆角、渐变外部服务未体现独立标注 OpenAI API、Vision Model、SMTP、OAuth Provider基础设施未体现Docker Compose、GitHub Actions、Prometheus、Grafana、Jaeger产出 3流程图 —— 信息密度的差异语义检索流程对比Trae 版本Claude Code 版本Claude Code 的流程图包含了缓存命中/未命中的菱形判断节点每一步都有编号和技术细节如 “Model Router: Built-in BERT / External API”旁注说明如混合检索权重 “Vector score * 0.7 BM25 text score * 0.3”分支路径颜色区分缓存命中用绿色未命中用红色后处理阶段的具体操作权限检查、分数阈值、分页产出 4更多专业流程图Claude Code 还额外生成了 Trae 未涉及的图认证授权时序图这张图用时序图的形式清晰展示了 Client - Gateway - Auth Service - PostgreSQL - Redis 的完整交互包含注册、登录、API 请求三个场景。资源入库流程图ER 关系图部署拓扑图关键差异总结能力维度对比维度Trae (Doubao-Seed-Code)Claude Code (Opus 4.6)需求文档合格结构完整未单独测试基于 Trae 的文档工作SVG 生成能力需要给参考才能完成直接生成无需引导技术审查未体现主动审查 PRD发现 15 个技术问题架构理解照搬文档描述基于技术判断补充和修正图表质量信息简单、视觉单调信息丰富、分层清晰、视觉专业主动性被动执行指令主动发现问题、提出修正方案技术深度表面级别涉及具体算法、参数、安全策略核心差距在哪1. 不是 “会不会画图” 的问题是 “理不理解” 的问题Trae 的架构图缺少 Gateway 层不是因为不会画多一个方块而是它不理解 SaaS 产品为什么需要网关层。Claude Code 不仅画出了 Gateway还标注了它的职责SSL Termination、负载均衡、Rate Limiting、Auth Middleware。2. 不是 “完成任务” 的问题是 “思考任务” 的问题让 Claude Code 做技术方案它的第一反应是审查需求文档的合理性。API Key 明文存储不行改成 SHA-256 哈希。没有消息队列异步任务会超时加 Redis Stream。这种工程直觉是最大的差距。3. 不是 “好看不好看” 的问题是 “有没有用” 的问题Trae 的图拿去给开发看开发还需要问一堆问题。Claude Code 的图拿去给开发看直接能开工 —— 技术栈标了交互协议标了连混合检索的权重都写上了。这是差距还是姿势不对老实说两者都有。确实是差距模型能力差距Opus 4.6 在代码理解、系统设计、技术判断上明显强于 Doubao-Seed-Code工具链差距Claude Code 对 SVG 的原生生成能力更强不依赖第三方渲染推理深度差距Claude Code 能做技术审查、发现架构缺陷这需要深层推理能力也可能是姿势问题Prompt 差异给 Claude Code 的指令明确要求了从专业技术角度审查这种引导很关键工具特性Claude Code 是终端工具天然适合代码和文件操作Trae 作为 IDE 插件在代码补全等场景可能有不同优势使用场景如果只是写业务代码、做简单的 CRUD差距可能没这么大一个残酷的现实在 AI 编程这个领域模型能力就是产品天花板。工具做得再好底层模型理解不了系统架构它就画不出好的架构图。给再多参考如果模型不理解为什么 SaaS 产品需要租户隔离它就不会主动在架构中加入这个概念。这不是用得对不对的问题 —— 是模型看到同一份需求文档时脑子里浮现的东西不一样。写在最后这次对比不是为了踩谁捧谁。Trae 在它的场景下有它的价值Doubao-Seed-Code 也在快速进步。但至少在系统设计、技术方案、流程图生成这类需要深层技术理解的任务上Claude Code Opus 4.6 展现出了明显的优势。选工具先想清楚你要它做什么。如果只是补全代码、生成样板用什么都差不多。但如果需要它像一个资深工程师一样思考—— 目前来看选择确实重要。