kyosora 筆記

你有沒有遇過這種情況：Claude Code 跑到一半說「完成了」，結果測試根本沒過？或是修好一個 bug 後，卻發現另外三個地方壞掉？ 更慘的是，每次都要手動檢查、手動下指令、再手動確認。一個簡單的「把所有測試跑通」任務，你可能要來回操作 10 次以上。 有個技術能讓 Claude Code 自己迭代、自己修 bug、自己跑測試，直到真的完成為止——甚至有人用它讓 AI 自主開發了整整 3 個月，做出一個完整的程式語言編譯器。 這就是 Ralph Wiggum。 問題：AI 的「一次性思維」困境症狀 1：虛假的「完成」Claude Code 很聰明，但它有個致命問題：它以為自己做完了，但其實沒有。 1234你：「幫我把這個 API 的測試覆蓋率提升到 80%」Claude：「好的，我已經新增了 5 個測試檔案」你：npm test結果：❌ 12 tests failed, coverage: 45% 問題在哪？Claude 寫完測試就認為任務結束，但它沒有真正驗證結果。 症狀 2：迭代開發的高成本真實的開發場景通常是： 寫程式碼 跑測試 → 失敗 看錯誤訊息 修 bug 再...

你以為 AI 模型競爭就是打價格戰？ OpenRouter 剛發佈的報告分析了 100 兆 tokens 的真實使用資料，發現一個驚人事實：**降價 10%，使用量只增加 0.5-0.7%**。 更扯的是，Claude 價格最貴，卻占了編程市場 60%。 到底發生什麼事？ 為什麼這份報告值得關注？這不是又一份「AI 趨勢預測」報告。 OpenRouter 是全球最大的 LLM API 聚合平台： 支援 300+ 模型 60+ 供應商（OpenAI、Anthropic、Google、DeepSeek...） 100 兆 tokens 真實使用資料（2024/11 - 2025/11） 這份報告揭露了三個開發者必須知道的反直覺發現。 發現 1：價格戰是假議題資料打臉時刻 策略 實際結果 降價 10% 使用量 ↑ 0.5-0.7% Claude（最貴） 編程市場占 60% DeepSeek（便宜） 使用者流失後又回流 報告原話： "需求缺乏價格彈性，使用者優先考慮品質和可靠性而非價格。" 為什麼會這樣？工程師選模型的真實決策流程：...

「幫我清理一下舊 repo 的 packages」——這句話毀了一個開發者的整個 Mac。 2025 年某個普通的工作日，Reddit 使用者在 r/ClaudeAI 發了一篇求救文：「Claude CLI 刪了我整個家目錄，所有工作都沒了！這能救回來嗎？」 這不是第一起，也不會是最後一起。GitHub Issues 上有超過 10 起類似的嚴重事件回報。當 AI Coding Assistant 變得越來越強大，誰該為這些災難負責？ 災難現場：一個 ~/ 引發的血案事件經過使用者的原始請求很簡單：「清理舊 repo 的 packages」。 Claude Code 生成並執行了這個命令： 1rm -rf tests/ patches/ plan/ ~/ 看到問題了嗎？ 最後的 ~/ 不是某個目錄名稱，而是使用者的整個家目錄。 損失清單這個命令執行後，使用者失去了： ✅ 整個 Desktop（桌面上的所有檔案） ✅ Documents、Downloads（多年的文件與下載） ✅ Keychain（所有儲存的密碼和憑證） ✅ ~/.claude（Claude 的設定和歷史記錄）...

