paper trading 这个方向一直不温不火但需求量其实很稳定想练交易策略又不敢拿真金白银上回测数据再漂亮也不敢确定实盘能不能用。Show HN 上这个项目把两件事结合在了一起——模拟交易加 AI 教练而且覆盖全球市场。换句话说它不只是给你一个虚拟盘下单界面还会像教练一样点评你的交易行为、提示风险、帮你做复盘。这篇文章会从产品形态、部署思路、功能验证到 AI 教练的实现逻辑做一个完整拆解。先看核心卖点。免费、模拟盘、全球市场、AI 教练这四点合在一起正好踩中两类人的需求一类是想练手的个人交易者另一类是想把 LLM 接进交易场景的开发者。对开发者来说这个项目还多了一层价值——它展示了一个 AI Agent 在金融领域落地的完整链路行情数据、订单管理、持仓状态、LLM 上下文构建每一步都是可借鉴的工程实践。这篇文章会分三块来讲第一这个平台能做什么适合哪些场景边界在哪里第二从技术上拆解模拟交易和 AI 教练的实现思路包括数据接入、状态管理、提示词设计第三给出一套完整的本地部署、功能测试、API 调用和批量任务的验证方法。如果你关心 AI 在量化交易、策略学习、自动化复盘中的应用这篇可以直接收藏。1. 核心能力速览在动手之前先把项目的关键信息列清楚。这个项目的输入材料来自 Show HN 标题具体技术参数、开源协议、部署方式还需要按实际仓库说明为准下面这张表给出的是基于项目定位的保守整理。能力项说明项目类型免费模拟交易平台Paper Trading核心功能虚拟资金模拟下单、多市场行情、AI 交易教练AI 能力交易行为分析、风险提示、复盘建议依赖 LLM 推理市场范围全球市场具体支持股票、外汇、加密货币等以实际项目为准真实资金不涉及属于模拟交易收费模式标题标注 Free具体免费额度以项目说明为准部署方式不确定需按仓库 README 确认常见形式是 Web 服务API 支持不确定下文给出通用接口验证模板批量任务可行可通过脚本批量执行策略模拟、批量复盘适合用户交易学习者、策略开发者、AI Agent 应用开发者、金融科技爱好者这里需要重点强调一个概念paper trading 和真实交易是两套逻辑。模拟盘能验证的是策略逻辑、订单流程、心态训练但不能验证真实市场的滑点、流动性、撮合延迟和极端行情冲击。所以无论这个平台做得多完善都不能把它当成实盘结果预测器。2. 适用场景与使用边界2.1 适合谁第一类是刚接触交易的新手。很多人对交易的理解停留在“低买高卖”但真正难的是仓位管理、止损设置、情绪控制。模拟盘配合 AI 教练可以提供类似“你这笔单子止损位离得太远风险收益比不合理”这样的反馈这比自己去翻书学要直观得多。第二类是量化策略爱好者。虽然这个平台不一定提供完整回测框架但如果它支持 API 或批量操作就可以把策略信号接到模拟盘上做“前向测试”也就是用虚拟资金跑一段时间的实盘数据观察策略在真实行情环境下的表现。这比纯历史回测更有参考价值。第三类是 AI 应用开发者。AI 教练这个功能本质上是一个金融领域的 RAG 或工具调用应用。开发者可以研究它如何把行情数据、持仓数据、历史交易记录组织成 LLM 的上下文如何设计提示词让模型给出有约束的交易建议这些思路可以迁移到其他垂直行业。2.2 能解决什么问题降低试错成本不用真实资金就能验证交易想法。建立交易纪律AI 教练可以持续提醒仓位、止损、情绪化交易等问题。多市场观察一个平台看全球市场省去切换多个终端的时间。教学演示适合培训机构、高校实验室作为案例。2.3 不适合什么场景真实交易执行模拟盘不产生真实订单不能直接对接实盘。投资建议获取AI 教练的输出是辅助参考不是投资建议。高频交易测试模拟盘的撮合延迟和真实高频环境差距很大。严格回测如果要做专业的策略回测还需要专门的回测引擎和数据源。2.4 合规与安全边界涉及交易和 AI 生成内容有三条底线必须明确。第一平台不提供投资建议AI 教练的输出属于教育辅助内容任何交易决策都需要用户独立判断。第二如果平台接入全球市场数据不同地区有不同的金融数据授权和监管要求使用时需要注意合规边界。第三如果平台提供 API使用 API key 时要保护好密钥不要提交到公共仓库。3. 产品形态与功能拆解一个完整的 paper trading 平台可以拆成四层数据层、交易层、AI 层、应用层。3.1 数据层数据层负责提供行情数据。全球市场意味着要接入多个市场的数据源比如美股、A 股、港股、外汇、加密货币等。不同市场的交易时段、数据格式、字段定义都不一样工程上通常采用统一的数据模型做适配例如统一为 symbol、timestamp、open、high、low、close、volume 这样的结构。如果平台免费开放行情数据可能来自免费 API例如某些加密货币交易所的公开行情、美股 EOD 数据等。这类数据存在延迟和覆盖不全的问题实时性要求不高的模拟交易场景可以接受但如果做分钟级策略验证数据质量就需要重新评估。3.2 交易层交易层是模拟盘的核心。用户下单后系统根据当前行情计算成交价更新持仓和保证金状态。这里有几个关键设计点订单状态机pending、filled、partial_filled、cancelled、rejected。账户模型可用资金、冻结资金、持仓市值、总资产、当日盈亏。订单撮合模拟盘通常使用当前最新价直接成交不考虑滑点更真实的模拟会加入手续费和固定滑点模型。# 模拟订单状态机示例伪代码 class OrderStatus: PENDING pending FILLED filled PARTIAL_FILLED partial_filled CANCELLED cancelled REJECTED rejected class SimulatedAccount: def __init__(self, initial_cash): self.cash initial_cash self.positions {} self.orders []3.3 AI 层AI 教练是项目的差异化功能。它的输入包括用户的历史交易记录、当前持仓、市场环境、用户提出的问题输出是结构化的分析建议。实现方式上通常是调用 LLM API把交易数据整理成文本提示词再用工具调用或函数调用的方式约束输出格式。AI 教练的关键不是模型本身而是上下文工程。你要让 LLM 理解这个用户的交易风格、风险偏好、历史错误然后给出针对性建议。这就需要在对话开始前构建一个结构化的“用户交易档案”。3.4 应用层应用层就是用户看到的界面包括行情列表、下单面板、持仓页面、AI 教练聊天窗口、历史记录和统计报表。应用层还负责用户体系、登录认证、数据持久化。4. 本地部署与技术架构参考虽然项目具体的部署方式需要以仓库 README 为准但这类 Web 应用通常可以按下面的架构来理解。通过 GitHub 或 Show HN 页面获取代码后常见的技术栈是前端框架加后端框架加数据库加 LLM API 服务。4.1 环境准备需要准备的内容包括Node.js 或 Python 运行时取决于后端技术栈。包管理工具npm、yarn、pip 或 poetry。数据库SQLite 适合本地开发PostgreSQL 适合生产环境。LLM API keyAI 教练功能需要调用大模型接口。行情数据源 API key如果平台使用第三方行情服务。4.2 通用启动步骤没有拿到具体项目的启动命令前先给出一套通用流程。实际执行时以项目 README 中的命令为准。# 1. 克隆项目代码 git clone https://github.com/your-project/paper-trading.git cd paper-trading # 2. 安装后端依赖示例具体以项目为准 pip install -r requirements.txt # 3. 安装前端依赖示例具体以项目为准 cd frontend npm install cd .. # 4. 配置环境变量 cp .env.example .env # 编辑 .env填入 LLM API Key、数据库地址、行情数据源 Key # 5. 启动数据库迁移示例 python manage.py migrate # 6. 启动后端服务 python app.py --host 127.0.0.1 --port 8000 # 7. 启动前端开发服务示例 cd frontend npm run dev启动后打开浏览器访问http://127.0.0.1:8000如果页面能看到行情列表和下单界面说明服务已经跑起来了。4.3 Docker 部署参考很多项目会提供 Docker Compose 配置这样可以避免本地环境依赖问题。可以参考下面的编排结构实际内容需要按项目仓库中的配置文件为准。version: 3.8 services: backend: build: ./backend ports: - 8000:8000 env_file: - .env depends_on: - db frontend: build: ./frontend ports: - 3000:3000 depends_on: - backend db: image: postgres:15 environment: POSTGRES_USER: paper POSTGRES_PASSWORD: paper POSTGRES_DB: paper_trading volumes: - pgdata:/var/lib/postgresql/data volumes: pgdata:5. 上手使用与功能测试平台跑起来之后建议按下面的顺序做一轮完整的功能测试。测试目的是确认核心链路是否可用行情展示、下单、持仓更新、AI 教练对话。5.1 测试环境准备准备一张测试记录表记录测试时间、市场、下单参数、系统反馈、AI 教练输出方便后面定位问题。5.2 行情展示测试测试目的确认行情数据能正常加载价格和涨跌幅持续刷新。操作步骤进入行情列表页面。切换到不同市场分类。观察行情刷新频率和异常数据。预期结果行情列表能展示至少一个市场的品种数据价格字段不为空。如果行情不刷新优先检查网络连接和数据源 API key 是否有效。如果某个市场完全没有数据可能是该市场数据源限制或需要单独配置。5.3 模拟下单测试测试目的验证订单能进入交易状态机持仓和资金正确更新。建议按下面几个用例逐项测试测试场景操作预期结果市价买入选择品种输入数量点击买入订单立即成交可用资金减少持仓增加限价买入设置低于当前价的价格订单进入 pending不立即成交市价卖出选择已有持仓品种点击卖出持仓减少资金增加取消订单对 pending 订单执行取消订单状态变为 cancelled余额不足输入超过可用资金的订单系统拒绝下单并给出提示这一轮测试最容易踩的坑是资金计算错误。比如买入后可用资金没有扣减、卖出后持仓数量不对这类问题往往出在订单成交和账户更新的逻辑没有使用事务导致数据不一致。5.4 AI 教练功能测试AI 教练是重点功能测试要多维度覆盖。先测基本信息检索向 AI 教练提问“帮我分析一下当前持仓的风险”观察它是否能结合当前持仓数据给出回答。如果回答没有引用持仓数据说明这个会话可能没有正确传递账户上下文。再测交易行为分析连续做几笔交易比如一次没有设置止损的买入、一次全仓买入然后问 AI 教练“复盘一下我的交易习惯”观察它是否能识别出风险点。最后测边界情况问一个与交易无关的话题观察 AI 是否有明确的拒绝策略避免模型被越狱后输出不受控制的内容。# 一个可用于测试的 AI 教练提示词模板参考实现 请基于以下交易数据给出复盘建议 - 账户总资产10000 USD - 当前持仓BTC/USDT 多单数量 0.5开仓价 60000当前价 58000 - 最近交易记录 1. 买入 BTC/USDT数量 0.5无止损设置 2. 卖出 ETH/USDT持仓仅 2 小时后卖出收益 -5% - 用户问题我的交易有什么问题 要求 - 只基于给定数据回答 - 指出风险点不给出具体买卖建议 - 输出格式风险点 改进建议5.5 历史记录与统计测试模拟盘的价值在于复盘。测试历史记录页面能否按时间筛选交易记录能否看到累计收益率、胜率、最大回撤等统计指标。如果项目支持导出交易记录建议测试导出功能方便后续在外部工具里做分析。6. 接口 API 与批量任务如果平台提供 API就可以把模拟盘接入到自己的脚本里做批量策略测试。这里给出通用调用模板实际接口路径、参数和鉴权方式需要按项目文档调整。6.1 API 调用示例import requests BASE_URL http://127.0.0.1:8000/api/v1 API_KEY your_api_key_here headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } # 获取账户信息 resp requests.get(f{BASE_URL}/account, headersheaders, timeout30) print(账户信息:, resp.json()) # 提交一个模拟市价买单 order_payload { symbol: AAPL, side: buy, order_type: market, quantity: 10 } resp requests.post(f{BASE_URL}/orders, jsonorder_payload, headersheaders, timeout30) print(下单结果:, resp.json())6.2 批量策略模拟假设你有一个简单的均线策略想把它在模拟盘上跑 20 个交易日可以用脚本循环执行。关键点是控制请求频率避免触发服务端的限流。import time import requests BASE_URL http://127.0.0.1:8000/api/v1 API_KEY your_api_key_here headers {Authorization: fBearer {API_KEY}, Content-Type: application/json} # 模拟一批交易信号 signals [ {symbol: AAPL, side: buy, quantity: 5}, {symbol: TSLA, side: sell, quantity: 2}, {symbol: BTC/USDT, side: buy, quantity: 0.01}, ] for signal in signals: resp requests.post(f{BASE_URL}/orders, jsonsignal, headersheaders, timeout30) print(signal[symbol], resp.status_code, resp.json()) time.sleep(1) # 控制频率避免触发限流批量任务的工程要点每次脚本执行前清理上一次的测试订单避免账户数据污染。为每批任务生成一个批次 ID方便后续对账。记录每个请求的响应状态失败时自动重试重试次数建议不超过 3 次。批量测试后导出持仓和交易记录做收益分析。6.3 Webhook 与定时任务更高级的用法是把模拟盘接进定时任务。比如每天收盘后自动获取持仓、调用 AI 教练生成复盘报告、推送到企业微信或钉钉。这样可以把模拟盘变成一个持续运行的策略验证机器人。# 定时复盘任务参考逻辑 import schedule import time def daily_review_job(): account get_account_info() review ai_coach_review(account) send_to_feishu(review) schedule.every().day.at(20:00).do(daily_review_job) while True: schedule.run_pending() time.sleep(1)这个思路适合开发者深入研究AI 教练不只是聊天机器人它可以变成自动化流程中的一个节点参与数据采集、分析、报告生成。7. AI 教练的实现思路分析AI 教练是平台上最有技术含量的部分。从工程角度看它就是一个垂直领域的 LLM Agent核心要解决三个问题上下文怎么组织、输出怎么约束、知识边界怎么控制。7.1 上下文组织LLM 没有记忆每次调用都需要把相关数据放进 prompt。AI 教练需要的数据包括账户摘要、持仓明细、最近交易记录、行情快照、用户当前问题。如果数据量大需要做截断或摘要。系统提示词参考框架 你是一个模拟交易复盘教练。你的职责是帮助用户识别交易行为中的风险点。 每次回答前你会收到以下信息 - 用户账户概览总资产、可用资金、今日盈亏 - 当前持仓列表品种、数量、开仓价、当前价、浮动盈亏 - 最近 20 笔交易记录时间、方向、品种、数量、盈亏 - 用户的最新问题 你的输出要求 1. 只基于给定数据分析不编造行情或交易记录。 2. 明确指出用户交易行为中的风险点。 3. 不提供任何形式的投资建议和买卖指令。 4. 回答尽量简洁条目化输出。这个提示词设计的核心是限制模型不要越界。金融场景中LLM 的幻觉危害很大它可能编造一个不存在的持仓来分析或者给出看似合理但完全错误的建议。所以上下文数据的准确性非常关键。7.2 输出结构化为了让 AI 教练的输出能稳定解析建议使用函数调用或 JSON Schema 约束输出格式。例如要求模型返回下面的结构{ risk_points: [未设置止损, 单次仓位过重], strengths: [交易频率控制较好], suggestions: [建议每笔订单设置固定比例止损] }结构化输出可以方便前端渲染也方便后续做数据聚合比如统计一段时间内 AI 教练识别出的高频风险点。7.3 知识边界控制要明确告诉模型哪些问题可以回答、哪些不能回答。涉及实时行情预测、具体买卖点位的问题应该给出拒绝话术。平台可以在提示词层面做控制也可以在服务端做输入输出过滤。8. 资源占用与性能观察虽然这个项目不是典型的模型推理应用但资源占用同样要关注。如果平台部署在云服务器上CPU、内存、带宽是主要成本AI 教练调用 LLM API 则是按 token 计费。8.1 什么环节最耗资源行情推送如果使用 WebSocket 推送实时行情长连接数量和消息频率会消耗较多带宽。数据持久化全球市场数据量大如果不做定期清理数据库会快速增长。AI 教练调用单次对话消耗的 token 取决于上下文长度和回答长度高频调用会显著增加成本。8.2 性能观察方法观察服务端的 CPU 和内存使用可以使用系统命令。# 查看后端进程资源占用 top -p $(pgrep -f python app.py | head -1) # 查看容器资源占用如果是 Docker 部署 docker stats重点观察三个指标行情推送高峰时 CPU 是否打满、数据库磁盘增长速率、AI 教练接口响应时间。如果 AI 教练接口耗时超过 10 秒优先检查是不是 prompt 中塞入了过长的交易记录可以考虑缩短历史记录长度或做摘要。8.3 降低资源占用的手段对行情数据做缓存减少数据库访问。对 AI 教练的历史交易上下文按时间窗口截断例如只取最近 20 笔。增加缓存层相同的复盘请求结果可以缓存一段时间。定期归档历史订单数据。9. 常见问题与排查方法从部署到使用paper trading 平台的问题主要集中在数据源、AI 接口和交易状态一致性上。下面给出一份排查表。问题现象可能原因排查方式解决方案页面启动后行情列表空白数据源 API key 失效或网络不通检查后端日志、测试数据源接口重新申请 API key检查网络策略下单后持仓没有更新订单状态机或事务逻辑异常查看后端日志中的订单处理记录检查数据库事务确认订单是否进入 filled 状态AI 教练不回复LLM API key 配置错误或余额不足直接测试 LLM API 是否可调用检查环境变量、API key 权限AI 教练回答的内容与持仓无关上下文构建逻辑缺失检查是否把账户数据传入了提示词修复上下文拼接逻辑行情延迟明显数据源本身有延迟或轮询频率过低对比官方行情源更换数据源或提高数据刷新频率Docker 部署时端口冲突宿主机端口被占用执行netstat -ano或lsof -i查看端口占用修改 docker-compose 或启动脚本中的端口映射批量脚本执行时报错限流请求频率超过服务端限制检查返回的 HTTP 状态码和错误信息增加 sleep 间隔降低并发数据库磁盘增长过快周期行情数据累积过多查看数据表大小建立归档策略定期清理过期数据这里面最常见的坑有两个。一个是用户图省事把 AI 教练当成实时行情预测器来用问“明天 BTC 是涨还是跌”这种问题应该被拒绝。另一个是在部署时没有配置好 LLM API导致 AI 功能不可用但行情和交易功能正常容易误判为平台整体故障。10. 最佳实践与使用建议10.1 个人学习场景如果你是新手建议给自己定一个训练目标比如“一个月内做到单笔亏损不超过总资金 2%”。每天收盘后用 AI 教练做一次复盘重点看它识别的风险点。坚持两周你会发现自己的交易习惯有明显变化。10.2 开发者场景如果你是开发者建议优先研究三件事。第一平台的订单状态机和账户模型是怎么设计的这直接决定了系统能否扩展成真实交易系统。第二AI 教练的上下文构建方式这是 LLM 应用落地的通用难题。第三数据层如何统一处理多市场行情这是金融应用的通用基础设施问题。10.3 二次开发建议如果项目开源可以考虑下面几个扩展方向增加策略回测引擎把模拟盘和回测结合。增加自定义指标监控例如当账户回撤超过阈值时自动通知。增加 AI 教练的知识库让它可以回答更多市场基础知识。增加多账户支持方便团队共用一套模拟盘。接入更多数据源解决单一数据源覆盖不全的问题。10.4 合规提醒所有使用这个平台的用户都需要注意模拟交易和真实交易的差异。模拟盘中的盈利不代表真实交易能盈利。平台和 AI 教练提供的信息都不构成投资建议任何投资决策都需要自己负责。如果要把项目用于商业目的需要确认平台的开源协议、数据源授权范围、以及目标市场的金融监管要求。11. 总结与下一步这个项目的核心价值不在于模拟交易本身——这类平台已经有很多而在于它把 AI 教练和模拟交易结合在了一起。从技术角度看它是一个典型的 LLM 垂直应用有实时数据输入、有状态管理、有约束输出、有用户交互。这类架构放在金融交易之外的其他领域比如模拟面试、健身教练、投资辅助思路也是完全通用的。最值得先验证的功能是 AI 教练能否准确读取并分析你的持仓数据。如果这个链路是通的说明平台的数据层和 AI 层已经打通后续做自动化复盘、批量策略模拟就都有了基础。最容易踩的坑在数据源限制和 AI 接口成本上。免费数据源通常不稳定LLM API 调用也不是无限制的长时间高频使用需要关注成本。建议第一次使用时先跑通最小链路注册账户、下一笔模拟单、让 AI 教练做一次复盘确认三个环节都没问题再决定要不要深入使用。下一步可以考虑的是把模拟盘的数据导出结合 Python 做策略分析或者用 Webhook 把 AI 教练的每日复盘推送到自己的聊天工具里。这个项目作为学习和二次开发的起点是值得收藏的。 模拟交易+AI教练：全球市场免费平台的技术拆解
paper trading 这个方向一直不温不火但需求量其实很稳定想练交易策略又不敢拿真金白银上回测数据再漂亮也不敢确定实盘能不能用。Show HN 上这个项目把两件事结合在了一起——模拟交易加 AI 教练而且覆盖全球市场。换句话说它不只是给你一个虚拟盘下单界面还会像教练一样点评你的交易行为、提示风险、帮你做复盘。这篇文章会从产品形态、部署思路、功能验证到 AI 教练的实现逻辑做一个完整拆解。先看核心卖点。免费、模拟盘、全球市场、AI 教练这四点合在一起正好踩中两类人的需求一类是想练手的个人交易者另一类是想把 LLM 接进交易场景的开发者。对开发者来说这个项目还多了一层价值——它展示了一个 AI Agent 在金融领域落地的完整链路行情数据、订单管理、持仓状态、LLM 上下文构建每一步都是可借鉴的工程实践。这篇文章会分三块来讲第一这个平台能做什么适合哪些场景边界在哪里第二从技术上拆解模拟交易和 AI 教练的实现思路包括数据接入、状态管理、提示词设计第三给出一套完整的本地部署、功能测试、API 调用和批量任务的验证方法。如果你关心 AI 在量化交易、策略学习、自动化复盘中的应用这篇可以直接收藏。1. 核心能力速览在动手之前先把项目的关键信息列清楚。这个项目的输入材料来自 Show HN 标题具体技术参数、开源协议、部署方式还需要按实际仓库说明为准下面这张表给出的是基于项目定位的保守整理。能力项说明项目类型免费模拟交易平台Paper Trading核心功能虚拟资金模拟下单、多市场行情、AI 交易教练AI 能力交易行为分析、风险提示、复盘建议依赖 LLM 推理市场范围全球市场具体支持股票、外汇、加密货币等以实际项目为准真实资金不涉及属于模拟交易收费模式标题标注 Free具体免费额度以项目说明为准部署方式不确定需按仓库 README 确认常见形式是 Web 服务API 支持不确定下文给出通用接口验证模板批量任务可行可通过脚本批量执行策略模拟、批量复盘适合用户交易学习者、策略开发者、AI Agent 应用开发者、金融科技爱好者这里需要重点强调一个概念paper trading 和真实交易是两套逻辑。模拟盘能验证的是策略逻辑、订单流程、心态训练但不能验证真实市场的滑点、流动性、撮合延迟和极端行情冲击。所以无论这个平台做得多完善都不能把它当成实盘结果预测器。2. 适用场景与使用边界2.1 适合谁第一类是刚接触交易的新手。很多人对交易的理解停留在“低买高卖”但真正难的是仓位管理、止损设置、情绪控制。模拟盘配合 AI 教练可以提供类似“你这笔单子止损位离得太远风险收益比不合理”这样的反馈这比自己去翻书学要直观得多。第二类是量化策略爱好者。虽然这个平台不一定提供完整回测框架但如果它支持 API 或批量操作就可以把策略信号接到模拟盘上做“前向测试”也就是用虚拟资金跑一段时间的实盘数据观察策略在真实行情环境下的表现。这比纯历史回测更有参考价值。第三类是 AI 应用开发者。AI 教练这个功能本质上是一个金融领域的 RAG 或工具调用应用。开发者可以研究它如何把行情数据、持仓数据、历史交易记录组织成 LLM 的上下文如何设计提示词让模型给出有约束的交易建议这些思路可以迁移到其他垂直行业。2.2 能解决什么问题降低试错成本不用真实资金就能验证交易想法。建立交易纪律AI 教练可以持续提醒仓位、止损、情绪化交易等问题。多市场观察一个平台看全球市场省去切换多个终端的时间。教学演示适合培训机构、高校实验室作为案例。2.3 不适合什么场景真实交易执行模拟盘不产生真实订单不能直接对接实盘。投资建议获取AI 教练的输出是辅助参考不是投资建议。高频交易测试模拟盘的撮合延迟和真实高频环境差距很大。严格回测如果要做专业的策略回测还需要专门的回测引擎和数据源。2.4 合规与安全边界涉及交易和 AI 生成内容有三条底线必须明确。第一平台不提供投资建议AI 教练的输出属于教育辅助内容任何交易决策都需要用户独立判断。第二如果平台接入全球市场数据不同地区有不同的金融数据授权和监管要求使用时需要注意合规边界。第三如果平台提供 API使用 API key 时要保护好密钥不要提交到公共仓库。3. 产品形态与功能拆解一个完整的 paper trading 平台可以拆成四层数据层、交易层、AI 层、应用层。3.1 数据层数据层负责提供行情数据。全球市场意味着要接入多个市场的数据源比如美股、A 股、港股、外汇、加密货币等。不同市场的交易时段、数据格式、字段定义都不一样工程上通常采用统一的数据模型做适配例如统一为 symbol、timestamp、open、high、low、close、volume 这样的结构。如果平台免费开放行情数据可能来自免费 API例如某些加密货币交易所的公开行情、美股 EOD 数据等。这类数据存在延迟和覆盖不全的问题实时性要求不高的模拟交易场景可以接受但如果做分钟级策略验证数据质量就需要重新评估。3.2 交易层交易层是模拟盘的核心。用户下单后系统根据当前行情计算成交价更新持仓和保证金状态。这里有几个关键设计点订单状态机pending、filled、partial_filled、cancelled、rejected。账户模型可用资金、冻结资金、持仓市值、总资产、当日盈亏。订单撮合模拟盘通常使用当前最新价直接成交不考虑滑点更真实的模拟会加入手续费和固定滑点模型。# 模拟订单状态机示例伪代码 class OrderStatus: PENDING pending FILLED filled PARTIAL_FILLED partial_filled CANCELLED cancelled REJECTED rejected class SimulatedAccount: def __init__(self, initial_cash): self.cash initial_cash self.positions {} self.orders []3.3 AI 层AI 教练是项目的差异化功能。它的输入包括用户的历史交易记录、当前持仓、市场环境、用户提出的问题输出是结构化的分析建议。实现方式上通常是调用 LLM API把交易数据整理成文本提示词再用工具调用或函数调用的方式约束输出格式。AI 教练的关键不是模型本身而是上下文工程。你要让 LLM 理解这个用户的交易风格、风险偏好、历史错误然后给出针对性建议。这就需要在对话开始前构建一个结构化的“用户交易档案”。3.4 应用层应用层就是用户看到的界面包括行情列表、下单面板、持仓页面、AI 教练聊天窗口、历史记录和统计报表。应用层还负责用户体系、登录认证、数据持久化。4. 本地部署与技术架构参考虽然项目具体的部署方式需要以仓库 README 为准但这类 Web 应用通常可以按下面的架构来理解。通过 GitHub 或 Show HN 页面获取代码后常见的技术栈是前端框架加后端框架加数据库加 LLM API 服务。4.1 环境准备需要准备的内容包括Node.js 或 Python 运行时取决于后端技术栈。包管理工具npm、yarn、pip 或 poetry。数据库SQLite 适合本地开发PostgreSQL 适合生产环境。LLM API keyAI 教练功能需要调用大模型接口。行情数据源 API key如果平台使用第三方行情服务。4.2 通用启动步骤没有拿到具体项目的启动命令前先给出一套通用流程。实际执行时以项目 README 中的命令为准。# 1. 克隆项目代码 git clone https://github.com/your-project/paper-trading.git cd paper-trading # 2. 安装后端依赖示例具体以项目为准 pip install -r requirements.txt # 3. 安装前端依赖示例具体以项目为准 cd frontend npm install cd .. # 4. 配置环境变量 cp .env.example .env # 编辑 .env填入 LLM API Key、数据库地址、行情数据源 Key # 5. 启动数据库迁移示例 python manage.py migrate # 6. 启动后端服务 python app.py --host 127.0.0.1 --port 8000 # 7. 启动前端开发服务示例 cd frontend npm run dev启动后打开浏览器访问http://127.0.0.1:8000如果页面能看到行情列表和下单界面说明服务已经跑起来了。4.3 Docker 部署参考很多项目会提供 Docker Compose 配置这样可以避免本地环境依赖问题。可以参考下面的编排结构实际内容需要按项目仓库中的配置文件为准。version: 3.8 services: backend: build: ./backend ports: - 8000:8000 env_file: - .env depends_on: - db frontend: build: ./frontend ports: - 3000:3000 depends_on: - backend db: image: postgres:15 environment: POSTGRES_USER: paper POSTGRES_PASSWORD: paper POSTGRES_DB: paper_trading volumes: - pgdata:/var/lib/postgresql/data volumes: pgdata:5. 上手使用与功能测试平台跑起来之后建议按下面的顺序做一轮完整的功能测试。测试目的是确认核心链路是否可用行情展示、下单、持仓更新、AI 教练对话。5.1 测试环境准备准备一张测试记录表记录测试时间、市场、下单参数、系统反馈、AI 教练输出方便后面定位问题。5.2 行情展示测试测试目的确认行情数据能正常加载价格和涨跌幅持续刷新。操作步骤进入行情列表页面。切换到不同市场分类。观察行情刷新频率和异常数据。预期结果行情列表能展示至少一个市场的品种数据价格字段不为空。如果行情不刷新优先检查网络连接和数据源 API key 是否有效。如果某个市场完全没有数据可能是该市场数据源限制或需要单独配置。5.3 模拟下单测试测试目的验证订单能进入交易状态机持仓和资金正确更新。建议按下面几个用例逐项测试测试场景操作预期结果市价买入选择品种输入数量点击买入订单立即成交可用资金减少持仓增加限价买入设置低于当前价的价格订单进入 pending不立即成交市价卖出选择已有持仓品种点击卖出持仓减少资金增加取消订单对 pending 订单执行取消订单状态变为 cancelled余额不足输入超过可用资金的订单系统拒绝下单并给出提示这一轮测试最容易踩的坑是资金计算错误。比如买入后可用资金没有扣减、卖出后持仓数量不对这类问题往往出在订单成交和账户更新的逻辑没有使用事务导致数据不一致。5.4 AI 教练功能测试AI 教练是重点功能测试要多维度覆盖。先测基本信息检索向 AI 教练提问“帮我分析一下当前持仓的风险”观察它是否能结合当前持仓数据给出回答。如果回答没有引用持仓数据说明这个会话可能没有正确传递账户上下文。再测交易行为分析连续做几笔交易比如一次没有设置止损的买入、一次全仓买入然后问 AI 教练“复盘一下我的交易习惯”观察它是否能识别出风险点。最后测边界情况问一个与交易无关的话题观察 AI 是否有明确的拒绝策略避免模型被越狱后输出不受控制的内容。# 一个可用于测试的 AI 教练提示词模板参考实现 请基于以下交易数据给出复盘建议 - 账户总资产10000 USD - 当前持仓BTC/USDT 多单数量 0.5开仓价 60000当前价 58000 - 最近交易记录 1. 买入 BTC/USDT数量 0.5无止损设置 2. 卖出 ETH/USDT持仓仅 2 小时后卖出收益 -5% - 用户问题我的交易有什么问题 要求 - 只基于给定数据回答 - 指出风险点不给出具体买卖建议 - 输出格式风险点 改进建议5.5 历史记录与统计测试模拟盘的价值在于复盘。测试历史记录页面能否按时间筛选交易记录能否看到累计收益率、胜率、最大回撤等统计指标。如果项目支持导出交易记录建议测试导出功能方便后续在外部工具里做分析。6. 接口 API 与批量任务如果平台提供 API就可以把模拟盘接入到自己的脚本里做批量策略测试。这里给出通用调用模板实际接口路径、参数和鉴权方式需要按项目文档调整。6.1 API 调用示例import requests BASE_URL http://127.0.0.1:8000/api/v1 API_KEY your_api_key_here headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } # 获取账户信息 resp requests.get(f{BASE_URL}/account, headersheaders, timeout30) print(账户信息:, resp.json()) # 提交一个模拟市价买单 order_payload { symbol: AAPL, side: buy, order_type: market, quantity: 10 } resp requests.post(f{BASE_URL}/orders, jsonorder_payload, headersheaders, timeout30) print(下单结果:, resp.json())6.2 批量策略模拟假设你有一个简单的均线策略想把它在模拟盘上跑 20 个交易日可以用脚本循环执行。关键点是控制请求频率避免触发服务端的限流。import time import requests BASE_URL http://127.0.0.1:8000/api/v1 API_KEY your_api_key_here headers {Authorization: fBearer {API_KEY}, Content-Type: application/json} # 模拟一批交易信号 signals [ {symbol: AAPL, side: buy, quantity: 5}, {symbol: TSLA, side: sell, quantity: 2}, {symbol: BTC/USDT, side: buy, quantity: 0.01}, ] for signal in signals: resp requests.post(f{BASE_URL}/orders, jsonsignal, headersheaders, timeout30) print(signal[symbol], resp.status_code, resp.json()) time.sleep(1) # 控制频率避免触发限流批量任务的工程要点每次脚本执行前清理上一次的测试订单避免账户数据污染。为每批任务生成一个批次 ID方便后续对账。记录每个请求的响应状态失败时自动重试重试次数建议不超过 3 次。批量测试后导出持仓和交易记录做收益分析。6.3 Webhook 与定时任务更高级的用法是把模拟盘接进定时任务。比如每天收盘后自动获取持仓、调用 AI 教练生成复盘报告、推送到企业微信或钉钉。这样可以把模拟盘变成一个持续运行的策略验证机器人。# 定时复盘任务参考逻辑 import schedule import time def daily_review_job(): account get_account_info() review ai_coach_review(account) send_to_feishu(review) schedule.every().day.at(20:00).do(daily_review_job) while True: schedule.run_pending() time.sleep(1)这个思路适合开发者深入研究AI 教练不只是聊天机器人它可以变成自动化流程中的一个节点参与数据采集、分析、报告生成。7. AI 教练的实现思路分析AI 教练是平台上最有技术含量的部分。从工程角度看它就是一个垂直领域的 LLM Agent核心要解决三个问题上下文怎么组织、输出怎么约束、知识边界怎么控制。7.1 上下文组织LLM 没有记忆每次调用都需要把相关数据放进 prompt。AI 教练需要的数据包括账户摘要、持仓明细、最近交易记录、行情快照、用户当前问题。如果数据量大需要做截断或摘要。系统提示词参考框架 你是一个模拟交易复盘教练。你的职责是帮助用户识别交易行为中的风险点。 每次回答前你会收到以下信息 - 用户账户概览总资产、可用资金、今日盈亏 - 当前持仓列表品种、数量、开仓价、当前价、浮动盈亏 - 最近 20 笔交易记录时间、方向、品种、数量、盈亏 - 用户的最新问题 你的输出要求 1. 只基于给定数据分析不编造行情或交易记录。 2. 明确指出用户交易行为中的风险点。 3. 不提供任何形式的投资建议和买卖指令。 4. 回答尽量简洁条目化输出。这个提示词设计的核心是限制模型不要越界。金融场景中LLM 的幻觉危害很大它可能编造一个不存在的持仓来分析或者给出看似合理但完全错误的建议。所以上下文数据的准确性非常关键。7.2 输出结构化为了让 AI 教练的输出能稳定解析建议使用函数调用或 JSON Schema 约束输出格式。例如要求模型返回下面的结构{ risk_points: [未设置止损, 单次仓位过重], strengths: [交易频率控制较好], suggestions: [建议每笔订单设置固定比例止损] }结构化输出可以方便前端渲染也方便后续做数据聚合比如统计一段时间内 AI 教练识别出的高频风险点。7.3 知识边界控制要明确告诉模型哪些问题可以回答、哪些不能回答。涉及实时行情预测、具体买卖点位的问题应该给出拒绝话术。平台可以在提示词层面做控制也可以在服务端做输入输出过滤。8. 资源占用与性能观察虽然这个项目不是典型的模型推理应用但资源占用同样要关注。如果平台部署在云服务器上CPU、内存、带宽是主要成本AI 教练调用 LLM API 则是按 token 计费。8.1 什么环节最耗资源行情推送如果使用 WebSocket 推送实时行情长连接数量和消息频率会消耗较多带宽。数据持久化全球市场数据量大如果不做定期清理数据库会快速增长。AI 教练调用单次对话消耗的 token 取决于上下文长度和回答长度高频调用会显著增加成本。8.2 性能观察方法观察服务端的 CPU 和内存使用可以使用系统命令。# 查看后端进程资源占用 top -p $(pgrep -f python app.py | head -1) # 查看容器资源占用如果是 Docker 部署 docker stats重点观察三个指标行情推送高峰时 CPU 是否打满、数据库磁盘增长速率、AI 教练接口响应时间。如果 AI 教练接口耗时超过 10 秒优先检查是不是 prompt 中塞入了过长的交易记录可以考虑缩短历史记录长度或做摘要。8.3 降低资源占用的手段对行情数据做缓存减少数据库访问。对 AI 教练的历史交易上下文按时间窗口截断例如只取最近 20 笔。增加缓存层相同的复盘请求结果可以缓存一段时间。定期归档历史订单数据。9. 常见问题与排查方法从部署到使用paper trading 平台的问题主要集中在数据源、AI 接口和交易状态一致性上。下面给出一份排查表。问题现象可能原因排查方式解决方案页面启动后行情列表空白数据源 API key 失效或网络不通检查后端日志、测试数据源接口重新申请 API key检查网络策略下单后持仓没有更新订单状态机或事务逻辑异常查看后端日志中的订单处理记录检查数据库事务确认订单是否进入 filled 状态AI 教练不回复LLM API key 配置错误或余额不足直接测试 LLM API 是否可调用检查环境变量、API key 权限AI 教练回答的内容与持仓无关上下文构建逻辑缺失检查是否把账户数据传入了提示词修复上下文拼接逻辑行情延迟明显数据源本身有延迟或轮询频率过低对比官方行情源更换数据源或提高数据刷新频率Docker 部署时端口冲突宿主机端口被占用执行netstat -ano或lsof -i查看端口占用修改 docker-compose 或启动脚本中的端口映射批量脚本执行时报错限流请求频率超过服务端限制检查返回的 HTTP 状态码和错误信息增加 sleep 间隔降低并发数据库磁盘增长过快周期行情数据累积过多查看数据表大小建立归档策略定期清理过期数据这里面最常见的坑有两个。一个是用户图省事把 AI 教练当成实时行情预测器来用问“明天 BTC 是涨还是跌”这种问题应该被拒绝。另一个是在部署时没有配置好 LLM API导致 AI 功能不可用但行情和交易功能正常容易误判为平台整体故障。10. 最佳实践与使用建议10.1 个人学习场景如果你是新手建议给自己定一个训练目标比如“一个月内做到单笔亏损不超过总资金 2%”。每天收盘后用 AI 教练做一次复盘重点看它识别的风险点。坚持两周你会发现自己的交易习惯有明显变化。10.2 开发者场景如果你是开发者建议优先研究三件事。第一平台的订单状态机和账户模型是怎么设计的这直接决定了系统能否扩展成真实交易系统。第二AI 教练的上下文构建方式这是 LLM 应用落地的通用难题。第三数据层如何统一处理多市场行情这是金融应用的通用基础设施问题。10.3 二次开发建议如果项目开源可以考虑下面几个扩展方向增加策略回测引擎把模拟盘和回测结合。增加自定义指标监控例如当账户回撤超过阈值时自动通知。增加 AI 教练的知识库让它可以回答更多市场基础知识。增加多账户支持方便团队共用一套模拟盘。接入更多数据源解决单一数据源覆盖不全的问题。10.4 合规提醒所有使用这个平台的用户都需要注意模拟交易和真实交易的差异。模拟盘中的盈利不代表真实交易能盈利。平台和 AI 教练提供的信息都不构成投资建议任何投资决策都需要自己负责。如果要把项目用于商业目的需要确认平台的开源协议、数据源授权范围、以及目标市场的金融监管要求。11. 总结与下一步这个项目的核心价值不在于模拟交易本身——这类平台已经有很多而在于它把 AI 教练和模拟交易结合在了一起。从技术角度看它是一个典型的 LLM 垂直应用有实时数据输入、有状态管理、有约束输出、有用户交互。这类架构放在金融交易之外的其他领域比如模拟面试、健身教练、投资辅助思路也是完全通用的。最值得先验证的功能是 AI 教练能否准确读取并分析你的持仓数据。如果这个链路是通的说明平台的数据层和 AI 层已经打通后续做自动化复盘、批量策略模拟就都有了基础。最容易踩的坑在数据源限制和 AI 接口成本上。免费数据源通常不稳定LLM API 调用也不是无限制的长时间高频使用需要关注成本。建议第一次使用时先跑通最小链路注册账户、下一笔模拟单、让 AI 教练做一次复盘确认三个环节都没问题再决定要不要深入使用。下一步可以考虑的是把模拟盘的数据导出结合 Python 做策略分析或者用 Webhook 把 AI 教练的每日复盘推送到自己的聊天工具里。这个项目作为学习和二次开发的起点是值得收藏的。