跳到主要內容
聯絡我們

你的 AI 已經會跑了。缺的是收錢、限額、對帳、和不被打穿。

以下 18 張規格卡，挑你需要的組。每張都標了成熟度與實作證據。

這一層本身不呼叫任何模型。模型在你的 workflow 裡，我們負責它外面那一圈。

跳到規格卡先看三種常見組合

GROUP A ／ 計費與金流

GROUP A 依賴 →—

把「跑一次」變成「扣一次點」，把點數變成收得到的錢。

A1點數計費引擎

完成待驗

使用者買點數，執行一次扣一次，免費點與付費點分開計算

INPUT輸入
儲值方案設定、使用者帳號、每次執行的計費規則
OUTPUT輸出
點數餘額、逐筆交易流水、扣款結果
DEPENDS ON相依
資料庫（PostgreSQL）；不相依任何金流商
MATURITY成熟度
完成待驗
EVIDENCE實作證據
資料庫 schema · 儲值方案設定模組 · 點數 API 路由

A2餘額稽核端點

完成待驗

用交易流水重算餘額，對不上就抓得出來

INPUT輸入
使用者帳號、時間區間
OUTPUT輸出
帳面餘額 vs 流水重算餘額的差異報告
DEPENDS ON相依
卡 A1
MATURITY成熟度
完成待驗
EVIDENCE實作證據
後台稽核 API 路由

A3台灣金流串接：綠界

完成待驗

檢查碼產生與驗證、測試／正式環境切換、callback 與 return 雙端點

INPUT輸入
訂單資料、金額、商店代號與金鑰
OUTPUT輸出
導向付款頁的參數、付款結果回呼的驗證後資料
DEPENDS ON相依
綠界商店帳號
MATURITY成熟度
完成待驗（未上線）
EVIDENCE實作證據
檢查碼工具模組 · 回呼 API 路由 · 付款結果 API 路由

A4台灣金流串接：藍新

生產級

自行實作的 MPG 加解密與簽章，低階為純函式，可用官方手冊的黃金向量逐位元組驗證

INPUT輸入
訂單資料、商店金鑰組
OUTPUT輸出
加密後的交易參數、驗證通過的回呼資料
DEPENDS ON相依
藍新商店帳號
MATURITY成熟度
生產級（已在真實生產環境運行）
EVIDENCE實作證據
加解密純函式模組 · 單元測試 · 閘道封裝 · 架構決策文件

A5付款到扇出的交易安全

完成待驗

用條件式更新做競態安全的狀態轉移，付款只會被處理一次

INPUT輸入
付款成功回呼、訂單編號
OUTPUT輸出
訂單狀態轉移結果 + 稽核紀錄；後續扇出動作在交易之外執行
DEPENDS ON相依
PostgreSQL 交易；卡 A1 或既有訂單表
MATURITY成熟度
完成待驗
EVIDENCE實作證據
付款觸發服務 · 付款扇出服務

這一組沒有發票卡，也沒有退款卡——因為沒有實作。往下的「這一頁沒有的東西」把缺口一次列完。

GROUP B ／ 分潤與提領

GROUP B 依賴 →A1

雙邊平台真正的難處不是收錢，是把錢正確地分出去、而且對得起帳。

B1開發者收益歸戶

完成待驗

每一次執行產生的收益歸到對應的開發者名下，可逐筆追溯

INPUT輸入
執行紀錄、抽成比例設定
OUTPUT輸出
開發者收益明細與累計餘額
DEPENDS ON相依
卡 A1
MATURITY成熟度
完成待驗
EVIDENCE實作證據
資料庫 schema

B2提領申請與審核撥款

完成待驗

開發者申請提領，後台審核、撥款、退件，每一步留紀錄

INPUT輸入
提領申請（金額、收款資訊）、審核者操作
OUTPUT輸出
提領單狀態（待審／核准／退件／已撥款）與匯出報表
DEPENDS ON相依
卡 B1
MATURITY成熟度
完成待驗
EVIDENCE實作證據
資料庫 schema · 後台撥款 API 路由 · 前台提領頁

