Busabase × AWS KiroKiro 知识库
Kiro 能把一个想法拆成需求、设计和可执行任务。Busabase 承接围绕 Spec 的业务决定，让跨团队、跨仓库的验收过程有负责人、可审核、可追溯。
三类 Spec 工件
Kiro 负责规范实现过程，这些文件应该留在仓库。
Kiro Feature Spec 会生成 requirements.md、design.md 和 tasks.md。需求文件保存 user story 与 acceptance criteria，设计文件描述架构，任务文件驱动实现。Kiro 建议把 Spec 与它所描述的代码一起纳入版本控制。
requirements.md行为
User story、约束和验收标准
design.md方案
架构、数据流、错误处理和测试策略
tasks.md执行
离散任务、依赖关系和完成状态
独立的归属层
一项产品承诺的范围，通常比单个仓库 Spec 更大。
技术工件继续归仓库所有。只有当同一需求影响产品规划、客户承诺、合规、客服准备或多个仓库时，Busabase 才接手这部分正式事实。链接原 Spec，不复制第二份可编辑正文。
| 信息 | 存放位置 | 正式归属 |
|---|---|---|
| 编码规范或项目上下文 | .kiro/steering/ 或 AGENTS.md | 仓库 |
| 功能需求、设计、任务 | .kiro/specs// | 仓库 |
| 代码变化与测试 | Commit / Pull Request | Git 平台 |
| 跨团队需求与验收决定 | 结构化记录 + Change Request | Busabase |
追溯链
把最初需求连接到证明它已经交付的证据。
这条链要经得住持续调整。即使 Kiro 修改设计，或在需求变化后重新同步任务，业务记录仍要指向被接受的需求版本、实现证据与最终负责人。
变化影响
Spec 一变，就明确还有谁必须做决定。
Kiro 可以调整需求并重新生成设计或任务文件，但它不会自动解决仓库外的影响。一张精简影响矩阵，可以把 Spec 修改变成明确的审核队列。
验收台账
把 Spec 周围的决定存成下一条流程能查询的字段。
记录只链接 Kiro 文件和 Git 证据，不与它们竞争。下面这些字段足以回答：接受了什么、对应哪个版本、谁接受、有哪些附加条件。
| 字段 | 用途 |
|---|---|
| requirement_id | 与 Kiro Spec 共享的稳定标识 |
| spec_url | 指向需求、设计和任务的版本化链接 |
| accepted_behavior | 必须持续成立的业务结果 |
| implementation_ref | Pull Request、commit、build 或 deployment |
| verification | 测试结果和运行证据 |
| decision | 提议、接受、有条件接受、拒绝或已替代 |
| owner | 对验收负责的人 |
| effective_at | 依赖团队从何时可以据此行动 |
自动化职责更窄
Hook 可以强制检查，但不能替利益相关者完成验收。
Kiro Hooks 能在生命周期事件发生时执行 shell command 或 agent prompt。PreToolUse 和 PreTaskExecution 可以阻塞，PostFileSave 或 Agent Stop 可以收集结果。让它们生产证据或触发提议，业务决定仍单独审核。
PostFileSave证据运行 lint、类型检查或定向测试
PreTaskExecution执行门禁缺少必要输入时阻止任务开始
Agent Stop + confirm提议触发器询问是否提交本次 session 结果
Busabase 审核正式决定检查范围、证据、负责人和影响
持续调整，不丢历史
Spec 只改一次，再有意识地更新验收链接。
Kiro Specs 支持持续 refinement 和任务同步。使用版本化 Git 引用，避免正式记录指向不断移动的分支内容。如果已接受需求发生实质变化，应提出一条替代决定，而不是覆盖原历史。
连接边界
知识页说明信息归属，连接页负责 MCP 设置。
Kiro 在 IDE、CLI、Web 和 Mobile 使用统一 Agent harness，并共享 .kiro 配置，但不同工作面仍有特定行为。Workspace 或 user 级 MCP 配置可以指向 Busabase；endpoint、OAuth、范围优先级与验证步骤以连接页为准。
Spec 驱动团队常问的问题
Kiro 知识库常见问题
Busabase 会取代 Kiro Specs 吗？
不会。requirements.md、design.md 和 tasks.md 应该和代码一起接受版本控制。Busabase 记录需要更广泛系统承接的跨团队需求、验收决定、负责人和运营状态。
每个 Spec 都要创建 Busabase 记录吗？
不用。只有其他团队、仓库、客户承诺、控制要求或发布流程依赖结果时才建记录。纯本地实现细节可以留在 Spec 和 Git 历史中。
Kiro Hook 能自动批准需求吗？
Hook 可以运行检查、阻止动作或触发提议，但不能证明利益相关者已经接受业务后果。最终决定仍属于明确负责人。
两个系统之间用什么稳定关联？
使用 requirement_id 加版本化 spec_url 或 commit SHA。不要只链接到会持续变化的分支页面，否则以后无法确认当时接受的具体版本。
Quick Spec 也能使用这套流程吗？
可以，但 Kiro 把 Quick Spec 定义为不经过标准阶段审核就生成全部工件。高影响工作应补充明确的需求分析与验收审核，再把它当成正式范围。
从下一个验收点开始
给一份 Kiro Spec 指定仓库之外的负责人。
选择一项跨团队功能，关联当前 Spec 与证据，在依赖工作继续之前完成第一次验收决定。