这两天 AI 工程化圈子里最热的早报是三件事AI 原生 SDLC 六阶段流程、淘宝百亿补贴背后的数据 Agent以及 Physical Intelligence 在物理 AI 上的实践。三件事分属研发效能、数据智能、机器人三个领域但放在一起读你会发现同一个信号AI 正在从“帮人写代码、帮人查资料”的辅助工具变成一条条完整的业务/研发/物理闭环。这篇文章不做新闻搬运只聊我读完之后的工程化拆解包括每一件事的核心设计、关键环节怎么落地以及团队想跟进时最容易踩的坑。适合正在做 AI 应用、数据平台或者决策自动化的人参考。1. AI 原生 SDLC 六阶段流程研发流程本身开始被重写1.1 先分清AI 辅助编码和 AI 原生研发是两回事过去两年大家用得比较多的 Copilot 属于“AI 辅助编码”人写需求、写设计、写代码主体AI 在中间做补全、做问答整体流程还是传统瀑布或敏捷那套。AI 原生 SDLC 则完全不同它是从流程设计之初就把模型当作默认组件而不是某个环节的外挂工具。我看完那份六阶段流程材料第一反应是它把软件研发重新切成了六个环节需求分析、系统设计、编码实现、质量保障、发布部署、反馈演进。每个环节里 AI 都有明确产物人的角色从“亲手做”变成“定义目标 评审结果 处理异常”。这个转变比“让 AI 多写点代码”要大得多因为它动的是流程本身而不是某几个任务。很多团队对 AI 原生研发的理解还停留在“代码生成率”上这是个误区。代码生成率再高如果需求理解错了、测试用例覆盖不到、上线后没人看反馈整体质量依然上不去。六阶段流程的核心不是让 AI 做更多事而是让 AI 在每个阶段都产出可评审、可追踪、可回滚的半成品人来把住质量闸门。1.2 六阶段拆解每阶段 AI 干什么、人干什么我把这六个阶段做成了一张速查表方便团队照着设计自己的流程阶段AI 承担的核心工作人的核心工作典型产物需求分析从会议记录、历史文档中提取需求生成用户故事和验收标准明确业务目标拍板需求优先级校验关键约束PRD、用户故事、验收标准清单系统设计生成架构方案、接口定义、数据模型给出技术选型对比确认非功能约束检查安全合规做最终决策架构图、接口文档、ER 图、ADR编码实现按任务拆解生成代码、单元测试、迁移脚本主动做静态检查做代码评审处理设计权衡修改边界情况业务代码、单元测试、迁移脚本质量保障生成测试用例执行回归分析覆盖率与缺陷根因把关关键路径测试确认缺陷修复策略测试报告、缺陷清单、覆盖率报告发布部署生成发布计划、变更脚本、监控配置和回滚预案审批发布决定是否回滚处理线上事故发布记录、监控 dashboard、回滚脚本反馈演进汇总用户反馈、日志和指标生成迭代建议与工单草稿决定 roadmap分配优先级确认迭代范围迭代建议、工单、数据报表这张表背后有个容易忽略的点每个阶段 AI 的产出物都是“草稿级”的但必须是结构化、可追踪的。比如需求阶段AI 不能只丢回一段文字而要输出一条条带 ID 的用户故事每条故事关联验收标准这样后面测试阶段才能回溯到需求。1.3 每个阶段落地时最容易忽略的三个细节需求阶段最容易被 AI “带节奏”。我见过不少团队直接把会议录音丢给模型生成 PRD结果模型把老板随口一句玩笑话也写成了需求。正确的做法是先做脱敏和结构化把会议记录整理成“背景、目标、用户、约束”四段式输入再让模型生成用户故事。另外验收标准一定要让模型给出“可测试”的描述比如“补贴列表页加载时间小于 1 秒”而不是“体验要流畅”。设计阶段要防的是 AI 的“一本正经”。模型生成的架构方案经常看起来很完整但一问到“为什么选这个方案”它就含糊了。我会强制要求模型输出 ADR架构决策记录每个决策必须写清楚背景、选项、权衡、结论人只需要审结论合不合理而不是从零看方案。这样评审效率会高很多。测试阶段有个典型问题AI 生成的单元测试断言太“温柔”经常只覆盖 happy path边界值和异常路径基本不碰。我们团队的做法是让 AI 先生成测试用例清单人补关键边界条件再让 AI 按清单生成测试代码。不要直接让 AI “把所有测试都写了”那样覆盖率好看但线上该挂还是挂。1.4 试点怎么选一个中等模块跑通全流程六阶段流程不建议一上来就在核心交易链路试点风险太大。我的建议是选一个业务边界清晰、接口依赖少、团队对领域知识比较熟悉的中等模块先跑一个完整迭代。跑的时候重点记三个数每个阶段的人工介入次数、从需求到上线的前置时间、线上缺陷逃逸率。这三个数直接决定你能不能向老板证明 AI 原生流程的价值。我们当时跑完一个模块前置时间缩短了大约 40%但人工介入次数并没有明显减少这说明 AI 并没有完全替代人只是把人的精力从“写”变成了“审”。这是好事但也意味着你要提前跟团队对齐预期否则大家会觉得“AI 也没让我轻松多少”。还有一点六阶段流程是强依赖工具的光有模型不行。需求管理、接口文档、CI/CD、监控告警这些系统必须提前打通否则 AI 在每个阶段生成的产物无法自动流转。我在实操中看到不少试点失败不是模型能力不够而是产物停在文档里没人接下一步。2. 淘宝百亿补贴数据 Agent让“看数-分析-决策”变成一条流水线2.1 为什么百亿补贴这种业务需要数据 Agent百亿补贴这类业务的运营节奏非常快每天都要盯补贴效率、价格力、流量转化、竞对动作。以前的数据链路是“运营提需求 → 分析师写 SQL → 出报表 → 运营自己看数归因”一个来回少说半天等分析结果出来补贴策略可能已经错过最佳调整窗口。数据 Agent 的出现本质上是把这条链路从“人找数”变成“数找人”。业务人员直接用自然语言提问Agent 负责取数、做异动归因、生成分析结论甚至给出下一步运营建议。我在很多数据中台团队里看到类似的探索淘宝百亿补贴这个案例比较典型的地方在于它把“数据工厂”直接变成了“数据对话”让一线运营不需要理解 SQL 和表结构就能做深度分析。但这里要泼一盆冷水数据 Agent 不是简单接个大模型就能跑的。自然语言转 SQL 只是最外层的壳真正决定效果的是底层的指标语义、数据血缘和归因逻辑。如果底层这些没做好Agent 越聪明错得越离谱因为它会非常自信地给你一个口径错误的答案。2.2 Agent 的五个核心模块拆开看一个能用于百亿补贴这种业务的数据 Agent基本逃不出五个模块第一是统一语义层。所有指标必须有唯一口径比如“补贴效率”到底是指 GMV/补贴金额、订单量/补贴金额、还是拉新用户数/补贴金额必须提前定义清楚并把口径、维度、来源表都沉淀成元数据。没有这层NL2SQL 就是空中楼阁。第二是自然语言转 SQL。不能只靠大模型现场发挥要结合指标字典做语法的强约束限制可查询的表、字段和聚合方式防止模型生成越权 SQL 或语义错误的 SQL。实践中通常会用一些少量样本做 few-shot把常见问法映射到固定查询模板上。第三是工具调用。Agent 不能只查一个库它要能调指标平台、报表系统、AB 实验平台、甚至外部竞对数据接口这样才能回答“补贴效率下降了是不是因为竞对跟进”这类跨源问题。第四是归因引擎。这是很多人忽略的部分。光把数字查出来没有意义要能自动做维度下钻、时间对比、基尼系数或者时序突变检测定位到“哪个品类、哪个渠道、哪个城市在拖后腿”这一步才是运营真正想要的价值。第五是结果生成与人审闭环。Agent 输出的不能只是表格还要有结论、证据链和可执行的建议。同时涉及调价、发券这类敏感动作系统必须有人工确认节点不能让 Agent 直接操作。2.3 一个典型交互流程示例我拿一个百亿补贴运营最常见的诉求举例“帮我看下今天补贴效率比昨天低的原因。”在数据 Agent 架构下完整流程是这样的第一步Agent 解析意图识别出指标是“补贴效率”时间范围是“今天 vs 昨天”动作是“异动归因”。第二步Agent 查语义层确认补贴效率口径是“补贴带来的 GMV / 补贴消耗金额”然后生成查询 SQL。伪代码大致长这样SELECT date, SUM(gmv) / SUM(subsidy_amount) AS subsidy_efficiency FROM dwd_subsidy_daily WHERE date IN (2025-09-04, 2025-09-05) AND business_line baibutie GROUP BY date;第三步Agent 发现补贴效率确实下降于是启动归因引擎按品类、渠道、城市、用户分层四个维度逐级下钻对比两天的差异找出贡献最大的负向维度。第四步Agent 汇总结果输出一段人话“补贴效率下降 8%主要是 3C 数码品类在华东渠道的补贴消耗上升 25%但 GMV 只涨了 6%。建议核查该品类今晚是否有多档补贴叠加确认是否需要收紧人群定向。”末尾标记“建议待运营确认”。第五步运营看到结论后如果觉得有价值一键转给对应品类运营去处理整个归因过程从原来的半天压缩到几分钟。这在我看来是数据 Agent 最实在的价值不是替你拍板而是把分析时间从小时级压到分钟级。2.4 数据 Agent 落地时最容易踩的四个坑第一个坑是口径没统一就急着上。很多团队连“活跃用户”都有一版五六个口径Agent 一问就随机选一个结果运营看到数字不对信任感立刻归零。我接触到的比较稳妥的顺序是先花两周把核心指标口径梳理成文档再上 Agent。第二个坑是拿 Agent 直连生产库。自然语言转 SQL 能力再强也扛不住业务库的表结构复杂和权限散乱。正确做法是在中间加一层数据网关Agent 只能访问经过授权的宽表和汇总表底层明细库和跨部门数据一律隔离。第三个坑是只评估 SQL 生成准确率不评估业务效果。SQL 写对了不代表业务问题解决了。我建议大家至少盯两个业务指标Agent 分析结论的采纳率以及一次分析请求从发起到拿到结论的耗时。这两个数才能说明 Agent 有没有真正进入业务流。第四个坑是让 Agent 直接做决策动作。发券、调价、改补贴比例这类动作目前再怎么也要有人点头。技术上可以在 Agent 的工作流里加“建议状态”和“执行状态”两个状态机只有人审通过后才允许调用执行接口把风险卡在流程上。3. Physical Intelligence 与物理 AI 实践模型开始理解物理世界3.1 Physical Intelligence 在做的事为什么值得关注Physical Intelligence 是物理 AI 领域比较有代表性的一家创业公司专注机器人基础模型目标是构建一个能驱动多种硬件本体的“通用大脑”。和传统机器人公司“一个场景训练一个模型”的做法不同它在尝试用大规模异构机器人数据训练一个通用的视觉-语言-动作模型让同一个模型能操作机械臂、移动底盘甚至双足机器人。这件事难在哪语言模型的数据是文本互联网上几乎无限量供应而物理 AI 要处理的是连续动作、接触力、多模态感知和真实世界的反馈这类数据在互联网上根本不存在只能自己造。所以 Physical Intelligence 这类公司的核心能力一半在模型结构另一半在“数据工厂 blueprint”——一套能持续产出高质量物理交互数据的标准化流水线。这也是我为什么把这条消息放进这篇博文物理 AI 看似离普通互联网团队很远但它解决数据问题的方式跟前面 SDLC 和数据 Agent 的玩法其实是同一个逻辑都是把“数据从哪里来、如何回流、如何闭环”想得比模型本身更重。3.2 物理 AI 和普通 AI 的底层差异物理 AI 和常规的 NLP/CV 模型有个本质区别它在闭环里跟真实世界交互。文本模型输出一个错的词最多是句子不通物理 AI 输出一个错的动作有可能直接把机械臂撞坏。这个差异决定了物理 AI 在模型设计、数据采集、评估和安全机制上走的是另一条路。这里要提一下物理信息神经网络PINN。传统神经网络是靠大量输入输出数据硬拟合PINN 的思路是把物理方程写进损失函数让模型在训练时同时满足数据约束和物理定律约束。打个比方普通模型像一个没学过物理的学生全靠刷题背答案PINN 像是一个被老师强制要求“每个答案都要验算是否符合万有引力”的学生即使题目没见过也不会推出一个违背常识的结果。数据工厂 blueprint 同样值得展开。它在物理 AI 里的角色相当于预训练数据管线之于大语言模型仿真环境生成海量场景、遥操作收集人类示范、真机采集真实反馈、自动清洗去重、标准化标注封装最后变成训练语料。Physical Intelligence 的实践之所以有参考价值就是因为它把“物理经验”变成了可复用、可扩展的数据资产而不是靠老师傅一个个场景去调。3.3 物理 AI 数据工厂的五个核心环节结合目前公开的实践和我对具身智能行业的观察一套可落地的物理 AI 数据工厂大概有这么五个环节第一是仿真数据生成。用仿真引擎生成大量环境、物体位姿、光照变化和任务变体同时做域随机化让模型在仿真里见过足够多“意外情况”减少 sim-to-real 的落差。这里要控制好仿真和真实的差距差距过大模型在仿真里再厉害也是白搭。第二是遥操作数据采集。让人通过手柄、动捕设备操作机器人完成具体任务同时记录视觉、关节角度、力矩、速度等完整时序数据。遥操作数据的质量直接决定模型行为的上限所以采集时要制定严格的操作规范比如动作必须平滑、不能有急停急转。第三是数据清洗与标注。不是所有采集数据都能直接进训练集要过滤掉失败动作、异常轨迹和低质量样本然后把每个数据段标注成“任务描述 初始状态 动作序列 最终结果”的结构化样本。这一步工作量最大也最容易被低估。第四是模型训练与评估。模型在训练中要同时拟合视觉输入、语言指令和动作输出评估却不能只看训练集上的成功率必须在仿真环境和真实环境中做分布外测试看模型面对没见过的物体、背景和执行精度要求时还能不能稳定完成。第五是失败样本回流。真实测试里失败的案例不能删掉就算了要送回数据工厂作为难例补充进训练集。这个“失败回流”动作是整个闭环的发动机没有它数据工厂就只能产出重复数据模型越训越偏。3.4 不做机器人也能从物理 AI 里抄到的东西很多人觉得物理 AI 跟自己没关系其实不是。只要你的业务涉及物理过程、设备状态或时空约束都可以借鉴这套思路。比如工业预测性维护设备有轴承温度、振动频率、电流这些数据可以在损失函数里加上物理方程约束比如“温度不能突变”“振动频率与转速满足关系式”这样即使在故障样本很少的情况下模型也不会给出违反物理常识的预测。这比单纯堆数据靠谱得多。再比如供应链和仓储仿真你有库存周转、订单到达率、搬运路径这些物理和时序约束完全可以用数字孪生 强化学习的方式做决策优化训练用的“场景工厂”就是一个小型数据工厂 blueprint核心是让模型在仿真里把各种边界情况都见一遍。还有一点是安全机制。物理 AI 里的急停、力控阈值、人机隔离这些概念放到任何 AI 决策系统里都适用上线前要定义好“什么情况 AI 必须停下来交给人”不能等出了事故再补。这个思路在数据 Agent 里的人审节点、在 SDLC 里的发布审批本质上是一回事。4. 三条线索的共性和我们团队能直接抄的作业4.1 三个案例背后同一个关键词闭环AI 原生 SDLC 说的是研发流程的闭环需求从用户来最后又通过反馈回到需求数据 Agent 说的是业务分析闭环问题从业务来结论和建议再回到业务动作物理 AI 说的是“感知-决策-执行”的物理闭环失败样本回流到数据工厂再训练。你会发现三件事都不是“模型一次性交付”。过去大家做 AI 项目训练完模型、简单上线就认为结束了但现在靠谱的玩法全是闭环数据在真实使用中持续回流模型在反馈中持续迭代系统的价值随时间增长而不是衰减。我甚至觉得“有没有闭环”可以当成判断一个 AI 项目是否成熟的分水岭。闭环还会改变团队的组织方式。以前是“做模型的做模型做数据的做数据做业务的做业务”各管一段。现在三边必须坐在一起因为数据回流、人审节点、迭代决策这些动作都是跨职能的没有业务参与闭环根本转不起来。4.2 人也跟着变了从操作员变成目标定义者和审批者三件事里人的角色惊人地一致。六阶段 SDLC 里人从写代码变成审代码、定需求数据 Agent 里人从写 SQL 变成审归因结论、拍运营动作物理 AI 里人从手动操控机器人变成设计任务、审核安全边界、处理失败案例。这意味着团队的人员结构要提前调整。业务分析师可能需要具备“提示词 数据校验”的能力测试工程师需要理解 AI 生成用例的盲区运维要开始设计模型服务的监控和回滚机制。我在帮团队做转型规划时反复强调一个原则先别急着招“提示词工程师”先把现有角色的职责里加上“AI 产物审核”这一项这是成本最低、见效最快的过渡方案。另一个容易被忽略的点是信任机制。AI 在闭环里给出建议人在什么条件下采纳、什么条件下否决这些规则要提前写清楚。比如数据 Agent 给的调价建议如果跟运营自己的经验冲突以谁为准我的建议是初期全部人工确认运营被说服了、验证了几次有效之后再逐步放开到部分自动执行。信任是攒出来的不是规划出来的。4.3 按团队情况给落地优先级可以直接抄的作业不同团队的基础不一样我按三类常见情况给一个起步优先级团队类型第一步优先做什么为什么有研发团队的互联网公司AI 原生 SDLC 先做测试用例生成和代码评审辅助切入成本低边界清晰质量反馈快容易量化价值有数据平台但查询门槛高的团队先统一指标语义层再上 NL2SQL 数据 Agent语义层是地基Agent 只是表现层前面不做后面必返工有硬件/生产制造场景的团队从设备数据仿真 预测性维护切入再考虑端到端 AI 决策物理约束明显、安全要求高适合用 PINN 思路小步验证如果你的团队资源比较紧张只能选一个场景我的建议是挑“反馈闭环最短、价值最清晰”的那个。所谓闭环短就是模型输出之后很快就能看到结果是好是坏价值清晰就是做好了能直接省成本或者增收。这两个条件同时满足的场景通常就是最适合先跑 AI 闭环的地方。还要提醒一句别同时铺开三条线。我在实际项目里看到太多团队今天看到 SDLC 觉得要做明天看到数据 Agent 觉得更酷后天又听物理 AI 很热结果每条线都只做了一半。我的建议是六个月之内只聚焦一条主线和一条辅助线主线做到业务指标明显变化再考虑复制方法论到其他场景。4.4 常见问题与排查速查表最后把我在跟进这几类项目时遇到的典型问题整理成一个速查表方便团队对照排查症状排查思路建议动作Agent 回答的指标数字跟报表对不上优先检查指标口径是否存在多版本统一语义层手工核对 10 个核心指标的来源和计算逻辑NL2SQL 频繁生成错误 SQL表结构太复杂模型没有足够的字段约束限制 Agent 只能访问简化后的宽表增加 few-shot 示例六阶段 AI 流程跑了一轮就想放弃很可能是人工介入成本太高缺乏工具流转先打通产物自动流转减少“模型生成-人来抄写”的重复劳动物理模型在仿真里表现好真实环境表现差sim-to-real gap 过大域随机化不够增大环境扰动范围采集更多真实场景数据做微调AI 建议没人敢采纳缺少证据链和人工确认机制让 AI 输出结论时必须附带数据依据并明确标注风险点试点结果无法向老板证明价值没有定义清晰的业务指标从一开始就锁定前置时间、采纳率、缺陷率等可量化指标这些问题的共同根源大部分不是模型不够强而是“数据、流程、信任”三件事没跟上。模型能力可以靠换更大参数、更优质的指令微调来解决但数据口径、流程衔接和人对系统的信任只能靠实打实的工程投入一点点磨出来。4.5 我的一点实际体会从我自己的实践来看AI 原生 SDLC、数据 Agent、物理 AI 这三条线看起来场景天差地别但落地节奏惊人地一致。都是先把数据底座和口径理清楚再让模型输出“草稿级”结果最后由人来审、人来拍板跑通一个最小的正向闭环后再逐步扩大自动化范围。我比较推荐的做法是每个闭环先做到“人负责最终动作模型负责数据和候选方案”跑两三个迭代之后再根据业务结果决定要不要把更多环节交给模型自动决策。别一上来就追求全自动那往往是项目翻车的开始。把模型当成一个能力很强的实习生前期多盯、多校验等它表现稳定了再放手这个节奏在三个场景里都适用。