Buda vs Amazon Q Developer：2026 年迁移前，先把工作分流
梳理 Amazon Q 当前产品面与 Kiro 迁移范围，判断哪些跨职能工作需要持久多 Agent 工作区。
Buda vs Amazon Q Developer：2026 年迁移前，先把工作分流
Amazon Q Developer 不是按下一个开关就整体消失，Buda 也不是它在代码和 AWS 专业能力上的直接替代品。2026 年真正有用的比较，应该先画一张地图：每项工作今天依赖 Amazon Q 的哪一个产品面，这个产品面将去哪里，迁移之后这项工作是否仍然只属于开发者？
AWS 已经把 Q CLI 转为 Kiro CLI；2026 年 5 月 15 日之后不再接受新的 Q Developer Account 和 Subscription；IDE Plugins 与付费订阅计划在 2027 年 4 月 30 日结束支持。但 AWS Management Console、AWS 一方网站与 Mobile App、Slack 和 Microsoft Teams 中的 Amazon Q Developer 明确不在这次 Sunset 范围内。
所以这不是一条迁移路线，而至少是三条：保留继续运行的 AWS 辅助面；把 Repository 工作迁往 Kiro 或其他 Coding Environment；当工作已经扩展到长期跨职能运营时，再考虑托管式 Agent Workspace。
迁移是一张产品面地图，不是厂商胜负表
“Amazon Q Developer”这个名称目前承载了多种工作：
- 在 AWS Console 与一方入口中回答架构、资源、排障和最佳实践问题；
- 在 IDE 中读取 Workspace Context、修改本地文件、运行 Shell、做 Code Review 与 Security Scan；
- 通过 MCP 连接外部工具；
- 进入 GitHub、GitLab 以及 Slack、Microsoft Teams；
- 承接应用转换与现代化。
这些产品面并不共享同一个生命周期。一家公司说“我们在用 Amazon Q”，背后可能是六种依赖，由六个团队负责。若把品牌名当成一项采购统一替换，就会把 AWS 运维、软件交付、协作和业务运营混成同一个迁移项目。
先建立 Workload Register。每项使用都记录当前产品面、负责人、能访问的文件或系统、订阅依赖、审核对象、截止时间和目标去向。
把四个日期放到迁移看板上
2025 年 11 月 17 日：Q CLI 成为 Kiro CLI
AWS User Guide 的 Document History 明确记录，Q CLI 在这一天成为 Kiro CLI。因此命令行路径已经是 Kiro 决策，不应再计划迁往“另一个 Q CLI”。需要盘点的是 Kiro CLI 的配置、认证、Agents、Rules 或 Steering、Prompts、MCP Servers 和脚本。
2026 年 4 月 30 日：AWS 宣布迁移范围
AWS 宣布 Amazon Q Developer IDE Plugins 与付费 Subscriptions 将在 2027 年 4 月 30 日结束支持，并把 Kiro 定位为 Agentic Coding、Inline Chat、Terminal、MCP、Specs、Hooks、Steering 与 Custom Subagents 的迁移路径。
2026 年 5 月 15 日：停止新建 Account 与 Subscription
通过 Builder ID IDE Plugin 新建 Q Developer Free Tier Account，以及通过 AWS Console 新建 Q Developer Subscription，已经停止。现有 Subscription 仍可增加用户，现有客户在迁移窗口内仍能使用 IDE Plugin。这已经是当前采购限制，不是未来脚注。
2027 年 4 月 30 日：指定产品面结束支持
IDE Plugins、付费 Subscriptions，以及依赖这条订阅路径的 Code Transformation 到期。AWS 建议 IDE 用户迁往 Kiro，相关现代化工作迁往 AWS Transform。
这个日期不代表 Amazon Q Developer 整体停服。AWS 明确说明，AWS Management Console、AWS 一方网站、AWS Console Mobile App，以及 Slack 和 Microsoft Teams 中的 Amazon Q Developer 不受这次 Sunset 影响。
先保留 Amazon Q Developer 真正擅长的工作
如果把 Amazon Q 写成旧式补全工具，迁移建议就会失真。当前官方产品页与 User Guide 仍明确记录：
- 面向 AWS 架构、资源、最佳实践、文档、支持和运维的专业回答；
- IDE Chat、Inline Completion、多文件生成、Debug、Optimization 和 Code Upgrade；
- 可读写本地文件、生成 Diff、运行 Shell 并持续汇报的 Agentic Coding；
- Workspace Context、Project Rules、Conversation History 与 Customizations；
- Security Scan 与 Code Review；
- IDE 与原 Q CLI 产品面中的 MCP、Tool Permission 和 Governance；
- GitHub、GitLab、AWS Console 与 Chat Applications 等入口。
这些能力与跨职能 Agent Workspace 不是同一种工作。Buda 不应宣称替代 AWS 专业知识、IDE 代码生成、安全扫描或 Kiro Migration。
把三类 Workload 分开处理
AWS 架构与运维
例如询问 AWS Resource、排查 Operational Issue、阅读 AWS Documentation、检查成本或安全建议，以及在 Console 或 AWS 一方入口使用 Amazon Q。
这些工作有充分理由留在继续运行的 Amazon Q 产品面。权威上下文本来就是 AWS Account、Resource、Policy 或 Service。只因为 IDE Plugin 有结束支持日期就迁往 Buda，反而会丢掉产品最强的适配面。
以 Repository 为核心的软件交付
例如在 IDE 实现 Feature、生成 Tests、Review Code、运行 Shell、使用 Workspace Context，或把 MCP Tools 接入 Coding Session。
这些工作需要 Coding Path 决策。现有用户可以受控迁移到 Kiro，或评估其他 Coding Environment。Buda vs Kiro 讨论的是另一层选择：Software Specification 与 Repository Delivery，和长期团队 Operating Runbook 的分工。AI Coding Assistants 指南 更适合用于 Coding 产品短名单。
Buda 可以保存文件、Git 工作、Terminal Session 与可审核产物，但不是 IDE Plugin 的直接替代品，不应拿 Code Completion 做一一对标。
跨职能长期运营
例如每周竞品报告同时需要 AWS Release Notes、Repository、客户反馈、文档和经理审批；或一次 Incident 后续要变成客户通知、内部 Runbook 与定期预防检查。
这才是 Buda 相关的部分。工作流需要命名且长期存在的 Agents、共享 Space 与 Drive、Browser/Terminal/Git、长期 Sessions、Permissions、Channels、Automations 和最终 Artifact Review。团队已经不只是在选 Coding Assistant，而是在分配长期业务工作。
用 Workload Routing Decision Tree 做决定
逐项问四个问题：
- 权威上下文是 AWS Account 或一方 AWS 产品面吗？ 除非 AWS 已明确替换该入口，否则保留在继续运行的 Amazon Q 产品面。
- 权威产物是 Repository Change 吗？ 通过 Kiro 或其他 Coding Environment 迁移，Code Review 仍留在 Repository。
- 工作是否跨部门、跨系统、持续多天？ 评估持久 Agent Workspace，不要把 IDE Session 硬拉成运营流程。
- 人最终要验收什么？ Code Diff 进入 Repository Review；客户回复、报告、Campaign 或运营决策，需要业务 Artifact Owner。
| Workload | 分流后的主要负责人 | 原因 |
|---|---|---|
| Console 中的 AWS Resource 问题 | 继续运行的 Amazon Q 产品面 | AWS Context 与一方 Integration 仍是核心 |
| IDE Agentic Coding | Kiro 或其他 Coding Environment | Repository 与 Developer Loop 仍是工作对象 |
| Code Review / Security Finding | Repository 与 Security Workflow | Finding 与 Fix 需要工程验收 |
| 跨系统每周运营 | Buda Agent Workflow | 需要持久上下文、多工具、排程与产物审核 |
| 使用已验收代码或 AWS 产物的业务决策 | Buda 或既有业务系统 | 工作已经从实现进入可追责运营 |
Buda 是不同层级的 Alternative
Amazon Q Developer alternative 这个 Query 其实隐藏了两种意图。
如果用户需要新的 IDE Assistant、Code Generator、AWS-aware Coding Agent 或 Q Developer Plugin 替代品，Buda 不是直接答案。应该围绕 Repository 与开发行为比较 Kiro 或其他 Coding 产品。
如果用户希望降低对本地开发面依赖，并让多个云端 Agent 围绕文件、研究、代码、业务系统、排程和人工审核协作，Buda 是另一个运营层级的 Alternative。Buda Space 可以放置多个命名 Agent；Drive 提供共享资料；每个 Agent 有持久工作环境和 Sessions；Skills 让流程可复用，Automations 提供时间触发，Permissions 与 Review 把验收留给人。具体能力因套餐而异。
建立 Migration Register，不做一刀切替换
| 字段 | 需要记录什么 |
|---|---|
| Surface | Console、IDE Plugin、原 Q CLI/Kiro CLI、GitHub/GitLab、Chat App、Transformation |
| Owner | Developer、Platform Team、Cloud Operations、Security 或业务部门 |
| 当前依赖 | Builder ID、Pro Subscription、IAM Identity Center、AWS Account、本地文件、Repository、MCP |
| Lifecycle | 继续运行、已迁往 Kiro、过渡至 2027-04-30，或仍需单独核对 |
| Destination | 保留 Amazon Q、迁往 Kiro/Coding Tool、迁往 Buda，或双系统共存 |
| Acceptance | Diff、Security Finding、AWS Action、Report、Customer Message 或 Management Decision |
不要根据 Marketing Page 或旧安装指南猜生命周期。使用最新 AWS 公告、User Guide、Document History、实际 Account Status 和团队配置。
清晰边界比强制替换更合理
工程团队可以把 AWS Resource 与 Coding Work 留在合适的 AWS/Kiro 产品面，再把已验收产物晋级到 Buda，承接跨职能长期执行。
例如，Kiro 或 Amazon Q Workflow 产出经过批准的 Architecture Decision Record、测试脚本、Pull Request 或 Security Report；工程审核后，Buda 再把这份已验收 Artifact 用于 Release Checklist、客户通知、培训更新或每周运营报告。
交接必须有一个 Artifact、一个 Owner 和一次明确验收。否则两套 Agent System 只会重复上下文和权限。
迁移期最常见的问题
Amazon Q Developer 会整体停服吗？
不会。AWS 宣布的是 IDE Plugins 与付费 Subscriptions 在 2027 年 4 月 30 日结束支持。AWS Console、一方 AWS 入口、AWS Console Mobile App，以及 Slack 与 Microsoft Teams 中的 Amazon Q Developer 明确不受影响。
Amazon Q Developer CLI 去哪里了？
AWS User Guide 历史记录显示，Q CLI 已于 2025 年 11 月 17 日成为 Kiro CLI。命令行开发应按 Kiro 迁移，核对配置路径、认证、Agents、Rules、Prompts 和 MCP Settings。
Buda 能替代 Amazon Q Developer 的 Coding 能力吗？
不能直接替代。Buda 不是 IDE Code Completion 或 AWS 专业知识替代品。它提供的是持久多 Agent Workspace，服务跨工具、文件、部门、排程和业务审核的工作。
哪些团队应该在迁移期评估 Buda？
如果 Amazon Q 使用已经超出 Repository Delivery，扩展到定期研究、运营、内容、销售、客户沟通或管理报告，就值得评估 Buda。只需要 IDE Coding 的团队应优先完成 Coding Tool 迁移。
做一次 30 天分流试点
选择一个横跨 AWS、Code Repository、文档与业务交付物的流程。每一步都交给拥有权威上下文的系统：Code Review 留在 Repository，AWS Resource Action 留在 AWS 控制面，只把跨职能编排与已验收产物放入持久 Agent Workspace。
记录重复上下文、权限请求、无人负责的交接、等待时间和审核耗时。结果会告诉你，团队缺的是 Coding Assistant、AWS Assistant，还是管理多个 Agent 的运营环境。
查看 Buda AI Agent Workspace、长期 Agent 角色、Skills Marketplace，并在 Buda Docs 核对当前套餐边界。