企业官网建设流程全解析

早上刷到 BestBlogs 的 09-05 早报，三条标题都挺来电：AI 原生 SDLC 六阶段流程、淘宝百亿补贴背后的数据 Agent、Physical Intelligence 的物理 AI 实践。单独看每一条都值得聊，但把它们放在一块儿读，你会发现它们正好落在 AI 落地的三个完全不同的层面：改软件流程、改业务决策、改物理世界。我这两年一直在做 AI Agent 的工程化落地，也有不少朋友在追 AI 编程和数据智能的方向，说句实话，早报本身只是索引，真正有价值的是把每条新闻背后的工程逻辑、落地方式和踩坑点拆开来看。这篇文章就把这三条信息从头到尾展开，结合我自己在 Agent 项目里的实际经验，聊聊每条到底意味着什么、能怎么用、哪里有坑。

1. AI 原生 SDLC：从"辅助写代码"变成"重写开发流程"

1.1 六阶段流程到底指哪六个阶段

传统 SDLC，也就是软件开发生命周期，大家都很熟了：需求分析、设计、开发、测试、部署、维护。AI 原生 SDLC 不是在这套流程上简单地加一个"AI 帮你写代码"的步骤，而是把整个流程的每个环节都重构成可以让 AI 参与、甚至由 AI 主导的形态。

我看到的消息里提到的六阶段流程，拆开来看大致是这样的：

• 需求澄清与规格生成：产品经理扔进来一段自然语言描述，AI 负责补全用户故事、验收标准、边界条件，生成一份可供后续步骤直接消费的需求规格文档。
• 架构设计与任务拆解：AI 基于规格生成技术方案，包括模块划分、接口定义、数据模型设计，并把开发工作拆成一张张可执行的任务清单。
• 代码生成与实现：编码 Agent 按任务清单写代码、改代码、跑本地检查，这个阶段也是目前工具链最成熟的环节。
• 自动化测试与质量验证：AI 生成单元测试、集成测试，并对代码做静态扫描、安全检查和代码审查。
• 构建、部署与发布：AI 负责构建产物、执行 CI/CD 流水线，根据测试结果和变更范围判断是否可以发布。
• 线上反馈与维护闭环：线上日志、报错、用户反馈被 AI 聚合，聚类出问题根因，生成修复补丁，再进入下一轮迭代。

熟悉 Agent 工程的朋友一眼就能看出来，这就是把一个人工智能体的完整闭环——感知、规划、执行、验证、反馈——套在了软件开发的全流程上。和单纯用 Copilot 补全代码是完全不同的玩法： Copilot 是人在写代码，AI 在旁边搭把手；AI 原生 SDLC 更像 AI 在操盘整个开发过程，人变成审批者和最终责任人。

1.2 哪些环节真正被 AI 改写了

这里我要泼一点冷水。六阶段听起来很完整，但以我实际测试过的 Agent 编码流程来看，各个阶段的价值是完全不对等的。

效率提升最明显的是代码生成和测试生成。比如我有一个订单状态机的改造，传统人工写大概要一天，用编码 Agent 半小时就完成了一版，还顺手把单元测试补到接近百分之九十的行覆盖率。原因是这两个环节的上下文足够集中，AI 在仓库级上下文中能准确理解现有代码结构，产出可验证的结果。代码能不能编译、测试能不能通过，都是客观反馈，AI 可以基于反馈自我修正。

但需求澄清和架构设计这两个阶段，AI 的表现就远远没有宣传里那么神。原因是这两个环节的核心不是语言生成，而是决策。产品要什么优先级，哪些需求这期做、哪些砍掉，技术方案是选微服务还是选模块化单体，这些是充满了权衡和业务上下文的决策，AI 没有业务负责人脑子里那些"不能明说但很重要"的信息。我见过不少团队让 AI 做需求拆解，结果拆出来的任务清单表面看很工整，但缺少对历史包袱的考虑，真正执行时返工率很高。

所以目前 AI 原生 SDLC 真正跑得通的组织形态是"半自动流水线加人工闸门"：在需求到任务、任务到代码、代码到测试这些环节之间保留人工确认点，而不是把六个阶段全部交给 AI 自动跑完。说白了，AI 可以当得力执行者，但不能当默认决策者，至少在需求这个层面还不行。

1.3 落地 AI 原生流程时最容易翻车的三个地方

