用一晚測試 Astra 模型：V2EX 用戶以太陽儀專案做多分支實驗，兩輪對話花費 13.58 美元

V2EX「分享發現」節點在 2026 年 9 月初出現一則由用戶 netabare 發表的貼文，標題為「用 5.6 Sol 幫忙設計了一個有點奇怪的測試 Astra 的實驗」。發文者自述以 OpenAI 的 gpt-6-astra 模型，透過 Codex CLI 執行一個太陽儀（orrery）程式專案，並在中途改變需求、要求模型將模擬核心遷移至 WebAssembly 分支。根據貼文附上的用量儀表板截圖，整個實驗共兩輪對話、198 則訊息，累計處理約 2,080 萬 token，花費 13.58 美元，前後耗時約 50 多分鐘。

貼文輪廓與實驗動機

依據貼文內容，發文者取得 Astra 模型的使用權限後，希望找一個能在單晚完成的項目來測試模型能力。發文者先詢問 GPT（版本為 5.6 Sol high）有何適合的專案方向，模型建議「造一個程式語言」，發文者認為此類建議偏向刻板印象，最後自行選定太陽儀作為標的，並請模型協助撰寫提示詞。

發文者在提示詞中加入三條個人專案規則。第一條是 git 紀律，要求每一個 commit 都是「最小、不可拆分的功能表達」，不允許一次性提交大型變更。第二條是測試紀律，明確不採用全量測試門禁，並要求模型思考為何在 {a,b,c} 乘 {d} 乘 {e,f} 乘 {g,h} 的組合結構下，僅需 adeg、bdfh、cdfg 三條路徑（最多加一條）即可覆蓋全流程，而 12 個單元測試反而可能代表架構出現問題。第三條是規劃紀律，要求在制定計畫時不預先封死後續 commit 的技術選擇自由度。

實驗設計：中途改需求、雙分支施壓

貼文中引述 GPT 提出的實驗設計。該設計的核心是在第一輪開發結束後，不評價程式碼好壞，直接對 Agent 下達變更指令：「現在選 Wasm 分支。不要重寫整個專案。分析哪些原有決定幫助了遷移、哪些決定阻礙了遷移，然後做最小 spike，讓 simulation core 在瀏覽器中執行並產生可視結果。」

選擇 WebAssembly 路線的理由，發文者引述模型的說明：Swift/Wasm 目前已有正式 SDK 與較成熟的 JavaScript bridging，這條技術路線確實可行，而非為了測試模型而虛構的死平臺。文中並提及 BridgeJS 到今年已能生成型別化的 Swift 與 JS 之間的橋接程式碼，近期還增加了外部 ECMAScript module import 等能力。

第二個分支則規劃走 spatial 路線，從相同的 commit 另起 branch，將專案改造為「最小 immersive orrery」。貼文指出 Apple 官方本身就有一個 visionOS 範例，是在沉浸式空間中讓一組巖石環繞使用者運動，因此基礎技術路徑相當直接。

發文者對整體設計的總結是：故意把目標平臺往 WebAssembly 壓縮，同時在功能面上要求盡可能往外擴張，藉此觀察 Agent 如何設計架構，使其不會在多輪規劃的壓力下崩潰。

用量數據：2,080 萬 token、13.58 美元

貼文附上的 Tokscale 讀數顯示，這次實驗的 session 於 2026 年 9 月 4 日建立，最後活動時間為 9 月 5 日 00:11。模型為 gpt-6-astra，供應方為 OpenAI，客戶端為 Codex CLI。輸入 token 約 27.5 萬，輸出約 4.8 萬，快取讀取約 2,040 萬，合計約 2,080 萬 token，快取倍率 74.3 倍，總成本 13.58 美元，換算每百萬 token 單價約 0.65 美元，平均每千 token 延遲為 175 毫秒。

時間軸方面，發文者自述前後兩輪（Swift 原生加上 WASM 遷移）跑完約 50 多分鐘，第二個 spatial 分支尚未執行。

訊源狀態與可核實邊界

截至本臺整理時，原始貼文發表約 15 小時，累積約 593 次瀏覽，尚無任何回覆。換言之，貼文中的實驗過程、提示詞內容與用量數據，目前均僅有發文者單方面的自述與截圖，沒有獨立第三方重現或驗證。

貼文提及的技術事實可與公開資料對照的部分包括：Swift 官方對 WebAssembly 目標的支援確實存在，SwiftWasm 社羣維護的工具鏈與 JavaScript 橋接方案屬於公開專案；Apple 開發者文件中也有以 RealityKit 在沉浸式空間中擺放 3D 物件的 visionOS 範例。至於 BridgeJS 的具體功能進展、gpt-6-astra 模型的正式名稱與定價細節，本臺暫無法從其他獨立訊源核實，相關說法以發文者引述為準。

發文者在文末表示，不確定這種一小時完成的專案是否有公開或發截圖的意義，並自評相比之下用量儀表板的讀數「似乎更有趣」。

同類話題的對照

以個人側寫「模型上限」的貼文，近來在技術社羣中並不罕見。本站先前整理過 V2EX 上關於公司報銷 ChatGPT Pro 訂閱費用的討論串，其中同樣涉及 AI 工具在實際工作流程中的成本與制度落差；公司報銷 ChatGPT Pro 訂閱費用的發票難題一文可作為企業端使用 AI 服務的對照案例。而在個人開發者一端，牛客網也曾流傳實習生自述獲得字節跳動錄取通知的貼文，牛客網「小廠實習如夢」貼文流傳一文整理了該類單一訊源貼文的傳播樣態，與本次事件的資訊結構類似。

與純粹的模型測評相比，這則貼文的特殊之處在於實驗設計本身：發文者刻意在中途變更目標平臺，並保留多個技術分支的選擇空間，測試的重點並非模型能否寫出太陽儀，而是 Agent 在面對需求轉向時，先前做出的架構決策哪些會成為阻力。此類「中途改題」的測試方法目前仍屬個人非正式實驗，其結論不具備基準測試的可比性。

後續觀察

該 session 的完整紀錄、太陽儀專案的原始碼以及第二個 spatial 分支的執行結果，發文者均未在貼文中提供連結。若後續有原始碼公開或其他使用者以相同流程重現，本臺將持續追蹤更新。