采用人工智能的最大障碍并不是认知不足。而是谈论人工智能与用它进行构建之间的差距。
主要职责并非编写代码、但日常工作日益依赖AI解决方案的专业人士,不需要工程背景就能开始构建AI能力。他们需要的是合适的工具、结构化的支持,以及失败的许可。下面是我们如何证明这一点的方法,以及你如何复制这一做法。
各组织正在忽视的问题
您的团队已经参与到了关于AI的对话中，无论是回答客户的问题、评估供应商的解决方案，还是在日常职责中发现自动化机会。鉴于代理式AI工具以如此快的速度普遍可用，他们中的大多数人从未用自己正在讨论的工具构建过任何东西。
这些团队,无论身处销售、运营、财务还是产品岗位,都观看过演示并完成了认证。但当有人问“这到底是怎么运作的?”时,他们却给不出那种来自亲手构建过的答案。
成本是真实存在的：采用速度放缓、生产力提升延迟、错失识别用例的机会，以及团队所面临的与……之间日益扩大的脱节。 了解 以及它们能做什么 实现。
我们询问了商业专业人士——那些每天使用AI工具但不编写生产代码的人——是什么阻碍了他们采用AI。答案并不是“我不想学习”。90%的人希望获得构建AI代理的动手实践经验。他们缺少的是安全构建所需的连接组织和支撑框架。下图展示了业务团队在尝试用AI进行构建时面临的最常见障碍。
图1：业务团队在使用AI构建时所列出的主要障碍
从宏观层面来看，他们可以谈论 Amazon Bedrock 和 Amazon Bedrock AgentCore，这是一个可使用任何框架或模型大规模构建、连接和优化智能体的平台（80%的人曾探索过它）。但只有不到1/5的人使用过 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 Regional Services 页面。
行动手册：我们如何设计该计划
以下各节将分解计划的结构、每个阶段以及使其成功的设计决策。
计划结构
该计划为期六周，参与者每周投入大约四小时。我们是有意这样设计的：根据我们的计划数据，完成分阶段计划的参与者所掌握的实用技能是参加两天强化形式参与者的三倍。对于不以编写代码为主要工作的专业人士来说，迭代周期是必要的：有时间在不熟悉的概念中挣扎、恢复，并在信心变得牢固之前再次构建。
阶段 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 智能体，推动团队走向可部署的生产级架构，而不仅仅是本地笔记本。
核心原则从未改变：构建真正可用的东西，让你能在短时间内进行演示。
管理对本职工作的干扰
我们将每周投入时间刻意限制在四个小时，并让参与者灵活安排这些时间。最常见的反馈是，参与者在最初两周内就将所学内容直接应用到了工作中，使这项时间投入感觉是增益性的，而非相互挤占。
结果
以下图表比较了参与者在八项关键指标上项目前后的自我评估，包括AI能力、工具采用情况以及向客户应用所学知识的准备程度。
图2：参与者在项目前后的自我评估
入场时,参与者将“缺乏现实世界实例”列为他们在 AI 方面构建的最大障碍。离场时,自评有信心将 AI 应用于实际用例的参与者比入场前预期的多出 23 个百分点(pp)。参与者在完成该项目时都拥有一个可运行的原型、一个代码仓库以及一套可以立即向利益相关者演示的参考架构。
他们所打造并将带给客户的是：
- 面向医疗保健独立软件供应商(ISV)的多智能体护理协调。
- 内容审核与分流系统。
- 欺诈识别与防范。
- 客户流失预测与预防。
- 面向自主决策的多智能体编排。
- Kiro + Amazon Bedrock AgentCore 客户研讨会演示。
影响：从观察者到建设者
当我们的参与者实际接触到AI工具后，他们从讨论可能性转变为构建可用的原型。数字说明了这一切：
- 自评为对代理型AI具有‘强或专家’级理解的比例：从27%增长到82%（+55个百分点）。
- 感到“准备充分或准备极其充分”以识别AI机会：从41%增加到85%(+44个百分点)。
- 仅有理论或有限经验的参与者：从34%降至0%（已移除）。
以下是投资此项所能解锁的内容：
适用于您的团队： 他们不再只是AI的旁观者，而是成为AI的建造者。通过直接的实验，他们知道什么是可行的、什么是昂贵的、什么是一个周末就能构建出来的。在我们的学员群体中，52%的人找到了能够从他们所构建的东西中受益的具体客户。 期间 该课程，并且87%的学员预计会在30天内将所学应用到客户身上。该课程在实用场景方面超额完成了目标，因为它要求学员自己创建示例。
致你们的工程团队： 当业务伙伴能够构建原型并清晰地阐述架构权衡时，工程团队就可以把更少的时间花在翻译需求上，而把更多时间用于实际构建。技术构建者将获得更清晰的需求输入、更少的错位请求，以及能在单个冲刺启动之前就可行性进行压力测试的合作伙伴。试想：82%的参与者在离开时对智能体AI架构有了深刻的理解。工具熟练度在整个技术栈中大幅提升：Strands Agents SDK的采用率从20%上升到80%（+60个百分点），AgentCore从39%上升到85%，这提高了对工程判断力的要求。
面向您的客户： 他们获得的是通过直接、亲身实践经历过相同架构权衡的合作伙伴。对话从“我回头再答复您”变成了实时演示。在该计划之前，44%的参与者将对架构模式的不确定性视为障碍。该计划之后，90%的参与者感到自己在真实的客户对话中识别AI机会时准备充分或更为从容。
针对您的组织： 你将获得一个可复制且能不断增值的模型。我们的试点项目从一个团队扩展到区域乃至现在的全球部署,印证了这一模式:实践能力的流利度会自我扩展。该计划实现了100%的推荐率,95%的参与者表示该计划达到或超出了他们的预期。
在您的组织中复制这一做法的七条经验
这七条经验总结了该项目成功的原因，以及在您自己的组织中可以复制哪些做法。
1. 工具的选择改变一切
低代码、智能体式的体验消除了“我不够懂技术”这道门槛。这是一个项目设计决策，而不是采购时的事后考虑。如果你的工具要求精通 Python，那么在第一周之前你就已经失去了半数参与者。
2. 结构胜过强度
对于非技术受众，一个设有明确里程碑的分阶段计划(6周)优于为期两天的冲刺。第一周会感觉缓慢，这是正常的。复利效应在其后才会显现。
3. 导师制是乘数
让非技术参与者与技术能力强的导师结对，可以消除对失败的恐惧并加速学习。导师不会替他们构建，而是提供一个安全网。
4. 构建真实的东西
要求提供带有代码仓库和参考架构(而非幻灯片)的可运行原型，能迫使参与者深入使用这些工具。现场演示是无法蒙混过关的。这正是黑客马拉松与培训课程的区别。
5. 前后测量
前后的能力评估能让影响可见,并为扩展提供商业依据。自我报告的信心是有用的,但从“有限”到“丰富”的动手经验转变才是真正重要的。
6. 使其可复制
一份完善的操作手册(参与者指南、评估量规、导师配对框架、环境搭建指南)可以将一次性活动转变为可扩展的项目。
7. 首先营造心理安全感
当人们不惧怕失败时,他们能构建出自己从未想过可能实现的东西。获胜团队将“重在学习而非获胜”列为他们的首要原则。每一个表现出色的团队都在写代码之前建立了信任。
开始使用
操作手册、评估量规和环境搭建指南可供希望复制这一模式的团队使用。请联系其中一位作者,了解更多关于将该框架引入您组织的信息。
了解更多关于 Amazon Bedrock | Kiro IDE | Strands Agents SDK