[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-open-code-review-turns-ai-reviews-line-accurate-checks-zh":3,"article-related-open-code-review-turns-ai-reviews-line-accurate-checks-zh":30,"series-tools-0ca67afc-db75-48f7-8185-0a539685ce60":77},{"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},"0ca67afc-db75-48f7-8185-0a539685ce60","open-code-review-turns-ai-reviews-line-accurate-checks-zh","Open Code Review 把 AI 審查變準","\u003Cp data-speakable=\"summary\">Alibaba 的 \u003Ca href=\"\u002Fnews\u002Fopenai-ipo-delay-turns-hype-into-caution-zh\">Open\u003C\u002Fa> \u003Ca href=\"\u002Ftag\u002Fcode-review\">Code Review\u003C\u002Fa> 把 AI code review 做成可重複、可定位到行號的流程。\u003C\u002Fp>\u003Cp>我用 AI 做 code review 一陣子了，越用越火大。它很會講話，看到 diff 也會裝得很懂，但一碰到真的要抓 bug，就開始亂飄：行號對不上、檔案漏看、評論像是隔著霧玻璃瞄過去寫的。最煩的是，它不是完全沒用，而是會先讓你以為有用，等你真的拿去放進團隊流程，才發現每次輸出的可信度都在打折。\u003C\u002Fp>\u003Cp>我想要的是能進 CI、能進 PR 流程、能被工程師當成第二雙眼睛的東西，不是三分鐘 demo。後來我看到 Alibaba 的 \u003Ca href=\"https:\u002F\u002Fwww.xugj520.cn\u002Fen\u002Farchives\u002Fopen-code-review-ai-tool.html\">Open Code Review\u003C\u002Fa> 介紹，才覺得這方向對了：不要再逼模型自己決定一切，而是把該精準的部分交給程式。這種拆法，我比較買單。\u003C\u002Fp>\u003Ch2>不要再把 reviewer 當聊天機器人\u003C\u002Fh2>\u003Cblockquote>“A purely language-driven architecture lacks strong constraints on the review process.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：如果你讓模型自己決定看哪裡、怎麼對位、要不要嚴格，它就會不穩。今天看得很仔細，明天就漏一半；這次 line number 對，下一次直接飛到別的地方。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782490706378-ts02.png\" alt=\"Open Code Review 把 AI 審查變準\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我自己看過太多「請仔細 review 這段程式」的 prompt，結果模型一開始很像回事，diff 一大就開始縮水。這不是它壞掉，是它本來就不是拿來做精準定位的。語言模型擅長生成文字，不擅長保證審查流程的穩定性。你拿它當 reviewer，等於把最需要一致性的工作交給最不一致的元件。\u003C\u002Fp>\u003Cp>Open Code Review 的第一個重點，就是把工作切成兩半：規則、範圍、檔案選擇、評論落點，交給 deterministic logic；理解內容、抓上下文、判斷風險，才交給 \u003Ca href=\"\u002Ftag\u002Fagent\">agent\u003C\u002Fa>。這個切法很務實。我不想讓模型決定哪些 generated files 要不要看，也不想讓它自己猜 review 範圍。那些事情應該先鎖死，再讓模型進場。\u003C\u002Fp>\u003Cp>實操寫法很簡單：你如果也在做自己的 review assistant，先把「一個 prompt 解決全部」丟掉。先寫 pre-processing，決定哪些檔案要看、哪些排除、哪些要分組。等範圍縮乾淨了，再把模型丟進去做判斷。少一點自由發揮，多一點流程控制，結果通常會好很多。\u003C\u002Fp>\u003Ch2>檔案選擇要寫成規則，不要寫成祈禱\u003C\u002Fh2>\u003Cblockquote>“Precise file filtering” and “important changes are never missed.”\u003C\u002Fblockquote>\u003Cp>OCR 把 file selection 當基礎設施，不是提示詞裡的建議。文章裡直接講可以用規則指定要 review 的路徑，例如 \u003Ccode>src\u002Fmain\u002F**\u002F*.java\u003C\u002Fcode>，也可以排除 \u003Ccode>**\u002Fgenerated\u002F**\u003C\u002Fcode>。這聽起來很無聊，但我反而覺得這才像真的工具。因為 review 最怕的不是多看一個檔案，是漏看該看的檔案。\u003C\u002Fp>\u003Cp>白話一點說，這套東西不是靠模型「記得」所有變更，而是先用規則把 diff 過一遍。該進來的進來，不該進來的出去。這比「請幫我全面檢查」可靠太多，因為後者其實是在拜託模型自己別偷懶。\u003C\u002Fp>\u003Cp>我碰過一個改動，裡面同時有 business logic 和 generated artifact。一般 AI reviewer 很愛把注意力花在垃圾檔案上，真正的服務層 bug 反而被掃過去。OCR 要避免的就是這種浪費：先用規則定義 review surface，再讓模型去看真正值得看的東西。\u003C\u002Fp>\u003Cp>實操寫法：先列 include，再列 exclude。把 generated、vendored、lockfile、minified assets 先排掉；如果你們 repo 裡有不同標準，像 source code、SQL、config、migration 各自有不同規則，也別靠 prompt，直接寫進 filter stage。規則寫死，結果才會穩。\u003C\u002Fp>\u003Cul>\u003Cli>先定義要看的路徑，再補排除規則。\u003C\u002Fli>\u003Cli>generated、vendor、dist 這類檔案先排掉。\u003C\u002Fli>\u003Cli>讓每次執行看到的 scope 都一樣。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>bundle 不相關的檔案，模型就會開始胡扯\u003C\u002Fh2>\u003Cblockquote>“Smart file bundling” groups related files into a single review unit.\u003C\u002Fblockquote>\u003Cp>這段我覺得很重要。OCR 不會把所有變更硬塞成一包，而是把相關檔案組成 review bundle，再交給子 agent。文章舉的例子是 \u003Ccode>message_en.properties\u003C\u002Fcode> 和 \u003Ccode>message_zh.properties\u003C\u002Fcode> 一起看，這就很合理，因為它們本來就是同一個語意單元。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782490707507-jo4m.png\" alt=\"Open Code Review 把 AI 審查變準\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>也就是說，OCR 在幫模型減少上下文噪音。大變更不是一件事，是很多小事混在一起。你如果把它們全丟進同一個 prompt，模型很快就會從「檢查」退化成「摘要」，然後評論開始空泛，像在交作業。\u003C\u002Fp>\u003Cp>我自己人工 review 也不會把整個 branch 當一坨看。我會把 API 變更、config 變更、migration、localization 分開看。OCR 這個 bundle 概念，其實是在逼工具照著工程師真正的 review 習慣走，而不是讓人遷就模型的上下文限制。\u003C\u002Fp>\u003Cp>實操寫法：bundle 規則不要只看副檔名，要看 domain。translation 檔案一起、schema 與 migration 一起、controller\u002Fservice\u002Ftest 一起、設定檔一起。變更量大時最好能平行跑子 review，這樣 coverage 比較完整，也不會把所有資訊塞成一坨。\u003C\u002Fp>\u003Cul>\u003Cli>按 domain 分組，不要只按副檔名分組。\u003C\u002Fli>\u003Cli>每個 bundle 用自己的 review context。\u003C\u002Fli>\u003Cli>大 diff 可以平行化處理，別硬塞單一 prompt。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>行號對不上，整份 review 就是廢的\u003C\u002Fh2>\u003Cblockquote>“External location and reflection components” systematically correct location errors.\u003C\u002Fblockquote>\u003Cp>這裡才是 OCR 最像正經工具的地方。文章說它有\u003Ca href=\"\u002Fnews\u002Fsuno-launches-spark-indie-artists-zh\">獨立\u003C\u002Fa>的 comment positioning 和 content reflection 模組。白話講就是：模型先提意見，但如果落點不準，系統會再校正一次；如果內容有問題，也能反射回去再修。\u003C\u002Fp>\u003Cp>翻譯一下就是，OCR 不相信模型第一次給的位置。這很對，因為 line-level review 只有在行號真的正確時才有價值。錯的 line number 不叫 review，那叫把 reviewer 變成客服，還要工程師自己去找你到底在講哪一行。\u003C\u002Fp>\u003Cp>我最受不了的就是工具說「這裡可能有 null pointer risk」，結果箭頭指到空白行，或是指到一個根本沒問題的 return。那種情況下，我先驗工具，再驗 code，順序整個反了。OCR 想做的，就是把這個負擔移回系統層，別讓人肉去補模型的位置錯誤。\u003C\u002Fp>\u003Cp>實操寫法：挑工具或自己做 review 系統時，先確認它能不能把評論 anchor 回真實 diff 或 file snapshot。評論必須綁定實際檔案 offset，不是只靠語意相似度。再來，用已知 diff 測試它的穩定性，多跑幾次看行號會不會飄。如果會飄，那不是小瑕疵，是結構性問題。\u003C\u002Fp>\u003Cp>如果你要讓團隊真的用起來，最好把測試 review output 當成測 code 一樣對待。拿幾個固定變更反覆跑，確認位置一致、評論一致、沒有亂飛。這種東西不先驗，後面只會一直吵。\u003C\u002Fp>\u003Ch2>模型可以用，但要關在短籠子裡\u003C\u002Fh2>\u003Cblockquote>“Scenario-specific prompt tuning” and a “dedicated toolset” for code review.\u003C\u002Fblockquote>\u003Cp>OCR 不是把模型扔掉，而是把它放回該做的地方。文章提到他們有針對 code review 調整 prompt，也縮過工具集，根據真實 tool-call pattern 去刪掉不常用的東西。這種做法我很熟悉，因為 agent 系統最常見的死法，就是工具越加越多，最後模型在那邊亂跳。\u003C\u002Fp>\u003Cp>也就是說，agent 可以讀檔、搜尋、看其他變更檔案來補上下文，但不需要一整包花俏工具。工具太多只會讓它更吵、更不穩。review 這種工作，重點不是「會不會很多」，而是「會不會每次都差不多」。\u003C\u002Fp>\u003Cp>我看過不少系統，明明是 review agent，卻塞了一堆不相干的 helper。結果模型在工具間來回切，token 燒得很快，結論卻很碎。OCR 的方向比較乾脆：縮工具、調 prompt、把行為鎖在 review 任務上，不要讓它到處亂逛。\u003C\u002Fp>\u003Cp>實操寫法：先盤點工具清單，把幾乎沒用到的先砍掉。如果 review 場景真的只需要 file reader、search、diff inspector，那就夠了。接著重寫 prompt，明確寫出要看什麼、要抓什麼、嚴重度怎麼排、什麼情況該閉嘴。別把「更多工具」誤認成「更聰明」。\u003C\u002Fp>\u003Ch2>CLI 要接進工作流，不要做成玩具\u003C\u002Fh2>\u003Cblockquote>“Workspace mode,” “branch range mode,” and “single commit mode.”\u003C\u002Fblockquote>\u003Cp>OCR 是 CLI，所以整合方式很直接。文章把常見模式分成三種：看目前 workspace 的未提交變更、比對兩個 ref 的 branch diff、或是只看單一 commit。這三種其實就涵蓋了大部分團隊的真實使用情境：本地開發、分支審查、回歸排查。\u003C\u002Fp>\u003Cp>白話說，這工具沒有硬要你改開發習慣。你在本地改 code，就看 dirty tree；你要送 PR，就比對 feature branch 和 main；你要查 bug，就盯單一 commit。這種設計我很喜歡，因為越少 ceremony 的工具，越容易真的被用。\u003C\u002Fp>\u003Cp>我一直覺得 review 工具的價值，不只在準不準，也在會不會被持續使用。比起一個很厲害但大家懶得開的系統，我寧可要一個稍微沒那麼花俏、但每次都能跑的流程。穩定使用，比偶爾驚豔重要得多。\u003C\u002Fp>\u003Cp>實操寫法：把 review 指令接進你們平常的 dev flow。local 開發前先跑一次，開 PR 前再跑一次，CI 裡對 branch diff 再跑一次。若你們本來就有 \u003Ca href=\"\u002Ftag\u002Fgithub\">GitHub\u003C\u002Fa> Actions、GitLab CI 或其他 pipeline，CLI 形態會比 web-only assistant 好塞很多。\u003C\u002Fp>\u003Cul>\u003Cli>workspace mode 用在本地 pre-PR 檢查。\u003C\u002Fli>\u003Cli>branch range mode 用在 merge request \u002F CI review。\u003C\u002Fli>\u003Cli>single commit mode 用在回歸追 bug。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>安裝路徑要清楚，因為 adoption 一定會卡\u003C\u002Fh2>\u003Cblockquote>“Install via NPM,” “download the binary,” or “build from source.”\u003C\u002Fblockquote>\u003Cp>文章把安裝方式列得很完整：可以用 npm 裝、可以抓 binary、也可以自己從 source build。這才像一個正常的 open source 工具。你想快點試，就走 npm；你想要鎖版，就抓 release binary；你要深度整合或 patch 行為，就從 source 下手。\u003C\u002Fp>\u003Cp>這件事看起來普通，但其實很重要。團隊\u003Ca href=\"\u002Fnews\u002Fhippo-deploys-devin-insurance-engineering-zh\">導入\u003C\u002Fa>工具最常死在 boring stuff：安裝步驟、設定檔位置、auth header、預設行為不清楚。OCR 文章願意花篇幅講這些，代表它知道 adoption 不是靠功能堆出來的，是靠 setup 不要太煩。\u003C\u002Fp>\u003Cp>我待過的團隊很多，最後沒推起來的工具，常常不是因為不夠強，而是因為一開始裝起來就一堆坑。這種東西最怕大家試一次就放棄。你如果真的想讓 review agent 被用，先把安裝流程寫乾淨，比多寫十個 fancy feature 更實際。\u003C\u002Fp>\u003Cp>實操寫法：團隊內只選一條推薦安裝路徑，其餘當備援。若你支援多個 LLM provider，就把環境變數、config 檔位置、認證方式寫清楚。不要把 setup 藏在功能介紹後面，然後期待大家自己摸懂。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Open Code Review 導入模板（可直接改成你們自己的 repo 用法）\n\n## 1) 安裝\n擇一即可：\n- npm install -g @alibaba-group\u002Fopen-code-review\n- 從 GitHub Releases 下載 binary\n- 需要改行為就從 source build\n\n## 2) 設定模型端點\n先固定一種 provider，團隊不要每個人各玩各的。\n\n範例 env：\nexport OCR_LLM_URL=\"https:\u002F\u002Fapi.anthropic.com\u002Fv1\u002Fmessages\"\nexport OCR_LLM_TOKEN=\"YOUR_API_KEY\"\nexport OCR_LLM_MODEL=\"claude-opus-4-6\"\nexport OCR_USE_ANTHROPIC=true\n\n如果你走 Anthropic-style auth：\nocr config set llm.auth_header x-api-key\n\n## 3) 定義 review scope\n用 deterministic 規則先把範圍鎖死。\n\nInclude：\n- src\u002Fmain\u002F**\u002F*.java\n- app\u002F**\u002F*.ts\n- services\u002F**\u002F*.py\n\nExclude：\n- **\u002Fgenerated\u002F**\n- **\u002Fvendor\u002F**\n- **\u002Fdist\u002F**\n- **\u002F*.min.js\n\n## 4) Bundle 規則\n按 domain 分組，不要亂塞。\n- localization 檔案一起\n- migration \u002F schema 一起\n- controller \u002F service \u002F test 一起\n- config 檔一起\n\n## 5) 選對模式\n本地工作樹：\nocr review\n\n分支 diff：\nocr review --from main --to feature-branch\n\n單一 commit：\nocr review --commit abc123\n\n## 6) 讓輸出能被自動化\nJSON 格式：\nocr review --format json\n\n先預覽：\nocr review --preview\n\n補背景：\nocr review --background \"Add rate limiting to login API\"\n\n## 7) 把 agent 關小一點\n- 只保留 file read、search、changed-file inspection\n- 每個評論都要對得上真實 diff\n- 不能 anchor 到 source position 的評論直接丟掉\n- prompt 只針對 code review 調整，不要塞一堆通用任務\n\n## 8) CI policy\n- high-confidence issue 才 fail pipeline\n- medium-confidence 交給人看\n- low-confidence noise 不要一直吵，除非它重複出現\n\n## 9) 團隊規則\n如果一則 review comment 不能指到真實檔案的真實行號，它就不算 review finding。\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這段就是我會直接拿去改的版本。它把 OCR 的核心想法收斂成一個 workflow：scope 先鎖、bundle 按 domain 分、模式選對、每則評論都要有真實錨點。你如果要自己做 review assistant，這個骨架很夠用了。\u003C\u002Fp>\u003Cp>原始來源是 \u003Ca href=\"https:\u002F\u002Fwww.xugj520.cn\u002Fen\u002Farchives\u002Fopen-code-review-ai-tool.html\">Efficient Coder on xugj520.cn\u003C\u002Fa>，我這篇是根據那篇文章和 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Falibaba\u002Fopen-code-review\">Open Code Review GitHub repository\u003C\u002Fa> 的內容，整理成比較適合\u003Ca href=\"\u002Ftag\u002F台灣開發者\">台灣開發者\u003C\u002Fa>直接拿去用的拆解。\u003C\u002Fp>\u003Cp>如果你想看安裝與版本，我也建議順手看 \u003Ca href=\"https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@alibaba-group\u002Fopen-code-review\">npm package\u003C\u002Fa> 和 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Falibaba\u002Fopen-code-review\u002Freleases\">GitHub Releases\u003C\u002Fa>；如果你在比對不同 \u003Ca href=\"\u002Ftag\u002Fai-coding\">AI coding\u003C\u002Fa> workflow，\u003Ca href=\"https:\u002F\u002Fwww.anthropic.com\u002Fclaude-code\">Claude Code\u003C\u002Fa> 的文件也很有參考價值。\u003C\u002Fp>","我拆 Alibaba 的 Open Code Review CLI，順手給你一份可直接複製的 line-level AI code review 配置。","www.xugj520.cn","https:\u002F\u002Fwww.xugj520.cn\u002Fen\u002Farchives\u002Fopen-code-review-ai-tool.html",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782490706378-ts02.png","tools","zh","d4b06c3c-43b1-4638-b02f-78b79585218a",[17,18,19,20,21],"AI code review","line-level checks","CLI","prompt tuning","agent workflow",[23,24,25],"把 review 的範圍、檔案選擇、行號定位交給規則，不要交給模型臨場發揮。","用 bundle 把相關變更分組，讓模型在小而乾淨的上下文裡做判斷。","把工具集縮到最小，並把每則評論強制錨定到真實檔案行號。",0,"2026-06-26T16:17:57.066004+00:00","2026-06-26T16:17:57.035+00:00","c3c88dd2-a940-438a-b359-0e5a24562273",{"tags":31,"relatedLang":36,"relatedPosts":40},[32,34],{"name":17,"slug":33},"ai-code-review",{"name":19,"slug":35},"cli",{"id":15,"slug":37,"title":38,"language":39},"open-code-review-turns-ai-reviews-line-accurate-checks-en","Open Code Review turns AI reviews into line-accurate checks","en",[41,47,53,59,65,71],{"id":42,"slug":43,"title":44,"cover_image":45,"image_url":45,"created_at":46,"category":13},"c614316e-6910-49e8-83d1-da7e7c2c3e79","spec-kit-guided-ai-workflow-setup-zh","Spec Kit 把設定變成導引流程","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782505105249-9o62.png","2026-06-26T20:17:59.33633+00:00",{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"69cbfbfb-8532-4bd3-814b-559a260cdd4a","litefuse-agent-observability-single-binary-doris-zh","Litefuse 不是 Langfuse 的補丁，而是 Agent 可觀測的正…","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782500574117-ul0z.png","2026-06-26T19:02:21.266856+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"4f42621b-c5ca-42ca-a567-c48e1cb34222","20-ai-coding-assistants-stripped-down-2026-zh","20 個 AI 寫碼助手，拆成可用清單","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782498806913-57hj.png","2026-06-26T18:32:53.614602+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"2d745abb-9cb8-4d94-b2a6-cb3558904f27","grok-imagine-1-5-turns-prompts-into-720p-video-zh","Grok Imagine 1.5把提示詞變720p短片","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782475410787-cu25.png","2026-06-26T12:03:02.703582+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"42fe01d4-37e4-44d0-811c-119a991c9069","ocr-4-turns-pdfs-into-cited-rag-input-zh","OCR 4 把 PDF 變成可引用 RAG 輸入","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782469113477-4epx.png","2026-06-26T10:18:04.231073+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"f79f80f7-5632-4403-ad91-3e7b9e0a7282","ai-code-review-beating-human-teammates-zh","AI 程式碼審查正在壓過人類隊友","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782460982684-i0a9.png","2026-06-26T08:02:32.066092+00:00",[78,83,88,93,98,103,108,113,118,123],{"id":79,"slug":80,"title":81,"created_at":82},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":84,"slug":85,"title":86,"created_at":87},"9b19ab54-edef-4dbd-9ce4-a51e4bae4ebb","mcp-in-2026-the-ai-tool-layer-teams-use-zh","2026 年 MCP：團隊真的在用的 AI 工具層","2026-03-26T08:01:46.589694+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":94,"slug":95,"title":96,"created_at":97},"05553086-6ed0-4758-81fd-6cab24b575e0","garry-tan-open-sources-claude-code-toolkit-zh","Garry Tan 開源 Claude Code 工具包","2026-03-26T08:26:20.068737+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"042a73a2-18a2-433d-9e8f-9802b9559aac","github-ai-projects-to-watch-in-2026-zh","2026 必看 20 個 GitHub AI 專案","2026-03-26T08:28:09.619964+00:00",{"id":104,"slug":105,"title":106,"created_at":107},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"bfdb467a-290f-4a80-b3a9-6f081afb6dff","aiml-2026-student-ai-ml-lab-repo-review-zh","AIML-2026：像課綱的學生實驗 Repo","2026-03-27T01:21:51.467798+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"80cabc3e-09fc-4ff5-8f07-b8d68f5ae545","ai-trending-github-repos-and-research-feeds-zh","AI Trending：把 AI 資源收成一張表","2026-03-27T01:31:35.262183+00:00",{"id":124,"slug":125,"title":126,"created_at":127},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]