规则+LLM混合架构：终端行情分析工具的Vibe Coding实践

最近用Vibe Coding的习惯越来越重了，很多小工具我都是先跟AI把需求聊明白，再让它把架子搭起来，然后我手动改关键部分。这次这个“黄金与指数行情分析终端”就是这么来的，一个跑在终端里的TUI工具，底层是“规则系统先筛一遍、LLM再做语义解读”的混合架构。做完之后我自己用了两周，顺手把它从单纯看行情的脚本，迭代成了一个能辅助判断的终端助手。

这个项目最值得聊的，不是用了多新的模型，也不是行情预测有多准，而是“规则+LLM”这种搭配在终端场景下竟然出奇地顺。很多做量化或者盯盘的朋友，上来就想着全丢给大模型，结果要么输出不稳定，要么上下文太长烧钱，要么关键数据被幻觉带偏。我自己踩过这些坑之后，才意识到规则层的重要性——它能把LLM从“什么都要管”的泥潭里解放出来，让它只做自己擅长的事：总结、解释、给出倾向性判断。

这篇文章就完整记录一下这个终端的整体设计、核心模块、Vibe Coding实操过程，外加我在开发中踩过的坑，尤其是API密钥保护、LLM输出不稳定这类高频问题。如果你也想做一个类似的命令行行情工具，这篇可以当参考。

1. 为什么用“规则+LLM”而不是纯LLM：这个行情分析终端的架构取舍

先说说这个终端到底是干什么的。它不是一个自动交易系统，也不追求预测涨跌。它的定位是：当我打开终端，想快速了解当前黄金和几个主流指数的状态时，它能帮我完成三件事——第一，用规则引擎把行情数据做一次客观扫描，标出“超买”“超卖”“突破”“背离”这类技术信号；第二，把扫描结果和最近的K线走势、重要价位这些信息组装成上下文，交给LLM生成一段可读性很强的解读；第三，在终端里用一个清爽的界面把这些输出渲染出来，让我一眼扫完就有结论，不需要手动翻网页。

这个定位决定了我不可能用纯规则写死所有逻辑，也不可能把行情数据一股脑全丢给LLM。所以“规则+LLM”不是噱头，是真的各干各的活。

1.1 纯规则方案的瓶颈

很多人一开始都会觉得，搞个行情分析工具不就用技术指标算一算就行了吗？确实，规则方案有它的优势：计算速度快、结果稳定、逻辑透明。你把均线金叉、RSI超买超卖、布林带突破这些条件写好，输入行情数据，输出就是明确的信号。

但纯规则的瓶颈也很明显：它缺乏“解释能力”和“容错能力”。举个例子，RSI超过70，规则告诉你“超买”，但市场处于强趋势行情时，RSI可以在超买区钝化很久，这时候简单机械的规则输出就会产生误导。类似的情况还有很多，比如MACD金叉之后又立刻死叉，规则引擎只能机械地输出“信号失效”，但没法告诉你这背后可能是震荡行情的典型特征。

另外，规则系统的维护成本会随着条件增多而指数上升。你今天加一条“非农数据发布前后半小时不交易”，明天加一条“黄金突破前高后回踩确认”，规则文件很快变成一团乱麻，而且互相之间可能冲突。到后面你会发现，写规则的时间比看行情的时间还多。

1.2 纯LLM方案的失控感

既然规则方案有这么多限制，那直接上LLM行不行？我试过。把行情数据、历史K线、指标值全部拼成一段文本丢给GPT或DeepSeek，让它“分析并给出建议”。第一版确实惊艳，输出又流畅又全面，但用几天就发现问题了：不稳定。

不稳定体现在几个层面。第一，同样的数据，换一次会话，输出的结论可能完全不同，今天说“偏多”，明天同样的数据结构说“偏空”，你没法判断到底哪个是模型真实判断还是随机波动。第二，LLM经常一本正经地编造不存在的价位，比如K线最高点明明只有2050，它能编出“上方压力位2085”这种完全没出现在数据里的数字。第三，当行情数据量比较大的时候，模型的注意力会被最近的K线带偏，忽视了长期区间结构，导致解读失真。

