背景

缠论是国内交易者常讨论的一套技术分析方法，对它的解释和评价差异很大。本文不讨论它是否有效，也不把图上的结构当成交易结论；我只想把其中的部分规则落实为一个可运行、可复核的观察工具。

缠论里的包含关系、分型、笔、线段和中枢都有计算顺序，但不同实现的口径并不相同。真正落到 K 线图上，麻烦不只在算法：数据要下载和缓存，图层缩放、拖拽后不能错位，待确认结构也不能装成确定结论，还要能测试、能复现。

用户选择交易对、周期和日期区间，浏览器下载公开 K 线，按固定规则计算并叠加结构。它只说明“按这套规则，图上有哪些结构”，不回答“该买还是该卖”。

最终效果

图 1：最终效果图

项目基于 Vue 3 + TypeScript + Vite 构建，数据缓存在浏览器的 IndexedDB 中。

首次打开页面会请求 BTCUSDT 日线，并写入本地缓存；切换币种、周期或指定日期时，先查询 IndexedDB，只有缺失区间才从币安公开接口分页下载。

图表使用的是 Lightweight Charts 绘制真实 OHLCV K 线和成交量，并叠加缠论的分型结构，如：

• 顶分型、底分型；
• 笔：黄色，确认笔为实线，最右侧待确认笔为虚线并标记“待确认”；
• 线段：蓝色；
• 中枢：紫色半透明矩形，展示 ZG、ZD 和起止时间；
• 包含处理后的结构轮廓、图层开关、十字光标 Tooltip、结构 JSON 导出。

右侧面板显示的是当前数据区间、最新已确认分型、已确认笔数量、待确认方向和最近中枢。

它把结构计算和图表定位放在同一处，方便学习时回看每一个分型、笔和中枢来自哪些 K 线。

搭建过程

最近 Qwen3.8-Max 发布，官方对比图里的跑分很高，我想看看它在一段完整工程任务里的实际表现。

图 2：Qwen3.8-Max 在官方对比图中的表现。

技术选型

这次使用的是日常就在用的 Claude Desktop 的 Code 编码模式，并通过 Gateway 接入百炼模型 Qwen3.8-Max。

图 3：Token Plan

我构思的核心逻辑只有四步：

Binance 公开 K 线 → IndexedDB 缓存 → 确定性缠论计算 → 图表叠加渲染

项目不需要后端、登录、API Key 和大模型调用，因为它运行时只做结构计算和图表绘制。用户可以在真实 K 线上查看分型、笔、线段和中枢，不必完全依赖人工逐根判断。

行情接口采用币安公开的数据，接口使用 https://data-api.binance.vision/api/v3/klines，请求参数是 symbol、interval、startTime、endTime、limit。单页数据不够就继续分页，结果按开盘时间去重排序；请求失败时保留上一份图表，并提供重新下载按钮。

缠论规则部分没有在 Prompt 里预设具体口径。实际执行时，模型自行查阅资料，再设计一版可执行、可测试的工程规则；实现时仍要求每一层拆成独立、无副作用的模块，方便其他功能引用：

原始 K 线
→ inclusion.ts（包含关系）
→ fractal.ts（顶底分型）
→ stroke.ts（笔）
→ segment.ts（线段）
→ pivot.ts（中枢）

这样每一层都能单测，图上每一条线也能追到对应的规则。默认参数写在 config.ts：严格笔模式开启，两个端点至少间隔 5 根合并 K 线。

核心 Prompt 以及执行逻辑

图 4：Prompt

我用 Qwen3.8-Max 为我先设计了一个 Prompt，当然你也可以通过交互式问询的方式去设计，经过我的几轮调整，部分内容如下。

请使用 Agent Team 协作开发一个完整、可运行的纯前端项目。

项目名称：BTCUSDT 缠论结构观察员

