<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
    <channel>
      <title>Memory Pieces</title>
      <link>https://bugloop.com</link>
      <description>最近的 10 條筆記 on Memory Pieces</description>
      <generator>Quartz -- quartz.jzhao.xyz</generator>
      <item>
    <title>Laradock 多專案架構</title>
    <link>https://bugloop.com/Topics/Docker-%E6%9C%AC%E6%A9%9F%E9%96%8B%E7%99%BC/Laradock-%E5%A4%9A%E5%B0%88%E6%A1%88%E6%9E%B6%E6%A7%8B</link>
    <guid>https://bugloop.com/Topics/Docker-%E6%9C%AC%E6%A9%9F%E9%96%8B%E7%99%BC/Laradock-%E5%A4%9A%E5%B0%88%E6%A1%88%E6%9E%B6%E6%A7%8B</guid>
    <description><![CDATA[ 一份 laradock 同時服務多個專案的關鍵，是 .env 的 APP_CODE_PATH_HOST=../——掛載的是 laradock 的父目錄，不是某個專案資料夾。把 laradock 與各專案放在同一層，父目錄底下每個專案就都被掛進 container 的 /var/www/&lt;專案名&gt;。 C:\code\ ├── laradock\ # 一份，所有專案共用 ├── project-1\ # → /var/www/project-1 └── project-2\ # → /var/www/project-2 為什麼這樣就能多專案並存 laradock 容器（nginx / ... ]]></description>
    <pubDate>Wed, 03 Jun 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Laradock</title>
    <link>https://bugloop.com/Topics/Docker-%E6%9C%AC%E6%A9%9F%E9%96%8B%E7%99%BC/bookmark-Laradock-Docker%E9%96%8B%E7%99%BC%E7%92%B0%E5%A2%83</link>
    <guid>https://bugloop.com/Topics/Docker-%E6%9C%AC%E6%A9%9F%E9%96%8B%E7%99%BC/bookmark-Laradock-Docker%E9%96%8B%E7%99%BC%E7%92%B0%E5%A2%83</guid>
    <description><![CDATA[ Laradock 是基於 Docker 的完整 PHP 本機開發環境，預先打包 nginx、php-fpm、MySQL / MariaDB、Redis、phpMyAdmin 等 70+ 服務，用 docker-compose 選用啟動。把 laradock 與專案資料夾並列同層、設 APP_CODE_PATH_HOST=../，一份環境即可服務多個專案；雖以 Laravel 為名，純 PHP / CodeIgniter 等專案同樣適用。 連結 官網 / 文件：laradock.io/ Repo：github.com/laradock/laradock 相關 Laradock-多專案架構 — 一... ]]></description>
    <pubDate>Wed, 03 Jun 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Docker 本機開發</title>
    <link>https://bugloop.com/Topics/Docker-%E6%9C%AC%E6%A9%9F%E9%96%8B%E7%99%BC/</link>
    <guid>https://bugloop.com/Topics/Docker-%E6%9C%AC%E6%A9%9F%E9%96%8B%E7%99%BC/</guid>
    <description><![CDATA[ 用 Laradock 在 Windows + Docker Desktop 跑既有專案的本機開發環境，啟動模板與初始化踩坑 ]]></description>
    <pubDate>Wed, 03 Jun 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Python 直譯器指令名跨平台選擇</title>
    <link>https://bugloop.com/Cards/Python-%E7%9B%B4%E8%AD%AF%E5%99%A8%E6%8C%87%E4%BB%A4%E5%90%8D%E8%B7%A8%E5%B9%B3%E5%8F%B0%E9%81%B8%E6%93%87</link>
    <guid>https://bugloop.com/Cards/Python-%E7%9B%B4%E8%AD%AF%E5%99%A8%E6%8C%87%E4%BB%A4%E5%90%8D%E8%B7%A8%E5%B9%B3%E5%8F%B0%E9%81%B8%E6%93%87</guid>
    <description><![CDATA[ 跨平台 skill 的腳本呼叫，不假設單一 Python 指令名永遠存在。實務規則是：先跑 python3；如果錯誤明確是命令不存在，再改跑 python。 為什麼先找 python3 python3 是 macOS / Linux 的正規名，能避開裸 python 不存在或指向不明版本的問題： macOS 現代版：已移除 /usr/bin/python，裸 python 可能 not found；這正是當初 mac sync 失敗的根因。 Linux：python3 正規名，python 常缺。 Windows：不同安裝來源差異較大，官方 installer、Python Install M... ]]></description>
    <pubDate>Tue, 02 Jun 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>GitHub Actions PR merge Discord 通知</title>
    <link>https://bugloop.com/Topics/%E9%83%A8%E7%BD%B2/GitHub-Actions-PR-merge-Discord-%E9%80%9A%E7%9F%A5</link>
    <guid>https://bugloop.com/Topics/%E9%83%A8%E7%BD%B2/GitHub-Actions-PR-merge-Discord-%E9%80%9A%E7%9F%A5</guid>
    <description><![CDATA[ obsidian-memory repo 在 .github/workflows/discord-notify.yml 設定 PR merge 後送 Discord Embed 通知。Webhook 原理見 bookmark-Discord-Webhook-CI通知用；Secret 放哪層、怎麼命名見 GitHub-Actions-Secrets-與-Variables。 觸發條件 on: pull_request: types: [closed] jobs: notify: if: github.event.pull_request.merged == true closed 同時涵蓋「關閉... ]]></description>
    <pubDate>Tue, 02 Jun 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>GitHub Actions Secrets 與 Variables</title>
    <link>https://bugloop.com/Topics/%E9%83%A8%E7%BD%B2/GitHub-Actions-Secrets-%E8%88%87-Variables</link>
    <guid>https://bugloop.com/Topics/%E9%83%A8%E7%BD%B2/GitHub-Actions-Secrets-%E8%88%87-Variables</guid>
    <description><![CDATA[ repo → Settings → Secrets and variables → Actions。兩條軸交叉成四格：敏感與否（Secrets / Variables）×作用範圍（Repository / Environment）。案例見 GitHub-Actions-PR-merge-Discord-通知；鍵名怎麼取見 環境變數-Secret-命名規範。 Secrets vs Variables SecretsVariables儲存加密、log 遮蔽、建立後讀不回明文、可見用途token、webhook URL、密碼region、image tag、flag取用${{ secrets.NAM... ]]></description>
    <pubDate>Tue, 02 Jun 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>環境變數 / Secret 命名規範</title>
    <link>https://bugloop.com/Topics/%E9%83%A8%E7%BD%B2/%E7%92%B0%E5%A2%83%E8%AE%8A%E6%95%B8-Secret-%E5%91%BD%E5%90%8D%E8%A6%8F%E7%AF%84</link>
    <guid>https://bugloop.com/Topics/%E9%83%A8%E7%BD%B2/%E7%92%B0%E5%A2%83%E8%AE%8A%E6%95%B8-Secret-%E5%91%BD%E5%90%8D%E8%A6%8F%E7%AF%84</guid>
    <description><![CDATA[ CI secret、環境變數、.env 鍵名的命名慣例。實際取捨脈絡見 GitHub-Actions-Secrets-與-Variables。 規則與慣例 UPPER_SNAKE_CASE：作為環境變數注入的慣例寫法。 只能字母／數字／底線，不可數字開頭。 GitHub Actions 另禁 GITHUB_ 前綴（保留）。 結構：&lt;服務&gt;_&lt;資源&gt;_&lt;型別&gt; 服務前綴 標歸屬：DISCORD_、AWS_、SLACK_。 型別後綴 標「是什麼」：_URL、_TOKEN、_KEY、_ID。 DISCORD_WEBHOOK vs DISCORD_WEBHOOK_U... ]]></description>
    <pubDate>Tue, 02 Jun 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Claude Code Windows 雙 shell 問題</title>
    <link>https://bugloop.com/Topics/Claude-Code/Claude-Code-Windows-%E9%9B%99-shell-%E5%95%8F%E9%A1%8C</link>
    <guid>https://bugloop.com/Topics/Claude-Code/Claude-Code-Windows-%E9%9B%99-shell-%E5%95%8F%E9%A1%8C</guid>
    <description><![CDATA[ Claude Code 在 Windows（platform=win32）上，模型常反射性吐 bash/Unix 語法——printf、$_、[ -f ]、extglob、/dev/null 照抄進 PowerShell 就失敗；拿到「不是 cmdlet」錯誤後還常不自我糾正，反覆重試同一條壞指令。這是官方 repo 多個公開 issue 都踩到的已知問題（見來源），不是個案。 為什麼會有兩個 shell Windows 原生 PowerShell，但 Claude Code 的 PowerShell 工具：沒裝 Git Bash 時自動啟用，裝了則走漸進式 rollout（未輪到前仍走 Gi... ]]></description>
    <pubDate>Mon, 01 Jun 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>LLM Wiki 方法論</title>
    <link>https://bugloop.com/Cards/LLM-Wiki-%E6%96%B9%E6%B3%95%E8%AB%96</link>
    <guid>https://bugloop.com/Cards/LLM-Wiki-%E6%96%B9%E6%B3%95%E8%AB%96</guid>
    <description><![CDATA[ Karpathy 提出的個人知識庫模式：不靠 RAG 即時擷取，而是讓 LLM 漸進式建立並維護一個持久、互聯的 markdown wiki，夾在你與原始資料之間。本 vault 自身就是這套模式的實作，這篇是它的方法論原典與出處。 與 RAG 的根本差異 RAG 每次查詢都從原始文件重新擷取、重新拼湊——什麼都不累積，問一個需要綜合五份文件的問題，每次都得重找。 LLM Wiki 相反：知識被編譯一次後持續維護。交叉引用已建好、矛盾已標記、綜合分析已反映讀過的所有內容。wiki 是複利資產——每加一個來源、每問一個問題都讓它更豐富。 判準：知識要不要跨時間累積、要不要互聯成網 → 用 Wik... ]]></description>
    <pubDate>Fri, 29 May 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>AI 設計品質量化檢測</title>
    <link>https://bugloop.com/Topics/UI%E8%A8%AD%E8%A8%88/AI-%E8%A8%AD%E8%A8%88%E5%93%81%E8%B3%AA%E9%87%8F%E5%8C%96%E6%AA%A2%E6%B8%AC</link>
    <guid>https://bugloop.com/Topics/UI%E8%A8%AD%E8%A8%88/AI-%E8%A8%AD%E8%A8%88%E5%93%81%E8%B3%AA%E9%87%8F%E5%8C%96%E6%AA%A2%E6%B8%AC</guid>
    <description><![CDATA[ AI 生成設計最大的問題不是「不好看」，而是使用者很難說清楚哪裡壞。與其反覆要求「再好看一點」，更穩的做法是建立一套可重跑的檢測閉環：先把明顯壞偏離抓出來，修完再跑一次。 這是 Claude-Code-前端設計工作流 的反向切角：前者處理「怎麼生出設計」，這篇處理「怎麼檢測 AI 生出的設計哪裡壞」。 最小可用閉環 實作上不需要一開始追完整研究工具鏈。最有價值的是能讓 AI 在每次改版後自己重跑、自己修正、再重跑確認的檢測： CSS token / 視覺一致性統計 用 Playwright 讀實際頁面，統計顏色、字級、圓角、陰影、按鈕樣式。 抓「同一語意卻有多套樣式」：太多灰階、太多 font... ]]></description>
    <pubDate>Wed, 27 May 2026 00:00:00 GMT</pubDate>
  </item>
    </channel>
  </rss>