你大概听过这样的说法：AI 正在让程序员变成“10 倍工程师”。但一份来自 ACM Queue 的研究却先问了另一个问题——程序员的时间，到底有多少在写代码？答案是，不到 14%。

2025 年，微软研究团队追踪了 450 多名工程师后发现，开发者平均每天花在写代码上的时间只有 14%。早前研究里，状态较好的工作日编码占比约 18%，状态差的工作日则跌到 11%。读文档、开会、理解旧系统、调试、测试、配置环境、做设计，才是占据他们日程的大头。

这个数字本身并不新鲜。新鲜的是，生成式 AI 铺天盖地宣传“自动写代码”时，恰好暴露了行业里长期被忽略的一个事实：把写代码速度翻倍，整体效率的提升也到不了 15%。因为写代码从来不是瓶颈。

02 微软团队总结的八大误区

这篇题为 *Eight Myths on Software Engineering and GenAI* 的论文由 Jenna Butler、Brian Houck、Margaret-Anne Storey 等微软与高校研究者共同撰写，逐条拆解了围绕生成式 AI 与软件工程的主流误解。

误区一：开发者大部分时间都在写代码。 如上所述，14% 的数字已经否定了这一点。

误区二：写代码是项目瓶颈。 如果编码只占 15%，即使 AI 把编码速度翻倍，对整体进度的推动也小于 15%。更麻烦的是，快速产出未经验证的代码会把压力转移到下游的代码审查、测试和集成，反而可能拖慢交付。

误区三：AI 生成的代码行数是衡量生产力的好指标。 比尔·盖茨曾把“用代码行数衡量软件生产力”比作“用飞机重量衡量飞行进度”。2014 年的一篇统计研究也指出，代码行数并未通过效度检验，作为指标用途有限。微软 CEO 在 2025 年 4 月提到公司“最多 30% 的代码由 AI 编写”，但这仍不能说明质量、速度或商业价值。

误区四：AI 对所有工程师的帮助都一样。 研究结果并不一致。有研究发现 GitHub Copilot 带来明显提升，也有研究显示开源资深开发者使用 AI 后完成任务的时间反而平均增加了 18%。有经验的开发者在熟悉任务上获益更大，但专业年限与提示词信心反而呈负相关。

误区五：AI 能把普通开发者变成 10 倍开发者。 很多研究基于孤立的小型任务得出“55% 生产力提升”的结论，但真实团队环境复杂得多。开发者之间的表现差异主要来自任务本身，而非恒定个人能力。

误区六：用好 AI 是开发者个人的事。 文章指出，真正改变生产力的是组织层面的系统工程，而不是每个人自己摸索提示词。

误区七：好用的 AI 工具自然会被采用。 Stack Overflow 2025 年调查显示，80% 的开发者用过 AI 工具，但只有 29% 相信其准确性。能力惩罚、伦理担忧、对“去技能化”的恐惧都会拖慢采用。

误区八：有了 GenAI，大企业就能以小团队速度创新。 初创公司依赖公开框架和代码，正是大模型训练数据的主要来源；而企业依赖专有遗留系统，AI 没见过这些代码，还要面对合规、安全、隐私和向后兼容的约束。

03 这对企业和团队意味着什么

研究者认为，当前围绕 AI 写代码的叙事，本质上是在优化一个本来就不够大的工作切片。如果组织真正想提升软件交付效率，重点应该放在：减少会议和上下文切换、改善遗留系统可理解性、把代码审查和测试流程做得更轻更快，以及建立可信的 AI 使用规范。

换言之，AI 可以是杠杆，但它撬动的支点不是键盘，而是整个工程系统的设计。

来源：ACM Queue / *Eight Myths on Software Engineering and GenAI*（2026 年 5 月）

原因不是苹果嫌麻烦，而是大模型让”找漏洞”这件事的产能突然爆了。如今的模型能自己发现漏洞、把多个漏洞串成攻击链、再写出可用的利用代码，审核团队根本跟不上提交速度。苹果自己也认这股力量——在 iOS 26.5.2 那批更新的安全说明里，它公开致谢了借助 OpenAI、Anthropic、Z.ai 等工具的研究者；其中安全公司 Calif.io 今年五月称，用 Anthropic 的 Mythos Preview 模型，五天就在 M5 芯片的 Mac 上做出了一个可用的内核内存破坏利用。

代价是真人也被误伤。七人小团队 Bynario 今年向苹果报了五个漏洞、去年报了八个（其中一个已在十一月的更新中被修复），结果提交权限被封。《金融时报》报道之后，苹果才重新联系上他们，开始复核手上的成果，包括一条可能让攻击者完全控制 Mac 的提权链。