第一，上下文窗口不是越大越好。我见过团队为了"让 AI 更了解项目"，把整个仓库都塞进 Agent 的上下文，结果 token 消耗爆炸，推理速度变慢，代码反而开始出现莫名其妙的风格混合。正确做法是让 Agent 按需拉取上下文：当前模块、相关接口、测试模板，而不是让它记住所有历史代码。

第二，AI 生成代码的"bug 分布"和人类完全不一样。人写的代码容易在边界条件和异常处理上出错，AI 生成的代码则更像"看着对但经不起推敲"——它在常见路径上表现良好，一到并发冲突、数据一致性、极端输入就会暴露出隐藏问题。所以 AI 原生的测试阶段必须更严格，尤其是并发和异常场景的测试要人工重点审查，不能觉得 AI 写的代码"测试都过了"就放心。

第三，责任边界要提前划清。代码是 AI 写的，但出事故时背锅的肯定是团队。我现在的做法是：AI 生成的每一次变更都强制关联一个 human reviewer，并且在提交信息里记录 AI 工具、模型版本、上下文摘要，将来一旦出问题可以回溯是提示词导致的幻觉还是模型本身的问题。

2. 百亿补贴背后的数据 Agent：当数据洞察变成自动执行

2.1 为什么是百亿补贴业务先跑起来

淘宝百亿补贴是电商里竞争最激烈、数据变化最快的业务场景之一。补贴活动的定价、库存、流量采买、竞对动向，每一天都在剧烈变化。传统的数据分析流程是：业务方发现某个指标不对，提需求给数仓，数仓写 SQL 查数据，分析师做归因，再回给业务方。这一来一回，在百亿补贴这种分钟级变化的活动面前，速度完全跟不上。

数据 Agent 在这里的核心价值，不是"更快地出报表"，而是把整个"发现异常—定位根因—建议动作—触发执行"的链条自动化。简单说，传统 BI 是人找数据，数据 Agent 是数据找人，甚至数据直接驱动动作。

为什么百亿补贴适合先落地？因为它有几个天然优势。第一，业务闭环清晰，补贴的投入和产出能算清楚，ROI 是一个明确的目标函数；第二，指标链路完整，从流量到点击到转化到客单到毛利，数据链路是通着的；第三，动作可以被标准化，比如竞价调价、预算追加、库存释放，这些都是可以规则化、可以被 Agent 调用的操作。这三个条件缺一个，数据 Agent 就容易变成"一个会说话的数据看板"，而不是真正的智能体。

2.2 数据 Agent 和传统 BI 的差别到底在哪

我在不少场合被问到同一个问题：我们已经有 BI 和日报，为什么还要数据 Agent？我的回答是，BI 是工具，数据 Agent 是闭环。

具体差别可以列一个表：

举一个具体场景。百亿补贴里某个品类的 ROI 突然掉了 20%，BI 的做法是告诉你，ROI 从多少掉到多少，折线图展示一下趋势，然后人脑开始分析为什么。数据 Agent 的做法是：自动定位是补贴成本涨了还是转化率跌了；进一步查到转化率跌是因为某个渠道的流量质量下降；再看这个渠道流量下降是不是因为竞对同期提价抢量；最后给出建议，比如"建议把 A 渠道的补贴预算调回上一档，预计 ROI 回归到阈值以上"，如果权限允许，它直接就把预算调整执行了，并在执行后持续监控指标变化。

这套能力的关键，不是某个大模型有多聪明，而是背后的归因图谱做得好不好。数据 Agent 的"智商"取决于知识图谱里各指标之间的逻辑关系、活动策略的规则、历史案例库的沉淀。模型只是负责把推理过程串起来。

2.3 电商大促场景下数据 Agent 的真实挑战

数据 Agent 听起来很美好，但在真实电商环境里，有四个坎是绕不开的。

口径一致性是第一个坑。补贴金额怎么算、ROI 分母是 GMV 还是毛利、新客怎么定义，这些口径在不同团队之间可能完全不同。数据 Agent 如果接入了两套口径不一致的数据，给出的归因结论就会自相矛盾。所以我做这类项目时第一件事不是选模型，而是先做指标口径治理，把每个核心指标的来源、计算逻辑、生效时间全部元数据化，喂给 Agent 当基础规则。

