AWS 如何用六周项目弥合 AI 知识与应用能力差距

AI 落地的最大障碍不是认知不足，而是从谈论 AI 到真正动手构建之间的鸿沟。

那些主要职责并非编写代码、但日常工作越来越依赖 AI 解决方案的专业人士，并不需要工程背景就能开始构建 AI 能力。他们需要的是合适的工具、结构化的支持，以及允许失败的许可。以下是我们如何证明这一点，以及你如何复制这一做法。

组织正在忽视的问题

你的团队早已身处 AI 对话之中，无论是回应客户提问、评估供应商方案，还是在日常职责中识别自动化机会。鉴于智能体 AI 工具的普及速度，他们中的大多数人从未用自己正在讨论的工具构建过任何东西。

这些团队，无论身处销售、运营、财务还是产品部门，都看过演示、完成了认证。但当有人问“这实际上是怎么运作的？”，他们无法给出那种只有亲手构建过才能拥有的答案。

代价是真实的：更慢的采用速度、被延迟的生产力提升、错失的用例识别机会，以及团队所了解的与他们能够实现的之间日益扩大的脱节。

我们询问了那些每天使用 AI 工具但不编写生产代码的业务专业人士，是什么阻碍了他们采用 AI。答案并不是“我不想学”。90% 的人希望获得亲手构建 AI 智能体的经验。他们缺少的是安全构建所需的连接组织和脚手架。下图展示了业务团队在尝试用 AI 构建时面临的最常见障碍。

图 1：业务团队提到的用 AI 构建的主要障碍

从宏观层面看，他们能谈论 Amazon Bedrock 和 Amazon Bedrock AgentCore——一个可用任意框架或模型大规模构建、连接和优化智能体的平台（80% 的人探索过它）。但不到五分之一的人接触过 Strands Agents SDK 或用 AWS Lambda 智能体构建过。他们选择不参加黑客松和构建活动，因为不相信自己的技术知识足以与工程师同台竞争。

为解决这一问题，我们设计了一个为期六周的结构化项目，将业务专业人士与导师和生产级工具配对，构建可运行、且能在项目结束后继续扩展的 AI 原型。目标：弥合概念知识与动手能力之间的差距。

一个团队构建了什么：六周内的证明

四位此前从未合作过的面向客户的专业人士参加了我们的项目。他们都没有工程背景。六周后，他们展示了原型 WealthWise——一个多智能体 AI 财务顾问工具，并赢得了第一名。

他们构建的内容：

五个专业 AI 智能体，提供智能财务顾问服务：投资组合分析、风险评估、财务规划、市场洞察和个性化投资建议。
双服务器架构（Node.js + Python Flask），采用 Amazon Nova 模型。*
Strands Agents SDK，用于多智能体编排和对话记忆。
四个 Amazon DynamoDB 表，用于实时数据持久化。
实时市场数据集成，用于情境感知的财务建议。
5 秒以内的响应时间，用于复杂的财务推理。

该系统具备协同决策能力：每个智能体独立决定调用哪些工具，并将多个工具串联起来，在投资组合数据、市场数据库和财务规划模型之间进行多步推理。

他们将成功归功于第一天就确立的五项原则：

学习优先于获胜——选择有挑战性的方法而非安全的捷径，让他们能够无所畏惧地尝试。
固定的节奏——每日站会防止了孤立，并能及早发现问题。
从最小可行产品（MVP）开始，然后迭代完善——第2天就实现端到端流程，然后迭代。
参与答疑时间——遇到困难时主动寻求指导。
享受乐趣——心理安全感先于技术产出。

参与者回顾了这种动手实践的形式如何加速了他们的学习：

“黑客松的时机恰到好处，动手实践的形式对AgentCore赋能来说价值非凡——加速了原本可能漫长的学习曲线。”

“很棒的团队建设和AI学习项目！我自学了很多，也对刚接触AI解决方案的客户多了一份同理心。”

* Amazon Nova模型已在部分AWS区域的Amazon Bedrock上提供。如需了解最新可用情况，请参阅AWS区域服务页面。

行动手册：我们如何设计这个项目

以下章节将拆解项目结构、各个阶段，以及使其奏效的设计决策。

项目结构

该项目为期六周，参与者每周投入约四小时。我们这样设计是有意为之：根据我们的项目数据，完成分阶段项目的参与者所保留的实用技能，是参加为期两天密集型培训者的三倍。不以写代码为主要工作的专业人士需要迭代周期：有时间去琢磨陌生的概念、恢复调整，然后再次构建，直到信心变得持久。

阶段0：招募与项目设置

我们通过经理提名、Slack和电子邮件活动招募参与者，目标人群是每天接触AI解决方案但不亲自构建它们的专业人士：客户经理、解决方案顾问、运营分析师、项目经理及类似角色。首先获得管理层的支持。我们向团队负责人说明了时间投入（六周内每周四小时），并将其定位为对流畅度和对话质量的投资，而不是对日常交付工作的干扰。

