一、信息流业务遇到的问题及思考

淘宝推荐信息流是在淘宝APP中把“你此刻可能最感兴趣的商品、内容和服务”排成一条可滑动的卡片流，系统按你的兴趣和场景实时排序推荐，主要分为首页信息流和购后信息流（如支付成功、订单详情）。在功能实现过程中，主要遇到了以下两个问题。

1. 迭代效率要求非常高

• 需求多，耗时长：信息流迭代频繁且每个需求全流程耗时平均需要一周时间，还有各种创新项目并行；

平均每个需求需要一周时间

• 技术栈多：购后信息流光前台的技术栈就有iOS、Android、鸿蒙、Weex及DX，一个UI调整可能要涉及到五个端代码的改动；（注：Weex及DX均为大淘宝技术自研的动态化渲染引擎）。
  

2. 协同效率比较低

产品经理变动比较频繁，有着多种卡片模板和无数推荐理由的知识库难以传承；即使到了开发过程中也要反复对焦细节，沟通成本高。（注：产品经理指推荐信息流的功能负责人，制定需求并推进落地，下文简称为“产品”）

业界的方案可以解决我们的问题吗

2024年来各种AI编程工具腾空出世，大大提高了我们的开发效率，但在大部分都是专注于某一垂直领域，无法完全解决我们的问题：

综上，现有工具要么聚焦个体效率，要么局限于原型验证，缺乏面向复杂业务、多端协同、端到端交付的系统能力。我们希望有一个工具可以从需求提出到最终上线能全链路帮助我们完成任务。

二、WaterFlow：通过大模型能力提高信息流产品域下的迭代和协同效率

最终目标：一句话让淘宝推荐信息流需求上线，并把过程的产物沉淀下来。

一个信息流需求从开发到测试，再到最终上线，除关键决策外均由大模型自动完成；产物除了代码，还有 PRD、技术方案、测试报告、数据报告等，作为下一个需求和答疑的上下文。

面向用户：信息流项目的产研团队（含产品、技术、测试、运营等）。

实现路径：先搭建基础链路，然后在需求实战中打磨各个 Agent 的准确性和完整性，建设上下文。

上线效果：上线30+需求，耗时从一周减少到两天以内，部分需求由产品开发，详情请见下文。

一个用户的日常使用（看完就懂WaterFlow）

三、从自然语言到代码发生了什么

1.通过Central Agent协助需求文档及任务生成

为了保证可靠的网络传输，TCP协议会有一个三次握手的过程。而在产研团队里，也有属于产品和开发间的“N次握手”的过程。

三次握手 vs N次握手

产品最清楚一个需求所包含的细节，但是由于信息在传递过程中会丢失或者失真，所以在需求实现过程中，产品与开发会有多轮的需求澄清。如何能保证产品脑中的想法能最还原成仓库的代码呢？我们认为，解决方案的关键在于利用大模型把自然语言生成需求文档和任务，再通过任务生成代码。

在WaterFlow正是如此，产品在左侧输入框把自己的想法输入进去，我们利用大模型的推理能力在右侧生成需求文档和任务这两种产物。

• 两种产物：需求文档和开发任务

OpenAI创始成员Andrej Karpathy在一次演讲中说到“我们正在进入「软件3.0」时代，自然语言在成为新的编程接口，大模型会完成剩下的工作”。我们希望产品的语言成为最高效的编程语言，再利用我们的Code Agent最终实现需求。

2.通过Code Agent协助代码生成

有了清晰明确的开发任务，接着就是把它们交给AI发挥了。代码开发这块我们用的是终端团队自研的Codex，会将任务委托给云端独立的沙盒环境中运行，相当于云端有台Cursor或者Claude Code帮我们写代码。为什么不直接用本地的Cursor开发呢？因为很少产品的电脑上会有Cursor等编程工具，所以我们希望提供一个开箱即用的编程工具，使用者无需关注环境、技术细节。下面会详细介绍其运行环境、上下文以及不同技术栈之间的差异。