权限边界和动作控制是第二个坑。让 Agent 自动调价、自动追加预算，一旦出错就是真金白银的损失。我强烈建议在初期把 Agent 的权限设计成"只读归因 + 人工确认执行"，跑通稳定后再放开低风险动作的自动执行，而且必须设执行上限和熔断机制，比如单次调价幅度超过 5% 就必须人工介入。

归因幻觉是第三个坑。大模型做归因时，会因为训练数据里某些"看似相关"的历史模式，编造出并不成立的因果链。比如某天 ROI 下降，Agent 可能把原因归到前一天的某个运营活动上，但实际原因是数据上报延迟。解决方法是给 Agent 配备"可验证的归因路径"，每一条结论都要落到具体的指标变化和数据表上，不能让它给"感觉性归因"。

最后是峰值性能。百亿补贴大促期间，数据流量的峰值可能是日常的十倍甚至更多，Agent 如果在这个时间点延迟升高或漏消息，业务方就会瞬间失去信任。我之前做过的一个处理是：在 Agent 外面加一层轻量级的规则引擎，负责高优先级告警的秒级响应，复杂的归因分析放到异步队列里处理，不让长任务阻塞实时链路。

3. Physical Intelligence 路线：物理 AI 不只是给机器人装一个大模型

3.1 从 VLA 到动作生成：物理 AI 的技术核心到底是什么

Physical Intelligence 以及它代表的物理 AI 路线，和现在大多数 AI 应用最大的区别在于：它要处理的不再是文本、图片、代码这类数字信息，而是真实物理世界里的连续动作。让一个机器人把桌上的盘子拿起来放到水槽里，这不是简单的"识别盘子"加"移动机械臂"，它需要模型对物体的材质、摩擦力、当前姿态、周围空间关系有综合理解，还要实时生成平滑的、可执行的动作序列。

当前主流的技术框架是 VLA，也就是 Vision-Language-Action 模型。它把视觉输入、语言指令和动作输出统一到一个模型里：视觉编码器负责理解场景，语言模型负责解析任务意图，动作头负责生成电机控制信号。Physical Intelligence 代表性工作在 π0 等系列模型里体现得很明显——它们不把动作当作离散的分类标签，而是当作连续分布来生成，看得出来核心思路追求的是让模型在物理世界的动作输出也能像大模型生成文本一样"流畅自然"。

这个技术选择和单人单步的机器人控制不同，它更像把语言模型的生成范式移植到了动作空间里。你可以粗浅地理解为：语言模型在 token 序列上学下一个词，物理 AI 在状态序列上学下一个动作。所以"动作数据的质量和分布"就替代"文本数据的质量和分布"，成了决定模型能力上限的关键。

3.2 数据从哪来：物理世界没有现成的"互联网语料"

做 NLP 和大模型，我们可以靠全网文本堆积出一个规模惊人的预训练语料库。但物理 AI 没有这么好的条件：让机器人做一万次"拿起杯子"的动作，每次都需要真实的机械臂、真实的杯子、真实的物理环境，这就是物理 AI 数据困局的底层矛盾。

行业里现在主要有几条路来解决这个数据问题。

遥操作采集是目前最可靠的方式。人类操作员通过示教器或动作捕捉设备，控制机器人完成大量真实任务，记录下完整的传感器数据、关节角度和动作轨迹。这样采集的数据质量高，但成本也高得吓人：一个人力一天可能只采几百条有效轨迹，和语言模型动辄上万亿 token 的语料规模完全不成比例。

仿真合成数据是另一个重要补充。在仿真环境里批量生成任务场景、物体布局、物理属性组合，然后自动采集成千上万条训练数据。仿真的问题在于"Sim-to-Real Gap"——仿真世界毕竟是简化过的，摩擦系数、物体形变、光照变化都跟真实世界有差异，模型在仿真里学得很顺，一到真实环境就"见光死"。现在行业里大量工作都在压缩这个 Gap，而不是幻想它能完全消失。

还有一种思路被我个人非常看好，就是利用海量的人类操作视频做预训练。视频数据里包含了大量人类与物理世界交互的信息，虽然缺少精确的力觉和关节数据，但包含了丰富的视觉线索。先用这些视频让模型形成对物理世界的初步理解，再用少量高质量遥操作数据进行精调。这本质上就是"互联网预训练 + 领域微调"这套范式的物理版。