还有一个现实问题就是成本。把大量行情历史数据每次全量丢给LLM，token消耗很吓人。我有一版跑了三天，API账单直接让我老老实实回到“先过滤再分析”的路线上。

1.3 规则+LLM的妥协与配合

所以最后我采用的是“规则先行，LLM兜底”的混合架构。规则层负责确定性比较强的工作：计算技术指标、识别明确的价格形态、过滤掉低质量数据、把连续的行情压缩成关键事件摘要。LLM层只负责一件事：基于规则层的结构化输出，进行自然语言解读和风险提示，把“发生了什么”和“可能意味着什么”用人类能直接理解的方式表达出来。

这个配合关系很像现实中的助理工作方式：规则层是数据清洗工和逻辑校验员，LLM是写汇报的分析师。分析师不需要自己去翻原始凭证，只需要看清洗工整理好的报表。这样既保证了输出的确定性，又保留了LLM的表达能力。

实测下来，这种方式有四个直接的好处：第一，LLM的输入长度大幅缩短，上下文控制在2000 token以内，成本降了一个数量级；第二，因为规则层已经把关键价位、信号这些结构化信息都算好了，LLM出现幻觉的概率明显下降；第三，规则层可以做一层“安全拦截”，如果检测到极端行情或者关键价位确认失败，可以直接不调用LLM，避免生成误导性结论；第四，整个系统行为可审计，每个结论都可以说清楚是规则算出来的，还是LLM基于哪些信息推出来的。

2. 终端工具的总体设计与数据链路

整个项目从零搭到现在，功能边界和架构其实迭代了好几轮。最初的版本就是一个Python脚本，拉数据算指标，打印在终端里。后来慢慢加了LLM解读、规则引擎、缓存机制和交互界面。现在整个项目的结构已经稳定下来。

2.1 终端形态选型：为什么不用Web

做这个工具之前，我先问自己一个问题：为什么要做成终端工具，而不是一个网页或者一个带界面的桌面应用？答案其实很实际：因为我大部分时间本来就在终端里工作，多开一个浏览器页面去盯盘反而分散精力。而且终端工具启动快、依赖少、改起来也方便，适合快速迭代。

终端工具还有一个好处，就是它天然适合“规则+LLM”的输出形态——结构化的技术信号用表格呈现，解读文本用段落呈现，整个界面层次分明。如果做成Web，很容易陷入“要不要加个图表”“要不要加个K线组件”这类需求陷阱中，偏离了“快速看结论”的核心目标。

当然，终端工具也有它的代价：无法展示复杂的图形交互，鼠标操作也基本可以忽略。但对我来说，这不是问题。因为行情分析这个场景，核心是数据和结论，不是图表的美观度。真有需要看图的时候，我可以随时调用TradingView或者看盘软件，这个终端只负责帮我快速完成“扫一眼、有结论”的步骤。

2.2 行情数据接入与缓存

数据源这块，我用的是免费的行情接口，具体是雅虎财经的API接口，通过Python的yfinance库拉取黄金（GC=F期货）、标普500指数、纳斯达克指数、道琼斯指数以及美元指数这几类标的的日线数据。之所以选择日线，是因为我的分析频率就是每日收盘后和次日开盘前各看一次，不需要分钟级数据。

数据接入有个很关键的优化点：缓存。因为免费接口有请求频率限制，而且重复拉历史数据浪费时间和带宽，我引入了一层本地缓存机制。第一次运行会把拉到的数据存成CSV文件，后续运行如果当前日期没变，就直接读缓存，只有需要更新当天数据时才走网络请求。这个设计在实际使用中非常管用，终端工具启动时间从原来的三秒钟降到了几百毫秒。

