🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付

為何需要自動化投資分析

我利用 Claude Code Skills 和 yfinance 開發了一套自動化投資分析系統,涵蓋股票篩選到投資組合管理的全過程。透過 Python 和振動編碼技術,這套系統用五項技能來支持個人投資者的整體投資工作流程。

作為個人投資者,在接觸日本股市和美國股市時,尋找「被低估的股票」這項工作實在繁瑣。透過證券公司的篩選器來過濾,再逐一檢查出來的股票,並考慮整個投資組合的平衡——我渴望能找到方法來解決這樣的重複性工作。

如果你向 ChatGPT 或 Claude 的網頁版要求「尋找被低估的股票」,它們會在一定程度上滿足要求。然而,當我想將這些功能整合進投資決策的工作流程時,卻遇到了四個障礙。

  • 回應與資料來源的不穩定性 ── 網頁搜索每個股票需花幾十秒,每次參考的文章也不同,無法用於定點觀察。
  • 上下文的消失 ── 上週的篩選結果和交易根據,在下次會話中卻被遺忘。
  • 缺乏重現性 ── 每次會話中 PER 的閾值或評分會略有不同。在缺乏重現性的系統中,投資決策無法積累。
  • 處理量的障礙 ── 即使請求檢查 10 檔股票,輸出也可能在 3 到 4 檔間停止。儘管全數檢查每一檔股票是有意義的。

Claude Code 的 Skills 解決了這四個問題。

  • 針對回應和資訊來源 → 將邏輯固定於 Python 腳本,並統一使用 yfinance API 來獲取數據。每次都從相同的來源以相同的方式獲取數據。
  • 上下文消失 → 投資組合以 CSV 形式保存,閾值以 YAML 格式保存,設計判斷則持久化至 CLAUDE.md。即使跨會話,上下文也會被延續。
  • 重現性 → 由於篩選邏輯被固定為腳本,因此對於相同的輸入會執行相同的處理。
  • 處理量 → 由於以 Python 過程執行,而非 LLM 的輸出標記,因此沒有限制。即便是一口氣篩選東證所有上場股票(包含大盤、標準盤和成長盤約 1,000 到 2,000 檔)也能在幾十秒內完成。

最初我僅想實現篩選功能。但隨著需求的增長,「我也想要報告」、「還想管理投資組合」、「還需要健康檢查」、「還要進行壓力測試」,結果不知不覺中變成了一個由五項技能組成的系統。

本文將主要介紹這一系統的設計思想、技術選擇及其判斷。

Claude Code Skills 介紹

Claude Code 有一種名為 Skills 的機制,允許用戶自創斜線命令。只需在技能定義文件(SKILL.md)中記錄技能名稱、描述、參數規則及允許的工具,Claude 就能解釋自然語言的輸入並執行腳本。

image

重點是,用戶只需用自然語言交流即可。完全不需要輸入斜線命令。Claude 可以理解用戶的意圖,自動選擇並執行適當的技能。

例如,當我隨意說「尋找日本股票的高股息股票」時,Claude 會根據上下文判斷出篩選技能,恰當設置地區和預設條件來執行腳本。問「我的投資組合狀況如何?」時,便會進行健康檢查。「給我看豐田的報告」時,則會生成該股票的個別報告。

換句話說,Skills 並不是「命令行工具」,而是 Claude 根據情境使用的工具箱。用戶無需記住命令體系,只需在投資的上下文中自然交流,便能讓後台運行適當的腳本。這一「自然語言 → 技能選擇 → 腳本執行 → 結果解讀」的整個流程,正是振動編碼的體驗,與傳統 CLI 工具形成了鮮明對比。

另一個重要點是 重現性。由於邏輯固定於 Python 腳本,因此今天與上個月的篩選可在相同標準下執行,這一點是有保障的。

自動化投資分析的五項 Skills

此次開發的技能有五項。

