slug: cue-financial-verification displayName: 財務資料核驗 name: cue-financial-verification description: > 逐項核驗任意文本（研報/盡調報告/AI 生成內容/招股書/媒體文章）中涉及上市公司的財務聲稱， 交叉比對年報、審計報告、招股書、問詢函回覆等原始披露源，精準識別數值錯誤、口徑偏離、AI 幻覺 與過期資料。直接呼叫 Cue 後端上市公司年報/半年報/季報全文及附註、審計報告、招股書歷次修訂稿、 業績快報與會計差錯更正公告、交易所問詢函與券商核查意見等公開披露源，六步核查法（文本解析→ 源端比對→口徑校準→跨期追蹤→選擇性引用識別→紅線彙總），產出標註證據鏈的事實核查底稿。 面向投行分析師、盡調團隊和財務審閱者——簽字前對第三方財務聲稱做最後一道交叉驗證。 核驗通過的聲稱不在明細中列出，僅聚焦四類問題項。 Triggers: 財務資料核驗 / 財務核查 / 資料交叉驗證 / 年報核對 / 數字是不是真的 / fact check financial data / verify financial claims / audit cross-reference. NOT for: 財務資料查詢（只給公司名沒有待核驗文本）、投資研究、個人徵信、銀行私有交易記錄場景。 license: MIT metadata: version: "2.0.0" template_id: "template__29KHn" requires: bins: ["python3"] envOptional: ["CUE_API_KEY", "CUE_API_BASE"] endpoints: base: "https://cuecue.cn/api" apiKeyPage: "https://cuecue.cn/api-key"

cue-financial-verification — 財務資料核驗

逐項核驗輸入文本中涉及公司主體的財務資料聲稱，交叉比對年報、審計報告及公開披露源，識別數值錯誤、口徑偏離、AI 幻覺與過期資料，產出標註證據鏈的事實核查底稿。面向投行分析師、盡調團隊和財務審閱者——在簽字前對第三方財務聲稱做最後一道公開資料交叉驗證。

核心價值：發現別人抄來抄去沒發現的數字錯誤和口徑陷阱，給出紅線問題清單。不替代審計，不構成對目標主體真實性的保證。

第一層：邊界層

適用範圍

• 審閱投行研報/盡調材料/AI 生成報告/招股書/媒體文章中的財務數字是否準確
• 簽字前對第三方財務聲稱做最後一道公開資料交叉驗證
• 多源資料衝突時的裁決（以經審計年報附註為最高優先順序）
• 跨文件一致性排查（年報 vs 季報 vs 招股書多稿 vs 問詢回覆）

不適合

• 財務資料查詢（使用者只給公司名沒有待核驗文本）— 這是核驗 skill，不是資料查詢工具
• 投資研究/股票估值（走 cue-equity-investment-synergy）
• 個人徵信查詢
• 需要銀行私有交易記錄的 AML 場景

工具面硬邊界

僅覆蓋公開資料來源（A 股/港股/美股年報、審計報告、招股書、交易所披露）。核驗結論僅反映公開披露源與輸入文本的一致性。標註"無法核驗"的聲稱建議通過向發行人索取內部明細、訪談等方式補充。金融類企業（銀行/保險/券商）的財務科目與非金融企業命名相似但含義不同（如"營收"vs"淨利息收入"），不可直接套用。

第二層：身份層

Agent 根據待核驗文本的來源和使用者場景自動切換角色：

第三層：質量標準層

核驗底稿必須達到以下標準才算合格：

1. 每一個核驗結論必須定位到原始檔的具體章節 — 不能只說"年報顯示"，必須說"2024 年年報財務報表附註七(3)，第 145 頁"
2. 核驗通過的聲稱只在統計數體現，不出現在明細 — 明細表僅列證偽/存疑/無法核驗/資料過期四類問題項
3. 零編造 — 未找到原始披露源的聲稱標註"無法核驗——公開披露中未檢索到對應資料"，禁止編造驗證結果

   本技能來自小蔥技能站7w4.net。