一、最终交付边界
- 技术栈必须为 Vue 3 + TypeScript + Vite。
- 纯前端运行，不使用后端、不登录、不接入任何大模型、不需要 API Key。
- 不做自动交易、买卖点推荐、涨跌预测、收益测算或任何投资建议。
- 页面固定提示：本工具仅用于市场结构观察，不构成投资建议。
- 使用公开行情接口获取真实 K 线；优先使用：
  https://data-api.binance.vision/api/v3/klines
- 必须提供 README、启动命令、数据来源说明、算法口径说明和测试说明。
- 不要只做静态原型，必须可运行、可下载真实数据、可绘制真实 K 线和缠论结构。

二、请建立以下 Agent Team，并按顺序协作
1. 缠论理论专家
职责：
- 输出可执行、可测试的缠论规则；
- 明确包含关系、顶底分型、笔、线段、中枢的定义；
- 规定“已确认”和“待确认”的判定条件；
- 给出不少于 8 个固定 K 线测试案例；
- 将规则写入 docs/chanlun-rules.md。

2. 产品经理
职责：
- 输出产品需求和交互流程；
- 定义币种、周期、日期区间、缓存、下载状态、无数据和接口失败的处理；
- 写入 docs/product-spec.md。

3. UI/UX 设计师
职责：
- 设计深色金融风格页面；
- 明确 K 线、成交量、分型、笔、线段、中枢、待确认结构的颜色和图层优先级；
- 要求已确认结构使用实线，待确认结构使用虚线；
- 写入 docs/design-spec.md。

4. 前端工程师
职责：
- 根据前三位 Agent 的文档实现完整项目；
- 不得自行改变缠论规则；
- 所有缠论计算写为独立、无副作用的 TypeScript 函数；
- 图表、算法、数据缓存、状态管理分层实现。

5. 测试工程师
职责：
- 为缠论算法编写 Vitest 测试；
- 验证图表缩放、拖拽、切换周期、切换日期区间后图层不会漂移；
- 验证无数据、下载失败、重复下载、极端 K 线、包含关系等边界情况；
- 输出 docs/test-report.md。

并行策略：
- 第一阶段并行完成缠论规则、产品需求和设计规范；
- 第二阶段由前端工程师统一实现；
- 第三阶段测试工程师验收；
- 不允许多个 Agent 同时修改同一个核心算法文件；
- 主 Agent 负责整合结果、解决冲突并最终运行 build 和 test。

...（其他内容省略）

我采用多角色并行方式，把任务拆给缠论规则、产品规格和界面规范三个角色，随后统一实现，再用 Vitest 和构建验收。

实际使用时，产品和设计很快交付了 product-spec.md、design-spec.md；缠论规则 Agent 却连续两次卡住，既没有输出，也没有写文件。我没有继续干等，先终止这个子任务，保留已有文档，再让主对话直接完成规则、实现和测试。

图 5：第一阶段中，产品与设计文档已完成，规则文档仍在等待。

这次让我看到的，不是“多 Agent 自动完成了一切”。更有用的是，子任务卡住后，Qwen3.8-Max 还能沿着已有上下文接手，把产品、设计、规则、源码和测试继续往下推进。多 Agent 能提速，但不能代替任务边界、文件落盘和可重复执行的测试。

图 6：子 Agent 中断后，改由主对话继续完成规则、实现和测试。

先把缠论口径写成程序

图 7：缠论核心算法

项目采用一套工程化、可测试的口径，不把它说成唯一解释：

1. 包含关系按趋势方向处理，且合并 K 线保留原始时间范围与高低点映射；
2. 顶底分型基于相邻三根处理后 K 线，以严格大于/小于判断；
3. 笔要求顶底交替并满足最少间隔；下一笔形成后，上一笔才锁定为已确认；
4. 线段只由已确认笔构成，至少三笔；
5. 中枢固定取连续三段已确认线段的重叠区域，ZG = min(三段高点)、ZD = max(三段低点)，只有 ZG > ZD 才绘制。

“待确认”本来就应该留在图上。代码允许最右侧笔被同类、更极值的分型延伸；已经确认的笔不会被后面的数据改写。项目还写了窗口不变性测试：对同一份 K 线的多个历史前缀分别计算，已确认笔、线段和中枢要与全量结果里的历史部分一致。

