AI Native Engineering

AI 原生软件开发：大厂与行业专家的实践清单

围绕“大公司 / 行业专家如何在真实工程里用 AI 写软件”这一主题，从官方工程博客、一线负责人手记、年度调研报告与国内大厂实践中筛选出 25 篇， 按一手程度 × 数据密度 × 行业影响力降序排列。每张卡片给出可直接判断“要不要读全文”的核心摘要与关键数字。

共 25 篇 · 大厂官方 10 · 专家手记 7 · 调研/咨询 3 · 国内实践 3 · 综述汇编 2
大厂官方 专家手记 行业调研 咨询机构 国内实践 综述汇编
排序说明：#1–#13 基本都是可直接照抄的一手方法论或带硬数据的内部复盘；#14–#21 是专家视角与组织落地；#22–#25 为行业汇总与国内实践。 时间以发布年份标注，能确定的给出月份。
01
大厂官方 OpenAI · Codex 团队（Ryan Lopopolo） 2026-02

Harness Engineering：在智能体优先的世界里善用 Codex

一份极端但真实的实验报告：5 个月、3→7 名工程师、零手写代码交付了一个约 100 万行、1500 个 PR 的真实内部产品（含外部 alpha 用户），耗时约为手写的 1/10。 真正的经验不在提示词，而在工程环境：AGENTS.md 只做约 100 行的“目录”而非百科全书；把 UI、日志、可观测性做成 agent 可读（worktree 启动实例 + Chrome DevTools 协议 + LogQL/PromQL）；用自定义 linter 机械强制分层依赖等“不变量”。

  • 核心判据：AGENTS.md 是地图，不是手册——巨量指令会挤占 context、迅速腐烂、无法机械校验
  • agent 视角下“不在仓库里、进不了 context 的知识等于不存在”，Slack 里的架构共识必须落盘
  • 吞吐上来后合并哲学反转：修正很便宜，等待很昂贵；评审逐步转向 agent-to-agent
阅读原文 → openai.com
02
大厂官方 Anthropic · 工程博客 2026 持续更新

Claude Code 最佳实践（Best practices for Claude Code）

Anthropic 内部团队与大量外部工程师验证过的 agentic coding 方法论，是目前“最容易被直接照抄”的一份手册。 全文围绕一个硬约束展开：context window 会迅速填满且性能随之下降。由此推导出几条可操作铁律——给 agent 一个可运行的 pass/fail 检查（测试、构建、截图对比）、探索→规划→实现→提交四阶段分离、CLAUDE.md 每一行都要过“删掉会让 Claude 犯错吗”这一关、用 hooks / skills / 子智能体把纪律变成确定性机制。

  • 最高杠杆动作：给 agent 能自己跑的验证——否则“看起来做完了”就是唯一信号，你成了唯一的反馈环
  • 让 agent 出示证据（测试输出、运行命令、截图），而不是声称成功
  • 膨胀的 CLAUDE.md 会让 Claude 忽略你的真实指令；按目录分层放，别堆百科
阅读原文 → anthropic.com
03
大厂官方 Amazon / AWS · 机器学习博客 2026

前沿团队如何重造 AI 原生开发（How frontier teams are reinventing AI-native development）

亚马逊数百个工程团队实验的复盘，数据最扎实的一篇。三条路径：pathfinder（6 名工程师 76 天重写 Bedrock 推理引擎，原估 30 人 12–18 个月；人均周提交从 2 涨到 40）、 structured sprint（Prime Video 10 天 556 commits，把 90 周工期的项目压到 24 周）、in-situ（50 个普通团队中位数 4.5x，部分超 10x）。 关键结论：用同样工具的团队差距巨大，分水岭是“是否重构了工作流”，不是工具本身。

  • 三个 1.5x 因子相乘才成立：低判断工作加速 × 高判断工作专注 × 领域知识即时可得，去掉任一个收益就塌
  • 普通团队（brownfield、非精选工程师）也能拿到中位数 4.5x——不是精英特例
  • 瓶颈判断：代码生成速度已不是瓶颈，决策与审批流程是
阅读原文 → aws.amazon.com
04
行业调研 Google Cloud · DORA 年度报告 2025

2025 DORA 报告：AI 辅助软件开发现状（State of AI-assisted Software Development）

