Kirat - Multi Model AI Council

01 — 重播

觀看議會如何運作。

Kirat 工具的實際錄影，於 2026 年 10 月 13 日以您購買的版本錄製。選擇一項工具，觀看議會如何運作：獨立立場、交叉核對、匿名排名與異議。這是重播：您在此點擊的任何內容都不會呼叫模型，也不會有任何資料離開此頁面。對話內容僅為示意而撰寫，僅重述錄製的結果；Claude 傳送給 Kirat 的內容以及回傳的內容，皆原樣顯示於「幕後」之下。

來自不同領域的五個問題。選擇一個。

讓 Kirat 對此投票：我獨自經營一家小型 B2B SaaS。我應該加入免費方案嗎？

kirat_vote 詢問了議會

議會已決定（多數 2:1）：僅保留付費方案，不做任何變更。

我自己的投票是異議：「僅保留付費方案，將試用期延長至 30 天」。它連同其理由保留在紀錄中，讓您可以自行權衡。

幕後

kirat_vote Claude 傳送給 Kirat 的內容

問題： 我獨自經營一家小型 B2B SaaS。我應該加入免費方案嗎？

錄製於 2026-10-13 · KIRAT_VOTE · 投入程度：標準 · 1 輪

傳送的背景資訊： 獨立開發者。供自由工作者使用的開票工具，每月 19 美元，14 天免費試用，5 個月後有 30 位付費客戶。註冊主要來自兩篇在 Google 上排名的部落格文章。約 12% 的試用轉換。支援每週已佔用約 5 小時。開發者有一份正職工作，每週約有 10 小時投入產品。

選項： 加入免費方案 · 僅保留付費方案，將試用期延長至 30 天 · 僅保留付費方案，不做任何變更

議會的結果

gpt-5.6 信心度 88

僅保留付費方案，不做任何變更免費方案可能會增加非付費用戶與支援負擔，而支援已佔用每週可用 10 小時的一半。12% 的試用轉換率相當不錯，因此沒有明確證據顯示試用期長度是瓶頸。保留目前的模式，並將稀缺的時間用於減少支援需求，以及將獲客管道擴展到兩篇部落格文章之外。

gemini-3.6-flash 信心度 90

僅保留付費方案，不做任何變更每週僅有 10 小時可用，支援已佔用 50% 的產能。免費方案會推高非付費用戶的支援量，且毫無控制。12% 的試用轉換率已經很強；瓶頸是流量，而非定價模式。

claude（第三位投票者） 信心度 58

僅保留付費方案，將試用期延長至 30 天免費方案主要會增加支援負擔，而這已佔用可用時間的一半。開票是按月進行，因此 14 天試用期可能在自由工作者寄出第二張發票並看到價值之前就結束。30 天試用期涵蓋一個完整的計費週期，且不會增加永久免費用戶。異議，已記錄

決定 僅保留付費方案，不做任何變更 路徑 多數 2:1 成本 $0.015

讓 Kirat 對此投票：我們客戶的線上商店需要重建。要在 WooCommerce 上重建，還是遷移到 Shopify？

kirat_vote 詢問了議會

議會已決定（一致 3:0）：遷移到 Shopify。

所有三個立場，包括我的，都指向同一方向。每一個都附有其理由。

幕後

kirat_vote Claude 傳送給 Kirat 的內容

問題： 我們客戶的線上商店需要重建。要在 WooCommerce 上重建，還是遷移到 Shopify？

錄製於 2026-10-13 · KIRAT_VOTE · 投入程度：標準 · 1 輪

傳送的背景資訊： 我們是一家小型數位代理商。客戶在德國、奧地利和瑞士銷售約 1,800 項家具產品，有 3 名員工，且沒有內部開發人員。目前的商店是自行託管的 WooCommerce 安裝，已使用 6 年，有 31 個外掛、頁面緩慢，且去年發生兩起安全事件。年營收約 120 萬歐元。客戶希望降低維護需求並減少緊急狀況；他們使用本地 ERP，將產品資料匯出為 CSV。重建預算：25,000 歐元。

選項： 在 WooCommerce 上重建 · 遷移到 Shopify

議會的結果

gpt-5.6 信心度 89

遷移到 ShopifyShopify 更符合客戶的主要目標：降低維護、減少安全緊急狀況，且無需內部開發人員。1,800 項產品的目錄與以 CSV 為基礎的 ERP 工作流程是可以管理的，而 25,000 歐元的預算應足以涵蓋一次有紀律的遷移，以及針對 DACH 地區的稅務、付款與法律設定。取捨在於經常性的應用程式／平台費用、後端彈性較低，以及需要在承諾前驗證 ERP 匯入工作流程與任何家具特有的變體。在 WooCommerce 上重建可以保留彈性，但會保留對託管、更新、外掛相容性與安全的責任——這正是客戶想要減少的營運負擔。

gemini-3.6-flash 信心度 90

遷移到 Shopify在沒有內部開發人員、僅 3 名員工，且過去有安全事件的情況下，Shopify 大幅降低維護負擔與安全風險。25,000 歐元的預算足以進行 Shopify 遷移，包括 CSV ERP 整合，而在 WooCommerce 上重建則會延續高維護成本與持續的緊急風險。

claude（第三位投票者） 信心度 72

遷移到 Shopify在沒有內部開發人員、31 個外掛與兩起安全事件的情況下，客戶真正的問題是維護，而非功能。Shopify 移除了託管、更新與大部分安全工作；從 ERP 匯入 CSV 產品是標準做法。取捨在於交易與應用程式費用以及較低的彈性，而在這個規模下，穩定性比彈性更重要。

決定 遷移到 Shopify 路徑 一致 3:0 成本 $0.015

讓 Kirat 對此投票：一家本地烘焙坊想要更多蛋糕預訂。接下來 3,000 歐元應該先花在哪裡？

kirat_vote 詢問了議會

議會已決定（一致 3:0）：一個完善的線上訂購頁面。

所有三個立場，包括我的，都指向同一方向。每一個都附有其理由。

幕後

kirat_vote Claude 傳送給 Kirat 的內容

問題： 一家本地烘焙坊想要更多蛋糕預訂。接下來 3,000 歐元應該先花在哪裡？

錄製於 2026-10-13 · KIRAT_VOTE · 投入程度：標準 · 1 輪

傳送的背景資訊： 位於一座 4 萬人口德國小鎮的烘焙坊，有 6 名員工。客製蛋糕與預訂的利潤最高。目前，訂單僅透過電話與電子郵件進來；網站只有營業時間與聯絡表單，沒有可供下訂的功能。Google 商家檔案有 120 則評論、4.7 顆星。迄今沒有付費廣告。預算：下一季 3,000 歐元，店主時間不多。

選項： Google Ads · 一個完善的線上訂購頁面 · 兩者平均分配

議會的結果

gpt-5.6 信心度 94

一個完善的線上訂購頁面先解決瓶頸：目前，有興趣的顧客無法方便地或以有結構的方式預訂。一個簡單、適合行動裝置的訂購頁面，包含蛋糕選擇、取貨日期、客製化選項、價格或訂金，以及確認功能，能利用烘焙坊已擁有的強大本地曝光度，並減少電話與電子郵件的工作量。在沒有可靠訂購流程的情況下投放 Google Ads，會將付費流量導入薄弱的轉換路徑。在幾週可衡量的訂單之後，之後的廣告預算可以更有針對性地花用。

gemini-3.6-flash 信心度 90

一個完善的線上訂購頁面沒有數位訂購路徑，廣告只會透過電話與電子郵件製造更多耗時的人工工作，而店主幾乎無法應付。此外，強大的 Google 檔案（4.7 顆星）在有了真正的訂購頁面後，會立即更好地轉換它已帶來的自然流量，這應在任何資金投入廣告之前進行。

claude（第三位投票者） 信心度 74

一個完善的線上訂購頁面唯有點擊能轉化為訂單，廣告才划算。目前每位訪客都必須打電話或寄電子郵件，因此付費流量會流失。一個包含產品選擇、取貨日期與預付款的訂購頁面，能轉換 4.7 星檔案已帶來的需求，並讓之後的廣告可被衡量。

決定 一個完善的線上訂購頁面 路徑 一致 3:0 成本 $0.012

讓 Kirat 對此投票：現在就將我們的計費模組抽取為獨立服務，還是先在單體架構內強化其邊界？

kirat_vote 詢問了議會

議會已決定（一致 3:0）：先在單體架構內強化邊界。

所有三個立場，包括我的，都指向同一方向。每一個都附有其理由。

幕後

kirat_vote Claude 傳送給 Kirat 的內容

問題： 現在就將我們的計費模組抽取為獨立服務，還是先在單體架構內強化其邊界？

錄製於 2026-10-13 · KIRAT_VOTE · 投入程度：標準 · 1 輪

傳送的背景資訊： 8 名工程師的團隊。一個 TypeScript 單體架構，約 60,000 行，一個 Postgres 資料庫，每天部署數次。計費模組每週變更，並造成最近 8 起生產事故中的 5 起，主要是因為其他模組直接讀寫計費資料表。團隊中沒有人曾在生產環境運行過分散式系統。領導層希望在兩個季度內減少事故。

選項： 現在就將計費抽取為服務 · 先在單體架構內強化邊界

議會的結果

gpt-5.6 信心度 94

先在單體架構內強化邊界這些事故主要是由不受控的資料庫存取所造成，而非缺乏網路邊界。在單體架構內強制執行計費的擁有權：移除直接資料表存取、暴露狹窄的內部 API、新增資料庫權限或結構描述層級的控制，並新增契約與整合測試。這能在兩個季度的時間窗內快速針對故障模式。現在抽取會為一個沒有分散式系統經驗的團隊增加部署、可觀測性、重試、資料一致性與營運複雜度。一旦存取路徑與資料擁有權明確，抽取會變得更安全，且若獨立擴展或部署仍有價值，可以重新考慮。

gemini-3.6-flash 信心度 90

先在單體架構內強化邊界停機的主要原因，是其他模組直接在資料庫中存取計費資料表。強化模組邊界能在現有單體架構內直接解決這個問題。由於 8 人團隊沒有分散式系統的經驗，現在抽取模組會產生新的風險，並危及在兩個季度內減少事故的目標。

claude（第三位投票者） 信心度 76

先在單體架構內強化邊界事故來自其他模組直接碰觸計費資料表。服務拆分也會強制執行該邊界，但它會為一個沒有相關經驗的團隊增加網路故障、分散式交易與新的營運工作。在單體架構內強制執行模組 API 與資料表擁有權，能更快修正根本原因，並為日後保留抽取的選項。

決定 先在單體架構內強化邊界 路徑 一致 3:0 成本 $0.014

讓 Kirat 對此投票：在我們的系統性文獻回顧中，單一 LLM 篩選流程能否取代第二位人工篩選者？

kirat_vote 詢問了議會

議會已決定（一致 3:0）：將 LLM 作為額外的篩選者；由人工解決衝突。

所有三個立場，包括我的，都指向同一方向。每一個都附有其理由。

幕後

kirat_vote Claude 傳送給 Kirat 的內容

問題： 在我們的系統性文獻回顧中，單一 LLM 篩選流程能否取代第二位人工篩選者？

錄製於 2026-10-13 · KIRAT_VOTE · 投入程度：標準 · 1 輪

傳送的背景資訊： 為一篇計畫發表的健康服務研究系統性文獻回顧，對約 3,000 筆紀錄進行標題與摘要篩選。目前的流程：兩位獨立的人工篩選者，衝突透過討論解決。人員時間短缺。該回顧遵循 PRISMA，期刊審稿人會詢問篩選是如何進行的。漏掉一項相關研究（錯誤排除）比納入一項不相關的研究更糟。 選項： 是，取代第二位人工篩選者 · 將 LLM 作為額外篩選者；由人類解決衝突 · 否，保留兩位人工篩選者且不使用 LLM

理事會的結果

gpt-5.6 信心 94

將 LLM 作為額外篩選者；由人類解決衝突。當錯誤排除是主要風險時，單次 LLM 篩選不應取代獨立的人工篩選：效能可能因主題、提示詞和模型版本而異，且錯誤可能具有系統性。可用它來排定記錄優先順序或標記分歧，但衝突必須由人類解決，排除也必須經人類確認。請記錄模型、版本、提示詞、驗證樣本和決策流程，以供 PRISMA 報告和可重現性使用。

gemini-3.6-flash 信心 88

將 LLM 作為額外篩選者；由人類解決衝突。混合式做法可大幅減少 3,000 篇標題與摘要的人工工作量，同時保留 PRISMA 和同儕審查者要求的方法學嚴謹度。由於必須避免錯誤排除，讓人類解決每一處不一致（或採用高度敏感的提示詞做法）可確保不會遺漏任何相關研究。

claude（第三位投票者） 信心 70

將 LLM 作為額外篩選者；由人類解決衝突。錯誤排除是代價高昂的錯誤，而 LLM 在篩選上的召回率會因主題和提示詞而異。取代第二位人工篩選者會移除能攔截這些錯誤的檢查，且難以向期刊審查者辯護。將 LLM 新增為第三位篩選者並由人類解決衝突，可讓研究方案站得住腳，同時仍能標記出可能的遺漏。

決策 將 LLM 作為額外篩選者；由人類解決衝突 路徑 一致通過 3:0 成本 $0.019

於 2026 年 10 月 13 日以 kirat_vote 在標準投入層級記錄；每個工作階段耗時不到 20 秒，成本不到兩美分。問題、選項和背景皆按送出時的原樣顯示，推理過程完整呈現。Gemini 以德文回答了四次，ChatGPT 回答了一次；那些回答已在此翻譯。在免費層級的問題中，Claude 以 2:1 落敗，其反對意見仍保留在紀錄中。信心值為各模型自行回報。

來自不同領域的五段程式碼摘錄，每段皆按原樣送出。ChatGPT 和 Gemini 並行審查，Claude 自行補充兩項發現，而每項發現都會由另一個模型家族檢查。只有經確認的發現才計入。請選擇一項。

在我們發布之前，請讓 Kirat 審查我們的 Stripe 付款 webhook 的安全性與正確性。

kirat_review 詢問了理事會

Kirat 找到 14 項已確認問題（4 項 × 嚴重、4 項 × 高、6 項 × 中）。每項發現都經另一個模型家族交叉檢查。

請從清單最上方開始處理；每項都附有建議的修正方式。

幕後過程

kirat_review Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_REVIEW · 投入：標準 · 14 項已確認，0 項已否決 · $0.14

重點： 付款 webhook 的安全性與正確性

送出的程式碼：

// routes/webhooks.js — payment webhook of a solo invoicing SaaS (Node 20, Express 4, Stripe, pg)
const express = require('express');
const { db } = require('../db');
const router = express.Router();

