AWS发布AI-PDLC框架：用六个Quick代理承接产品开发前四阶段
AWS机器学习博客介绍了一套基于Amazon Quick的产品开发代理套件，覆盖发现、决策、设计、原型四个阶段，每一步都要人工批准，产出的规格可交给Kiro或Claude Code等编码代理。
AI解读：AWS机器学习博客于近期发布文章，介绍“AI驱动的产品开发生命周期”（AI-PDLC）框架，作者为Vishnu Elangovan。框架由六个Amazon Quick自定义代理组成，面向产品团队的前四阶段：Discover、Decide、Design、Prototype。
六个代理分工是：Orchestrator统一入口，读取各专家代理的问题框架并分发任务；Discovery生成按严重度和频率打分的痛点看板；Prioritize用 0—10 的两套透明评分框架对用例排序；Working Backwards按亚马逊方法生成PR/FAQ；Spec Generator输出含验收标准、用户流程和约束的构建规格；Designer生成用户旅程图、线框图和可点击HTML原型。
文章称每个阶段都设有人工批准环节：确认痛点、批准优先级、签署规格、把任务交给编码开发、接受评审；代码构建由编码代理依据上游规格完成。代理通过Agent Client Protocol（ACP，开放的JSON-RPC 2.0标准）把任务交给Kiro、Claude Code等编码代理。
使用方式上，整套代理可从GitHub仓库克隆，在Quick Desktop的Customize → Agents → Create from File中创建，并建立一个共享Space存放产物。流程有两种节奏：Deep Discovery每阶段提 8—12 个问题，Fast Track每阶段压缩到 3—5 个问题并给出可直接确认或覆盖的默认值。
文章描述的应用场景包括全新产品开发、现有产品功能追加、缺陷修复与事故驱动改进三类；三者都走同一管道但进入深度不同。文章还称，资源闲置不产生费用；清理时需删除六个代理、Space和连接器。
文中关于提速的说法（如“多周的迭代可能变成数天甚至数小时”）来自AWS博客的表述，未给出公开的效果数据或客户案例指标。
AWS机器学习博客发布文章，介绍一套在Amazon Quick上实现的AI驱动产品开发生命周期（AI-PDLC）框架：六个自定义代理覆盖Discover、Decide、Design、Prototype四个阶段，每个阶段都设有人工批准，最终产出可交给编码代理的构建规格。
六个代理如何分工
用户只与Orchestrator交互。文章称，Orchestrator在运行时读取各位专家代理的问题框架，针对当前阶段提出定向问题，再把产物生成任务分发给对应代理；整条流水线只有在每一步获得人工批准后才会推进。
按文章描述，第一阶段Discovery从交互问答、URL抓取以及Slack、Jira、Salesforce等已连接来源收集信号，按严重度和频率为每个痛点打分，生成痛点看板（Pain Point Board）。第二阶段Decide由Prioritize代理用两套 0—10 评分框架对用例排序：一套面向代理类用例，考量大语言模型能力匹配度、工具可用性和用户接受度；另一套面向传统应用，考量为可行性、业务影响和工作量。随后Working Backwards代理为选中的用例生成完整的PR/FAQ，内部FAQ涵盖单位经济、失败模式、监管风险和竞争格局。
第三阶段Design由Spec Generator代理把用例和PR/FAQ转成包含验收标准、用户流程、约束和元数据的规格，并生成给UX团队的设计交接简报。文章称，验收标准同时充当编码代理遵循的构建契约和评审代理审计所依据的评分标准。第四阶段Prototype由Designer代理在Quick内生成用户旅程图、线框图和可点击HTML原型，用于在投入Figma等设计工具前与利益相关者验证概念。
- Orchestrator：统一对话入口，按阶段分发任务并维护全流程决策日志
- Discovery：按严重度和频率评分，输出痛点看板
- Prioritize：两套 0—10 评分框架，展示用例排序理由
- Working Backwards：按亚马逊方法生成PR/FAQ
- Spec Generator：输出含验收标准的构建规格和设计交接简报
- Designer：生成旅程图、线框图和可点击HTML原型
人工审批介入的位置与交接方式
文章列出的人工审批节点是：确认痛点、批准优先级、签署规格、把任务交给编码开发、接受评审。上游产物汇聚为一份prototype_spec.md，包含验收标准、人物画像、屏幕和数据模型；文章称每个决策都可追溯到来源。
编码阶段交给外部编码代理。文章称，Quick通过Agent Client Protocol（ACP）委派开发任务，ACP是开放的JSON-RPC 2.0标准、不锁定供应商，用户可选用Kiro或Claude Code等编码代理，依据上游生成的规格进行构建。文章把后四个阶段（Engineer、Ship、Operate、Learn）划归编码代理负责，并称生产数据会回流到Discovery。
- 人工闸门：痛点确认、优先级批准、规格签署、构建放行、评审接受
- 交接标准：Agent Client Protocol，开放JSON-RPC 2.0，不锁定供应商
- 交接产物：prototype_spec.md，含验收标准、人物画像、屏幕、数据模型
- 生产数据回流至Discovery，形成闭环
部署方式、节奏与适用场景
文章给出的前提是：已安装Quick Desktop客户端，并具备在Quick中创建自定义代理的权限、配置好Slack、Jira、SharePoint等企业连接器。整套代理指令、问题框架样例和配置文件放在AI-PDLC的GitHub仓库中，在Quick Desktop的Customize → Agents → Create中选择Create from File创建六个代理，再建立一个名为AI-PDLC Artifacts的共享Space存放产物，从代理选择器选中Orchestrator输入“Run the full pipeline”即可启动。
节奏有两种：Deep Discovery每阶段提 8—12 个问题，追问歧义和边缘情况，适合陌生问题空间；Fast Track每阶段压缩到 3—5 个关键问题，并根据已有上下文给出默认值供确认或覆盖，适合时间受限的会话。
文章列出三类场景：全新产品开发走完整流程；现有产品追加功能可从连接工具拉取信号、跳过深度发现；缺陷修复与事故改进可压缩为单个聚焦周期。三者共用同一管道，但进入深度不同。文章称，这套流程创建的资源闲置时不产生费用；清理时需删除六个代理和共享Space、撤销团队访问、断开为此添加的连接器和编码代理链接。
- 部署入口：GitHub仓库提供代理指令、问题框架样例和配置说明
- 创建路径：Quick Desktop → Customize → Agents → Create from File
- 共享产物库：名为AI-PDLC Artifacts的Quick Space
- 两种节奏：Deep Discovery每阶段 8—12 问；Fast Track每阶段 3—5 问
文中未给出的数据
文章关于缩短周期的说法仅限于定性表述，如“过去需要多个sprint的起草和评审可能变成一个聚焦的会话”“多周的原型与迭代可能变成数天甚至数小时”，并注明取决于问题复杂度。文章没有提供客户案例、效率提升比例或缺陷减少等可核验指标，也没有说明该框架在何种规模团队中的实测表现。