# 技能 角色
1 篩選 尋找被低估的股票(支援 4 個引擎、7 個預設,yfinance 股票查詢的 60+ 交易所)
2 個別報告 指定股票代碼生成財務分析報告
3 投資組合管理 顯示買賣紀錄、損益、結構分析、健康檢查、預估報酬和再平衡建議
4 壓力測試 使用 8 種情境檢驗投資組合的薄弱環節(集中度、相關性、VaR)
5 觀察名單 管理感興趣的股票列表

這些技能涵蓋了「從篩選發現股票 → 通過報告進行詳細檢查 → 註冊於觀察名單 → 在投資組合中記錄買賣 → 通過健康檢查進行持續監控 → 通過壓力測試了解風險」的整個投資工作流程。

image

系統設計:三層架構與資料持久化

分層原因

系統被分為 Skills 層(介面)→ Core 層(業務邏輯)→ Data 層(資料獲取) 三個層級。

  • Skills 層 僅作為介面,薄層次地解釋參數並調用腳本。
  • Core 層 集中業務邏輯。共配置了 17 個模組,包括篩選引擎、打分、健康檢查、情境分析等,並在五項技能間共享邏輯。例如「變化打分」的計算邏輯便同時被篩選(阿爾法預設)和健康檢查所調用。
  • Data 層 負責統一資料獲取。不直接調用 yfinance,而是必須經由包裝器處理,統一管理緩存(24 小時 TTL)、速度限制(API 間 1 秒延遲)及異常值去除(排除股息率 > 15% 或 PBR < 0.1 等)。

這種分離使得當「新增技能」時可以重用 Core 的邏輯,而當「更改資料來源」時,只需替換 Data 層即可。

資料持久化策略

針對網頁版的「上下文消失」問題,將三種資料以適當格式持久化。

資料 格式 理由
投資組合(持有股票・交易歷史) CSV 方便人類直接編輯和確認
篩選閾值・交易所定義 YAML 以可讀性高的結構化設定來管理
設計判斷・架構 CLAUDE.md Claude Code 在新會話中也能理解項目的上下文
股票資料快取 JSON 直接保存 API 回應(24 小時 TTL)

特別是 CLAUDE.md 對於運作的說明至關重要,其中詳細記錄了篩選引擎的作業要求、ETF 判斷的規則及資料獲取的模式。這樣,即使在新會話中打開 Claude Code,也能在理解項目上下文的情況下繼續開發。

技術選擇與邏輯

資料來源:yfinance

此系統的基礎是 yfinance(Yahoo Finance 的 Python 函數庫)。它免費且無需 API 金鑰,可以獲取個人投資者所需的大部分資料。

資料類型 可獲取的資料 用途
股價・評價 PER(股價收益率)、PBR(股價淨資產比)、配息率、市值、52 週高低價 篩選、報告
財務報表 損益表、資產負債表、現金流量表 變化打分(阿爾法)、健康檢查
分析師共識 目標股價(高/均/低)、評級、分析師數 預估報酬(3 種情境)
價格歷史 每日/每週/每月 OHLCV(最大可追溯數十年) 技術分析、VaR、相關性分析
新聞 來自官方媒體的新聞文章(標題、URL、摘要) 預估報酬的定性資訊
EquityQuery 指定條件批量搜尋股票(yfinance 支援 60+ 交易所) 篩選(全市場一次性)

特別是 EquityQuery 功能強大,當我設定「PER < 15 且配息率 > 3% 且在東證上市」,便會一次性回傳符合條件的股票。不必預先準備股票列表,因此能對東證的所有大盤、標準盤和成長盤股票進行全面篩選。這是相較於在網頁版逐一查詢時的最大差別。

yfinance 雖然免費可用,但數據有其特性(如 ETF 的銷售歷史回傳空列表、配息率可能以百分比回傳等),因此在 Data 層統一進行異常值的去除處理。

篩選:四個引擎

篩選使用了四個針對目的的引擎。

