Kiro 小应用开发：设计和实现隐私号码
去年笔者曾经设计过隐私号码、隐私邮箱、网址短链三个小应用，使用亚马逊云科技的 Amazon Connect，DynamoDB，Amazon SES，Lambda，CloudFront 等服务构建。在设计方案时，我查找了不少文档和网上资料，来选择合适的服务，完善架构。在将方案设计好后，由 Claude 协助完成 Lambda 代码（当时是 Claude 3 Sonnet），并手动完成其它的服务的配置。方案使用上述的 Serverless 服务，有成本可控和运维压力小的优点，在某个电商客户部署后得到好评。
在 Kiro 推出后，其 Specs 模式令人印象深刻。需求分解，方案设计，甚至是应用部署，这些原来需要人来主导的工作，现在是否可以由 Kiro 来完成？这里我将使用 Kiro 来重新开发隐私号码项目，看看在 Specs 加持下能否将所有的工作都由 Kiro 来完成。
🔥 想利用生成式 AI 开发工具解放双手，却苦于应用效果不够完善、流程不够规范？
✨ 亚马逊云科技 Kiro 登场！采用“规范驱动”开发理念，结合 Agent Hooks 自动化系统，1 小时让小白变身生产级游戏制作人！
🔛 速来云上探索实验室，体验 Kiro 开发独立游戏，从需求到部署全掌握！
👉 点击这里，即刻开启 AI 开发之旅！
1.什么是虚拟号码？
虚拟号码使用单独创建的号码来代替真实号码，为用户提供一个额外的身份，能够有效的保护真实联系信息：
保护隐私：在不暴露个人真实联系方式的情况下与第三方沟通。
身份管理：为不同的身份或活动使用不同的联系方式。
安全性：降低个人信息被泄露或滥用的风险。
虚拟号码可以有不同的形态：
正常普通号码（与普通号码一样，运营商预留的专用号段）。当呼叫这个号码时，自动转接到绑定的真实号码。这种方式在网约车、外卖等场景有广泛的使用。因为号段资源是有限的，这种虚拟号码一般有时效限制，在服务完成后一段时间会解除该虚拟号码与真实号码的绑定。
指定号码呼叫+输入短号（分机号）。指定号码是正常普通号码。当呼叫指定号码后，会自动接通并收到输入短号/分机号的提示，输入短号后再转接到真实的号码。这种方式只需要少量的普通号码，通过生成不同的短号关联到不同的真实号码，能够持久的使用或根据需求自定义任意的有效时间。
在接下来的内容中，我将测试由 Kiro 来完成整个短号方案的需求分解、方案设计、开发、和部署。
2.体验 Kiro SPEC 模式的魅力
Kiro 具体的介绍可以参考官网（https://kiro.dev/），另外推荐由社区整理的 Book of Kiro（https://kiro-community.github.io/book-of-kiro/）。
进入 Kiro 后，使用 SPEC 模式，输入如下需求：
Kiro 开始方案的设计，生成需求文档 requirements.md，针对需求完成设计文档 design.md。在确认设计方案无误后，进一步的生成实施计划文档 tasks.md。
图 1 SPEC 模式从创建规范需求开始
在生成这几个 SPEC 模式的文档时，需求的总结和方案的设计让我眼前一亮，输出的工作流程和 mermaid 流程图与原先我设计的方案思路完全一致，并额外有一些易用性和可维护性的增强：
考虑了通话记录存储、日志记录功能。方便查询通话统计和异常事件
设计了增/删/查/改 API 接口
原来方案在添加短号-真实号码的映射关系时，需要将映射记录手动导入到 DynamoDB，删查改等功能也是直接到数据库中操作，只适合开发人员使用。而 Kiro 的设计更像一个完整的方便易用的生产系统，添加这些运维接口后，任务人员都可以通过 Web 界面直观的维护。相关的记录和日志功能，也为进一步拓展业务场景打下了基础。
Kiro 设计文档比较完整的介绍了工作流程和架构，节选部分内容和加架构图如下：
图 2 设计文档在 design.md 中的流程图
Kiro SPEC 模式通过 Requirement-Design-Task 这个流程，利用 AI 将一句简短的模糊需求，变成一份结构清晰、条理清楚的规范文档。通过 Requirements 明确要做什么，通过 Design 规划如何实现，通过 Implementation 将整个项目分解为可执行的开发任务，指导 LLM 不偏离不失控。
在生成初始 Design 设计文档后，我添加了一个“支持 CDK 部署”需求，Kiro 更新了需求文档和设计文档，之后转到实施计划阶段，生成开发任务
实施计划出炉后，Kiro 最终的总结输出节选如下：
在进入任务执行前，我让 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 内容总结：
这三个.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 来查询亚马逊云科技文档，辅助做故障定位和原因分析。相关的 Amazon MCP Server 可参考 https://awslabs.github.io/mcp/
图 5 问题修复示例（开发-部署-问题定位-修复-部署的闭环）
6.总结
在虚拟号码开发的过程中，Kiro 的表现可以用“惊艳”来形容。
SPEC 模式相较于之前的上下文管理更进一步，通过具体的需求分析-方案设计-执行计划这几步设计，从根本上给 LLM 的发挥提前指好了方向。并通过 Steering 上下文管理，以及本文没有具体提及的 Agent Hooks，MCP 支持等特性，将 Agentic IDE 带到了一个新的高度。SPEC 模式的理念，极大的影响了其它 Coding 工具的演进，为 AI Coding 拓展了新的方向。
虚拟号码的方案，与原来笔者设计的方案高度一致，都使用了 Serverless 服务来构建，具有项目整体成本低、免运维的特点。Kiro 的设计，在项目的完整性、易用性、可拓展性上更好，可以作为生产级应用直接部署。
相较于原来让 LLM 单纯编写代码的定位，Kiro 在需求分解、方案设计、应用部署等原来依赖人工的环节能够有更大的发挥。当然这里并不是说 Kiro 能够完全代替人的作用，人和生成式 AI 的配合，就像是“设计师”和“施工队”：设计师绘画蓝图，说明作品的模样和具体的风格；施工队负责落实，完成细节设计并与设计师确认，再利用各类工具搭建完成。好的“设计师”，能够更好的发挥“施工队”的能力。
需要改进的地方：
会话 Context 的管理需要优化提升。在使用中会遇到当前会话 Context 过大的情况，特别是使用 MCP 工具可能引入大量上下文内容。Kiro 此时会自动总结压缩内容并启动新的会话，目前存在两个问题：
在我测试的时间，目前还不能直观的查看当前 Context Token 消耗情况，以及当前模型支持的 Context 大小（其中一些模型在 Bedrock 上已经提供 1M Token 版本，但 Kiro 是否使用未知）
在总结压缩内容并开启新会话后，对正在进行中的任务的延续性需要提升。目前开启新会话后，需要手动输入之前相关的内容，才能继续任务
图 6 会话超出 Context 时自动总结并开启新会话
对于 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/）
Amazon MCP Servers （https://awslabs.github.io/mcp/）
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。
本篇作者
🔥 想利用生成式 AI 开发工具解放双手，却苦于应用效果不够完善、流程不够规范？
✨ 亚马逊云科技 Kiro 登场！采用“规范驱动”开发理念，结合 Agent Hooks 自动化系统，1 小时让小白变身生产级游戏制作人！
🔛 速来云上探索实验室，体验 Kiro 开发独立游戏，从需求到部署全掌握！
👉 点击这里，即刻开启 AI 开发之旅！
还未添加个人签名 2019-09-17 加入
进入亚马逊云科技开发者网站，请锁定 https://dev.amazoncloud.cn 帮助开发者学习成长、交流，链接全球资源，助力开发者成功。
评论