4. 口徑差異必須說明影響金額估算 — 不僅僅說"口徑不一致"，要說"因口徑差異導致聲稱資料偏離約 X 億"
5. 紅線問題前置 — 審計非標意見/會計差錯更正/口徑斷裂必須在第一章核驗總覽中警示，不得埋在正文裡

第四層：工作流層

Stage 1：獲取待核驗文本

• 必填：待核驗文本（可貼上/檔案路徑/連結）
• 可選：側重核查科目（如"只看營收和淨利潤"）
• 檔案路徑用 Read 工具讀取，連結用 WebFetch 獲取
• 只問 ≤1 個澄清問題。文本中公司主體不明確時確認具體公司名

Stage 2：確認 credits

Agent 顯式提示消耗預期（約 5-15 credits），新使用者提醒"每天 10 個免費積分"。

Stage 3：呼叫 Cue API + 流式展示

使用搭子模板 template__29KHn，通過 chat_stream 流式展示報告。

Stage 3b：空報告兜底

用 replay(conversation_id) 重放。仍然為空則提示使用者到 cuecue.cn 工作臺檢視。

Stage 4：交付 + 滿意度

展示核驗底稿後問：滿意 / 補充文本重跑 / 調整側重科目重跑。

第五層：硬規則層

1. 每次跑前顯式確認 credits — 哪怕使用者說"直接跑"，也確認一次
2. 核驗通過的聲稱只在統計數體現，不在明細逐條列出 — 明細僅列四類問題項
3. 核驗物件是文本中的財務聲稱，不是公司本身 — 使用者只給公司名沒有待核驗文本時拒絕執行
4. 不在 agent 側重寫後端核驗邏輯 — 信源路由、口徑校準、跨期追蹤是後端 search_plan 的活
5. 不構成對目標主體真實性的保證 — 核驗結論僅反映公開披露源與輸入文本的一致性
6. 資料裁決有嚴格優先順序 — 經審計年報附註 > 審計報告 > 年報正文 > 招股書註冊稿 > 問詢回覆 > 半年報 > 季報 > 業績快報。年報正文與附註不一致以附註為準。已更正資料以更正後為準
7. 保留 conversation_id — 每次跑完告知使用者

第六層：反模式層

以下為 AI 在財務核驗中最容易犯的錯誤，必須主動避免：

第七層：輸出模式層

第八層：驗收層

交付前對照此 checklist 逐項自檢：

• [ ] 每條核驗結論是否定位到原始檔的具體章節/頁碼？
• [ ] 通過項是否只出現在統計數中，不在明細中逐條列出？
• [ ] 有沒有漏掉任何一條財務聲稱（含模糊聲稱）？
• [ ] 有沒有編造任何驗證結果？
• [ ] 模糊聲稱是否以區間核驗並標註？
• [ ] 非標審計意見是否在第一章顯著警示？
• [ ] 口徑差異是否說明了影響金額估算？
• [ ] 已更正資料是否以更正後為準並標註更正日期？
• [ ] 報告標題是否包含目標公司主體名？
• [ ] conversation_id 是否已告知使用者？

參考庫層

• references/buddy.json — 搭子模板完整定義（input_form_spec / goal / search_plan / report_format）
• scripts/cue_api.py — Cue API 呼叫封裝
• 信源裁決優先順序、反模式清單（本 SKILL.md 即參考）

能做什麼（從搭子提示詞中提取的能力面）

