Kiro小应用开发：设计和实现隐私号码

去年笔者曾经设计过隐私号码、隐私邮箱、网址短链三个小应用，使用亚马逊云科技的Amazon Connect，DynamoDB，Amazon SES，Lambda，CloudFront等服务构建。在设计方案时，我查找了不少文档和网上资料，来选择合适的服务，完善架构。在将方案设计好后，由Claude协助完成Lambda代码（当时是Claude 3 Sonnet），并手动完成其它的服务的配置。方案使用上述的Serverless服务，有成本可控和运维压力小的优点，在某个电商客户部署后得到好评。

在Kiro推出后，其Specs模式令人印象深刻。需求分解，方案设计，甚至是应用部署，这些原来需要人来主导的工作，现在是否可以由Kiro来完成？这里我将使用Kiro来重新开发隐私号码项目，看看在Specs加持下能否将所有的工作都由Kiro来完成。

1.什么是虚拟号码？

虚拟号码使用单独创建的号码来代替真实号码，为用户提供一个额外的身份，能够有效的保护真实联系信息：

1. 保护隐私：在不暴露个人真实联系方式的情况下与第三方沟通。
2. 身份管理：为不同的身份或活动使用不同的联系方式。
3. 安全性：降低个人信息被泄露或滥用的风险。

虚拟号码可以有不同的形态：

1. 正常普通号码（与普通号码一样，运营商预留的专用号段）。当呼叫这个号码时，自动转接到绑定的真实号码。这种方式在网约车、外卖等场景有广泛的使用。因为号段资源是有限的，这种虚拟号码一般有时效限制，在服务完成后一段时间会解除该虚拟号码与真实号码的绑定。
2. 指定号码呼叫+输入短号（分机号）。指定号码是正常普通号码。当呼叫指定号码后，会自动接通并收到输入短号/分机号的提示，输入短号后再转接到真实的号码。这种方式只需要少量的普通号码，通过生成不同的短号关联到不同的真实号码，能够持久的使用或根据需求自定义任意的有效时间。

在接下来的内容中，我将测试由Kiro来完成整个短号方案的需求分解、方案设计、开发、和部署。

2.体验Kiro SPEC模式的魅力

Kiro具体的介绍可以参考官网（https://kiro.dev/），另外推荐由社区整理的Book of Kiro（https://kiro-community.github.io/book-of-kiro/）。

进入Kiro后，使用SPEC模式，输入如下需求：

我想设计一个虚拟号码应用，当用户拨打某个号码时，会自动播报提示用户输入短号。输入短号后，自动转接到接听方真实的号码。使用AWS的服务设计一个解决方案，尽可能使用Serverless服务。

Kiro开始方案的设计，生成需求文档requirements.md，针对需求完成设计文档design.md。在确认设计方案无误后，进一步的生成实施计划文档tasks.md。

图1 SPEC模式从创建规范需求开始

在生成这几个SPEC模式的文档时，需求的总结和方案的设计让我眼前一亮，输出的工作流程和mermaid流程图与原先我设计的方案思路完全一致，并额外有一些易用性和可维护性的增强：

1. 考虑了通话记录存储、日志记录功能。方便查询通话统计和异常事件
2. 设计了增/删/查/改API接口

原来方案在添加短号-真实号码的映射关系时，需要将映射记录手动导入到DynamoDB，删查改等功能也是直接到数据库中操作，只适合开发人员使用。而Kiro的设计更像一个完整的方便易用的生产系统，添加这些运维接口后，任务人员都可以通过Web界面直观的维护。相关的记录和日志功能，也为进一步拓展业务场景打下了基础。

Kiro设计文档比较完整的介绍了工作流程和架构，节选部分内容和加架构图如下：

虚拟号码路由应用采用AWS Serverless架构，以Amazon Connect为核心的电话服务平台，结合Lambda函数处理业务逻辑，DynamoDB存储配置数据，实现高可用、自动扩展的电话转接服务。

系统的核心工作流程：用户拨打虚拟号码 → Connect接听并播放提示音 → 收集用户输入的短号 → Lambda查询映射关系 → 发起转接到真实号码 → 建立通话桥接。