近 5000 名技术从业者 + 100 小时质性访谈的年度权威调研，是判断“AI 到底有没有用”的基准数据。 核心结论一句话：AI 是放大器——放大高效能组织的优势，也放大低效能组织的失能。90% 从业者用 AI、80%+ 认为提效， 但 30% 几乎不信任输出；AI 采纳首次与交付吞吐正相关，却仍与交付不稳定性正相关。报告还给出 7 类团队画像与 DORA AI 能力模型（清晰 AI 策略、健康数据生态、高质量内部平台等 7 项）。

  • 信任悖论：仅 24% 高度信任 AI 输出，30% 几乎不信任；日均约 2 小时花在 AI 上
  • 94% 组织已做平台工程，内部平台质量决定 AI 投资回报高低
  • 从“要不要用”转向“会不会用”：培训重点应是批判性引导与验证，而非鼓励使用
阅读原文 → PDF 全文 → blog.google
05
专家手记 Addy Osmani（Google Cloud AI 总监，前 Chrome 工程负责人） 2026-06

Loop Engineering：别再 prompt 了，去设计循环

2026 年传播最广的一篇专家长文，把“提示工程 → 上下文工程 → harness 工程 → loop 工程”这条演进线讲透了。 一个能跑的 loop 需要六个部件：定时自动化（发现与分诊）、worktree（并行隔离）、Skills（把项目知识写死）、插件/连接器、子智能体（干活的与审查的必须分开）、以及落在磁盘上的状态记忆。 作者同时给出三个只会更尖锐的警告：验证责任仍在人、理解债（comprehension debt）、认知投降（cognitive surrender）。

  • “写代码的模型给自己的作业打分太仁慈”——必须由独立 agent 做验证
  • agent 会忘，仓库不会：状态必须存在磁盘上的 markdown / 看板，而不是 context 里
  • 适不适合建 loop 有前提：任务高度重复、验证已自动化、token 预算够、agent 有完整工具权限
阅读原文 → O'Reilly 转载版 → addyosmani.com
06
大厂官方 Anthropic · 内部实践访谈 2026

Anthropic 内部各团队是怎么用 Claude Code 的

覆盖数据基础设施、产品工程、安全、推理、数据科学、增长市场、法务等十来个团队的真实用例合集，是“AI 怎么渗透进非编码岗位”的最好样本： K8s 集群挂了直接把仪表盘截图喂进去定位 Pod IP 耗尽；把 Terraform plan 丢进去问“我会后悔吗”；法务自建电话树系统；增长团队几分钟生成数百条广告变体。 最有价值的判断：成功团队把它当思考伙伴而非代码生成器，并明确区分“可全托管异步”与“必须同步监督”的任务。

  • 推理团队研究时间下降 80%（1 小时 → 10–20 分钟）；故障定位 10–15 分钟 → 约 5 分钟
  • Vim 模式功能约 70% 由 Claude 自主完成，人类只做收尾
  • 边界正在溶解：能清楚描述问题的人就能造工具，法务、市场、财务都在自建
阅读原文 → anthropic.com
07
大厂官方 Microsoft · All Things Azure 开发者博客 2026-04

智能体时代的 DevOps 手册（DevOps Playbook for the Agentic Era）

微软给出的“agent 时代 DevOps”系统答案，适合工程负责人直接转成内部规范。三个最有分量的部分： 规范从静态文档演进为 Living Specs（持续更新、链接代码与测试、被流水线用于验证）；agent 治理三维度（一致性、可审计、范围控制）； CI/CD 从“守门员”升级为“主动验证者”——不止问“能编译吗”，还要问“是否匹配规范”“测试是不是 agent 自己写的自我验证测试”“新依赖是否真实存在”。

  • 三层验证：结构 / 语义 / 来源，分别对应架构边界、行为正确性、依赖与供应链真实性
  • 新型风险：通过代码注释与 issue 的 prompt injection、幻觉依赖包、agent 越界改 CI/部署配置
  • 附带六维“代码库是否 agent-ready”自检清单与四级成熟度模型
阅读原文 → devblogs.microsoft.com
08
咨询机构 McKinsey · The Symbiotic Enterprise 2026

共生型企业：软件开发里的“两班制工厂”