引擎 方法 用途
QueryScreener 透過 yfinance 的 EquityQuery API 批量獲取 → 根據價值打分排序 基本的被低估股票搜尋(價值、高股息等 5 個預設)
PullbackScreener EquityQuery → 根據 RSI/布林帶進行回檔判定 → 價值打分 想在上升趨勢中選擇短暫回調的時候進場
AlphaScreener EquityQuery(條件過濾) → 變化打分(3/4 指標) → 回檔判定 → 雙軸打分 尋找既被低估又有業績改善跡象的股票(四段管道)
ValueScreener 一檔檔案單獨取得 → 過濾 → 打分 遺留方式(為了兼容性而保留)

價值打分計算公式為 PER(25 分) + PBR(25 分) + 配息率(20 分) + ROE(15 分) + 營收成長率(15 分) = 總分 100 分。每個指標在 0 到 100 分的範圍內打分,合併計算後進行排序。

AlphaScreener 的「變化打分」以 accrued earnings(利益品質)、營收加速度、FCF 利潤變化及 ROE 趨勢四項指標來量化「業績是否朝良好的方向變化」。通過觀察變化的方向,不僅僅依賴於是否被低估來避免「被低估卻持續放置的陷阱(價值陷阱)」。

健康檢查:技術 × 基本分析的雙軸判定

用於判定擁有股票的「投資假設是否仍然有效」的健康檢查,擁有三階段的警示系統。

警示 技術條件 基本面條件 行動
早期警告 SMA50 下跌 / RSI 驟降 觀察
注意 SMA50 接近 SMA200 變化打分的 1 項指標惡化 考慮部分獲利
撤退 死亡交叉 變化打分的多個指標惡化 撤退考慮

設計上的關鍵判斷是,撤退信號要求同時須滿足技術崩潰與基本惡化的條件。儘管出現死亡交叉,只要基本面尚好,就僅定為「注意」。若僅因臨時供需波動就發出賣出信號將造成過度反應,因此必須從兩方面進行佐證。

對於 ETF(金 ETF、債券 ETF 等)則自動判定為基本面分析的例外,只進行技術評估。

image

預估報酬:分析師共識 + 歷史回報

通過樂觀/基準/悲觀的三種情境來提供未來 12 個月的預期回報。個別股票和 ETF 的處理方式不同。

個別股票 利用 yfinance 獲取的分析師目標價格(高/均/低)。若分析師人數少於 3 名,目標價格的價差通常會變得狹隘,因此自動擴大這一價差來分離三種情境。

ETF 由於沒有分析師覆蓋,則通過過去 2 年的月報酬計算 CAGR(複利年成長率),並依據標準差分歧設定情境。設置上限以防止由於異常值產生的過高估計。

此外,還可選擇性附加 yfinance 的官方新聞以及 Grok API(X Search)所進行的社交網路情緒分析。如果 Grok API 的環境變數未設定則將其選擇性跳過(優雅降級)。

image

壓力測試:基於情境的風險分析

通過 8 種預先定義的情境(如三重貶值、科技崩潰、日圓升值等)來檢驗投資組合的脆弱性。

分析透過管道進行結構化。集中度分析(HHI)→ 襲擊敏感度 → 情境影響估算 → 相關性分析(皮爾森相關 + 宏觀因素分解)→ VaR(95%/99%)→ 因果關聯分析 → 建議行動,這樣的流程。

在技術上,ETF 會自動歸類為資產類別(金、長期債、股息等),並根據每個情境套用適當的影響係數。例如,在「三重貶值」情境中,金 ETF 會作為對沖工具運作,與股票的影響呈反向計算。

推薦行動則根據規則生成,Claude 在考量投資組合的上下文後提供補充說明。此設計分離了定量分析(計算)和定性分析(LLM 的解釋),發揮各自的優勢。

image

個別報告是指通過指定股票代碼生成財務摘要的功能,觀察名單則管理感興趣的股票,以 JSON 格式持久保存。儘管這些都是簡單的輔助技能,但它們在篩選→報告確認→觀察名單註冊的過程中承擔了重要的鏈接角色。

