超越语音输入：仅通过说话构建软件
Source: Dev.to
TL;DR: Kiro Steering Studio 是一款语音驱动的工具，通过自然对话（而非口述）生成结构化的 Kiro steering 文件。它基于 Amazon Nova 2 Sonic 的双向流媒体技术，将你的语音路由到相应的文件，跟踪未解答的问题，并为你的工作区生成 AI 优化的 Markdown 上下文。本文介绍了它的构建方式、为何它不同于你已经在使用的语音 AI 工具，以及我在此过程中学到的经验。
Source: …
语音正成为开发者工具中的一等接口
语音转文本领域在 2026 年迎来爆发，多个产品竞争让打字变得可有可无。有的把它视为更快的文本输入方式，另一些则用它来驱动 结构化、代理式工作流。
2026 年第一季度开发者的语音 AI 生态
-
OpenAI – Codex
语音是受支持的功能，但范围故意保持狭窄。
官方的 Codex macOS 应用（2026 年 2 月发布）包含语音指令，允许开发者直接在代理界面中说出提示。VS Code 扩展同样支持语音转文本输入指令。在这两种情况下，语音是 提示交付机制：你说出任务，Codex 在隔离的沙箱中执行，并提出 PR。语音界面并未改变交互模型；它仅仅把键盘从循环中移除。 -
Anthropic – Claude
Anthropic 为通用 Claude 应用（移动端 & 网页端）推出了官方 Voice Mode。Claude Code 的语音功能主要基于社区开发的第三方集成。 -
Cursor
Cursor 2.0 引入了官方语音支持。Voice Mode 让你可以用口头指令控制编辑器及其 AI 功能，例如 “打开文件app.ts”、 “提取函数” 或 “将此重构为 async/await”。AI 随后生成相应的补丁。这是超越纯粹听写的有意义一步，因为口头指令可以触发多步骤编辑。 -
SuperWhisper 与 WisprFlow
这两者位于光谱的另一端——通用听写工具，开发者用它们来完成从编写提示到起草文档的所有工作。WisprFlow 以无缝的 “流畅” 体验取胜，自动编辑让听写感觉自然。两者均通过键盘快捷键集成，并在转录方面表现出色。
所有这些工具都验证了同一个洞见：语音比打字更快、更自然。然而，它们都充当 输入机制。
当你使用这些工具来构建软件时，仍然需要进行以下认知工作：
- 将信息结构化为正确的格式
- 保持术语和约定的一致性
- 将内容组织成逻辑章节
你可能说话比打字更快，但仍然是在手动编写 markdown 文件。
Kiro 方向文件到底是干什么的
在解释 Kiro Steering Studio 如何工作之前，先了解一下什么是方向文件以及它们为何重要是很有必要的。简而言之，方向文件通过 markdown 文件为 Kiro 提供关于你的工作空间的持久化知识。这样，你不必在每次聊天时都解释你的约定，方向文件可以确保 Kiro 始终遵循你已经建立的模式、库和标准。
捕获项目上下文的三个核心文件
| 文件 | 用途 |
|---|---|
product.md | 定义 你在构建什么：一句话概述、目标用户、MVP 路径与功能、非目标、成功指标以及领域词汇表。 |
tech.md | 定义 如何构建：前端技术栈、后端方案、认证方式、数据存储、IaC、可观测性以及样式指南。 |
structure.md | 定义 项目组织：仓库布局、命名约定、导入模式、架构模式以及测试方法。 |
手动编写这些文件非常繁琐。Kiro 提供了一个“一键生成”功能，可以在你已有成熟代码库的情况下自动生成它们，但在从零开始构建新应用时，这种情况并不存在。
How Steering Studio Is Different
Kiro Steering Studio 将语音视为 结构化知识生成的接口，而不仅仅是简单的转录。与其手动编写 steering 文件，你可以直接说出你的项目。AI 会提出澄清性问题，探查你可能忽略的细节，并 实时 生成结构正确的 steering 文件。对话本身就成为文档。
Conversational Extraction
你可以进行自然的对话，而不是口述预先结构化的内容。例如：
“我正在使用 React、TypeScript 和 Node.js 为内部工程团队构建一个任务管理应用。”
AI 不会仅仅逐字转录，它会提出你可能未考虑的澄清性问题：
- “你的状态管理方式是什么 — Redux、React Query 还是 Context API？”
- “你如何处理身份验证？”
- “你的测试策略是什么？”
- “身份验证应使用 OAuth 还是魔法链接？”
每个答案都会在对话中不断完善相应的 steering 文件。
Intelligent Routing
AI 能够理解 信息所属位置：
- 提到 “React with TypeScript” 会自动更新
tech.md中的 frontend 部分。 - 描述用户旅程会填充
product.md。 - 说明目录结构会更新
structure.md。
Active Gap Detection
AI 会追踪缺失的内容。如果你尚未指定前端技术栈或命名约定，它会记录未解决的问题并提示你进行补全。当你 answ … (原文内容在此结束；该句故意保留不完整以保持原始材料的完整性).
构建概述
架构分为四个关注点：流式传输、会话管理、状态引导 和 工具处理。
NovaSonicClient：双向音频流
我们应用的核心是与 Amazon Bedrock 的实时双向流式传输，具体使用 Nova 2 Sonic —— Amazon 的语音转语音基础模型。
与传统的请求‑响应流程（先录音、发送一次请求、等待响应，然后批量执行工具调用）不同，Nova 2 Sonic 在你说话的同时处理音频，并在对话过程中交叉执行工具。
传统语音 AI 流程
- 录制全部语音
- 发送完整音频
- 等待响应
- 执行工具调用
- 发送结果
- 等待最终响应
双向流式流程
- 音频持续流式传输——无需等语音结束
- 模型在你仍在说话时就开始响应
- 工具调用在对话进行中发生，而不是之后
- 结果立即返回；模型继续说话
音频缓冲区会排队（最多 220 个块），并以每批五个块的方式处理，以防止流被压垮。当队列在高压下填满时，旧的块会被丢弃，以保持实时响应性。
客户端通过状态机管理会话生命周期——启动、音频内容、提示、工具结果以及优雅关闭——并跟踪已发送的事件。
工具系统：同步执行，交叉于语音
工具调用不会等到你说完才执行。模型可能在描述你的项目时正好说到需要更新产品引导，便会触发 toolUse 事件，获取结果后继续说话。这通过 toolResult 事件处理器实现：
session.onEvent('toolEnd', async (d: unknown) => {
const toolData = d as ToolEndData;
const result = runTool(store, toolData.toolName, toolData.toolUseContent); // Synchronous
await sonic.sendToolResult(socket.id, toolData.toolUseId, result); // Send back to model
});可用工具
| 工具 | 用途 |
|---|---|
set_product_steering | 应用描述、用户旅程、MVP 功能、成功指标 |
set_tech_steering | 前端/后端技术栈、认证、数据、基础设施、约束 |
set_structure_steering | 仓库布局、命名约定、架构模式 |
add_open_question | 记录需要解决的决策 |
resolve_open_question | 用文档化决策关闭问题 |
get_steering_summary | 检查缺失内容 |
checkpoint_steering_files | 持久化到磁盘 |
每个工具的描述都会引导 AI 生成适合 LLM 处理的要点、精确版本、反模式以及文件用途。描述本身就是关键的“秘密酱料”：
const techDescription = `Write in terse bullet-point format. For each field include:
- Exact versions (e.g., "Next.js 14.2" not "Next.js")
- Key conventions to follow
- What NOT to do (anti-patterns)
- Relevant CLI commands where applicable`;SteeringStore: 内存状态与原子写入
该存储在内存中维护 steering 状态，并以原子方式写入磁盘。合并模式（merge 与 replace）决定了更新是扩展已有内容还是直接覆盖。会话状态会持久化到 JSON 文件中以便恢复：
{
"version": 1,
"updatedAt": "2025-01-26T18:30:00.000Z",
"product": {
"appOneLiner": "A task management app for remote teams",
"targetUsers": "Distributed engineering teams"
},
"tech": {
"frontend": "React with TypeScript",
"backend": "Node.js with Express"
}
}重启服务器后，对话将从上次结束的地方继续。
设计决策
在构建过程中我学到的几点：
对话状态比看上去更难维护
首要的挑战是保持对话状态——跟踪已经讨论了哪些主题、还有哪些未完成，以及存储待后续跟进的开放问题。解决方案是使用 状态文件管理系统 并结合 Zod 验证的工具调用。这使得 AI 能在对话中原子化地更新 steering 文件，同时将会话上下文持久化到 state.json 文件，从而在中断后能够恢复。模式（schemas）负责验证结构；状态文件则捕获连续性。
人类在回答前会（长时间）思考
人类的决策往往会在思考架构和技术栈选择时出现停顿。这些停顿可能导致流式会话超时。我们在会话管理器中加入了 keep‑alive timer，它会定期发送信号，在长时间思考的暂停期间保持 Bedrock 连接，而不会提前终止活跃的对话。
工具描述比模式更重要
早期版本只提供了最小的工具描述，却写了详细的 JSON 模式。AI 能正确调用工具，但生成的内容比较通用。解决办法是把 工具描述当作提示：提供具体的格式指导、优秀输出示例以及明确的反模式。模式仍然用于结构验证，但描述决定了质量。简而言之，优秀的提示工程至关重要！
工具执行必须快速
由于我们的工具是同步执行并与语音交错进行的，慢速工具会导致可听到的停顿。所有七个 steering 工具都设计为子毫秒级执行：在内存中更新状态且不阻塞 I/O。文件持久化通过 checkpoint_steering_files() 完成，模型会在自然的对话间隙调用它。如果你添加自定义工具，请保持其快速，或使用异步方式并立即返回确认。
如果你正在构建语音驱动的应用，欢迎告诉我——在下方留言吧！
想尝试 Kiro Steering Studio 吗？代码已在我们的 GitHub 仓库公开：