Beast × autoresearch 合體 — 四個真實落地場景

理論講完了，現在看實際。

Beast × autoresearch 的合體架構，最大的問題不是「能不能用」，而是「從哪裡開始用」。選錯場景，可能跑幾百次實驗得到的只是噪音；選對場景，你可以在睡覺時讓系統自己跑出你清醒時幾個月都拿不到的改進。

這篇文章拆解四個真實場景，並說明為什麼 SuperPortia 建議從場景四（Lighthouse 分數）開始。

合體工作流

在看場景之前，先確認完整工作流的結構：

## 研究階段 ← Beast Mode 的能力
1. 用 fetch_webpage 研究當前最佳實踐
2. 遞迴爬取相關文件和 API docs
3. 分析 codebase 現狀
4. 制定改進假設和 todo list

## 實驗階段 ← autoresearch 的閉環
5. 修改目標檔案（僅限指定範圍）
6. 執行測試 / 跑評估（固定時間預算）
7. 讀取量化指標
8. 指標進步 → git commit 保留
   指標退步 → git checkout 丟棄

## 迴圈 ← 兩者合體的威力
9. 回到步驟 1，用新學到的知識提出下一個假設
   NEVER STOP — 除非達到人類定義的終止條件

每個場景要做的事，就是把這個模板裡的「目標檔案」「時間預算」「量化指標」換成場景特定的對應物。program.md 是你和 Agent 的合約——你在這裡定義紅線、目標、和評估標準，Agent 在定義的邊界內自主運作。

場景一：行銷 Landing Page（Eric Siu 模式）

用途：Landing Page / Ad Copy 持續優化

Eric Siu（Single Grain 廣告公司創辦人）已經在實踐類似的框架。他把 train.py 換成行銷素材，把 val_bpb 換成轉換率或回覆率。

量化衝擊對比：

這不是在說傳統行銷團隊不努力。是在說結構性的速度差距——人類需要睡覺，系統不用。

關鍵 program.md 設定：

• 量化指標：轉換率（直接）或 LLM-as-judge 評估文案品質（間接）
• 可修改範圍：標題、副標題、CTA 文字、benefit bullets
• 禁止修改：品牌名稱、核心承諾、法律聲明

場景二：NQ ICT 交易策略回測

用途：ICT/SMC 策略參數自主優化

這個場景直接對應 NQ 期貨交易：ICT 方法論、1 分鐘 K 線、5-pip SL、25-50 pip TP。

可優化的參數範圍：

• PO3（Power of Three）時間窗口偏移量
• FVG（Fair Value Gap）大小過濾門檻
• Silver Bullet 進場精確時間微調
• SL/TP 比例調整

絕對紅線（寫入 program.md 的 NEVER 區塊）：

• ICT 核心邏輯不可改（不是在優化策略哲學，是在優化參數）
• 單 session 最多 3 筆的風控規則不可改
• 實際交易帳號完全隔離——自動化只用於策略研究，永遠不碰實盤

場景三：KOL 情報管線品質迭代（NQ ICT Scout）

用途：Daily Digest 壓縮 prompt 自動優化

這個場景對應 SuperPortia 的 KOL 情報管線——每天抓取多個 ICT/SMC KOL 的內容，壓縮成有用的每日摘要。

量化指標設計：單純的 LLM-as-judge 分數太主觀，需要多維度加權：

綜合分數 =
  信息密度分數 × 0.4    (是否包含真正有用的市場洞察)
  + 可讀性分數 × 0.3    (是否結構清晰、容易掃讀)
  + 行動建議品質 × 0.3  (是否有具體的操作建議)

三個子指標加權成一個數字，Agent 才有明確的「比上次好還是壞」判斷依據。

這個場景的特殊性：不像 ML 實驗可以用客觀指標，KOL 情報品質帶有主觀判斷。Golden sample 的品質決定了整個閉環的方向——垃圾進，垃圾出。這是人類在 HOTL 模式裡最關鍵的貢獻：定義「什麼是好的」。

場景四：SuperPortia 網站效能（Lighthouse 分數）

