Kiro 搭 HealthOmics，生資流程少卡關

生資 workflow 很磨人。你要懂 biology，也要會 WDL、Nextflow，還得顧雲端設定。AWS 這次把 Kiro 接上 AWS HealthOmics，直接把痛點搬進 IDE。AWS 說，workflow 建置和 migration 的速度，能拉到 2 倍以上。還有一個 RNA-seq migration，從數天壓到半天內。

講白了，這不是在比誰 prompt 寫得帥。這是在比誰少踩坑。生資工程最貴的，常常不是寫 code，而是等跑完才發現 container 壞了、directive 不支援，或參數根本不合規。

這次 AWS 的做法很直白。它想把平台知識塞進工具裡。讓你不用每次都重新教 AI 一遍 HealthOmics 規則。這點我覺得蠻實際的。

AWS 這次到底做了什麼

核心是 AWS HealthOmics extension for Kiro，再加上 AWS HealthOmics Kiro Power。兩個東西合起來，讓 Kiro 多了 HealthOmics 的語境。

這代表 IDE 不再只會補字。它還能幫你看部署、驗證、除錯，甚至更新 workflow。對一般 app 開發者來說，這很像把 lint、deploy、runbook 全塞回編輯器。

對生資團隊來說，這種整合很重要。因為一個錯誤常常不是小 bug，而是幾小時 compute 白燒。你不想等到跑完才知道 container image 不對。你想在寫的時候就被攔下來。

• 支援 Nextflow 和 WDL
• 提供 IntelliSense 和即時診斷
• 內建 HealthOmics Explorer，可看 workflow 和 run
• 可先檢查不支援的 directive 與 container 格式
• 透過 Model Context Protocol 做自然語言操作

這裡的重點不是 AI 很會聊。重點是它知道你在 HealthOmics 裡做事。這種 context 才值錢。沒有 context 的 AI，常常只是在猜。

而且 AWS 沒叫你改用自家新語言。它還是吃 Nextflow 和 WDL。這很務實。因為生資團隊早就有既有 pipeline，不可能為了 AI 再重寫一輪。

為什麼 MCP 這層很關鍵

MCP 是這次最有意思的地方。因為它決定 AI 回答的品質。沒有 domain context，模型可以寫 code，但常常漏掉平台限制。對 HealthOmics 來說，漏一條規則就可能整個部署失敗。

AWS 說，Kiro Power 會自動設定 HealthOmics MCP server，還會加上 steering guides。這些 guide 會管第一次設定、spec-driven 開發、跨平台 migration。也就是說，Kiro 不只會寫，還知道怎麼包、怎麼 deploy、怎麼查錯。

這種設計很像把資深同事的腦袋，做成工作區設定。你不用每次問「這個 container 可以嗎」。工具自己先幫你擋一次。這對團隊協作也有幫助，因為規則會比較一致。

“You can ask Kiro to create a totally new workflow definition from only a natural language description,” AWS wrote in the blog post announcing the extension and power.

這句話很直球。AWS 想把起點放在自然語言，再一路走到 spec、部署、執行。流程不是聊天而已。它是把聊天接到可跑的 pipeline。

我覺得這種模式比空泛的 AI demo 實在。因為它把問題縮小了。不是問 AI 會不會萬用。是問它懂不懂這個系統。

跟舊流程比，差在哪

傳統生資流程很像打地鼠。你改一版，跑一次，等很久，然後爆掉。再改，再跑，再等。這種迴圈很耗人。也很耗雲端費用。

AWS 在文章裡給了幾個數字。這些數字比形容詞有用多了。因為你可以直接拿來估工時，也能拿來算成本。

它的說法很簡單：把錯誤提早抓出來，把重複工作交給工具。這樣一來，很多本來要靠手動檢查的步驟，就能在 editor 裡先過濾掉。

• 一般 workflow 建置與 migration：速度超過 2 倍
• 一個 RNA-seq migration：從數天縮到半天內
• 失敗診斷：從 run 後才知道，改成寫的時候先檢查
• 部署方式：直接從 IDE 送出，不用一直切 console

這種差異很像一般軟體開發從命令列，走到完整 IDE 的過程。差別是，生資的錯誤代價更高。你不是只浪費時間。你還可能浪費樣本、算力，甚至研究排程。

如果拿競品來看，Nextflow 本身已經很成熟。WDL 也有穩定社群。AWS 的差別，不在語言本身，而在整合層。

它想做的是把 workflow 語言、雲端資源、AI 助手綁在一起。這跟單純賣一個 chatbot 不一樣。它比較像工作台。

這件事對 AI 工具的意思

這次更新其實在講一件事。AI coding 工具要有領域知識，才真的有用。通用模型很強，但不代表懂每個雲端服務的規則。

在科學軟體裡，這件事更明顯。你寫得對，不代表能跑。你跑得動，不代表合規。你合規，也不代表省錢。這些條件常常同時存在。

所以 HealthOmics extension 的價值，不是它會聊天。是它知道 HealthOmics 的邊界。知道什麼可以做，什麼不行。這種知識，才是生資團隊真正需要的。

我也覺得這會影響其他領域。像 lab automation、影像 pipeline、金融風控流程，都很吃 domain context。未來如果 AI 工具只會泛用回答，競爭力會很有限。

真正有用的工具，會把模型包進工作流程。不是叫你換腦袋，而是叫工具先學會你現在的規矩。

這波更新背後的產業脈絡

生資軟體本來就很碎。研究人員、資料工程師、雲端工程師，常常要一起配合。每個人看問題的角度都不同。這也是 workflow 開發一直難搞的原因。

另外，雲端算力越來越貴。尤其是長時間跑的分析。像 RNA-seq、variant calling、metagenomics，任何一個節點出錯，都會拖掉整條鏈。這時候，早點發現問題，比事後修正重要很多。

從產業角度看，AWS 這次是把 AI 助手往垂直場景推。不是再做一個萬用聊天介面，而是把它塞進既有平台。這種做法比較容易被企業買單。因為它能直接對到工時、錯誤率、和 cloud bill。

如果你問我，這類工具會不會取代生資工程師？我覺得不會。它比較像把重複勞動壓縮掉。人還是要負責判斷。尤其是資料品質、實驗設計、和結果解讀，AI 還差很遠。

但如果你問它會不會改變團隊寫 pipeline 的方式？我覺得會。至少從現在開始，大家會更期待 IDE 直接懂平台，而不是只會幫你補幾行 code。

接下來該看什麼

如果你已經在用 HealthOmics，我會先試 Kiro 和 extension。不要先想大改架構。先拿一條現有 pipeline 試水溫。看它能不能真的幫你抓錯、補 spec、縮短 migration。

如果你是做一般軟體開發，也可以把這次當成一個訊號。AI 工具正在往「懂場景」走。下一個有用的助手，不一定是最會講話的那個。可能是最懂你專案規則的那個。

我自己的判斷很直接。這類整合如果真的穩，接下來 12 個月，會有更多雲端服務學這一套。問題不是會不會跟上。問題是你的團隊準備好把流程標準化了沒。

你如果是生資或資料平台團隊，現在就該問一句：我們的 pipeline，有沒有哪一段，其實可以先交給工具處理？