AI 编程

硅谷大厂正在模糊 QA 和研发的边界——AI Agent 推动岗位融合 最近半年我一直在断断续续想一件事：硅谷大厂对工程师的招聘要求、团队的分工方式，这一年里悄悄变了不少。我翻了二十多家公司的招聘数据和工程团队调整的公开信息，最让我意外的，不是 AI 工具变强，而是"QA 和研发"那条线越来越难划清楚。【关键词：#AI 编程 #岗位融合 #职业规划】 这篇文章是我梳理完数据和自己的思考后写下来的笔记，不求全，只求我能讲明白一件事：这件事对我们这些研发岗位意味着什么，以及我自己会怎么调整职业规划。 01｜硅谷正在发生的几件事 我最近看到的几个具体动作： Salesforce 的 CEO Benioff 公开说过，2025 年起不再招新的软件工程师（Times of India 报道）；客服从 9,000 砍到 5,000，把省下来的人力预算换成 1,000–2,000 个卖 AI 产品的销售岗。 Cognition（Devin 母公司） 整个工程团队 15 个人，每人同时带 5 个 Devin 跑任务；2026 年初他们自家代码库 89% 的提交来自 agent（agentmarketcap.ai 报道）。 GitLab 2025 年裁掉 14% 员工、退出 22 个国家（LinkedIn 报道）；研发团队从 30 个重组为 60 个跨职能 pod，把原本独立的 DevSecOps 收编进 agent 工作流。 Anthropic 2025-12 内部研究：60% 的工程师工作有 Claude 参与，27% 的任务原本不会做（Anthropic 研究页）——agent 不只是替代人，还创造了新的工作量。 更让我在意的是组织层面的合并。Skai 砍掉中间管理层、把团队改成跨职能 pod，效率从 7–12% 跳到 500%；HaxiTAG 33 个工程师只配 1 个 team lead；Jahnel Group 4 个人做原本需要 2 倍人力的活，靠 6 个并行 review agent 替代了原本由不同岗位承担的审核分工。 ...

Go 语言在 AI 辅助编程时代被谷歌官方力挺：动态语言与 Go 并非对立，而是互补关系 原文：谷歌官方力挺：为什么 Go 语言是 AI 辅助编程时代的“标准答案”？ 作者：场长 来源：21CTO 公众号，发布于 2026 年 7 月 16 日 过去，程序员最关心的问题是：哪门语言写起来更快？ 进入 AI 辅助编程时代后，这个问题正在变成：哪门语言更容易让 AI 写对，也更容易让人类看懂、验证、部署和维护？ 这不是文字游戏，而是软件生产方式发生变化后的真实转向。AI 可以在几秒钟内生成数百行代码，却无法替人类承担全部架构责任。代码越容易生成，审查、测试、安全和运维的重要性就越高。 谷歌官方力挺 Go，核心并不是说 Python、JavaScript 或 TypeScript 已经过时，而是指出：Go 从诞生之初就偏向大型、长期运行的软件系统。在智能体持续生成代码的今天，这些原本服务于人类团队的设计原则，也恰好成为 AI 协作所需要的“确定性护栏”。 更准确的结论应该是：动态语言负责快速探索和连接生态，Go 负责把经过验证的能力变成稳定运行的服务、工具和基础设施。 一、AI 编程真正改变的，是软件开发循环 很多人提到 AI 编程，首先想到的是代码补全：输入函数名，AI 自动写出函数体；写一段注释，AI 生成一段实现。 这只是最早期、也最简单的用法。 真正的 AI 辅助编程，通常是一个持续循环： 实现 → 构建 → 测试 → 分析失败 → 修改 → 再次构建。 如果是能够自主操作终端和代码仓库的智能体，它还会继续执行：读取日志、搜索依赖、修改多个文件、运行集成测试、启动服务、调用接口，然后根据结果再次修复。 对人类开发者来说，几分钟的编译等待可能只是一次短暂的停顿。对一个需要运行几十轮的智能体来说，每一次等待都会累积成时间、算力和模型调用成本。 这会放大许多过去被忽略的工程摩擦： 构建速度慢：每次修改都要等待更久，智能体的有效迭代次数下降； 依赖关系复杂：环境安装失败后，智能体可能把大量上下文消耗在解决版本冲突上； 错误反馈太晚：问题到运行时才暴露，智能体可能已经在错误基础上写了更多代码； 代码风格不统一：人类和 AI 都要花时间理解不同写法，评审速度自然下降； 部署链路过长：代码虽然生成了，但服务无法稳定启动，任务仍然不能算完成； 生态变化太快：模型根据旧文档生成的代码，可能在今天已经不适用。 过去，这些问题可能每周出现几次。现在，智能体可能在一天内把同一个循环执行数百次。问题没有变，但问题出现的频率变了，成本结构也随之变化。 ...