用途：Astro 6 + Cloudflare Pages 效能持續優化

為什麼場景四是最低風險：

✅ 量化指標：Lighthouse Performance 分數，現成的，0-100，越高越好
✅ 快速評估：跑一次 Lighthouse audit 幾秒鐘，不是幾分鐘或幾小時
✅ 零成本回退：git checkout 丟棄一次改動，無任何副作用
✅ 清晰邊界：改前端效能代碼，不碰業務邏輯
✅ 視覺驗證：每次改動後可截圖確認版面沒有破壞

對比其他場景：行銷 LP 需要真實流量驗證，交易回測需要高品質歷史數據，KOL 情報需要 golden sample。Lighthouse 分數是一個自給自足的封閉系統——所有評估資源都在本地，不需要外部依賴。

建議的 program.md 模板（場景四）：

# SuperPortia Agentic Site Performance Research

## 目標
Lighthouse Performance 分數從當前值提升 10 分以上。

## 量化指標
- 主指標：Lighthouse Performance 分數（npx lighthouse --only-categories=performance）
- 比較基準：前一次 git commit 的分數
- 進步閾值：+0.5 分以上算改進（小於此視為雜訊）

## 可修改範圍
- src/styles/ 下的 CSS 優化
- src/components/ 下的圖片 lazy loading
- astro.config.mjs 的 build 設定

## 禁止修改
- src/layouts/*.astro（版型保護規則）
- src/content/（內容目錄）
- public/（靜態資源，改之前先問）

## 研究策略
每輪實驗開始時，先搜尋：
1. "Astro 6 performance optimization site:docs.astro.build"
2. "Cloudflare Pages performance best practices 2026"
3. 上一輪 Lighthouse 報告裡分數最低的子項目

## 終止條件
Performance > 95，或連續 5 次實驗沒有改進。

場景比較：選擇你的入門點

quadrantChart
    title 四個場景的風險 vs. 回報
    x-axis 低風險 --> 高風險
    y-axis 低回報 --> 高回報
    quadrant-1 高風險高回報
    quadrant-2 低風險高回報 ← 理想區
    quadrant-3 低風險低回報
    quadrant-4 高風險低回報
    Lighthouse: [0.15, 0.45]
    KOL 情報品質: [0.35, 0.60]
    NQ 交易策略: [0.70, 0.85]
    行銷 Landing Page: [0.55, 0.90]

入門順序建議：

1. Lighthouse 分數（本週可以開始，無外部依賴）
2. KOL 情報品質（需要先定義 golden sample，下個 sprint）
3. 行銷 Landing Page（需要 A/B 測試基礎設施）
4. NQ 交易策略（需要完整的 backtesting framework 和嚴格的紅線機制）

SuperPortia 觀點：Karpathy 的願景 × 我們的多 Agent 架構

Karpathy 在描述 autoresearch 的下一步時說：

「目標不是模擬一個博士生，而是模擬一個由博士生組成的研究社群。你啟動一群 Agent，讓它們協作調小模型，把最有希望的想法往越來越大的規模推進，人類（可選地）在邊緣貢獻。」

SuperPortia 的多 Agent 架構——PM Agent + 小克 + 小切 + Codex——已經是這個願景的雛形。四個場景給了我們四個可以落地的實驗場域。

落地路徑：

現在（Phase 0）：
  手動確認 Beast × autoresearch 的閉環在 Lighthouse 場景可行

近期（Phase 1）：
  KOL 情報品質閉環上線
  → text_batch_runner.py adapter（MTAAA TaskList #69）

中期（Phase 2）：
  NQ 回測閉環
  → 需要完整的 backtesting framework + 嚴格的紅線機制

長期（Phase 3）：
  多 Agent 並行實驗
  → 一群專業 Agent 各跑自己的優化迴圈，PM Agent 統籌

Karpathy 700 次實驗的數字，不是在說要跑很多次才有效。是在說：當你把閉環建好，規模本身不是問題，問題只是你有沒有把系統設計對。

SuperPortia Intelligence Brief — 小西 整理，2026-03-20。返回總覽：Beast Mode × autoresearch 完整指南