该项目由四名核心团队成员以及导师共同组织，他们在本职工作之余推进此事。这是一个关键的可复制性要点：这不需要一个专职的项目团队，但确实需要至少一个人拥有足够的组织信任度来保护参与者的时间。

阶段1：组队与启动

参与者做什么：组成3–4人的团队，有意混合不同经验水平。团队定义一个与他们角色中遇到的真实场景相关的问题陈述。

这会产生什么：一个可演示的、范围明确的项目概念，以及团队问责结构。

为什么在继续之前这一步很重要：如果没有具体的问题要解决，赋能课程就会变得抽象。先定义目标用例的团队会带着目的去吸收技术内容。

阶段2：赋能

参与者做什么：参加关于智能体 AI 概念和 AWS 工具的实时培训课程。这些不是讲座。参与者在构建阶段实际使用的工具中进行操作，完成与其项目工作相对应的结构化练习。

这会产生什么：基础技术熟练度和可用的本地环境。

为什么在继续之前这很重要：直接跳到构建阶段的团队会在环境设置和基础概念上碰壁。这一阶段避免了最常见的流失点。

第三阶段：构思、构建与开发

参与者做什么：在数周内设计并迭代可用的原型。每个团队都配有一位技术娴熟的导师，提供安全网，解决基础设施问题并建议架构模式，但不替他们完成工作。

这会产生什么：一个可以向利益相关者或客户演示的功能性原型。

为什么在继续之前这很重要：延长的时间线允许 2–3 个迭代周期。在第 3 周构建了原型的团队有时间不断应用新知识、推倒重来，并在第 5 周重建得更好。真正的学习就发生在这样的迭代中。

第四阶段：评审与演示

参与者做什么：进行现场演示，从五个类别进行评估：业务影响、技术卓越、可复用性与可扩展性、创新以及演示质量。

这会产生什么：同行验证的能力证明和一个可复用原型库。

为什么这很重要：演示形式模拟了参与者与客户、领导层和跨职能合作伙伴进行真实对话时的场景。评审标准强调，能运行还不够。它必须有影响力、可扩展，并且能够清晰地传达。

关键设计决策

对于非工程师的构建者来说，工具选择是最重要的决策。错误的工具会造成摩擦，阻碍前进的势头。正确的工具则能抽象基础设施，并在人们当前的专业水平上与他们对接。我们选择了：

Kiro 集成开发环境（IDE）用于自然语言开发：描述你想要什么，它就会搭建架构。
Amazon Bedrock 用于该区域可用的 API 可访问基础模型：无需机器学习（ML）专业知识即可从模型获得可用的响应。
Strands Agents SDK 用于可组合的智能体模式：智能体像积木一样组合。
AWS Model Context Protocol (MCP) servers 和 AWS Lambda 智能体，推动团队走向可部署的生产级架构，而不仅仅是本地 notebook。

核心原则从未改变：构建真实的东西，让你可以在短时间内进行演示。

管理工作日干扰

我们有意将每周投入时间限制在四小时，并让参与者灵活安排这些时间。最常见的反馈是，参与者在头两周内就将所学直接应用到工作中，使时间投入感觉是增益而非竞争。

结果

下图比较了参与者在项目前后在八项关键指标上的自我评估，包括 AI 能力、工具采用以及与客户应用所学知识的准备度。

图 2：参与者在项目前后的自我评估

一开始，参与者将“缺乏真实世界案例”列为使用 AI 构建的最大障碍。结束时，相比项目开始时的预期，对将 AI 应用于实际用例感到自信的参与者多出 23 个百分点（pp）。参与者离开项目时带有一个可运行的原型、一个代码仓库，以及一个可以立即向利益相关者演示的参考架构。

他们构建了什么，并将带给客户：

面向医疗健康独立软件供应商（ISV）的多智能体护理协调。
内容审核与分诊系统。
欺诈识别与预防。
客户流失预测与预防。
用于自主决策的多智能体编排。
用于客户研讨会的 Kiro + Amazon Bedrock AgentCore 演示。

影响：从旁观者到构建者

当我们的参与者获得对 AI 工具的动手访问权限后，他们从讨论可能性转向构建可运行的原型。数字说明了这一点：

自评对智能体 AI 的理解为“较强或专家级”：从 27% 增至 82%（+55 pp）。
感觉“准备充分或极其充分”以识别 AI 机会：从 41% 增至 85%（+44 pp）。
仅有理论或有限经验的参与者：从 34% 降至 0%（已消除）。

以下是投资于此所释放的价值：

对你的团队：他们不再是 AI 旁观者，而成为 AI 构建者。通过直接实验，他们知道什么是可行的、什么是昂贵的，以及什么是周末就能构建出来的。在我们的队列中，52% 的人确定了可以从他们在项目期间构建的东西中受益的具体客户，87% 的人预计在 30 天内将所学应用到客户中。该项目在实际用例方面超出预期，因为它要求他们自己创建这些案例。