何为Codex-云端AI开发服务

Codex是一个在云端沙盒环境可以执行代码开发、仓库问题回答等多种任务的AI服务，有独立的前台应用，也可以通过API方式接入（WaterFlow通过API接入）。

Coding Sandbox：利用Docker容器建立安全沙箱环境，提供代码执行的工作空间，在容器预先克隆仓库并分配给每个代码仓库特定的资源和用户权限。

Code Langgraph Agent：基于LangGraph的AI代理服务，提供代码分析、智能推理以及工具调用的能力，支持代码搜索、文件操作、Shell执行、Git、MCP等各类工具。

LLM：大模型用的是在编程领域表现良好的代码大模型，提供卓越的代码和推理能力，同时更精确地响应用户指令。

三种上下文引导AI正确执行

有了强大的一个AI编码工具Codex，也有了需要执行的任务（提示词），我们如何指挥大模型进行正确的修改呢？这时上下文给大模型提供了一个关键的依据。在WaterFlow中，我们每次任务执行的上下文由三部分组成。

系统上下文：WaterFlow定义的基本规则，不可更改，比如Git操作，获取User Context/Code Context等上下文及最终返回格式等；

用户上下文：每位用户自定义规则，可在系统设置中更改，比如编码习惯、用户画像等；

代码上下文：每个代码仓库相关的资料，存放在代码仓库特定路径下的markdown文件，在任务执行过程中可选择特定的上下文，由代码的所有开发者共同维护，同样可适用于Cursor或Jules等编程工具，包含目录结构、仓库工作流、技术栈等。

如何编写代码上下文可参考业界通用的AGENTS.md的规范，在Github上有两万多个优秀例子，这边是信息流（前端）的部分示例

# @ali/weex-waterfall

## 概述
- 是一个React组件的npm包
- 提供给接入方提供商品推荐信息流的样式和功能

## 技术栈
- 开发语言: typescript
- 样式和渲染主要由React + CSS完成
- Weex2.0提供了基础能力, 比如waterfall组件双列流的排列和动画能力
- Ice3.0提供了脚手架能力, 运行调试及构建

## 启动命令
- 安装依赖：tnpm install
- 开发调试：tnpm run startWeex
- 打包编译：tnpm run build

## 目录结构
|-- src
|   |-- index.tsx                          # 瀑布流实现
|   |-- cards                              # 所有卡片集合
|   |-- components                         # 公用组件
|   |-- hooks                              # 所有hooks集合
|   |-- utils                              # 工具类函数

## 执行步骤
- 先拉取远端分支代码，并切换至主干分支
- 基于主干新建一个分支，并在新分支根据任务修改代码
- 修改完成后，提交commit并将当前分支推送至远端

提示词 VS 上下文提示词（Prompt），告诉模型“怎么做、做到什么样”的指令；上下文（Context），告诉模型“根据什么来做”的材料；两者最终都会被拼成同一段输入给模型。在WaterFlow中，Central Agent根据产品需求生成的各种开发任务属于提示词，每个需求都不一样；而存储在系统或者代码仓库里的内容属于上下文，由开发者维护，每个需求基本一致。

• 不同技术栈流程之间的对比

WaterFlow目前支持前端、后端、客户端（IOS/Android/Harmony）、DX代码共六种技术栈代码的开发，相同的地方在于它们最基本产物都是一个开发好代码的新分支。而每个技术栈在开发的前中后都有一些差异（表格中加粗），为了能增加自动化程度，减少人工干预，我们都尽量通过MCP或者开放接口做相应适配。

四、上线实践效果

自WaterFlow上线近3个月，在信息流业务取得了一定效果，尤其是协同和开发两方面，下面将介绍具体效果和案例。

上线实践效果

协同提效：一次握手

