边界划在工具层，是因为只有工具能被验收
软件定制的验收依据是需求说明：输入什么、输出什么、异常时怎么处理，都能逐条测试。策略收益取决于市场状态、成交环境和参数选择，开发方无法对其负责，也无法在交付日证明。把交付停在工具层不是能力上限，而是把「能被验证的部分」与「不能被承诺的部分」分开。合同里写收益目标，等于把一个不可验收的结果写进了验收条款。
工具层通常包含哪些模块
常见范围包括：行情与历史数据接入、回测引擎、信号到订单的执行模块、仓位与风控规则、订单与成交日志、监控告警、部署与配置管理。这些模块的共同点是行为可描述。例如「断线重连后不重复下单」「单品种持仓超过上限时拒绝新单」，都可以写成测试用例。需求阶段应逐模块确认由谁提供数据源和交易所账号，避免交付时才发现依赖项没人负责。
策略不在范围内，是因为判断与知识产权在委托方
策略包含入场逻辑、参数和风险偏好，本质是委托方的投资判断。如果开发方同时写策略和系统，会出现三个问题：策略归属不清，回测中的过拟合无人对结果负责，实盘亏损时也难以区分是代码缺陷还是策略失效。更清晰的做法是委托方提供策略规则或伪代码，开发方实现并证明实现与规则一致。规则本身的好坏，不属于软件交付的检查项。
资金权限决定责任边界，代运营是另一类业务
工具交付不需要接触资金。对接交易所时，API 密钥应只开通查询与交易权限，关闭提现，并尽量绑定固定 IP，密钥由委托方自己保管和轮换。一旦开发方持有可提现权限，或替多人集中下单、代管资金，性质就从软件开发变成资产管理或投资服务，不同法域对牌照和披露的要求不同，具体以当地监管规定为准。需要代运营的，应单独评估主体资质，不应夹在开发合同里。
验收标准写在行为上，而不是收益上
可操作的验收项包括：同一份数据与参数重复回测，结果逐笔一致；回测与实盘共用同一套信号与风控代码，或明确列出差异；订单状态机覆盖部分成交、拒单、超时、撤单失败；网络中断与重启后状态可恢复且不重复下单；风控阈值触发时有日志与告警；先在模拟盘或小额环境跑通。回测收益曲线好看不等于验收通过，它只能说明规则被正确执行了一次。
出现这些信号时应停止或换方案
以下情况建议暂停签约或重新评估：对方承诺收益、回撤或「保本」；要求开通提现权限或把资金转入其控制的账户；不愿书面确认需求与验收用例；不交付源码、部署文档或依赖清单，导致你无法独立运行；用一份回测报告替代测试记录。工具型合同的底线是：你能自己部署、自己停机、自己审计日志。做不到这三点，再低的开发费用也不值得。