前言：你是否也深陷「需求變更地獄」？身為工程師，你是否遇過這種狀況：PM 拍拍肩膀說「這功能很簡單，兩天就能做完吧？」結果兩週後你還在改 bug，因為需求根本沒講清楚？ 或是專案開發到一半，突然有人問「這個功能為什麼要這樣設計？」然後你發現...根本沒有人記得當初的設計理念？ 如果以上情境讓你會心一笑（或想哭），那麼 spec-workflow-mcp 這個工具絕對值得你關注。 什麼是 Spec Workflow MCP？Spec Workflow MCP 是一個專門為軟體開發設計的規格驅動工作流管理工具。簡單來說，它就是要解決一個核心問題：讓開發團隊在寫程式之前，先把要做什麼搞清楚。 這個工具遵循一個很簡單但有效的三階段流程： Requirements（需求） - 確定要做什麼 Design（設計） - 決定怎麼做 Tasks（任務） - 拆解執行步驟 聽起來很理所當然對吧？但現實是，大部分專案都是直接跳到第三步開始寫程式，然後在需求不明確的泥沼中掙扎。 核心功能一覽🖥️ 雙介面支援，開發者友善Web Dashboard 即時專案總覽，一眼掌握進度 文件檢視器，所有...

前情提要：測試機被臨時收走台電那邊因為要做白帽滲透測試，得暫時把測試機關掉。但開發團隊三不五時還是需要一個能驗功能的環境，於是我們把程式臨時搬到另一台機器上跑。原本盤算著，IIS 設個 IP 白名單就能擋住外人，半小時搞定。結果這個白名單，前後折騰了我大半天。 問題：白名單一開，全員 403我在 IIS 管理器的「IP 位址及網域限制」裡，把信任的 IP 一個個加進白名單，存檔，重新整理頁面。畫面回我一個乾脆的 403。 換個設定再試，規律很清楚： 設成「允許未指定的用戶端」→ 一切正常 設成「拒絕未指定的用戶端，只放行白名單」→ 所有人都 403 白名單裡明明有我自己的 IP，怎麼也被擋？翻 IIS Log 才看懂： 1c-ip: 192.168.0.28 每一筆請求的來源 IP 都是 192.168.0.28。這是那台 Proxy Relay 伺服器。外部請求全部先打到它，再由它轉發進 IIS。IIS 眼裡只有代理伺服器這一個來源，真正的客戶端 IP 它根本看不到——白名單再怎麼設都是擋自己人。 追查：真實 IP 藏在哪個標頭代理轉發時，習慣上會把原始客戶端 IP 塞進...

你是不是經常在 Notion 和 Claude 之間來回複製貼上？有了 Notion MCP（Model Context Protocol），Claude 可以直接連接你的 Notion 工作區，幫你建立頁面、整理資料、查詢內容，不用再手動搬資料。 什麼是 Notion MCP？Notion MCP 讓 Claude 可以直接讀寫你的工作區——不只是讀取筆記，還能新增頁面、查詢資料庫、建立結構化內容。 MCP（Model Context Protocol）是 Claude 和外部工具之間的通訊協定。Notion 官方提供了對應的 MCP Server，串接之後 Claude 就能直接操作你的 Notion，而不是只能在旁邊看著。 開始前的準備需要準備的東西： Claude Desktop 應用程式（必須是桌面版，Claude.ai 網頁版不支援 MCP） 一個 Notion 帳戶 基本的終端機操作能力 大約 15 分鐘 第一步：建立 Notion Integration首先要在 Notion 建立一個 Integration，讓 Claude 取得操作工作區的授權。 前往 ...

公司舊系統是 Vue 2，新功能想用 React，遷移又不能一刀切——這個局面在中大型前端團隊裡比想像中常見。Module Federation 最初是 Webpack 5 的功能，後來 @originjs/vite-plugin-federation 把這套機制帶進 Vite 生態，讓跨框架整合在開發體驗上變得可接受。 這篇文章拆解它的原理、給出可實際跑起來的設定，並點出幾個抄網路範例會踩到的坑。 微前端在解決什麼問題一個大型電商平台，商品展示、購物車、會員中心分屬不同團隊。傳統做法是把所有功能打包成單一應用程式，結果： 購物車改一行，整站要重新部署 商品團隊想升 Vue 3，但購物車還繫在 Vue 2 的 API 上 測試牽一髮動全身，沒人敢在上線前改超過三個檔案 微前端把這個大應用拆成多個獨立部署的模組，每個模組有自己的建置流程、自己的技術棧，只在瀏覽器端組合成完整的畫面。 Module Federation 的核心機制Module Federation 讓不同應用程式在執行時動態分享程式碼，不是在建置時打包在一起。 架構裡有兩個角色： Host（主應用程式）：載入並整...