图2 设计文档在design.md中的流程图

Kiro SPEC模式通过Requirement-Design-Task这个流程，利用AI将一句简短的模糊需求，变成一份结构清晰、条理清楚的规范文档。通过Requirements明确要做什么，通过Design规划如何实现，通过Implementation将整个项目分解为可执行的开发任务，指导LLM不偏离不失控。

在生成初始Design设计文档后，我添加了一个“支持CDK部署”需求，Kiro更新了需求文档和设计文档，之后转到实施计划阶段，生成开发任务

实施计划出炉后，Kiro最终的总结输出节选如下：

完美！虚拟号码路由应用的规格说明现在已经完成。我们已经成功创建了：

✅ 需求文档 - 包含7个详细需求，涵盖语音提示、短号输入、自动转接、管理功能、监控日志、可扩展性和CDK部署

✅ 设计文档 - 完整的AWS Serverless架构设计，包括Amazon Connect、Lambda、DynamoDB、API Gateway和CloudWatch的集成方案

✅ 实施计划 - 15个渐进式开发任务，从基础设施搭建到最终部署验证

现在你可以开始执行这些任务了。你可以：
1.	打开tasks.md文件，点击任务旁边的"Start task"按钮开始执行
2.	从任务1开始，按顺序逐步实现整个系统
3.	每完成一个任务，我建议先测试验证再继续下一个

这个规格说明为你提供了一个完整的、基于AWS Serverless服务的虚拟号码路由解决方案的实现路径。整个系统将具备高可用性、自动扩展能力，并且支持CDK自动化部署。

在进入任务执行前，我让Kiro 结合Specs三个文档（requirements.md, design.md, tasks.md），更新了Steering。

3.完善的上下文管理Steering

简单的理解Steering，就是每个Task执行时都会注入的上下文内容。统一的上下文，能够控制LLM在执行不同Task开发任务时始终遵循相同的模式、库和标准。

Streering文件可以自定义手动创建，在Kiro面板中Steering部分创建.md文件即可，使用标准的markdown语法编写。在本项目开发中，我让Kiro自己调用LLM，结合Specs文档来完善。它自动创建了三个文档，分别是：

• 产品概述 (product.md) – 定义产品的目的、目标用户、关键功能和业务目标。这帮助 Kiro 理解技术决策背后的”为什么”，并建议与您产品目标一致的解决方案。
• 技术栈 (tech.md) – 记录选择的框架、库、开发工具和技术约束。当 Kiro 建议实现方案时，它会遵从这些选择。
• 项目结构 (structure.md) – 概述文件组织、命名约定、导入模式和架构决策。

节选Kiro自己输出的Steering内容总结：

product.md 更新
•	添加了中文产品描述，体现项目的中文业务背景
•	详细描述了通话流程功能（语音提示、DTMF输入、智能转接等）
•	补充了管理功能（短号映射管理、通话记录追踪、实时监控等）
•	明确了技术特性（自动扩展、多语言支持、基础设施即代码）
•	添加了数据流架构和部署架构说明

tech.md 更新
•	详细描述了AWS服务架构（Connect、Lambda、DynamoDB等）
•	添加了Lambda函数的具体功能和配置
•	补充了DynamoDB表结构和设计
•	扩展了测试策略，包括性能测试和监控测试
•	明确了性能要求（99%成功率、2秒响应时间、1000并发等）
•	添加了多语言支持的具体实践

structure.md 更新
•	扩展了目录结构，包括计划中的stacks、constructs、lambda目录
•	添加了多堆栈架构模式的详细说明
•	补充了Lambda函数的组织结构和命名规范
•	明确了开发工作流程和实施顺序
•	添加了代码审查标准和质量要求
•	强调了中英文混合的文档和注释规范

这些更新的steering文档现在能够为AI助手提供更准确和详细的项目指导，特别是：
•	明确了项目的中文业务背景和多语言特性
•	详细的AWS架构和服务配置要求
•	具体的性能指标和质量标准
•	清晰的开发流程和代码组织规范

这三个.md文档，会在每个Task任务执行开始时注入到上下文中。