对你的工程组织：当业务对口人员能够制作原型并阐明架构权衡时，工程团队花在转化需求上的时间更少，花在构建上的时间更多。技术构建者获得更清晰的输入、更少不一致的请求，以及能够在承诺任何一次冲刺之前对可行性进行压力测试的合作伙伴。想想看：82% 的参与者离开时对智能体 AI 架构有了深入理解。工具熟练度在整个技术栈中激增：Strands Agents SDK 的采用率从 20% 升至 80%（+60 pp），AgentCore 从 39% 升至 85%，从而提高了工程判断的标准。

对你的客户：他们得到的是通过直接动手经验，已经走过他们正面临的相同架构权衡的合作伙伴。对话从“我回头再答复你”转向实时演示。在项目之前，44% 的参与者将架构模式的不确定性列为障碍。项目之后，90% 的人感觉准备充分或更好，能够在真实客户对话中识别 AI 机会。

对你的组织：你得到一个可复制且能产生复利效应的模式。我们的试点从一个团队扩展到区域，再到如今的全球部署，展示了这一模式：动手熟练度会自我扩展。该项目实现了 100% 的推荐率，95% 的参与者表示项目达到或超出预期。

在你的组织中复制这一做法的七条经验

这七条经验总结了该项目成功的原因，以及在你自己的组织中应复制的内容。

1. 工具选择改变一切

低代码、智能体化体验消除了“我不够技术”的障碍。这是程序设计决策，而非采购时的附加考虑。如果你的工具要求熟练使用 Python，那么在第一周之前你就已经失去了一半的人。

2. 结构胜过强度

对于非技术受众而言，一个分阶段的项目（6 周）配有明确的里程碑，效果优于两天的冲刺。预计第一周会感觉进展缓慢。复利效应在之后才会显现。

3. 导师制是倍增器

将非技术参与者与技术娴熟的导师配对，可以消除对失败的恐惧并加速学习。导师不为他们代劳。他们提供的是安全网。

4. 构建真实的东西

要求提交可运行的原型，并附带代码仓库和参考架构（而非幻灯片），这会迫使参与者深入使用这些工具。你无法在实时演示中蒙混过关。这就是黑客马拉松与培训课程的区别所在。

5. 前后都要衡量

前后能力评估让影响可见，并为扩展构建商业论证。自我报告的信心有用，但从“有限”到“广泛”的实操经验的转变才是关键。

6. 使其可复制

一份记录完善的行动手册（参与者指南、评估量规、导师配对框架、环境搭建指南）能将一次性活动转变为可扩展的项目。

7. 首先建立心理安全感

当人们不害怕失败时，他们就能构建出自己从未想过可能的东西。获胜团队将“学习胜过获胜”列为首要原则。每一个蓬勃发展的团队都在写代码之前先建立了信任。

开始行动

行动手册、评估量规和环境搭建指南可供希望复制这一模式的团队使用。请联系作者之一，了解如何将这一框架引入你的组织。

了解有关 Amazon Bedrock | Kiro IDE | Strands Agents SDK 的更多信息

关于作者

Alicia Retzlaff

Alicia 是一位资深技术领导者，拥有 20 多年推动业务转型和客户成功的经验。她目前是 AWS 的高级领导者，专注于 ISV、数据与分析以及 GenAI 解决方案，领导一支云转型策略师团队，负责超过 50 亿美元的年投资组合。她此前曾在 Very Good Security 和 Upland Software 担任总监职务。Alicia 将战略愿景与真诚的领导力相结合，通过以人为本的方法和创新解决方案创造可持续的商业成功。Alicia 持有 3 项 AWS 技术认证——数据工程、云从业者和 AI 从业者。

Imaan Tariq

Imaan 是 Amazon Web Services (AWS) 的客户解决方案经理，她与 ISV 合作，推动复杂的迁移、现代化和 AI 创新之旅。她专注于引导客户走完整个生成式 AI 生命周期，从早期用例构思到生产就绪的解决方案，通过亲身协作和技术好奇心建立深厚的信任。作为活跃的 GenAI 大使，Imaan 不断尝试新兴的 AI 工具和框架，为客户突破可能性的边界。她毕业于圣何塞州立大学软件工程专业，持有四项 AWS 认证：解决方案架构师助理、云从业者、AI 从业者和开发者助理。

Patricia Laszlo

Patricia 是 Amazon Web Services (AWS) 的高级 ISV 客户解决方案经理。她与独立软件供应商紧密合作，帮助他们在 AWS 上构建、扩展和进入市场，为合作伙伴及其客户推动战略成果。

Sara Golon

Sara 是 Amazon Web Services (AWS) 的高级客户解决方案经理，她与企业组织合作，加速云采用、AI 创新和现代化举措。在加入 AWS 之前，她花了二十多年时间领导技术项目，并在复杂的企业环境中交付大规模 IT 解决方案，使她对业务和技术挑战都有深刻理解。Sara 热衷于帮助客户将大胆的想法转化为实用、可扩展的解决方案和持久的业务成果。