图层为什么不会跟着缩放漂移

图 8：绘制策略

K 线和结构层共用坐标。中枢、线段、笔、合并轮廓都写成 Lightweight Charts 的 Canvas Primitive；每次绘制时，都用 timeToCoordinate() 和 priceToCoordinate() 把时间、价格换算成像素位置。缩放、拖拽或 ResizeObserver 触发重绘后，图层仍对着同一套 K 线坐标。

因此我没有在页面上盖一层绝对定位 SVG。那样做首版可能更快，但图表一缩放就容易错位。实际预览里，K 线、成交量、黄色笔、蓝色线段和紫色中枢会一起变化。

踩坑记录

1. Agent Team 不是一直稳定

最开始的缠论规则子 Agent 没有输出，重启后仍然停滞。截图中可以看到，产品和设计文档已完成，规则文档却迟迟没有生成。最后改为主对话直接推进，避免整个工程被一个子任务阻塞。

这更像当前 Gateway 和子任务链路的稳定性问题，不能简单归因于模型本身。我的做法是给子任务明确的交付物和中断点，例如先创建 docs/chanlun-rules.md，而不是只显示“正在思考”。

2. 笔看起来“断了”，根因在待确认端点

真实 BTCUSDT 日线图跑起来后，我发现黄色笔有明显断点。定位到 stroke.ts 后，问题很具体：待确认笔遇到同类、更极值的分型时，旧逻辑只移动了笔的终点，没有同步下一次计算用的锚点。于是上一笔已经延伸，下一笔却仍从旧端点出发，图上自然断开。

修复不是改样式，而是在延伸分支里同步更新 anchor = f，并加入“上一笔终点必须等于下一笔起点”的回归测试。修复后，黄色笔链重新首尾相连。

图 9：通过真实图表定位待确认笔延伸时的断裂问题，并补上回归测试。

3. 线段与中枢不能只追求“画得出来”

后续真实数据又暴露两类问题：

• 线段在不足三笔就被破坏时，旧逻辑会过早截断，出现同向相邻或缺失；修复后，未达到三笔的信号会先继续吸收，满足条件才闭合线段；
• 中枢曾按延伸逻辑跨越太多线段，出现一个横跨多年、几乎盖住整张图的巨大矩形。最终改为严格使用连续三段已确认线段，不跨段无限延展。

这两个问题的处理原则很简单：宁可少画，也不用未确认结构或模糊规则凑出一个“看起来完整”的结果。

图 10：修复后，全量历史中的笔、线段和中枢按当前口径重新绘制。

图 11：在测试通过后启动浏览器预览，核对真实行情与图层渲染。

本文重新复跑当前源码：pnpm test 为 6 个测试文件、50 个用例通过；pnpm build 通过。测试覆盖固定 K 线案例、窗口不变性、缓存缺口、分页重试和接口失败状态。

效果对比

环节	仅靠临时脚本或手工画线	缠论结构观察员
行情数据	常需手动准备或重复下载	公开接口分页下载，IndexedDB 缓存缺失区间
结构口径	容易只存在于说明文字里	包含、分型、笔、线段、中枢各自独立实现与测试
已确认/待确认	常混在一起展示	实线与虚线明确区分，待确认笔有标识
图表联动	缩放后可能错位	所有结构按 K 线时间/价格坐标实时投影
可复核性	看图难以追溯	固定案例、窗口不变性测试、导出当前结构 JSON
产品边界	容易演变成交易信号	固定为市场结构观察，不提供投资建议

这次从需求到修复，累计消耗约 2,000 万 Token，耗时接近 2 小时，时间主要不在生成第一版页面，而在给规则定口径、定位缺陷、补测试和反复验证。

总结

Qwen3.8-Max 没有替我判断方向，也没有把缠论包装成预测工具。它在开发过程中支持多 Agent 并行，能够理解较长的产品约束和算法边界，拆分文档与实现任务；当子任务停滞后回到主上下文继续推进；再根据“笔断裂”“中枢过宽”这种图上的具体问题，定位到算法文件并补回归测试。

