阿里巴巴发布的《AI Native 研发范式实践手册》有 68 页。它从数字投手、千问用增 Agent 和万有无界三个项目写起，随后讨论研发环境、效能度量、数字员工和企业级基础设施。我把原版 PDF 下载下来，逐章对照了本站的 Harness Engineering Playbook。
两份材料在很多判断上相近。我们的 Playbook 从规约、验证、并行协作写到组织治理，适合回答“Agent 开发为什么会失控，以及如何设计闭环”。阿里的三个业务案例让这些原则有了更具体的现场：任务卡在哪个内部系统，谁给 Agent 授权，发布前拿什么证据，最终有没有让需求更快生效。
我还想把自己的 Feature Workflow 放进这次对照。它从 FDD 的特性切片出发，用隔离的执行上下文完成一个 Feature，再用机器可读的验证状态守住合并门禁。阿里手册提出的问题沿着同一条交付链继续向后：代码通过以后，项目能否在干净环境中跑起来，Agent 能否安全地进入发布系统，线上动作凭什么放行。
从需求到可验证的交付，Agent 的每一步都要能接上下一步。
三个案例把闭环落在不同位置
数字投手项目先把“经验、手脚、头脑”分开。工程系统预先计算状态、权限和可操作项，Agent 在限定范围内选择行动。上线后，团队发现技术上能执行的操作，业务效果仍可能不理想，于是用线上漏斗、黄金用例和失败轨迹继续校准。手册报告，策略供给周期从约十天缩短到两天；这个数字反映的是该项目的阶段性实践，不能直接套用到别的团队。
这与 Playbook 的规约定义意图和验证检查输出相互印证。数字投手多走了一步：验证结果进入下一轮策略和能力供给。它提醒我，验收标准如果只停在“功能能跑”，就会错过实际的业务偏差。
千问用增 Agent 的路径更接近研发现场。团队把项目文档、代码图谱和规则组合起来，让 Agent 找到模块和调用关系；需求阶段主动追问隐藏的权限、幂等和一致性决策；编码时用测试给出可重复反馈；线上排障则先收集 Trace、日志、状态和代码位置。手册记录了三个月的交付周期与质量指标变化，但没有给出可用于因果归因的对照实验，因此我更看重它展示的工作方法。
万有无界用真实工程中的交互原型减少评审交接损失，再把缺陷现场和同状态回归连起来。这与 Playbook 让意图能被并行分发的方向一致。团队也写出了一个尚未解决的瓶颈：自动修复的单次成功率提高，并没有让 bug 日清率同步大幅提高。触发、验收和发布仍要跟上，局部效率才可能进入整条交付链。
FDD 帮我确定 Agent 应该交付什么
我在 Feature Workflow 的复盘里把 FDD 的 Feature 定义为一个用户能感知、能独立验收、能在短周期内交付的价值切片。比如“用户可以撤销公开分享链接”是一项 Feature；数据库字段、撤销接口和页面按钮只是实现它的几项工程任务。按技术层拆分后，每个 Agent 都可能宣布自己的部分完成，用户仍然无法完成撤销动作。
阿里手册的案例给了这个判断更现实的参照。数字投手团队把策略发现、策略上线与行动能力补齐交给不同数字员工，并用结构化契约交接；千问用增团队逐步让一个负责人端到端承接单个需求；万有无界则让产品、设计、研发和测试围绕可交互原型与缺陷现场传递事实。三种组织方式不同，交付都需要一个能跨岗位核验的结果。把“某个 Agent 写完代码”当作完成点，会过早结束这个工作单元。
数字员工可以按岗位分工，Feature 仍应按用户价值划边界。拿广告场景举例，一个 Agent 负责发现策略机会，另一个负责实现投放动作；它们的岗位产物可以交接，但“商家能够看到有依据、可执行的优化建议”才适合作为端到端验收对象。这个 Feature 是否成立，需要把策略依据、可操作项、业务围栏和用户可见结果一起检查。这是我用 FDD 视角阅读案例得到的推论，手册没有把数字投手项目命名为 Feature Workflow。
Feature 在我的工作流里还承担三个工程角色。它是上下文单元，Agent 只加载这次变更所需的需求与代码；是隔离单元，分支和 Worktree 收住并发修改；也是恢复单元，任务中断后可以从队列状态、Git 和验证记录继续。大需求被拆成 Feature Map 和依赖 DAG 后，调度器只启动依赖已满足的节点。这样并行数量可以增加，验收边界仍能逐项说清。
阿里手册的 Coding 环境与 Sandbox 章节也让我重新看 Worktree 的位置。Worktree 隔开了文件副本，数据库基线、服务桩、网络策略和短期凭证还需要项目运行环境承接。一个 Feature 在原工程师电脑上通过测试，换一处执行现场也能复现，交付证据才更扎实。我把这层实践整理进了企业执行补遗。
一次触发可以跑完整个周期，失败必须停住
Feature Workflow v3把调度入口、独立 Agent 上下文和具体 Skill 分开。调度器读取队列和依赖，为每个 Feature 创建隔离执行上下文；执行器推进 start → implement → verify → complete；验证与归档结果回写后，下一批依赖节点才会释放。一次触发可以推动整个任务图，单个 Feature 的失败也有明确停点。
后来我复盘这套设计，发现固定阶段太多会拖慢普通需求。现在的路径是 Lite 默认，遇到公共 API、数据库迁移、跨模块依赖、权限或数据一致性风险再升级 Deep。需求充实、规格审查、历史深读和额外 Agent 都按风险启用。无论走哪条路径，Feature 边界、持久状态和质量门要保留。
阿里手册在“环境与验证驱动”一节也批评把 Agent 塞进既有研发流程的每个固定节点。它希望 Agent 能自主获得反馈，按结果调整行动，工作流负责调度、权限、状态、审计和高风险检查。这个判断帮助我确认了轻量化的方向：模型可以自行决定怎样搜索代码、怎样修复一次测试失败；系统要清楚记录当前 Feature、允许的副作用和进入下一状态所需的证据。
尤其不能把失败写成 warning 后继续自动完成。我在复盘中记录过旧策略：验证失败重试两次，仍失败就记日志并进入 complete。修订后，验证阶段写入机器可读的 verification-status；产生 Git 副作用前、合并前各检查一次。测试、类型检查或验收场景失败，证据缺失，checklist 未完成，或存在阻断项，都会停在 needs_attention。--auto 也不能绕过这道门。这个门禁保护的是代码合并与归档的可信度。
阿里的企业现场再次验证了这套思路
把三个案例和基础设施章节连起来读，我更确信 Playbook 与 Feature Workflow 选择的方向。卷一用规约、测试和审查锁定意图；卷二用上下文、并行隔离和多层验证扩大执行规模；卷三把问题带到角色和组织协作。阿里团队在真实业务中遇到的障碍，以及他们建立的企业基础设施，让这些原则有了另一组可观察的实践证据。
| Playbook 与 Feature Workflow 的判断 | 阿里手册中的企业实践 |
|---|---|
| 以用户价值和验收结果组织 Feature | 数字投手围绕策略效果建立线上数据闭环；千问用增让负责人端到端承接需求 |
| 隔离执行，并让任务跨会话恢复 | 云上数字员工协作、任务沙箱和可重建的 Coding 环境保存执行边界与现场 |
| 将权限和副作用写成可执行边界 | Agent 身份、任务委托、短期凭证和资源侧校验控制真实操作 |
| 验证失败时停止状态推进 | Guardrail 将检查规则、当前动作和证据绑定，UNKNOWN 也阻止自动放行 |
| 用交付事实推动工作流演进 | 从会话关联到提交、变更和需求，并把失败轨迹送回评测与能力建设 |
这些对应关系是方向上的互证，不表示两套系统有相同的实现，也不能用一个案例证明所有企业都能得到相同收益。我把阿里手册里值得继续实践的运行环境、生产门控和度量方法整理为 Playbook 的两篇补遗：把 Agent 接进可复现的交付现场与用交付事实衡量 Harness。原有带来源版本的章节保持原文。
两道门禁保护不同的动作
Feature Workflow 的完成门禁已经能阻止未验证的代码进入主干，但代码合并不等于生产动作获准。手册的 Guardrail 案例讨论配置发布批次恢复。规则和本次动作先固定版本，Agent 查询监控、日志与告警，为每个检查项提交证据及 PASS、BLOCKED、UNKNOWN 结果。检查缺失或无法判断时，门控不会自动放行；发布系统在执行前还要重新核对当前状态、权限和目标。
研发验证与生产检查各自控制一道状态转移。
我把两道门放在同一条交付链上看：
| 门禁位置 | 要保护的动作 | 必须确认的事实 | 失败后的状态 |
|---|---|---|---|
| Feature 完成前 | commit、合并与归档 | 验收场景、测试、类型检查、checklist 和验证证据 | 停在 needs_attention，修复后重验 |
| 生产动作前 | 继续发布、修改配置等真实操作 | 当前目标、规则版本、现场证据、身份权限和动作防重 | BLOCKED 或 UNKNOWN 不放行，交给人或重新搜证 |
这两道门可以共用 Feature ID、变更 ID 和证据引用，但判定不能互相替代。功能测试通过，不说明当前生产批次健康；一次生产检查通过，也不证明这项 Feature 满足最初的用户验收标准。手册中的 Guardrail 还固定了规则版本和动作快照，生产状态变化时要求重新判断。五分钟前的监控结果不能无限期授权下一次动作，在一个批次取得的 PASS 也不能放行另一个批次。
这与 Playbook 的三层验证可以形成顺序关系。硬门禁检查结构，软门禁审查块内语义，集成验证检查跨块行为。在把这些机制接入 Feature Workflow 时，完成门可以消费它们的结果，控制是否合并；生产 Guardrail 再消费当前现场的证据，控制是否执行具体动作。越接近外部副作用，门禁越需要绑定时间、目标和权限。
阿里的生产实践也给了 Feature Workflow 一个继续演进的方向。verification-status 可以引用可复跑的测试命令和环境版本；合并后的 Feature 可以关联发布变更；生产检查使用三态结果，证据不足时明确停下；撤权、换目标、换批次后让旧结论失效。这样，研发完成门和生产动作门沿用相同的证据意识，各自控制所在阶段的真实动作。
把前面的广告示例继续走下去，可以看到每一层该留下什么。这是我根据两份材料组合出的示意流程，并非阿里手册中已经实现的同一条流水线：
| 阶段 | Feature 产物与检查 | 下一步的条件 |
|---|---|---|
| 定义 | 商家能查看优化建议；Spec 写明证据、适用条件、不可触碰的预算边界 | 产品负责人确认用户价值和验收场景 |
| 执行 | Agent 在独立 Worktree 修改代码，沙箱提供数据库和广告服务的测试替身 | 代码与环境都能复现 |
| 验证 | 检查建议内容、权限限制、接口契约和用户路径，保存命令与测试结果 | 阻断项为零，verification-status 通过 |
| 合并与发布 | 完成门核对 Feature 证据，发布系统记录对应 Change ID | 代码合并后另起生产检查 |
| 生产动作 | Agent 读取当前批次监控和告警，按固定规则提交三态结果与证据 | Guardrail 放行，发布系统再次校验现场 |
这个例子也暴露了一处容易混淆的“完成”。Feature Workflow 的 complete 目前表示代码合并、归档等研发动作完成；业务结果还要等发布和线上反馈。归档记录可以保留研发完成状态，同时关联后续 Change 与业务观察结果，避免把两个时刻合并成一个完成时间。
度量要能走到需求生效
手册提出把 Session → Commit → Change → Workitem 连起来。会话数和 AI 代码行数可以帮助判断工具是否被使用；变更失败、回滚和恢复时间用于守住质量；需求周期和业务结果才能说明交付是否改善。这里也有一个容易踩的坑：按仓库名把会话、提交、变更和需求直接拼在一起，会重复计数。需要任务与变更的真实关联，缺失关联的样本应单独标记。
Feature Workflow 已经有队列、Feature ID、分支、Worktree、验证状态和归档记录。这些对象可以作为更长证据链的起点。每个 Feature 记录从进入队列到验收通过的时间、验证失败与重试次数、合并时间；发布系统继续关联 Change ID、灰度结果、回滚和最终生效时间。用户价值的验收口径则由产品或业务负责人事先写进 Spec。这样能分别看见 Agent 执行速度、门禁等待、环境准备和发布排队各占了多少时间。
以数字投手项目为例，策略从发现到上线的周期缩短，值得继续追问上线后是否扩大了有效诊断覆盖，错误建议和反向操作是否被压住，客户效果是否持续改善。手册也坦诚，过程指标变好能否转化为留存和长期商业价值仍需归因与实验。FDD 强调用户价值，正好提醒我们把最后一段纳入 Feature 的复盘，并让归档继续关联上线后的结果。
这些判断正在影响我对 SysFactory 的产品设计。它的首版方案让业务专家在工作台描述需求，也可以直接选中预览页面上的组件，附上位置、截图和当前构建版本。分析 Agent 将这些输入整理成带验收条件的任务，建设 Agent 在受控工程环境里修改系统，执行检查、构建、必要的数据迁移与健康检查，再把可运行的预览版本交回工作台。业务专家操作真实页面，决定继续修改或确认版本。
这条工作流把 Feature Workflow 的特性边界和质量门做成用户能感知的产品动作。任务、代码版本、检查结果、预览版本和验收决定要指向同一次变更；验证失败时停止进入待验收状态；确认版本后留下可恢复的记录。页面选点也让“这里要改什么”带上具体界面和版本上下文，减少业务语言到代码位置之间的猜测。SysFactory 目前仍是方案和 MVP 验证阶段，首版先跑通一个业务对象的连续修改与人工验收，生产发布门禁留待这个闭环稳定后再接入。
我接下来会用三个连续 Feature 检查这套产品方向：先改一个页面，再增加前后端能力，最后完成带已有数据的结构变更。每次都要能在新环境复现检查，打开对应的预览版本，并追溯是谁确认了结果。等这条链路跑通，再测量从验收到线上生效的时间，才能判断 Harness 产品化给交付带来了多少实际改善。