图3 Task执行时将Steering文档注入上下文

4.丝滑的开发任务执行

Kiro在这个项目的实施计划中分解了15个开发任务。这些开发任务的启动非常简单，在tasks.md文件中点击任务旁边的”Start task”按钮，或者直接在对话框输入“开始任务”即可。

这里我直接将所有任务的开始按钮一起点击了，Kiro会启动第1个任务，并排队后面的14个任务。整个代码开发持续了约三个小时，除任务1中需要安装一些依赖，授权创建一些工具运行外，基本实现了无人值守，由Kiro调用LLM自主完成了代码开发。

图4 Task任务列表示例（已完成状态）

5.自动纠错的方案部署

整个项目支持CDK一键部署到云。在开发完成后，直接本地运行CDK部署命令即可。而使用Kiro，可以让它来运行部署命令，由于是集成的IDE环境，Kiro可以监控部署过程，遇到错误时会自动定位问题，修复代码，再重试部署。

在项目部署中，遇到了部署使用的profile权限不足、部署区域不正确、部署失败再次部署时资源名冲突、Lambda函数没有自动关联到Amazon Connect实例、Contact Flow IVR流格式不对等问题，但基本都能快速定位原因并修复。

在此过程中，一个小技巧是通过提示词引导Kiro使用aws-documentation MCP Server来查询AWS文档，辅助做故障定位和原因分析。相关的AWS MCP Server可参考 https://awslabs.github.io/mcp/

图5 问题修复示例（开发-部署-问题定位-修复-部署的闭环）

6.总结

在虚拟号码开发的过程中，Kiro的表现可以用“惊艳”来形容。

1. SPEC模式相较于之前的上下文管理更进一步，通过具体的需求分析-方案设计-执行计划这几步设计，从根本上给LLM的发挥提前指好了方向。并通过Steering上下文管理，以及本文没有具体提及的Agent Hooks，MCP支持等特性，将Agentic IDE带到了一个新的高度。SPEC模式的理念，极大的影响了其它Coding工具的演进，为AI Coding拓展了新的方向。
2. 虚拟号码的方案，与原来笔者设计的方案高度一致，都使用了Serverless服务来构建，具有项目整体成本低、免运维的特点。Kiro的设计，在项目的完整性、易用性、可拓展性上更好，可以作为生产级应用直接部署。
3. 相较于原来让LLM单纯编写代码的定位，Kiro在需求分解、方案设计、应用部署等原来依赖人工的环节能够有更大的发挥。当然这里并不是说Kiro能够完全代替人的作用，人和生成式AI的配合，就像是“设计师”和“施工队”：设计师绘画蓝图，说明作品的模样和具体的风格；施工队负责落实，完成细节设计并与设计师确认，再利用各类工具搭建完成。好的“设计师”，能够更好的发挥“施工队”的能力。

需要改进的地方：

1. 会话Context的管理需要优化提升。在使用中会遇到当前会话Context过大的情况，特别是使用MCP 工具可能引入大量上下文内容。Kiro此时会自动总结压缩内容并启动新的会话，目前存在两个问题：
   1. 在我测试的时间，目前还不能直观的查看当前Context Token消耗情况，以及当前模型支持的Context大小（其中一些模型在Bedrock上已经提供1M Token版本，但Kiro是否使用未知）
   2. 在总结压缩内容并开启新会话后，对正在进行中的任务的延续性需要提升。目前开启新会话后，需要手动输入之前相关的内容，才能继续任务

图6 会话超出Context时自动总结并开启新会话

2. 对于Amazon Connect Contact Flow这一类格式复杂，对专业性要求比较高的配置文件，对LLM来说很有挑战。在本项目中，Kiro在尝试多次失败后，提议到Connect控制台UI手动创建IVR流，不过它提供了详细的配置步骤和节点类型配置，并说明了如何导出IVR流配置文件到CDK项目中，方便后续直接部署。

图7 Contact Flow的下一步操作指南

7.参考资料

Book of Kiro （https://kiro-community.github.io/book-of-kiro/）

AWS MCP Servers （https://awslabs.github.io/mcp/）

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者