stockClaw-yingyan

適用場景

• 使用者只發送股票名稱或股票程式碼
• 使用者傳送"股票名稱/股票程式碼 + 行情"
• 使用者傳送自然語言選股條件，想搜尋某一類股票
• 使用者要查詢今天有哪些漲停股
• 使用者要接收即時監控訊號推送

輸入規則

1. 如果訊息只包含股票名稱或股票程式碼，呼叫 POST /api/openclaw/stock/message
2. 如果訊息包含"行情"關鍵詞，呼叫 POST /api/openclaw/stock/message
3. 如果訊息是自然語言選股條件，呼叫 POST /api/openclaw/stock/query
4. 如果使用者明確要查詢漲停股股票列表，呼叫 GET /api/openclaw/stock/limit-up
5. 如果要接收即時訊號推送，先呼叫 GET /api/openclaw/stock/monitor/stream 獲取 WebSocket 連線模板

自然語言 AI 搜股意圖識別

滿足以下特徵時，應優先判斷為"自然語言 AI 搜股"：

• 使用者在描述一類股票，而不是單隻股票，例如："漲幅超過 8% 的科技股"、"換手率高的深圳股票"、"近 20 日漲幅靠前的半導體股票"
• 使用者帶有篩選、排序、區間、排除、前 N 名等表達，例如："大於"、"小於"、"區間"、"按漲幅排序"、"取前 20 只"、"剔除 ST"
• 使用者意圖是"找股票列表"，而不是生成單隻股票量化圖，也不是診斷單隻股票行情

不要誤判為自然語言 AI 搜股的場景：

• 純股票名稱或程式碼：如 平安銀行、000001
• 明確包含"行情"並指向單隻股票診斷：如 平安銀行行情
• 明確要求查詢"漲停股"、"今日漲停股票"、"今天漲停股有哪些"
• 僅要求連線即時監控、訂閱監控訊號

憑證持久化（config.json，必讀）

本 Skill 目錄下與本檔案同級的 config.json 中設有物件 openclawCredentials，包含三個字串欄位：

讀取順序（每次呼叫前執行）

1. 讀取 config.json 的 openclawCredentials.user_id、openClaw_api_key、monitor_api_key（僅含空格的字串視為未配置）。
2. 若使用者在當輪對話中提供了新憑證（貼上 key、更換賬號等），以當輪值為準，並寫回 config.json（見「寫回規則」）。
3. 合併：檔案中的非空值為預設；當輪使用者輸入覆蓋對應欄位。
4. HTTP 能力（規則 1～4 及 rating-changes-to-await）：合併後 user_id 與 openClaw_api_key 均須為有效 12 位字母數字，方可請求；滿足後不得再索要這兩項。
5. WebSocket 即時監控（規則 5）：除 user_id 外，還須 monitor_api_key 有效；若使用者要連監控但該欄位空，單獨提示其到會員中心「開放API」→「監控訊號」儲存 Key，不要與 OpenClaw Key 混淆。
6. 強約束（防重複索要）：只要 user_id + openClaw_api_key 已有效，呼叫 HTTP 介面時禁止以新會話、換話題等理由再次索要；monitor_api_key 同理——僅在使用者要連 WS 且該欄位缺失/無效時再提示。

寫回規則（持久儲存）

• 首次湊齊必填項或使用者主動更新任一欄位後，將當前合併結果寫回 config.json 的 openclawCredentials（user_id、openClaw_api_key、monitor_api_key 按需更新），保留其餘頂層鍵不變；合法 JSON，勿寫多餘註釋。
• 後續會話優先讀檔案。

使用者修改憑證

1. 對話中修改：使用者貼上新 Key 或新 user_id 時，覆蓋對應欄位並寫回 config.json；未提及的欄位保留原 config。
2. 手動編輯 config.json：下次執行須以檔案為準，勿因對話未出現而重複索要。

HTTP 與 URL 中的 apikey 名對照（避免搞混）

• POST/GET 的 JSON 或 Query 引數名統一叫 apikey，其值 = 合併後的 openClaw_api_key。
• WebSocket URL 查詢引數名也叫 apikey，其值 = 合併後的 monitor_api_key（與 HTTP 不是同一把 Key 時兩者不同）。