中心 Agent 生成了30个以上的需求文档及任务，占总需求30%，平均耗时 10 分钟，通过WaterFlow生成需求的用户除了有熟悉业务的信息流产品，还有其他不熟悉信息流业务的技术。大大降低了提需求的门槛和沟通成本，从“N次握手”变成“一次握手”。

如此有以下好处：

• 大部分需求附有正确可执行的开发任务，能缩短排期时间，这也是提效的最大原因
• 不用多次询问需求细节，细节都在对话和 PRD 里；并且也能帮助补充需求的细节。

开发提效：more time for everything else

Codex无缝执行开发任务，在云端高效完成工作。上述 Agent 生成的30个需求任务都直接交由Code Agent进行开发，大部分需求完成度达到90%，其中有部分更是由产品直接执行开发任务。节省了以往环境搭建、开发和部署的时间，执行后只需要静静等待结果即可，就像Jules倡导的“More time for the code you want to write, and everything else”。

哪些需求适合完全交给AI执行？

经过实践总结，如果为Codex分配一些新人工程师或实习生在提供充分、清晰的任务下能够完成的需求，那么Codex完成的效果就很好，从中挑选了一些100%代码由AI生成的需求举例：

• 【体验优化】定时上架品前台优化表达
• 【样式调整】引导发布评价卡片评价返现样式优化
• 【配置修改】解析URL参数并更新特定对象
• 【推荐理由】新增88VIP推荐理由字段
• 【增加埋点 】确认收货信息流缓存添加性能点位

代码行数：Java、JavaScript、XML等各类语言生成超过54000行

上下文建设：对前后端及客户端信息流相关仓库的技术栈、目录结构及工作流都有详尽描述，同时总结了信息流最常用DX模板的组件、属性及语法，另外这些上下文都会随着需求数增加而逐步完善。

不同业务的提效案例

五、总结和规划

先回答标题提出的问题，产品能“开发”需求吗？答案是部分需求可以的。借助Waterflow的能力，有效的提高了我们的协同和开发效率。短期来说，我们会继续打磨好各个端的流程；长期来说，我们希望在以下两方面做突破以完成复杂度更高的需求：

• 评估标准：OpenAI Agent 团队负责人认为做好一个Agent产品最关键的要创建正确的评估和评分机制，从评估到生产，再到微调，这是一个强大的循环。我们也希望有一个评估机制，以保证我们的Prompt、上下文及代码生成的效果能不断得到优化。
• 记忆功能：目前在WaterFlow做过的需求都是通过一些机制更新到上下文中，存在一定的局限性。我们希望让Agent 具备持续学习能力，提供更符合用户偏好的个性化服务和体验。

团队介绍

本文作者川封，来自淘天集团-用户终端技术团队。我们服务于淘宝基础用户产品，是淘宝最重要的业务线之一。首页、信息流推荐、消息聊天、搜索、我淘、用增、互动、内容等亿级用户规模产品，为我们带来大量业务/技术挑战及机会。

团队在保证业务的同时，以先进的跨端框架和研发模式不断完善自己，打造最极致的体验和工程技术，保障多端设备的适配和稳定运行，并探索端智能等创新机会，通过技术高效驱动业务的良性发展。持续探索以AI为底座构建从需求到上线的端到端自动化与产品化能力，使亿级规模的交付更快、更稳、更可控。

我们渴望优秀的你一起加入，去打造行业标杆。详情请点击链接：https://talent.taotian.com/off-campus/position-detail?positionId=100001940001&shareCode=8l%2FGMUcSfnicARi9OL4aAjGlku0PpXny5Uv697sCaOGfpOa9IdOAefK4ayJCEBjs

本文视频讲解可在此观看👉【产品经理也能“开发”需求？大厂程序员自救之路，从需求到上线的AI端到端实践-《实战篇》-哔哩哔哩】 https://b23.tv/ybqP7FD

来源  |  阿里云开发者公众号

作者  |  川封