[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-baz-spec-review-agent-bedrock-agentcore-zh":3,"article-related-baz-spec-review-agent-bedrock-agentcore-zh":30,"series-industry-16b6ff6e-a48b-4fac-8f8f-45ea58449a83":82},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"16b6ff6e-a48b-4fac-8f8f-45ea58449a83","baz-spec-review-agent-bedrock-agentcore-zh","Baz 怎麼把規格變成合併檢查","\u003Cp data-speakable=\"summary\">我拆 Baz 的做法：把 \u003Ca href=\"\u002Ftag\u002Ffigma\">Figma\u003C\u002Fa>、Jira、瀏覽器預覽串成逐條檢查，讓 PR review 不再只看 diff，而是直接驗證產品意圖。\u003C\u002Fp>\u003Cp>我用過一堆 \u003Ca href=\"\u002Ftag\u002Fcode-review\">code review\u003C\u002Fa> 流程，老實講，很多都很會演。diff 看起來乾淨、測試也過了、CI 綠燈亮著，結果一進預覽環境就開始露餡。按鈕位置不對、空狀態文案不對、某個互動步驟根本沒出現。最煩的是，大家還會先誇一句「這個 PR 很整齊」，好像整齊就等於做對。不是啊，review 如果只看程式碼長相，不看產品意圖，那它其實只是在挑字體，不是在驗收。\u003C\u002Fp>\u003Cp>我看到 Baz 這篇關於用 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fmachine-learning\u002Fhow-baz-improved-its-ai-agent-code-review-accuracy-using-amazon-bedrock-agentcore\u002F\">Amazon Bedrock AgentCore\u003C\u002Fa> 提高 \u003Ca href=\"\u002Ftag\u002Fai-agent\">AI agent\u003C\u002Fa> code review 準確度的文章時，心裡只有一個反應：對，這才像在做事。它不是把\u003Ca href=\"\u002Fnews\u002Fminimax-m3-triple-capability-open-model-zh\">模型\u003C\u002Fa>調得更會講漂亮話，而是把 review 的判斷基準改掉。它把 \u003Ca href=\"https:\u002F\u002Fwww.figma.com\u002F\">Figma\u003C\u002Fa> 和 \u003Ca href=\"https:\u002F\u002Fwww.atlassian.com\u002Fsoftware\u002Fjira\">Jira\u003C\u002Fa> 拉進來，拆成細粒度檢查，再到瀏覽器裡看實際跑起來的介面。這種做法很土，但土得很對。\u003C\u002Fp>\u003Ch2>別再把 diff 當成完整真相\u003C\u002Fh2>\u003Cblockquote>「Baz 想把缺少的那一層驗證自動化，把意圖、行為與實作放進同一條 review 流程。」\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：他們不再假裝 code review 可以單獨回答產品問題。diff 只能告訴你「改了\u003Ca href=\"\u002Fnews\u002Fwhy-small-businesses-should-use-ai-for-admin-zh\">什麼\u003C\u002Fa>」，不能可靠地告訴你「是不是符合設計」、「是不是滿足驗收條件」、「是不是保住了 PM 和設計師在意的互動細節」。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780762739603-v006.png\" alt=\"Baz 怎麼把規格變成合併檢查\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我自己最常遇到的爛尾場景，就是某個元件改完了，測試也綠了，大家就以為差不多了。結果一打開預覽，才發現 spacing 不對、disabled 狀態沒出現、某個流程多了一步。不是程式碼不對，是 review 的問題定義就錯了。你如果只盯著 diff，永遠只會得到「程式有變」，不會得到「產品有沒有做對」。\u003C\u002Fp>\u003Cp>Baz 的思路是把 review 從「程式驗證」升級成「產品驗證」。這句聽起來很大，但實作上其實很務實：先把需求來源抓進來，再看跑起來的系統是不是跟需求對得上。這才是 AI reviewer 真正該做的事，不然它只是會講話的 lint tool。\u003C\u002Fp>\u003Cp>實操上，我會先把 reviewer 的輸入改掉：不要只餵 PR diff。至少要把設計稿、工單、驗收條件、預覽連結一起丟進去。沒有產品意圖，\u003Ca href=\"\u002Ftag\u002Fagent\">agent\u003C\u002Fa> 只能猜；而猜得很像的東西，通常最害人。\u003C\u002Fp>\u003Ch2>Figma 和 Jira 才是規格，不是聊天串\u003C\u002Fh2>\u003Cblockquote>「規格子代理會同時讀取來自 Figma 的視覺規格，以及來自 Jira 的功能規格。」\u003C\u002Fblockquote>\u003Cp>這句話我很買單，因為它直接點出真實世界的 truth source 在哪裡。不是 Slack 討論串，不是會議記憶，不是某個人腦中模糊的「我記得應該是這樣」。真正能拿來判斷的，還是設計系統、工單、驗收條件這些有結構的東西。\u003C\u002Fp>\u003Cp>也就是說，Baz 不是讓 agent 自己幻想規格，而是讓它去讀兩種不同的來源。Figma 提供視覺意圖：排版、間距、層級、狀態、元件長相。Jira 提供功能意圖：使用者能不能完成任務、\u003Ca href=\"\u002Fnews\u002Fwhy-minimax-m3-matters-long-context-model-zh\">什麼\u003C\u002Fa>算 done、哪些 edge case 要管。少了任何一邊，review 都會歪掉。只看 Figma，會變成挑像不像；只看 Jira，會變成只管功能過不過，不管畫面是不是整個壞掉。\u003C\u002Fp>\u003Cp>我很少看到團隊真的把這兩個來源整合好。多數時候是設計師在 Figma 改了，工程師看 Jira 做，最後 reviewer 只能靠肉眼補洞。這種流程很累，而且很容易漏。Baz 的做法比較像把大家本來就分散在不同系統裡的真相，拉回同一個檢查面上。\u003C\u002Fp>\u003Cp>如果是我自己要抄，我會先做一個需求匯入層，把 Figma frame、Jira acceptance criteria、相關截圖和註解都轉成可檢查的條目。每條條目都要能回指原始來源。因為只要不能回指，後面所有判斷都會變得很玄。玄的東西，最後通常都只能靠人肉拍板。\u003C\u002Fp>\u003Cul>\u003Cli>視覺規格：Figma frame、元件狀態、字級、間距、層級、色彩。\u003C\u002Fli>\u003Cli>功能規格：Jira 驗收條件、流程步驟、例外情境、完成定義。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>把一個功能拆成很多小判決\u003C\u002Fh2>\u003Cblockquote>「系統接著會啟動彼此隔離的子代理工作者，每個工作者對應一條需求，專門驗證那條需求。」\u003C\u002Fblockquote>\u003Cp>這種拆法我很認同，因為一個大 agent 想一次看完整個功能，最後通常只會變成一坨模糊印象。它會記錯、漏看、腦補，然後講得像自己很有道理。Baz 把工作切成一條需求一個子代理，這很無聊，但也很有效。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780762741960-5wts.png\" alt=\"Baz 怎麼把規格變成合併檢查\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>白話講就是：不要問「這個功能整體有沒有做好」，要問「這一條驗收條件有沒有被滿足」。前者太大，後者才可操作。當 agent 只負責一件事，它才比較不會飄，也比較好 debug。哪一條失敗、哪一條需要人工複查，一眼就看得出來。\u003C\u002Fp>\u003Cp>我以前碰過那種 review 系統，輸出一長串像論文摘要，看到最後還是不知道它到底在反對什麼。是規格不清楚？是 browser 操作失敗？還是模型自己腦補？完全拆不開。子代理的價值就在這裡：把大而空的判斷，切成可以追的單位。這樣你才能真的修，不是只會安慰自己「AI 有看過」。\u003C\u002Fp>\u003Cp>而且 Baz 後面還有彙總報告，這點也很重要。人不想看 20 段 agent 對話，他想看結論、證據、下一步。子代理負責辛苦幹活，彙總器負責把結果整理成團隊能用的格式。這才是正常的工程流程，不然你只是把噪音自動化。\u003C\u002Fp>\u003Cp>實作上，我會先定義需求 schema，再讓每個 worker 只處理一條需求。輸出也要限制成 pass \u002F fail \u002F needs_human_review，再附證據。千萬不要讓摘要 agent 自己編故事，因為一旦讓它自由發揮，最後就會產生一份看起來很完整、其實完全沒用的漂亮謊言。\u003C\u002Fp>\u003Cul>\u003Cli>好的工作單位：一條驗收條件、一個 UI 狀態、一條互動路徑。\u003C\u002Fli>\u003Cli>不好的工作單位：「幫我 review 整個功能」或「看起來對就好」。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>真正的答案在瀏覽器，不在原始碼\u003C\u002Fh2>\u003Cblockquote>「實作子代理是這個架構的核心……它們會在實際的預覽環境中渲染真正的實作，並以視覺方式驗證 UI 是否符合 Figma 設計，以及功能是否符合 Jira 規格。」\u003C\u002Fblockquote>\u003Cp>這段是我最在意的。靜態分析有用，但它永遠看不到瀏覽器裡真正在發生什麼。Baz 用 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fbedrock\u002Fagentcore\u002F\">Amazon Bedrock AgentCore\u003C\u002Fa> 的瀏覽器工具打開預覽環境、看 DOM、模擬事件、對照規格。這才是該驗證產品行為的層級，因為使用者就是活在這一層。\u003C\u002Fp>\u003Cp>也就是說，agent 不再只是讀 code，而是會點、會輸入、會觀察畫面變化。這很重要。很多 bug 在 code review 裡根本看不出來，因為程式碼長得很合理；真正出事，是 app 跑起來之後，state 變了、畫面沒跟上、互動流程卡住。這種問題，瀏覽器裡才會露出來。\u003C\u002Fp>\u003Cp>我自己最常撞到的就是表單、modal、條件式渲染、disabled 狀態這些小東西。程式碼都在，元件也 render 了，但狀態切換錯了，或某個控制項被動畫蓋掉，或某個步驟根本不會出現。這些東西不是看 diff 就能抓到的。你要真的打開預覽，真的去操作，才知道有沒有鬼。\u003C\u002Fp>\u003Cp>AgentCore 在這裡扮演的角色也很務實：隔離、沙箱、可重複執行。因為一旦讓 agent 進瀏覽器，你就得控制它不要亂跑、不要吃到別人的 session、不要依賴某台開發機的怪狀態。這些都不是模型問題，是執行環境問題。\u003C\u002Fp>\u003Cp>實操上，我會把 review agent 接到真實的 preview deployment，再讓它像使用者一樣操作頁面。能用 browser automation 驗的，就不要只靠 code 讀心。像畫面狀態、互動流程、輸入回饋、錯誤提示，全部都應該在瀏覽器層驗證。只看原始碼的 reviewer，基本上就是瞎子。\u003C\u002Fp>\u003Cp>如果你要找工具起點，可以先看 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fbedrock\u002F\">Amazon Bedrock\u003C\u002Fa> 做模型推理、\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fbedrock\u002Fagentcore\u002F\">AgentCore\u003C\u002Fa> 做瀏覽器執行，再接一個盡量接近正式環境的 preview。預覽如果是假的，review 也會跟著假。\u003C\u002Fp>\u003Ch2>把模型留給判斷，別叫它管機器\u003C\u002Fh2>\u003Cblockquote>「Amazon Bedrock AgentCore 成了建立能驗證真實產品行為的 AI code reviewer 的基礎。」\u003C\u002Fblockquote>\u003Cp>Baz 這裡做對的一點，是把模型的工作範圍收得很乾淨。LLM 負責解讀規格、比對觀察結果、下判斷；AgentCore 負責瀏覽器執行和隔離。這個分工很重要，不然系統很快就會變成一個需要人類照顧的模型玩具。\u003C\u002Fp>\u003Cp>翻成白話就是：模型應該做 reasoning，不該做 infrastructure babysitting。它不需要去煩瀏覽器怎麼啟動、session 怎麼維持、sandbox 怎麼設。那些是平台的事，不是模型的事。你把這些混在一起，最後每個錯誤都會變得很難查，因為根本不知道是推理錯、執行錯，還是環境錯。\u003C\u002Fp>\u003Cp>我很喜歡這種切法，因為故障邊界比較清楚。模型判錯，就回頭查 prompt、查需求拆解；瀏覽器壞掉，就查執行層。兩邊分開，系統才有辦法維護。否則你會得到一個很會講道理、但出了事完全沒人知道該修哪裡的東西。\u003C\u002Fp>\u003Cp>Baz 也提到 observability，這點我覺得很多團隊都會拖到最後才補。你讓 agent 對 UI 狀態下判斷，就一定要知道它看到了什麼、點了什麼、為什麼判 pass 或 fail。不然你只是把「自動化信心」包裝得比較漂亮而已，出事時一樣沒人知道發生什麼。\u003C\u002Fp>\u003Cp>實作上，我會把 reasoning 和 execution 完全拆開。模型只處理規格與觀察，執行層只負責跑瀏覽器、抓截圖、記 DOM snapshot、留 trace。最後一定要有可重播的路徑，讓人能回頭看 agent 為什麼下這個結論。沒有 trace 的自動判斷，基本上都不值得信。\u003C\u002Fp>\u003Cul>\u003Cli>模型負責：規格解讀、證據比對、結論輸出。\u003C\u002Fli>\u003Cli>平台負責：瀏覽器啟動、環境隔離、步驟記錄、快照保存。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>把結果送回開發者真的會看的地方\u003C\u002Fh2>\u003Cblockquote>「審查完成後，結果會分發到適當管道：直接留言到 GitHub PR、透過 Slack 通知團隊可見性、並把發現的問題自動連回 Jira 追蹤與修正。」\u003C\u002Fblockquote>\u003Cp>這一段看起來很平凡，但其實是整套流程能不能活下來的關鍵。你如果把 review 結果丟到另一個獨立儀表板，大概沒多久就沒人看了。Baz 把結果送回 \u003Ca href=\"\u002Ftag\u002Fgithub\">GitHub\u003C\u002Fa> PR、Slack、Jira，這才是對的。因為開發、協作、追蹤，本來就已經在這些地方發生。\u003C\u002Fp>\u003Cp>白話講就是：工具不要逼人換腦袋。開發者想在 PR 看評論，QA 想知道問題有沒有追蹤，PM 想看 ticket 有沒有回連。你如果硬要大家再去一個新後台查 AI 意見，採用率很快就掉光，而且掉了還不一定有人承認是因為流程太麻煩。\u003C\u002Fp>\u003Cp>我看過太多內部工具死掉，原因不是功能爛，是輸出放錯地方。邏輯很強，交付很弱。Baz 的好處就在這裡：它知道 review 的輸出不是報告本身，而是後續行動。找得到位置、接得上流程，團隊才會真的用。\u003C\u002Fp>\u003Cp>我自己會再多加一個原則：每個發現都要有可追蹤的 issue 編號。沒有對應 ticket 的 comment，通常只會變成噪音。只要 agent 能把問題自動連回 Jira，後續修正就不用重講一次背景，這點很省時間。\u003C\u002Fp>\u003Cp>實操上，你可以先決定三種輸出要放哪裡：阻擋性問題進 PR、跨團隊可見性進 Slack、後續修正進 Jira。不要讓 agent 找不到出口。找不到出口的發現，最後通常就等於沒發現。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># 規格審查 Agent 模板：把 PR 變成可驗證的合併檢查\n\n## 目標\n在合併前，驗證 PR 是否同時符合產品意圖、設計意圖與功能需求。\n\n## 輸入\n- GitHub Pull Request 連結\n- Figma 檔案或 frame 連結\n- Jira 工單或驗收條件\n- 預覽環境 URL\n- 原始碼存取權\n\n## 流程\n1. PR webhook 觸發審查工作。\n2. 從 Figma 抓取視覺規格。\n3. 從 Jira 抓取功能規格。\n4. 把規格整理成一條條可驗證需求。\n5. 針對每一條需求啟動一個子代理。\n6. 每個子代理只做一件事：\n   - 讀相關原始碼\n   - 打開預覽環境\n   - 用瀏覽器操作 UI\n   - 比對觀察結果與需求\n   - 回傳 pass \u002F fail \u002F needs_human_review 與證據\n7. 彙總所有子代理結果。\n8. 把摘要貼回 GitHub PR。\n9. 把通知送到 Slack。\n10. 對失敗項目建立或更新 Jira issue。\n\n## 需求 schema\n- id：字串\n- source：figma | jira | both\n- type：visual | functional | interaction\n- description：字串\n- expected_result：字串\n- evidence_required：screenshot | dom_state | console_log | network_log | step_trace\n- severity：blocker | major | minor\n\n## 子代理輸出 schema\n- requirement_id：字串\n- verdict：pass | fail | needs_human_review\n- summary：字串\n- evidence：\n  - screenshots\n  - DOM snapshots\n  - interaction steps\n  - relevant code references\n- confidence：low | medium | high\n- follow_up：字串\n\n## 審查提示詞\n你是一個 code review agent。你的工作是驗證實作是否符合需求。\n請同時使用原始碼、預覽環境與需求來源。\n不要猜。若證據不足，請標記 needs_human_review。\n只輸出要求的 schema 欄位。\n\n## PR 留言格式\n### 審查摘要\n- 通過：X\n- 失敗：Y\n- 需人工確認：Z\n\n### 阻擋性問題\n- [requirement_id] 問題簡述與證據連結\n\n### 非阻擋性問題\n- [requirement_id] 問題簡述與證據連結\n\n### 備註\n- 截圖連結\n- 瀏覽器 trace 連結\n- Jira 後續處理連結\n\n## 操作原則\n- 以具體證據優先，不靠模型直覺。\n- 每個子代理只處理一條需求。\n- 執行紀錄與最終判斷分開保存。\n- 證據不足時要保守失敗。\n- 永遠保留回溯到原始規格的能力。\u003C\u002Fcode>\u003C\u002Fpre>\u003Ch2>我會偷走的不是模型，是這套判斷方式\u003C\u002Fh2>\u003Cp>我對 Baz 的讀法很簡單：它不是把 AI 塞進 code review 而已，而是把 review 能判斷的範圍整個改掉。它不再只問「diff 看起來有沒有問題」，而是問「產品證據有沒有對上」、「瀏覽器裡真的有沒有跑出來」、「每條需求能不能被追溯」。這才是有用的方向。\u003C\u002Fp>\u003Cp>如果你也要做類似的東西，別先從模型開始。先問你到底要它回答什麼問題，再決定要抓哪些證據、怎麼拆成小檢查、結果要送去哪裡。這三件事沒想清楚，後面接再多 agent 都只是堆戲法。\u003C\u002Fp>\u003Cp>而且我真的不建議跳過瀏覽器那層。很多團隊會覺得那一步很煩、很慢、很像多此一舉。但說白了，使用者看到的就是瀏覽器裡那個東西。你不去那裡驗，review 再漂亮也只是紙上談兵。\u003C\u002Fp>\u003Cp>來源：\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fmachine-learning\u002Fhow-baz-improved-its-ai-agent-code-review-accuracy-using-amazon-bedrock-agentcore\u002F\">https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fmachine-learning\u002Fhow-baz-improved-its-ai-agent-code-review-accuracy-using-amazon-bedrock-agentcore\u002F\u003C\u002Fa>。我這篇是拆解與模板整理，屬於衍生寫作；模板段落與實操建議則是我自己的整理版本。\u003C\u002Fp>","我拆 Baz 的做法：把 Figma、Jira、瀏覽器預覽串成逐條檢查，讓 PR review 不再只看 diff，而是直接驗證產品意圖。","aws.amazon.com","https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fmachine-learning\u002Fhow-baz-improved-its-ai-agent-code-review-accuracy-using-amazon-bedrock-agentcore\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780762739603-v006.png","industry","zh","b7eb0616-74c8-417f-a62f-7d4c5eeabd0b",[17,18,19,20,21],"AI code review","Amazon Bedrock AgentCore","Figma","Jira","瀏覽器驗證",[23,24,25],"不要只看 diff，要把規格、預覽與實作一起驗證。","把一個功能拆成多條需求，每條需求各自判斷。","review 結果要回到 PR、Slack、Jira，才會真的被用。",0,"2026-06-06T16:18:30.695336+00:00","2026-06-06T16:18:30.673+00:00","caa87b65-9bbc-46fe-bba8-4f4158dd2d8b",{"tags":31,"relatedLang":41,"relatedPosts":45},[32,34,35,37,39],{"name":18,"slug":33},"amazon-bedrock-agentcore",{"name":21,"slug":21},{"name":17,"slug":36},"ai-code-review",{"name":20,"slug":38},"jira",{"name":19,"slug":40},"figma",{"id":15,"slug":42,"title":43,"language":44},"baz-spec-review-agent-bedrock-agentcore-en","Baz’s review agent turns specs into merge checks","en",[46,52,58,64,70,76],{"id":47,"slug":48,"title":49,"cover_image":50,"image_url":50,"created_at":51,"category":13},"ddac71cf-620a-416f-8b98-f3112d5aeb6f","5-things-to-know-about-metas-llama-3-rollout-zh","5 個關於 Meta Llama 3 上線的重點","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780772570959-gp8f.png","2026-06-06T19:02:22.642329+00:00",{"id":53,"slug":54,"title":55,"cover_image":56,"image_url":56,"created_at":57,"category":13},"0162440b-046f-4147-b704-0afbabc3b676","5-reasons-to-use-kimi-k2-5-on-cloudflare-zh","5 個在 Cloudflare 用 Kimi K2.5 的理由","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780769867960-owsi.png","2026-06-06T18:17:17.33325+00:00",{"id":59,"slug":60,"title":61,"cover_image":62,"image_url":62,"created_at":63,"category":13},"7e79459f-ae3f-4c7c-9f5b-a913241bf3d1","5-diem-chinh-ve-thoi-tiet-ngay-mai-56-zh","5 個明日天氣重點","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780766280183-d5os.png","2026-06-06T17:17:34.104555+00:00",{"id":65,"slug":66,"title":67,"cover_image":68,"image_url":68,"created_at":69,"category":13},"9bf21f52-52f5-48e9-a426-f9c1faab64e5","why-thanh-hoa-to-hue-weather-alerts-should-be-taken-seriousl-zh","為什麼清化到順化的天氣警報不能輕忽","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780765371111-tpdu.png","2026-06-06T17:02:19.456487+00:00",{"id":71,"slug":72,"title":73,"cover_image":74,"image_url":74,"created_at":75,"category":13},"9603aac9-7616-4a09-b2ee-e6e9ce526e08","4-market-signals-trumps-iran-talks-zh","4 個川普伊朗談判市場訊號","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780759083218-xdn2.png","2026-06-06T15:17:29.685095+00:00",{"id":77,"slug":78,"title":79,"cover_image":80,"image_url":80,"created_at":81,"category":13},"dc6fea60-bcbb-46a3-816a-0cdc8c9b5db8","guangdong-humidity-2024-template-zh","廣東濕氣把 2024 變模板","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780748300997-dotl.png","2026-06-06T12:17:54.189651+00:00",[83,88,93,98,103,108,113,118,123,128],{"id":84,"slug":85,"title":86,"created_at":87},"ee073da7-28b3-4752-a319-5a501459fb87","ai-in-2026-what-actually-matters-now-zh","2026 AI 真正重要的事","2026-03-26T07:09:12.008134+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"83bd1795-8548-44c9-9a7e-de50a0923f71","trump-ai-framework-power-speech-state-preemption-zh","川普 AI 框架瞄準電力、言論與州權","2026-03-26T07:12:18.695466+00:00",{"id":94,"slug":95,"title":96,"created_at":97},"ea6be18b-c903-4e54-97b7-5f7447a612e0","nvidia-gtc-2026-big-ai-announcements-zh","NVIDIA GTC 2026 重點拆解","2026-03-26T07:14:26.62638+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"4bcec76f-4c36-4daa-909f-54cd702f7c93","claude-users-spreading-out-and-getting-better-zh","Claude 用戶更分散，也更會用","2026-03-26T07:22:52.325888+00:00",{"id":104,"slug":105,"title":106,"created_at":107},"bd903b15-2473-4178-9789-b7557816e535","openclaw-raises-hard-question-for-ai-models-zh","OpenClaw 逼問 AI 模型價值","2026-03-26T07:24:54.707486+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"eeac6b9e-ad9d-4831-8eec-8bba3f9bca6a","gap-google-gemini-checkout-fashion-search-zh","Gap 把結帳搬進 Gemini","2026-03-26T07:28:23.937768+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"0740e53f-605d-4d57-8601-c10beb126f3c","google-pushes-gemini-transition-to-march-2026-zh","Google 把 Gemini 轉換延到 2026 年 3…","2026-03-26T07:30:12.825269+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"e660d801-2421-4529-8fa9-86b82b066990","metas-llama-4-benchmark-scandal-gets-worse-zh","Meta Llama 4 分數風波又擴大","2026-03-26T07:34:21.156421+00:00",{"id":124,"slug":125,"title":126,"created_at":127},"183f9e7c-e143-40bb-a6d5-67ba84a3a8bc","accenture-mistral-ai-sovereign-enterprise-deal-zh","Accenture 攜手 Mistral AI 賣主權 AI","2026-03-26T07:38:14.818906+00:00",{"id":129,"slug":130,"title":131,"created_at":132},"191d9b1b-768a-478c-978c-dd7431a38149","mistral-ai-faces-its-hardest-year-yet-zh","Mistral AI 迎來最硬的一年","2026-03-26T07:40:23.716374+00:00"]