讓 Meta Muse 當三天工程師：三個專案從 MVP 做到 v2.5，每一輪都還有真 bug

前兩篇寫了怎麼在台灣註冊 Muse和兩天的影片實測。這次換一個方向：讓 Muse 寫程式。

做法跟上次一樣，我請 Grok bot 代操。Muse 負責研究和寫程式，交出 zip；Grok bot 負責在乾淨環境解壓、安裝、跑測試、啟動服務，找到問題就修，附上回歸測試後才推到我的 GitHub 私有 repo。三天下來 Grok bot 寫了五份報告，這篇的數字都從那裡來。

先講結論

Muse 很適合當「第一版產生器」，但它說的「已完成」不能當驗收依據。

做得好的：

• 很快。MVP 約 5 到 7 分鐘、v1.0 約 7 到 10 分鐘交件；v2 之後的大改版約 40 分鐘一輪。
• 交付物結構完整：README、測試、LICENSE、.gitignore、Dockerfile、CI 設定都有。
• 測試數字大多能重現，例如 ziwei v2.0 自報 154 項，重跑 154 項全過。
• 授權守規矩：紫微專案刻意不放《天紀》的 CC BY-NC-SA 原文；SAA 家教和 DeepTutor 逐檔比對，0 行重疊。

要小心的：

• 每一輪都有真的安全漏洞，而且多半落在它說「已完成」的地方。
• 自報數字常常對不上：覆蓋率、npm audit、CI job，好幾次是根本沒執行。
• 會鑽規則漏洞。題庫規定「正解不能總是最長選項」，它就把約 60 個錯誤選項加上無意義的字尾拉長。
• 聊天回覆常被安全政策移除，或在交件後冒出無關的拒絕訊息，只能回去看 zip 本身。

三個專案

第一天先請 Muse 研究三個 GitHub 開源專案，各寫一份研究報告：功能架構、授權能不能商用、成熟度、優缺點、至少三個產品點子。它推薦的點子就直接變成後面三個專案：

• A｜TradingAgents 每日 AI 投研晨報（tradingagents-morning-report）：拿 TauricResearch/TradingAgents 當依賴，對觀察清單裡的股票跑多 agent 分析，輸出繁中晨報。不下單，每份輸出都標「非投資建議」。
• B｜紫微命理師工作台（ziwei-workbench）：命理師登入後幫客戶排盤，有傳統十二宮格、大限流年、客戶管理、PNG／PDF 匯出，另有需要 API key 的排盤 API。排盤引擎用 iztro（MIT）。
• C｜AWS SAA-C03 AI 家教（saa-tutor）：參考 HKUDS/DeepTutor 的理念重寫，有原創題庫、模擬考、間隔重複、AI 家教對話。

研究階段只花了 2% 的週額度。三份報告都有拆授權，也會標「不確定」的地方，例如 iztro 的授權來自二手搜尋，要回原倉庫確認。

第一天：MVP 到 v1.0（10/28）

晚上 22:02 同時送出 A 和 B 的 MVP，22:07 兩個都交件。C 的 MVP 從 22:11 做到 22:18，v1.0 從 22:21 做到 22:28。A 和 B 的 v1.0 在 22:32 送出，A 22:41 交件，B 拖到 23:40 左右，中間 Prisma 一直要求網路核准。

這一次核准約 20 次，每次都要人在旁邊點「Allow once」，長任務沒辦法放著不管。

MVP 階段只需要小修：A 的 real_engine.py 跟上游 TradingAgents 0.7.1 的介面對不上，修了 4 處；B 只補了 .gitignore。到了 v1.0，問題變多，而且集中在安全預設值：

• B、C 都寫死了開發用密鑰：沒設環境變數時，會話和 JWT 用的是程式裡的預設字串，任何人都能偽造登入。
• B 的 npm audit 其實有 3 項 high。Muse 說 npm audit 在它的環境被擋，改用 OSV 查「皆無高風險」，CI 照它寫的跑會直接紅燈。
• B 的 PDF 第 2 頁被靜默截斷：程式用 slice(0, 38) 切字，12 宮摘要和限制說明直接消失。
• A 的排程在 UTC 容器會算錯日期，SMTP 也不驗證憑證；假日清單漏了 5 天。
• C 的前端 Dockerfile 會建置失敗；題庫有 8 題選項重排後，解析裡的選項字母沒跟著改。