复杂项目不能靠一次生成直接交付。Agent Team 会卡住，初版算法也会错。模型放进开发闭环里才有意义，最后还是要靠可检查的规则、真实数据、测试和人工审阅。

复现指南

完整的 Prompt：

请使用 Agent Team 协作开发一个完整、可运行的纯前端项目。

项目名称：BTCUSDT 缠论结构观察员

一、最终交付边界
- 技术栈必须为 Vue 3 + TypeScript + Vite。
- 纯前端运行，不使用后端、不登录、不接入任何大模型、不需要 API Key。
- 不做自动交易、买卖点推荐、涨跌预测、收益测算或任何投资建议。
- 页面固定提示：本工具仅用于市场结构观察，不构成投资建议。
- 使用公开行情接口获取真实 K 线；优先使用：
  https://data-api.binance.vision/api/v3/klines
- 必须提供 README、启动命令、数据来源说明、算法口径说明和测试说明。
- 不要只做静态原型，必须可运行、可下载真实数据、可绘制真实 K 线和缠论结构。

二、请建立以下 Agent Team，并按顺序协作
1. 缠论理论专家
职责：
- 输出可执行、可测试的缠论规则；
- 明确包含关系、顶底分型、笔、线段、中枢的定义；
- 规定“已确认”和“待确认”的判定条件；
- 给出不少于 8 个固定 K 线测试案例；
- 将规则写入 docs/chanlun-rules.md。

2. 产品经理
职责：
- 输出产品需求和交互流程；
- 定义币种、周期、日期区间、缓存、下载状态、无数据和接口失败的处理；
- 写入 docs/product-spec.md。

3. UI/UX 设计师
职责：
- 设计深色金融风格页面；
- 明确 K 线、成交量、分型、笔、线段、中枢、待确认结构的颜色和图层优先级；
- 要求已确认结构使用实线，待确认结构使用虚线；
- 写入 docs/design-spec.md。

4. 前端工程师
职责：
- 根据前三位 Agent 的文档实现完整项目；
- 不得自行改变缠论规则；
- 所有缠论计算写为独立、无副作用的 TypeScript 函数；
- 图表、算法、数据缓存、状态管理分层实现。

5. 测试工程师
职责：
- 为缠论算法编写 Vitest 测试；
- 验证图表缩放、拖拽、切换周期、切换日期区间后图层不会漂移；
- 验证无数据、下载失败、重复下载、极端 K 线、包含关系等边界情况；
- 输出 docs/test-report.md。

并行策略：
- 第一阶段并行完成缠论规则、产品需求和设计规范；
- 第二阶段由前端工程师统一实现；
- 第三阶段测试工程师验收；
- 不允许多个 Agent 同时修改同一个核心算法文件；
- 主 Agent 负责整合结果、解决冲突并最终运行 build 和 test。

三、功能要求

1. 行情选择与下载
- 默认交易对：BTCUSDT。
- 默认周期：1d。
- 支持周期：1m、5m、15m、1h、4h、1d。
- 支持输入交易对，例如 ETHUSDT。
- 支持选择开始日期和结束日期。
- 首次进入页面时，仅自动下载 BTCUSDT 的日线数据。
- 用户切换交易对、周期或日期区间时：
  - 先检查 IndexedDB 本地缓存；
  - 缓存完整则直接读取；
  - 缓存缺失则自动下载缺失 K 线；
  - 下载完成后缓存；
  - 不重复下载已有时间段。
- K 线接口请求使用 symbol、interval、startTime、endTime、limit 参数。
- 单次请求数据量不足时自动分页拉取并按时间去重、排序。
- 页面必须显示明确状态：
  - 正在读取本地缓存；
  - 正在下载行情；
  - 已下载 N 根 K 线；
  - 当前展示本地缓存；
  - 当前日期区间无数据；
  - 行情接口不可用，请重试。
- 下载失败时保留上一份图表，不清空页面，并提供“重新下载”按钮。