缓存逻辑本身不复杂，核心代码大概是这样：

python复制import os
import pandas as pd
from datetime import datetime

CACHE_DIR = os.path.expanduser("~/.cache/gold_index_analyzer")

def load_cached_data(symbol):
    cache_file = os.path.join(CACHE_DIR, f"{symbol}.csv")
    today = datetime.now().strftime("%Y-%m-%d")
    if os.path.exists(cache_file):
        df = pd.read_csv(cache_file, index_col=0, parse_dates=True)
        if str(df.index[-1].date()) >= today:
            return df
    df = fetch_from_api(symbol)
    df.to_csv(cache_file)
    return df

这个函数的意思是：先看本地文件里缓存的数据最后一条是不是今天，如果是就直接用，不是就去接口拉新的再存下来。别看逻辑简单，它对整个工具的使用体验影响很大。如果每次都重新拉数据，LLM部分的节奏也会被打断，因为你得等网络请求完成才能继续。有了缓存之后，“终端秒开”变成一种很舒服的体验。

2.3 规则引擎先行：过滤与打标

规则引擎是这个项目里我最花心思的部分，因为它承担了“把原始行情转化为结构化信号”的重任。整个引擎的核心数据结构是一个“信号列表”，每一项代表一个独立的技术信号。比如“黄金日线RSI触及70，进入超买区间”“标普500收盘价站上20日均线，短期趋势偏多”这类。

我用的规则集涵盖了几类常见的分析维度：

• 趋势类：均线多空排列、MACD金叉死叉、ADX趋势强度
• 动量类：RSI超买超卖、随机指标KDJ交叉
• 波动类：布林带开口收口、ATR波动率变化
• 支撑阻力类：近N日高低点、整数关口、斐波那契回撤位

每条规则本质上是一个纯函数：输入DataFrame，输出一个信号对象。信号对象包含规则名称、标的、触发时间、方向（多/空/中性）、强度等级。这种设计最大的好处是逻辑可测试、可组合、可追溯。你单独跑一条规则，也能看到它输出了什么，调试起来非常舒服。

规则层还有一个重要职责：过滤。不是所有信号都有资格进入LLM的上下文。例如在震荡行情里面，均线金叉和死叉可能连续交替触发，如果全部塞给LLM，它会无所适从。所以我在规则层加了一个“信号聚合器”，对同一标的时间相近、方向相反的规则信号进行去重和合并，只保留“关键转折点”级别的信号。这一层过滤之后，进入LLM的信号数量一般控制在5~8条，质量非常高。

3. 核心模块拆解：规则层、LLM层与终端渲染

整个项目按功能可以拆成三大模块：规则层、LLM解读层、终端渲染层。外加一个我在开发过程中反复使用的中控调度脚本。这一章就把每个模块的细节拆开讲，代码实现部分我也尽量贴出来，方便你直接参考。

3.1 规则层：把经验写成可读的规则

规则层的实现语言我选了Python，原因很简单：数据处理生态成熟，pandas和numpy做计算非常方便，而且Vibe Coding过程中，Python代码对AI来说也是“最熟悉”的语言，生成的代码质量通常最高。

规则引擎的核心抽象是一个接口，我给它起名叫AnalysisRule。每个具体规则只要实现这个接口，就能被引擎统一调度。

python复制from dataclasses import dataclass
from typing import Optional
import pandas as pd

@dataclass
class Signal:
    rule_name: str
    symbol: str
    direction: str  # bullish / bearish / neutral
    strength: float  # 0~1
    message: str
    timestamp: str

class AnalysisRule:
    def apply(self, df: pd.DataFrame, symbol: str) -> Optional[Signal]:
        raise NotImplementedError

以RSI超买超卖规则为例，实现起来非常直观：

python复制import pandas as pd

