企业官网建设流程全解析

susi_alexa_skill是一个把 AI 聊天机器人 Susi 接入 Amazon Alexa 的技能（Skill）：你说一句 "Alexa, Ask Susi Who Are You"，Alexa 就会调用 Susi 并语音回答你。这个项目的精髓藏在两个小文件里——intent_schema.json 定义了"意图"，sample_utterances.txt 定义了"用户会说哪些话"。本文用一篇语音交互设计指南，带你搞懂这两个关键文件如何决定 Alexa 能否听懂你。

先了解：一次语音请求是怎么被"听懂"的

在 Alexa 技能里，你说的每句话都会经历三步：

1. 唤醒并触发：说 "Alexa, ask Susi ……"，susi就是这个技能的唤起名（Invocation Name）；
2. 意图匹配：Alexa 拿你剩下的话去和"交互模型"比对，判断你要做什么（即"意图 Intent"），并抽出里面的关键词（即"槽位 Slot"）；
3. 后端执行：匹配成功后，请求发往你的服务端，代码取出货槽里的内容去调 Susi 接口。

而第 2 步用到的"交互模型"，就来自项目根目录的两个文件：

关键文件一：intent_schema.json 定义意图与槽位

打开 intent_schema.json，整个文件只有十几行，结构非常直观：

{ "intents": [ { "slots": [ { "name": "query", "type": "AMAZON.LITERAL" } ], "intent": "callSusiApi" } ] }

三个核心概念：

• intent（意图）：这里是callSusiApi，表示"调用 Susi 接口"。当 Alexa 判断你的话属于这个意图时，后端就会执行 handlers.js 中同名函数callSusiApi来处理请求。
• slots（槽位/参数）：意图携带的参数。这里只有一个名为query的槽位，类型是AMAZON.LITERAL，意思是"原样接收一串文本"。你问题中的整句话，都会被塞进query。
• type（槽位类型）：AMAZON.LITERAL相当于字符串，是最灵活也最简单的类型；Alexa 还提供数字、日期、城市名等内置类型，适合需要结构化解析的场景。

💡 设计要点：意图是"动词"，槽位是"宾语"。意图越多越容易混淆，槽位越精准越省心。Susi 技能把所有问题都归为一个callSusiApi意图，用单个query槽位承载全部内容——这正是"聊天类技能"最简洁的设计。

关键文件二：sample_utterances.txt 写出用户的真实话术

意图定义好了，还要告诉 Alexa："用户到底会怎么说？"这就是 sample_utterances.txt 的任务。它的全部内容只有一行：

callSusiApi {query is passed here| query}

这一行语法信息量很大：

• callSusiApi：映射到的意图名，必须与 intent schema 中完全一致；
• {... | query}：花括号内是要捕获的文本片段，竖线后面的query表示"把这段内容放进query槽位"；
• query is passed here：一句示例说法，用来描述"整句话原样传入"这种模式。

效果是：你说 "Alexa, ask Susi what is the temperature in berlin"，Alexa 会命中callSusiApi意图，并把 "what is the temperature in berlin" 完整写入query。

⚠️ 新手常见坑：sample utterances 写得越少、越抽象，Alexa 的识别越依赖默认模式；如果技能功能复杂，建议为每个意图补充多条、覆盖不同语序和口吻的例句，识别率会明显提升。

两个文件如何联动：从语音到 Susi 的回答

配置好交互模型后，剩下的链路已经由代码搭好：

1. server.js 监听 Alexa 发来的请求，判断类型；
2. alexa.js 从请求体中解析出intent（意图名）和slots（槽位值）；
3. handlers.js 用意图名找到对应处理函数，从slots.query.value取出用户问题，拼接成 Susi 的查询地址，请求 Susi 接口后把回答用response.say()说回来。

也就是说：intent_schema.json 负责"听懂"，sample_utterances.txt 负责"认话"，handlers.js 负责"作答"——三者名字必须一一对应，任何一处拼写不一致，Alexa 都会礼貌地表示"没听懂"。

快速验证：用测试模拟器检查识别效果

发布前，强烈建议先在控制台的 Service Simulator 里输入文字测试，例如who are you，观察返回的 JSON 中outputSpeech是否是 Susi 的回答：

如果识别失败，优先按这个顺序排查：

• 意图名不一致：检查 sample utterances 里写的意图名和 intent_schema.json 中是否完全相同（区分大小写）；
• 槽位名不一致：花括号后指定的槽位名，必须和 schema 里slots的name一致；
• 说法覆盖不足：为意图补充更多例句，尤其是用户日常会说的变体；
• 唤起名冲突：确认 Invocation Name 未被其他技能占用。

常见问答 FAQ

Q1：为什么只定义一个意图就够了？聊天类技能的核心是"自由提问"，把整句都装进一个LITERAL槽位是最稳妥的做法，避免意图之间抢话。

Q2：AMAZON.LITERAL和其他槽位类型有什么区别？LITERAL原样接收文本，不做解析；内置数字、日期等类型会做结构化提取，适合"明天天气"这类需要字段拆分的技能。

Q3：改完两个文件要重新部署代码吗？不用。交互模型是在 Alexa 控制台更新的，服务端代码 handlers.js、server.js 无需改动。

总结

回到本文开头的问题：决定 Alexa 能否听懂你的，正是 susi_alexa_skill 中的这两个关键文件——

• intent_schema.json：声明"有哪些意图、带什么槽位"；
• sample_utterances.txt：声明"用户会怎么说、怎么说对应哪个意图"。

理解并写好它们，你就掌握了 Alexa 语音交互设计的核心。项目的完整部署步骤可参考官方说明 README.md，Kubernetes 部署配置在 kubernetes/yamls/ 目录下。