麦肯锡对 AI 原生研发组织形态最完整的一次描述。模型是：人类上白班（定方向、精化故事、把特性翻译成详细 spec 与验收标准、给架构约束与护栏）， agent 上夜班（由编排智能体协调编码、测试、QA、安全、性能、文档等专职子智能体并行执行，失败自动回流修正），早上人类收一批评审就绪的 PR。 判断很明确：第一代助手只带来 5–15% 提效，重构工作流之后才是阶跃（某大型金融机构的 agent 工厂开发新支付系统，生产力提升 40%+）。

  • 人类角色从“写代码”变成指挥、分解、质量把关；24 小时交付循环替代多周冲刺
  • 可自动化范围随时间扩大，系统自主性与生产力同步上升
  • 麦肯锡自身已在不到两年内部署约 2.5 万个 agent，与 4 万名员工并行
阅读原文 → mckinsey.com
09
大厂官方 Shopify · 工程 VP Farhan Thawar 深度访谈（Bessemer） 2026

Shopify 的 AI 优先工程手册（Inside Shopify's AI-first engineering playbook）

Tobi Lütke 那份“AI 使用是基线要求”的备忘录之后，Shopify 工程负责人把可复制的部分讲清楚了： 标准化工具之下的基础设施（自建 LLM 代理网关统一路由、计费与用量分析，而不是统一到某一个工具）；20% 提效主要来自更快原型与“探索 10 个方案而不是 2 个”，不看代码行数； 文化靠领导人示范 + 低门槛赋能（提示库、配置指南、MCP 连接）而非自上而下命令；最大长期风险是理解债——要求工程师至少理解自己工作层以下 2–3 层。

  • 法务口径“默认 yes”；token 不设配额，甚至有 token 消耗排行榜当价值代理指标
  • 判断：2026 年没搞定 agentic harness 就会落后——并行多 agent 或 45 分钟以上串行深度批判循环
  • 非工程岗（销售、财务、HR）开始自建 n-of-1 软件
阅读原文 → bvp.com
10
专家手记 Addy Osmani · AI Engineer World's Fair 2026 闭幕 keynote 2026

Own the Outer Loop：工程师要握住的是外循环

对“人还剩下什么”这个问题最有力的回答。框架是三个词：Quality（前置检查产生证据）、Verdict（放行 / 阻断 / 重定向 / 收窄 / 加护栏的生产决策）、Answerability（被问到时能解释为什么）。 agent 跑内循环（调查—实现—验证—重复），人拥有外循环：决策、验证、批准、负责。文中给出关键背景数据——Sonar 2026 报告显示 42% 的提交代码是 AI 生成或重度辅助，而生成变便宜后，稀缺的是评审、验证、理解与维护。

  • 系统内产出的是能力，系统外人拥有的是代理权（agency）
  • 信任—验证缺口：很多人不信任 AI 代码，却没把这份不信任写进验证流程
  • 不要给 agent 它能行使的最大自治，只给能在必要时踩住刹车的那一份
阅读原文 → addyosmani.com
11
专家手记 Thoughtworks 2026

超越 vibe coding：AI 原生工程的五大构件

Thoughtworks 对“新工程栈”的结构化拆解：选 agent（Claude Code / OpenCode / Cline / Antigravity 等，按隐私与工具调用控制粒度选）、 选模型（按认知任务专业化分工：架构推理、代码生成、测试与质量、文档综合、安全漏洞分析）、选方法论（如 BMAD）、写 spec、配 context 与护栏。 核心判断：2026 年企业级开发已经走出 vibe coding，工程师的工作从打字变成编排。

  • agentic engineering 与 vibe coding 从外面看不出来：同样工具、同样编辑器、同样像样的 PR，差别在验证机制
  • agent 是“受监督自治”：可以自主改 bug、实现小功能，但提交必须经人工正式评审授权
  • 安全与漏洞分析模型建议做成强制 pre-commit hook
阅读原文 → thoughtworks.com
12
大厂官方 Amazon / AWS · DevOps 博客 2025

生成式 AI 如何重塑亚马逊的开发者工作流

亚马逊视角的“生产力悖论”：开发者每天真正写代码只有 1–2 小时，其余被 toil（文档、协调、运维）吃掉，这才是该被 AI 拿下的部分。 把内部数百万份知识文档灌进 Amazon Q 后，等待技术答案的时间减少 45 万小时；大规模现代化改造节省 4500 开发者年。 更重要的判断是：AI 让“以前不可能做的任务”变得可行——比如跨数千服务的复杂依赖升级。

  • 新人掌握一门新语言的爬坡期从 3 周降到 1 周，资深工程师开始敢用不熟的语言做项目
  • AI 在改变开发者“思考问题的方式”，而不只是写代码的速度
  • 下一步是把正确性验证、测试、异常检测也交给 agent 做互补