仍缺必填憑證時的提示（user_id / openClaw_api_key）

僅在 user_id 或 openClaw_api_key 缺失或非法時提示（與是否使用監控無關）：

使用股票量化圖、行情問答、自然語言搜股或漲停查詢前，必須配置 user_id 與 openClaw_api_key（均為 12 位 OpenClaw Key 對應會員中心「OpenClaw」卡片）。

獲取方式：鷹眼量化網站「使用者中心」→「開放API」：https://yingyan.chatface.com/

配置後我會寫入本 Skill 的 config.json（openclawCredentials），之後 HTTP 呼叫無需重複填寫。

僅缺監控 Key 時的提示（要連 WebSocket 時）

當用戶明確要求即時監控，但 monitor_api_key 為空或無效時：

連線即時監控還需要「監控訊號」API Key（會員中心「開放API」頁面第一個卡片）。若你不需要 WebSocket 推送，可忽略此項。

請配置 monitor_api_key 後寫入 config.json，或到上述頁面儲存監控 Key 後再試連線。

鑑權失敗時

• HTTP 報錯多與 openClaw_api_key 或 user_id 不一致有關，請核對會員中心 OpenClaw 卡片。
• WebSocket 關閉碼 1008 等多與 monitor_api_key、會員等級或 monitor.html 許可權有關，請核對 監控訊號 Key 與許可權。

呼叫約定

（以下請求體中的 apikey 取值均為合併後的 openClaw_api_key，欄位名與 HTTP API 一致。）

1. 量化圖

請求：

{
  "message": "平安銀行",
  "user_id": "your_user_id",
  "apikey": "YOUR_OPENCLAW_12_CHAR_KEY"
}

處理規則：

• intent=chart：返回量化圖 URL
• ok=false：讀取 error.code 與 error.message

2. 行情問答

請求：

{
  "message": "平安銀行行情",
  "user_id": "your_user_id",
  "apikey": "YOUR_OPENCLAW_12_CHAR_KEY"
}

處理規則：

• intent=market_query：返回結構化 TDX 截面資料、system_prompt、user_prompt
• 收到響應後，你（OpenClaw 大模型）必須使用返回的 system_prompt 和 user_prompt 來生成趨勢診斷
• ok=false：讀取 error.code 與 error.message

3. 自然語言 AI 搜股

請求：

{
  "query": "漲幅超過8%的半導體股票，按換手率從高到低排序，取前20只",
  "user_id": "your_user_id",
  "apikey": "YOUR_OPENCLAW_12_CHAR_KEY"
}

處理規則：

• 呼叫 POST /api/openclaw/stock/query
• 該能力參考 web/query/queryFundamentals.html 的自然語言理解思路，但不要複用網頁端 POST /api/query/tdx 介面
• OpenClaw 場景只返回輕量結果，最多 20 只
• 返回結果僅允許包含以下欄位：
  • 程式碼
  • 名稱
  • 漲幅%
  • 現價
  • 漲跌
  • 換手%
  • 細分行業
  • 活躍度
  • 連漲天
  • 昨漲幅%
  • 3日漲幅%
  • 5日漲幅%
  • 10日漲幅%
  • 20日漲幅%
  • 60日漲幅%
  • 一年漲幅%
  • 月初至今%
  • 年初至今%
  • 近日指標提示
• OpenClaw 應直接把結構化股票列表返回給使用者；如果介面同時返回摘要欄位，可優先使用摘要，再附表格結果
• ok=false：讀取 error.code 與 error.message

4. 漲停股專用查詢

請求：

GET /api/openclaw/stock/limit-up?user_id=your_user_id&apikey=YOUR_OPENCLAW_12_CHAR_KEY

處理規則：

• 當用戶明確要查"今天漲停股有哪些"、"漲停股票列表"時，優先呼叫該專用介面
• 不要把這類請求誤走通用自然語言搜股 POST /api/openclaw/stock/query
• 該介面按股票程式碼和名稱對應的漲停閾值識別結果：主機板約 10%，創業板/科創板約 20%，北交所約 30%，ST 約 5%
• 返回結果為結構化股票列表，可直接展示給使用者