image

投資組合的快照功能可以顯示持有股票的當前評估額與損益。

image

Agents / Teams:並行搜尋,並行檢驗

Claude Code 有一個稱為 Teams 的功能,允許多個代理以團隊格式並行啟動。這與篩選系統非常契合。

篩選的並行化

當我想要「同時在日本、美國、東南亞和香港這四個區域尋找被低估的股票」時,若逐個執行,每個區域需30秒到1分鐘,合計將需要幾分鐘。而使用 Teams 時,四個代理能夠同時探索各自不同的區域,並彙總結果回傳。

與一個代理按順序處理相比,實際所需時間將接近 1/N。由於系統支持 yfinance 的 60 多個交易所,這一並行化的優勢非常明顯。透過 yfinance 獲取分析師的信息(目標股價、評級和分析師數量),因此可以「同時搜尋全球的被低估股票,並按与共識目標的偏離程度進行排序」,使得全面探索成為現實。

總測試的並行化

相同的機制也應用於品質管控。我啟用了四個測試代理,同時執行所有技能的整合測試。

  • 篩選測試器 → 4 種模式(日本價值、美國高股息、日本阿爾法、美國回檔)
  • 報告測試器 → 4 種報告模式 + 6 種觀察名單 CRUD
  • 投資組合測試器 → 5 個子命令(列舉、快照、分析、健康、預測)
  • 壓力測試器 → 4 種模式(混合、情境指定、僅 ETF、權重指定)

結果是 23 個測試全數通過。在測試中發現了兩個輕微的錯誤,並以 Linear 自動記錄下來。

image

開發的實際狀況

遇到的問題

在利用 Skills 創建功能時,我遇到的問題都源自於 yfinance 數據的特性。

ETF 判斷的陷阱。 在判定 ETF 不是健康檢測對象的邏輯中,未注意到 yfinance 會對 ETF 的銷售歷史返回「空列表」,導致 ETF 被誤判為個別股票。透過切換到 bool() 的真值檢查(而非 is not None)來解決。外部 API 的返回值以何種方式表達「無數據」往往無法僅通過文檔得知,這是值得學習的教訓。

ETF 回報的年率換算。 単純將月回報中位數乘以 12 的單利計算導致金 ETF 的預估回報出現 +86% 明顯過高估計。修改為 CAGR(複利年回報)後,並將獲取期限從 6 個月擴大至 2 年,以獲得穩定的預估數字。

分析師人數過少時的情境崩潰。 在分析師少於 2 名的情況下,目標價格的高、中、低全為相同值,導致三個情境失去意義。於是我設置了自動附加價差以進行區分的功能。

振動編碼的開發流程

使用 iTerm 多窗口 x worktree 進行並行開發。 實際開發中,我會將 iTerm2 的窗口依角色分開,並同時並行工作。

  • PdM 窗口 ── 在 Linear 中創建任務,審核已完成的實作,並給予問題的反饋,扮演產品經理的角色。
  • 開發窗口 ── 在 feature 分支上持續實作,與 Claude Code 對話編寫代碼。
  • 測試窗口 ── 執行測試及操作確認。

Claude Code 是以終端為基礎,因此這一「多窗口同時與 Claude 交流」的開發風格自然契合。我在 PdM 窗口中創建問題並整理需求,然後將實作交給開發窗口的 Claude,完成後在 PdM 窗口進行審核和反饋——這正是 振動編碼 的本質。只需自然語言表達想做的事,AI 就可以負責設計、實作和測試,堪稱單人敏捷開發流程的實現。

另外,使用 git worktree 可以將同一個版本庫的不同分支檢出為不同目錄,讓我能在一個窗口推進 feature 分支的開發,並在另一窗口運行 main 分支的測試。根據需求切分 worktree,讓開發、測試、合併獨立同時進行,個人開發效率明顯提升。