3.3 物理 AI 的落地边界和真实瓶颈

听完技术路线，很多人的第一反应是"那什么时候能真正用上"。我的判断是：物理 AI 已经能在结构化程度较高的任务里跑出可用的效果，但离通用操作还有一段距离。

结构化任务，比如工业场景的抓取、分拣、码垛，这几类任务环境固定、物体种类有限、动作模式重复，物理 AI 已经可以表现出比传统自动化方案更高的泛化能力，换一个不认识的物体也能靠视觉泛化能力抓起来。仓储物流是落地最快的场景之一，因为箱子在传送带上的姿态是可控的，光照是可控的，失败成本也是可控的。

真正难的是开放环境里的非结构化任务。比如家务场景，让机器人收拾一桌刚吃完饭的桌面，盘子上有残留食物，碗会滑动，餐具有可能被埋在纸巾下面，桌布可能不平整——这种"每时每刻都是新情况"的场景，对模型的感知、规划、动作控制都提出极高要求。Physical Intelligence 的演示视频里，很多任务是在受控场景下完成的，这一点我在评估的时候会特别留意。

另外还有一个经常被忽略的成本：安全和可靠性评估。数字世界里一个 AI 模型犯错的代价可能是一次错误回答，物理世界里一个动作出错可能损坏设备甚至伤人。所以在物理 AI 真正大规模部署之前，必须要有完整的风险评估、安全冗余和性能验证体系。

4. 把三条早报串起来看：AI 正在从"建议者"变成"执行者"

4.1 数字世界、数字业务、物理世界：三条线的交汇点

单独看这三条早报容易把它们当作彼此无关的行业动态，但我把它们放在一起看，背后有一条非常清晰的逻辑线。

AI 原生 SDLC 改造的是数字世界的建设方式。传统软件开发是人写需求、人写代码、人测试，现在变成 AI 参与甚至主导交付过程；淘宝百亿补贴的数据 Agent 改造的是数字世界的业务决策方式。传统数据分析给人提供参考，人来拍板，现在变成数据 Agent 给出归因并直接执行动作；Physical Intelligence 则直接把 AI 的触角从数字世界伸进了物理世界。过去 AI 只是"说说应该怎么做"，现在要让机器人真的去做。

这三条线的交汇点在于：AI 的角色正在从"建议者"变成"执行者，并要对结果负责"。以前 AI 的工具形态是聊天机器人、代码补全、推荐系统，它们永远停留在"被调用"的位置；现在 Agent 化的 AI 开始出现在流程的末端——写代码、调预算、操控机器人——直接参与结果产出，也直接承受结果反馈。

这个转变对工程实践的影响是深远的。以前我们评估一个 AI 系统看的是准确率、F1 值这些静态指标，现在要看的变成任务完成率、成功率、修复率、ROI 回归率。以前我们优化的是模型推理质量，现在要优化的是一整套"感知—决策—执行—反馈"的 Agent 闭环。我自己最近半年做 Agent 项目最大的感受是：把模型从 GPT 级别换成更聪明的版本，对最终结果的影响往往不如修好一个工具调用链路、补上一个状态同步、完善一次失败重试来得大。

4.2 作为工程师和产品经理，现在可以怎么跟进

早报看完了总得落点行动，我给几条实操性比较强的建议。

如果你的团队做软件交付，我的建议是从测试生成切进 AI 原生 SDLC。不要一上来就上"需求即代码"的全自动流程，先在测试环节让 AI 生成测试用例和补充边界测试，这个环节反馈客观、风险低、见效快。跑顺之后再把代码生成和测试串成半自动流水线。

如果你在做数据产品，我的建议是先把口径治理和归因图谱做起来，再考虑上数据 Agent。没有这两个地基，Agent 只会放大数据的混乱。初期权限设成"只读归因 + 人工确认执行"，用三个月的稳定运行积累信任和案例库，再逐步放开低风险动作。

如果你关注物理 AI，我的建议是别只盯着模型的 demo 视频，重点看他们的数据采集方案、任务成功率和失败案例。物理 AI 的护城河在数据飞轮和数据质量上，谁能以更低成本采到更高质量的动作数据，谁才有可能在下一阶段胜出。

这三条线需要的核心能力其实是相通的：理解业务目标、拆解任务链路、设计评估体系、治理数据质量。工具和模型更新很快，但这些基本功不会过时。