AWS Kiro Requirements Analysis：AI 落手寫 Code 前先驗清需求

Parallel Task Execution：加快執行，但唔等於驗證正確性

Parallel Task Execution 係同一輪 Kiro 更新之一。SiliconAngle 指 AWS 想移除架構規劃同 code execution 之間嘅樽頸，而 Parallel Task Execution 係其中一項幫開發者加快推進嘅能力。^[4]

不過，現有資料冇詳細公開 Kiro 內部點樣排程、點樣切分並行任務。所以較穩陣嘅講法係：Parallel Task Execution 主要係提升執行速度同工作流效率，而唔應該被理解成一個需求正確性驗證機制。^[4]

Quick Plan：縮短由想法到計劃嘅距離

Quick Plan 亦係今次更新中被提到嘅 streamlined workflow capability，目標同樣係令開發者更快由 planning 去到 execution。^[4]

如果將三個功能放埋一齊睇，分工幾清楚：Requirements Analysis 負責檢查計劃本身有冇問題；Parallel Task Execution 同 Quick Plan 就負責令計劃成形同執行得更順。^[6][4]

點解呢件事同 Kiro 嘅 spec-driven 模型咁夾？

AWS 將 Kiro 定位為一個 agentic coding service：佢可以同開發者協作，將 prompt 變成詳細 specs，再變成可運行 code、文件同測試。^[1]

Kiro 自家 specs 文件亦講得好清楚：specs 係一種結構化 artifact，用嚟將 feature 或 bug fix 嘅開發流程形式化，將高層次想法變成有追蹤、有責任歸屬嘅 implementation plan。^[2]

呢啲 specs 可以將需求拆成 user stories 同 acceptance criteria，支援 design docs，亦可以追蹤唔同 task 嘅 implementation progress。^[2] Kiro 產品頁亦指，佢會將自然語言 prompt 轉成以 EARS notation 表達嘅 requirements 同 acceptance criteria，令開發者意圖同限制更明確。^[9]

所以 Requirements Analysis 唔係突然加落去嘅外掛式功能，而係補強 Kiro 原本嘅核心假設：AI 唔應該一收到 prompt 就即刻寫 code；中間應該有一層 spec，先將需求講清楚，再檢查需求本身，最後先進入 implementation。^[6][2]

「Neurosymbolic」可以點理解？

公開資料支持一個高層次講法：Kiro 用大型語言模型協助開發，而 Requirements Analysis 被報道為結合 LLM 解讀能力同額外檢查機制。AWS 文件指 Kiro 建基於 Amazon Bedrock，並使用多個 foundation models 完成任務。^[1] GeekWire 報道亦指 Requirements Analysis 結合大型語言模型同其他檢查 machinery；另外有用戶生成嘅技術文章將呢種思路稱為 neurosymbolic AI，即結合 LLM 嘅語言理解能力同形式數學邏輯。^[6][13]

但要講清楚：現有來源未有提供一份 AWS 官方技術白皮書，逐步確認「LLM → EARS → SMT-LIB → semantic entropy → 指定 SMT solver」係完整內部流程。所以以下較適合視為一個保守、來源可支持嘅理解框架，而唔係已完全公開嘅產品內部設計。

1. 自然語言先變成結構化需求。 Kiro 由自然語言 prompt 開始，將想法整理成 specs、requirements 同 acceptance criteria。^[1][9]
2. EARS notation 令表述更規範。 Kiro 網站指 EARS notation 用嚟令意圖同 constraints 更明確，減少自然語言需求太鬆散嘅問題。^[9]
3. 形式化步驟會將需求變成邏輯約束。 如果要做形式檢查，結構化需求需要被轉成 solver 可讀嘅 representation。SMT-LIB 就係一種同 SMT solvers 互動嘅標準語言，而 SMT solvers 係用嚟解 logical constraint problems，亦特別適合軟件推理相關工作。^[21]
4. SMT solver 檢查約束是否可同時成立。 SMT solver 可以判定 SMT-LIB benchmark library 入面問題係 satisfiable 定 unsatisfiable。^[18] 套用到需求場景，如果一組已編碼需求變成 unsatisfiable，就代表呢批需求唔可能同時為真，亦即存在矛盾。
5. Semantic entropy 呢一環未有足夠公開證據。 現有來源支持 Requirements Analysis 目標係捉矛盾同缺口，亦支持 Kiro 使用 EARS notation。^[6][9] 但未有獨立資料確認 AWS 已將 semantic entropy 作為正式、公開記載嘅模糊度訊號；所以呢點應當視為報道或推論層面，而唔係已被完整驗證嘅產品細節。

呢類檢查可以證明乜？又證明唔到乜？

最關鍵嘅限制係：形式化分析只能檢查「被表示出嚟」嘅需求。如果自然語言轉成邏輯約束嗰一步本身漏咗、錯咗，solver 之後嘅結果都可能睇唔到真實世界嘅問題。^[21][18]

對於矛盾，SMT solver 嘅故事相對直接：如果兩條已編碼需求唔可能同時成立，成組 constraint 就有機會變成 unsatisfiable。^[18]

對於「缺口」或者「漏 case」，問題會難好多。Checker 只有喺 domain、狀態、條件同預期行為被建模得夠完整時，先有機會指出邊啲情況冇覆蓋。^[6][21]

至於模糊需求，Kiro 使用 EARS notation 確實可以幫助將 intent 同 constraints 講得更明確。^[9] 但根據現有資料，未見 AWS 公開承諾 Requirements Analysis 能夠形式化保證偵測所有 ambiguous requirements。

對開發者工作流有乜實際影響？

實務上，Kiro 嘅流程會變得更加「前重後輕」。以前用 AI coding assistant，好多人會先叫 AI 寫 code，再靠 review、測試同 debug 慢慢修。Kiro 嘅方向係反過來：先將需求、acceptance criteria、design 同 tasks 整理好，然後先寫 code。^[1][2]

Requirements Analysis 就係加喺呢個前段嘅 validation step；Parallel Task Execution 同 Quick Plan 就主力處理計劃成形之後，點樣更快推進到 implementation。^[6][4]

換句話講，AWS 想令 Kiro 同時做到兩件事：一方面更有工程紀律，唔好一開始就亂寫；另一方面又唔想 spec-driven development 變成慢吞吞嘅文件流程，所以再用 Quick Plan 同 Parallel Task Execution 減少摩擦。^[6][4]

已確認同未清楚嘅界線

目前可以較肯定嘅事有幾點：AWS Kiro 係 spec-driven、agentic coding service；佢會將 prompt 變成 specs，再支援 code、documentation 同 tests；Kiro 會用 EARS notation 表達 requirements 同 acceptance criteria；今次更新加入 Requirements Analysis、Parallel Task Execution 同 Quick Plan。^{[1][2][9][6][4]}

未完全清楚嘅，就係 Requirements Analysis 內部架構。現有來源支持高層次嘅 neurosymbolic framing 同形式推理方向，但未有 AWS 官方技術規格逐步證明 LLM、EARS notation、SMT-LIB formalization、semantic entropy 同某個具體 SMT solver 係點樣串成一條完整產品 pipeline。^[13][21][18]

所以，最穩陣嘅理解係：Requirements Analysis 係 AWS Kiro 用嚟提早檢查需求嘅新功能，方向係以更形式化嘅方式捉矛盾同缺口；至於完整內部機制，仍然只係部分公開。