Linear 連結。 Claude Code 的 MCP(模型上下文協議)連接 Linear,讓我可以直接在 PdM 窗口中創建和更新問題。「這是錯誤」→ 創建問題 → 開發窗口中修正 → 測試 → 在 PdM 窗口中審核 → 更新完成,所有過程皆可在終端中完成。

image

image

單元測試。 維持 740 測試以上。所有測試約在 20 秒內完成,因此每次修改都能輕鬆運行。由於外部 API 會用模擬數據,是不需要網路的高速運行。這些單元測試的存在,成為了我放心進行重構的基礎。即使將代碼改善交給 Claude Code,只要測試通過,就能立即確認現有運作未遭破壞。將開發工作交給 AI 的模式常常會伴隨不安,「是否能放心委託?」但測試則成為了這方面的安全網。

image

開發 Skills 的心得

  1. SKILL.md 應該作為「界面規範書」來撰寫。明確定義參數解釋規則和輸出格式,Claude 才能正確調用腳本。含糊的定義導致含糊的執行結果。
  2. 將邏輯放在技能以外。Skills 的腳本專注於入口點,業務邏輯有別的模塊進行區分。這樣能在技能間共享邏輯,寫測試也變得更加容易。
  3. 在 CLAUDE.md 中寫下架構。為了讓 Claude Code 在代碼修訂時參考,明確載明模組間的依賴關係和資料流程,會提升修訂的精度。
  4. 如何與上下文上限相處。即便是 Claude Code,隨著會話的延長也會達到上下文的上限。解決方法是「知識層次化」。可以邏輯化的部分落實到 Python 代碼中,能用規則管理的部分整理到 Skills 的 SKILL.md 中,整體項目的設計判斷寫在 CLAUDE.md 或 Rules 裡。這樣一來,即便在新會話中,Claude Code 也能藉由閱讀 CLAUDE.md 理解上下文而啟動。上下文中僅需載入「現階段想做的事」,透過定期重構整理知識即可隨著時間形成良性循環。
  5. 注意優雅降級。對於外部 API(如 Grok API 等),設計為未設置時會跳過,以避免由於環境差異而產生的錯誤。理想上是「即使不能運作,也能正常運行,如有則更好」。

總結:Claude Code Skills 在投資分析中實現了多大的自動化

作為振動編碼的實踐範例,利用 Claude Code Skills 我建構了「可對話的投資分析系統」,並使用自然語言介面進行交互。

  • 結構性解決了在網頁版中遇到的四個問題(回應、上下文消失、重現性、處理量)
  • 只需以自然語言交流,Claude 便能選擇並執行適當的技能,無需記住命令體系
  • 由於邏輯固定於腳本,故可以保證每次都能進行質量一致的篩選
  • 通過 Teams 實現並行執行,使得同時篩選 yfinance 支援的 60 多個交易所和收集共識信息成為現實
  • 與 Linear 連結,740 多項測試的自動執行,使開發、運營、質量管理都可在 Claude Code 內完成

Skills 使得「編寫代碼的 AI」轉變為「擁有可用工具的 AI」。一旦邏輯設計完成,接下來僅需進行自然語言交流,便可獲得具重現性的分析。

回顧這個專案,開發周期完全依靠 AI 和終端自我閉環。在 Linear 中整理需求,通過 iTerm 的多窗口與 Claude Code 進行對話來實施,並在 worktree 內平行測試,若有錯誤則自動提交到 Linear 進行修正,通過 Teams 進行整合測試的並行執行,以及合併並更新為完成。幾乎沒有打開瀏覽器的場景。未來會有不僅可以撰寫代碼的 AI,還能承擔需求管理、質量管理和專案管理的一體化世界,已在我手中實現。

這一方法不僅適用於個人投資者的工作流程改善,也能應用於繼續進行重複性分析和處理的業務。


原文出處:https://qiita.com/okikusan-public/items/61100a5b1aa8d752ae24


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
📝19   💬3  
490
🥈
我愛JS
📝1   💬5   ❤️2
65
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付