阅读原文 → aws.amazon.com
13
专家手记 Clare Liguori（AWS 资深首席工程师，Kiro 负责人） 2026

从 AI 辅助到 AI 原生：如何建设前沿开发团队

亚马逊那批 4.5x–10x 数据的一线讲述者。基于 Bedrock Mantle、Prime Video 冲刺、50 队 Amazon Stores 试点总结出五个日常习惯： 投资 agent 上下文（把隐性知识转成 steering 文件与 skills，并随模型进步修剪过时指令）、慢下来才能快（重构出强类型、agent 可导航的代码库）、 别保姆式盯梢而是“喂饱”它、用 spec 把意图显性化、把确定性测试与本地 mock 左移。

  • frontier 开发者手写代码只占 1–2%，agent 可连续自主运行数小时
  • 坦白一个反直觉事实：初期 ROI 是负的，要先接受生产力下滑才有后面的曲棍球杆
  • 组织性风险：上下文切换导致倦怠、铺太快没有本地最佳实践、发布审批成为新瓶颈
阅读原文（含要点整理） → bestblogs.dev
14
国内实践 美团技术团队 2026-05-07

用 Agent 评测思路管理 AI Coding —— 31 万行代码 AI 重构的实践

国内最扎实的一篇落地复盘：31 万行代码重构没有申请一天专门排期，而是拆进业务需求里渐进式消化。 四步法可直接抄：AI 穷举扫描技术债（核心开发只圈高危方向）→ 团队共识固化为 always 加载的 AI Rule / Skill → 主 R 打样沉淀迁移 SOP → 建立 Pre-PR 机制让 AI 先按规范自查，人工 CR 只聚焦业务语义。 最扎心的一句：当 90% 代码由 AI 生成，人的工作变成“设计并维护一个能让 AI 可靠产出代码的工程环境”。

  • 重构不需要排期，需要的是拆解能力——技术债要能变成业务需求的顺带动作
  • 规范不落进 AI 工具链里就只是一纸空文
  • AI 提速后 CR 成为新瓶颈，Pre-PR 自查这步不能省
阅读原文 → tech.meituan.com
15
专家手记 Birgitta Böckeler（Thoughtworks 杰出工程师）· The Pragmatic Engineer 2025

两年 AI 工具使用经验总结（Learnings from two years of using AI tools for software engineering）

全球最早一批“全职研究 AI 辅助交付”的工程师的两年回顾，冷静且少有营销味。内容覆盖：从“打了激素的自动补全”到 agent 的演进时间线； 把 AI 当“队友”的实操心智模型（特别提醒它会通过迎合你来“操纵”你的认知偏差）；速度确实提升但测量极其复杂，缺乏监督时质量影响可能是负的； 以及一个反共识判断——LLM 不是下一代编译器，AI coding 的未来分布极不均匀，我们会在摸索过程中主动背上技术债。

  • review fatigue 是真实现象，部分开发者会因此直接关掉补全
  • 快速铺工具时，团队动力学受到的冲击往往比技术风险更早暴露
  • 适合作为团队内部“建立共同语言”的共读材料
阅读原文 → newsletter.pragmaticengineer.com
16
大厂官方 Microsoft · 开发者博客 2026

Agentic-Agile：智能体开发为什么还需要敏捷（而不只是提示词）

微软把 spec-first 塞回敏捷框架的一次实操总结，附可直接复制的开源模板（agentic-agile-template）。要点：先建 issue 再写代码（没有 issue 就不许提交）、 验收标准即契约、按波次交付、把治理放进 backlog——CI/校验基础设施是第一张 story，不是最后一张。 文中还坦白了自己的翻车：CI 流水线没在第一时间建，导致质量债跨波次累积，最后被迫返工。

  • 判据很好用：如果你是在最终评审时才抓到架构违规，说明治理来得太晚
  • 每波交付之间加对抗式代码评审，单测写进验收标准
  • 用 PR、CI、retro 来持续改进这套人机混合流程
阅读原文 → devblogs.microsoft.com
17
行业调研 Gergely Orosz · The Pragmatic Engineer 2026

AI 时代软件工程的未来：六个判断