class RSIRule(AnalysisRule):
    def __init__(self, period=14, overbought=70, oversold=30):
        self.period = period
        self.overbought = overbought
        self.oversold = oversold

    def apply(self, df, symbol):
        delta = df["Close"].diff()
        gain = delta.clip(lower=0).rolling(self.period).mean()
        loss = (-delta.clip(upper=0)).rolling(self.period).mean()
        rs = gain / loss
        rsi = 100 - (100 / (1 + rs))
        latest = rsi.iloc[-1]
        if latest >= self.overbought:
            return Signal("RSI超买", symbol, "bearish", min((latest - 70) / 30, 1.0),
                          f"RSI达到{latest:.1f}，进入超买区间", str(df.index[-1]))
        if latest <= self.oversold:
            return Signal("RSI超卖", symbol, "bullish", min((30 - latest) / 30, 1.0),
                          f"RSI达到{latest:.1f}，进入超卖区间", str(df.index[-1]))
        return None

注意这里我把强度strength计算成了0到1之间的一个连续值，而不是简单的True/False。这样做的好处是，后续LLM层可以根据强度值赋予不同信号不同的权重，比如RSI刚突破70的弱信号和RSI冲到85的极强信号，解读的措辞应该不一样。让规则层输出“带权重的信号”，是我在迭代过程中很满意的一个设计。

实际跑通之后，我又补了一组趋势确认规则，比如“收盘价连续N日站在均线上方则确认上升趋势”，这组规则能有效过滤掉很多假突破。这个细节在纯规则系统里没什么特别的，但放在“规则+LLM”的架构里，它让LLM拿到的不再是零散指标，而是一组有内在逻辑关系的趋势判断。

3.2 LLM层：提示词模板与上下文组装

LLM层是这个项目的灵魂，也是最容易翻车的地方。先说结论：不要让LLM直接去看原始K线数据，一定要给它看“经过规则层提炼的结构化信号”。

提示词的组装逻辑我迭代了好几版，最终稳定成三段式结构：角色设定、客观数据、任务指令。

• 角色设定：你是一名严谨的贵金属与股指市场分析师，擅长结合技术指标进行客观研判，你的分析必须基于给定的数据，不得编造数据。
• 客观数据：列出当前各品种的最新价格、涨跌幅、以及规则层识别出的关键信号（信号名、标的、方向、强度、说明）。
• 任务指令：请基于以上信息，给出每个品种的短评、综合风险提示和关键价位关注列表。

提示词模板用f-string拼接，简单直接。但有几个关键细节必须注意：

第一，客观数据部分必须用文本表格或列表形式结构化呈现，不能是长篇描述。结构化文本能显著降低LLM遗漏信息的概率。第二，要把“不得编造数据”写进提示词，并且配合规则层把关键价位全部算好放进数据区，这样模型就没有发挥空间去编价位了。第三，温度参数要调低，我一般设temperature=0.2，避免模型过度发散。太高了它容易写出“可能突破也可能回调”之类的废话。

代码实现大概是这样的：

python复制def build_prompt(signals, market_data):
    data_lines = []
    for item in market_data:
        data_lines.append(f"{item['symbol']}: 最新价 {item['close']}, 日涨跌 {item['change_pct']}%")
    signal_lines = []
    for s in signals:
        signal_lines.append(f"[{s.strength:.2f}] {s.symbol} {s.rule_name}: {s.message} ({s.direction})")
    prompt = f"""
你是一名严谨的贵金属与股指市场分析师。
请基于以下数据给出客观分析，禁止编造任何未出现的数据及价位。

【当前行情】
{chr(10).join(data_lines)}

【规则引擎识别信号】
{chr(10).join(signal_lines)}

【任务】
1. 按品种分别给出短评（每品种不超过100字）
2. 给出综合风险提示
3. 列出未来24小时值得关注的关键价位
"""
    return prompt