B3非同步報表匯出

完成待驗

大量資料的匯出丟進背景任務，不卡住請求也不逾時

INPUT輸入
匯出條件（區間、對象、欄位）
OUTPUT輸出
任務狀態 + 完成後的 CSV 檔
DEPENDS ON相依
背景任務表；PostgreSQL
MATURITY成熟度
完成待驗
EVIDENCE實作證據
非同步匯出服務 · CSV 匯出函式庫 · 資料庫 schema

B4平台抽成與供應方營收儀表板

完成待驗

供應方看得到自己的營收、平台看得到抽成，兩邊看的是同一份資料

INPUT輸入
交易紀錄、抽成設定、結算週期
OUTPUT輸出
營收統計 API 與儀表板資料、結算結果
DEPENDS ON相依
卡 B1
MATURITY成熟度
完成待驗
EVIDENCE實作證據
營收與統計 API 路由 · 營收服務 · 結算服務

GROUP C ／ 工作流執行

GROUP C 依賴 →A1 · D1

把 workflow 變成可以對外提供的服務：一個介面、一份契約、會停損的排程、看得見的監控。

C1n8n / Dify 統一執行代理

完成待驗

兩種平台走同一支代理，含逾時、重試、多型別檔案上傳與輸出解析

INPUT輸入
workflow 端點、輸入參數、附件檔案
OUTPUT輸出
正規化後的執行結果、錯誤分類、耗時
DEPENDS ON相依
開發者自有的 n8n 或 Dify 服務；卡 D1（SSRF 防護）為必要相依
MATURITY成熟度
完成待驗
EVIDENCE實作證據
執行代理模組 · 背景執行模組

C2無程式碼 API 契約定義器

完成待驗

開發者用表單描述輸入輸出，平台自動生成使用者端的操作介面與測試器

INPUT輸入
欄位定義（型別、必填、檔案大小限制、預設值）
OUTPUT輸出
使用者端操作 UI、API 測試器、契約 schema
DEPENDS ON相依
卡 C1
MATURITY成熟度
完成待驗
EVIDENCE實作證據
輸入設定元件 · 契約定義表單 · API 測試器元件

C3訂閱排程執行器

完成待驗

每小時／每日／每週／每月定時跑，連續失敗 5 次自動暫停

INPUT輸入
排程設定、workflow 與參數
OUTPUT輸出
執行紀錄、失敗計數、暫停狀態
DEPENDS ON相依
卡 C1；卡 A1（每次執行要扣點）
MATURITY成熟度
完成待驗
EVIDENCE實作證據
排程模組 · 排程執行 API 路由

C4執行監控 Console

完成待驗

即時執行 feed、錯誤日誌、效能指標、營收圖表

INPUT輸入
執行紀錄串流
OUTPUT輸出
即時面板資料、統計 API
DEPENDS ON相依
卡 C1；即時訂閱（Realtime）
MATURITY成熟度
完成待驗
EVIDENCE實作證據
監控元件 · 即時訂閱 hook · 統計 API 路由

C5執行事件通知中心

完成待驗

事件匯流排 + 模板 + 寄送 worker，寄送供應商可換

INPUT輸入
系統事件（執行完成、失敗、額度不足、提領狀態變更）
OUTPUT輸出
依模板產生的通知，經 adapter 寄出
DEPENDS ON相依
PostgreSQL；至少一個 email adapter（含 mock 供測試）
MATURITY成熟度
完成待驗
EVIDENCE實作證據
事件匯流排 · 通知服務 · 模板服務 · 寄送服務與 worker · 可替換的 email adapter

C6多租戶容器編排與雙類憑證分離

原型

每個租戶一個獨立 workflow 容器；開發者憑證打包進快照、使用者憑證執行時才注入