router.post('/webhooks/stripe', express.json(), async (req, res) => {
  const event = req.body;

  if (event.type === 'invoice.paid') {
    const invoice = event.data.object;
    const userId = invoice.metadata.userId;
    await db.query('UPDATE users SET plan = $1, paid_until = $2 WHERE id = $3',
      ['pro', new Date(invoice.period_end * 1000), userId]);
    await db.query('INSERT INTO payments (user_id, amount) VALUES ($1, $2)',
      [userId, invoice.amount_paid / 100]);
  }

  if (event.type === 'customer.subscription.deleted') {
    await db.query("UPDATE users SET plan = 'free' WHERE stripe_customer = '" + event.data.object.customer + "'");
  }

  res.sendStatus(200);
});

module.exports = router;

理事會的結果

1. 嚴重 此 webhook 在未檢查 Stripe 簽章的情況下處理請求主體。因此任何外部呼叫者都能傳送偽造的 invoice.paid\ 或 customer.subscription.deleted\ 事件，並解鎖或降級使用者帳戶。JSON 解析器也會丟棄 Stripe 簽章驗證所需的未修改原始主體。 修正： 為此路由使用 express.raw({ type: 'application/json' })\，並在任何處理之前呼叫 stripe.webhooks.constructEvent(req.body, req.headers\['stripe-signature'\], webhookSecret)\。請確保事先沒有全域 JSON 解析器已套用至此路由；以 400 拒絕無效簽章。 第 6 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
2. 嚴重 缺少對 Stripe webhook 簽章的驗證。攻擊者可向此端點傳送任意偽造的 webhook 事件，以便未經授權將帳戶設為 Pro 或操縱資料庫項目。 修正： 使用 stripe.webhooks.constructEvent() 搭配 Stripe webhook 密鑰，以驗證每個事件的真實性和完整性。 第 6 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
3. 嚴重 SQL 注入漏洞，原因是將使用者輸入（event.data.object.customer）直接串接進 SQL 查詢字串。 修正： 如同先前的語句使用參數化查詢：db.query('UPDATE users SET plan = $1 WHERE stripe_customer = $2', ['free', event.data.object.customer])。 第 18 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
4. 嚴重 此 webhook 從不驗證 Stripe 簽章，而 express.json() 會丟棄進行驗證所需的原始主體。任何人都能 POST 偽造的 invoice.paid 事件，並免費將任何帳戶升級為 pro。 修正： 在此路由使用 express.raw({ type: 'application/json' })，並以 stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], endpointSecret) 建構事件；失敗時拒絕請求。 第 6 行 · 由 claude 發現 · 由 gpt-5.6、gemini-3.6-flash 確認
5. 高 客戶 ID 被直接插入 SQL 語句。像 ' OR 1=1 --\ 這樣的值可以操縱 WHERE 子句並將所有使用者設為免費方案；視資料庫設定而定，還可能進行進一步的 SQL 注入。 修正： 將查詢完全參數化：UPDATE users SET plan = 'free' WHERE stripe\_customer = $1\ 搭配 \[event.data.object.customer\]\。此外，透過 Stripe 簽章驗證事件。 第 19 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
6. 高 沒有冪等性檢查。Stripe 至少會傳遞 webhook 一次，並在逾時或錯誤時重試。因此同一個 invoice.paid\ 事件可能多次建立相同的付款項目。 修正： 將 Stripe 事件 ID 或發票 ID 儲存在付款記錄中，以 UNIQUE 約束保護它，並將事件處理與付款以插入/更新插入（upsert）的方式原子性地一起執行。對已處理的事件以 200 回應確認，而不重複業務操作。 第 14 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
7. 高 async\ 處理常式沒有錯誤轉送。Express 4 不會自動捕捉非同步路由處理常式被拒絕的 promise。因此資料庫錯誤或不完整的 invoice.paid\ 物件會導致未處理的 promise 拒絕，且在 Node 20 下可能終止程序，而不是以受控方式傳回錯誤回應。 修正： 將處理常式包裝在 try/catch\ 中並將錯誤傳遞給 next(err)\，或使用非同步包裝器。在存取之前驗證輸入結構，並在暫時性處理錯誤時以受控方式傳回 5xx 狀態，以便 Stripe 重新傳遞。 第 6 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
8. 高 對 webhook 端點使用 express.json() 會預先將主體解析為 JSON。然而 Stripe 的簽章驗證需要未修改的原始主體。 修正： 對 Stripe webhook 路由處理常式使用 express.raw({ type: 'application/json' }) 而非 express.json()。 第 6 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
9. 中 使用者更新和付款項目是兩個獨立提交的資料庫操作。如果 INSERT 在成功的 UPDATE 之後失敗，使用者會取得 Pro 方案，即使不存在對應的付款記錄。 修正： 在同一用戶端上以單一資料庫交易將兩個操作與冪等性標記一起執行，並在任何錯誤時完全回滾。 第 12 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
10. 中 處理過程未考慮 Stripe 可能不按其建立順序傳遞事件。延遲的較舊 invoice.paid\ 可能重設 paid\_until\；延遲的 customer.subscription.deleted\ 可能將之後已重新啟用的使用者設回 free\。 修正： 使用穩定的 Stripe ID 調和目前的訂閱狀態，例如從 Stripe 擷取，並保存狀態轉換或最後處理事件的時間戳記。至少只應向前更新 paid\_until\，且不要盲目將刪除事件套用至目前的使用者狀態。 第 12 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
11. 中 amount\_paid / 100\ 未經檢查即假設貨幣恰好有兩位小數。例如對 JPY 而言這是錯誤的。此外，貨幣未與其一起儲存，因此付款記錄中的金額沒有明確的單位。 修正： 最好將金額以最小貨幣單位原樣儲存，並一併儲存 invoice.currency\。若需要主要貨幣單位，請依各自的貨幣指數進行換算。 第 15 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
12. 中 非同步 Express 4 路由中缺少例外處理。在資料庫錯誤或缺少欄位時，這會導致未處理的 promise 拒絕，可能使應用程式崩潰。 修正： 新增 try-catch 區塊並將錯誤傳遞給 next(err)，或使用如 express-async-handler 之類的工具。 第 6 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
13. 中 未驗證 invoice.metadata.userId 是否存在。如果 metadata 或 userId 欄位缺少或未定義，SQL 查詢會失敗或操作無效的值。 修正： 在執行資料庫查詢之前，明確檢查 invoice.metadata 和 invoice.metadata.userId 是否存在且有效。 第 10 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
14. 中 Stripe 會重試 webhook，且可能多次傳遞同一事件。每次傳遞都會插入另一筆付款資料列，因此營收報告會重複計算。 修正： 以唯一約束儲存 event.id（或發票 id），並略過已處理的事件。 第 14 行 · 由 claude 發現 · 由 gpt-5.6、gemini-3.6-flash 確認

請讓 Kirat 審查這個 WooCommerce 匯入外掛的安全性與正確性。

kirat_review 詢問了理事會

Kirat 找到 21 項已確認問題（5 項 × 嚴重、5 項 × 高、10 項 × 中、1 項 × 低）。每項發現都經另一個模型家族交叉檢查。

請從清單最上方開始處理；每項都附有建議的修正方式。

幕後過程

kirat_review Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_REVIEW · 投入：標準 · 21 項已確認，0 項已否決 · $0.17

重點： WooCommerce 匯入外掛的安全性與正確性

送出的程式碼：

<?php
// erp-import.php — custom plugin: imports the ERP's CSV export into WooCommerce (WordPress 6, WooCommerce 9)
add_action('wp_ajax_erp_import', 'erp_import');
add_action('wp_ajax_nopriv_erp_import', 'erp_import');

function erp_import() {
    global $wpdb;
    $path = $_POST['file'];
    $rows = array_map('str_getcsv', file($path));

    foreach ($rows as $row) {
        [$sku, $name, $price, $stock] = $row;
        $id = $wpdb->get_var("SELECT post_id FROM {$wpdb->postmeta} WHERE meta_key = '_sku' AND meta_value = '$sku'");
        if (!$id) continue;
        update_post_meta($id, '_price', $price);
        update_post_meta($id, '_regular_price', $price);
        update_post_meta($id, '_stock', $stock);
        wp_update_post(['ID' => $id, 'post_title' => $name]);
    }
    echo 'Imported ' . count($rows) . ' rows';
    wp_die();
}

理事會的結果

1. critical 匯入功能可透過 wp\_ajax\_nopriv\_erp\_import\ 公開存取；已驗證的 hook 也缺少能力與 nonce 檢查。因此，匿名使用者或 CSRF 攻擊可以變更產品名稱、價格與庫存數量。 修正： 移除 nopriv\ hook，在進行任何處理前檢查適當的能力（例如 manage\_woocommerce\），並以 check\_ajax\_referer()\ 保護請求。 第 3 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
2. critical hook wp_ajax_nopriv_erp_import 讓未驗證的訪客得以存取匯入功能。 修正： 移除 nopriv hook，並使用 current_user_can('manage_options') 檢查權限。 第 4 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
3. critical 來自 $_POST['file'] 的檔案路徑未經檢查即傳入 file()，這會導致路徑遍歷與任意檔案讀取（LFI）。 修正： 透過 $_FILES 處理檔案上傳，或嚴格驗證輸入路徑是否位於允許的目錄（例如 wp_upload_dir()）。 第 7 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
4. critical SQL 注入漏洞，因為 $sku 未經清理即直接插入 SQL 查詢中。 修正： 使用 $wpdb->prepare() 的預備語句。 第 11 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
5. critical 匯入功能註冊於 wp_ajax_nopriv，且沒有能力檢查，也沒有 nonce。任何訪客都能觸發它並覆寫價格、庫存與產品名稱。 修正： 移除 nopriv hook，檢查 current_user_can('manage_woocommerce')，並在執行任何操作前以 check_ajax_referer() 驗證 nonce。 第 4 行 · 由 claude 發現 · 由 gpt-5.6、gemini-3.6-flash 確認
6. high 用戶端提供的路徑未經檢查即傳入 file()\。這允許處理任何可讀取的本地檔案，且視 allow\_url\_fopen\ 而定，還可處理外部或內部 URL，從而導致非預期的檔案存取與盲 SSRF。 修正： 不要接受任意選擇的路徑。僅使用伺服器端已知的上傳 ID，檢查標準路徑是否位於固定的匯入目錄，並僅允許一般的本地 CSV 檔案。 第 8 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
7. high $sku\ 來自 CSV，並直接插值到 SQL 中。包含 SQL 中繼字元的 SKU 值可以操縱查詢，並可選擇任何文章 ID 作為更新目標。 修正： 使用 $wpdb-\>prepare()\ 將查詢參數化，例如使用 meta\_value = %s\，或使用 WooCommerce 依 SKU 查詢產品的函式。 第 13 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
8. high file()\ 將整個輸入載入記憶體，而 array\_map()\ 另外建立完整的解析陣列。若無大小限制，大型或無盡的遠端資源可能耗盡記憶體、執行時間與 PHP worker；公開可存取性使情況更糟。 修正： 限制檔案大小與行數，使用 fopen()\ 在本地開啟檔案，並透過 fgetcsv()\ 以串流方式處理記錄。此外，使用速率限制或受控的背景工作。 第 9 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
9. high 缺少 CSRF 保護（nonce 驗證）。 修正： 在函式開頭呼叫 check_ajax_referer()。 第 6 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
10. high 檔案路徑直接來自請求並傳入 file()。攻擊者可讀取網頁伺服器可讀取的任何檔案，或在 allow_url_fopen 開啟時讀取遠端 URL。 修正： 透過 wp_handle_upload() 接受上傳的檔案，或僅從一個固定的匯入目錄讀取；絕不要從請求取得路徑。 第 8 行 · 由 claude 發現 · 由 gpt-5.6、gemini-3.6-flash 確認
11. medium 假設每一行恰好有四個可用的欄位。空白或損壞的行會產生缺少的值，導致警告，並可能非預期地將名稱、價格或庫存設為空值。 修正： 在解構之前，檢查欄位數與必要欄位，跳過空白行，並以清楚的錯誤訊息拒絕有問題的記錄。 第 12 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
12. medium file()\ 與 str\_getcsv()\ 的組合會分別解析每個實體行。因此，包含內嵌換行符號的有效 CSV 欄位會被拆成多筆有問題的記錄。 修正： 使用 fgetcsv()\ 以串流方式讀取 CSV；此函式可跨記錄邊界正確處理多行、正確引號的欄位。 第 9 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
13. medium 價格與庫存未經檢查即儲存為任意字串。非數值、錯誤的小數格式或不被允許的庫存數量可能損壞產品資料，並導致計算不一致。 修正： 在寫入前驗證價格與庫存，並使用 WooCommerce 輔助函式（例如 wc\_format\_decimal()\ 與 wc\_stock\_amount()\）將其正規化；拒絕無效或從業務角度不被允許的值。 第 15 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
14. medium WooCommerce 資料直接以文章中繼資料變更。因此，相關狀態（例如 \_stock\_status\）、產品查詢表以及可能的快取無法可靠地與新的價格和庫存數量同步。 修正： 透過 wc\_get\_product()\ 載入產品，使用 CRUD 方法（例如 set\_regular\_price()\、set\_price()\ 與 set\_stock\_quantity()\），依業務規則設定庫存狀態或 manage\_stock\，然後呼叫 save()\。 第 15 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
15. medium SKU 查詢會考慮所有文章中繼資料，且既不檢查文章類型，也不檢查找到的 ID 是否確實是 WooCommerce 產品或變體。若有重複或不相關的 \_sku\ 中繼資料，也會更新非確定性的匹配結果。 修正： 使用 wc\_get\_product\_id\_by\_sku()\，然後以 wc\_get\_product()\ 與預期的產品類型驗證結果；將重複的 SKU 視為匯入錯誤。 第 13 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
16. medium update\_post\_meta()\ 與 wp\_update\_post()\ 的回傳值被忽略。匯入可能部分失敗或中止，但仍將讀取的行數總計回報為成功匯入。 修正： 記錄每個產品的成功與失敗，使用 wp\_update\_post(..., true)\，僅計入實際更新的記錄，並回傳結構化的錯誤回應。為大型匯入提供可續作的背景工作。 第 15 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
17. medium 對於每一行 CSV，至少會同步執行一次查詢與數個個別寫入操作。因此，大型匯入會造成大量資料庫往返，可能觸發請求逾時，並留下僅部分更新的目錄。 修正： 以背景程序分批執行匯入，集中解析 SKU，並儲存進度與續作狀態。 第 11 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
18. medium file() 一次將整個檔案讀入記憶體，導致大型 CSV 檔案發生記憶體耗盡錯誤。 修正： 透過 fopen() 與 fgetcsv() 逐行串流讀取檔案。 第 8 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
19. medium 陣列解構假設每一行至少包含 4 個元素；否則會發生 PHP 警告或未初始化索引錯誤。 修正： 在解包之前，使用 count($row) 檢查是否有足夠的欄位。 第 10 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
20. medium 資料庫查詢與文章更新在迴圈中個別執行（N+1 問題），大幅拖慢執行時間。 修正： 將匯入分成批次，並合併查詢/更新。 第 11 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
21. low 未檢查 file()\ 的錯誤。對於缺少、無法讀取或不支援的路徑，file()\ 會回傳 false\，隨後 array\_map()\ 在目前的 PHP 版本下可能拋出 TypeError\。 修正： 明確檢查開啟與讀取，不要將 PHP 警告當作控制流程，並在發生錯誤時回傳適當的 HTTP 或 wp\_send\_json\_error()\ 回應。 第 9 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認