5. WebSocket 即時監控

請求：

GET /api/openclaw/stock/monitor/stream?user_id=your_user_id

處理規則：

• 返回 ws_url_template，模板中查詢引數名為 apikey、user_id（佔位符可能寫作 {apikey} 與 {user_id}）
• URL 中的 apikey 必須填入 monitor_api_key（監控訊號 Key），不要填 openClaw_api_key
• user_id 填合併後的使用者 ID
• 連線地址示例：wss://yingyan.chatface.com/ws/monitor/open?apikey=<monitor_api_key>&user_id=<user_id>
• 連線成功後將持續接收監控訊號變化推送（JSON 陣列格式）
• 每條推送包含：ticker（程式碼）、name（名稱）、prev_rating（原評級）、latest_rating（新評級）、close（現價）、zhangdie（漲跌幅比例）、latest_time（時間）
• 訊號過濾：當評級變為 await（等待）時，服務端不會推送通知，僅推送有實際買賣意義的訊號變化

6. OpenClaw 自然語言 AI 搜股的執行要求

• 若使用者輸入明顯是選股條件，應呼叫 POST /api/openclaw/stock/query，不要誤走單股量化圖或單股行情診斷。
• 搜股介面返回的是股票列表，不是自由發揮的分析長文；應以結構化結果為主。
• 預設最多返回 20 只股票；即使使用者要求更多，也應以介面上限為準。
• 不要自行擴充返回欄位，嚴格使用介面定義的固定欄位集合。
• 可識別的意圖包括：漲幅篩選、換手率篩選、區間篩選、行業篩選、地區篩選、排序、前 N 名、排除 ST、排除北交所、排除科創板、排除創業板等。
• 如果使用者明確要的是"漲停股列表"，應改走漲停股專用介面，而不是通用搜股介面。

7. OpenClaw 連線即時監控的推薦執行順序

當用戶要求"連線即時監控"、"配置 WebSocket 監控"、"接收即時監控訊號"時，OpenClaw 應按以下順序執行：

1. 確認合併後的 user_id、monitor_api_key 均有效；若缺 monitor_api_key，使用上文「僅缺監控 Key 時的提示」，不要用 openClaw_api_key 冒充監控 Key。
2. （可選）用 user_id + openClaw_api_key 呼叫一次 POST /api/openclaw/stock/message 驗證 HTTP 憑證；此步不能代替監控 Key 校驗。
3. 呼叫 GET /api/openclaw/stock/monitor/stream 獲取 ws_url_template。
4. 將模板中 apikey 佔位替換為 monitor_api_key，user_id 佔位替換為真實 user_id，再建立 WebSocket。
5. 優先使用原生 WebSocket 客戶端能力建立連線，不要把安裝 wscat、websocat、curl WebSocket 外掛當成預設流程。
6. WebSocket onopen 或等價握手成功後，就應判定為"即時監控連線成功"。
7. 連線成功後保持等待；如果暫時沒有收到任何訊息，不能據此判定失敗。

8. OpenClaw 在即時監控場景下的強約束

• 不要預設先嚐試安裝或呼叫 wscat、websocat、curl 特殊模式；這些只可作為人工排障兜底方案，不是首選接入路徑。
• 若平臺本身支援 WebSocket 客戶端，應直接連線 ws_url_template 替換後的正式地址。
• 服務端不會在連線建立後主動傳送歡迎包、首包或心跳說明；連線後暫時沉默是正常現象。
• 只有監控訊號發生變化時，服務端才會推送 JSON 陣列訊息。
• 當最新評級變為 await 時，服務端不會推送，所以"已連線但暫時無訊息"通常代表當前沒有有效買賣訊號變化。
• 如果連線被關閉且關閉碼為策略拒絕（常見為 1008），應優先檢查：monitor_api_key 是否與會員中心「監控訊號」Key 一致、user_id 是否正確、會員狀態是否有效、會員等級是否滿足 monitor.html 許可權要求（不要用 OpenClaw Key 連監控 WS）。

