你填计划，系统算数量
你填写亏损预算与价格，系统用预算除以每 BTC 到止损的价差，算出下单数量，再回算预计亏损。片中演示指定入场价的流程：第一次点击先计算并检查计划；结果显示后，核对数量与预计亏损，再次确认才下单。
Trade Assistant
先想好能承担的损失，
再决定交易的数量。
将以损定量等交易仓位管理方法工具化，把风险预算、仓位计算、止盈止损与交易执行整合为统一工作流。交易内核已接入 Binance、OKX、Bybit、Bitget 和 Hyperliquid。
开发与验收中统一交易内核 · 5 个交易场所记录于 2026.09.08
把“以损定量”讲明白
不用先懂交易。从一个简单问题开始：如果这次判断错了，你愿意承担 100U 的损失，该开多大的仓位？用一笔 BTC 交易看懂以损定量，再走一遍 Sidepanel 交易页：填亏损预算和价格、看盈亏比、计算数量与预计亏损，最后核对并确认下单。这里用 U 代指 USDT。
Trade Assistant 将仓位管理方法工具化。
4:40 · 字幕讲解可暂停阅读 / 全屏观看
阅读产品讲解文字稿
先想好，最多愿意亏多少
Trade Assistant 将仓位管理方法工具化。先确定风险预算，再计算这笔交易的仓位。把入场、止损、止盈和数量组成交易计划。这支视频，围绕 Sidepanel 的交易页展开。先看懂亏损预算、价格和盈亏比，再把算例填进页面，核对计算结果并确认下单。它不预测涨跌，目前仍在开发和验证中。
做多、做空：你在判断方向
做多：希望价格上涨，涨了有利，跌了不利。做空：希望价格下跌，跌了有利，涨了不利。交易页用 LONG 和 SHORT 选择这两个方向。接下来，用比特币（BTC）的做多交易举例。这里用 U 代指 USDT，表示金额。
进场前，先画好两条出口
假设以 100,000U/BTC 的价格入场。跌到 95,000U/BTC，按计划止损退出。这相当于价格下跌 5%。涨到 110,000U/BTC，按计划止盈退出。这相当于价格上涨 10%。对应交易页的入场 E、止损 SL 和止盈 TP。实际成交价可能有偏差，并不保证按原价成交。
以损定量：用亏损预算倒推
这次计划最多亏 100U，能开多大的仓位？入场到止损的价格距离，是入场价的 5%。100U ÷ 5% = 2,000U 仓位。仓位金额，指参与这笔交易的总价值。按 100,000U/BTC 换算，就是 0.02BTC。先定能承担的损失，再倒推仓位：以损定量。这个简化例子，先忽略手续费和滑点。
止损放远，数量就要缩小
把止损价移到 90,000U/BTC。相对 100,000U 入场价，止损幅度变成 10%。风险预算仍是 100U，重新倒推仓位。100U ÷ 10% = 1,000U 仓位。对应 0.01BTC，仓位与数量都减半。实际计算还要计入手续费、滑点等成本，并按交易所的数量规则，向下取整。
盈亏比：风险与回报
盈亏比＝目标收益 ÷ 计划损失。计划亏 100U，目标赚 200U，比例是 2∶1。意思是：承担 1U 计划风险，争取 2U 收益。把计划风险记为 1R，目标收益就是 2R。用它可以比较不同交易的潜在回报与风险。假设连续 3 笔交易，风险与盈利目标都相同。并且都按计划价退出，暂不计交易成本。一笔赚 200U，两笔各亏 100U，合计为 0。在这个例子里，赚 1 次能抵亏 2 次。盈亏比不代表胜率，也不保证最终盈利。
在交易页，把计划填清楚
这里把前面的算例，填进 Sidepanel 交易页。选择 LONG，再填 100U 亏损预算。入场 E 填 100,000，止损 SL 填 95,000。止盈 TP 填 110,000，组成这一笔计划。右侧 RR 显示实际盈亏比，这里是 2R。需要保持这个比例，可以点旁边的锁。下单数量和最大亏损，要等计算完成后查看。接下来，以填写指定入场价的计划演示。
先看计算结果，再确认下单
填好计划后，先点底部的确认 LONG。这一步计算并检查计划，还没有下单。你填的是亏损预算，以及入场、止损和止盈价。系统先算：入场 100,000，减去止损 95,000。每 1BTC，到止损的价差损失就是 5,000U。100U 预算除以 5,000，算出 0.02BTC。再回算：0.02 乘 5,000，预计亏损 100U。计算并检查通过后，页面才显示这些结果。两个结果，分别填到下单数量和最大亏损。最大亏损是按止损估算的金额，不是损失保证。这里忽略费用与滑点，实际计算还要计入成本。核对数量、预计亏损和风险检查状态。再点确认下单，才提交这笔执行。输入计划，计算结果，核对后再下单。
算例有意做了简化
假设 BTC 入场价为 100,000U，止损价为 95,000U：100U 风险预算对应 2,000U 仓位，即 0.02BTC。价格仅作教学示例，未计费用与滑点；实际计算还涉及合约单位、数量步进等。止损预算是估计，跳空、强平和保护延迟仍可能造成更大损失。
三条线背后，是一套交易系统
Chart 负责图上交互，Side Panel 组织人的操作，Trade Core 接住执行与恢复。从三部分内部结构，到一次请求超时后的处理，再展开 58 项操作与故障矩阵，看看复杂度具体藏在哪里。
图表上的三条线，背后连着三个领域。
5:52 · 字幕讲解可暂停阅读 / 全屏观看
阅读系统架构文字稿
三部分，接住一笔交易
图表上的三条线，背后连着三个领域。Chart 把价格和计划变成可看的线、可拖的对象。Side Panel 让人编辑计划、发起操作、查看结果。Trade Core 负责计算、执行、保护，以及出错后的恢复。中间由可信宿主连接：一份权威草稿，接入交易内核。界面上的计划，和交易所已经发生的事实，要分别管理。
Chart：把价格变成操作
最底下的适配器，识别图表实例、坐标和行情能力。场景投影把计划翻译成入场、止损、止盈等图上对象。渲染器负责画线、标签、命中区域和键盘操作。拖动时先本地预览；松手才提交一次修改意图。价格联动复用内核的计算规则，宿主保存前还会重验。切换品种或图表实例，要清掉旧对象和过期交互。页面行情仅供规划参考；图表不持有密钥，也不直接下单。
Side Panel：把意图讲清
侧栏包含交易、持仓、历史和设置等操作页面。表单保留正在输入的文字，区分未保存内容和已保存计划。应用层组织保存、开仓，以及等待、失败和恢复的反馈。平台桥接把请求送到后台，再把可信结果带回界面。它与图表编辑同一份宿主草稿，用版本号拦住过期修改。关闭侧栏，只结束这个界面；不应停止执行或销毁图表会话。图表暂不可用时，侧栏也应能走通已有交易能力。
Trade Core：把交易做到底
契约层统一计划、命令和交易事实；领域层负责纯计算。Engine 是状态机：输入命令与事实，输出状态和待执行动作。它不直接联网，也不偷偷读取系统时间。Runtime 按账户组织处理：先落库，再发送，再接收事实。存储、时钟、行情和交易接口，通过端口注入。五个场所各有适配器，把不同接口翻译成统一事实。同一内核供不同宿主消费；各宿主接入仍分别验收。
一次点击，三道边界
第一道边界：图表或侧栏提交意图，宿主检查计划版本。旧窗口的修改，不能盖掉刚保存的新计划。第二道边界：开仓服务用可信证据完成报价、冻结和启动。这是一次 OPEN 内部的步骤，不是让用户再点三个按钮。第三道边界：请求被接受，不等于已经成交或已有止损保护。内核依据真实成交更新仓位，再建立对应数量的保护。界面读取这些状态，不能自己把“已发送”推断为“成功”。
超时之后，钱动了吗？
订单发出后网络超时，交易所可能其实已经成交。此时状态是 UNKNOWN：结果未知，不能当成下单失败。如果直接再发一单，就可能买了两次。系统要沿用原订单身份查询，吸收可能迟到的成交。撤单也是如此：撤掉的是剩余量，已成交部分仍要保护。进程重启时先读持久状态并对账，再恢复发送和调度。难点在于每个分支都要守住数量、身份和保护。
58 项操作，分成 13 类
内核操作目录里，有 58 项操作，归入 13 类。从报价、入场，到仓位保护、移动止损、退出和反手。还包括批量平仓、撤单、标签，以及交易状态读取。再往后，是账户设置、算法版本、定时任务和对账。还有本机与远端之间，唯一执行权的变更和移交。例如反手，要先确认旧仓归零，再开始反向入场。这里数的是目录条目，包含内部事件与查询；不是 58 个按钮。快照中 3 项标为未交付；其余按各能力组记录内核交付。
58 × 6 = 348 个检查格
每项操作，还要沿六条轴检查它在不同情况下的行为。顺利完成、被规则拒绝，以及交易所写入结果未知。还有迟到事实、重启恢复，以及重复投递同一请求。重复投递要得到同一结果，不能重复产生交易副作用。58 乘以 6，得到 348 个矩阵检查格。其中 296 格适用，52 格明确不适用，比如只读查询不下单。这些是覆盖要求的数量，不是已通过的测试数量。
计划组合，已经过亿
再看规格里的计划空间，仅四场所基线就已经过亿。入场路线、场所、运行与持仓模式、方向，组成 1,400 种组合。再乘 16 种数量方式、8 种最小止损配置。再乘主保护与价格求解的 666 种组合。合计 119,347,200 种，还没加入多段保护和故障时序。这是规格定义的离散空间，未加入 Hyperliquid，也不是实测数。验证要抓等价类、边界和不变量，再用真实场所证据校准。三个领域划清边界，才能让每一种复杂性有明确的负责人。
展开 13 类操作与数字口径
按 2026.09.08 项目内核操作目录统计：58 项命令、内部事件与权威读取，不含 UI 草稿操作。其中 3 项标为未交付：放弃未启动确认、外部仓位认领、放弃未发送意图。其余按各能力组记录内核交付，产品接线与各场所验收分别推进。
| 操作类别 | 目录项数 |
|---|---|
| 报价与授权 | 5 |
| 入场控制 | 7 |
| 仓位保护 | 7 |
| 移动止损与平保 | 3 |
| 退出与反手 | 5 |
| 标签与备注 | 1 |
| 快捷操作 | 7 |
| 权威读取 | 6 |
| 账户设置 | 5 |
| 算法版本 | 5 |
| 触发器与定时任务 | 2 |
| 对账与归属 | 3 |
| 唯一执行权 | 2 |
故障矩阵：58 项 × 6 条检查轴 = 348 格，296 格适用、52 格明确不适用。这是覆盖要求，不代表已有 348 个测试通过。
计划空间：1,400 种入场等组合 × 16 种数量方式 × 8 种最小止损配置 × 666 种主保护与求解组合 = 119,347,200。它来自 Binance、OKX、Bybit、Bitget 四场所的规格基线，未加入 Hyperliquid、多段保护、故障时序与连续数值；不表示所有组合都可实盘执行或已被逐一测试。
两种权威，不能混淆
宿主管理唯一可编辑草稿与版本，内核管理执行、成交、仓位与保护事实。界面提交意图，再读取可信结果；“已经画出来”和“已经成交且受保护”分别取证。
把异常当成正常设计的一部分
请求超时后查原单，撤单后吸收迟到成交，重启后先对账再恢复。难度来自操作、状态与时序的交叉，也来自每条路径都要守住数量、身份和保护。
AI 会写代码，产品为什么还难做
Coding agent 是能读代码、改代码、跑测试的 AI 开发助手。我让它做一个看似只需“三条线”的工具，却经历了废弃、重开和反复返工。这段故事里，难点从写代码转移到了判断：做什么，做到哪一步，怎样才算真的能用。
让 AI 做个交易工具，看起来只是拖动三条线。
5:01 · 字幕讲解可暂停阅读 / 全屏观看
阅读开发复盘文字稿
画出来，只是开始
让 AI 做个交易工具，看起来只是拖动三条线。入场、止损、止盈，画出来似乎就完成了。但每条线都要对应正确的品种、价格和计划。刷新页面、切换图表、重启插件后，也得一致。画面有了，产品为什么还是用不起来？这成了整个开发过程中，反复出现的问题。
修一处，牵动一片
旧项目把找图表、算坐标、处理拖动，以及解释交易含义，都挤在同一块代码里。它会挑页面上最大的画布，猜哪个才是主图。就像靠外形认房间，装修后可能再也找不到。修一处，牵动一片，局部补丁越来越难奏效。最终，我保留原型、放弃旧实现，重新开发。这次先拆清：每一部分究竟负责什么。
文档，也会长歪
重开后，本想先写清最基础的操作。代理却把规格扩成了近 4,000 行的平台设计。眼前只需几种操作，却提前搭起未来的框架。后来，主规格重新收敛到约 322 行。计算公式和设计决策，拆到各自的文档。拿掉当前用不到的设计，才看得清当前目标。
重开，也会走远
新项目的职责清楚了，范围却再次膨胀。第一个使用流程还没稳定，就开始同时设计多种计划、多种图表，以及插件和桌面端。第一间房还没住过，已经在规划整座小区。架构图越来越完整，用户却仍可能看不到线。重开项目，并不会自动解决范围失控。
测试，走了另一扇门
有些测试先在后台放好草稿，再检查能否画线。真实用户第一次打开，草稿却是空的。最关键的初始化，恰好被测试跳过去了。于是：验收时有线，用户打开却没线。测试通过有价值，但它走过的那条路，必须和用户真正走的路对得上。
越改，越像绕圈
审查发现风险，就加保护；嫌复杂，又要精简。反复加减，有时连必要的清理也被删了。早该消失的旧线还留着，重启恢复也坏了。还有一次，精简任务反而加了未要求的重试。随后又用测试，把这个新策略固定下来。没有稳定的判断标准，审查也会变成绕圈。
先退到，零条线
第三代图表，我先退回完全不画线的版本。第一步删除 9,676 行，新增 1,384 行，这些改动包含代码、测试和文档。先查清：谁保存计划，谁负责启动和清理。再验证：插件重启后，计划能否正确恢复。这条小链路稳定了，再逐项恢复画线和编辑。主动缩小范围，才重新得到可以验证的进展。
两块屏幕，一本账
图表和侧栏，就像同一家店的两块屏幕。如果各自记账，拖完价格再刷新，就可能对不上。现在，后台保存同一份权威计划。图上拖动先预览，松手后再提交修改。图表页面里的价格只作参考，不直接改账。真正下单前，还要重新核对价格和风险。不能照着一张可能过期的画面执行交易。
AI 的手脚，更好用了
从 GPT-5.6 换到 GPT-6 Astra 后，我的体感是：启动插件、操作浏览器，代理没以前那么容易卡住了。新版模型也更重视跨代码、浏览器和软件的操作。代理能亲手走一遍，反馈就更接近真实使用。从「代码看着没问题」，到「按钮按了没反应」。这是个人开发体感，工具和环境也同时在变。模型更强，可以用来把真实验证做得更充分。
从头到尾，真的走一遍
成功下一笔单之后，还有很多问题要回答。重启会不会重复下单？保护是否仍然有效？这个项目，目前仍在打磨这些边界。每一步真实使用，都可能暴露新的问题。用 AI 开发产品，可以先抓住三件事：明确行为、缩小范围、从用户入口验证。代理越能写，人越要说清方向和完成标准。
产品行为先说清
原型说明用户怎样操作，规格说明计算与安全规则。工程架构不能偷偷替产品做决定。
先走通一条路径
先从首次打开走到修改、保存、关闭和恢复，再扩展宿主与能力。缩小范围，也要保留真实生命周期所需的保障。
从用户入口开始测试
首次打开能否使用，刷新、关闭和出错后能否恢复。测试应走过用户真正会走的路。
继续了解
多交易所内核已接入，图表与侧栏界面持续完善。当前在模拟盘与测试网中验证各场所的执行、保护和恢复。这里分享的是产品思路和开发中的判断。
参考资料
- 想进一步理解以损定量：CME 的仓位规模说明。
- 想了解模型的通用执行能力：OpenAI 的 Astra 说明。片中的效率感受来自个人实践，并非模型对照实验。