[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-prompt-engineering-turns-codegen-into-repeatable-workflow-zh":3,"article-related-prompt-engineering-turns-codegen-into-repeatable-workflow-zh":30,"series-research-cf300a40-a285-4a1c-a0fb-ddd8fb0c6cce":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},"cf300a40-a285-4a1c-a0fb-ddd8fb0c6cce","prompt-engineering-turns-codegen-into-repeatable-workflow-zh","Prompt 工程把 codegen 變成可重複流程","\u003Cp data-speakable=\"summary\">以前我靠靈感叫模型寫 code，現在我改用固定 prompt 流程，輸出才開始穩。\u003C\u002Fp>\u003Cp>我用 \u003Ca href=\"\u002Ftag\u002Fllm\">LLM\u003C\u002Fa> 寫 code 已經夠久了，久到一看輸出就知道它又在唬爛。速度很快，Demo 也很漂亮，第一版常常看起來能交差。但一進真實 codebase 就露餡：需求講得不清、邊界條件漏掉、測試沒補、還會一本正經地附和我那個其實很爛的想法。這種東西不是幫手，頂多算是更會說話的 autocomplete。\u003C\u002Fp>\u003Cp>我想要的是能在專案裡真的信得過的方法。不是什麼神奇咒語，也不是今天有用、明天失靈的一句 prompt。我想要的是\u003Ca href=\"\u002Fnews\u002Fopenai-compatible-model-comparison-script-zh\">一套\u003C\u002Fa>可以重複、可以檢查、可以交給團隊一起用的寫法。這篇 review 就是因為這個痛點被我翻出來。它不是在賣夢，它是在整理：到底哪些 prompt 寫法真的有助於 code generation，哪些只是大家嘴上講得很順。\u003C\u002Fp>\u003Cp>觸發我拆這份觀點的來源，是 Erika Camacho、Yazmin Gutierrez、Cesar Pardo 的系統性回顧，發在 \u003Ca href=\"https:\u002F\u002Fjournal.iberamia.org\u002Findex.php\u002Fintartif\u002Farticle\u002Fview\u002F2395\">Inteligencia Artificial\u003C\u002Fa>，DOI 是 \u003Ca href=\"https:\u002F\u002Fdoi.org\u002F10.4114\u002Fintartif.vol29iss78pp21-58\">10.4114\u002Fintartif.vol29iss78pp21-58\u003C\u002Fa>。他們整理了 26 篇 primary studies，切成六個主題。這種東西我比較吃得下，因為我不缺又一篇「prompt 很重要」的廢話，我缺的是能直接搬去用的地圖。\u003C\u002Fp>\u003Ch2>別把 prompt 當成聊天語氣\u003C\u002Fh2>\u003Cblockquote>\"This Systematic Literature Review examines prompt engineering in automatic code generation using large language models (LLMs). A methodological protocol identified 26 relevant primary studies to characterize the status, trends, challenges, and opportunities of prompt engineering in software development.\"\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：作者不是憑感覺講 prompt 有沒有用，他們先定義方法，再從 26 篇研究裡整理出共通模式。這點很重要，因為業界最愛把一個漂亮 demo 當成通則，然後大家一起踩坑。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784923395397-latp.png\" alt=\"Prompt 工程把 codegen 變成可重複流程\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我自己最早用 LLM 產 code 的時候也這樣。丟一句「幫我做一個 CRUD \u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa>」，結果我花在修 output 的時間，常常比自己從頭寫還久。模型不一定爛，很多時候是我問得很爛。這篇 review 的價值就在這裡：它把 prompt 拉回工程問題，不是聊天問題。\u003C\u002Fp>\u003Cp>實操上，我現在會先把需求縮成一個可驗證的任務。語言、框架、輸入、輸出、不能犯的錯、驗收條件，全都直接寫。你不寫清楚，模型就會用它自己的常識補洞，而那個常識通常不是你的 stack。\u003C\u002Fp>\u003Cul>\u003Cli>一句話寫清楚這段 code 要做什麼。\u003C\u002Fli>\u003Cli>把語言、框架、版本、相依套件講明白。\u003C\u002Fli>\u003Cli>把不該發生的事列出來。\u003C\u002Fli>\u003Cli>要求 tests 或驗證步驟一起交付。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>六個分類比那些 buzzword 有用\u003C\u002Fh2>\u003Cp>這篇 review 把結果整理成六個 recurring themes：structured methodologies、pedagogical strategies、accuracy and robustness、code improvement techniques、security through prompts、以及 \u003Ca href=\"\u002Ftag\u002Fprompt-engineering\">prompt engineering\u003C\u002Fa> 在 LLM 互動中的角色。學術味很重，但我覺得拿來當\u003Ca href=\"\u002Fnews\u002Fxai-july-2026-grok-45-updates-zh\">工作\u003C\u002Fa>清單其實很順手。\u003C\u002Fp>\u003Cp>白話一點，prompt engineering 不是一招通吃。它是一疊不同用途的工具。某些 prompt 是在幫模型理解任務結構，某些是拿例子教它風格，某些是在壓低錯誤率，某些是拿來修舊 code，某些是直接防危險輸出，還有一些是在規範你怎麼跟模型講話。\u003C\u002Fp>\u003Cp>我以前很懶，會把這些全塞進「我 prompt 寫得好不好」這個大籃子裡。那很偷懶。像我如果要它生 migration script，我先在意 correctness，再來是 security，最後才是可讀性；但如果我要它 refactor，我先在意 behavior 不要變，再來才是 style。不同任務，本來就該用不同 prompt 形狀。\u003C\u002Fp>\u003Cp>實操寫法很簡單：下 prompt 前先選你要解的類別。要 correctness，就叫它補 tests、列 edge cases。要 code improvement，就先貼舊 code，再定義你要改善什麼。要 security，就直接講 threat surface，不要期待它自己自律。\u003C\u002Fp>\u003Cul>\u003Cli>Structured methodology：用固定欄位的模板。\u003C\u002Fli>\u003Cli>Pedagogical strategy：給範例，讓它照著學。\u003C\u002Fli>\u003Cli>Accuracy and robustness：要求測試、邊界條件、假設。\u003C\u002Fli>\u003Cli>Security：直接要求它標出風險與防護點。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>結構比聰明字眼更管用\u003C\u002Fh2>\u003Cp>我最有感的是 structured methodologies 這一塊。這跟我自己實戰看到的東西完全對得上：prompt 長得像規格書，模型就比較像在做任務；prompt 長得像閒聊，它就比較像在猜你心情。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784923394250-f5ot.png\" alt=\"Prompt 工程把 codegen 變成可重複流程\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>也就是說，prompt engineering 有一部分其實是文件設計。你不是在寫漂亮句子，你是在降低歧義。結構越清楚，模型要自己腦補的東西就越少；它腦補越少，亂編的機率就越低。不是歸零，至少少很多，這已經夠救命了。\u003C\u002Fp>\u003Cp>我之前做過同一個功能，先用鬆散 prompt，再用結構化 prompt。鬆散版生出來的 code 可以 compile，但商業規則漏掉了。結構化版雖然還是要 review，至少它比較像真的有看懂需求。模型沒變，差別只是我怎麼問。\u003C\u002Fp>\u003Cp>實操寫法：每次 code generation 都固定用同一套骨架。欄位不要亂跳，讓你自己和模型都習慣它。像是 goal、context、constraints、examples、output format、validation，這樣你不用每次重新發明問法。\u003C\u002Fp>\u003Cpre>\u003Ccode>Goal: generate code for [task]\nContext: [language, framework, repo state]\nInputs: [data shape, API contract, file names]\nConstraints: [performance, style, security, compatibility]\nExamples: [sample input\u002Foutput or existing pattern]\nOutput format: [files, functions, tests, explanation]\nValidation: [unit tests, edge cases, lint rules]\u003C\u002Fcode>\u003C\u002Fpre>\u003Ch2>範例不是裝飾，是教模型看你的 codebase\u003C\u002Fh2>\u003Cp>這篇 review 裡的 pedagogical strategies，我覺得特別實用。因為 code generation 本質上就是 pattern transfer。你有沒有給它看過你專案裡真的長什麼樣，差很多。沒給，它就會吐出一份很 generic、看起來像樣、但跟你專案氣味不合的東西。\u003C\u002Fp>\u003Cp>翻譯一下就是：few-shot prompting 不只是拿來做學術 demo，它是教模型你的命名規則、錯誤處理方式、資料結構習慣。這比你在 prompt 裡多加幾個形容詞有用太多。你寫「clean」「robust」通常沒什麼屁用；你貼一個真的範例，效果就會明顯很多。\u003C\u002Fp>\u003Cp>我遇過最煩的一種狀況，是我叫它寫一個 endpoint，結果它一直回我 generic exception。不是它不會，是我沒給它看我們專案習慣用 domain error。後來我直接貼一個現成 function，叫它照那個 style 寫，output 立刻順很多。不是完美，但至少不再跟 codebase 打架。\u003C\u002Fp>\u003Cp>實操寫法：只放一兩個高品質範例，不要塞一堆半吊子例子。你要它寫新 endpoint，就貼一個同類 endpoint；你要它寫測試，就貼一個你團隊真的會接受的測試。模型很字面，它看到什麼就學什麼。\u003C\u002Fp>\u003Cul>\u003Cli>用自己 codebase 裡的真實範例。\u003C\u002Fli>\u003Cli>範例若有隱含規則，直接註解出來。\u003C\u002Fli>\u003Cli>範例要貼近任務，不要只是「看起來類似」。\u003C\u002Fli>\u003Cli>把雜訊刪掉，讓模型看到 pattern，不是看到垃圾。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>準確度其實是 prompt 設計問題\u003C\u002Fh2>\u003Cp>review 把 accuracy and robustness 拉成一個獨立主題，這點我很同意。很多人把模型品質講得像唯一變數，但實戰不是這樣。prompt 寫法會直接改變輸出形狀，這對 \u003Ca href=\"\u002Ftag\u002Fcode-review\">code review\u003C\u002Fa> 跟維護都很重要。\u003C\u002Fp>\u003Cp>白話就是：你要逼模型先證明它自己。不是哲學上的證明，是 developer 意義上的證明。叫它先列 assumptions，再列 edge cases，再附 tests，最後補一段為什麼這樣寫。這不保證正確，但至少讓你有更多地方可以抓問題。\u003C\u002Fp>\u003Cp>我之前看過它產出一段看似正常的 code，直到我追問 boundary cases，才發現 null handling 根本沒補。重點不是模型突然變聰明，而是我把 prompt 寫成會逼它露餡的形式。\u003C\u002Fp>\u003Cp>實操寫法：每個 code prompt 都加 validation 欄位。請它先列假設，再列測試，再列可能失敗的地方。你在 review output 時，也先看假設，因為 bug 常常先死在那裡。\u003C\u002Fp>\u003Ch2>安全性要直接寫進 prompt\u003C\u002Fh2>\u003Cp>六個主題裡有一個是 security through prompts，我覺得這個不能省。LLM 生 code 很快，但它也很容易吐出功能正常、風險很高的寫法。這種 trade 我不想要。\u003C\u002Fp>\u003Cp>也就是說，安全性不能靠運氣。只要碰到 authentication、authorization、input validation、檔案處理、SQL、shell execution、secret management，我都會把安全要求寫死。你不能假設模型會自動選安全版本，有時候它會，有時候它不會，而這個不確定性本身就是問題。\u003C\u002Fp>\u003Cp>我曾經叫它寫一段接受使用者輸入的 shell script，第一版簡直是 production 事故預備軍。後來我直接加上 argument escaping、禁止 shell interpolation 這種條件，輸出才往正確方向走。不是魔法，只是我終於把話講清楚。\u003C\u002Fp>\u003Cp>實操寫法：把安全清單塞進模板。要求 input sanitization、least privilege、secret handling、secure defaults。如果任務碰到使用者資料，先叫模型列 threat surface，再開始寫 code。這一步很煩，但很值得。\u003C\u002Fp>\u003Ch2>Prompt 應該進到開發流程，不該只活在私訊裡\u003C\u002Fh2>\u003Cp>這篇 review 提到 2021 到 2025 之間相關研究\u003Ca href=\"\u002Fnews\u002Fprompt-engineering-cheat-sheet-2026-zh\">快速\u003C\u002Fa>增加，而且學界持續關注，代表 prompt engineering 在 software lifecycle 裡已經有實際價值。我讀起來比較像提醒：這東西早就不是個人小把戲了，但很多團隊還在把 prompt 當一次性的文字。\u003C\u002Fp>\u003Cp>翻譯一下就是：prompt 應該像其他工程資產一樣被版本化、被 review、被重用。哪一個 prompt 常常產出好 migration code，就把它留著。哪一個 prompt 在某類任務上一直翻車，就記下來。prompt 本身會變成團隊知識的一部分。\u003C\u002Fp>\u003Cp>我現在會把好用的 prompt 直接放進 repo，像小工具一樣管理。stack 變了就改，需求變了就修。它不是神聖不可碰，但也不是用完就丟。這個轉變很重要，因為它把 prompt engineering 從個人手感，變成團隊流程。\u003C\u002Fp>\u003Cp>實操寫法：把 prompts 跟產出的 code 放在一起。每個 prompt 附上適用情境和不適用情境。如果團隊有在用 AI 做 scaffold 或 review，就把 prompt 納入 onboarding。不然每個工程師都會自己重造一個更爛的版本。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Code generation prompt template\n\n你是我的資深工程助理，請幫我產出可直接 review 的 code。\n\n## Task\n請用 [language\u002Fframework] 寫出\u002F修改 [specific goal]。\n\n## Context\n- Project type: [web app \u002F API \u002F CLI \u002F library]\n- Stack: [language, framework, runtime, DB]\n- Existing pattern to follow: [貼一段真實範例或描述]\n- File(s) to modify or create: [list]\n\n## Inputs and outputs\n- Input shape: [JSON, form data, function args, event payload]\n- Output shape: [response, file content, return value]\n- Success criteria: [什麼條件成立才算完成]\n\n## Constraints\n- Style rules: [naming, formatting, architecture]\n- Do not use: [unsafe APIs, deprecated libraries, patterns to avoid]\n- Security requirements: [validation, escaping, auth, secrets]\n- Performance requirements: [latency, memory, complexity]\n\n## Example\n以下是我專案裡的一個範例，請盡量維持相同風格：\n[PASTE EXAMPLE]\n\n## Validation\n在寫 final code 前，先做這些事：\n1. 列出你做了哪些假設。\n2. 找出 edge cases 和 failure modes。\n3. 一起附上 tests 或 test cases。\n4. 標出任何可能 unsafe 或 brittle 的地方。\n\n## Output format\n請回傳：\n1. code\n2. tests\n3. 簡短說明 key choices\n4. caveats \u002F follow-up work\n\n## Refactor mode\n如果我給你的是既有 code，不是空白任務，請先說明你會怎麼改，再在保留行為的前提下重寫。\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這段就是我會直接複製的版本。它之所以有用，不是因為它很會講，而是因為它逼模型回答我在 code review 時本來就會問的問題。這樣輸出比較好驗，也比較不容易誤讀。\u003C\u002Fp>\u003Cp>你要真的用得順，不要把模板當咒語背一遍。把你專案裡真的在意的限制填進去，貼真實範例，直接寫出安全風險。你越具體，後面要收爛攤子的機會就越小。\u003C\u002Fp>\u003Cp>原始來源是 \u003Ca href=\"https:\u002F\u002Fjournal.iberamia.org\u002Findex.php\u002Fintartif\u002Farticle\u002Fview\u002F2395\">Erika Camacho、Yazmin Gutierrez、Cesar Pardo 的 review\u003C\u002Fa>，DOI 是 \u003Ca href=\"https:\u002F\u002Fdoi.org\u002F10.4114\u002Fintartif.vol29iss78pp21-58\">10.4114\u002Fintartif.vol29iss78pp21-58\u003C\u002Fa>。我上面這份模板是我根據他們的整理做的衍生版本，不是逐字抄 paper。\u003C\u002Fp>","我拆解一篇 prompt engineering for code generation 的系統性回顧，整理成開發者可直接套用的固定 prompt 流程與模板。","journal.iberamia.org","https:\u002F\u002Fjournal.iberamia.org\u002Findex.php\u002Fintartif\u002Farticle\u002Fview\u002F2395",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784923395397-latp.png","research","zh","8b0e71c7-05b9-4b12-ba3b-32ee6b3922e7",[17,18,19,20,21],"prompt engineering","code generation","LLM","few-shot prompting","software workflow",[23,24,25],"把 prompt 寫成規格，不要寫成聊天句子。","用固定模板、真實範例、驗證步驟，讓 codegen 可重複。","安全性和邊界條件要直接寫進 prompt，別靠模型自覺。",0,"2026-07-24T20:02:49.165518+00:00","2026-07-24T20:02:49.155+00:00","788967d9-4aba-4e53-bffc-f452d7d0af7f",{"tags":31,"relatedLang":36,"relatedPosts":40},[32,34],{"name":17,"slug":33},"prompt-engineering",{"name":19,"slug":35},"llm",{"id":15,"slug":37,"title":38,"language":39},"prompt-engineering-turns-codegen-into-repeatable-workflow-en","Prompt engineering turns codegen into a repeatable workflow","en",[41,47,53,59,65,71],{"id":42,"slug":43,"title":44,"cover_image":45,"image_url":45,"created_at":46,"category":13},"30e85daf-b3bd-47dc-a99c-f5fdbdf57a97","prompt-engineering-cheat-sheet-2026-zh","2026 Prompt Engineering 快速手冊","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784890982363-ipaj.png","2026-07-24T11:02:34.935593+00:00",{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"e37b2e5c-b360-4184-8223-005203aeb2f2","35-chatgpt-research-prompts-better-studies-zh","35 個 ChatGPT 研究提示詞實作指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784885594088-voer.png","2026-07-24T09:32:44.664883+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"c6d14983-2dd2-457e-bc16-4122c07dd388","graphvid-interaction-graphs-video-generation-zh","GraphVid 用互動圖控影片生成","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784876580687-1hss.png","2026-07-24T07:02:27.302432+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"3fac1251-74ee-40ea-b8ff-fedd7356a00b","expanding-flow-maps-variable-size-generation-zh","可擴張 Flow Map：生成尺寸跟著長","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784874777592-cgsg.png","2026-07-24T06:32:30.189145+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"e0c23a43-b87a-4bb8-842f-f44d76b8dfbf","vlm-ie3d-3d-geometry-vlms-zh","VLM-IE3D替VLM補上3D幾何","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784872975550-yi8q.png","2026-07-24T06:02:30.1684+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"abb4a4d3-19d3-4392-b8bb-14f57d083348","openai-test-model-broke-into-hugging-face-servers-zh","OpenAI 測試模型闖進 Hugging Face 伺服器","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784829771266-0mzj.png","2026-07-23T18:02:29.01097+00:00",[78,83,88,93,98,103,108,113,118,123],{"id":79,"slug":80,"title":81,"created_at":82},"f18dbadb-8c59-4723-84a4-6ad22746c77a","deepmind-bets-on-continuous-learning-ai-2026-zh","DeepMind 押注 2026 連續學習 AI","2026-03-26T08:16:02.367355+00:00",{"id":84,"slug":85,"title":86,"created_at":87},"f4a106cb-02a6-4508-8f39-9720a0a93cee","ml-papers-of-the-week-github-research-desk-zh","每週 ML 論文清單，為何紅到 GitHub","2026-03-27T01:11:39.284175+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"c4f807ca-4e5f-47f1-a48c-961cf3fc44dc","ai-ml-conferences-to-watch-in-2026-zh","2026 AI 研討會投稿時程整理","2026-03-27T01:51:53.874432+00:00",{"id":94,"slug":95,"title":96,"created_at":97},"cf046742-efb2-4753-aef9-caed5da5e32e","adaptive-block-scaled-data-types-zh","IF4：神經網路量化的聰明選擇","2026-03-31T06:00:36.990273+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"53a0dc54-0371-4e40-8d5e-74e94a73840c","geometry-aware-similarity-metrics-for-neural-representations-zh","超越距離測量：用微分幾何重新理解神經網路","2026-03-31T06:01:01.241968+00:00",{"id":104,"slug":105,"title":106,"created_at":107},"fee7d472-a775-4b1d-bbc2-1e8bca1bbf8b","on-the-fly-repulsion-in-the-contextual-space-for-rich-divers-zh","讓AI繪圖更有創意：用排斥力提升生成多樣性","2026-03-31T06:01:25.439673+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"a9901203-d69b-447b-8854-15d14eab32b4","vision-aided-beam-prediction-cnn-eca-zh","影像輔助波束預測升級 CNN","2026-04-01T10:00:25.8073+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"b55e7dd4-0a24-4b3d-804d-b0309a03f498","triple-band-fss-mimo-antenna-sub-6-ghz-zh","三頻 FSS MIMO 天線瞄準 sub-6 GHz","2026-04-01T13:18:36.857305+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"f68290bd-e7f3-4b30-ba22-dcd4e0130a66","openclaw-1299-repos-eight-weeks-analysis-zh","OpenClaw 1299 個 Repo 的資料解讀","2026-04-02T05:03:45.208411+00:00",{"id":124,"slug":125,"title":126,"created_at":127},"ed9f80eb-eb02-4d35-8ad4-0ddf428751dd","beam-coherence-aware-combining-mmwave-mimo-zh","毫米波 MIMO 的雙階合併法","2026-04-02T05:27:26.897188+00:00"]