半夜接到電話說網站掛了的感覺，過一次就不想再有第二次。Cloudflare 不是什麼魔法，但它確實解決了大部分小網站會遇到的問題：DDoS、SSL 憑證、DNS 緩慢、靜態資源重複傳輸。 什麼是 Cloudflare？它站在你和流量之間Cloudflare 是一個反向代理網路，全球超過 330 個資料中心，當使用者連到你的網域時，流量先經過 Cloudflare 的節點，再轉發到你的伺服器。這個架構帶來三件事： 流量過濾：惡意請求在邊緣節點就被攔下，DDoS 流量能降低到達源站的機率，但沒有任何系統能保證攔下所有入侵手法。 靜態快取：HTML、CSS、圖片等靜態資源就近回應，不必每次打到源站。 邊緣 SSL：訪客到 Cloudflare 邊緣的連線自動加密，但端到端安全還取決於你選擇的 SSL/TLS 模式與源站憑證狀態（後面細說）。 根據 Cloudflare 2025 年第一季報告，Q1 阻擋了 2,050 萬次 DDoS 攻擊，較去年同期增長 358%。目前他們的網路容量已達 500 Tbps，是 2025 年底有紀錄以來最大攻擊（31.4 Tbps）的約 16 倍。 ...

Github頁面：Context7mcp問題：AI 助手的知識截止日「這段程式碼有問題，Upstash Redis 的連線方式好像不對...」 即使是最新的 LLM，處理快速迭代的函式庫時都有同樣的罩門：訓練資料有截止日，新的 API 或 breaking change 根本不在它的知識範圍內。你貼給它的是 Next.js 14 的問題，它給你的可能是 Next.js 12 的寫法。 這正是 Upstash 團隊開發 Context7 要解決的事。 Context7 怎麼運作Context7 是一個 MCP 伺服器（Model Context Protocol server）。它不是靠爬蟲快取一份舊文件，而是在 AI 助手提出請求時，即時從官方文件與原始碼庫抽取相關片段，組成 AI 可直接讀取的上下文，再送回對話。 整個流程對使用者是透明的：你問問題，AI 在背景呼叫 Context7 的工具取回文件，然後根據真實文件回答。和直接問 AI 的差別是 — 它參考的是你指定版本的官方說明，不是兩年前訓練進去的印象。 Context7 的核心設計有幾點值得注意： 文件來源直接指向原始碼...

前言作為 Python 開發者，你大概都踩過同一批坑：requirements.txt 在本機跑得好好的，換一台機器就版本衝突；conda 解析依賴跑了二十分鐘；新人入職第一天光搭環境就花掉半天。 這篇文章比較 venv、conda 和 uv 三種工具，重點放在實際使用差異，以及 uv 為什麼不只是「更快的 pip」——它其實已經是一套完整的專案管理工具鏈。 venv：Python 內建的解決方案venv 從 Python 3.3 起內建，不需要額外安裝是它最大的優點。 1234python -m venv myenvsource myenv/bin/activate # Linux / macOSmyenv\Scripts\activate # Windowspip install -r requirements.txt 適合的場景： 快速開一個臨時環境驗證想法 CI 環境裡只需要標準工具鏈 維護老專案，不想引入額外依賴 限制： pip 的依賴解析速度慢，套件數量一多就有感 不管理 Python 版本本身，需要另外用 pyenv 或系統 P...