Pragmatic Summit 与 Deer Valley 50 人闭门工作坊的共识整理，参与者包括 Martin Fowler、Kent Beck、Laura Tacho、GitHub 前 CEO、Atlassian CTO。 最有价值的是数据而非观点：92% 开发者每月使用 AI 编码工具；“不健康”组织的事故数是健康组织的 2 倍，健康组织事故少 50%。 另外一个被私下反复讨论的话题：中级工程师正在被 AI 浪潮落下——新人用工具更猛，资深者有经验护城河。

  • AI 原生团队长什么样（GitHub 前 CEO × Atlassian CTO 对谈，含角色与考核变化）
  • 重构在 AI 时代不但没死，反而更重要
  • 也有反向样本：做嵌入式 Assembly/C 的工程师仍在大量手写代码，只是 AI 占比持续上升
阅读原文 → newsletter.pragmaticengineer.com
18
专家手记 Thoughtworks Perspectives #36（Martin Fowler、Birgitta Böckeler 等） 2025-05

AI 优先软件工程：开发的演进（AI-first software engineering）

给业务负责人看的一期，但技术判断密度很高。三条值得记住：AI-first 软件交付（AIFSD）远不止编码，覆盖从需求到长期运维的全生命周期； 真实采用率没看起来那么高——多数人只把 AI 用在很小的编码子集里，只有极少数组织把它当成需要变革管理的事； 遗留系统现代化可能是 ROI 最大的场景，逆向工程从几个月压缩到几周，直接消掉“分析瘫痪”。

  • Fowler 判断：这一转变的意义可能堪比从汇编到高级语言
  • 生产力只是冰山一角，真正的收益是整个软件反馈环被加速
  • AI 会同时放大解法与问题，监控与高质量输入是前提
阅读原文（中文版） → thoughtworks.com
19
大厂官方 Anthropic · Applied AI 团队 2025–2026

在组织内规模化 agentic coding（Scaling Agentic Coding Across Your Organization）

给已经个人跑通、要往全组织推的技术负责人看的落地手册。内容包括：从 20–50 名 power user 起步做试点而不是全员铺开、 沉淀组织专属的 slash 命令与 CLAUDE.md、如何衡量 ROI、常见的采纳阻力与解法、安全前置（保护代码库），以及超出常规编码的创新用法（遗留系统现代化、新人上手、事故响应、非技术岗位参与）。

  • 先造冠军用户，再靠他们扩散——成功模式是可设计的，不是自然发生的
  • 按用例定制 slash 命令（如 /migrate-db、/fix-security）是最容易被低估的杠杆
  • 组织草率推进的典型后果：采纳阻力、结果不一致、错失重构研发方式的机会
阅读原文（PDF） → resources.anthropic.com
20
行业调研 Bessemer Venture Partners · Atlas 2026

AI-pilled 工程团队内部：规模化不失焦的五条教训

从 Shopify 等一批“全员 AI 化”团队抽象出的领导力层面教训。核心论点是：agentic 开发改变了领导力的算式—— 工程管理者从“管写代码的人”变成“管调度 AI 写代码的体系”。两种已跑通的 harness 模式：多 agent 并行 + 人工评审合并；或单个模型跑 45 分钟以上的串行深度批判循环。 同时提醒不同阶段需要不同的工程领导力画像，别用一个模板管到底。

  • MCP 走基础设施治理而非个人授权：agent 能查 Salesforce/Slack/GitHub，但权限继承人的 auth
  • “标准化基础设施，不标准化工具”——在剧变期唯一稳的做法
  • 配套问题清单：AI 工具基建能否按团队/项目衡量成本 vs 收益
阅读原文 → bvp.com
21
专家手记 Birgitta Böckeler × InfoQ 播客 2026

从 MCP 与 vibe coding 到 Harness Engineering：AI 原生工程的一年演进

一年之内发生了什么：从啰嗦的 vibe coding 走向上下文工程；单体大文件和一堆 MCP server 被懒加载的 skills、CLI 和脚本取代，目的就是省 context。 “Harness engineering”的目标是让 agent 能自我纠错从而减少人工监督：前馈工具（约定、架构上下文）负责引导，反馈机制（静态分析、测试结果）负责纠偏。 最实用的一条：监督强度应当按成功概率 × 失败影响 × 可检测性做风险评估来定，而不是一刀切。

  • 工具形态之争的实情：终端型（Claude Code）适合无头执行，IDE 型（Cursor）适合调试与复杂任务
  • AI 原生仍处在“成形期”，风险、自治与监督的平衡尚未收敛
  • 想快速补齐概念演进，这一期性价比最高
