AWS 发布「培养 AI 构建者」实战手册：弥合 AI 知识与动手能力的差距

采用 AI 的最大障碍不是认知不足，而是停留在谈论 AI 与真正动手构建之间的鸿沟。

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

组织正在忽视的问题

你的团队早已身处 AI 话题之中——无论他们是在回答客户的问题、评估供应商的解决方案，还是在日常职责中寻找自动化机会。鉴于智能体（agentic）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 秒以内的响应时间，应对复杂的财务推理。

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

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

1. 重学习而非输赢 – 选择具有挑战性的路径而非稳妥的捷径，让他们可以无所畏惧地进行实验。
2. 规律的节奏 – 每日站会避免各自孤立，并能及早发现问题。
3. 从最小可行产品（MVP）开始，再逐步完善 – 在第 2 天实现端到端可运行的流程，然后持续迭代。
4. 积极参与答疑时间 – 遇到困难时主动寻求导师指导。
5. 享受乐趣 – 先营造心理安全感，再谈技术产出。

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

“这次黑客松的时机恰到好处，动手实践的形式对 AgentCore 上手来说弥足珍贵——大大缩短了原本可能漫长的学习曲线。”

“很棒的团队建设和 AI 学习项目！我自学到了很多，也更能共情那些初次接触 AI 解决方案的客户。”

* Amazon Nova 模型已在部分 AWS 区域的 Amazon Bedrock 上提供。有关最新的可用性信息，请参阅 AWS 区域服务页面。

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

以下各节将拆解该项目的结构、各个阶段，以及让它行之有效的设计决策。

项目结构

该项目为期六周，参与者每周投入约四个小时。我们刻意采用这种结构：根据我们的项目数据，完成分阶段项目的参与者所保留的实用技能是参加两天集中式课程的三倍。对于本职工作不写代码的专业人士来说，他们需要迭代周期：有时间在不熟悉的概念中挣扎、恢复，并在信心变得持久之前反复重建。

阶段 0：招募与项目筹备

我们通过经理提名、Slack 和邮件推广来招募参与者，目标是那些日常使用 AI 解决方案但不负责构建它们的专业人士：客户经理、解决方案顾问、运营分析师、项目管理人员及类似角色。首先要获得管理层的支持。我们向团队负责人说明了时间投入（每周四小时，共六周），并将其定位为对流利度和沟通质量的投资，而不是对他们日常交付工作的干扰。

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

阶段 1：组队与启动

参与者需要做什么：组建 3–4 人团队，刻意混合不同经验水平。团队定义一个与其工作中遇到的真实场景相关联的问题陈述。

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

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

阶段 2：赋能培训

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

这一阶段的成果：基础技术熟练度和一个可用的本地环境。

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

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

参与者做什么：在数周内设计和迭代可运行的原型。每个团队都配有一名技术娴熟的导师提供安全网，帮助解决基础设施问题、建议架构模式，但不会代劳。

这一阶段的成果：一个可以向利益相关方或客户演示的功能性原型。

为什么在进入下一阶段之前这很重要：较长的周期允许 2–3 轮迭代。在第 3 周就构建出原型的团队有时间持续应用新学到的知识，推倒重来，并在第 5 周构建出更好的版本。真正的学习正是在这种迭代中发生的。

第 4 阶段：评审与演示

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

这一阶段的成果：经同行验证的能力证明，以及一个可复用原型库。

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

关键设计决策

对于非工程师出身的构建者来说，工具选择是最重要的决策。错误的工具会造成阻碍进展的摩擦，而正确的工具可以抽象基础设施，并从人们当前的专业水平出发。我们选择了：

• Kiro 集成开发环境（IDE）用于自然语言开发：描述你想要的东西，它就会搭建起架构。
• Amazon Bedrock 用于该区域内可通过 API 访问的基础模型：无需机器学习（ML）专业知识即可从模型获得可用的响应。
• Strands Agents SDK 用于可组合的智能体模式：智能体像积木一样组合。
• AWS Model Context Protocol（MCP）服务器和 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 天内将所学应用于客户。该项目在实用用例方面超额交付，因为它要求参与者自己创造这些案例。

对于你的工程组织：当业务 counterparts 能够进行原型设计并清晰阐述架构权衡时，工程团队可以将更少的时间用于翻译需求，把更多时间用于构建。技术构建者能获得更清晰的需求输入、更少的偏差请求，以及在投入任何一个 sprint 之前就能对可行性进行压力测试的合作伙伴。想一想：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 的信息

关于作者