INPUT輸入
租戶設定、開發者憑證、使用者憑證
OUTPUT輸出
隔離的執行環境（設計目標）
DEPENDS ON相依
容器平台、Volume 快照、憑證保管庫
MATURITY成熟度
原型
EVIDENCE實作證據
架構設計文件。無實作程式碼——這張卡目前只有設計，沒有東西可以交付

這張卡刻意留在目錄裡，因為多租戶隔離是每個買家都會問的問題，而我們對它的答案是「設計想過了，還沒做」。把它藏起來會讓你在 POC 中期才發現；放在這裡你現在就知道。若你的需求以此為前提，這一項要當作共同開發項目估價，不是既有功能。

GROUP D ／ 安全

GROUP D 依賴 →C1 · C2

只要平台上有一個欄位讓使用者填 URL，你就有一個 SSRF 洞。

D1SSRF 防護

完成待驗

使用者填的 URL 一律解碼、解析、再驗一次，內網與雲端 metadata 端點直接擋掉

INPUT輸入
任意使用者提供的 URL 字串
OUTPUT輸出
通過／拒絕，以及拒絕原因
DEPENDS ON相依
無（純函式，零外部依賴）
MATURITY成熟度
完成待驗
EVIDENCE實作證據
URL 過濾純函式模組

D2上架審核工作流

完成待驗

開發者送審、後台可直接試跑該 workflow，再決定核准或退件

INPUT輸入
待審 workflow 與其契約定義
OUTPUT輸出
審核狀態、試跑結果、退件原因
DEPENDS ON相依
卡 C1、卡 C2
MATURITY成熟度
完成待驗
EVIDENCE實作證據
後台審核 API 路由 · 後台審核頁

D3功能開關與邀請碼守門

完成待驗

功能可以逐項開關，帳號可以用邀請碼控制啟用，封測期不用改程式碼

INPUT輸入
功能開關設定、邀請碼發放紀錄
OUTPUT輸出
前端的功能可用性、帳號啟用狀態
DEPENDS ON相依
無
MATURITY成熟度
完成待驗
EVIDENCE實作證據
功能開關 API 路由 · 邀請碼 API 路由 · 啟用守門元件

這道防護的由來

  1. 起因

    一次自動化安全掃描在這個平台上記錄了一筆 CRITICAL 等級的 SSRF 弱點

  2. 修補

    補上這支過濾器：整數 / 八進位 / 十六進位形式的 IP 編碼一律先解開再驗、DNS 解析之後再驗第二次、雲端 metadata 端點列入阻擋

  3. 現在

    任何讓使用者填 URL 的功能（卡 C1 執行代理是最大宗）都必須經過它

為什麼要把「我們曾經有一個 CRITICAL 弱點」寫在 Landing Page 上？因為這條時間線比任何一句「我們重視資安」都有說服力。這道防護不是抄範本抄來的，是被打過之後補上的。一個從沒被掃出過弱點的團隊，通常只代表沒有人掃過。

你不需要相信我們——這支過濾器擋的是整數 / 八進位 / 十六進位 IP 編碼與 DNS 重綁定這一類只有被實際掃過才會想到要擋的變形。這張清單抄範本抄不出來。

本頁只揭露「發現並修補」這件事本身，不揭露弱點細節，也不指認專案或程式碼位置。

三種常見組合。你多半屬於其中一種。

組合 1｜內部工具平台

情境：各部門都想用 AI，IT 要控管誰能用、用多少。不收錢，但要限額與歸戶。

A1A2
C1C2C3C4C5
D1D3

用到的卡：A1（當作額度而非金錢）· A2 · C1 · C2 · C3 · C4 · C5 · D1 · D3。

不需要：金流（A3／A4）、整個群組 B。

組合 2｜對外可販售的工作流商城

情境：雙邊市場，開發者上架、使用者購買、平台抽成。最完整的一組，也是原始系統本來的形狀。

