网站建设及维护涉及哪些内容创建网站向导和模板

网站建设及维护涉及哪些内容,创建网站向导和模板,网站规划建设与管理维护答案,网站建设公司推广网站品牌运营去年笔者曾经设计过隐私号码、隐私邮箱、网址短链三个小应用#xff0c;使用亚马逊云科技的Amazon Connect#xff0c;DynamoDB#xff0c;Amazon SES#xff0c;Lambda#xff0c;CloudFront等服务构建。在设计方案时#xff0c;我查找了不少文档和网上资料#xff0c;…去年笔者曾经设计过隐私号码、隐私邮箱、网址短链三个小应用使用亚马逊云科技的Amazon ConnectDynamoDBAmazon SESLambdaCloudFront等服务构建。在设计方案时我查找了不少文档和网上资料来选择合适的服务完善架构。在将方案设计好后由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 Kirohttps://kiro-community.github.io/book-of-kiro/。进入Kiro后使用SPEC模式输入如下需求我想设计一个虚拟号码应用当用户拨打某个号码时会自动播报提示用户输入短号。输入短号后自动转接到接听方真实的号码。使用AWS的服务设计一个解决方案尽可能使用Serverless服务。Kiro开始方案的设计生成需求文档requirements.md针对需求完成设计文档design.md。在确认设计方案无误后进一步的生成实施计划文档tasks.md。图1 SPEC模式从创建规范需求开始在生成这几个SPEC模式的文档时需求的总结和方案的设计让我眼前一亮输出的工作流程和mermaid流程图与原先我设计的方案思路完全一致并额外有一些易用性和可维护性的增强考虑了通话记录存储、日志记录功能。方便查询通话统计和异常事件设计了增/删/查/改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来查询亚马逊云科技文档辅助做故障定位和原因分析。相关的Amazon MCP Server可参考 https://awslabs.github.io/mcp/图5 问题修复示例开发-部署-问题定位-修复-部署的闭环6.总结在虚拟号码开发的过程中Kiro的表现可以用“惊艳”来形容。SPEC模式相较于之前的上下文管理更进一步通过具体的需求分析-方案设计-执行计划这几步设计从根本上给LLM的发挥提前指好了方向。并通过Steering上下文管理以及本文没有具体提及的Agent HooksMCP支持等特性将Agentic IDE带到了一个新的高度。SPEC模式的理念极大的影响了其它Coding工具的演进为AI Coding拓展了新的方向。虚拟号码的方案与原来笔者设计的方案高度一致都使用了Serverless服务来构建具有项目整体成本低、免运维的特点。Kiro的设计在项目的完整性、易用性、可拓展性上更好可以作为生产级应用直接部署。相较于原来让LLM单纯编写代码的定位Kiro在需求分解、方案设计、应用部署等原来依赖人工的环节能够有更大的发挥。当然这里并不是说Kiro能够完全代替人的作用人和生成式AI的配合就像是“设计师”和“施工队”设计师绘画蓝图说明作品的模样和具体的风格施工队负责落实完成细节设计并与设计师确认再利用各类工具搭建完成。好的“设计师”能够更好的发挥“施工队”的能力。需要改进的地方1、会话Context的管理需要优化提升。在使用中会遇到当前会话Context过大的情况特别是使用MCP 工具可能引入大量上下文内容。Kiro此时会自动总结压缩内容并启动新的会话目前存在两个问题在我测试的时间目前还不能直观的查看当前Context Token消耗情况以及当前模型支持的Context大小其中一些模型在Bedrock上已经提供1M Token版本但Kiro是否使用未知在总结压缩内容并开启新会话后对正在进行中的任务的延续性需要提升。目前开启新会话后需要手动输入之前相关的内容才能继续任务图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/Amazon MCP Servers https://awslabs.github.io/mcp/*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营具体信息以中国区域官网为准。本篇作者 想利用生成式AI开发工具解放双手却苦于应用效果不够完善、流程不够规范✨ 亚马逊云科技 Kiro 登场采用“规范驱动”开发理念结合 Agent Hooks 自动化系统1小时让小白变身生产级游戏制作人 速来云上探索实验室体验 Kiro 开发独立游戏从需求到部署全掌握 点击这里即刻开启 AI 开发之旅