2. 图表要求
- 使用专业 K 线图表库，例如 Lightweight Charts。
- 必须展示真实 OHLCV K 线和成交量柱。
- 支持缩放、拖拽、十字光标和 Tooltip。
- Tooltip 显示时间、开盘、最高、最低、收盘、成交量。
- 所有缠论图层必须与 K 线坐标同步。
- 切换数据、缩放、拖拽、调整窗口大小时，图层不能偏移或漂移。
- 提供图层开关：
  - 原始 K 线；
  - 包含处理后的结构；
  - 顶底分型；
  - 笔；
  - 线段；
  - 中枢；
  - 成交量。

3. 缠论算法要求
- 不使用大模型、AI API 或任何“猜测式”算法。
- 计算顺序固定为：
  原始 K 线
  → 包含关系处理
  → 顶底分型
  → 笔
  → 线段
  → 中枢。
- 包含关系处理后必须保留原始 K 线时间范围和高低点映射，保证图表可定位。
- 顶分型、底分型基于处理后的相邻三根 K 线识别。
- 笔使用严格、可配置的规则；默认规则、最少 K 线数量和端点确认条件必须写入配置文件。
- 已确认笔使用实线；最右侧仍在形成的笔使用虚线，并标注“待确认”。
- 线段只由已确认笔组成。
- 中枢默认由连续三段已确认线段的重叠区间构成；数据不足时不绘制中枢，不允许用未确认结构凑出中枢。
- 中枢以半透明矩形绘制，显示上沿、下沿、开始时间和结束时间。
- 算法必须遵守无未来数据原则：某根 K 线之后尚未发生的数据，不得参与该时点历史结构的确认。
- 切换回看窗口时，同一段已确认结构不得变化；为此编写窗口不变性测试。

4. 页面布局
- 顶部控制区：
  - 交易对选择；
  - 周期选择；
  - 日期区间；
  - 加载/重新下载按钮；
  - 当前数据来源与缓存状态。
- 左侧主区域：
  - K 线图；
  - 成交量；
  - 缠论结构叠加层。
- 右侧结构面板：
  - 当前交易对、周期和数据区间；
  - 最新已确认顶底分型；
  - 已确认笔数量；
  - 当前待确认笔方向；
  - 最近中枢区间；
  - 当前结构状态。
- 底部说明区：
  - 算法版本；
  - 当前规则参数；
  - “仅用于市场结构观察，不构成投资建议”。
- 提供“导出当前结构 JSON”按钮。
- 提供“重置图层”和“恢复默认视图”按钮。

四、代码组织要求
建议目录：
src/
  api/
    marketData.ts
  cache/
    klineCache.ts
  core/
    chanlun/
      inclusion.ts
      fractal.ts
      stroke.ts
      segment.ts
      pivot.ts
      types.ts
      config.ts
  components/
    ChartPanel.vue
    StructurePanel.vue
    MarketControls.vue
    StatusMessage.vue
  composables/
    useKlines.ts
    useChanlun.ts
  utils/
  tests/
docs/
  chanlun-rules.md
  product-spec.md
  design-spec.md
  test-report.md

五、验收标准
- pnpm install 后可运行 pnpm dev。
- pnpm build 必须通过。
- pnpm test 必须通过。
- 首次打开默认自动请求 BTCUSDT 的 1d 真实数据。
- 切换到 ETHUSDT、1h、指定日期区间时，能自动下载并正确提示。
- 真实 K 线图上能看见分型、笔、中枢。
- 已确认与待确认结构视觉上明显不同。
- 图层在缩放、拖拽、调整窗口大小后仍与 K 线对齐。
- 无 API Key、无大模型调用、无后端依赖。
- 所有页面和 README 都不得出现交易建议、收益承诺或自动买卖表述。

完成后请：
1. 运行测试和构建；
2. 修复所有报错；
3. 输出项目结构、启动方式、测试结果；
4. 说明缠论实现采用的具体口径和仍未覆盖的理论部分。

Node 版本为 v26.3.0，采用的是 PNPM 的管理方式，需要安装。