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

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

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

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

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

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

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

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

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

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

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

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

「Neurosymbolic」可以點理解？

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

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

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

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

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

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

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

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

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

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

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

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

已確認同未清楚嘅界線

目前可以較肯定嘅事有幾點：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。

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

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