9. 連線成功後的使用者反饋要求

• 一旦握手成功，應明確告訴使用者："WebSocket 連線已成功建立，當前正在等待即時監控訊號。"
• 如果幾秒到幾十秒內沒有推送，應補充說明："這是正常現象，服務端只在監控訊號變化時推送。"
• 如果收到 JSON 陣列訊息，再把結構化內容轉述給使用者。
• 如果連線失敗，不要籠統說"連線異常"；要優先說明最可能的鑑權或許可權原因。

返回處理

• 如果返回 image_url，直接把圖片 URL 返回給使用者
• 如果返回 render_markdown，優先把它作為聊天渲染內容返回給客戶端
• 如果返回 system_prompt 和 user_prompt，按照下方"行情問答提示詞"完成分析並返回
• 如果返回自然語言搜股結果，優先返回精簡表格或結構化列表，保留欄位順序與介面一致
• 如果返回 candidates，提示使用者從候選股票中進一步明確程式碼或名稱

行情問答提示詞

當 intent=market_query 時，API 返回 system_prompt 和 user_prompt 欄位。你應按如下方式使用：

系統提示詞（system_prompt）

你是一個只基於給定 TDX 股票欄位和規則摘要進行推理的 A 股趨勢診斷器。

任務邊界：
1. 只能使用輸入中明確提供的欄位、數值和規則側摘要，不得虛構新聞、公告、財報細節、資金流細節或 K 線結構。
2. 若訊號互相沖突、欄位缺失較多、估值無法判斷或趨勢不穩，必須主動降低置信度並說明原因。
3. 趨勢判斷只能使用"偏強 / 震盪 / 偏弱"等機率性語言，禁止"必漲""一定反轉""穩健翻倍"等絕對化表述。
4. 分析重點是未來短期（1-2 周）與中期（1-3 個月）的趨勢傾向、觀察條件和風險，不要寫成長篇泛化研報。
5. 如果某個結論的支撐不足，就明確說"當前證據不足"，不要硬給結論。

輸出要求：
- 使用 Markdown。
- 嚴格按照以下標題輸出，不要改標題名：

## 趨勢判斷
- 短期趨勢：...
- 中期趨勢：...
- 置信度：高 / 中 / 低，理由...

## 關鍵依據
- ...
- ...

## 風險與反證
- ...
- ...

## 操作建議
- ...
- ...

## 免責宣告
- 僅基於最新 TDX 截面資料生成，不構成投資建議。

寫作要求：
- 先結論，後依據。
- 每條依據儘量引用具體欄位名和數值。
- 風險部分必須包含至少一個反證點；如果暫未發現極端風險，也要寫"當前未見明顯極端風險，但仍需繼續觀察 xxx"。
- 操作建議要與趨勢和置信度一致，避免一邊說高波動一邊給出激進追漲建議。

使用者提示詞（user_prompt）

API 會返回基於 TDX 截面資料自動構建的使用者提示詞，包含以下結構化資訊：

• 診斷物件（股票名稱、程式碼、行業、地區）
• 規則側預判（短期趨勢、中期趨勢、置信度、可用訊號數、主要衝突）
• 行情快照（現價、漲幅、今開、最高、最低等）
• 短線動量訊號（漲幅、量比、換手率、近日指標提示等）
• 中線趨勢訊號（20/60 日漲幅、強弱度、連漲天等）
• 資金與基本面訊號（主力資金、估值、財務概況等）
• 已識別風險

請直接將 user_prompt 作為使用者訊息，配合上方系統提示詞完成趨勢診斷。

參考資料

小蔥技能站7w4.net發現了升級外掛。

• 介面欄位說明見 reference.md
• 呼叫示例見 examples.md

這個 Skill 功能做得比較完善，股票量化圖、行情問答、自然語言搜股和即時監控都有覆蓋，文件示例也比較豐富。不足之處是配置流程稍顯複雜，需要填寫 user_id 和 OpenClaw Key 兩個憑證，且不同功能可能要用不同的 Key，新手容易混淆。整體質量中上，但首次上手需要花點時間理解配置邏輯。