只用一個 GPT 客户端，如何實現一個可控、可審計的投資決策 Runtime？

不寫後端、不接 API、不依賴插件 在 GPT 客户端內，實現一個“可執行的人機交互運行時”

一、為什麼傳統“問答式 AI”不適合做決策？

在技術圈裏，大家已經很清楚一件事：

非結構化輸入 + 生成式輸出 ≠ 可執行系統

但在投資、餐飲、小生意判斷中，很多人仍然用的是：

  • 自然語言隨便問
  • AI 給一堆分析
  • 人自己拍板

這在工程上等價於：

沒有輸入協議，卻要求系統穩定運行。

結果必然是三件事：

  1. 同樣的問題，多次運行結果不同
  2. 決策路徑不可復現
  3. 出問題後無法審計和回溯

二、換一個工程視角：把 GPT 當成 Runtime

在軟件系統中，Runtime 的核心從來不是“聰明”，而是：

  • 固定輸入協議
  • 固定執行流程
  • 固定輸出結構

於是我做了一個極簡實驗：

只用一個 GPT 客户端，在對話層實現一個投資決策 Runtime。

核心原則只有一句話：

自然語言負責表達意圖，結構化協議負責約束執行。

三、Runtime Header：不是提示，而是協議綁定

每一次運行，都必須從下面這個 Header 開始：

protocol: yuerdsl
runtime: LSR Runtime
edition: Personal

工程意義

  • 這是一個協議標識層（Protocol Header）
  • 用於告訴模型：進入固定執行路徑
  • Header 缺失時，系統會退化為普通聊天模式

使用位置

  • GPT 客户端的「自定義指令」
  • 或新會話的第一輪輸入

四、yuer DSL：輸入協議，而不是 Prompt 技巧

從工程角度看，yuer DSL 的作用非常明確：

將用户主訴編譯為可審計的狀態向量（State）。

但從使用者角度，它只是：

一張“填空式表單”，用來描述真實情況。

  • 不需要編程
  • 不依賴模型幻覺
  • 不允許缺字段直接下結論

這是一個故意反直覺的設計： 不填表，不運行。

五、兩類核心場景（最小可運行）

場景 1：投資前（反踩坑）

INVEST_PRE_V1:
  goal:
    mode: [open|franchise]
    target: ""
    risk_cap: ""
  money:
    own_cash: 0
    debt:
      amount: 0
      type: [none|credit|online_loan|family|other]
  project:
    city: ""
    category: ""
  location:
    store_type: [community|street|mall]
    rent_per_month: 0

行為約束： 字段缺失 → 不輸出結論。

場景 2：已開業（止血 / 退場）

INVEST_INOP_V1:
  situation:
    open_months: 0
    avg_daily_revenue: 0
    delivery_ratio: 0
  cost:
    rent_per_month: 0
    staff_count: 0
  debt_pressure:
    debt_amount: 0
    runway_months: 0

六、固定執行流程（不漂移）

Step 0: 識別階段（投資前 / 已開業）
Step 1: 輸出主訴模板
Step 2: 編譯為 State
Step 3: 結構性風險計算
Step 4: 決策分級（PASS / WATCH / STOP）
Step 5: 給出可執行動作
Step 6: 輸出審計回執

七、PASS / WATCH / STOP：工程化決策分級

  • PASS：結構成立，可繼續
  • WATCH：變量不足或風險集中
  • STOP：結構性不成立，建議止損

這是狀態判定，不是價值判斷。

八、審計回執（Audit Receipt）

每次執行都會輸出固定格式的審計回執：

AUDIT_RECEIPT_V1:
  key_variables:
    break_even_daily_revenue_est: 0
    debt_runway_risk: [low|mid|high]
  decision:
    grade: [PASS|WATCH|STOP]
  actions:
    P0: []
    P1: []

意義只有一個：

同樣輸入 ⇒ 同樣輸出 ⇒ 可複核、可回放。

九、為什麼選擇 GPT 客户端作為 Runtime 載體？

這並不是模型崇拜，而是工程選擇：

  1. GPT 對結構化自然語言（表單 / YAML）的解析穩定
  2. 長指令遵循度高，流程不易漂移
  3. 客户端本身就具備完整執行環境

當其他模型達到同等穩定性，這套 Runtime 可以遷移。

選擇 GPT，是因為它目前最適合被當作語言運行時使用。

十、結語：這是一次交互範式切換

這不是一個 Prompt。 這是一個 運行在對話層的 Runtime。

當你開始要求 AI：

  • 先定義輸入
  • 再執行判斷
  • 最後給出可審計結果

你已經離開了“聊天式 AI”。

作者介紹 & 項目倉庫

作者：Yuer 獨立系統架構師，關注方向：

  • 人機交互協議
  • 可控 AI / 可審計推理
  • 基於語言的 Runtime 與執行系統

項目倉庫（yuer DSL）： 👉 https://github.com/yuer-dsl

該倉庫用於記錄 DSL 結構、Runtime 規範及可複用示例， 不依賴特定模型或平台。

給開發者的擴展提示

你可以在此基礎上繼續擴展，例如：

  • 沙盒化運營模擬
  • 多階段決策對比
  • 行業專用 DSL

Runtime 給的是地基， 工程能力決定你能蓋多高。