AWS Quick 如何用 AI 驱动生命周期管理（AI-PDLC）加速产品开发

这篇博客文章重点介绍 AI 如何借助基于 AWS Quick 构建的智能体来改进和加快产品开发生命周期，并将人工审批融入流程之中。

AI 驱动的软件交付正在帮助团队以前所未有的速度发布产品。随着实现速度加快，上游的产品开发流程变得更加重要。编码智能体可以比以前更快地把清晰的需求转化为可运行的软件，但它们无法弥补构建错误产品的问题。既然实现变得更加容易，你的竞争优势就转移到了上游的四项关键活动上：发现正确的客户问题、决定追逐哪个机会、设计正确的体验，并通过原型加以验证。

做出这些决策所需的信号散落在各处。你的客户在 Slack 中留下反馈，销售团队在 Salesforce 中记录洞察，系统在 ServiceNow 中记录事故，利益相关者在 Microsoft SharePoint 中撰写需求文档，工程师在 Jira 中跟踪工作项，团队则在 Outlook 会议和邮件往来中做出决策。当团队在这些工具之间切换时，上下文与它本应支撑的决策脱节，并且每次交接都会丢失更多。

AWS Quick 为这些碎片化的知识提供了连接层。通过将自定义聊天智能体建立在连接的企业数据之上，并将其产物存储在共享的 Spaces 中，AWS Quick 帮助你的团队利用现有的组织知识进行构建，而不是每次都从一张白纸开始。

AI 驱动的产品开发生命周期（AI-PDLC）是一个框架，它通过一套包含六个具备专门技能的 AWS Quick 智能体来应用这些能力，在每个阶段产出一组可追溯的产物。智能体收集并整理上下文、发现缺口并起草产物。你和你的团队贡献判断并审批每一项决策。其目标不是更快地产出文档，而是帮助你的团队更好地思考、保留每项决策背后的原因，并为工程团队和编码智能体提供一份以客户证据为基础的规范。我们将向你展示如何在 AWS Quick 中配置这套六智能体 AI-PDLC 套件，并用它从分散的客户信号推进到经过验证的原型。整个过程自始至终保留从最初洞察到工程交接的上下文。

架构

该图展示了 AI-PDLC 框架的端到端流程。

图 1：端到端 AI-PDLC 流程，从分散的企业信号经由 AWS Quick 智能体直至编码智能体交接

它始于大多数团队会忽略的信号，也就是那些承载着决策背后原因以及客户真实所言的 Slack 讨论串、Jira 工单、文档和通话记录。企业连接器从 Slack、Outlook、Jira、Salesforce、SharePoint、ServiceNow 以及更多企业数据源中提取这些上下文。

图 2：AWS Quick 构建一个个人知识图谱，将跨连接应用和文件夹的人员、项目和决策关联起来

AWS Quick 可以根据你连接的应用和文件夹构建个人知识图谱，将工具之间的人员、项目和决策关联起来。

这些信号汇入“大脑”：即 AWS Quick 上的一组智能体，由一个 Orchestrator（编排器）领导，负责运行 Discovery（探索）、Prioritize（优先级排序）、Working Backwards（逆向工作法）、Spec Generator（规范生成器）和 Designer（设计师）。它们产出的一切都汇聚为一种通用语言：一个 prototype_spec.md，其中包含验收标准、用户画像、界面和数据模型。每一项决策都可以追溯到来源。

AWS Quick 可以将开发任务委托给使用智能体客户端协议（Agent Client Protocol，ACP）的 AI 编码智能体。ACP 是一个开放 JSON-RPC 2.0 标准，没有厂商锁定。客户可以使用他们偏好的编码智能体（如 Kiro 或 Claude Code）来根据 AI-PDLC 生成的规格进行构建。

在底层，每个阶段都运行着一个人工审批关卡。您验证痛点、批准优先级、签署规格、把控构建、接受评审。生产数据随后回流到发现（Discovery）阶段，形成闭环。智能体负责执行工作，而由您做出决策，且无需有人离开自己的工具。