A1A2A3或A4
B1B2B3B4
C1C2C3C4C5
D1D2D3

用到的卡：群組 A 全部（A3 或 A4 擇一）· 群組 B 全部 · C1–C5 · 群組 D 全部。

要特別談的：C6（多租戶容器編排）在這個組合裡幾乎一定會被問到，而它目前只有設計。是否需要真正的容器級隔離、還是代理層隔離就夠，是這個組合最重要的一次架構決策。

組合 3｜給既有系統加一層計費

情境：產品已經在跑了，只是想加上按次計費與台灣金流。最輕的一組，通常也最快。

A1A2A3或A4A5
C5

用到的卡：A1 · A2 · A3 或 A4 · A5 · C5（付款與額度通知）。

不需要：整個群組 C 的執行層（你已經有自己的執行邏輯）、群組 B。

計數規則（三個組合一致，不可各用各的）：A3 與 A4 是擇一，合計 1 張；C6 未列入任何組合（只有架構文件、沒有實作，這一條也列在「這一頁沒有的東西」裡）。三個組合的卡片數依此規則逐一相加如下。

項目組合 1組合 2組合 3
卡片數9165
算式A1·A2(2) + C1–C5(5) + D1·D3(2) = 9群組 A 擇一後(4) + 群組 B(4) + C1–C5(5) + 群組 D(3) = 16A1·A2·A5(3) + A3 或 A4(1) + C5(1) = 5
需要金流否是是
需要分潤否是否
相依鏈最長長度3（A1 → A2 → C5）42（A1 → A2）
最大未知數無C6 多租戶隔離既有系統的資料模型

這一頁沒有的東西，寫在這裡。

規格卡容易給人「什麼都有」的錯覺，所以這一區把缺口集中列出來。

  1. 1

    發票開立

    群組 A 有點數、交易流水與餘額稽核，但沒有電子發票開立流程。要串發票需另行開發

  2. 2

    退款流程

    同上。目前有交易紀錄，沒有退款的狀態機與金流反向操作

  3. 3

    平台本身沒有 AI

    這一層不呼叫任何模型。若你要的是「幫我做一個會思考的東西」，這一頁不是答案

  4. 4

    不是正在營運中的平台

    這是一套完整的參考實作，可作為客製化的基礎。它沒有在對外營運，我們不會說它有多少使用者

  5. 5

    多租戶容器隔離未實作

    卡 C6。只有架構文件

  6. 6

    第二代重寫只到 UI 原型

    我們自己後來重寫過一版，只做到介面原型、沒有後端。能拿來用的是第一代這套

  7. 7

    綠界未上線

    卡 A3 程式碼完整但未經生產驗證。生產驗證過的金流是卡 A4（藍新）

  8. 8

    沒有效能數字

    沒有壓測報告，因此不提供 TPS、併發數或延遲數字

  9. 9

    沒有成本節省數字

    同上。不寫任何 ROI 或省下多少工時

工程規模（可查證的部分）

401
主要來源專案的檔案數
12
資料庫 migration 支數
約 45
API route 支數
2181
另一套來源系統（金流扇出／分潤／通知）的測試全數通過
34/34
該系統前端頁面全數 build 成功

以上數字出自 repo 內容與各專案 README，非行銷估算。它們描述的是工程規模，不是產品成效——規模大不代表適合你，所以請照上面那三種常見組合挑卡片，不要照數字選供應商。

告訴我們你要哪幾張卡。

不用先講需求全貌。翻上去挑三到五張卡的編號（例如 A1, A4, C1, D1），我們就能開始談範圍與時程。沒有把握挑哪些，就講你的情境，我們幫你對照前面那三種常見組合。

寄卡片編號給我們規格卡總表 PDF 尚未提供。

本頁列出的能力來自 AMAX 自有專案與客戶專案的既有實作。每張卡的成熟度為當前狀態，會隨開發進度更新。