一句话看懂：DoorDash CEO Tony Xu 公开表示，AI 辅助编程只覆盖了工程师约25%-50%的工作时间，剩余的产品评审、设计会议和跨团队协同仍需 AI 介入。这打破了“AI 写代码=全栈提效”的简单预期，也为 AI 应用工具链的下一步进化点明了方向。
事件核心：发生了什么
在近期播出的《Uncapped》播客中，DoorDash CEO 兼联合创始人 Tony Xu 指出，软件工程师的工作绝不仅仅是写代码。产品需求评审、设计对齐、跨业务部门协作占据了工程师大半的工作时间。虽然 DoorDash 目前已有约三分之二的代码由 AI 生成，且组织内部看到了明显的生产力提升，但 Xu 认为：“如果那些非编码环节的工作流不发生改变，你无法真正获得期望中的效率提升。”
Xu 还特别提到，除了代码层面的 AI 化，DoorDash 仍在探索物理 AI（如食品制备机器人和自动驾驶配送车）在业务中的落地，这些环节的自动化同样重要。Wix 的 CEO Avishai Abrahami 和 OpenAI 创始成员、前特斯拉 AI 负责人 Andrej Karpathy 近期也在不同场合表达了对 AI 能力“被过度承诺”的担忧，Karpathy 甚至形容 AI 写出的代码“臃肿、复制粘贴、抽象脆弱但勉强能跑”。
为什么重要
这一观点直接挑战了“大模型+编程助手=工程效率倍增器”的主流叙事。当前 AI 编程赛道（如 GitHub Copilot、Codium、Cursor 等）竞争激烈，多数产品聚焦于代码补全与生成。但 DoorDash CEO 的发言暗示了一个更深的瓶颈：AI 未触及的组织流程、决策对齐和产品协作，才是限制整体研发效率的关键。
这意味着，AI 工具的未来竞争力可能从“写代码好不好”转移到“能否嵌入整个研发工作流”——包括自动分析需求文档、辅助产品决策、提炼会议结论并生成待办事项。对于大模型厂商（如 OpenAI、Anthropic、Google）而言，这将推动其产品从“代码助手”向“全流程 AI 代理”演进。对于企业采购方，选择 AI 开发工具时也需要从“代码行数”视角转向“团队协作效率”的评估维度。
对用户/开发者/创作者的影响
对软件开发者和技术团队负责人：不应迷信 AI 写代码带来的单点提速。应优先投入资源改造团队内部的沟通、评审与对齐流程，将 AI 嵌入这些环节（例如用大模型自动生成 PR 摘要、分析长线需求文档），才能让工程师被解放出的时间真正转化为产出。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对创业公司和 AI 工具开发者：下一个值得切入的细分市场是“非编码工作流的 AI 化”——比如用大模型做自动化的 API 设计评审、跨团队知识库问答、以及基于业务指标的代码影响预测。单纯优化代码生成模型的推理速度和上下文窗口，可能很快会走入边际效益递减。
对 C 端或 B 端企业采购者：目前公开信息显示，AI 编程工具的提效宣传仍主要聚焦开发环节。企业在引入相关工具时，建议以 3-6 个月为周期评估整体项目交付周期的变化，而非只看代码产出量；同时需关注工具能否接入 Jira、Notion、Slack 等现有的协作工具生态。
值得关注的后续
1. AI 编程产品是否会向“工作流引擎”转型：如果 DoorDash、Wix 等公司的反馈成为行业共识，GitHub、Codium、Replit 等平台可能会在 2026年下半年推出更强调“跨角色协作”的新功能模块。
2. 物理 AI 与代码 AI 的协同案例：Xu 提到食品机器人和自动驾驶配送是 DoorDash 的投资方向，这类“代码+硬件”的闭环一旦跑通，将为餐饮配送行业的技术壁垒带来范式级冲击。
3. 企业组织结构的连锁调整：如果 AI 真的能接管产品评审、需求对齐等流程，传统的“产品经理-设计师-开发-测试”流水线可能被压缩或重组，部分中台岗位的职能定义将发生根本性变化。