调用LLM接口的部分我封装成了一个独立模块，这样可以方便切换不同的模型服务商。最开始用的是OpenAI的GPT-4o-mini，后来测试了DeepSeek的deepseek-chat，发现对中文数据解读的质量也相当不错，而且成本更低。我最终保留了一个MODEL配置环境变量，想切换模型的时候直接改配置就行。

3.3 终端渲染：Rich布局与交互

终端渲染层我用了Python的Rich库。这个库能让终端输出带上颜色、表格、面板这些排版元素，瞬间把一个普通的命令行脚本提升到专业工具的观感。

渲染层的核心是用Panel和Table这两类组件。顶部放标题和更新时间，中间区域分左右两栏：左边放各品种的最新行情表格（价格、涨跌幅、技术信号标签），右边放LLM生成的解读内容。底部放规则引擎扫描出的信号列表，每条信号前面用颜色区分方向——绿色表示偏多，红色表示偏空，灰色表示中性。

这里有一个很关键的交互设计：按回车刷新，按Q退出。因为终端用户习惯了极简交互，不需要复杂的菜单，只要能触发数据刷新就够了。刷新的时候会先重新拉数据、跑一遍规则引擎、再调用LLM，整个过程大概在5到10秒。为了让用户知道程序正在工作，我在等待时输出一行“正在获取最新行情并生成解读...”的提示。

Rich库的用法很简单，核心逻辑如下：

python复制from rich.console import Console
from rich.table import Table
from rich.panel import Panel
from rich.layout import Layout

console = Console()

def render_dashboard(market_df_list, signals, llm_comment):
    layout = Layout()
    layout.split_column(
        Layout(name="header", size=3),
        Layout(name="body", ratio=1),
        Layout(name="signals", size=10)
    )
    layout["body"].split_row(
        Layout(name="market", ratio=2),
        Layout(name="comment", ratio=3)
    )
    header_text = f"[bold]黄金与指数行情分析终端[/bold] - {datetime.now().strftime('%Y-%m-%d %H:%M')}"
    layout["header"].update(Panel(header_text, border_style="blue"))
    layout["market"].update(render_market_table(market_df_list))
    layout["comment"].update(Panel(llm_comment, title="LLM解读", border_style="green"))
    layout["signals"].update(render_signal_table(signals))
    console.print(layout)

跑起来之后，整个界面就是一个信息密集但结构清晰的仪表盘。我第一次完整跑通的时候，那种成就感不比写完一个Web应用差。终端的克制感和精确感，反而让信息传达更高效。

4. Vibe Coding实操：提示词驱动与迭代过程

既然项目标题里带上了Vibe Coding，这一章我得好好说一说我是怎么用AI辅助编程把整个东西做出来的。Vibe Coding的核心不是“让AI全部写完”，而是“用自然语言描述需求、让AI搭框架、自己审关键逻辑、再让AI改细节”这种循环。

4.1 第一版：用自然语言描述需求

我做这个项目的第一条提示词大概是这样的：“我要做一个Python终端工具，分析黄金期货和美股指数的日线行情。先从雅虎财经拉数据，计算RSI和均线指标，在终端里用表格打印出来。请给我一个完整的项目结构和代码。”

这条提示词其实已经包含了我核心的需求：Python、终端、雅虎财经、RSI和均线、表格输出。AI返回的是一个脚本，基本能用，能拉数据、能算RSI、能打印一个简单的ASCII表格。第一步实现“能用”的目的达到了。

Vibe Coding的第一步要点就在于：不要指望AI一次生成完美方案，而是先让它快速出一个能跑的最小版本。这个版本存在的意义是让你有一个可以摸、可以改、可以讨论的对象。我在实际命令行里跑通这个最小版本后，才对“我要一个终端行情工具”这件事有了更具体的感知。

4.2 迭代：让AI改代码的边界

