一种不同的构建方式：我在 Kiro + IncidentOps 的经验

Source: Dev.to

架构概览

为什么选择 Kiro？

这个项目让我最惊讶的是 Kiro 与典型的 AI 辅助编码截然不同。它不是尝试“猜测”我的需求，而是鼓励我通过规范驱动的开发方式清晰地定义系统。

编写规范的过程非常自然——几乎像是把我的思考过程记录下来。一旦规范准备好，Start Task 工作流就能让执行变得可预测且高效。我可以让 Kiro 一次构建一个组件，随后审查、改进并继续前进。

通常需要跨工程和运维团队数周才能完成的任务，在经过人工审查后，仅用数小时即可完成。

我构建的内容

IncidentOps 是一个顺序流水线：

MonitorAgent → LLMAlertSummaryAgent → TriageAgent →
LLMResolutionAgent → OpsLogAgent → LLMGovernanceAgent →
LLMGovernanceInsightsAgent → NotificationAgent

代理职责

• 检测异常
• 生成面向人的友好摘要
• 确定性地分配严重性和类别
• 建议修复步骤
• 编写事实审计日志（不做解释）
• 对风险、升级和合规性进行评分
• 使用数据库聚合分析历史模式
• 发送通知

使用的技术

• 用 Python 进行编排
• 用 SQLite 进行持久化
• 用 Streamlit 构建 UI
• 用 LLM 进行摘要、修复和洞察
• 用 Kiro 的规范驱动工作流提供结构和迭代

我的收获

• 明确的规范可以显著加快开发速度。
• AI 生成的代码仍需人工验证。
• 小而明确的单元降低了复杂性和漂移。
• 将确定性逻辑与 LLM 推理相结合，既保证可靠性又具备适应性。
• 结构化的工作流让即使是复杂系统在紧迫的时间线下也能易于管理。

结束语

好工具不仅能加速开发——还能提升思考的清晰度。对于事故管理而言，隐藏的模式与显现的错误同等重要，而这种清晰度正是必不可少的。

感谢 Kiro 团队提供的工作流，让整个过程稳健、透明且出乎意料地愉快。我很期待在黑客松之后继续完善 IncidentOps。