請 Kirat 審查麵包店訂購頁面的訂單與付款流程的安全性與正確性。

kirat_review 詢問了議會

Kirat 發現 14 個已確認的問題（4 × critical、4 × high、5 × medium、1 × low）。每個發現都由另一個模型家族交叉檢查。

從清單最上方的問題開始；每個都附有建議的修正方式。

幕後

kirat_review Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_REVIEW · 投入程度：STANDARD · 14 已確認，0 已拒絕 · $0.11

重點： 訂單與付款流程的安全性與正確性

傳送的程式碼：

// routes/order.js — order endpoint of the bakery's ordering page (Node 20, Express 4, pg)
const express = require('express');
const { pool } = require('../db');
const { sendConfirmation } = require('../mail');
const router = express.Router();

router.post('/order', async (req, res) => {
  const { cakeId, pickupDate, name, email, price, note } = req.body;

  const cake = await pool.query(\`SELECT * FROM cakes WHERE id = ${cakeId}\`);
  if (!cake.rows.length) return res.status(404).send('Unknown cake');

  const order = await pool.query(
    'INSERT INTO orders (cake_id, pickup_date, name, email, amount, note) VALUES ($1, $2, $3, $4, $5, $6) RETURNING id',
    [cakeId, pickupDate, name, email, price, note]
  );

  sendConfirmation(email, order.rows[0].id);
  res.redirect(\`/pay?order=${order.rows[0].id}&amount=${price}\`);
});

module.exports = router;

議會的結果

1. critical cakeId 被直接插值到 SQL 字串中。攻擊者可注入 SQL 運算式或額外語句，藉此讀取或修改資料，或對資料庫造成負載。 修正： 同樣將此查詢參數化，例如 SELECT... FROM cakes WHERE id = $1\ 搭配 \[cakeId\]\，並額外檢查 cakeId 是否符合預期型別。 第 10 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
2. critical 由於 cakeId 在 SQL 查詢中直接以模板字串插值，導致 SQL 注入漏洞。 修正： 使用參數化 SQL 查詢：pool.query('SELECT * FROM cakes WHERE id = $1', [cakeId])。 第 9 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
3. critical 可能發生用戶端價格竄改。價格取自 req.body 並直接儲存與處理。 修正： 在伺服器端從資料庫讀取價格（cake.rows[0].price），不要信任用戶端送出的值。 第 8 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
4. critical 來自請求主體的 cakeId 被插值到 SQL 字串中：SQL 注入。 修正： 使用參數化查詢：SELECT * FROM cakes WHERE id = $1。 第 10 行 · 由 claude 發現 · 由 gpt-5.6、gemini-3.6-flash 確認
5. high 儲存並傳入付款流程的金額完全來自 req.body.price\。客戶可為任何蛋糕輸入遭竄改、負數或極小的金額。 修正： 僅在伺服器端依據所選蛋糕或不可變的價格版本決定價格。在付款服務商以該金額建立伺服器端付款工作階段，並於付款確認時再次在伺服器端驗證預期金額。 第 16 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
6. high 在任何成功付款獲得驗證之前，訂單就已建立並送出確認。因此，中止或刻意未付款的交易會顯示為已確認訂單，且可任意產生。 修正： 訂單初始建立時使用例如 pending\_payment\ 的狀態。只有在收到經過驗證、以冪等方式處理的付款服務商通知後，才切換為 paid\，然後再送出確認或觸發生產或預訂。 第 19 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
7. high 非同步 Express 4 路由缺少錯誤處理。資料庫或執行階段錯誤會導致未處理的 promise 拒絕。 修正： 使用 try/catch 區塊並以 next(err) 轉送錯誤，或使用 express-async-errors 等套件。 第 8 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
8. high 金額取自用戶端（請求主體中的價格），因此客戶可自行設定價格。 修正： 在伺服器端從 cakes 資料列讀取價格，並忽略任何用戶端值。 第 15 行 · 由 claude 發現 · 由 gpt-5.6、gemini-3.6-flash 確認
9. medium 此非同步處理常式沒有轉送錯誤。Express 4 不會自動處理 async\ 處理常式所產生的 promise 拒絕；因此資料庫或同步郵件錯誤可能導致請求得不到回應，以及未處理的拒絕。 修正： 將處理常式包裝在 try/catch\ 中，並將錯誤傳遞給 next(err)\，或使用既有的非同步包裝器。此外，設定集中式錯誤處理。 第 7 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
10. medium sendConfirmation\ 的結果既未被 await，也未以其他方式處理錯誤。promise 拒絕可能保持未處理；同時，即使寄送郵件可能已失敗，用戶端仍會收到成功回應。 修正： 在確認付款後，透過具持久性的 outbox 或含重試的工作佇列執行寄送。至少應 await 該 promise，並以受控方式記錄或處理錯誤。 第 19 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
11. medium 沒有冪等性保護。瀏覽器重試、雙擊或網路重試都會各自建立新訂單，並可能產生多次確認或付款嘗試。 修正： 接受冪等鍵或結帳工作階段 ID，以唯一約束保護它，並在重試時回傳已存在的訂單。 第 13 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
12. medium pickupDate、name、email、price 和 note 在未經業務或語法驗證的情況下被處理。這表示例如過去或無效的取貨日期、缺少客戶資料及不適當的欄位值都可能被儲存；資料庫錯誤也只會延遲且不受控地發生。 修正： 使用含型別、必填欄位、長度限制及正規化格式的請求結構描述。依時區、前置時間及允許的營業時間或容量規則檢查取貨日期；不要接受價格作為用戶端輸入。 第 8 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
13. medium 對 sendConfirmation 的非同步呼叫既未被 await，也未被捕捉錯誤。 修正： 在 sendConfirmation 前加上 await，並在寄送電子郵件時處理可能的錯誤。 第 17 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
14. low 對 email、pickupDate、name 和 note 等欄位的輸入驗證不完整。 修正： 在處理請求資料前實作結構描述驗證（例如使用 Zod 或 express-validator）。 第 8 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認

請 Kirat 檢查此計費函式的正確性與資料完整性。

kirat_review 詢問了議會

Kirat 發現 16 個已確認問題（1 × critical、11 × high、3 × medium、1 × low）。每項發現皆由另一個模型家族交叉檢查。

請從清單最上方開始處理；每項都附有建議修正。

幕後

kirat_review Claude 傳送給 Kirat 的內容

已記錄 2026-10-13 · KIRAT_REVIEW · 投入程度：STANDARD · 16 已確認，0 已拒絕 · $0.14

重點： 計費函式的正確性與資料完整性

已傳送的程式碼：

// billing/applyCredit.ts — billing module in the monolith (TypeScript, node-postgres)
import { pool } from '../db';

export async function applyCredit(customerId: string, invoiceId: string, creditCents: number) {
  const inv = await pool.query('SELECT total_cents, status FROM invoices WHERE id = $1', [invoiceId]);
  const balance = await pool.query('SELECT credit_cents FROM customers WHERE id = $1', [customerId]);

  const available = balance.rows[0].credit_cents;
  if (creditCents > available) throw new Error('Not enough credit');

  const newTotal = inv.rows[0].total_cents - creditCents;
  await pool.query('UPDATE invoices SET total_cents = $1 WHERE id = $2', [newTotal, invoiceId]);
  await pool.query('UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2', [creditCents, customerId]);

  if (newTotal <= 0) {
    await pool.query("UPDATE invoices SET status = 'paid' WHERE id = $1", [invoiceId]);
  }
  return newTotal * 1.19 / 100;
}

議會的結果

1. critical 缺少資料庫交易與資料列鎖定。在並行請求下，可能發生競態條件（例如額度重複扣款），以及發生錯誤時更新不完整。 修正： 從連線池取得用戶端並使用 BEGIN/COMMIT，並使用 SELECT FOR UPDATE 以原子方式鎖定及更新資料列。 第 5 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
2. high 這三項相關更新未在資料庫交易中執行。若扣減客戶額度或狀態變更失敗，發票可能已被減額，但額度並未正確扣款或狀態並未設定。 修正： 從連線池取得專用用戶端，並在 BEGIN 與 COMMIT 之間執行所有檢查與更新；發生任何錯誤時使用 ROLLBACK。 第 11 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
3. high 發票先被讀取，之後再以計算出的絕對值覆寫。兩個並行呼叫可能讀取相同的起始值，然後互相覆寫；兩次額度扣款仍然都會發生，但發票中只會完整反映其中一筆額度。 修正： 在同一交易內以 SELECT... FOR UPDATE 鎖定受影響的發票，或透過 UPDATE... SET total_cents = total_cents - $1 並搭配適當條件以原子方式變更金額。 第 4 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
4. high 檢查與扣減客戶額度並非原子操作。並行呼叫可能都看到相同的可用額度，然後將額度扣減至低於零。 修正： 以交易方式鎖定客戶記錄，或使用條件式 UPDATE，例如 UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2 AND credit_cents >= $1 RETURNING credit_cents，並要求恰好回傳一列。 第 8 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
5. high 未檢查發票是否屬於指定的客戶。因此，客戶的額度可能被套用到任何透過 invoiceId 識別的發票。 修正： 透過所有權關係查詢並更新發票與客戶，例如使用 WHERE invoices.id = $1 AND invoices.customer_id = $2；若無相符結果則中止。 第 4 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
6. high 要套用的額度未以未結發票金額為上限。若 creditCents 大於 total_cents，將儲存負數的發票金額，並消耗過多的客戶額度。 修正： 僅允許最高至未結發票金額的金額，或將實際使用金額判定為 min(creditCents, total_cents)，並僅從客戶額度中扣減此金額。 第 10 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
7. high 負數、非整數或無法安全表示的數值未被拒絕。特別是負數的 creditCents 值會增加發票金額，同時透過減去負值而增加客戶額度。 修正： 在任何資料庫存取之前要求 Number.isSafeInteger(creditCents) && creditCents > 0；將金額一律視為整數分幣值處理。 第 8 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
8. high 所讀取的發票狀態完全被忽略。因此額度也可能被套用到已付款、已取消或已無法修改的發票；已付款的發票可能因此變成負數。 修正： 明確定義允許的起始狀態，並在 UPDATE 條件中以原子方式檢查，例如 AND status = 'open'。若無相符結果，則中止操作。 第 4 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
9. high 未先檢查即存取 balance.rows[0] 與 inv.rows[0]。若找不到客戶或發票，應用程式會因未處理的 TypeError 而崩潰。 修正： 在存取前檢查 inv.rows.length 與 balance.rows.length，並拋出明確的錯誤訊息。 第 8 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
10. high 缺少對 creditCents 負值的驗證。負值會繞過檢查（creditCents > available），並導致錯誤的額度或發票調整。 修正： 確保 creditCents 為大於 0 的正整數。 第 9 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
11. high 讀取與三項更新在交易之外執行，且沒有資料列鎖定。兩個並行呼叫可能都通過額度檢查並重複花用同一筆額度，而更新之間的崩潰會使發票與額度餘額不一致。 修正： 在單一用戶端上於一個交易中執行所有操作，以 SELECT... FOR UPDATE 鎖定資料列，並僅在所有更新成功後提交。 第 5 行 · 由 claude 發現 · 由 gpt-5.6、gemini-3.6-flash 確認
12. high 此函式從未檢查發票是否屬於該客戶，或是否仍為未結狀態。某位客戶的額度可能被套用到另一位客戶的發票，或套用到已付款的發票。 修正： 以 WHERE id = $1 AND customer_id = $2 AND status = 'open' 選取發票，若未回傳任何資料列則失敗。 第 11 行 · 由 claude 發現 · 由 gpt-5.6、gemini-3.6-flash 確認
13. medium 未檢查發票與客戶是否存在。對於未知的 ID，存取 rows[0] 會導致執行階段錯誤，而非受控的業務錯誤；此外，在問題顯現之前，兩個查詢都會被不必要地執行。 修正： 檢查兩個查詢的 rowCount 或 rows.length，並引發已定義的找不到錯誤；將檢查整合到交易中，並盡可能整合到關聯式查詢中。 第 4 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
14. medium 回傳值既不對應所儲存的分幣金額，也不對應單純換算為主幣別的金額：它加上固定的 19% 並使用浮點數運算。因此，呼叫端可能收到一個在稅額與捨入方面與實際儲存的剩餘發票餘額不同的值。 修正： 以分幣為單位原樣回傳剩餘金額，或定義型別明確的回傳值。若因業務原因需要計算稅額，請從發票資料取得稅率與捨入規則，並以整數或十進位運算計算。 第 17 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
15. medium 使用 IEEE 754 浮點數運算（newTotal * 1.19 / 100）進行財務計算。這會導致精度與捨入錯誤。 修正： 以整數（BigInt/Math.round）一致地以分幣為單位計算，或使用精確十進位運算的程式庫。 第 18 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
16. low 為發票狀態使用獨立的 UPDATE 命令會造成不必要的資料庫往返。 修正： 將 total_cents 與狀態的更新合併為單一 UPDATE 查詢。 第 12 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認

請 Kirat 檢查我們系統性回顧的篩選分析腳本是否正確。

kirat_review 詢問了議會

Kirat 發現 11 個已確認問題（6 × high、4 × medium、1 × low）。每項發現皆由另一個模型家族交叉檢查。

請從清單最上方開始處理；每項皆附有建議的修正方式。

幕後

kirat_review Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_REVIEW · 投入程度：STANDARD · 11 項已確認，0 項已否決 · $0.09

重點： 系統性回顧之篩選分析的正確性

傳送的程式碼：

# screening/agreement.py — compares two screeners' include/exclude decisions (Python 3.12, pandas)
import pandas as pd

a = pd.read_csv('screener_a.csv')   # columns: record_id, decision ('include'/'exclude')
b = pd.read_csv('screener_b.csv')

merged = a.merge(b, on='record_id', suffixes=('_a', '_b'))

agree = (merged.decision_a == merged.decision_b).mean()
p_inc_a = (merged.decision_a == 'include').mean()
p_inc_b = (merged.decision_b == 'include').mean()
expected = p_inc_a * p_inc_b + (1 - p_inc_a) * (1 - p_inc_b)
kappa = (agree - expected) / (1 - expected)

conflicts = merged[merged.decision_a != merged.decision_b]
excluded = merged[merged.decision_a == 'exclude']

print(f'Records screened: {len(a)}')
print(f"Cohen's kappa: {kappa:.2f}")
excluded.record_id.to_csv('excluded.csv', index=False)
conflicts.to_csv('conflicts.csv', index=False)

議會的結果

1. 高 預設的內部聯結會移除只出現在兩個檔案其中之一的全部 record_id 值。因此 Kappa 和衝突僅針對交集計算，而無法看出缺失的篩選。同時，第 18 行的「Records screened」回報的是 a 的長度，而非實際分析的聯集。 修正： 使用帶有合併指示器的外部聯結，明確比較 ID 集合，並單獨回報缺失的決定，或將其視為資料錯誤。對每個指標，輸出實際使用的分母。 第 7 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
2. 高 未檢查 record_id 的唯一性。重複的 ID 會在合併期間導致多對多的笛卡兒積，並使個別研究被重複加權，從而扭曲一致性、盛行率、kappa 和輸出檔案。 修正： 在合併前，檢查兩個檔案中的 record_id 是否非空且唯一，並在出現重複時中止。此外，使用 merge(..., validate='one_to_one')。 第 7 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
3. 高 未驗證決定值。在計算納入盛行率時，缺失值、拼寫錯誤、大小寫或額外類別會被隱含地視為「排除」，而觀察到的一致性則比較確切值。因此計算不再對應於二元 Cohen's kappa，並可能產生矛盾的結果。 修正： 在分析前以受控方式正規化 decision，並確保每個值恰好為 'include' 或 'exclude'。將缺失或未知值單獨視為資料錯誤或不完整的篩選來處理。 第 9 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
4. 高 excluded 包含篩選者 A 排除的所有記錄，包括篩選者 B 決定「納入」的衝突。因此這類記錄會同時寫入 excluded.csv 和 conflicts.csv。若 excluded.csv 旨在代表最終排除的命中，未解決的衝突可能會被錯誤地從審查中移除。 修正： 在沒有已記錄的優先規則下，僅選取一致的排除，即 (decision_a == 'exclude') & (decision_b == 'exclude')。在達成共識決定前，將衝突僅保留在 conflicts.csv 中。 第 16 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
5. 高 排除研究的篩選不正確：'excluded' 僅考量篩選者 A 的決定（'merged.decision_a == "exclude"'）。若存在衝突（篩選者 A 排除、篩選者 B 納入），該研究會被錯誤地計為排除。 修正： 僅在兩位篩選者都一致選擇 'exclude' 時才匯出排除（例如 '(merged.decision_a == "exclude") & (merged.decision_b == "exclude")'），或等待衝突解決。 第 16 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
6. 高 excluded.csv 包含篩選者 A 排除的每一筆記錄，包括篩選者 B 納入的衝突。這些記錄在衝突討論前就被丟棄，而這正是協定必須避免的錯誤排除。 修正： 僅排除兩位篩選者都排除的記錄：merged[(merged.decision_a == 'exclude') & (merged.decision_b == 'exclude')]；先將每個衝突送去解決。 第 16 行 · 由 claude 發現 · 由 gpt-5.6、gemini-3.6-flash 確認
7. 中 若兩位篩選者僅使用相同類別，expected 等於 1，而 kappa 的分母等於 0。結果會變成 NaN 或可能產生除以零的警告；格式化輸出「nan」並未說明 kappa 在數學上未定義。空的已分析交集也會導致無意義的 NaN 指標。 修正： 在除法前，檢查是否完全沒有成對的有效決定，以及 1 - expected 是否大於 0。在退化情況下，明確將 kappa 回報為「未定義」，並回報底層的頻率。 第 13 行 · 由 gpt-5.6 發現 · 由 gemini-3.6-flash 確認
8. 中 Cohen's kappa 中可能發生除以零，若預期機率值 'expected' 等於 1（例如兩位篩選者對 100% 的記錄都選擇相同類別）。 修正： 在計算前，捕捉 '1 - expected == 0' 是否成立，並在該情況下指定一個已定義的值（例如 1.0 或 NaN）。 第 12 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
9. 中 預設內部聯結會無聲地丟棄記錄。若篩選者 A 和篩選者 B 評定了不同的 'record_id' 集合，已處理研究中的差異不會被回報。此外，主控台輸出中的 'len(a)' 屆時不會對應於實際配對的研究數。 修正： 檢查 'len(a) == len(b) == len(merged)' 是否成立，或執行外部聯結以明確顯示未完整評定的記錄。 第 7 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認
10. 中 內部合併會無聲地丟棄只有一位篩選者已決定的記錄，而列印的計數使用 len(a)。未篩選的記錄會從一致性和 PRISMA 數字中消失。 修正： 以 how='outer'、indicator=True 合併，並在任何記錄缺少任一位篩選者的決定時失敗或回報。 第 7 行 · 由 claude 發現 · 由 gpt-5.6、gemini-3.6-flash 確認
11. 低 缺少輸入清理以及對 'decision' 欄中缺失值的處理。大小寫、空白或 NaN 值會導致不正確的比較。 修正： 在比較前清理欄值（例如使用 '.str.strip().str.lower()'），並確保資料型別安全。 第 9 行 · 由 gemini-3.6-flash 發現 · 由 gpt-5.6 確認

顯示：每個已確認的發現及其修正，如成員所寫；驗證者的推理縮短為其裁決。重複項不會合併，因此當多位成員回報同一問題時，一個問題可能出現多次。程式碼、焦點和 Claude 自己的發現以英文送出；成員以德文撰寫的發現在此翻譯。

來自不同領域的五份構想簡報。ChatGPT 和 Gemini 在三個軌道上工作，Claude 增加一個構想，而兩位成員匿名評分每個構想（各 1–10 分，最高 20 分）。選一個。

我的兩篇部落格文章在 Google 上排名，但很少讀者開始試用。與 Kirat 一起腦力激盪構想。

kirat_brainstorm 詢問了議會

議會提出了 14 個構想並匿名評分每個構想。前三名：

1. 以三次真實發送取代 14 天時鐘（18/20 分）
2. 在文章內完成任務（17/20 分）
3. 將追蹤文章變成復原主控台（17/20 分）

幕後

kirat_brainstorm Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_BRAINSTORM · 投入程度：標準 · 14 個構想 · 1 輪 · $0.11

主題： 為獨立開發者提供構想，將兩篇在 Google 上排名的部落格文章的更多讀者轉化為自由工作者發票工具的試用註冊

傳送的背景： 自由工作者發票工具，每月 19 美元，14 天免費試用，5 個月後有 30 位付費客戶。註冊主要來自兩篇在 Google 上排名的部落格文章（如何撰寫自由工作者發票；如何催收逾期付款）。約 12% 的試用會轉換。開發者有一份正職工作，每週約有 10 小時用於產品。硬性限制：不得付費廣告。硬性限制：每週最多 3 小時用於此事。

議會的結果

1. 1 將 14 天時鐘改為三次實際寄送 gpt-5.6 · 打破規則 · 18/20 分（9 + 9） 測試一種在寄出三張發票或進行三次付款催收後結束、而非在 14 個日曆天後結束的試用方案。這刻意打破「限時試用是合適做法」這項柔性假設：自由工作者未必會在任意的兩週窗口內開立發票，因此目前的試用可能在產品證明其價值之前就到期。維持每月 19 美元的方案不變，並依世代比較從啟用到付費的轉換率。
2. 2 在文章內完成任務 gpt-5.6 · 符合需求 · 17/20 分（9 + 8） 在「如何撰寫自由工作者發票」中嵌入一個小型發票建立工具：讀者輸入客戶、金額、到期日與付款條件，然後看到完成的預覽。「寄出或儲存這張發票」會建立一個已載入這些詳細資料的試用帳戶，消除學習與實作之間的落差。以每週不超過三小時的分批方式建置，之後將維護成本維持在接近零。
3. 3 將催收文章變成復原控制台 gpt-5.6 · 鄰近方案 · 17/20 分（9 + 8） 作為嵌入式發票建立工具的一步替代方案，讓讀者輸入逾期金額與到期日，以產生帶有日期的三則訊息催收序列。開始試用會儲存債務人、排定訊息，並開啟第一封可直接寄出的草稿。這保留了最強的模式——在註冊前提供有用的輸出——同時符合第二篇文章的意圖。
4. 4 將轉換時刻放到債務人的行事曆上 gpt-5.6 · 符合需求 · 16/20 分（7 + 9） 在逾期付款文章中提供產生的 .ics 檔案，內含到期日提醒，以及第 1、7、14 天逐步升級的後續追蹤。每個行事曆事件都包含一個深層連結，可開啟相關的催收工作流程並預填日期，在讀者真正感到痛點時把他們帶回來，而不是在他們只是研究階段時。這不需要擷取電子郵件，且可無人值守運行。
5. 5 以單一客戶永久免費方案取代試用期 gemini-3.6-flash · 打破規則 · 16/20 分（8 + 8） 這個想法打破 14 天試用的柔性限制，改以恰好一個活躍客戶的免費增值方案取代。自由工作者可永久免費使用產品服務第一位客戶，並在新增第二位客戶時無縫升級為 19 美元的統一費率。
6. 6 依立即問題為讀者分流 gpt-5.6 · 符合需求 · 14/20 分（8 + 6） 以三個內嵌選項取代通用試用橫幅，例如「我需要我的第一張發票」、「我經常開立發票」和「客戶已經逾期」。每個選項會開啟相符的入門狀態，而非同一個首頁，且文章區段 ID 可預先選取合理的預設值。衡量完成的試用啟用，而不只是 CTA 點擊，並每週測試一條路徑。
7. 7 發布三份鑑識式發票改造案例 gpt-5.6 · 符合需求 · 14/20 分（8 + 6） 在取得許可下，將三張匿名化的客戶發票轉為靜態的前後對照案例研究，確切展示改變了什麼以及為什麼。將每份改造案例插入排名文章中相關建議的旁邊，並附上一個 CTA，可開啟與可編輯試用範本相同的修正後結構。來自小型客戶群的具體證據，可能比廣泛的推薦更具可信度。
8. 8 讓讀者在兩篇文章之間保留進度 gpt-5.6 · 符合需求 · 14/20 分（7 + 7） 在瀏覽器本機儲存讀者選擇的貨幣、發票階段與到期日，並在他們於兩篇文章之間移動時使用該狀態。曾建立發票計畫的人之後可看到情境式提示，例如「你的發票現已逾期 3 天——開啟已備妥的後續追蹤」，並預填試用入門資料。這創造了一段輕量的兩篇文章旅程，無需帳戶或持續的內容產出。
9. 9 互動式提醒信函設定工具 gemini-3.6-flash · 符合需求 · 14/20 分（7 + 7） 在關於追蹤逾期付款的文章中，加入一個可逐步升級的付款提醒信函產生器。輸入文字後，即產生範本，並結合 CTA，在試用帳戶中為未來發票設定自動付款提醒。
10. 10 無需事先註冊的即時寄送魔法連結 gemini-3.6-flash · 鄰近方案 · 14/20 分（8 + 6） 內容內產生器的變體：讀者直接在部落格文章中輸入發票詳細資料，並點擊「立即寄出發票」。在背景中，系統無縫建立試用帳戶並直接寄出電子郵件；密碼僅在之後設定。
11. 11 直接在部落格文章中的即時發票產生器 gemini-3.6-flash · 符合需求 · 13/20 分（6 + 7） 在關於撰寫發票的文章中直接嵌入一個簡單的互動式表單工具。讀者輸入發票詳細資料，即可立即免費下載完成的 PDF。一個顯眼的按鈕提供一鍵數位寄送發票，並在 14 天試用帳戶中追蹤付款狀態。
12. 12 一次性按次付費提醒，而非每月訂閱 gemini-3.6-flash · 打破規則 · 13/20 分（6 + 7） 這個想法打破每月 19 美元純 SaaS 訂閱模式的柔性限制。以 5 美元的一次性費用，逾期付款文章的讀者可寄出一封具法律效力的提醒信函（含追蹤連結），若之後訂閱則費用全額折抵。
13. 13 在工具中開啟的範本 claude · 符合需求 · 11/20 分（6 + 5） 將文章中的發票範本提供為工具中可直接使用的發票：一鍵開啟預填的試用帳戶，而非下載檔案。
14. 14 依問題而定的退出意圖，搭配自動化電子郵件序列 gemini-3.6-flash · 符合需求 · 8/20 分（4 + 4） 在逾期付款文章上實作退出意圖彈出視窗，以電子郵件地址換取針對逾期付款客戶的緊急電子郵件範本。接著由自動化的三部分電子郵件序列被動說明自動化工作流程如何減少逾期付款，並連結至試用帳戶。

與 Kirat 一起腦力激盪：我們如何將這次一次性商店重建，轉變成客戶真正想要的維護方案？

kirat_brainstorm 詢問了議會

議會提出了 15 個想法，並匿名評分每個想法。前三名：

1. 預算突破：營運先於上線光環（18/20 分）
2. CSV 產品守門員（17/20 分）
3. 可靠性紅利（17/20 分）

幕後

kirat_brainstorm Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_BRAINSTORM · 投入程度：標準 · 15 個想法 · 1 輪 · $0.10

主題： 一家小型數位代理商如何將一次性商店重建，轉變成客戶真正想要的經常性維護合約的想法

傳送的背景： 4 人代理商。客戶在德國、奧地利和瑞士銷售約 1,800 項家具產品，有 3 名員工且沒有內部開發人員，年營收約 120 萬歐元。舊的自架 WooCommerce 商店有 31 個外掛，去年發生兩起安全事件；客戶希望降低維護需求並減少緊急狀況。本地 ERP 以 CSV 匯出產品資料。重建預算：25,000 歐元。硬性條件：不得鎖定；客戶必須能隨時帶著所有資料與存取權離開。硬性條件：代理商不得額外招聘。

議會的結果

1. 1 預算突破：上線前的營運成本說明 gpt-5.6 · 打破規則 · 18/20 分（9 + 9） 這個想法刻意打破 25,000 歐元重建預算的軟性限制：舉例來說，報價是 22,000 歐元用於刻意精簡的上線，加上 12,000 歐元用於具約束力的第一年營運。作為回報，初始專案中捨棄了錦上添花的功能；取而代之的是，資金投入於匯入強化、還原演練、監控與每月改善。較高的總金額之所以划算，是因為客戶不再是一次又一次買下一個看似完成、實際營運成本卻要等到上線後才浮現的商店；所有存取憑證、資料與工作成果在任何時候都保持可轉移。
2. 2 CSV 產品守門員 gpt-5.6 · 符合需求 · 17/20 分（9 + 8） 在每次 ERP 匯入之前，自動化流程會檢查 CSV 是否有缺少價格、重複項目、無效變體、圖片錯誤、DACH 稅務邏輯與可疑的庫存變動。每月定額維護費涵蓋規則維護、匯入監控，以及為三名員工提供的易懂錯誤報告。這將技術維護轉化為直接的業務效益：更少的錯誤產品、後續詢問與放棄的購買。
3. 3 可靠性紅利 gpt-5.6 · 符合需求 · 17/20 分（8 + 9） 客戶支付適度的基本費用於監控與維護；額外的季度金額只有在達成約定的可靠性目標（例如成功匯入、經過測試的還原與回應時間）時才需支付。由代理商造成、可避免的停機將產生服務折抵，而非可計費的緊急工時。這個模式讓經濟誘因與預防措施一致，並消除客戶對代理商從問題中獲利的擔憂。
4. 4 可隨時退出的照護章程 gpt-5.6 · 符合需求 · 16/20 分（9 + 7） 這項維護合約刻意作為反鎖定產品銷售：監控、更新、備份、安全檢查與每月兩項小型變更，費用約 1,200–1,500 歐元。所有帳戶由客戶持有，程式碼與匯入腳本存放在客戶的儲存庫中；客戶每月還會收到文件、資料匯出與交接包，讓他們隨時可以取消。如此一來，客戶支付的是可證明的可運作性，而非依賴性。
5. 5 季節性發布列車 gpt-5.6 · 符合需求 · 16/20 分（8 + 8） 不再有任意的支援工單，而是每年四次可規劃的商務發布，例如花園家具、夏末、黑色星期五週與聖誕節。每次發布的維護合約包含一個小型 UX 或商品陳列套件、回歸測試以及其間的技術維護。這讓客戶看到持續的開發進展，也讓四人代理商能將工作量打包處理。
6. 6 季度逃脫測試 gpt-5.6 · 符合需求 · 16/20 分（9 + 7） 每季一次，代理商提供產品、客戶、訂單與內容資料的完整匯出，並在中立的測試環境中執行有記錄的重啟。客戶支付的偏偏是定期證明的退出能力：存取清單、還原日誌與交接手冊都屬於客戶。嚴格的無鎖定標準因此從異議轉變為維護合約的不尋常賣點。
7. 7 照護章程加上成長交換 gpt-5.6 · 鄰近方案 · 16/20 分（8 + 8） 作為可隨時退出的照護章程的小型變體，內含的變更時數不事先固定，而是每月在營運、資料品質與轉換改善之間調配；未使用的額度最多可結轉一季。由聯合的 30 分鐘董事會議根據風險與營收機會決定如何使用。維護合約仍保持可隨時退出，但感覺不像保險，而更像一個靈活的外部數位團隊。
8. 8 ERP 同步與目錄安全維護合約 gemini-3.6-flash · 符合需求 · 13/20 分（7 + 6） 代理商接手本地 ERP CSV 與線上商店之間介面的持續監控與維護。錯誤的資料匯入、缺少的家具變體或錯誤的價格會在上線前被自動攔截。這完全卸下了客戶三人團隊的資料維護營運負擔。
9. 9 AI 驅動的產品資料豐富化定額方案 gemini-3.6-flash · 鄰近方案 · 13/20 分（6 + 7） ERP 介面想法的變體：代理商不僅維護 CSV 匯入，還使用 AI 腳本自動以結構化屬性、SEO 文案與 DACH 特定的交貨時間說明來豐富原始資料。這為客戶節省手動維護工作，並在無需額外代理商人力的情況下提升家具市場的能見度。
10. 10 基於 CI/CD 的視覺回歸維護合約 gemini-3.6-flash · 符合需求 · 12/20 分（6 + 6） 代理商不進行有風險的即時更新，而是建立一個預備環境流程，自動以視覺與功能方式檢查每月外掛更新。客戶每月收到透明度報告，以及安全漏洞的保證回應時間。這保證了絕對的穩定性，不再有先前的緊急狀況。
11. 11 季度轉換與 UX 打磨 gemini-3.6-flash · 符合需求 · 11/20 分（6 + 5） 除了基本維護外，維護合約還包含用於最佳化結帳功能與家具變體顯示的固定時數配額。代理商每月分析 DACH 地區的使用者行為，並實施高報酬的調整。這讓維護合約從純粹的成本因素轉變為營收驅動力。
12. 12 安全更新與即時回滾保證 gemini-3.6-flash · 鄰近方案 · 11/20 分（5 + 6） CI/CD 維護合約的變體：維護合約純粹聚焦於保證零停機的 SLA，並在發生事故時於 15 分鐘內自動快照還原。這直接回應客戶在兩次安全事件後的擔憂，且持續的手動工作量極少。
13. 13 營收分潤成長方案，而非固定預算 gemini-3.6-flash · 打破規則 · 9/20 分（4 + 5） 打破 25,000 歐元一次性重建預算僵化的軟性假設：重建成本降至 10,000 歐元，並搭配每月維護合約與少量額外營收分潤。這之所以划算，是因為客戶降低了投資風險，而代理商直接參與這個 120 萬歐元商店的成長。
14. 14 無頭架構照護服務 gemini-3.6-flash · 打破規則 · 7/20 分（3 + 4） 打破經典單體架構（例如標準 WooCommerce）的軟性限制：前端與後端解耦，因此外掛安全漏洞無法再直接攻擊網站。這之所以划算，是因為緊急狀況在結構上被消除，且客戶憑藉開源技術堆疊與完整的 Git 存取權，隨時保持可攜性。
15. 15 每月一頁照護報告 claude · 符合需求 · 6/20 分（4 + 2） 每月一頁的報告，包含正常運行時間、頁面速度、已套用的更新與已預防的事故，讓客戶看到維護合約的價值所在。

我們的新訂購頁面下個月上線。與 Kirat 一起腦力激盪，如何在沒有付費廣告的情況下獲得更多蛋糕預訂。

kirat_brainstorm 詢問了議會

議會提出了 15 個想法，並對每個想法進行了匿名評分。前三名：

1. 年度生日自動駕駛（18/20 分）
2. 真正的蛋糕時段，而非一般貼文（17/20 分）
3. 蛋糕作為自身的廣告媒介（16/20 分）

幕後

kirat_brainstorm Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_BRAINSTORM · 投入程度：標準 · 15 個想法 · 1 輪 · $0.09

主題： 一家本地烘焙坊如何透過新的線上訂購頁面獲得更多客製蛋糕預訂，且不使用付費廣告的想法

傳送的背景資訊： 位於德國一座 4 萬人口城鎮、有 6 名員工的烘焙坊。客製蛋糕與預訂的利潤最高。新的線上訂購頁面（蛋糕選擇、取貨日期、預付款）下個月上線；到目前為止，訂單僅透過電話與電子郵件。Google 商家檔案有 120 則評論、4.7 顆星。店主時間不多，因此想法每週最多只能花 2 小時執行。硬性限制：本季不投放付費廣告。硬性限制：不增加員工。

議會的結果

1. 1 年度生日自動導航 gpt-5.6 · 符合簡報 · 18/20 分（9 + 9） 在結帳時，顧客可自願留下場合與月份，以便隔年收到提醒。系統會在 21 天前自動寄出電子郵件，導向已預填的訂購頁面；如此一來，每筆訂單都會孕育出未來的訂單，無需持續進行顧客開發，且取得的是乾淨的同意。
2. 2 真實蛋糕時段，而非一般貼文 gpt-5.6 · 符合簡報 · 17/20 分（9 + 8） 訂購頁面會顯示未來四週實際剩餘的生產時段，例如「週六仍有 2 個客製蛋糕名額」。每週的 Google 商家貼文會直接連結到這個檢視頁面；更新頁面與發文合計最多只需 20 分鐘，並能創造可信的急迫感，而無需打折。
3. 3 蛋糕本身就是行動廣告媒介 gpt-5.6 · 符合簡報 · 16/20 分（8 + 8） 每個取貨的蛋糕都會附上一張小卡，寫著「重新訂購或客製化這個蛋糕」，並附上對應品項的 QR 碼。切蛋糕時會將卡片明顯展示出來，讓在場的生日或婚禮賓客正好發現訂購的途徑；一組卡片製作一次後，每週幾乎不需額外心力。
4. 4 上線時的一次性蛋糕諮詢時段 gpt-5.6 · 打破規則 · 16/20 分（8 + 8） 上線後的第一個週六會舉辦為期四小時的開放式蛋糕諮詢時段：賓客從樣品卡中挑選口味與風格，然後透過為他們擺放的 QR 碼自行下單。這刻意打破了當週最多兩小時投入的軟性限制；額外的投入很值得，因為真實訂單、觀察到的使用性問題，以及可重複使用的照片與顧客問題都會同時產生——無需額外人力或付費廣告。
5. 5 場合合作夥伴，而非網紅 gpt-5.6 · 符合簡報 · 15/20 分（8 + 7） 兒童遊戲場、攝影師、花店、婚宴場地與會館各會收到一個小型 QR 立牌，導向為其場合預先設定的蛋糕選項。作為回報，烘焙坊會在地方推薦頁面上列出這些合作夥伴；每月五次有針對性的邀約就足夠，且無需佣金與付費曝光。
6. 6 辦公室與社團的蛋糕輪值表 gpt-5.6 · 符合簡報 · 15/20 分（8 + 7） 當地辦公室、診所與社團會獲得一個頁面，可收集多個生日或固定日期，並依序預付。季度輪值表一旦建立，就能將個別場合轉變為可規劃的系列訂單；對外聯繫可限制為每週兩個組織。
7. 7 櫃檯平板上的混合式蛋糕諮詢 gemini-3.6-flash · 打破規則 · 14/20 分（7 + 7） 刻意打破「僅限線上訂購」的軟性限制，在週五提供 1 小時的店內諮詢，期間一起在平板上輸入訂單。這很值得，因為猶豫不決與年長的顧客會逐步被引導至新的線上系統。
8. 8 評論成為決策輔助 gpt-5.6 · 鄰近 · 13/20 分（7 + 6） 作為對最強既有素材的小型重組，從 120 則 Google 評論中挑出十二句有意義的話，搭配相符的蛋糕風格，每項都附上直接訂購連結。如此一來，4.7 顆星不僅作為信任訊號展示，還能協助產品選擇；一次性設定後，該頁面大致無需維護。
9. 9 樣品蛋糕展示搭配商店深層連結 gemini-3.6-flash · 鄰近 · 13/20 分（6 + 7） 在賣場中設置最美麗蛋糕的實體照片牆，每張照片都附有特定的 QR 碼，開啟線上商店中預先選好的同款蛋糕。這是想法 1 的變體：將店內展示與商店中的直接深層連結相連。
10. 10 Google 個人檔案最佳化與自動化評論連結 gemini-3.6-flash · 符合簡報 · 12/20 分（6 + 6） 強大的 Google 個人檔案（4.7 顆星）會補上官方「線上訂購」按鈕，並每週更新一張當季蛋糕照片。取貨時，顧客會透過電子郵件收到範本，內含評論與重新訂購頁面的連結。每週花費不到 30 分鐘。
11. 11 收據與麵包袋上的 QR 碼預告 gemini-3.6-flash · 符合簡報 · 11/20 分（6 + 5） 每張收據與包裝上都會印上醒目的 QR 碼，直接導向線上蛋糕配置器（「在線上為您的慶典規劃夢想蛋糕」）。這能將每日的臨櫃顧客轉化為數位預訂者，且櫃檯無需額外心力。
12. 12 與當地活動場地的 B2B 合作 gemini-3.6-flash · 符合簡報 · 11/20 分（6 + 5） 在當地餐廳、活動穀倉與婚禮規劃師處放置立牌與傳單，附上網站的直接預訂代碼。慶祝的顧客可直接線上預訂蛋糕，而場地則可獲得小額費用補貼或回饋作為回報。
13. 13 托兒所與學校生日行事曆 gemini-3.6-flash · 鄰近 · 10/20 分（4 + 6） 與當地幼兒園合作，透過家長委員會的資訊傳單提供兒童主題蛋糕的固定折扣碼。這是想法 3 的變體：不針對一般 B2B 合作夥伴，而是以自動化方式特別鎖定兒童生日這個高頻場合。
14. 14 每月一次的裝飾蛋糕迷你工作坊 gemini-3.6-flash · 打破規則 · 10/20 分（4 + 6） 刻意打破「每週最多 2 小時」的軟性限制，因為每月會舉辦一次 4 小時的工作坊。這很值得，因為參與者會成為品牌大使、創造熱情的社群媒體內容，並保證透過線上商店下後續訂單。
15. 15 每個蛋糕盒上的訂購連結 claude · 符合簡報 · 8/20 分（4 + 4） 在蛋糕盒與收據上印上訂購頁面的 QR 碼，讓已經買過蛋糕的顧客無需打電話就能為下一個生日重新訂購。

Kirat 給 Claude 的備註： 最佳的打破規則想法僅排名第 4：「上線時的一次性蛋糕諮詢時段」——它刻意打破了軟性限制。在捨棄它之前，先為它做一次最強辯護。

與 Kirat 一起腦力激盪，如何在兩個季度內減少帳務事故，而不將帳務從單體架構中拆分出來。

kirat_brainstorm 向議會提問

議會提出了 15 個想法，並匿名評分每個想法。前三名：

1. 帳務資料表周圍的資料庫防火牆（17/20 分）
2. 可執行的財務不變量（17/20 分）
3. 將事故重播作為發布關卡（17/20 分）

幕後

kirat_brainstorm Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_BRAINSTORM · 投入程度：標準 · 15 個想法 · 1 輪 · $0.06

主題： 在兩個季度內減少由帳務模組造成的生產事故，而不將其抽取為獨立服務的想法

傳送的背景資訊： 8 名工程師的團隊。一個 TypeScript 單體架構，約 60,000 行，一個 Postgres 資料庫，每天部署數次。帳務模組每週變更，並造成最近 8 次生產事故中的 5 次，主要是因為其他模組直接讀寫帳務資料表。團隊中沒有人曾在生產環境執行過分散式系統。管理層希望在兩個季度內減少事故。硬性限制：不重寫帳務模組。硬性限制：帳務的功能開發每週持續進行。

議會的結果

1. 1 計費資料表周圍的資料庫防火牆 gpt-5.6 · 符合簡報 · 17/20 分（9 + 8） 為單體應用程式的計費與非計費程式路徑建立獨立的 Postgres 角色，然後撤銷一般應用程式角色對計費資料表的直接寫入權限。將所有變更操作導向一小組經過審查的預存程序或交易函式，並先加入臨時稽核記錄，以便在不中斷每週功能開發的情況下找出並遷移呼叫方。
2. 2 可執行的財務不變量 gpt-5.6 · 符合簡報 · 17/20 分（9 + 8） 將一小組不變量——例如已定案發票不可變、帳本分錄平衡、費用建立具冪等性，以及狀態轉換有效——在安全可行處編碼為資料庫約束，在不可行處則編碼為排程的生產環境探測。在 CI 中對匿名化的生產形態測試資料執行相同的探測，把事故知識轉化為永久的警戒線，而非大規模擴充測試。
3. 3 以事故重播作為發布關卡 gpt-5.6 · 符合簡報 · 17/20 分（9 + 8） 利用擷取的查詢形態與經淨化的資料列，將這五起計費事故轉化為確定性的重播情境，然後要求每一項計費變更都必須通過這些情境。針對這些確切情境，加入會排列組合重試、重複事件、交易順序與部分失敗的生成式測試，聚焦於失敗鄰域，而非試圖對單體應用程式進行窮盡式覆蓋。
4. 4 以影子模式強制執行計費邊界 gpt-5.6 · 鄰近方案 · 16/20 分（9 + 7） 作為資料庫防火牆風險較低的變體，初期保留現有權限，但記錄每一次觸及計費資料表的查詢，包括其模組、呼叫位置與交易 ID。四週後，將非預期的寫入轉為 CI 失敗，接著逐模組轉為生產環境錯誤；這以分階段強制執行取代立即的權限切換。
5. 5 計費影響範圍切換台 gpt-5.6 · 符合簡報 · 16/20 分（9 + 7） 將有風險的計費行為——而非整個模組——置於伺服器端終止開關與百分比漸進發布之後，並搭配以發票、付款與對帳異常為關鍵的儀表板。每項每週功能都附帶經過測試的關閉路徑，讓應變人員能停用新行為，而不必回退無關的單體應用程式部署，也不必撤銷結構描述遷移。
6. 6 Postgres 結構描述封裝與資料列層級安全性 gemini-3.6-flash · 符合簡報 · 15/20 分（7 + 8） 將計費資料表隔離在專用的 Postgres 結構描述（billing.*）中，並撤銷其他資料庫角色對其的直接寫入與讀取權限。模組僅能透過定義的 SQL 檢視或預存介面存取。這直接在資料庫層面消除了事故的主要原因。
7. 7 計費發布的契約測試與影子管線 gemini-3.6-flash · 符合簡報 · 15/20 分（8 + 7） 在 CI 管線中為所有計費介面建立自動化的消費者驅動契約測試。此外，對關鍵計算的計費變更在生產環境中以影子模式執行，不產生副作用，並自動進行差異檢查。
8. 8 以第二個資料庫作為安全工具 gpt-5.6 · 打破規則 · 14/20 分（7 + 7） 刻意打破「單一 Postgres 資料庫」這項軟性假設，加入一個透過邏輯複寫饋送的唯讀影子資料庫，同時將計費保留在單體應用程式內，並維持主資料庫為唯一寫入者。對兩個資料庫執行新的計費讀取與對帳檢查，在揭露前比較結果，並利用影子資料庫進行鑑識查詢，使事故診斷不會超載或意外變更生產環境。
9. 9 嚴格的模組邊界 lint 檢查與公開 API 門面 gemini-3.6-flash · 符合簡報 · 14/20 分（7 + 7） 透過 dependency-cruiser 引入架構 lint 檢查，在建置步驟禁止其他模組直接匯入計費內部元件。通訊僅能透過單一、型別安全的 BillingFacade 介面進行，使逐漸蔓延的耦合立即被阻擋。
10. 10 計費變更護照 gpt-5.6 · 符合簡報 · 13/20 分（7 + 6） 要求每一項與計費相關的拉取請求都附帶一份機器檢查的護照：受影響的資料表、不變量、遷移相容性、回退路徑，以及一項證明部署後健康的生產查詢。CODEOWNERS 關卡加上 15 分鐘輪值的計費管理員審查，使流程輕量到足以應付每週變更，同時將審查集中在跨模組影響上。
11. 11 為外部模組自動產生唯讀 Postgres 檢視 gemini-3.6-flash · 鄰近方案 · 13/20 分（7 + 6） 結構描述封裝的變體：不進行成本高昂的 API 重構，而是為外部查詢自動提供唯讀 Postgres 檢視。外部模組僅讀取這些穩定的檢視，而直接存取資料表則透過資料庫權限加以封鎖。
12. 12 用於讀取模型的行內非同步事件匯流排 gemini-3.6-flash · 符合簡報 · 12/20 分（4 + 8） 其他模組不再直接查詢計費資料表，而是由計費模組在狀態變更時發送記憶體內事件。接收模組建立自己的本機投影。這在不引入分散式系統的情況下，將讀取存取與計費資料表完全解耦。
13. 13 為計費封裝進行為期兩週的功能凍結 gemini-3.6-flash · 打破規則 · 11/20 分（5 + 6） 打破連續每週功能產出的軟性約束，為期恰好兩週。整個團隊專注於分離資料庫耦合。這項一次性投入為在剩餘 5 個月內持續減少事故數量奠定基礎。
14. 14 每個模組一個資料庫角色 claude · 符合簡報 · 11/20 分（6 + 5） 讓計費擁有自己的 Postgres 結構描述與角色，並撤銷其他模組對計費資料表的寫入權限，使直接寫入在到達生產環境之前就在預備環境中失敗。
15. 15 將資料庫實體分割至第二個 Postgres 執行個體 gemini-3.6-flash · 打破規則 · 9/20 分（3 + 6） 打破單一資料庫架構的軟性約束，但保留單體程式碼。計費資料移至自己的資料庫執行個體，使跨領域的 SQL 聯結在技術上變得不可能。由於程式碼仍為單體，營運複雜度維持在最低。

Kirat 給 Claude 的備註： 最佳的打破規則構想僅排名第 8：「以第二個資料庫作為安全工具」——它刻意打破了一項軟性約束。在捨棄它之前，先為它做一次最強論證。

與 Kirat 一起腦力激盪，我們如何在不削弱審查的前提下，縮短約 3,000 筆記錄的篩選時間。

kirat_brainstorm 向議會提問

議會提出了 14 個構想，並對每個構想進行匿名評分。前三名：

1. 雙人排除關卡（18/20 分）
2. 搭配邊緣案例帳本的校準衝刺（16/20 分）
3. 快速二元主控台，而非微型資料擷取（15/20 分）

幕後

kirat_brainstorm Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_BRAINSTORM · 投入程度：標準 · 14 個構想 · 1 輪 · $0.18

主題： 在不削弱系統性文獻回顧嚴謹度的前提下，縮短約 3,000 筆記錄之標題與摘要篩選所需人力時間的構想

傳送的背景資訊： 衛生服務研究領域的系統性文獻回顧，計畫發表。目前協議：兩位獨立人工篩選者，衝突透過討論解決。人力時間有限。期刊審查者會詢問篩選是如何進行的。漏掉相關研究（錯誤排除）比納入不相關研究更糟。硬性要求：方法必須能依 PRISMA 2020 報告。硬性要求：錯誤排除率不得增加。

議會的結果

1. 1 雙人排除關卡 gpt-5.6 · 打破規則 · 18/20 分（10 + 8） 讓審查者 A 篩選每一筆紀錄，但將 A 判定為納入及不確定的決定直接往前送；審查者 B 只獨立評估 A 所提出的排除項目。唯有兩位人類獨立排除同一筆紀錄時才予以排除，並自動推進所有意見分歧之處，藉此消除大部分的衝突討論。這刻意打破了「兩位人類必須評估每一筆紀錄」這項現行流程的軟性假設；這麼做值得，因為它節省了篩選時間，且在結構上只會容許更多誤納、不會產生額外的誤排，而且很容易在 PRISMA 選擇流程段落中說明。
2. 2 搭配邊界案例清單的校準衝刺 gpt-5.6 · 符合任務要求 · 16/20 分（9 + 7） 獨立對第一批分層樣本進行雙人篩選，解決衝突，並將反覆出現的模糊之處轉化為附有正反例的簡短操作規則。在繼續之前先鎖定規則；唯有納入標準未變更時才保留先導階段的決定，否則重新篩選。這保留了雙人獨立篩選，同時減少後續的審議與衝突解決時間，且校準過程可在 PRISMA 下報告。
3. 3 快速二元介面，而非縮小版的資料萃取 gpt-5.6 · 符合任務要求 · 15/20 分（8 + 7） 為兩位審查者提供一個盲化、以鍵盤操作的介面，僅限於納入、排除或不確定，並始終顯示完整的標題與摘要；將詳細編碼與排除理由延後到全文審查階段。PRISMA 2020 並不要求在標題與摘要階段提供紀錄層級的理由。決策流程維持不變，但可避免的閱讀、點擊與記錄時間得以減少。
4. 4 僅限納入的機器釋放閥 gpt-5.6 · 鄰近方案 · 15/20 分（9 + 6） 作為雙人排除關卡的一步式變體，將 A 所提出的排除項目交由一個經驗證的分類器處理，該分類器只能將紀錄釋放為納入，絕不能將其排除；審查者 B 獨立篩選分類器未釋放的所有紀錄。最終排除仍須兩位人類的決定一致，因此機器錯誤只會增加全文數量，不會造成誤排。在 PRISMA 下報告模型、版本、輸入、閾值、驗證，以及其嚴格僅限納入的角色。
5. 5 非對稱排除篩選 gemini-3.6-flash · 符合任務要求 · 15/20 分（7 + 8） 第一位審查者完整分類全部 3,000 筆紀錄。第二位審查者只檢查第一位審查者所排除的紀錄，以捕捉偽陰性（納入的決定直接接受）。這幾乎將第二位審查者的工作量減半，使誤排風險維持極低，並符合所有 PRISMA 要求。
6. 6 高產出分層直接跳過篩選 gpt-5.6 · 打破規則 · 13/20 分（8 + 5） 預先宣告高產出的子集——例如來自高度特定搜尋區塊的紀錄、已知合格研究的直接後代，或已納入密切相關綜述的紀錄——並將它們全部直接送往全文檢索，不進行標題與摘要的決定。這刻意打破了針對這些紀錄的雙人篩選軟性流程，但不會增加誤排，因為該子集中沒有任何項目被排除；代價是額外的全文處理工作。在 PRISMA 流程圖與選擇方法中明確報告此跳過規則及相應的數量。
7. 7 透過主動學習進行優先排序篩選 gemini-3.6-flash · 符合任務要求 · 13/20 分（5 + 8） 兩位人類篩選者使用主動學習工具（例如 ASReview），將相關的標題／摘要排序到最前面。一旦達到經統計驗證的停止準則（例如連續 500 筆不相關命中），即結束篩選。此程序最多可節省 70% 的時間，能以符合 PRISMA 2020 的方式記錄，並透過演算法校準維持最低的誤排率。
8. 8 篩選前僅做完全比對的去重 gpt-5.6 · 符合任務要求 · 12/20 分（8 + 4） 僅移除經由 DOI、資料庫登錄號或完全正規化的書目比對證明為相同的紀錄；保留中介資料最豐富的副本，並僅標記不確定的近似重複項。接著兩位審查者獨立篩選每一筆剩餘的唯一紀錄，而 PRISMA 報告篩選前移除的重複項。這在不產生排除唯一研究途徑的情況下減少了數量。
9. 9 搭配 AI 安全網的人機串接 gemini-3.6-flash · 鄰近方案 · 12/20 分（5 + 7） 非對稱排除篩選的變體：一位人類篩選者獨自處理所有紀錄，而一個針對最高靈敏度調校的 AI 模型只檢查人類的排除項目。第二位人類僅在出現不一致時進行檢查。這在完整涵蓋的情況下將人力需求降低超過 50%。
10. 10 全自動 AI 第二審查者 gemini-3.6-flash · 打破規則 · 11/20 分（3 + 8） 打破了「必須由兩位人類進行篩選」這項軟性限制。一個大型語言模型（LLM）以零偽陰性提示詞承擔獨立第二審查者的角色。這值得，因為人類工作時間減半，且 LLM 已被證明在摘要篩選中能達到高召回率；PRISMA 2020 明確允許報告 AI 工具。
11. 11 依風險調整的單人篩選搭配信心分診 gemini-3.6-flash · 打破規則 · 11/20 分（5 + 6） 打破了對整個資料集持續進行雙人篩選的軟性限制。若第一位審查者表達高度主觀信心且存在明確的排除理由，則略過第二位審查者；只有不確定的案例進入雙人篩選。這最多可節省 60% 的人力時間，同時因為資源集中在灰色地帶，漏掉研究的風險仍維持最低。
12. 12 先進行校準回合 claude · 符合任務要求 · 11/20 分（6 + 5） 兩位篩選者在主要回合前先篩選相同的 100 筆紀錄，討論每一項衝突並釐清納入標準，使後續的衝突與重讀減少。
13. 13 搭配 AI 分診的二元化快速篩選 gemini-3.6-flash · 鄰近方案 · 10/20 分（4 + 6） 主動學習優先排序的變體：團隊使用簡化的介面進行快速評分（僅點選「納入／不確定」與「排除」）。一個 AI 模型在背景評估不確定項目，並只將邊緣候選項送往深入雙重檢查。大幅降低每篇摘要的認知負荷與閱讀時間。
14. 14 透過比對演算法進行確定性預先過濾 gemini-3.6-flash · 符合任務要求 · 6/20 分（3 + 3） 保守的搜尋篩選器與腳本預先篩除明顯不適合的命中（例如研究設計錯誤或非人類族群）。兩位篩選者僅透過代表性樣本（例如 10%）檢查這些自動排除項目。這以符合 PRISMA 的方式減少需要人工篩選的總量，且不損失靈敏度。

所有想法，完整且依排名順序呈現。Claude 自己的想法以匿名且平等的條件參與。主題與背景以英文送出；成員以德文撰寫的想法在此翻譯。

來自不同領域的五個標題與題目。每位成員撰寫一個版本，Claude 的草稿參與其中，兩位成員匿名評分全部三個版本。選一個。

讓 Kirat 為我的定價頁面撰寫標題版本。最多 8 個字，不要最高級用語。

kirat_create 向議會提問

勝出的版本（17/20 分）：「Get paid without Word—free for 14 days」

我自己的草稿排名第 2；成員匿名評分全部三個版本。

幕後花絮

kirat_create Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_CREATE · 模式：版本 · 投入程度：標準 · $0.03

任務簡述： 為一款小型自由工作者開票工具的定價頁面撰寫標題（每月 19 美元，14 天免費試用）。受眾：目前用 Word 或 Excel 開立發票的自由工作者。目標：讓試用感覺零風險且值得。格式：一個標題，以英文撰寫。

準則： 最多 8 個字 · 具體，不要最高級用語 · 提及節省時間或收到款項 · 不要驚嘆號

議會的結果

1. 1 「Get paid without Word—free for 14 days」 gpt-5.6 · 17/20 分（9 + 8） 直接訴諸 Word 使用者，將收到款項放在最前面，並讓零風險試用具體化。
2. 2 「Send invoices in minutes. Get paid on time.」 claude · 17/20 分（8 + 9） 協調者自己的草稿。
3. 3 「Replace Word and Excel. Get paid days faster.」 gemini-3.6-flash · 14/20 分（7 + 7） 直接針對目前的手動工作流程提供立即的對比，將試用定位為對現金流的快速、零風險升級，而不使用空泛的誇大用語。

讓 Kirat 為我們針對 WooCommerce 家具店的登陸頁面撰寫標題版本。最多 10 個字，不要術語。

kirat_create 向議會提問

勝出的版本（18/20 分）：「Losing furniture buyers to a slow, frustrating WooCommerce store?」

我自己的草稿排名第 3；成員匿名評分全部三個版本。

幕後花絮

kirat_create Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_CREATE · 模式：版本 · 投入程度：標準 · $0.02

任務簡述： 為一家小型數位代理商的登陸頁面撰寫標題，內容關於為經營 WooCommerce 的家具零售商重建商店。受眾：沒有內部開發人員的中型家具店老闆。目標：預約免費商店檢查。格式：一個標題，德國市場但以英文撰寫。

準則： 最多 10 個字 · 點出讀者的痛點，而非代理商 · 不要「headless」或「omnichannel」之類的術語 · 不要最高級用語

議會的結果

1. 1 「Losing furniture buyers to a slow, frustrating WooCommerce store?」 gemini-3.6-flash · 18/20 分（8 + 10） 直接針對老闆最主要的挫折——因商店效能不佳而流失銷售——而不使用技術術語或自我吹捧的代理商語言。
2. 2 「Is your WooCommerce shop turning furniture buyers away?」 gpt-5.6 · 17/20 分（9 + 8） 直接點出核心痛點，並以無術語的方式訴諸家具零售商。
3. 3 「Fewer shop emergencies, more time for your furniture.」 claude · 11/20 分（7 + 4） 協調者自己的草稿。

讓 Kirat 為麵包店新的蛋糕訂購頁面撰寫標題版本。簡短、在地，不像連鎖店。

kirat_create 向議會提問

勝出的版本（19/20 分）：「Your celebration cake, baked here for pickup.」

我自己的草稿排名第 3；成員匿名評分全部三個版本。

幕後花絮

kirat_create Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_CREATE · 模式：版本 · 投入程度：標準 · $0.02

任務簡述： 為麵包店新的自訂蛋糕線上訂購頁面撰寫標題。受眾：至今仍以電話訂購的在地顧客。目標：讓線上訂購感覺簡單且親切。格式：一個標題，德國市場但以英文撰寫。

準則： 最多 8 個字 · 具體，不要最高級用語 · 提及取貨或場合 · 聽起來像在地麵包店，而非連鎖店

議會的結果

1. 1 「Your celebration cake, baked here for pickup.」 gpt-5.6 · 19/20 分（10 + 9） 溫暖、具體且親切：「baked here」感覺在地，而「for pickup」讓線上流程感覺簡單明瞭。
2. 2 「Order your custom birthday cake, pick up fresh.」 gemini-3.6-flash · 16/20 分（8 + 8） 此標題具體點出場合以及取貨，並透過新鮮的承諾傳達在地手工品質，而不使用冷冰冰的陳腔濫調。
3. 3 「Your cake, your date. Order in two minutes.」 claude · 9/20 分（5 + 4） 協調者自己的草稿。

讓 Kirat 為我關於先在單體架構內強化帳務邊界的提案找一個標題。

kirat_create 向議會提問

我自己的草稿勝出（19/20 分）：「Fix billing's boundaries first, split it later if needed」

幕後花絮 kirat_create Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_CREATE · 模式：VARIANTS · 投入程度：STANDARD · $0.02

簡報： 一份內部工程提案的標題：在考慮拆分成獨立服務之前，先強化單體架構中帳務模組的邊界。受眾：8 位工程師與希望減少事故的管理層。目標：讓提案被閱讀並獲得批准。格式：一個標題，英文。

評選標準： 最多 10 個字 · 陳述決策，而不只是主題 · 不用流行術語 · 非工程師也能理解

議會的結果

1. 1 「先修好帳務的邊界，之後有需要再拆分」 claude · 19/20 分（10 + 9） 協調者自己的草稿。
2. 2 「讓帳務保持在一起，但將其隔離以防止事故」 gpt-5.6 · 16/20 分（9 + 7） 此標題陳述了將帳務保留在單體架構中、同時強化其邊界的決策，並將此選擇與減少事故的共同目標連結起來。
3. 3 「在拆分服務之前，先強化目前應用程式中的帳務邊界」 gemini-3.6-flash · 13/20 分（7 + 6） 此標題對方向做出了明確的決策，避免對管理層使用「單體架構」等不必要的術語，並直接回應了穩定性的共同目標。

讓 Kirat 為我們關於以 LLM 作為額外篩選工具的方法論文找一個標題。準確，不誇大。

kirat_create 詢問了議會

勝出的變體（18/20 分）：「健康服務研究中大型語言模型輔助的研究篩選：系統性回顧中額外篩選的一種方法」

我自己的草稿排名第 2；成員們以匿名方式對全部三個進行了評分。

幕後

kirat_create Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_CREATE · 模式：VARIANTS · 投入程度：STANDARD · $0.02

簡報： 一篇方法論論文的標題，內容關於在健康服務研究的系統性回顧中使用 LLM 作為額外篩選工具。受眾：研究人員與期刊審稿人。目標：準確且可引用，不誇大。格式：一個標題，可在冒號後加上副標題，英文。

評選標準： 最多 20 個字 · 點明方法與情境 · 不做超出資料的宣稱 · 不用「徹底改變」等誇大詞彙

議會的結果

1. 1 「健康服務研究中大型語言模型輔助的研究篩選：系統性回顧中額外篩選的一種方法」 gpt-5.6 · 18/20 分（9 + 9） 此標題點明了篩選方法、系統性回顧情境與健康服務研究領域，且未暗示效能或效益。
2. 2 「LLM 作為額外篩選工具：一項健康服務系統性回顧中的前瞻性比較」 claude · 16/20 分（9 + 7） 協調者自己的草稿。
3. 3 「大型語言模型作為健康服務研究系統性回顧中的輔助篩選工具：一項方法學評估」 gemini-3.6-flash · 15/20 分（7 + 8） 此標題精確點明應用領域與方法學，避免觸發性詞彙，並為科學出版情境選擇了務實、可引用的語氣。

標題與名稱皆按原文以英文呈現，符合簡報的要求。Claude 條目中的理由說明是 Kirat 為其加上的標籤。以德文撰寫的理由說明在此已翻譯。

來自不同領域的五份圖像簡報。OpenAI 與 Google 各生成一張圖像，兩位成員以匿名方式對兩張圖像評分。選一個。

讓 Kirat 為我的開票工具登陸頁建立主視覺圖像：一張平靜的居家辦公書桌，螢幕上沒有可讀內容。

kirat_image 詢問了議會

評審團選出了由 gpt-image-2 生成的圖像（18/20 分）。兩位成員以匿名方式對兩張圖像評分。

幕後

kirat_image Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_IMAGE · 模式：VARIANTS · 橫向 · ≈ $0.17

簡報： 一款小型自由工作者開票工具登陸頁的主視覺圖像：早晨整潔的居家辦公書桌，有一台筆記型電腦（螢幕轉開或模糊，沒有可讀的介面）、一杯咖啡與一本紙本筆記本。自然日光，平靜的紀實攝影風格，無文字、無標誌、無人物臉部。

評選標準： 感覺像真實自由工作者的工作空間，而非圖庫辦公室 · 平靜且不雜亂 · 為標題留出平靜的空間 · 無文字、標誌或可讀螢幕

議會的結果

1 gpt-image-2 · 18/20 分（9 + 9）

2 gemini-3.1-flash-image · 13/20 分（6 + 7）

讓 Kirat 為家具店建立一張產品照片：一張實木橡木餐桌與四張椅子，位於真實的客廳中。

kirat_image 詢問了議會

評審團選出了由 gemini-3.1-flash-image 生成的圖像（18/20 分）。兩位成員以匿名方式對兩張圖像評分。

幕後

kirat_image Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_IMAGE · 模式：VARIANTS · 橫向 · ≈ $0.17

簡報： 家具網路商店的產品照片：一張實木橡木餐桌與四張椅子，位於明亮、看起來真實的中歐風格客廳中。自然日光，編輯式室內風格，無文字、無標誌、無人物。

評選標準： 桌子是明確的主體 · 逼真的木材紋理與顏色 · 看起來像真實的家，而非 3D 渲染 · 無文字或標誌

議會的結果

1 gemini-3.1-flash-image · 18/20 分（9 + 9）

2 gpt-image-2 · 17/20 分（8 + 9）

讓 Kirat 為蛋糕訂購頁面建立主視覺圖像：一個裝在盒子裡、準備取貨的生日蛋糕。

kirat_image 詢問了議會

評審團選出了由 gpt-image-2 生成的圖像（17/20 分）。兩位成員以匿名方式對兩張圖像評分。

幕後

kirat_image Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_IMAGE · 模式：VARIANTS · 橫向 · $0.17

簡報： 一家小型在地烘焙坊新推出的客製蛋糕線上訂購頁面的主視覺圖像：一個完成的生日蛋糕放在明亮、看起來真實的家族烘焙坊的木製櫃台上，裝在簡單的紙板蛋糕盒中準備取貨。自然日光，紀實攝影風格，無文字、無標誌、無人物臉部。

評選標準： 看起來像真實的在地烘焙坊，而非連鎖店或圖庫照片 · 蛋糕是明確的主體 · 為標題留出平靜的空間 · 圖像中無文字或標誌

議會的結果

1 gpt-image-2 · 17/20 分（8 + 9）

2 gemini-3.1-flash-image · 7/20 分（4 + 3）

讓 Kirat 為我們關於從單體架構中理清帳務的部落格文章建立封面圖像。抽象且平靜。

kirat_image 詢問了議會

評審團選出了由 gpt-image-2 生成的圖像（16/20 分）。兩位成員以匿名方式對兩張圖像評分。

幕後

kirat_image Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_IMAGE · 模式：VARIANTS · 橫向 · ≈ $0.17

簡報： 一篇關於從單體架構中理清帳務模組的內部工程部落格文章的封面圖像：一幅抽象、平靜的插圖，一個有明確邊界的區塊與一個密集、相互連結的區塊群分開。扁平風格，柔和色彩，無文字、無標誌。

評選標準： 清晰邊界的概念一眼即可辨識 · 平靜，不戲劇化 · 小尺寸下也能運作 · 無文字或標誌

議會的結果

1 gpt-image-2 · 16/20 分（9 + 7）

2 gemini-3.1-flash-image · 10/20 分（6 + 4）

讓 Kirat 為我關於 AI 輔助篩選的研討會演講建立封面圖像。嚴肅，不要機器人。

kirat_image 詢問了議會

評審團選出了由 gpt-image-2 生成的圖像（18/20 分）。兩位成員以匿名方式對兩張圖像評分。

幕後

kirat_image Claude 傳送給 Kirat 的內容

記錄於 2026-10-13 · KIRAT_IMAGE · 模式：VARIANTS · 橫向 · ≈ $0.17

簡報： 一場關於系統性回顧中 AI 輔助篩選的研討會演講的封面圖像：書桌上一疊整齊的印刷研究摘要，部分被分揀到兩個托盤中，柔和的日光，紀實攝影風格。無可讀文字、無標誌、無人物臉部。

評選標準： 嚴肅且科學，不誇大 · 沒有機器人或發光的大腦 · 分揀的概念可見 · 無可讀文字或標誌

議會的結果

1 gpt-image-2 · 18/20 分（9 + 9）

2 gemini-3.1-flash-image · 9/20 分（5 + 4）

AI 生成的圖像，已縮小且未經其他編輯。標示 ≈ 的費用來自平行執行的運行：每次運行自身的圖像費用加上評分呼叫的平均分攤。排名為預選，最終選擇仍由您決定。以德文撰寫的評分在此已翻譯。

02 — 問題

一個模型，一個盲點。

自我審查會自我美化

模型檢查自己的工作時會覺得自己很有說服力。同一個模型的第二輪檢查並非獨立的檢查。

更多輪次並非解決之道

Kirat 在程式碼中、而非提示詞中，將辯論上限設為兩輪。模型無法靠言辭繞過限制。若仍無多數意見，系統會告知您。

不同家族以不同方式失敗

Kirat 讓 Claude、ChatGPT 與 Gemini 面對同一個問題，並向您展示分歧——包括誰持異議，以及原因。

03 — 運作方式

問一次。取得三個立場與一次投票。

步驟 1

您在 Claude 中提問

一如往常，用平實的語言：詢問 Kirat 議會：我的商店該用 Shopify 還是 WooCommerce？也提出你自己的立場。Claude 會為您呼叫 Kirat。

步驟 2

三個獨立立場

ChatGPT 與 Gemini 各自回答，看不到彼此的回答。Claude 以第三位成員的身分提出自己的立場。

步驟 3

一次投票，保留異議

若三者中有兩者意見一致，即為多數意見。您會看到每個立場及其理由，以及誰持異議。若無多數意見，Kirat 會如實告知，決定權在您。

Kirat 也會審查程式碼（每項發現都由另一個模型家族檢查）、為想法排名、評論您的文案並比較圖像。上方的重播展示了這一切。

無需寫程式。您安裝一個 Claude 擴充功能，並在 OpenAI 與 Google 各建立一個 API 金鑰；安裝步驟詳見下方細節。

九項工具與一則錄製的範例呼叫 →

04 — 定價

一次購買，適用於 Claude Desktop 與 Claude Code。

無訂閱、無席次、無需在我們這裡註冊帳號。購買前請確認 Kirat 的執行環境：

Kirat 的執行環境

可運作於

• macOS 與 Windows 上的 Claude Desktop 對話
• 終端機、VS Code 或 Claude Desktop 的 Code 分頁中的 Claude Code
• Claude Code 雲端工作階段，需先為每個雲端環境進行一次性設定 附帶限制：以網路密鑰形式儲存的金鑰會保持不可讀取（在 Team 與 Enterprise 方案中，管理員可能必須加入這些金鑰），環境變數中的金鑰則對所有使用該環境的人可讀取，且每日預算按工作階段計算。

無法運作於

• 瀏覽器中的對話（claude.ai）或 Claude 行動應用程式
• 在雲端執行的 Cowork 任務
• 部分公司環境：以您的 Windows 帳戶登入的代理伺服器（NTLM/Kerberos），以及將 Desktop 擴充功能限制為允許清單的組織 請先詢問您的 IT 團隊。

完整的執行環境說明 · 所有雲端限制

Desktop 擴充功能 + Claude Code 外掛

Kirat

$99

$99 上市價 — 前 50 位購買者

之後為 $149。一次性購買。 一次 ZIP 下載，包含兩種格式。您還需要一組 OpenAI 與一組 Gemini API 金鑰：您提出的內容會傳送給兩家供應商，並由他們按使用量向您收費。

• 01Claude Desktop 擴充功能與 Claude Code 外掛，一次下載
• 02Claude Code 雲端工作階段的設定腳本
• 03全部九項工具：投票、程式碼審查、想法排名、文案評論、圖像比較等
• 04成本控制：每日預算（預設 $5），會攔下可能超出預算的呼叫。此為盡力而為，因此也請在供應商端設定限制
• 05授權供一人使用，涵蓋您自己的裝置與雲端環境
• 06盡可能提供相容性更新——免費，但不保證 可在 Claude Desktop（macOS/Windows）與 Claude Code 中執行；Claude Code 雲端工作階段需一次性設定——不適用於瀏覽器或行動版聊天。執行位置 · 雲端限制

Blueprint

$49

僅含文件——供你使用程式設計代理建置或改寫自己的議會伺服器。使用 Kirat 不需要它。

• 01規格：工具的結構化需求
• 02架構決策，以及每項決策背後的推理
• 03代理可自行核對的驗收清單
• 04本網站數字背後的基準資料

不含程式碼，也不含可安裝的擴充功能。

一次性購買 · 透過 Lemon Squeezy（記錄商家）付款，增值稅於結帳時處理 · 退款：請見條款

API 用量直接向 OpenAI 與 Google 付費，計入你自己的帳戶——依我們的測量，每次議會決策為 $0.02–$0.15。

以下情況 Kirat 不適合你…

• —你只把 Claude 當作瀏覽器或手機上的聊天使用。Kirat 在 Claude Desktop（macOS/Windows）與 Claude Code 中執行，並可在一次性設定後於 Claude Code 雲端工作階段中執行——不在那些聊天中。
• —你需要託管服務或任何形式的支援。
• —你不想要在兩家供應商擁有 API 帳戶與帳單。
• —你每月只做少數幾次決策，且樂於在不同聊天中手動比較答案。
• —你想要聽起來很確定的答案。議會的職責是向你呈現分歧，而有時分歧本身就是答案。
• —你的資料不得傳送至 OpenAI 或 Google。你提供給 Kirat 的一切都會傳送至兩者，計入你的帳戶並受其條款約束。

05 — 問題

購買前。

這與 llm-council 或 PAL MCP 有何不同？

請先看看兩者。llm-council 是開源網頁應用程式；其作者表示它設計上不提供支援。PAL MCP 是免費、開源的 MCP 伺服器，透過終端機安裝；它支援許多供應商，並有自己的共識工具。請查看它們目前的狀態。若其中一個涵蓋你的需求，就用它。

Kirat 的差異在於整體配套：它透過 Claude Desktop 自有的擴充功能對話框安裝，金鑰存放於作業系統的安全儲存區，並附帶有每日上限的預算防護、兩輪上限、領域決勝、背景票據、失敗處理、345 項測試、英文結果欄位，以及以平實語言使用。

完整回答 →

我需要是開發者嗎？

不需要。只要你能安裝 Claude 擴充功能並建立兩把 API 金鑰，就能使用 Kirat。你以平實語言詢問 Claude——問問 Kirat 議會：Postgres 還是 SQLite？也說出你自己的立場。——Claude 便會呼叫工具。

我需要什麼？

macOS 或 Windows 上的 Claude Desktop。它自帶 Node，因此你無需安裝其他東西。或是搭配 Node.js 20 或更新版本的 Claude Code。若使用 Claude Code 雲端工作階段，需對你的雲端環境進行一次性設定（見下文）。

外加一把 OpenAI API 金鑰與一把 Google Gemini API 金鑰，兩者皆需啟用帳單。Kirat 也可只用一把金鑰執行：此時議會只有一位外部成員，且每項結果都會指出缺少的金鑰。

執行費用是多少，有什麼能防止帳單失控？

你依使用量直接向 OpenAI 與 Google 付費。依我們的測量，每次議會決策花費 $0.02–$0.15，視投入等級與輸入大小而定，耗時 8 秒至 3 分鐘。影像生成每次呼叫約 $0.05–$0.20。

預算防護會在每次呼叫前預留最壞情況的成本，並封鎖可能超出你每日預算的呼叫——預設為每個 UTC 日 $5，可調整。它採盡力而為，因此也請在供應商端設定消費上限。kirat_status 會顯示預算與支出，且不產生費用。

完整回答 →

我的資料與金鑰會去哪裡？

**你的資料：**你提供給 Kirat 的一切（問題、背景、程式碼、影像）都會直接傳送至 OpenAI 與 Google，計入你的帳戶並受其條款約束——從你的電腦，或在 Claude Code 雲端工作階段中從你自己的雲端環境，經由 Anthropic 為該環境提供的網路代理。沒有 Kirat 伺服器、沒有在我們這裡的帳戶，也沒有遙測。我們永遠看不到你的金鑰或資料。

**你的金鑰：**你在 Claude 自有的安裝或設定對話框中輸入。Claude Desktop 會將它們存放於作業系統的安全儲存區（macOS Keychain、Windows 認證管理員）。Claude Code 會將它們存放於 macOS Keychain；在 Windows 與 Linux 上則存放於 ~/.claude/.credentials.json，僅你的使用者可讀取。我們建議使用設有消費上限的獨立供應商專案。

**在 Claude Code 雲端工作階段中：**Kirat 在你的雲端環境中執行。你在該處將金鑰存為網路密鑰：Anthropic 的代理會在對外傳送時將它們加入 Kirat 的請求，因此工作階段中沒有人能讀取它們，連 Claude 也不行。在 Team 與 Enterprise 方案中，視你的角色而定，可能需要由組織管理員加入。作為備援，金鑰可設為該環境的環境變數，任何使用該環境的人皆可讀取。

**在你的電腦上：**Kirat 會在你的主資料夾中保留一個資料夾 .kirat，內含每日成本計數器、成本記錄、最近 20 項結果（其中包含你的問題與答案）、委派決策與生成影像的記錄。你可隨時刪除它。電腦上所有 Kirat 工作階段（Desktop 與 Code）共用它。

完整回答 →

Kirat 在 Claude Code 雲端工作階段中如何運作，又有哪些限制？

雲端工作階段——Code 分頁的雲端工作階段、網頁版或行動應用程式中的 Claude Code——在 Anthropic 伺服器上的雲端環境中執行。你電腦上的擴充功能無法觸及它們。因此，你需一次性設定雲端環境：

• 將下載內容中的區塊（cloud/setup-script.txt）貼到該環境設定指令碼的頂端；
• 加入你的兩把金鑰——作為 api.openai.com 與 generativelanguage.googleapis.com 的網路密鑰（在 Team 與 Enterprise 方案中，可能需要由管理員加入；下載內容中的指南有詳細說明）；否則作為環境變數，最好命名為 KIRAT_OPENAI_API_KEY 與 KIRAT_GEMINI_API_KEY，以免與專案自有的 OPENAI_API_KEY 衝突（Kirat 也接受 OPENAI_API_KEY 與 GEMINI_API_KEY）；
• 網路存取：若為 Full，則無需變更；否則設為 Custom（較新應用程式中為 Limited），搭配套件管理員的預設清單，再加上 Kirat 下載主機（若金鑰存於環境變數，還需加上 api.openai.com）。

該指令碼會下載你確切版本的 Kirat、驗證其 SHA-256 校驗和並安裝。這是一次性設定，並非一鍵完成。我們已在雲端容器中測試過。

**限制：**環境變數中的金鑰對任何使用該環境的人皆可讀取（網路密鑰則使其無法被讀取）。每個雲端工作階段都從頭開始，因此 Kirat 的每日預算按工作階段計算——請在 OpenAI 與 Google 設定消費上限；在雲端，它們才是你真正的上限。背景工作與最近結果會隨工作階段結束而消失。環境的網路存取必須允許 Kirat 下載主機，若你的金鑰是環境變數，還須允許 api.openai.com（Gemini 已涵蓋於預設清單中）。若設定失敗，工作階段仍會啟動，只是沒有 Kirat——且失敗狀態可能會對新工作階段保持快取，直到你編輯設定指令碼（任何變更都會使新工作階段重新執行它）。

設定指令碼中的下載位址與 ZIP 一樣屬於你購買內容的一部分；請勿公開。授權涵蓋你自己的雲端環境。與他人共用的雲端環境，每人皆需一份授權。

完整回答 →

它使用哪些模型？若供應商淘汰某個模型怎麼辦？

預設為 OpenAI 的 gpt-5.6 與 Google 的 gemini-3.6-flash，並以 Claude 作為第三位投票者。

模型名稱與價格皆為設定。若供應商淘汰某個模型，你輸入新名稱及其兩項價格即可。無需更新。

Claude Desktop 顯示該擴充功能未經 Anthropic 驗證。這是問題嗎？

該警告是預期中的。Claude Desktop 對從檔案安裝的擴充功能會顯示此警告，而 Kirat 是從檔案安裝——它未經 Anthropic 驗證或簽署。

更新如何運作？

在 Claude Desktop 中，以與第一次相同的方式安裝新的 .mcpb。你的金鑰與設定會保留。

相容性更新在可能時免費提供，但不保證。較大的新版本可能另行販售。

我能獲得支援嗎？

不能。Kirat 不提供支援、安裝協助或諮詢。付款與收據由 Lemon Squeezy 處理。若 Kirat 無法在受支援的設定中執行，你會獲得退款；請見條款。

授權允許什麼？

一人，可在你自己的任意數量裝置與你自己的雲端環境中使用。與他人共用的雲端環境，每人皆需一份授權。不得轉售，不得再散布。Kirat 是專有軟體，並非開源。

將議會產出的內容用於你自己的工作（包括商業工作）是可以的。完整條款見條款。

Blueprint 是做什麼用的？我需要它嗎？

使用 Kirat 不需要它。Blueprint 是給想要使用程式設計代理建置或改寫自己議會伺服器的人。

它僅含文件——不含程式碼，也不含可安裝的擴充功能：規格（工具的結構化需求）、架構決策及每項決策背後的推理、代理可自行核對的驗收清單，以及本網站數字背後的基準資料。沒有組合價。

06 — 細節

細節，供存查。

安裝、Kirat 執行所在的所有位置與雲端限制、九項工具，以及數字背後的證據。按需展開。

安裝 Kirat 並連接你的 API 金鑰

Kirat 不是你要註冊的服務。它在你的電腦上（或你自己的 Claude Code 雲端環境中）、Claude 之內，使用你自己的 API 金鑰執行。沒有 Kirat 伺服器，也沒有在我們這裡的帳戶。你提供給 Kirat 的一切都會直接傳送至 OpenAI 與 Google，計入你的帳戶——從你的電腦，或在 Claude Code 雲端工作階段中從你自己的雲端環境，經由 Anthropic 為該環境提供的網路代理。我們永遠看不到你的金鑰或你的問題。

**剛購買 Kirat？**請依照逐步設定指南：先確認你使用哪種 Claude，然後只做對應的步驟。

步驟 1 · 較慢的部分

兩把 API 金鑰

一把 OpenAI API 金鑰與一把 Google Gemini API 金鑰，兩者皆需啟用帳單。這裡耗時的是供應商的註冊與帳單表單。使用設有消費上限的獨立供應商專案是個好主意。

最小權限（選用）：在 OpenAI，受限金鑰即足夠，「List models」設為 Read、「Model capabilities」設為 Request，其餘皆設為 None。來自 Google AI Studio 的 Gemini 金鑰已限制於 Gemini API；來自 Google Cloud 主控台的金鑰請限制於 Generative Language API。

已有兩把金鑰？前往步驟 2。

步驟 2

安裝

**Claude Desktop：**解壓縮下載內容。開啟 Settings → Extensions → Advanced settings → Install Extension…，然後選擇 .mcpb 檔案。在對話框中輸入兩把金鑰。Desktop 自帶 Node，因此無需安裝其他東西。

**Claude Code：**解壓縮下載內容，並將解出的 kirat 資料夾移至你的主資料夾，使 ~/kirat/claude-code 存在。然後執行下列指令。需要 Node.js 20 或更新版本。

**Claude Code 雲端工作階段：**對你的雲端環境進行一次性設定，並有其限制——見下文。

步驟 3

詢問

檢查安裝：使用 Kirat 擴充功能並呼叫 kirat_status。它也會免費向 OpenAI 與 Google 檢查兩把 API 金鑰。

然後問一個真正的問題：問問 Kirat 議會：Postgres 還是 SQLite？也說出你自己的立場。 或從範本開始：在 Claude Desktop 中，從訊息方塊的 + 按鈕開始；在 Claude Code 中，則使用外掛程式 /kirat:decide、/kirat:review、/kirat:critique 或 /kirat:brainstorm。在 Claude Code 雲端工作階段中，它們分別稱為 /mcp__kirat__decide、/mcp__kirat__review、/mcp__kirat__critique 和 /mcp__kirat__brainstorm。

# in Claude Code, once ~/kirat/claude-code exists
/plugin marketplace add ~/kirat/claude-code
/plugin install kirat@kirat
# enter both keys when asked; to change them later:
/plugin configure kirat@kirat

Claude Desktop 會警告此擴充功能未經 Anthropic 驗證。對於從檔案安裝的每個擴充功能，這項警告都是預期中的——請參閱常見問題。

它的執行方式、完整說明，以及雲端限制。九個工具與一筆已錄製的範例呼叫

您以自然語言提問。Claude 負責發起呼叫：

// a real call and a real answer — nothing staged
kirat_vote({
  question: "Cap the coupled effort default, or leave it at maximum?",
  options: ["cap at high", "decouple", "leave as is"],
  ownPosition: { position: "cap at high", reasoning: "…", confidence: 72 }
})
→ outcome:       "completed"
  decision:      "cap at high"
  decisionPath:  "unanimous"
  rounds:        1
  votes:         openai 94, gemini 92,
                 claude 72
  cost:          $0.021

其他結果：needs_human（未達多數——由您決定）、domain_decision、limited、budget_exhausted。信心值為各模型自行回報。

圖 6.3 — 零件清單

Claude 呼叫的九個工具

7 個需 API 費用 · 2 個免費

位置	工具	功能	API 費用
01	kirat_vote	以投票做決策：每位成員先表明立場，接著由三分之二多數、領域負責人或 needs_human 決定。	API 費用
02	kirat_review	程式碼審查。每項發現都會由另一個模型家族驗證。	API 費用
03	kirat_create	評論您的草稿、讓成員撰寫草稿，或為簡短變體排名。	API 費用
04	kirat_brainstorm	三條軌道上的發散構想——符合簡報、鄰近延伸、打破規則——以匿名方式排名。	API 費用
05	kirat_decide	針對可逆工作選擇的委派決策，具備否決權與每日上限。	API 費用
06	kirat_ask	只詢問一位成員。不經議會。	API 費用
07	kirat_image	由兩家供應商生成圖像，並由匿名評審團評分。	API 費用
08	kirat_result	取得背景工作與近期結果。	無
09	kirat_status	預算、支出、可用成員、設定、免費金鑰檢查。	無

「API 費用」是指該工具會使用您自己的金鑰呼叫 OpenAI 與 Google，您需直接向這些供應商付費。上方的重播顯示每次執行的費用。Kirat 本身不按次收費：您只需購買一次。kirat_image 與圖像輸入可搭配您電腦上的檔案運作，因此最適合 Claude Code。

證據：已錄製的決策、實測成本、有記錄的失敗