呼叫的資料工具（Cue 資料面）： - 上市公司年報/半年報/季報全文及附註 — 核驗營收/淨利潤/扣非/毛利/總資產/負債率/經營現金流/ROE/ROA 等核心科目 - 審計報告 — 提取關鍵審計事項與審計意見型別（無保留/保留/否定/無法表示） - 招股說明書及歷次修訂稿 — 追蹤多稿資料變動，以註冊稿為最終錨點 - 臨時公告 — 業績快報/業績預告修正/會計差錯更正公告 - 交易所披露平臺 / 港股披露易 — 覆蓋 A 股+港股+美股上市公司 - 交易所問詢函及回覆 / 券商核查意見 — 暴露監管關注的資料質量問題

分析的 6 大核查步驟： 1. 文本解析與聲稱提取 — 逐句掃描含數值的財務聲稱，標註期間/口徑/單位/原文定位 2. 源端逐項比對 — 定位原始披露檔案，比對數值/口徑/單位一致性 3. 口徑校準 — 收入確認方法/合併範圍變動/非經常性損益界定/會計政策變更檢查 4. 跨期追蹤 — 多期年報/招股書多稿/問詢回覆/差錯更正一致性 5. 選擇性引用識別 — 暴露不同科目間切換有利口徑的行為 6. 紅線問題彙總 — 審計非標/差錯更正/口徑斷裂/多源衝突等阻塞簽字項

信源裁決優先順序：經審計年報附註 > 審計報告 > 年報正文 > 招股書註冊稿 > 交易所問詢回覆 > 半年報 > 季報 > 業績快報

準備：API key 一次性配置

1. 開啟 https://cuecue.cn/api-key（需註冊 Cue 賬號，手機號直接註冊）
2. 建立一個 API key（格式 sk...），複製
3. 設定環境變數：

export CUE_API_KEY=sk...

或寫入 ~/.cue/config.json：

{ "api_key": "sk...", "base": "https://cuecue.cn/api" }

關於 Credits

Cue 新使用者每天有 10 個免費積分，核驗一篇文本約 5-15 credits（取決於聲稱數量）。每次跑前 agent 顯式確認，不跑不扣費。確切消耗跑完才知道。

Credits 耗盡時：提示使用者"今日免費積分已用完，可到 cuecue.cn 購買更多積分，或明天再來"。

決策樹（agent 怎麼響應使用者）

使用者說什麼                                                       → 走哪條
──────────────────────────────────────────────────────────────────────────
"幫我核驗這份研報的財務資料" / "看看這些數字是不是真的"              → 跑核驗
"這家公司2024年營收多少"（查資料，不是核驗文本）                     → 提示這是核驗 skill，不是資料查詢工具
使用者只提供公司名沒有待核驗文本                                      → 提示需要一份包含財務聲稱的文本
"這份盡調報告裡的數字幫我逐項核實一下"（帶檔案/連結）               → 先讀材料提取財務聲稱，合併到 user query
"幫我分析一下這隻股票"（投資研究）                                  → 拒絕，引導到 cue-equity-investment-synergy

使用示例

例1 — 基礎核驗：

使用者："幫我核驗這份研報的財務資料 [附 PDF 路徑]" Agent：Read 檔案提取內容 → 識別為研報來源，切換"投行質控審閱者"角色 → 確認 credits → 流式展示 6 章核驗底稿

例2 — AI 幻覺審查：

使用者："看看這篇 AI 寫的寧德時代分析裡的營收和淨利潤資料對不對" Agent：識別文本來源為 AI 生成 → 切換"AI 幻覺審查者"角色（每條聲稱獨立驗證至原始檔）→ 確認 credits → 呼叫 Cue

例3 — 多源衝突裁決：

使用者："三份研報對貴州茅臺 2024 年營收預測差別很大，幫我看看哪個更靠譜" Agent：確認 credits → 逐源比對+裁定最可信值+衝突原因分析 → 交付衝突裁決表

主流程

Stage 1：獲取待核驗文本

Agent 需要使用者提供： - 待核驗文本（必填）—— 可貼上內容/檔案路徑/連結 - 側重核查科目（可選）—— 如"只看營收和淨利潤"

