基于蜡烛图技术的
加密货币市场分析

为什么开发这个项目

前几年，比特币一次次冲上新闻。价格一路往上冲的时候，所有人都在谈它。跌下来的时候，所有人也都在谈它。这个市场最特别的地方，不只是波动大，而是它天然带着一种很强的戏剧性。你一眼看过去，会觉得它和别的市场差不多，也有开盘、收盘、最高、最低，也有完整的 K 线和 OHLC 数据；可只要真的盯着它看一段时间，就会发现它比很多成熟市场更连续，也更躁动，情绪、叙事和价格经常缠在一起，根本分不开。

这个项目的idea来自我对一位长期研究数字资产图表的人的采访。对于这样一个市场，他会先看月线、周线、三日线，判断大背景是不是成立；再回到日线，看结构有没有变化；最后再往更短的周期里收，确认局部位置。我觉得这件事真正有意思的地方，不在某一个形态本身，而在于它背后其实藏着一套非常稳定的阅读顺序。不同周期并不是各看各的，而是在同一套判断里承担不同的功能。

但这次采访也让我发现了一个痛点：越是看上去成熟的方法，越难直接搬进程序。很多蜡烛图知识天然依赖经验，依赖上下文，依赖人对图形细节的整体感觉。同样一组 K 线，不同的人会读出不同的东西。另一层麻烦在于，这套流程又特别重复。切换周期、筛选候选、确认形态、排除干扰，很多步骤并不复杂，真正消耗精力的是它必须被一遍一遍地执行。

这是个痛点。这个过程可以被自动化吗？这个过程应该被自动化才对。 我想到《日本蜡烛图技术》。这本书让我越来越清楚地意识到，图表里的信息并不只是价格本身，很多判断其实已经被压缩在形态结构里。问题在于，这套知识原本就是写给人读的，不是写给程序跑的。书里的很多判断默认读者已经知道什么地方该结合趋势看，什么地方不能只看单根 K 线，什么地方要把前后文一起带进来。人读起来会觉得自然，程序读起来却会立刻撞上边界。

基于此，我想做的不是一个直接给出结论的页面，而是尝试把一套原本依赖人工阅读的过程拆开，重新组织成一条可以运行的工程链路。前面接公开行情数据和本地数据库，中间用规则系统做第一轮初筛，把候选范围压下来，后面再接入大语言模型处理解释层，最后把多周期图表、候选形态、说明文本和页面状态组织成一份真正能读下去的报告。

我的工作和实现路径

项目由我本人独立开发。这个项目不是一个静态报告，我在最初设计的时构思了一套完整的链路。

最早先解决数据获取和本地落库，再做规则初筛，把原始图表压缩成更可处理的候选结果。 然后接入大语言模型，专门处理解释层和候选比较，最后再把这些结果组织成长页报告和前端界面。

项目最终把一套依赖人工经验的图表分析流程，整理成了一条可以运行、可以解释、也可以展示的工程链路。

项目结构

该项目包含从后端数据接入、本地落库、规则初筛、LLM 解释到前端报告输出的完整链路：

后端

Python：113 个 Python 文件，约 1.95 万行 Python 代码。其中包含 18 个配置化蜡烛图形态定义，19 个形态识别初筛模块，4 个行情适配器，30 个测试文件。

SQLite：1 个本地SQLite数据库。

AI LLM：3 个大模型接口，2 个 prompt 模板。

前端

前端：10 个前端 React 组件。

详细目录树和各模块功能见页底的展开内容，简化的目录树如下。

project1-crypto/
├── main.py
├── candlestick/
├── data/
├── src/
│   ├── adapters/
│   ├── services/
│   │   ├── candles/
│   │   └── llm/
│   ├── spa/
│   ├── templates/
│   ├── static/
│   ├── database.py
│   └── web_server.py
└── tests/

重要提示

本页面仅展示历史原型的静态截图与系统设计思路，不提供实时数据、实际交易对象、投资建议或交易服务。公开展示的重点是工程实现、信息组织和界面结构，而非任何现实使用场景。

报告预览

前端渲染的报告，可以直接在网页中查看。但根据相关法律法规，我在这里以网页截图的形式展示报告的主要功能，对敏感信息做了遮挡处理，包括币种、价格、时间轴以及 AI 的具体分析结果。

报告的顶层结构包括标题区、说明区、统计区和主报告区域。整体分为“特别关注”和“信号发现”两部分。特别关注区展示的是由用户主动选定的条目；信号发现区则展示用户未主动关注、但在当前分析中出现了值得注意形态的条目。

报告的首页展示了整体结构，包括标题区、说明区、统计区和主报告区域。

用户可以通过交互按钮自行选择需要关注的条目。被选定的项目会始终置于报告顶部，无论当前 K 线是否识别出明确形态。

每一个被展示的币种，都对应一张独立的展示卡片。下图是单张卡片的内容示例。

卡片下方的候选形态模块用于展示当前 K 线可能对应的蜡烛图形态，并给出该形态的判断依据、确认条件和失效条件。

在示例的这张信号卡片里，蜡烛图形态初筛出了两种可能的形态，十字孕线和十字线家族（可能是家族中的晨星线），并按AI LLM分析的可能性优先级排序。 根据《日本蜡烛图技术》的指导，LLM给出的形态判断依据是“第二根不是普通小实体，而是十字线，被第一根实体包住。”，并提示用户可通过第三根K线方向确认该疑似形态。 LLM还分析了疑似形态的失效条件，当“K线回到十字线附近持续横盘，未形成突破”时，该形态失效，需重新判断。

此外，用户还可以在交互按钮（红框中）中切换不同周期的 K 线。

下图展示的是信号发现区。用户未主动关注的币种，在经过形态初筛和进一步分析后，如果出现值得注意的结构，就会被展示在这一部分。

报告还会抓取当前时段内可能相关的风险事件，作为页面中的补充信息，为分析提供背景。

风险事件展示在页面底部。

下一步

这条链路不只适用于当前原型，也可以迁移到其他 OHLC 数据驱动的金融场景。对我来说，这个项目最大的价值，是验证了从数据、规则、解释到页面展示的一体化方法。在本次项目开发经验的基础上，我正在开发另一项期货相关的分析流程。

更多细节

project1-crypto/
├── main.py
├── requirements.txt
├── candlestick/
│   ├── candlestick_patterns.yaml
│   ├── candlestick_params.yaml
│   ├── candlestick_global_rules.yaml
│   └── pattern_result_schema.yaml
├── data/
│   ├── cpia.db
│   ├── scan_symbols.txt
│   ├── always_include.txt
│   └── report_cache.json
├── scripts/
│   └── preprocess_playbooks.py
├── src/
│   ├── adapters/
│   ├── patterns/
│   ├── services/
│   │   ├── candles/
│   │   └── llm/
│   ├── spa/
│   ├── templates/
│   ├── static/
│   ├── database.py
│   ├── models.py
│   ├── config.py
│   └── web_server.py
└── tests/