解决方案概述

AI-PDLC 生命周期包含八个阶段：发现（Discover）、决策（Decide）、设计（Design）、原型（Prototype）、工程（Engineer）、发布（Ship）、运营（Operate）和学习（Learn）。本文聚焦于产品团队工作的前四个阶段。后四个阶段由 Kiro 等编码智能体处理，它们根据上游阶段产出的规格进行构建。上游阶段在 AWS Quick 中实现为六个智能体。

图 3：上游 AI-PDLC 阶段在 AWS Quick 中实现为六个智能体

用户只需与一个编排器（Orchestrator）交互，它在运行时读取各专家智能体的问题框架，针对当前阶段提出有针对性的问题，并将产出物生成任务分派给相应的专家。一段对话即可驱动整个旅程，且流水线只有在工作流的每一步都获得人工批准后才会推进。

图 4：一段编排器对话驱动流水线，只有在每个关卡获得人工批准后才推进

阶段 1：发现（Discover）

发现智能体（Discovery agent）通过交互式问答、URL 摄取，以及从 Slack、Jira、支持工单、Salesforce 和研究知识库等已连接的企业数据源直接拉取，引导结构化的痛点分析。它对每个痛点的严重程度和发生频率进行评分，生成一个痛点看板（Pain Point Board），让团队从单一且基于证据的视角了解客户面临的困难。

图 5：发现智能体生成一个按严重程度和频率评分的痛点看板

阶段 2：决策（Decide）

优先级智能体（Prioritize agent）使用两个透明的 0–10 分框架，按加权标准对每个用例进行评分：一个专为智能体用例构建（大语言模型（LLM）能力匹配度、工具可用性、用户接受度），另一个用于传统应用（可行性、业务影响、工作量）。团队可以打开评分矩阵（Scoring Matrix），准确追溯一个用例为何排在另一个之前。

图 6：优先级智能体的评分矩阵展示了一个用例为何排在另一个之前

选定最高优先级的用例后，逆向工作智能体（Working Backwards agent）使用 Amazon 逆向工作法生成完整的 PR/FAQ，其中包含客户 FAQ，以及涵盖单位经济效益、失效模式、监管风险和竞争格局的内部 FAQ。如果一个概念经不起这样的审视，团队就会在投入工程资源之前，先在纸面上认识到这一点。

图 7：逆向工作智能体为最高优先级用例生成完整的 PR/FAQ

阶段 3：设计（Design）

Spec Generator 智能体将经过验证的用例和 PR/FAQ 转化为可投入构建的规格说明，为智能体用例与应用用例分别提供模板，并为 UX 团队附加一份 Design Handoff Brief。每份规格说明都包含验收标准、用户流程、约束条件以及元数据，可将每项需求追溯回其来源痛点、优先级评分以及验证它的 PR/FAQ。这些验收标准具有双重用途：它们既是编码智能体遵循的构建契约，也是审查智能体进行审计的评审标准。过去需要多个冲刺周期来起草和评审的工作，现在只需一次专注的会话即可完成，细节足以让工程团队直接依据设计规格进行构建，几乎不需要或完全不需要额外的澄清会议。

图 8：Spec Generator 智能体将经过验证的用例转化为可投入构建的规格说明

阶段 4：原型

Designer 智能体直接在 AWS Quick 内生成旅程图、线框图和可点击的 HTML 原型。它依据 Design Handoff Brief、Discovery 阶段的用户画像、PR/FAQ 中的用户流程、待设计的屏幕、品牌上下文以及从客户引言中提炼的情感目标开展工作，使团队可以在投入 Figma 或其他设计工具之前先与利益相关者验证概念。规格说明获批后，会被分派给工程团队进行开发。

图 9：Designer 智能体在 AWS Quick 内生成旅程图、线框图和可点击的原型

