Loading... # Claude Opus 4.5 高级工程师能力评估技术分析 # 一、新闻概述 ## 1. 标题 Claude is not a senior engineer (yet) / Claude（尚）不是高级工程师 ## 2. 发布时间 2026 年 1 月 12 日 ## 3. 来源 Approach with Alacrity 技术博客 # 二、核心内容 ## 1. 事件摘要 ### A. 主要内容 作者经过数周在真实代码库中使用 Claude Opus 4.5 后，对业界关于 AGI 即将到来的乐观观点提出不同看法。文章通过三个实际案例评估 Claude 的工程能力。 ### B. 核心亮点 - Claude 在使用良好抽象的积木块时表现出色 - Claude 在创建抽象和优雅解决方案方面存在局限 - 高级工程师的核心价值被进一步放大，而非被替代 ## 2. 关键信息 ### A. 涉及版本 Claude Opus 4.5 ### B. 测试时长 数周实际使用 ### C. 测试场景 - Sentry 调试循环（90 分钟自主运行） - Modal 到 AWS ECS 迁移（3 小时完成） - React 代码重构（提出不当方案） # 三、详细报道 ## 1. 正面案例 ### A. Sentry 调试循环自主运行 **场景描述**： 作者尝试将 Sentry 集成到系统中，但遇到配置问题。Sentry 未能为 FastAPI 的 StreamingResponse 端点自动创建事务追踪。 **解决方案**： 作者让 Claude 编写了一个完整的自动化调试循环： ```mermaid graph LR A[Playwright 测试脚本] -->|发送测试消息| B[前端网站] B -->|触发代码路径| C[后端系统] C -->|发送追踪数据| D[Sentry] D -->|MCP 连接查询| E[Claude] E -->|分析结果| F[调整配置] F -->|循环测试| C ```  **执行过程**： 1. Claude 编写 Playwright 脚本自动登录网站并发送聊天消息 2. 通过 MCP 连接 Sentry，查询特定代码路径的追踪数据 3. 根据 Sentry 文档持续尝试不同配置方案 4. 经过约 90 分钟自主运行，最终找到解决方案 **技术细节**： - 问题根源：Sentry 自动为 FastAPI 端点创建事务，但不支持 StreamingResponse - 解决方案：手动为 StreamingResponse 端点编写事务配置代码 - 核心价值：性能工程的核心循环（修改代码、测试、检查追踪日志、重复）完全自动化 ### B. Modal 到 AWS ECS 迁移 **场景背景**： 作者使用 Modal 容器云服务一年后触及平台限制，需要迁移到 AWS ECS。 **技术挑战**： - 作者有 Linux 服务器管理经验 - 从未接触过 Kubernetes 或 ECS - AWS 术语和配置复杂度一直阻碍学习 **Claude 执行任务**： 1. 使用 Terraform 创建 Dockerfile 2. 推送镜像到 AWS 容器注册表（ECR） 3. 通过 AWS CLI 配置正确的权限 4. 在 Terraform 中设置必要的 ECS 配置 ```mermaid graph TB A[源代码] -->|Docker 构建| B[容器镜像] B -->|推送| C[AWS ECR] D[Terraform 配置] -->|应用| E[AWS ECS] F[AWS CLI] -->|配置权限| C F -->|配置权限| E E -->|部署| C ```  **执行结果**： - 首次尝试即成功运行 - 耗时约 3 小时（夜间完成） - 若手动操作预计需要 1-2 天 **成功原因分析**： - Terraform 提供了优秀的云资源抽象 - AWS CLI 提供了标准化的接口 - 任务边界清晰，步骤明确 ## 2. 负面案例 ### A. React 代码重构失败 **问题场景**： 两个组件需要访问同一份数据，但持有不同的标识符： - 组件 A 持有 key - 组件 B 持有 id **数据结构**： ```javascript keyIdPairs: [(key, id)] // 元组列表 idToData: Map<id, data> // ID 到数据的映射 ``` **核心需求**： 组件 A 需要根据 key 查找对应的 data ### B. Claude 提出的方案 ```mermaid graph LR A[key] -->|线性扫描| B[keyIdPairs 列表] B -->|找到匹配| C[id] C -->|查找| D[idToData] D -->|返回| E[data] ```  **Claude 的代码**： ```javascript // 扫描列表找到匹配的 id id = keyIdPairs.find(pair => pair.key == key).id data = idToData.get(id) ``` ### C. 正确方案 **上下文理解**： key 和 id 来自同一上游数据源，因此最佳方案是在上游传递数据时同时提供 id。 ```mermaid graph TB A[上游数据源] -->|传递| B[组件 A] A -->|传递| C[组件 B] A -->|同时提供| D[key + id] D -->|快速查找| E[idToData] E -->|直接获取| F[data] ```  ### D. 失败原因分析 当作者将问题抽象为纯数据问题时，Claude 能给出正确答案。但在实际代码库的复杂环境中： 1. **上下文干扰**：混乱的 React 代码掩盖了核心数据问题 2. **缺乏抽象能力**：Claude 无法识别问题本质是数据流设计 3. **局部优化思维**：倾向于修补而非重构 # 四、影响分析 ## 1. 技术分析 ### A. Claude 的能力边界 | 能力维度 | 表现 | |---------|------| | 使用现有抽象 | 优秀 | | 创建新抽象 | 较弱 | | 处理清晰任务 | 出色 | | 处理模糊问题 | 困难 | | 执行迭代循环 | 强大 | | 识别根本原因 | 有限 | ### B. 高级工程师的核心价值 作者引用了一位杰出工程师 Sweeks 的故事： **Sweeks 的编码哲学**： - 每次进入代码库都会修剪杂乱的代码 - 长期反复重写每一行代码 - 将代码精简到完美抽象的精髓 **高级工程师的特征**： 1. **识别非显而易见的改进点** 2. **快速执行改进** 3. **推动成本高但回报倍增的变革** 4. **设计易于理解和维护的抽象** ### C. Grant Slatton 的观点 文章引用了 Grant Slatton 的见解：当前大语言模型在概念图中绘制抽象边界的能力较弱。 ```mermaid graph TB A[数据流] -->|LLM 倾向| B[任意抽象边界] A -->|人类倾向于| C[概念清晰边界] B -->|结果| D[碎片化抽象] C -->|结果| E[内聚抽象] ```  ## 2. 行业影响 ### A. 对 AGI 预期的修正 - Opus 4.5 确实是能力的跨越式提升 - 但距离替代高级工程师仍有显著差距 - AGI 时间表可能需要重新评估 ### B. 工程师价值重估 - **优秀抽象和基础设施的价值空前提升** - **高级工程师变得更加重要** - AI 是放大工具而非替代品 ### C. 开发模式变化 - 使用良好抽象的积木块时效率大幅提升 - 需要设计抽象时仍依赖人类专家 - vibe coding（直觉编程）并非万能 # 五、各方反应 ## 1. Twitter 讨论 ### A. Ryan Nystrom 的观点 > 我看着 Notion 的设计师们写出与高级工程师无法区分的代码。 ### B. Leila Clark 的总结 > 优秀的高级工程师设计易于 vibe coding 的抽象。 ## 2. 社区反馈 ### A. 支持观点 - Claude 在明确边界任务中表现卓越 - 自动化调试循环确实令人印象深刻 ### B. 批判观点 - React 案例显示了理解上下文的局限性 - 无法创建优雅抽象是根本性限制 # 六、技术洞察 ## 1. Claude 的定位 **作者的核心比喻**： > Claude 就像一个非常聪明的孩子，喜欢组装乐高积木。 - **好的基础设施和抽象** = 乐高积木 - **积木越大越好** = 能做的事情越多 - **Claude 无法自己生产积木** = 无法创造抽象 ## 2. 关键限制 ### A. 缺乏"灵魂" > Claude 没有灵魂。它不渴望任何东西。它当然不渴望创造美好的事物。 ### B. 缺乏内在驱动力 - 不追求优雅的解决方案 - 不会主动修剪代码花园 - 没有创造美的内在动机 ### C. 依赖性限制 > Claude 无法重现 Sentry、Terraform 和 Playwright。这些是极其复杂且精心设计的代码。 ## 3. 实用建议 ### A. 适用场景 - 拥有良好抽象的基础设施 - 任务边界清晰 - 可以分解为迭代循环 ### B. 不适用场景 - 需要设计新抽象 - 代码库混乱且缺乏结构 - 需要根本性重构 ### C. 使用策略 1. **先设计抽象**，再让 Claude 实现 2. **提供清晰的积木块**，而非原始问题 3. **保持代码花园整洁**，让 Claude 能理解 # 七、未来展望 ## 1. 短期趋势（1-2 年） - Claude 在使用现有工具方面持续改进 - 仍需依赖人类设计抽象 - 高级工程师角色更加重要 ## 2. 长期思考（5 年以上） - AGI 需要解决抽象创造问题 - 需要发展内在驱动力 - 需要理解美学和优雅 ## 3. 行业建议 - **投资基础设施**：良好的抽象是 AI 时代的核心资产 - **培养高级工程师**：他们是最稀缺的资源 - **理性使用 AI**：认识其能力边界，合理定位 *** ## 参考资料 1. [Claude is not a senior engineer (yet) - Approach with Alacrity](https://www.approachwithalacrity.com/claude-ne/) 最后修改：2026 年 01 月 17 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