什麼是 Kiro？
Kiro 是由 Amazon Web Services 打造的一個可下載編程環境，將 AI 輔助開發帶向這類工具少有嘗試的方向。
大多數 AI 編程工具都讓你輸入提示詞，然後即時取得程式碼；Kiro 會先執行規劃流程： 它會讀取你的專案上下文、撰寫需求文件、生成技術設計、拆解成編號任務清單，然後才開始寫程式碼。
Kiro 提供 IDE、命令列工具、網頁介面（目前僅限付費用戶預覽）以及手機應用程式（iOS 早期體驗），定位為適合想要結構化、可維護輸出的開發者，而不是那種只追求快速產出、卻得在一星期後再花時間拆解的工具。
Kiro 適合誰？
- 曾被 AI 生成程式碼「第一日可用、第二日壞掉」折騰過的開發者。 Kiro 的 spec 工作流程會先規劃再實作，令它寫出的程式碼可追溯至已記錄的需求，而不是憑空拼湊出來。
- 正在轉向 agentic 工作流程的團隊。 Kiro 的 Agent Hooks 可自動化重複任務，例如撰寫測試或產生文件，只要符合條件的檔案有變動，就會自動觸發，無需重複提示。
- AWS 生態系開發者。 Kiro 建基於 AWS 基礎設施，會按你的地理位置在 AWS 區域之間處理資料，並可自然連接 AWS 服務。如果你的技術棧本身已以 AWS 為主，Kiro 幾乎不用額外設定就能配合。
- 想要比 autocomplete 更深入 AI 功能的 VS Code 用戶。 Kiro IDE 建基於與 VS Code 相同的基礎。你的鍵盤快捷鍵、設定和擴充功能都可在數分鐘內直接帶過去。
Kiro 的優缺點
- spec 工作流程會先規劃，然後才寫任何程式碼
- Agent Hooks 可根據檔案事件自動執行任務
- VS Code 擴充功能和設定可順利匯入
- Autopilot 模式可在無需持續確認下建置
- Steering docs 可為 Kiro 提供專案上下文
- 支援多個 frontier model，包括 Opus 4.8
- MCP server 整合可原生連接外部工具
- 需要下載；免費層無法在瀏覽器中使用
- 50 free credits 消耗速度比想像中快
- 在需求細化階段曾出現一次逾時
評分細項
Kiro 在功能和實用性方面得分最高，因為它的 spec 驅動工作流程、agent hooks 和 autopilot 執行，使它比這裡評測過的其他 AI 編程工具更勝一籌。它在可及性和 credits 模型方面失分，這兩點在決定是否採用之前必須誠實看待。
| 功能 | 分數（滿分 10） | 評分原因 |
|---|---|---|
| 易用性 | 7.0 | 任何 VS Code 用戶都會感到熟悉；但需要下載，而且只面向開發者，令非技術用戶無法輕易使用 |
| 功能與實用性 | 9.5 | spec 工作流程、agent hooks、autopilot、MCP 整合、steering docs：是所有 AI 編程工具中最完整的一套功能 |
| 設計與自訂化 | 7.0 | 深色與淺色 IDE 主題；可透過 spec 編輯和 steering documents 對生成程式碼結構作出強力控制 |
| 性價比 | 6.5 | 免費層的 50 credits 在進行規劃期間已消耗到 4.28，甚至還未寫出一行應用程式碼 |
| 效能與可靠性 | 7.5 | 規劃輸出詳細而具體；在需求細化過程中，有一次於 7 minutes 24 seconds 發生逾時 |
| 整體 | 8.2 | Kiro 的 spec 工作流程是迄今評測過最有結構的 AI 輔助開發方式。這個分數反映了它真正的差異化，但也被有限的免費層和測試期間錄得的單一可靠性失誤所拉低。 |
Kiro 功能
- spec 驅動工作流程：需求、設計、任務、程式碼
- Agent Hooks 可根據檔案事件自動執行任務
- Steering documents 可為 agent 提供專案上下文
- Autopilot 模式可無需逐步確認地執行任務
- 支援 MCP server 以整合外部工具
- 首次啟動時可匯入 VS Code 設定
- 支援多模型，包括 Claude Opus 4.8
我的誠實 Kiro 評測：實測後的發現
大多數 AI app builder 都屬於以下兩類之一：
- 以視覺化方式，根據描述生成介面
- 或者以聊天形式，直接根據提示詞撰寫程式碼
Kiro 既不屬於這兩類，這也是為何評測它時需要採用不同的方法。
Kiro 是一個 agentic IDE。你不會把元件拖到畫布上，也不會在 30 秒後看到即時預覽。你得到的是一個本地開發環境，它會先規劃建置，再開始執行，產生需求、設計文件，以及由 agent 逐步跟進的結構化任務清單。
它產生的應用程式是你機器上的真實專案，檔案屬於你，並且使用你定義的技術棧。
為了測試這個流程是否真的有效，我在 Kiro 裡從零開始建立了一個物業管理平台。
提示詞涵蓋業主與租客驗證、物業與單位管理、租約追蹤、帶狀態更新的維修請求、Stripe 付款整合、電郵通知，以及附有報表的業主儀表板。這與用來評測 Rork、Figma Make、Uizard 和 Retool 的同一個提示詞相同，因此可以比較各工具如何處理真正的複雜度，而不是簡單例子。
這篇評測要回答的問題很明確：Kiro 的 spec-first 工作流程，是否比直接跳到程式碼的工具產生更有結構、更易維護的輸出？
以下是我的發現。
啟動 Kiro：要下載，不是開瀏覽器分頁
與此比較中評測過的其他 AI app builder 不同，Kiro 並不是在瀏覽器中運行。開始使用的方法是前往 kiro.dev，點擊 Downloads，選擇你的作業系統，然後在電腦上安裝應用程式。
我使用的是 Pop OS，一個以 Debian 為基礎的 Linux 發行版，所以我在下拉選單中選擇了 Debian (.deb) 套件。網站亦為其他 Linux 設定提供 Universal (.tar.gz) 套件。同一個下載頁面也提供 Windows 和 macOS 安裝程式。
實際上這代表：
- 首次使用需要本地安裝，而不是瀏覽器分頁
- 免費層沒有僅限網上使用的存取方式（網頁介面目前只供付費方案預覽）
- 對開發者來說，這不是問題
- 對任何拿 Kiro 跟瀏覽器式 builder 比較的人來說，都要把這點計入設定時間
安裝本身十分順利。沒有任何設定步驟，也不需要手動解決依賴關係，應用程式在標準套件安裝後便能乾淨啟動。
登入在你的瀏覽器中進行，而不是在應用程式內
IDE 第一次打開時，它不會在應用程式視窗內要求你登入，而是會將你重新導向到瀏覽器頁面，於那裡完成驗證。
登入畫面提供四種選項：
| 登入方式 | 適合對象 |
|---|---|
| 個人開發者和自由工作者 | |
| GitHub | 對已有帳戶的開發者來說最自然的選擇 |
| AWS Builder ID | 已在 AWS 生態系內的開發者 |
| Your Organization | 使用 SSO 的企業團隊 |
GitHub 選項與目標受眾配合得很好。大多數開發者本來就有 GitHub 帳戶，可以無需再建立新憑證便完成驗證。
在註冊前，有幾點值得知道：
- 透過 Google 或 AWS Builder ID（而非 AWS Identity Center）登入，會獲得 20 美元的 credit，並可於首次升級至付費方案時使用。這是一個只能使用一次的好處，選擇登入方式時值得考慮。
- 透過 “Your Organization” 登入會經由企業 SSO，適合需要集中式身份管理的團隊。
- 一旦登入，即表示你同意 AWS Customer Agreement、Service Terms、Privacy Notice，以及 AWS Intellectual Property License。由於 Kiro 是 AWS 產品，你的資料會按你所在地區在 AWS 區域之間處理。
上手流程：三個設定步驟，不足兩分鐘
完成登入後，Kiro 會在打開主 IDE 前先跑一個簡短的設定流程。步驟如下：
步驟 1：選擇主題。 Kiro Dark 或 Kiro Light。兩者都會在你確認前顯示帶有程式碼語法高亮的即時預覽。
步驟 2：設定 shell 整合。 這可讓你透過 kiro 命令，從終端機開啟任何專案。你也可以略過，稍後再設定。
步驟 3：從 VS Code 匯入。 Kiro 會載入你現有的 VS Code 擴充功能（任何在 Open VSX 上可用的）、設定和 keybindings。擴充功能會在上手流程繼續時於背景載入，因此不會卡在載入畫面。
其中最實用的是 VS Code 匯入。如果你多年來都在自訂 VS Code 環境，轉換時就不需要從零開始。這次我的匯入運作得很順利。
上手流程沒有包括任何對 Kiro 核心功能的介紹。它不會帶你了解 Specs、Agent Hooks 或 Steering Documents 是什麼。你會直接進入主畫面，然後自己摸索。對有經驗的開發者來說這是可以接受的，但也代表你第一次接觸這個工具最具特色的功能時，需要自行探索。
IDE 內部：令 Kiro 與眾不同的四個面板
Kiro IDE 看起來像 VS Code，因為它確實建基於相同基礎。檔案總管、編輯器分頁、終端機、搜尋列和選單列都完全如預期般運作。
Kiro 與一般 VS Code 安裝的分別，在於專屬左側面板，當中包含四個在任何 VS Code 擴充功能中都不存在的部分：
| 面板部分 | 作用 |
|---|---|
| Specs | 建立及管理規格文件（需求、設計、任務），以應付複雜建置 |
| Agent Hooks | 設定在檔案系統事件觸發時執行的自動化任務 |
| Agent Steering and Skills | 儲存指引文件，以在所有 session 中塑造 agent 的行為 |
| MCP Servers | 將外部工具和資料來源連接到 Kiro agent |
右側是聊天面板。你在這裡與 Kiro 互動，也會即時看到 credits 消耗。每次 agent 動作後，”Est.
Credits Used: 0.1, Elapsed time: 57s” 都會更新，令你清楚知道每個任務的成本。
在聊天輸入欄底部，有兩個控制項決定 Kiro 在每個任務上的行為：
- Model selector： 可選 Auto（Kiro 會為每個請求挑選最具成本效益的模型），或直接選擇特定模型，例如 Claude Sonnet 4.6 或 Claude Opus 4.8。
- Autopilot toggle： 開啟 Autopilot 時，Kiro 會撰寫及編輯檔案，而不會在每一步都等你批准。關閉時，Kiro 會在每個指令前暫停，並要求你 Trust、Reject，或手動 Run。
在物業管理平台測試中，我在規劃階段保持 Autopilot 開啟，在任務執行時則使用手動批准，以便獨立評估每一步。
結論： 對任何 VS Code 用戶來說，IDE 版面在幾分鐘內就能上手。左側的四個部分正是 Kiro 價值所在，而在第一次 session 前了解它們，決定你能從這個工具得到多少。
Steering Documents：在第一個提示詞前先給 Kiro 上下文
在新 Kiro 專案中，第一件要做的事不是開始建置，而是生成 steering documents。
我在送出任何提示詞前，先在 Kiro 面板點選 “Generate Steering Docs”。Kiro 掃描了空白的專案目錄，並在 .kiro/steering/ 下建立了三個 markdown 檔案：
| 檔案 | 內容 |
|---|---|
| product.md | 產品名稱、描述、核心領域概念，以及主要目標 |
| structure.md | 預期的資料夾結構與檔案組織慣例 |
| tech.md | 預期的技術棧、常用指令，以及編碼慣例 |
對於一個完全空白的專案，Kiro 推斷出合理的預設值：React with TypeScript、Next.js API routes、PostgreSQL、Prisma、Tailwind CSS，以及基於 JWT 的驗證。它同時標示 tech.md 和 structure.md 為佔位文件，待實際技術棧透過 scaffolding 確認後再更新。
這很重要，因為之後每個 agent 動作都會先讀取這些檔案才執行。當你把專案 scaffold 起來並確認真實技術棧後，更新 tech.md 便會令 Kiro 在之後的所有任務中自動套用那些慣例。
你也可以新增自己的 steering 檔案，用於 API 設計標準、命名慣例、部署規則，或任何你希望 agent 視為固定的約束。
Vibe Mode 與 Spec Mode：決定整個建置的關鍵選擇
當你為一個新建置打開聊天視窗時，Kiro 會在你輸入之前顯示兩種模式：
Vibe mode 讓你先聊天，再邊做邊建置。沒有規劃文件，沒有結構化輸出。最適合快速實驗、早期探索，或者需求仍在釐清中的任務。
Spec mode 則會在任何程式碼寫出之前先跑規劃流程。Kiro 會生成需求、技術設計文件，以及任務清單。只有在三者都檢視並批准後，它才會開始寫程式碼。最適合對可維護性有要求的生產級工作。
我為物業管理平台選擇了 Spec mode。提交提示詞後，Kiro 先問了兩個後續問題，然後才開始生成：
- “What do you want to start with?”（Requirements，標示為 recommended，或 Technical Design）
- “Is this a new feature or a bugfix?”（Build a Feature，recommended，或 Fix a Bug）
這些問題決定了之後所有內容的結構。選擇 “Requirements” 代表 Kiro 會先撰寫 user stories 和 acceptance criteria，然後才碰架構。
這個順序所產生的規劃產物，與先從 technical design 出發再反推需求，會是完全不同的。
Spec 工作流程：在任何程式碼之前先有需求、設計和任務清單
這就是 Kiro 值得認真評估的部分。
在選擇 “Requirements” 和 “Build a Feature” 後，Kiro 在 .kiro/specs/property-management-platform/ 內建立了 requirements.md 檔案。文件即時出現在編輯器中，我可以邊看邊讀。內容包括：
詞彙表： 12 個領域術語被精確定義，包括 Auth_Service、Property_Service、Lease_Service、Payment_Service、Maintenance_Service、Notification_Service 和 Dashboard_Service，每個都對應到一個計劃中的子系統。
平台描述： 文件記錄了 Landlord 與 Tenant 角色，並確認了技術棧：Next.js、TypeScript、PostgreSQL、Prisma、Tailwind CSS、Stripe 和 Docker。
生成初始文件後，Kiro 進行了自動細化步驟。它解析全部 12 項需求，並將平行 detailer sub-agents 分派到每一項，然後把 requirements.md 更新為每項需求的完整 acceptance criteria。面板即時顯示：”Refining requirements 12/12.”。
需求完成後，我點擊 “Continue” 並選擇 “Generate Design and Tasks”。Kiro 同時產生了 design.md 和 tasks.md。任務拆解是這次 session 最出色的輸出：
11 個任務群組，43 個子任務，按實作順序排列：
- 專案 scaffolding 與基礎架構
- 驗證（JWT、blacklist、middleware、頁面）
- 物業與單位管理
- 租客管理
- 租約管理、文件上載，以及 cron job
- 維修請求
- Stripe 付款與 webhook
- 電郵通知
- 業主儀表板與報告
- 共享 UI 元件與版面配置
- API 加固（rate limiting、CORS、health check、環境驗證）
每個子任務都包含精確的指令、檔案路徑，以及可追溯的需求參考。舉例來說，Task 1.1 直接在描述中引用了 Requirements R12（Docker）和 R10（REST API）。
規劃與執行之間的連結在整個流程中都清晰且可驗證。
相比之下，Rork 會直接跳過整個階段，從提示詞直接生成使用者介面。輸出質素的差異是看得見的：Kiro 的任務清單具體到足以交給人類開發者，讓對方清楚知道要按什麼順序構建哪些內容。
任務執行：Kiro 實際建造了什麼
在批准任務清單後，我點擊 Task 1.1：Initialize Next.js 14 project with TypeScript, Tailwind CSS, and ESLint 的 “Start task”。
Kiro 把 task 狀態更新為 “in progress” 到 tasks.md，然後把執行委派給 spec-task-execution sub-agent。agent 先檢查工作區，確認只有 .kiro spec 資料夾存在，尚未有 Next.js 專案，然後開始 scaffolding 專案。
在第一個執行循環內，檔案樹已填充為：
- package.json 列出 Next.js、React 19.2.4、TypeScript 和 Tailwind 依賴項
- tsconfig.json、eslint.config.mjs、next.config.ts
- src/ 和 public/ 目錄結構
- AGENTS.md 和 CLAUDE.md，由 Kiro 生成作為專案的 agent 指引檔案
- README.md
CLAUDE.md 值得一提：Kiro 是 AWS 產品，但其底層運行的是 Anthropic 的 Claude model。CLAUDE.md 是 Claude-powered agent 儲存專案專屬行為指引的方式。即使在 AWS 基礎設施的脈絡下，生成的 scaffolding 仍反映了其底層 model。
在任務清單檢視頂部，有一個 “Run all tasks” 按鈕，可在啟用 Autopilot 時按順序執行全部 43 個子任務。
我逐個執行任務，以評估每一步。對於一個已批准計劃的真實專案而言，直接執行全部任務並在每個 group 完成後檢視輸出，是合理且省時的工作流程。
Kiro 在執行期間產生的每個檔案，都是我本地專案目錄中的真實檔案，從第一秒起就歸我擁有並可編輯。這與 Figma Make 或 Uizard 等瀏覽器式 builder 是重要分別，因為那些工具的輸出要不是設計資產，就是你無法在本地完全控制的託管應用程式。
第七分鐘的逾時：這對可靠性意味著什麼
我要坦白說，因為這件事發生在測試最重要的部分。
Kiro 在完成全部 12 項需求細化並接受 requirements.md 的編輯後，agent 逾時了。聊天面板中的錯誤訊息顯示：
“The request timed out. Please try again. (Conversation ID: 29d25548-c3ce-414c-8f57-702124c7fec6). Elapsed time: 7m 24s.”。
這發生在需求階段與設計生成階段之間。逾時前完成的工作有被保存。沒有任何需求遺失。
在確認錯誤後，我點擊 “Continue” 並選擇 “Generate Design and Tasks”。Kiro 順利恢復，沒有重跑需求步驟，清楚產生了兩份文件，並在餘下 session 中正常運作。
需要留意的背景：
- 逾時發生在一個複雜提示詞上，當中包括 12 個不同需求領域，而且有並行細化進行；較簡單的任務不大可能耗時這麼久。
- Kiro 目前仍處於 preview，而預覽階段工具在複雜任務邊界上的可靠性本來就有其特徵。
- 恢復過程很乾淨。檢查點系統保留了所有已完成工作，而下一步立即可跑。
話雖如此，在這個工具最具特色的功能上進行到七分鐘時發生逾時，確實是一種實際的體驗失敗。如果你在趕期限，一個會停下來並需要手動重試的工具，即使恢復順利，也會令人煩躁。
Agent Hooks：不需要被要求就會執行的自動化
Agent Hooks 並不出現在與此比較中評測過的其他 AI 編程工具裡，值得特別留意，因為它代表了一種不同的 AI 輔助思維方式。
Hook 是一個在檔案系統事件發生時自動執行的任務。你用自然語言描述行為，Kiro 會把它轉成事件監聽器，而之後只要觸發條件符合，這個行為就會在背景執行。無需下指令，也無需提醒。
Hooks 可以做的例子：
- 在檔案儲存時：為任何沒有測試檔的 component 生成基本測試
- 在檔案儲存時：執行程式碼清理或格式檢查
- 在建立檔案時：自動為新函式生成文件
- 在字串常數變更時：無需手動操作更新本地化檔案
Hook 會儲存在 .kiro/hooks/ 內，作為可編輯檔案。如果你想調整觸發條件或指令，可以直接編輯該檔案。這個設定是透明的，而且可與專案其餘部分一起進行版本控制。
最實用的例子是 save-on-test：開發者經常把寫測試拖到 sprint 最後，一個在 component 儲存時悄悄補上基本測試的 hook，便可直接消除這個決定。下一次儲存後，測試便會出現在檔案樹中，而你無需做任何事。
Credit 消耗：免費層實際能得到多少
credit 模型是 Kiro 在你決定投入工作流程前，最需要仔細理解的部分。
免費層提供 50 credits。一次物業管理平台 spec session 的消耗如下：規劃階段已用了 4.28 credits，涵蓋需求、設計文件以及完整的 43 任務清單，而這時甚至還未寫出一行應用程式碼。
按這個消耗率：
| 情境 | 預計可用免費層覆蓋次數 |
|---|---|
| 只做規劃 session（不執行程式碼） | 約 11 次 session |
| 規劃加部分任務執行 | 3 至 5 次 session |
| 完整的 spec 到執行流程，針對複雜專案 | 最多 1 個完整專案 |
在註冊前要理解的重點機制：
- credits 不會結轉。月尾未用完的部分會全部消失。
- 所有付費方案預設都關閉超額收費。你必須在達到上限前於 Settings 中啟用，否則 Kiro 會在中途停止工作。
- 模型選擇會影響消耗速度。以 Claude Sonnet 4.6 執行同一任務，比 Auto 模式貴 1.3 倍 credits。Opus 模型則更貴。
- 免費層用戶可使用 Claude Sonnet 4.5，以及一組開源模型，包括 Qwen3 Coder Next、DeepSeek v3.2 和 MiniMax 2.1。付費層用戶則可解鎖 Claude Sonnet 4.6、Claude Opus 4.6 和 Claude Opus 4.8。
- credit 使用量會在聊天面板中於每次 agent 動作後即時顯示，並且每五分鐘更新一次訂閱儀表板。
即時 credit 追蹤器（每次任務後顯示 “Est. Credits Used: 0.1, Elapsed time: 57s”）是一項其他同類工具目前都沒有的透明度功能。你可在每個任務執行期間清楚知道其成本，從而決定對某個任務應該使用 Auto 模式還是特定模型。
Kiro 定價與方案
Kiro 採用基於 credits 的模式，共有五個層級，從提供固定每月配額的免費方案，到為專業日常使用而設的高容量方案。
所有付費方案都包括 premium 模型存取、啟用 pay-per-use overage 的選項，以及完整的 Kiro 功能集，包括 specs、hooks、autopilot 和 CLI 存取。
選擇方案前要知道的事：
- 免費方案提供固定的每月 credits 配額，無需信用卡。它不會過期，但一個複雜的 spec session 就會令配額明顯減少。
- 首次使用 Google 或 AWS Builder ID（而非 AWS Identity Center）從免費升級到任何付費方案時，你會獲得 20 美元 credit，用於抵扣訂閱費用。這項優惠只可使用一次。
- Kiro 會在每個曆月第一天結算。月中升級代表需支付按比例計算的費用，但可即時使用新方案的完整 credit 上限。
- 所有付費方案均可按固定每額外 credit 費率使用超額收費，但預設為關閉。若在達上限前沒有到 Settings 啟用，Kiro 便會在 credits 用完時暫停你的工作。
- 未使用的 credits 不會結轉到下個月。
- 每位開發者都需要自己的訂閱。現時沒有共享團隊 seat 方案。團隊帳單功能標示為即將推出。
- Kiro 的標準政策是不會就月中取消提供退款。存取權會維持至計費周期結束。只有在帳單錯誤情況下，才會按個別情況考慮退款。
- 只接受信用卡付款。
- GovCloud (US) 的定價大約比標準定價高 20%，而且該環境不提供免費層。GovCloud 存取需要付費方案及透過 AWS IAM Identity Center 進行企業驗證。
- 網頁介面目前處於 preview，僅供付費用戶使用。無論你在 IDE、CLI 還是網頁上工作，credits 的消耗速率都相同。
哪種方案適合哪類用戶： 免費方案足以進行真實評估。若要在實際專案上持續開發，則需要付費方案，避免在中途耗盡。高階方案則適合每週進行多次完整 spec session，或同時處理多個複雜專案的開發者。
Kiro 的替代方案
Kiro 最直接的競爭對手是 Cursor，這是一個以 VS Code 為基礎、深度把 AI 融入開發環境的 AI 編程編輯器。
核心差異在於工作流程哲學。Cursor 的設計目標是加速你原本就在做的事：你寫程式，而 Cursor 提供輔助。
Kiro 則先處理規劃階段：agent 會在寫任何內容之前先定義需要建造什麼。如果你最困擾的是 AI 聊天與編輯器之間的反覆切換速度，那 Cursor 更直接解決這個問題；如果你最困擾的是 AI 生成的程式碼缺乏結構、難以維護，那 Kiro 的 spec 工作流程就更切題。
| 功能 | Kiro | Cursor |
|---|---|---|
| 易用性 | 對 VS Code 用戶來說熟悉；spec 工作流程增加學習曲線 | 對 VS Code 用戶來說熟悉；上手阻力較低 |
| 最適合 | 適合生產項目的結構化、spec 驅動建置 | 在現有 codebase 內快速進行 AI 輔助編輯與 agent 任務 |
| 後端與資料 | 建立真實本地專案，完整控制整個技術棧 | 編輯並擴展現有專案檔案，完整控制整個技術棧 |
| 設計彈性 | 沒有視覺化 builder；輸出真實、由本地擁有的程式碼 | 沒有視覺化 builder；輸出真實、由本地擁有的程式碼 |
| 定價模式 | 基於 credits；50 個免費 credits；所有使用量均從每月 credit 配額扣除 | 自 2025 年 6 月起採用 credit 模式；Auto 模式無限；選擇 premium model 會從每月 credit 池扣除 |
最終結論：Kiro 值得嗎？
Kiro 的突出之處，在於它把規劃放在編碼之前。它的 specification 工作流程、steering documents 和任務拆解，都能產生比直接跳到實作的 AI 工具更有結構、也更易維護的 codebase。Agent Hooks 亦是一大亮點，能提供超越單一提示詞、持續在背景運作的工作流程自動化。
取捨在於學習曲線和價格。免費層對大型專案而言太有限，而開發者也需要習慣在 IDE 內工作。測試期間我亦遇到一次逾時，不過 Kiro 成功恢復，沒有遺失進度。
如果你是要開發生產軟件的開發者，Kiro 是現時最強的 AI 編程工具之一。如果你想要的是簡單的 no-code app builder，那它就不適合你。