阅读原文 → infoq.com
22
综述汇编 Sonar · Sonar Summit 2026 六大要点 2026

Sonar Summit 2026：关于编码未来的六个要点

Gergely Orosz、Laura Tacho、Sonar CEO、以及 OpenAI / Google / Wiz 同台的一次行业共识快照。要点包括：SDLC 变成 Agent Centric Development Cycle（开发者从创造者变治理者）； “AI 验证金字塔”（人守两头——定结构化计划与最终验收，中间交给类型检查、lint、单测）；Laura Tacho 的“soup phase”与“组织免疫系统”； 企业落地形态是把概率性 AI 包进确定性质量门（SonarQube MCP + Codex 的自修复回路）。

  • 传统 PR 流程正在变得不合时宜：PR 体积膨胀、评审时间增长，成为新瓶颈
  • “没有安全绳的自治是负债”——企业侧的真实态度
  • 到 2027 年，代码量会更像负债而非资产，考核要转向高信号业务影响
阅读原文 → sonarsource.com
23
国内实践 腾讯云 · CodeBuddy / WorkBuddy 团队 2026

AI 队友正在进入公司：腾讯云如何重构下一代研发工作流

腾讯内部“AI 原生团队”协作闭环的完整描述：PM 用需求录入 Skill 发起任务 → AI 参与需求澄清与任务拆解 → 技术 Leader 与 AI 共建技术方案并生成研发任务 → 研发与 AI 协同开发验证 → 交付分析 Skill 回收数据反哺下一轮。 开发者角色变成“派活、收作业、把关”。文中坦白两个真实瓶颈：AI 生成 PR 太快，人工评审成为新瓶颈；收益高度依赖团队自身的自动化基建水平（工程素养高的团队收益被放大，低的要先补基建）。

  • CodeBuddy 2.0 升级：4 名工程师、4 个月、99% 代码由 AI 生成（原架构级演进通常需一年）
  • 下一步是 7×24 无人值守：AI 按测试与扫描结果自修复，甚至 NPC 之间互相协作推进
  • 竞争焦点判断：从“模型写得多好”转向“能否嵌进真实研发流程”
阅读原文 → x-techcon.com
24
国内实践 阿里 / 字节 / 腾讯 · 中国企业家报道（含阿里云叔同访谈） 2026

阿里、字节、腾讯，开始新一轮 AI 大基建

国内三家 AI 原生组织形态的横切面。可量化的几点：阿里 QoderWork 研发团队仅 5 人、7 天从启动到公测；阿里内部 AI 落地评估体系已从“代码生成量”转向 Token 消耗 vs 价值产出； 各家都在建 Skill 广场（腾讯 WorkBuddy 已汇聚 140+ 专家、1000+ 常用 Skill）。最有冲击力的是叔同的判断：未来 100 元产业投入中，只有 1–5 元会分配给软件与代码生产环节，其余流向 GPU 算力、云平台与模型基座。

  • AI 原生组织的核心特征：鼓励大规模消耗 Token，在关键场景换 10x 以上效能
  • 程序员重心转向：需求判断、管理 agent、调度任务、评估输出质量与规范执行
  • 产品衡量标准随之改变：日活与时长让位于迭代速度与市场占有率
阅读原文 → 163.com
25
综述汇编 行业综述：Stripe / Shopify / Duolingo / Vercel 横评 2026

工程团队在 2026 年实际怎么用 AI 交付软件（四家横评）

二手汇编但细节密度很高，适合一次性看完四种不同路线。Stripe：fork 自 Block 开源工具 Goose 搭了六层 agent 基础设施，中心 MCP server “Toolshed” 挂了 400+ 内部工具，agent 环境断网、无生产权限——隔离就是权限系统； Shopify：Augmented Engineering，不设 token 上限、设计师也要用 AI 出原型；Vercel：v0 走“AI 是起点”，AI SDK 6 支持 needsApproval 人工闸门（数据库迁移级别的双人规则）；Duolingo：把外包/合同工流程换成 agent，重点投入在评审基建而非 agent 本身。

  • Stripe 的规格驱动：agent 拿到的是详细 API 规范（错误码、限流、幂等、测试场景），不是开放式 prompt
  • 四家共同点：每个 PR 仍然人工审，代码 AI 写、人类批准
  • Duolingo 的教训：难点不是让 agent 产出代码，而是建立能抓住自动化测试漏掉的细微正确性问题的评审流程
阅读原文 → algeriatech.news