整个流程是迭代的，每个关卡都有人工评审和批准。未经明确签署确认，任何成果都不会交付。传统上需要数周原型制作和迭代的工作，根据问题复杂度的不同，可能只需数天甚至数小时的智能体引导协作即可完成。

每项决策都会在两个层级进行记录。每个专项智能体在其产出的工件中记录自己的决策、评分和依据，Orchestrator 则独立核查这些条目是否存在，同时在整个流水线范围内维护一份共享日志。即使某一层出现疏漏，另一层仍保有完整记录，因此任何关卡审批都不会失去追踪。

AI-PDLC 可以在两种节奏模式下执行。Deep Discovery 在每个阶段提出 8–12 个问题，深入探查模糊之处和边缘情况。它适用于团队希望充分探索的全新问题空间。Fast Track 将每个阶段精简至 3–5 个关键问题，并根据已掌握的上下文建议默认答案，供你逐项确认或覆盖。它适用于团队熟悉该领域、需要快速推进的限时会话。

智能体实现细节：逐步指南

我们将逐步讲解智能体的创建与实现过程。

前置条件

一个安装了桌面客户端的 AWS Quick 工作区。
在 AWS Quick 中创建自定义智能体的权限，并已为 Slack、Jira、SharePoint 或团队使用的其他工具配置好 Enterprise 连接器。

图 10：配置了企业连接器的 AWS Quick 工作区

第 1 步：克隆 AI-PDLC 仓库

完整的智能体套件、参考架构、提示词模板和设置说明均可在此 AI-PDLC GitHub 仓库中获取。

仓库中包含：

全部六个智能体的指令文件。
每个专项智能体的问题框架示例。
配置文件和设置指南。

第 2 步：创建专项智能体

在 AWS Quick 中，使用仓库中的说明创建专项智能体：

第 2.1 步：从用于构建智能体的 GitHub 仓库下载 JSON 文件。

第 2.2 步：前往 Quick Desktop → Customize → Agents → Create，然后选择 Create from File。

图 11：使用 Create from File 在 Quick Desktop 中创建专家智能体

第 2.3 步：聊天窗口随即打开。

图 12：智能体创建过程中打开的聊天窗口

第 2.4 步：将创建以下六个带有指令的智能体：

图 13：创建的六个 AI-PDLC 智能体及其指令

Orchestrator 是核心架构组件。它会在运行时动态读取每位专家的指令：

图 14：Orchestrator 在运行时动态读取每位专家的指令

第 3 步：配置 Quick Spaces（产物仓库）

创建一个共享的 Quick Space 用于存储流水线产物：

打开 Quick Spaces 并选择 Create New Space。
名称：AI-PDLC Artifacts。
Grant access to relevant team members.
图 15：创建 AI-PDLC Artifacts Space 并向团队成员授予访问权限

第 4 步：运行流水线

打开 AWS Quick Desktop。
从智能体选择器中选择 AI-PDLC Orchestrator。
输入：“Run the full pipeline”（如需简化会话，可输入“Fast Track”）。
在 Orchestrator 引导你完成每个阶段时，回答其结构化问题。
Review artifacts as they are produced at each gate.
图 16：运行流水线，并在每个关卡产生产物时对其进行审查

图 17：使用 AI-PDLC Orchestrator 启动流水线运行

你可以根据自身需求选择节奏：Deep Discovery 或 Fast Track。

图 18：根据自身需求选择节奏，Deep Discovery 或 Fast Track

观看实际演示

如需观看 AI-PDLC 的实际演示——从客户洞察出发，历经全部四个阶段直至可运行的原型——请观看我们的 YouTube 视频演示：

视频内容包括：

搭建智能体套件。
通过一个真实用例运行完整的 Orchestrator 流水线。
实时产生产物的实际效果。
向编程智能体进行 ACP 交接。
在 Deep Discovery 和 Fast Track 模式之间进行选择的技巧。