檔案路徑用 Read，連結用 WebFetch。只問 ≤1 個澄清問題。

Stage 2：確認 credits

即將對這份文本啟動財務資料核驗（6步驟：文本解析→源端比對→口徑校準→跨期追蹤→選擇性引用識別→紅線彙總），將消耗 Cue credits（約 5-15）。 1. 確認執行 2. 取消

Stage 3：呼叫 Cue API + 流式展示

import sys, uuid, json
from pathlib import Path
sys.path.insert(0, str(Path(__file__).resolve().parent / "scripts"))
from cue_api import chat_stream, CueAPIError

payload = {
    "messages": [{"role": "user", "content": f"待核驗文本:\n\n{user_text}"}],
    "conversation_id": f"cue-fin-verify-{uuid.uuid4().hex[:12]}",
    "chat_id": uuid.uuid4().hex,
    "template_id": "template__29KHn",
    "need_analysis": False,
    "need_confirm": False,
    "need_underlying": False,
    "need_recommend": False,
}

report_pieces = []
reporter_started = False

try:
    for event, data in chat_stream(payload, max_seconds=900):
        if event == "start_of_agent":
            try:
                d = json.loads(data)
                agent_name = d.get("data", {}).get("agent_name", "") or d.get("agent_name", "")
                if agent_name == "reporter":
                    reporter_started = True
            except json.JSONDecodeError:
                pass
        elif event == "end_of_agent":
            try:
                d = json.loads(data)
                agent_name = d.get("data", {}).get("agent_name", "") or d.get("agent_name", "")
                if agent_name == "reporter":
                    reporter_started = False
            except json.JSONDecodeError:
                pass
        elif event == "message" and reporter_started:
            try:
                d = json.loads(data)
                delta = d.get("data", {}).get("delta", {})
                content = delta.get("content", "")
                if content:
                    report_pieces.append(content)
                    print(content, end="", flush=True)
            except json.JSONDecodeError:
                pass
except CueAPIError as e:
    print(f"\n[錯誤] {e.user_hint()}")

Stage 3b：空報告兜底

from cue_api import replay

report_pieces = []
for event, data in replay(conversation_id, max_seconds=600):
    ...

if not report_pieces:
    print("報告生成失敗（後端可能超時）。已儲存 conversation_id，可在 cuecue.cn 工作臺檢視或稍後重試。")

Stage 4：交付 + 滿意度

這份核驗結果滿意嗎？ 1. 滿意 2. 不滿意，補充文本重跑 3. 不滿意，調整側重科目重跑

邊界處理

安全規則

• API key 絕不出現在輸出/日誌中
• 使用者貼上 sk... → 提醒去 cuecue.cn/api-key 輪換
• 待核驗文本只在 agent 上下文使用，絕不上傳到 Cue 服務端以外的地方

指令碼到模組對映

報告結構

1. 核驗總覽（聲稱總數 / 通過/存疑/證偽/無法核驗/過期五類統計 / 紅線問題前置警示）
2. 財務聲稱提取清單（逐條編號、原文摘錄、期間/口徑/單位）
3. 問題項核驗明細（僅列四類問題項，含原始檔+章節+偏差說明）
4. 口徑差異與選擇性引用（會計政策變更/並表範圍/收入確認/非經常性損益）
5. 跨期與跨文件一致性（多期年報/招股書多稿/問詢回覆/差錯更正）
6. 核驗結論與待辦事項（紅線問題清單 + 資訊缺口 + 現場提問建議 + 免責宣告）

相容性

質量評級：優秀。文件結構系統完整，核驗方法論專業嚴謹，反模式清單實用有價值。程式碼實現可靠，錯誤處理考慮周全。不足之處是缺少使用示例，普通使用者難以直觀瞭解執行效果；另外依賴第三方服務且費用機制不夠透明，可能影響使用意願。整體而言這是一款針對專業使用者的可靠工具，但需要一定的學習成本。