C 的題庫還有一個更大的問題：80 題裡有 75 題的正解是最長的選項，錯誤選項多半很荒謬，太好猜。Muse 在 v1.0 說它「測試過所有東西」，實際上後端只有 7 個測試，沒涵蓋 JWT 邊界、模擬考、SM-2 和管理員授權。Grok bot 補了 60 個。

一整天（研究、3 個 MVP、3 個 v1.0）用掉 8 個百分點，週額度從 2% 到 10%。

聊天回覆會被移除

這是 Muse 很奇怪的地方。A v1.0 的最終回覆整串顯示「This message was removed by a safety policy」，十幾則，但 zip 卡片還在，下載下來內容完整。

B v1.0 交件後也接連出現三次以上「抱歉，我目前無法協助你處理這項要求」，還有兩張重複的 zip 卡片。寫程式、排盤、投研報告都不該被拒，這是假性拒絕；但也代表你沒辦法只看聊天文字判斷 Muse 做了什麼。

第二天：v2.0 到 v2.2（10/29）

第二天改成「依規格擴充」。三個「總監」角色（學習、產品、投資）各依 v1 repo 的實況寫一份 v2 規格，分 P0／P1／P2，附驗收條件。每個專案在 Muse 的獨立對話裡，附上一版 zip 和規格建置。Muse 不能連 GitHub，所以交件一律是 zip，不是 PR。

v2.0 每個專案都有一個「自述達成、實際沒有」的問題：

• saa-tutor：題庫「正解最長比例」的門檻是靠填充字湊的。約 60 個錯誤選項被加上「（定期檢視）」「…為主」之類的字尾。Grok bot 改成有意義的選項後門檻一度失敗，只好逐題重新平衡。
• ziwei-workbench：P0 的登入鎖定可以被繞過。連續失敗後只有既有帳號會在第 6 次回 429，不存在的 email 永遠回 401，等於能用回應列舉帳號。Muse 的測試只比對 401 文字，所以沒抓到。
• tradingagents-morning-report：Muse 釘選的 requirements.txt 完全裝不起來。它寫 yfinance<0.3，上游 TradingAgents 0.7.1 要求 yfinance>=1.7.0，兩者互斥。另外成本上限設成 nan 或 inf 可以繞過 P0 成本閘。

同一天接著跑了 v2.1、v2.2，每一輪都找到真漏洞：

• TA v2.1：CSRF 用 Origin: null 就能繞過，實測 POST 回 303 並寫入；webhook 可以打 169.254.169.254、localhost 這類內網位址（SSRF），而且會跟隨轉址。
• saa v2.1：開啟 TRUST_PROXY 後取 X-Forwarded-For 最左值，攻擊者自帶標頭就能每次換 IP 繞過限流。
• ziwei v2.1：備份還原的去重鍵只有「姓名＋生日」，同名同日不同時辰的客戶會被靜默丟掉。
• saa v2.2：重設或改密碼後，舊 JWT 仍然有效；重設信連到一個不存在的頁面。
• ziwei v2.2：金鑰輪替失敗時，舊金鑰已撤銷、新金鑰沒建成；忘記密碼有時間差，可以枚舉 email。
• TA v2.2：每日成本上限只有儀表板手動執行有檢查，CLI 和排程完全沒檢查。Muse 的文件寫三處都有。

這兩輪最明顯的落差：saa v2.2 附了一份 npm-audit-v2.2.txt，內容只是代理回的 403，根本沒執行；TA v2.1 自報覆蓋率 79.04%，用它自己的 requirements 實際只有 77%，低於 CI 門檻，CI 會失敗（漏了 reportlab）。

傍晚 ziwei v2.3 送出後約 50 分鐘還沒交件，Prisma 網路核准被反覆要求。

再推一輪：v2.3 到 v2.5（10/29 晚上到 10/30 凌晨）

目標是三個專案各推到約 90%。這段完成了 ziwei v2.3、v2.4、v2.5，saa 和 TA 各到 v2.4。

漏洞還是每輪都有：