有了第一版之后，后面的迭代就有方向了。我开始逐条提需求，每条需求都尽量具体。比如“把输出从ASCII表格改成Rich库的输出，加上边框颜色”“把技术指标从RSI扩展到MACD和布林带”“把指标计算逻辑封装成独立的规则类，方便扩展”。AI每次都能很快给出改动方案，我只需要审查改动是否引入了问题。

这个阶段有一个重要的边界认知：AI擅长的是“基于现有代码做增量修改”，但对“架构方向的本质判断”往往不够敏感。比如某次我让AI优化LLM上下文，它直接把规则层所有信号的详细计算过程都拼进提示词里，导致上下文急速膨胀。我审查后发现不对，引导它改成只保留最终信号摘要，这个问题才解决。这种事发生多了，你就会明白Vibe Coding的边界——AI是高效的执行者，但架构判断仍要自己把关。

Vibe Coding的另一个实用技巧是：随时让AI写测试。我在迭代规则引擎的时候，会专门让AI为每条规则生成边界测试用例。比如让RSIRule跑在一个RSI值恰好等于70的DataFrame上，看它是否触发超买信号。这听起来很基础，但对于防止后续改动引入回归问题非常有效。AI写测试的能力很强，我只需要把测试数据构造好，剩下交给它就行。

4.3 迭代过程中的代码审查要点

Vibe Coding不是说AI写完你完全不管。实际上，越是接近核心逻辑的代码，越需要人工审查。我总结了几条自己的代码审查经验。

第一条，凡是涉及资金和风险判断的逻辑，必须人工读一遍再跑。行情分析工具不直接产生交易，但它的结论会影响人的交易决策，所以“规则层不犯错”是底线。我会重点审查所有数值计算是否引用了正确的列名，是否有未来函数（比如用了未来数据），是否有除零风险。

第二条，LLM模块的调用代码审查重点在密码学安全上。我会检查API密钥有没有硬编码、有没有可能被打印到日志里、环境变量的读取方式是否正确。密钥安全这个问题太重要了，值得单独开一节细聊。

第三条，终端渲染层的代码可以适当放松审查标准。因为渲染层出错最多是显示问题，不会影响分析结论的正确性。所以这一层我基本信任AI生成的结果，只在视觉上做一些微调。

5. 踩坑记录与安全常识：密钥、稳定性与规则冲突

最后这部分是真正的干货，我把开发这个项目过程中踩过的坑记录在这里，尤其是密钥安全、LLM输出稳定性、规则与LLM冲突这几个高频问题。

5.1 使用LLM时如何防止密钥等鉴权信息泄露

这个话题我必须先讲，因为它真的差点让我翻车。最早一版我把API Key直接写在代码里，然后觉得没事，项目放在本地跑又不会上传。后来有一次我想把项目分享给朋友，复制代码前突然意识到：我如果把这行硬编码密钥的代码发出去，密钥就泄露了。这还不是最可怕的，如果哪天我把项目推到Git仓库，又忘了加.gitignore，那密钥就直接暴露在公网上了。

正确的做法其实很简单，核心就三条：第一，密钥永远走环境变量，不写进源码；第二，养成提交前扫描密钥的习惯；第三，密钥一旦确认泄露，立刻去服务商后台更换。我用的方案是python-dotenv，把密钥放在项目根目录的.env文件里，然后.gitignore里明确排除这个文件。

python复制from dotenv import load_dotenv
import os

load_dotenv()
api_key = os.getenv("OPENAI_API_KEY")
if not api_key:
    raise RuntimeError("未检测到API密钥，请检查.env文件")

除了环境变量，还有几个容易忽略的泄露途径。比如你在调试的时候把包含完整响应的对象直接打印出来，而响应体里可能带有调用的模型名称和token使用量，虽然不直接泄露密钥，但会暴露你在用哪个服务商。再比如你把带密钥的命令行历史分享出去，别人通过history就能看到你的密钥。我在开发中就习惯性地在终端里执行过export OPENAI_API_KEY=xxx这种命令，后来心想这命令要是被录屏或者记录在案，等于密钥裸奔。所以我现在基本都是写在.env文件里，不让密钥出现在终端命令历史里。