说白了，这不是苹果一家的难题。GitHub 前几天也给自己的赏金计划分了层级，专门把认证过的研究员和刷量提交区分开。整个行业过去按”人能提交多少”设计的流程，正在被按”机器能提交多少”重新压测。

如果你在做安全研究，眼下更值得投入的或许不是找得更多，而是证明得更清楚——一份能跑通的复现，比十份看着像样的报告管用。

来源：9to5Mac（Marcus Mendes）、英国《金融时报》

这场电话会议在 7 月 29 日举行。纳德拉说：”Copilot 正在从聊天快速演进到 Cowork，再到 Autopilots。本季度，我们要把这些 Copilot 体验整合到一个超级应用里，包括代码能力……这是重要的一步，我期待很快分享更多细节。”

他同时明确，这款应用将”同时覆盖消费者与商业两类使用场景”。

四个产品，一个入口

根据《The Verge》记者艾玛·罗斯（Emma Roth）的报道，这款超级应用将把微软目前分散在各处的 AI 能力收拢到同一个入口下，具体包括四条产品线：

• Copilot 聊天助手：面向通用交互的对话机器人
• GitHub Copilot：面向开发者的编程助手
• Copilot Cowork：支持团队协作的办公层
• Autopilots：微软对自主智能体的称呼，可在无人逐步干预的情况下执行多步长任务

这一整合此前已有伏笔。《财富》杂志早在今年 5 月就报道过微软在秘密筹备一款超级应用，纳德拉此次的表态相当于官方确认。他在会议后段还提到，这将成为企业内不同岗位每天都会打开的旗舰应用。

对用户而言，好处比较直观：如果一个人平时要在写作用的 Copilot、写代码用的 GitHub Copilot、处理杂活用的智能体工具之间来回切换，合并之后就只剩一个应用。微软表示，目前 Copilot 付费席位已超过 3000 万个，这意味着相当规模的用户会直接感受到这一变化。

分散的品牌，也是要修的问题

对微软来说，整合的意义不止于产品层面。

过去两年，企业 IT 采购方普遍抱怨 Copilot 产品线过于混乱：不同的订阅方案、不同的管理后台、不同的账单条目，而员工眼里其实就是”工作里那个 AI”。把这些收进一个应用，等于把销售环节压缩成一份许可证和一个产品界面。

微软真正的结构性优势在于分发渠道——Copilot 已经嵌入 Windows、Office 和 Azure，但支离破碎的品牌形象一直在拖累采用率。因此这次的”超级应用”既是产品调整，也是一次品牌纠偏，把三类受众收敛到同一个认知模型里。

值得注意的是，纳德拉的措辞是”包括代码能力，在一个超级应用里”，这暗示编程助手仍会作为统一产品内的一项独立能力存在，而不是作为单独产品消失。微软尚未说明现有 GitHub Copilot 订阅用户是否会被自动迁移。

同行都在做同一件事

这个方向并非微软独有。Anthropic 的 Claude 已经提供了整合旗下全部工具的应用；OpenAI 也推出了 ChatGPT Work，把 ChatGPT 与编程工具 Codex 融合在一起，瞄准的正是微软借 Copilot 争取的同一批企业客户。

不过前车之鉴同样存在。OpenAI 自家超级应用的推出过程并不顺利，公司近期公开承认那款产品”确实有点乱”。微软能否避开同样的坑，还需要观察。

另一个潜在风险是，把四个各具特点的产品塞进同一个界面，最终体验可能反而不如单独使用时。微软在这方面战绩参半：Teams 作为合并产品是成功的，而统一 Outlook 与旧版邮件应用的努力则拖了很多年。企业管理员大概率会要求对”哪些 Copilot 能力对哪些员工开放”有细粒度控制权，而超级应用是否具备这一级别的策略管理，目前尚不清楚。

耐人寻味的是，纳德拉近期还表达过另一种倾向——微软正在从”应用”转向以智能体为中心。AI 时代仍然很新，围绕 AI 界面的设计趋势和最佳实践都还在剧烈变动。

作为对照，苹果至今没有任何走向超级应用的迹象，仍在持续推出各自独立的专用应用。这一策略未来是否会调整，同样值得关注。

从财务背景看，纳德拉的这番表态是在微软季度营收 900 亿美元的成绩单旁边给出的，AI 与云业务是主要增长引擎。选择在财报会议而非独立发布会上官宣，本身也说明微软把超级应用定位成一个营收故事，而非一次产品演示。

来源：9to5Mac（https://9to5mac.com/2026/07/30/microsoft-will-launch-new-super-app-for-copilot-soon/）、The Verge、Digital Trends