先分清四类交付物，验收标准各不相同
量化工具定制常见的四块是提醒、回测、看板和密钥。它们的失败方式不同：提醒的风险是漏发或重复发，回测的风险是结果不可信，看板的风险是口径不一致，密钥的风险是权限和归属不清。合同里如果只写「实现量化工具」，验收时就没有可对照的东西。建议按四块分别写出输入、输出和失败时的表现，再谈报价和工期。本文只讨论软件交付，不涉及收益预期，也不构成投资建议。
提醒：触发条件、去重和「提醒本身挂了」的告警
提醒的需求文档至少要写清触发条件的数据源、判断周期、冷却时间和去重规则。同一信号在一分钟内连发十条，和该发时没发，都算缺陷。渠道常见的是 Telegram Bot、邮件或企业 IM，要确认限流后如何排队，而不是直接丢弃。还有一项常被漏掉：心跳。数据源断连、进程崩溃时，提醒系统自己应当发出异常通知，否则「没有提醒」会被误读成「没有信号」。验收时可以用历史行情回放一遍，核对触发次数与预期是否一致。
回测：能复现，才谈得上可信
回测交付物不该只是一条收益曲线。要求对方说明数据来源和复权口径、手续费与滑点假设、成交价取法，以及是否排除了未来函数。同一份代码、同一份数据、同一组参数，应当跑出完全一致的结果，参数和数据版本要随报告一起保存。样本内外要分段，避免只展示拟合最好的区间。回测与实盘的差异来自延迟、流动性和费用，所以报告里应写明哪些因素被简化了。对方如果只给截图不给可运行的代码和配置，就无法复核。
看板：先统一指标口径，再谈界面
看板的难点在口径。收益率按成本还是按净值算，回撤取日内还是收盘，持仓是否含未成交委托，这些要在交付文档里逐项定义。需要标明每个数据块的刷新时间，过期数据应当有明显标识。还要确定看板是只读还是带操作能力。只读看板风险低；一旦能下单或撤单，就要有登录鉴权、操作日志和二次确认。数据库或表格的读写权限也应归使用方，开发者交付后不应保留长期后门入口。
密钥归属：谁创建、谁持有、谁能撤销
原则是密钥由使用方在自己的交易所账户里创建，开发者不接触主账户。权限按最小范围给：回测与看板用只读，需要自动下单时才开交易权限，提现权限不应开启。能绑定 IP 白名单的就绑定服务器出口地址。Telegram Bot 的令牌应由使用方通过 BotFather 自己创建；云服务器、域名和代码仓库也应在使用方名下。如果交付形态包含 Android 应用，应用上架所用的开发者账号归属同样要在合同里写明。密钥通过环境变量或密钥管理服务注入，不得写进代码仓库，并留有轮换方案。
交付与验收：哪些情况应当停下来
一份完整交付通常包含可运行的源码或部署包、配置说明、部署与回滚步骤、测试记录和密钥清单。源码是否交付、是否有授权限制，要在合同中明确，而不是事后协商。验收可以分两步：先用只读密钥和模拟数据跑通，再小范围启用。出现以下情况建议暂停或换方案：对方索要提现权限或主账户登录信息；拒绝提供回测的数据与参数；承诺固定收益；服务器和账号全部放在对方名下且不愿迁移。这些都属于控制权问题，而不是技术细节。