AI-PDLC 场景

我们将介绍一些可以应用 AI-PDLC 框架的常见场景：

场景 1：从零开始的新产品开发

当团队发现新的市场机会或未被满足的客户需求时，他们会面临经典的冷启动问题：信号分散、想法相互竞争，且没有从洞察走向行动的结构化路径。AI-PDLC 引导团队完成完整的上游旅程，从真实的客户数据中挖掘痛点，并依据透明标准对相互竞争的想法进行评分。它还通过严谨的 PR/FAQ 验证概念，并产出一个可供构建的规格说明，使第一行代码是基于经过验证的计划而非直觉编写的。

场景 2：为现有产品添加功能，由路线图驱动或由客户驱动

产品团队持续接收各类信号，以决定下一步构建什么：支持渠道中的客户反馈、销售部门转来的功能需求、显示流失节点的使用数据，或来自管理层的战略优先级。AI-PDLC 通过从关联工具（Slack、Jira、Salesforce、AWS Quick Sight）中提取这些信号来加速这一过程。该框架将这些信号结构化为一个经过优先级排序的待办事项列表（backlog），并采用有据可依的评分方式，同时生成一份保留每个功能背后“为什么”的规格说明，让工程团队接收到上下文丰富的工作项，而不是被剥离了意图的一行式 Jira 工单。

场景 3：Bug 修复和事件驱动的改进

当生产问题通过客户投诉、监控警报或支持升级浮出水面时，应对方式往往是跳过结构化分析，直接进行代码修复。AI-PDLC 为这种被动响应式工作流带来了纪律性：它将根本原因记录为痛点，并评估该修复是值得进行更广泛的设计变更，还是只需一个针对性的补丁。它会生成一份范围明确、带有可测试验收标准的规格说明，使修复能够解决根本问题而不仅是表面症状，同时完整保留决策轨迹以供日后参考。

每个场景都遵循相同的流水线（发现 → 决策 → 设计 → 原型），但进入的深度各不相同。新产品需要走完整个流程，功能新增可以跳过深度发现，Bug 修复则可压缩为一个聚焦的单一周期。方法论会灵活调整，而审计轨迹和治理机制始终保持一致。

清理

本演练所创建的资源在闲置状态下不产生任何费用，因此如果您计划再次运行该流水线，可以放心保留整套 AI-PDLC 套件。

要删除不再需要的资源，请在 Quick Desktop 中的Customize → Agents 下删除六个智能体，删除AI-PDLC Artifacts Space（或仅删除其中的测试工件）并撤销您授予的任何团队访问权限，断开任何仅为本次练习添加的 Enterprise 连接器或编码智能体链接。您还可以从本地计算机上删除克隆的 GitHub 仓库。

结论

产品开发的瓶颈已经发生转移。编码智能体让实现变得快速。然而，上游工作仍然制约着团队：发现客户问题、决定构建什么、验证概念以及产出清晰的规格说明。能够压缩这一上游周期的团队可以获得复利式优势：更快地构建正确的产品，并减少代价高昂的方向调整。

AI-PDLC 直接解决了这个问题。它提供了一个结构化、AI 原生的框架，作为 AWS Quick 中的一套智能体实现，引导产品团队完成发现、决策、设计和原型四个阶段，并在每个关卡内置治理机制。AI-PDLC 为每个决策提供归因，每个工件都能追溯到客户证据。当规格说明交付给工程团队时，它携带着完整的上下文：它为何存在、由谁验证，以及“完成”的标准是什么。

产品团队的角色不是编写代码，而是快速、可追溯地对构建什么以及为什么构建做出正确的决策。AI-PDLC 正是让这成为可能。

立即开始

克隆该仓库。
按照仓库中的设置指南创建五个专家智能体和一个 Orchestrator。
从智能体选择器中选择“AI-PDLC Orchestrator”，然后输入：“Run the full pipeline”。