我利用 Claude Code Skills 和 yfinance 開發了一套自動化投資分析系統,涵蓋股票篩選到投資組合管理的全過程。透過 Python 和振動編碼技術,這套系統用五項技能來支持個人投資者的整體投資工作流程。
作為個人投資者,在接觸日本股市和美國股市時,尋找「被低估的股票」這項工作實在繁瑣。透過證券公司的篩選器來過濾,再逐一檢查出來的股票,並考慮整個投資組合的平衡——我渴望能找到方法來解決這樣的重複性工作。
如果你向 ChatGPT 或 Claude 的網頁版要求「尋找被低估的股票」,它們會在一定程度上滿足要求。然而,當我想將這些功能整合進投資決策的工作流程時,卻遇到了四個障礙。
Claude Code 的 Skills 解決了這四個問題。
最初我僅想實現篩選功能。但隨著需求的增長,「我也想要報告」、「還想管理投資組合」、「還需要健康檢查」、「還要進行壓力測試」,結果不知不覺中變成了一個由五項技能組成的系統。
本文將主要介紹這一系統的設計思想、技術選擇及其判斷。
Claude Code 有一種名為 Skills 的機制,允許用戶自創斜線命令。只需在技能定義文件(SKILL.md)中記錄技能名稱、描述、參數規則及允許的工具,Claude 就能解釋自然語言的輸入並執行腳本。

重點是,用戶只需用自然語言交流即可。完全不需要輸入斜線命令。Claude 可以理解用戶的意圖,自動選擇並執行適當的技能。
例如,當我隨意說「尋找日本股票的高股息股票」時,Claude 會根據上下文判斷出篩選技能,恰當設置地區和預設條件來執行腳本。問「我的投資組合狀況如何?」時,便會進行健康檢查。「給我看豐田的報告」時,則會生成該股票的個別報告。
換句話說,Skills 並不是「命令行工具」,而是 Claude 根據情境使用的工具箱。用戶無需記住命令體系,只需在投資的上下文中自然交流,便能讓後台運行適當的腳本。這一「自然語言 → 技能選擇 → 腳本執行 → 結果解讀」的整個流程,正是振動編碼的體驗,與傳統 CLI 工具形成了鮮明對比。
另一個重要點是 重現性。由於邏輯固定於 Python 腳本,因此今天與上個月的篩選可在相同標準下執行,這一點是有保障的。
此次開發的技能有五項。
| # | 技能 | 角色 |
|---|---|---|
| 1 | 篩選 | 尋找被低估的股票(支援 4 個引擎、7 個預設,yfinance 股票查詢的 60+ 交易所) |
| 2 | 個別報告 | 指定股票代碼生成財務分析報告 |
| 3 | 投資組合管理 | 顯示買賣紀錄、損益、結構分析、健康檢查、預估報酬和再平衡建議 |
| 4 | 壓力測試 | 使用 8 種情境檢驗投資組合的薄弱環節(集中度、相關性、VaR) |
| 5 | 觀察名單 | 管理感興趣的股票列表 |
這些技能涵蓋了「從篩選發現股票 → 通過報告進行詳細檢查 → 註冊於觀察名單 → 在投資組合中記錄買賣 → 通過健康檢查進行持續監控 → 通過壓力測試了解風險」的整個投資工作流程。

系統被分為 Skills 層(介面)→ Core 層(業務邏輯)→ Data 層(資料獲取) 三個層級。
這種分離使得當「新增技能」時可以重用 Core 的邏輯,而當「更改資料來源」時,只需替換 Data 層即可。
針對網頁版的「上下文消失」問題,將三種資料以適當格式持久化。
| 資料 | 格式 | 理由 |
|---|---|---|
| 投資組合(持有股票・交易歷史) | CSV | 方便人類直接編輯和確認 |
| 篩選閾值・交易所定義 | YAML | 以可讀性高的結構化設定來管理 |
| 設計判斷・架構 | CLAUDE.md | Claude Code 在新會話中也能理解項目的上下文 |
| 股票資料快取 | JSON | 直接保存 API 回應(24 小時 TTL) |
特別是 CLAUDE.md 對於運作的說明至關重要,其中詳細記錄了篩選引擎的作業要求、ETF 判斷的規則及資料獲取的模式。這樣,即使在新會話中打開 Claude Code,也能在理解項目上下文的情況下繼續開發。
此系統的基礎是 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 等)則自動判定為基本面分析的例外,只進行技術評估。

通過樂觀/基準/悲觀的三種情境來提供未來 12 個月的預期回報。個別股票和 ETF 的處理方式不同。
個別股票 利用 yfinance 獲取的分析師目標價格(高/均/低)。若分析師人數少於 3 名,目標價格的價差通常會變得狹隘,因此自動擴大這一價差來分離三種情境。
ETF 由於沒有分析師覆蓋,則通過過去 2 年的月報酬計算 CAGR(複利年成長率),並依據標準差分歧設定情境。設置上限以防止由於異常值產生的過高估計。
此外,還可選擇性附加 yfinance 的官方新聞以及 Grok API(X Search)所進行的社交網路情緒分析。如果 Grok API 的環境變數未設定則將其選擇性跳過(優雅降級)。

