Buda vs Kiro：Software Spec 不是团队运行手册
当 requirements、design、tasks、code、tests 和 pull request 都已存在，一个功能看起来已经“完成”。Kiro 擅长把这条软件链路做实。真正棘手的问题从交接开始：产品、客服、内容和运营分别应该收到什么证据？谁来验收结果？
这篇文章只追踪一个 Feature 如何穿过这条边界，不做两款 Agent 产品的通用功能打分。
跟着一个 Feature 走完 Kiro
Kiro 官方定义是一套覆盖 IDE、CLI、Web 和 Mobile 的统一 Agent harness。仓库中的 .kiro/ 可以让 steering、Specs、custom agents、Hooks、permissions、MCP 和 Skills 在多个入口延续。IDE 与 CLI 通常操作本地代码库；Web 和 Mobile 则能连接托管 cloud session。
Kiro Web 有协作、Spec 和 autonomous 三种模式，可以规划、修改代码并发起 PR/MR。官方明确说明：Kiro 不会自动 merge，结果进入默认分支前仍由人审核。
所以，不能把 Kiro 写成只在 IDE、只有单 Agent，或没有人工 review 的工具。
一份 Kiro Spec 用三类文件组织功能或 Bug：requirements 记录用户故事和验收标准，design 记录架构与实现决定，tasks 把工作拆成可执行单元。依赖允许时，tasks 还能按 wave 并行推进。
这套结构回答的是工程问题：一个想法如何变成可以 review 和 merge 的软件变更？
它的优势在于产物紧贴仓库。Steering 与 Hooks 约束项目规范，permissions 控制 tool call，branch 和 PR 保留实现证据。
标出准确的交接点
PR 被接受以后，公司还要决定：什么产品行为可以对外说，哪些截图和帮助文档与生产一致，谁需要收到更新，明天和下周要跑什么检查，每份交付物由谁验收。
这些任务会引用仓库证据，但主要对象不再是 requirements.md、design.md、tasks.md 或代码，而是 brief、资料文件、浏览器核验、审核后的消息、报告和周期跟进。
Buda Agent Workspace 对应的是这段工作。每个 Agent 有持久 Drive 和独立云电脑，可以使用 chat、browser、terminal、files、Git 和 preview；也能从 Channels 接收任务、调用 Skills、按 Automations 运行。职能负责人审核可见产物，不必接手一段工程会话。
工程 Done 可以是测试通过、验收标准满足、review 完成、PR merge。运营 Done 则是文档与生产一致、客服话术通过、发布素材已核验、负责人验收、周期检查已安排。
不要让其中一个定义悄悄吞掉另一个。边界清楚以后，开发者不必审核每一份业务产物，非工程 Agent 也不必继承多余的仓库权限。
逐项检查 Release Packet
不要把一整段聊天记录扔给下一个 Agent。交接包只需要：已接受的 PR 与 commit、上线行为与验收证据、已知限制和受影响人群、批准使用的截图或文件、下游负责人、审核规则和日期。
Kiro 继续负责软件证据。Buda Agent 用这些证据准备文档、客服材料、发布协调和周期检查。每个领域由对应的人在看得见产物的系统中验收。
记录每种产物应该留在哪里
| 判断 | Kiro | Buda |
|---|---|---|
| 主要生命周期 | 想法到已审核的软件变更 | 请求到已审核的业务结果 |
| 核心产物 | Requirements、design、tasks、branch、PR/MR | Sources、工作文件、报告、内容、运营包 |
| 上下文锚点 | Repository 与 .kiro/ 配置 | Persistent Agent Drive、Sessions、Skills、Space resources |
| 执行入口 | IDE、CLI、Web、Mobile，本地或 cloud sandbox | 带 browser、terminal、files、Git、Channels 的云工作区 |
| 人工门禁 | Tool permissions 与默认分支 merge 前 review | 重要下游动作前的职能审核 |
| 自然负责人 | Developer 或软件团队 | 产品、内容、客服、运营或管理负责人 |
如果 Specs、steering、Hooks、code intelligence、本地或云端执行、PR 交付是工作的中心，Kiro 更直接。它也支持 custom agents、sub-agents、MCP、Skills、permissions 和 Web scheduled automations。评估时要同时查看套餐、仓库提供商、区域限制和各入口的功能可用表。
不同 Agent 角色要跨天保留，处理非代码文件和网站，从团队 Channels 接收请求，再把不同产物交给不同 Reviewer 时，Buda 更适合。差异是组织连续性，不是“自治程度更高”。
Kiro 落地前必须回答的问题
Kiro 只是 IDE Coding Assistant 吗？
不是。Kiro 官方文档覆盖 IDE、CLI、Web、Mobile，以及 cloud sessions、custom agents、sub-agents、MCP、Skills、Hooks、permissions 和 automations。
Kiro 支持 Cloud Agent 和人工审核吗？
支持。Kiro Web 在托管 sandbox 运行，可以发起 PR/MR；官方明确说它不自动 merge，结果进入默认分支前由人审核。
Kiro 能做非代码工作吗？
它能搜索 Web、调用工具和自动化任务。真正的判断点是：被验收的结果和负责人属于软件交付流程，还是另一个业务职能。
不要让“已合并”等于“已上线”
从一次发布开始。让 Kiro 证明软件变更，让 Buda 协调之后的运营工作。权限保持最小，交接保持明确，由人负责最终验收。