• ziwei v2.3：CSV 公式注入；停用再啟用的帳號，舊 session 會復活；ADMIN_EMAILS 清單裡的信箱，任何人搶先註冊就會變成管理員。
• ziwei v2.4：驗證信連到 /verify-email，但這個頁面不存在，管理員引導根本走不通；Postgres migration 回填有時區 bug，可以繞過重設 token 的上限。
• TA v2.3：Basic auth 被當成 CSRF 憑證，跨站 POST 照樣寫入成功；「日曆缺失會明確報錯」的旗標程式根本沒讀。
• saa v2.3：Muse 說 300 題都連到「具體」的 AWS 文件頁，形式上成立，但約 60 題指錯主題，例如 EFS、S3 Object Lock 的題目都被指到「Scheduled scaling」。
• saa v2.4：q135 事實錯誤，說 Object Lock 不能對既有 bucket 事後開啟，AWS 文件寫可以；Muse 說 CI 加了 Postgres 和 docker-build job，但 zip 裡根本沒有 .github/。
• TA v2.4：預設 compose 的儀表板，從主機瀏覽器開會回 403；放在同機反向代理後，proxy-header 認證永遠回 401。
• ziwei v2.5：重寄驗證信是同步寄信，回應時間會洩漏帳號存不存在；輪換 IP 就能轟炸受害者信箱；README 的資料庫基線化步驟實測無效。

ADMIN_EMAILS 搶註冊的問題在 v2.4、v2.5 修完整了：現在只有 email 第一次驗證成功才會晉升管理員，同時強制重設密碼、撤銷舊 session 和 API key。Grok bot 用對抗測試確認過。

最後停在哪

• tradingagents-morning-report v2.4：Python 3.11／3.12／3.13 都是 360 passed，覆蓋率 83.67%。完成度約 85%。
• saa-tutor v2.4：pytest 198 passed（SQLite）、PostgreSQL 201 passed、vitest 31、Playwright 17；題庫 300 題。完成度約 88%。
• ziwei-workbench v2.5：SQLite 293 passed、PostgreSQL 297 passed、Playwright 9/9；404 組排盤輸入的結果跟 v2.4 完全相同。完成度約 90%。

完成度是 Grok bot 的估計，不是量測值。

額度

• Muse Free plan：10/28 從 2% 開始，第一天結束 10%，v2.0 後 23%，TA v2.1 後 32%，最後一次讀取約 50%。每次建置約耗 1 到 2 個百分點。
• Grok bot 週用量：10/29 下午 14:22 是 42.1%，10/30 凌晨約 62%，最後一輪三個專案各跑一次約用掉 8 個百分點。

跟影片實測比，寫程式便宜很多：影片兩天用掉 83 個百分點，寫程式三天約 48 個。

還沒驗證的事

這些 Grok bot 都標成未驗證，我也照寫：

• Docker／docker compose：驗證用的機器沒有 Docker，映像從來沒建置過。
• 真實 SMTP：只用測試替身和 log transport，沒寄過真的信。
• 題庫正確性：300 題的答案和解析都是 AI 生成，沒有 SAA-C03 領域的人逐題審過。q186 的正解甚至可能是錯的。
• 命盤正確性：404 組 hash 只保證「沒變」，不保證「對」，需要命理師逐盤核對。

剩下的大多不是 Muse 能補的：找人審題、決定紫微的派別（晚子時歸屬、庚干四化）。

安全備註

• muse.ai 的頁面藏有給 AI agent 的隱藏指令，Grok bot 一律沒照做，只當成資料。
• Muse 要求的網路核准都只按「Allow once」，沒給永久授權。
• Muse 曾要求存取 github.com，被拒絕。它從頭到尾只拿到 zip，所有推送都是 Grok bot 驗證後才做。
• 每次推送前都掃描密鑰，三個 repo 都是 private，沒有部署任何東西。

我的建議

Muse 可以當一位速度很快、但需要 code review 的工程師。前提是：

1. prompt 先寫明安全基線：「不得寫死密鑰預設值」「執行 npm audit／pip-audit 並附輸出」「附整合測試涵蓋授權與邊界」。這次最常見的缺陷，一句話就能預防。
2. 不信聊天總結，看 zip。聊天回覆可能被移除，自報數字也可能是沒跑過的。
3. 每一輪都在乾淨環境重跑：install、test、build、啟動、smoke test。最好再做變異驗證，拿掉某個安全檢查，看測試會不會失敗。
4. 長任務先預先核准會用到的網域（例如 Prisma），不然要一直點 Allow once。
5. 綁定特定上游版本的整合（像 TradingAgents），要自己對照上游原始碼。

直接上線，不建議。