通過 8 種預先定義的情境(如三重貶值、科技崩潰、日圓升值等)來檢驗投資組合的脆弱性。
分析透過管道進行結構化。集中度分析(HHI)→ 襲擊敏感度 → 情境影響估算 → 相關性分析(皮爾森相關 + 宏觀因素分解)→ VaR(95%/99%)→ 因果關聯分析 → 建議行動,這樣的流程。
在技術上,ETF 會自動歸類為資產類別(金、長期債、股息等),並根據每個情境套用適當的影響係數。例如,在「三重貶值」情境中,金 ETF 會作為對沖工具運作,與股票的影響呈反向計算。
推薦行動則根據規則生成,Claude 在考量投資組合的上下文後提供補充說明。此設計分離了定量分析(計算)和定性分析(LLM 的解釋),發揮各自的優勢。

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

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

Claude Code 有一個稱為 Teams 的功能,允許多個代理以團隊格式並行啟動。這與篩選系統非常契合。
當我想要「同時在日本、美國、東南亞和香港這四個區域尋找被低估的股票」時,若逐個執行,每個區域需30秒到1分鐘,合計將需要幾分鐘。而使用 Teams 時,四個代理能夠同時探索各自不同的區域,並彙總結果回傳。
與一個代理按順序處理相比,實際所需時間將接近 1/N。由於系統支持 yfinance 的 60 多個交易所,這一並行化的優勢非常明顯。透過 yfinance 獲取分析師的信息(目標股價、評級和分析師數量),因此可以「同時搜尋全球的被低估股票,並按与共識目標的偏離程度進行排序」,使得全面探索成為現實。
相同的機制也應用於品質管控。我啟用了四個測試代理,同時執行所有技能的整合測試。
結果是 23 個測試全數通過。在測試中發現了兩個輕微的錯誤,並以 Linear 自動記錄下來。

在利用 Skills 創建功能時,我遇到的問題都源自於 yfinance 數據的特性。
ETF 判斷的陷阱。 在判定 ETF 不是健康檢測對象的邏輯中,未注意到 yfinance 會對 ETF 的銷售歷史返回「空列表」,導致 ETF 被誤判為個別股票。透過切換到 bool() 的真值檢查(而非 is not None)來解決。外部 API 的返回值以何種方式表達「無數據」往往無法僅通過文檔得知,這是值得學習的教訓。
ETF 回報的年率換算。 単純將月回報中位數乘以 12 的單利計算導致金 ETF 的預估回報出現 +86% 明顯過高估計。修改為 CAGR(複利年回報)後,並將獲取期限從 6 個月擴大至 2 年,以獲得穩定的預估數字。
分析師人數過少時的情境崩潰。 在分析師少於 2 名的情況下,目標價格的高、中、低全為相同值,導致三個情境失去意義。於是我設置了自動附加價差以進行區分的功能。
使用 iTerm 多窗口 x worktree 進行並行開發。 實際開發中,我會將 iTerm2 的窗口依角色分開,並同時並行工作。
Claude Code 是以終端為基礎,因此這一「多窗口同時與 Claude 交流」的開發風格自然契合。我在 PdM 窗口中創建問題並整理需求,然後將實作交給開發窗口的 Claude,完成後在 PdM 窗口進行審核和反饋——這正是 振動編碼 的本質。只需自然語言表達想做的事,AI 就可以負責設計、實作和測試,堪稱單人敏捷開發流程的實現。
另外,使用 git worktree 可以將同一個版本庫的不同分支檢出為不同目錄,讓我能在一個窗口推進 feature 分支的開發,並在另一窗口運行 main 分支的測試。根據需求切分 worktree,讓開發、測試、合併獨立同時進行,個人開發效率明顯提升。
Linear 連結。 Claude Code 的 MCP(模型上下文協議)連接 Linear,讓我可以直接在 PdM 窗口中創建和更新問題。「這是錯誤」→ 創建問題 → 開發窗口中修正 → 測試 → 在 PdM 窗口中審核 → 更新完成,所有過程皆可在終端中完成。


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

作為振動編碼的實踐範例,利用 Claude Code Skills 我建構了「可對話的投資分析系統」,並使用自然語言介面進行交互。
Skills 使得「編寫代碼的 AI」轉變為「擁有可用工具的 AI」。一旦邏輯設計完成,接下來僅需進行自然語言交流,便可獲得具重現性的分析。
回顧這個專案,開發周期完全依靠 AI 和終端自我閉環。在 Linear 中整理需求,通過 iTerm 的多窗口與 Claude Code 進行對話來實施,並在 worktree 內平行測試,若有錯誤則自動提交到 Linear 進行修正,通過 Teams 進行整合測試的並行執行,以及合併並更新為完成。幾乎沒有打開瀏覽器的場景。未來會有不僅可以撰寫代碼的 AI,還能承擔需求管理、質量管理和專案管理的一體化世界,已在我手中實現。
這一方法不僅適用於個人投資者的工作流程改善,也能應用於繼續進行重複性分析和處理的業務。
原文出處:https://qiita.com/okikusan-public/items/61100a5b1aa8d752ae24