还有一个技巧是针对LLM API调用的：如果你走的是代理或中转服务，不要把整个URL写死在代码里，用环境变量配置BASE_URL。这样换服务商或者换地区节点的时候，不需要改代码，只改环境变量就行。而且万一代码分享了，也不暴露你的具体网关地址。

5.2 LLM返回不稳定时的应对策略

LLM输出的不稳定性是这类项目最大的痛点。我遇到的最典型的问题是：同一组信号，第一次调用返回“短期偏多”，第二次调用返回“震荡观望”。后来我定位到，原因之一是temperature设得太高，导致模型每次推理的随机性过大。把这个参数从默认的0.7降到0.2之后，稳定性明显好转。

但temperature并不是唯一因素。另一个被我忽视的问题是：上下文顺序。同样的信息，放在提示词前面和后面的解读方式会不一样。当我用固定的模板组装提示词时，这个影响就不那么大，但如果某次上下文结构变了，LLM输出的风格和结论就可能跳变。

再一个问题是LLM输出格式不稳定。我一开始要求它返回JSON，然后直接解析。后来发现模型有时候会输出Markdown代码块包裹的JSON，有时候会在JSON后面加注释。解析失败的风险很高。我的解决办法是，干脆不用JSON作为主输出格式，而是让它输出纯文本段落，再用规则层去解析标题和内容。或者用起来比较稳妥的JSON修复库，比如json-repair，这个库专门处理LLM返回的不规范JSON。不过说实话，能不用JSON就别用JSON，纯文本输出对LLM来说最自然，解析成本也低。

第三个策略是设置“安全兜底”：如果LLM调用失败，或者返回内容里没有包含所有指定品种的关键词信息，程序直接输出规则层的结果，不展示LLM的解读。这样保证工具在LLM不可用时仍然能提供核心价值，起码行情数据和规则信号是完整可用的。

5.3 规则层与LLM冲突时怎么办

用了一阵子之后，我遇到一个很有意思的情况：规则层说RSI超买，偏空信号，但LLM却解读成“强势持续，可能继续冲高”。两边的结论方向相反。这种冲突该怎么处理？

我当时的处理方式时：在规则层预留一个“冲突检测”机制。如果规则层信号的总方向和LLM解读的方向不一致，终端界面会把两边的判断都展示出来，并在LLM解读底下追加一行提示：“注意：LLM观点与规则信号方向不一致，请谨慎参考”。不强行让某一方服从另一方，而是把分歧呈现给用户。这个设计我认为是符合实际需求的，因为技术分析和LLM的“语义理解”本身就是两种不同维度的信息，最终判断应该由用户结合自己的交易计划来做。

还有一个细节是，我在LLM解读的最底部追加了一行固定说明：“以上解读由AI生成，不构成任何投资建议”。这不是形式主义，而是让用户保持清醒。

5.4 高频问题速查表

开发过程中有些问题反复出现，我把它们整理成一个速查表，方便你参考。

最后再分享一点我做这个项目的体会

整个项目从开始写第一行代码到稳定运行，大概花了一个周末的时间。真正花时间的不是写代码本身，而是想清楚“让规则干什么、让LLM干什么”这个问题。代码只是思路的投影。现在每个交易日收盘后，我都会在终端里跑一遍这个工具，看看规则层的信号和LLM的解读，然后结合自己的判断做决策。它没有改变我的投资结果，但它确实改变了我每天获取信息的效率。

如果你也想做类似的东西，我的建议是：从最小版本开始，先把数据链路跑通，再慢慢加规则，最后再上LLM。不要一上来就追求华丽界面和深度分析，先把骨架搭起来，你自然会知道往哪里加肉。工具是长出来的，不是设计出来的。