AI 辅助嵌入式全流程开发：使用 Kiro 逐步构建智能温湿度监控系统
内容提要
本文介绍使用AI编码工具Kiro辅助嵌入式全流程开发，以STM32H743智能温湿度监控系统为例，涵盖构建Datasheet知识库、导入原理图、生成约束文档、需求设计拆解、代码生成、编译烧录及调试。通过Spec驱动、Steering约束和Skills沉淀机制，提升开发效率，并强调人工复核硬件参数的重要性。
延伸解读
AI 辅助嵌入式开发的关键：人机协作与人工复核
本文强调 AI 工具 Kiro 并非“一键生成代码”，而是通过 Spec 驱动、Steering 约束和 Skills 沉淀三个机制组织开发流程。这种结构化协作方式将需求、设计和任务逐层拆解，并在每个阶段保留人工审查机会。文章多次提醒，AI 生成的硬件描述、时序参数等必须经过工程师对照原始 Datasheet 复核，尤其是引脚复用和 I2C 设备地址，这体现了 AI 辅助开发中人工验证的重要性。
Steering 约束：提升 AI 生成代码的一致性
针对 AI 生成代码风格不一致的问题，文章提出使用 Steering 约束文档，将硬件参数、编码规范和工具链约定持久化，并支持始终包含、按文件匹配等加载方式。通过配置 coding-standards.md 等文档，可以统一命名规范、错误处理方式等，将团队规范前置到生成阶段，减少后期审查和修改成本。但文章也指出，Steering 不能替代代码审查和硬件验证。
Spec 驱动：结构化拆解复杂嵌入式项目
嵌入式系统开发依赖严格的顺序和系统级约束，难以通过单次提示词表达。Kiro 的 Spec 机制通过 Requirements → Design → Tasks 三层文档，将目标逐步细化为可执行任务，并在各阶段保留人工审查机会。文章以温湿度监控系统为例，展示了如何将需求用 EARS 格式编写，并设计渐进式点亮流程，每个阶段都有可观测的验证证据，有助于降低集成风险。
Q&A
Kiro 辅助嵌入式开发的核心机制是什么？
Kiro 通过三个机制组织开发过程：Spec 驱动（需求→设计→任务的结构化流程）、Steering 约束（硬件参数与编码规范一次配置、全程生效）、Skills 沉淀（把踩过的坑固化为可复用的团队资产）。
如何构建 Datasheet 知识库？
通过 MCP 连接 Amazon Bedrock Knowledge Bases，将 Datasheet 文档上传至 S3 Draft Bucket，经审批后进入 Production Bucket，再通过 Lambda 调用 Textract 提取文本并向量化入库，最后通过 Bedrock Knowledge Bases 提供检索增强生成能力。
导入原理图时，多模态视觉识别和网表文本解析两种方案有何区别？
多模态视觉识别直接处理 PDF/图片，适合简单电路，但对复杂电路（如 STM32H743）识别准确率低；网表文本解析基于 EDA 导出的结构化文本，更易追溯、版本管理和程序化处理，但可能缺少设计意图，解析结果仍需人工校验。
Steering 约束文档的作用是什么？
Steering 将硬件参数、编码规范和工具链约定写成持久化文档，并支持始终包含、按文件匹配等加载方式，以提高 AI 生成代码的一致性，减少命名、分层和错误处理上的偏差。
Spec 驱动中 Requirements、Design、Tasks 三层结构分别是什么？
Requirements 定义系统应该做什么，用 EARS 格式写出可验证的验收标准；Design 定义系统怎么做，包括架构分层、内存映射、任务模型和启动顺序；Tasks 定义具体实现哪些内容，标明相关文件、接口、依赖关系和需求。
在 SDRAM 初始化中，为什么需要人工复核硬件参数？
因为 AI 生成的 FMC 时序字段仍需按实际 FMC 时钟重新计算，且 STM32H7 HAL 参数传入的是实际周期数而非寄存器编码值，任何时序单位、时钟来源或刷新公式处理不当都可能导致 SDRAM 自检偶尔通过而显示异常，所以必须人工复核。
Kiro 如何辅助调试？
Kiro 辅助调试遵循“先观察，再验证”的原则，通过串口日志、LED 行为、LCD 显示等可观测证据，逐步定位问题，并利用 Skills 沉淀经验，避免重复踩坑。
Skills 沉淀机制如何帮助团队？
Skills 将开发过程中踩过的坑固化为可复用的团队资产，下次遇到类似问题时可以直接参考，避免重复踩坑，提升团队整体效率。
