背景缠论是国内交易者常讨论的一套技术分析方法对它的解释和评价差异很大。本文不讨论它是否有效也不把图上的结构当成交易结论我只想把其中的部分规则落实为一个可运行、可复核的观察工具。缠论里的包含关系、分型、笔、线段和中枢都有计算顺序但不同实现的口径并不相同。真正落到 K 线图上麻烦不只在算法数据要下载和缓存图层缩放、拖拽后不能错位待确认结构也不能装成确定结论还要能测试、能复现。用户选择交易对、周期和日期区间浏览器下载公开 K 线按固定规则计算并叠加结构。它只说明“按这套规则图上有哪些结构”不回答“该买还是该卖”。最终效果图 1最终效果图项目基于 Vue 3 TypeScript Vite 构建数据缓存在浏览器的 IndexedDB 中。首次打开页面会请求 BTCUSDT 日线并写入本地缓存切换币种、周期或指定日期时先查询 IndexedDB只有缺失区间才从币安公开接口分页下载。图表使用的是 Lightweight Charts 绘制真实 OHLCV K 线和成交量并叠加缠论的分型结构如顶分型、底分型笔黄色确认笔为实线最右侧待确认笔为虚线并标记“待确认”线段蓝色中枢紫色半透明矩形展示 ZG、ZD 和起止时间包含处理后的结构轮廓、图层开关、十字光标 Tooltip、结构 JSON 导出。右侧面板显示的是当前数据区间、最新已确认分型、已确认笔数量、待确认方向和最近中枢。它把结构计算和图表定位放在同一处方便学习时回看每一个分型、笔和中枢来自哪些 K 线。搭建过程最近 Qwen3.8-Max 发布官方对比图里的跑分很高我想看看它在一段完整工程任务里的实际表现。图 2Qwen3.8-Max 在官方对比图中的表现。技术选型这次使用的是日常就在用的Claude Desktop的Code编码模式并通过 Gateway 接入百炼模型 Qwen3.8-Max。图 3Token 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 以及执行逻辑图 4Prompt我用 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缠论核心算法项目采用一套工程化、可测试的口径不把它说成唯一解释包含关系按趋势方向处理且合并 K 线保留原始时间范围与高低点映射顶底分型基于相邻三根处理后 K 线以严格大于/小于判断笔要求顶底交替并满足最少间隔下一笔形成后上一笔才锁定为已确认线段只由已确认笔构成至少三笔中枢固定取连续三段已确认线段的重叠区域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 的管理方式需要安装。
