[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-tls-turns-insecure-links-into-encrypted-sessions-zh":3,"article-related-tls-turns-insecure-links-into-encrypted-sessions-zh":30,"series-research-42510df4-4692-44c6-a45a-c82a4a86b646":81},{"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},"42510df4-4692-44c6-a45a-c82a4a86b646","tls-turns-insecure-links-into-encrypted-sessions-zh","TLS 把明文連線變成加密會話","\u003Cp data-speakable=\"summary\">我拆 TLS 的握手、憑證檢查和可直接複製的設定模板，讓你能把它真的用在服務裡。\u003C\u002Fp>\u003Cp>我碰 TLS 很久了，老實說它最煩的地方不是加密本身，是大家都把它當 checkbox。開 HTTPS、丟個憑證、瀏覽器綠鎖一亮，就以為收工。結果一進 production，才開始分不清楚到底是憑證鏈壞了、cipher suite 不合、client 太舊，還是 server 自己配了一套「我覺得安全」的\u003Ca href=\"\u002Fnews\u002Fgenius-act-turns-eth-pressure-into-regulation-zh\">規則\u003C\u002Fa>。這種感覺我太熟了：TLS 表面上像一層透明包裝，實際上是滿地尖刺的協商流程。\u003C\u002Fp>\u003Cp>我後來會看懂它，是因為我不再聽那些 folklore，而是回頭看原始說明。這次我主要拆的是 \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FTransport_Layer_Security\">Transport Layer Security\u003C\u002Fa>，外加 \u003Ca href=\"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc8446\">RFC 8446\u003C\u002Fa>（TLS 1.3）跟 \u003Ca href=\"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc5246\">RFC 5246\u003C\u002Fa>（TLS 1.2）。這些文件很硬，但它們至少不會騙你：TLS 不是「HTTPS 的外殼」，它是 client 和 server 在任何資料傳出去之前，先談好\u003Ca href=\"\u002Fnews\u002Funderstand-clarity-act-crypto-market-structure-zh\">怎麼\u003C\u002Fa>互相信任的流程。\u003C\u002Fp>\u003Cp>我現在看 TLS 的方式很簡單：它不是「把資料加密」而已，它是先談判、再建立共享狀態、最後才開始傳資料。你只要把這個順序搞懂，很多平常被罵成「TLS 很不穩」的問題，會突然變得很有跡可循。這篇我就照這個順序拆，最後給你一段可以直接抄去你服務設定裡的模板。\u003C\u002Fp>\u003Ch2>TLS 不是加密而已，它先在談判\u003C\u002Fh2>\u003Cblockquote>\"The protocol is designed to provide communications security over a computer network.\"\u003C\u002Fblockquote>\u003Cp>白話翻譯就是：TLS 的重點不是「把東西蓋起來」，而是先決定這條連線值不值得蓋。client 和 server 不會一上來就直接加密資料，它們先談版本、談演算法、談怎麼驗證對方、談用哪個 shared secret。談不攏，連線就不成立。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780596207456-9or4.png\" alt=\"TLS 把明文連線變成加密會話\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前最常看到有人把 TLS 叫成「port 443 上的加密」。這句話不是全錯，但很沒用。真正有價值的部分是 handshake。因為 handshake 會決定這條連線到底有沒有 confidentiality、integrity、authentication。你如果只記得「有 HTTPS」，卻不知道它怎麼握手，那你在 debug 的時候只是在猜。\u003C\u002Fp>\u003Cp>我現在看一個服務的 TLS 設定，第一個問題不是「有沒有開」，而是「它到底保證了\u003Ca href=\"\u002Fnews\u002Fwhy-ethereums-bear-case-is-wrong-zh\">什麼\u003C\u002Fa>」。是只加密？還是也驗證 server 身分？有沒有 client auth？有沒有防 tampering？這三件事其實是分開的，TLS 只是把它們塞進同一個協商流程裡。\u003C\u002Fp>\u003Cp>實操寫法很簡單：你在設計或 review 服務時，先把三個問題寫出來，再去看設定。\u003C\u002Fp>\u003Cul>\u003Cli>我到底要保密什麼資料？\u003C\u002Fli>\u003Cli>我要驗證誰的身分？server、client，還是兩邊都要？\u003C\u002Fli>\u003Cli>如果有人改包，我怎麼知道？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果這三題答不出來，先別急著談 cipher。你連目標都沒定，談加密只是裝忙。\u003C\u002Fp>\u003Ch2>握手流程才是 TLS 的主場\u003C\u002Fh2>\u003Cp>TLS 最像工程現場的地方，就是 handshake。client 先送自己支援的版本和 cipher suites，server 挑一個能接受的組合，接著 server 丟出 certificate，client 去驗證，最後雙方再建立 session keys。RFC 8446 把這個流程寫得很清楚，TLS 1.3 甚至把很多老包袱砍掉，讓握手更乾淨。\u003C\u002Fp>\u003Cp>翻譯一下就是：TLS 不是「有沒有加密」的二元問題，而是一連串選擇。版本不合，掛。cipher 沒交集，掛。憑證鏈不對，掛。key exchange 算不出共同秘密，還是掛。這些不是 bug，這些是 protocol 在告訴你：這條線不值得信。\u003C\u002Fp>\u003Cp>我之前在一個 service mesh 專案裡踩過這種坑。應用團隊一直說 network 沒問題，因為 packet 看起來有到。結果一看 handshake log，真相很直白：client 和 server 互看得到，但根本談不攏安全參數。TLS 不在乎你 packet 有沒有送到，它只在乎你有沒有成功協商出一條可用的安全連線。\u003C\u002Fp>\u003Cp>實操寫法：把 handshake failure 跟 application failure 分開記錄。不要把它們混成「連線失敗」四個字，這樣你只會在事故時候多一層霧。\u003C\u002Fp>\u003Cul>\u003Cli>記錄 client hello 版本和 server choice。\u003C\u002Fli>\u003Cli>記錄憑證驗證失敗原因。\u003C\u002Fli>\u003Cli>記錄 cipher overlap 不足的情況。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>再來，supported cipher list 別貪多。列表很長不代表你很強，通常只代表你還沒決定自己要什麼。\u003C\u002Fp>\u003Ch2>憑證不是裝飾，是 trust chain\u003C\u002Fh2>\u003Cp>憑證這件事，很多人嘴上懂，實際上還是當成貼紙。TLS 文件會說 server 通常會提供 digital certificate，裡面有 server name、trusted CA、public key。這句話看起來很乾，其實意思很重：憑證是 server 對自己身分的主張，而 CA 是第三方替這個主張背書。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780596196152-bwgx.png\" alt=\"TLS 把明文連線變成加密會話\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>也就是說，TLS 的 authentication 不是 server 自己喊「信我」。它是拿一個簽過名的物件給 client 驗，client 再對照 trust store。name 不對、chain 斷掉、CA 不在信任清單裡，client 就應該擋下來。這不是麻煩，這就是設計本意。\u003Ca href=\"https:\u002F\u002Fwww.cloudflare.com\u002Flearning\u002Fssl\u002Fwhat-is-a-root-certificate\u002F\">根憑證\u003C\u002Fa>、中繼憑證、站點憑證這一整條鏈，少一環都不行。\u003C\u002Fp>\u003Cp>我看過不少團隊對著瀏覽器吐槽：「為什麼我們內網服務明明是自己架的，還一直報憑證錯？」我每次都想回一句：對啊，因為你沒有把 trust model 做完。你如果要 browser 或 client 相信你，就得給它能驗證的 chain，還得讓 hostname 對得上 endpoint。想跳過這些，就別說你在用 TLS，你只是把驗證關掉而已。\u003C\u002Fp>\u003Cp>實操寫法：把憑證管理當成部署基礎設施，不要當一次性雜務。\u003C\u002Fp>\u003Cul>\u003Cli>自動續期，不要靠人記憶。\u003C\u002Fli>\u003Cli>在 staging 測 hostname mismatch。\u003C\u002Fli>\u003Cli>把 expiry alert 設在真的來得及處理的窗口。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你有 internal PKI，請把 trust chain 寫進文件。沒人應該靠猜來理解你的安全邊界。\u003C\u002Fp>\u003Ch2>forward secrecy 才是值得保的底線\u003C\u002Fh2>\u003Cp>我現在 review TLS，最在意的不是「有沒有加密」，而是「過去的流量會不會被未來的 key 反查」。這就是 forward secrecy。RFC 8446 用的 key exchange 只保留提供 forward secrecy 的做法，這點我很買單，因為它把風險切得比較乾淨。\u003C\u002Fp>\u003Cp>白話翻譯：如果有人今天把你的 server private key 偷走，最好不要順便把上個月錄下來的流量也一起解開。沒有 forward secrecy 的話，一把長期 key 可能就變成整包歷史流量的萬能鑰匙。那種 blast radius 很難看。\u003C\u002Fp>\u003Cp>我以前 review 過一個對外 \u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa>，團隊一直以為「TLS 就是 TLS」。結果一挖，config 還留著舊式 key exchange，因為沒人整理過。修法一點都不性感，就是把 legacy 選項砍掉、測 client、再上線。可是安全姿勢差很多。\u003C\u002Fp>\u003Cp>實操寫法：如果能用 TLS 1.3，就優先用。真的還卡在 TLS 1.2，也至少要把 forward-secret 的 key exchange 排前面，別讓舊模式混進來當預設。\u003C\u002Fp>\u003Cul>\u003Cli>優先 TLS 1.3。\u003C\u002Fli>\u003Cli>TLS 1.2 只留必要的相容性。\u003C\u002Fli>\u003Cli>把長期 key 外洩後的影響範圍想清楚。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這不是學術潔癖，這是 incident response 的基本常識。\u003C\u002Fp>\u003Ch2>DTLS 是給不是 stream 的世界用的\u003C\u002Fh2>\u003Cp>TLS 的親戚叫 \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FDatagram_Transport_Layer_Security\">DTLS\u003C\u002Fa>，也就是 Datagram Transport Layer Security。它是給 UDP、SCTP、SRTP 這種 datagram 世界用的。這件事很重要，因為不是所有應用都適合 TCP 那種「看起來很穩」的 stream 假象。\u003C\u002Fp>\u003Cp>翻譯一下就是：如果你的資料會亂序、會遺失、會重送，安全層也要懂這個現實。DTLS 不是把 TLS 原封不動搬過去，而是把安全屬性留著，然後適配底層 transport 的混亂程度。這才是正確的想法。\u003C\u002Fp>\u003Cp>我比較常在即時通訊、VPN、語音影像這類場景看到 DTLS。重點不是「DTLS 比 TLS 高級」，而是你不能拿 stream 的腦袋去套 packet 的世界。很多系統後來會痛，就是因為一開始選錯 transport，後面再補安全層，整個架構就卡住了。\u003C\u002Fp>\u003Cp>實操寫法：先選 transport，再選安全層，不要反過來。\u003C\u002Fp>\u003Cul>\u003Cli>TCP 場景多半用 TLS。\u003C\u002Fli>\u003Cli>UDP 場景考慮 DTLS。\u003C\u002Fli>\u003Cli>不要把熟悉的工具硬塞到不對的協定上。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這句聽起來很廢，但真的很多事故都是這樣來的。\u003C\u002Fp>\u003Ch2>大多數 TLS 問題其實是配置問題\u003C\u002Fh2>\u003Cp>很多人一談 TLS 就想到攻擊名詞：downgrade、Heartbleed、POODLE。那些當然重要，但對大部分團隊來說，真正出事的原因通常沒那麼戲劇化。比較常見的是舊版本、爛預設、庫升級沒跟上、reverse proxy 設定亂掉。\u003C\u002Fp>\u003Cp>也就是說，問題通常不是「TLS 不夠神」，而是你沒有把版本、cipher、憑證、library、proxy 行為當成一整套系統在管。你只要其中一層比其他層弱，整個安全性就會被拖下去。\u003C\u002Fp>\u003Cp>我很常被問：「我們不是已經用了 TLS 嗎？」我通常會反問：你是用哪個版本？哪些 cipher？憑證從哪裡來？誰負責 renew？load balancer 會不會偷偷改行為？這些問題答不出來，就別急著說自己有安全。\u003C\u002Fp>\u003Cp>實操寫法：把 TLS policy 當成 API compatibility policy 來管。\u003C\u002Fp>\u003Cul>\u003Cli>定義允許的 protocol versions。\u003C\u002Fli>\u003Cli>列出禁止的 legacy ciphers。\u003C\u002Fli>\u003Cli>寫明 renewal 流程和 deprecation 路線。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>然後在 CI 或 staging 直接測，不要等到 outage 才知道某個老 client 還活著。\u003C\u002Fp>\u003Ch2>把 TLS 當成協商系統，而不是 checkbox\u003C\u002Fh2>\u003Cp>如果我要把整篇壓成一句話，我會說：TLS 不是裝飾性的加密開關，它是 negotiated trust system。client 和 server 先談好身份、能力、秘密，然後才開始傳資料。你只要把這個順序搞懂，很多看似玄學的問題就會變得很工程。\u003C\u002Fp>\u003Cp>這個框架也很適合拿去跟非密碼學背景的同事溝通。你不用解釋每個數學細節，只要講清楚它要保證什麼、在哪裡會失敗、失敗時誰會看到什麼錯誤。這就夠了。真的夠了。\u003C\u002Fp>\u003Cp>實操寫法：每個服務的文件都應該至少寫出這四件事。\u003C\u002Fp>\u003Cul>\u003Cli>TLS 版本\u003C\u002Fli>\u003Cli>憑證來源與 renewal 方式\u003C\u002Fli>\u003Cli>client 相容性\u003C\u002Fli>\u003Cli>失敗時的 log 位置\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你寫不出來，通常不是文件能力差，是你自己的 TLS 設定還沒整理好。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># TLS service playbook（可直接貼進你的 repo \u002F runbook）\n\n## 1) 這條服務要保證什麼\n- Confidentiality: yes\u002Fno\n- Integrity: yes\u002Fno\n- Server authentication: yes\u002Fno\n- Client authentication: yes\u002Fno\n\n## 2) 協定選擇\n- TLS version(s): TLS 1.3, TLS 1.2 only if legacy clients require it\n- DTLS needed: yes\u002Fno\n- Forward secrecy required: yes\n\n## 3) 憑證政策\n- Certificate source: internal CA \u002F public CA\n- Hostname(s) covered:\n- Renewal method:\n- Expiration alert window:\n- Trust store location:\n\n## 4) Cipher \u002F key exchange 政策\n- Allowed cipher suites:\n- Disallowed legacy suites:\n- Key exchange preference:\n- Compression disabled: yes\n- Renegotiation policy:\n\n## 5) 操作檢查\n- Handshake failure logging enabled: yes\n- Certificate expiry monitoring enabled: yes\n- Staging test for hostname mismatch: yes\n- Staging test for expired cert: yes\n- Staging test for protocol downgrade: yes\n\n## 6) Client 相容性\n- Browsers:\n- Mobile apps:\n- API clients:\n- Explicitly unsupported old clients:\n\n## 7) 事故處理\n- What to rotate if a private key leaks:\n- Whether old sessions remain protected by forward secrecy:\n- Where to revoke or replace trust anchors:\n\n## 8) 對外說明句\nThis service uses TLS to negotiate identity, key exchange, and encryption before application data flows.\nWe require forward-secret key exchange where supported and reject expired, mismatched, or untrusted certificates.\nTLS failures are treated as security failures, not transport noise.\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這段我刻意寫得很樸素，因為它不是要拿來炫技，是要拿來讓團隊對齊。你可以直接把它貼進 README、runbook，或是部署 checklist。重點不是字漂亮，是你真的有把 TLS 當成一個可操作的系統。\u003C\u002Fp>\u003Cp>原始拆解主要來自 \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FTransport_Layer_Security\">Wikipedia 的 Transport Layer Security\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc8446\">RFC 8446\u003C\u002Fa>，以及 \u003Ca href=\"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc5246\">RFC 5246\u003C\u002Fa>。我這篇的白話整理、判讀方式和模板是我自己整理的；協定名詞、流程與定義則是衍生自上述來源。\u003C\u002Fp>","我拆 TLS 的握手、憑證檢查和可直接複製的設定模板，讓你能把它真的用在服務裡。","en.wikipedia.org","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FTransport_Layer_Security",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780596207456-9or4.png","research","zh","0feba7dc-6027-4e75-bcf3-62d3e2a090a7",[17,18,19,20,21],"TLS","handshake","certificate","forward secrecy","RFC 8446",[23,24,25],"TLS 先協商再加密，握手失敗才是最常見的真相。","憑證是 trust chain，不是裝飾；hostname 和 renewal 都要管。","把 TLS 當成可操作的政策文件，而不是開關。",0,"2026-06-04T18:02:50.988357+00:00","2026-06-04T18:02:50.978+00:00","0c35a120-52fc-41fc-afa3-d404eb934158",{"tags":31,"relatedLang":40,"relatedPosts":44},[32,34,36,38,39],{"name":20,"slug":33},"forward-secrecy",{"name":17,"slug":35},"tls",{"name":21,"slug":37},"rfc-8446",{"name":19,"slug":19},{"name":18,"slug":18},{"id":15,"slug":41,"title":42,"language":43},"tls-turns-insecure-links-into-encrypted-sessions-en","TLS turns insecure links into encrypted sessions","en",[45,51,57,63,69,75],{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"923bb0c4-95f3-49a0-8e01-5cdd6bcd2e32","fixing-llm-forgetting-es-fine-tuning-zh","ES 微調忘記問題有解了","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780604276240-arx4.png","2026-06-04T20:17:25.720929+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"4fa896da-9616-425a-92bc-c1d7d5861ff9","streamma-multi-agent-reasoning-latency-zh","StreamMA 讓多代理推理邊想邊傳","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780554786134-1w1d.png","2026-06-04T06:32:32.769423+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"f31f51ba-4445-4e43-9bda-31e70f53d42b","audio-language-models-arbitration-reversals-zh","音訊模型不是聽不懂","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780553877373-ux95.png","2026-06-04T06:17:27.890159+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"447ac6c9-477b-45c8-bec2-ff94dc4cf5d4","stride-training-data-attribution-sparse-recovery-zh","STRIDE 讓訓練資料歸因快 13 倍","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780552979370-897a.png","2026-06-04T06:02:29.149166+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"33c9a55c-a8c0-4367-b742-f4567d1e98e3","mathematicians-warn-ai-could-distort-math-zh","數學界警告 AI 會扭曲證明標準","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780504386035-080l.png","2026-06-03T16:32:29.415063+00:00",{"id":76,"slug":77,"title":78,"cover_image":79,"image_url":79,"created_at":80,"category":13},"5c3cb90f-7efd-426f-8c09-32a303f82be9","humanoid-gpt-zero-shot-motion-tracking-zh","Humanoid-GPT：用 GPT 擴大動作追蹤","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780469319284-znpc.png","2026-06-03T06:47:34.463464+00:00",[82,87,92,97,102,107,112,117,122,127],{"id":83,"slug":84,"title":85,"created_at":86},"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":88,"slug":89,"title":90,"created_at":91},"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":93,"slug":94,"title":95,"created_at":96},"c4f807ca-4e5f-47f1-a48c-961cf3fc44dc","ai-ml-conferences-to-watch-in-2026-zh","2026 AI 研討會投稿時程整理","2026-03-27T01:51:53.874432+00:00",{"id":98,"slug":99,"title":100,"created_at":101},"cf046742-efb2-4753-aef9-caed5da5e32e","adaptive-block-scaled-data-types-zh","IF4：神經網路量化的聰明選擇","2026-03-31T06:00:36.990273+00:00",{"id":103,"slug":104,"title":105,"created_at":106},"53a0dc54-0371-4e40-8d5e-74e94a73840c","geometry-aware-similarity-metrics-for-neural-representations-zh","超越距離測量：用微分幾何重新理解神經網路","2026-03-31T06:01:01.241968+00:00",{"id":108,"slug":109,"title":110,"created_at":111},"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":113,"slug":114,"title":115,"created_at":116},"a9901203-d69b-447b-8854-15d14eab32b4","vision-aided-beam-prediction-cnn-eca-zh","影像輔助波束預測升級 CNN","2026-04-01T10:00:25.8073+00:00",{"id":118,"slug":119,"title":120,"created_at":121},"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":123,"slug":124,"title":125,"created_at":126},"f68290bd-e7f3-4b30-ba22-dcd4e0130a66","openclaw-1299-repos-eight-weeks-analysis-zh","OpenClaw 1299 個 Repo 的資料解讀","2026-04-02T05:03:45.208411+00:00",{"id":128,"slug":129,"title":130,"created_at":131},"ed9f80eb-eb02-4d35-8ad4-0ddf428751dd","beam-coherence-aware-combining-mmwave-mimo-zh","毫米波 MIMO 的雙階合併法","2026-04-02T05:27:26.897188+00:00"]