1. 别急着问“能不能告”先还原“机器人输钱”的四种剧本先说一个我自己的例子。前两年我给一个业余量化项目写过一个自动交易程序上线第三天它就做了一件让我血压拉满的事本应只买入1手的信号因为仓位计算函数里一个单位换算错误直接买入了10手导致账户单日回撤超过15%。当时我的第一反应和很多朋友一样特别想找人负责任——但冷静下来之后才发现那个“责任人”是我自己。你可能会觉得这只是一个程序员的倒霉故事。但如果把问题换成“我的机器人害我输了钱我能告他吗”你会发现这不是一句玩笑话而是一个非常现实的困境。这里的“机器人”可以很多种一个自动下单的量化交易脚本、一个每天往工作群推行情信号的钉钉机器人、一个由飞书机器人定时发送的Excel报表筛选程序甚至是一个帮你管理库存、自动补货的自动化流程。只要它参与了决策、操作了资金或者影响了你的判断一旦亏钱你第一个想找的就是它。但在动手“告”之前我更建议你先做一件事把“机器人害我输钱”这句话拆开还原成具体的场景。为什么呢因为“输钱”只是结果而结果是哪种原因造成的决定了这件事到底能不能追责、该找谁追责。同一个机器人可能是程序代码写错了可能是策略本身有漏洞可能只是市场波动还可能是行情源或者网络接口出了故障。这四种原因背后的责任归属完全不一样如果不先分清楚你连“告谁”都搞不明白。1.1 被机器人“坑”的场景比你想象的多我接触过的自动化机器人大致可以分成三类。第一类是信息型机器人比如用Python读取Excel后通过钉钉机器人推送到群消息或者用飞书机器人发送格式化表格。它们的工作是提醒你、帮你整理信息但不直接产生交易。第二类是决策型机器人它接收行情和指标然后给你下单建议有些还会自动挂单。第三类是执行型机器人比如工业机器人、AGV导航小车、库卡机械臂它们不碰钱但如果程序轨迹写错撞坏了设备或者让产线停工照样会造成经济损失。说实话我在一些技术社区里看到过不少类似帖子有人问“我的自动交易机器人连续亏损能找开发它的程序员赔偿吗”也有人问“用开源机器人操盘亏了钱项目作者该不该负责”。这些问题在逻辑上都有一个共同的难点机器人的行为和人的行为混在一起很难切断。当你按下“启动”按钮的那一刻你就已经是整个系统的一部分了。所以在分清场景之前任何结论都是草率的。1.2 一个反直觉的结论大多数“机器人坑人”其实是人在坑自己这个结论可能会让不少人难受但它确实是我这些年复盘下来的真实感受在多数亏钱案例里机器人只是把人的错误决定放大了。它可能会把错误执行得更快、更彻底、更不犹豫但源头往往是人——人写的策略人调的参数人关掉的风控开关人没处理的日志异常。当然我并不是说机器人永远没有“过错”。如果某家公司把一个商业化交易的机器人卖给你宣传说它经过了充分回测、有严格风控结果程序里一个for循环边界写错导致连续重复下单那这确实是产品问题追责逻辑完全不同。但在这之前你得先准确回答我的情况到底是哪一种2. 机器人“犯错”的四种模式责任归属完全不同这一章是全文的核心请耐心看。我根据自己写代码和踩坑的经验把“机器人害我输钱”归纳成了四种模式。你拿任何一个案例往里套基本都能找到对应位置。2.1 程序Bug这是“机器人有罪”最接近的场景如果要找一个“机器人真的坏了”的情况那就是程序代码写错了。这不是策略的问题也不是市场的问题而是代码逻辑本身不符合预期。举个典型的例子。我给自己的机器人写过一个止损模块条件是“当价格低于持仓成本2%时触发市价卖出止损”。结果因为把浮点比较的精度判断写反了导致价格回调时止损单没有触发等价格跌到5%的时候才猝不及防地成交。还有一次因为API接口的参数单位是“手”而代码里传的是“股”导致下单数量变成预期的10倍一秒钟之内就把账户仓位拉满了。程序Bug的责任怎么划要看代码的来历。如果你自己写的那只能自己认没有任何“告”的对象。如果你是从开源社区拿到的项目开发者通常会在LICENSE里写明“按现状提供不承担任何损失”——这不是不近人情而是开源生态的通用规则。如果你是购买商业软件那就得看产品合同里有没有承诺“程序无缺陷”以及缺陷造成损失的赔偿条款。老实说这类赔偿条款在金融软件领域非常苛刻很多合同直接标明“软件仅用于辅助参考不构成投资建议”把决策责任全部留给你。2.2 策略缺陷机器人没写错但策略本身不成立这一种最容易让人误判。程序完全按设计运行日志漂亮得无可挑剔但它依然在亏钱。问题出在哪里出在策略本身。举个例子有人写了一个“突破策略”当价格突破20日最高点时买入跌破10日最低点时卖出。用编程语言实现这个逻辑很简单程序也完全按照这个逻辑运行。但如果当时市场正处于震荡行情价格会在区间里反复“假突破”策略就会不断地买在高点、卖在低点连续亏损是非常正常的。这能怪机器人吗不能。机器人只是一个忠实的执行者它把规则100%执行了但规则本身没有考虑市场环境。还有一个更常见的策略缺陷是资金管理缺失。有些策略单笔胜率很高但一旦亏损就会把前面的利润全部吐回去。比如马丁格尔策略它通过亏损后加倍本金来摊平成本在单边下跌行情里会迅速消耗全部资金。这类策略如果是机器人自动执行亏损速度会非常快。我从一开始就提醒过自己机器人可以帮我把策略跑得更“坚定”但它不会帮我思考策略是否已经失效。策略失效的责任永远在策略设计者身上也就是你自己。2.3 市场风险机器人完美执行依然亏钱还有一种情况你可能找不到任何“错”。机器人按计划买入按计划止损每一笔记录都清清楚楚回测数据也支持这套逻辑但市场就是不给你面子。比如你买入了某只股票结果第二天突发利空消息价格跳空低开止损单根本来不及成交又比如市场整体下跌你的策略做多自然跟着跌。这种情况下机器人没有做错任何事它就是亏了。这种场景在法律上反而是最清晰的这就是投资风险。哪怕你把机器人设计得再精密它也不可能预测市场。市场波动、系统性风险、黑天鹅事件这些都属于投资人必须承担的固有风险。不要因为操作者是机器人就认为风险转移给了机器人。机器人只是工具市场不会因为工具精妙而对你手下留情。2.4 外部依赖故障行情源、API、服务器都不归你控制最后一种是我的重点提醒对象因为它最容易被人忽略。机器人的决策依赖外部数据比如行情源、交易所接口、云服务器。如果这些外部依赖出了故障机器人会表现得非常“蠢”。我就遇到过行情源断流的情况。某个下午行情数据突然停止更新机器人在完全没有最新价格的情况下给早期行情算出的“止盈点”挂了一个卖出单结果成交价格比实际市场价低了将近1%。很多人认为这属于“机器人害我亏钱”但从逻辑上讲这是第三方服务商的数据延迟问题。同样的情况还包括云服务器宕机导致止损程序没有运行、API拒绝连接导致无法撤单、网络延迟导致下单价格严重偏差。这类责任通常由你和服务商之间的服务协议来决定。大多数API服务商都会在条款里写清楚“不保证服务不中断”“不对因服务中断导致的损失承担责任”有的服务商干脆只承诺“月度可用性99.9%”如果没达到最多赔偿你当月的服务费——而不是你损失的本金。想告外部服务商你得先翻出当初勾选“同意”的那份协议看看白纸黑字是怎么写的。3. 责任链条怎么断开发者、平台、使用者的三方视角分清了四种场景后就可以认真聊聊“能不能告”这个问题了。要回答它你需要把责任链条拆成三个环节开发这个机器人的人、提供机器人运行平台或依赖服务的人、以及最终按下启动键的人。这三者的权限和责任完全不同。3.1 开发者的责任边界商品、开源、定制、自用四类完全不同先说结论开发者是否有责任取决于你是以什么身份拿到这个机器人的。咱们用一张表把常见情况梳理一下交付形态常见例子开发者的责任边界商业化产品购买的自动交易软件、量化终端通常只承担“产品不符合合同约定”的责任很难覆盖投资亏损开源项目GitHub上的免费交易机器人基本无责LICENSE里都会声明“按现状提供”委托定制开发专门找人写的交易策略程序看合同约定若合同没有明示“保证盈利”开发者一般不承担亏损自用脚本自己写的Python自动交易程序没有责任方责任就是你自己这里面最容易扯皮的是“委托定制开发”。很多朋友以为我花钱请人写一个机器人他写的东西让我亏钱了他就该赔。但实际情况是除非合同里写明“策略保证盈利”或者“程序不得存在任何Bug导致的亏损”否则开发者的义务是“按需求交付代码”而不是“替你赚钱”。金融市场里没有任何程序能保证盈利写着“包赚”的大概率是骗子。所以开发定制机器人之前一定要把验收标准写清楚什么算交付完成如何验证程序没有重大缺陷对策略收益是否做任何承诺哪怕只做一份简单的“需求确认单”以后有争议时也能少很多麻烦。3.2 平台和服务的责任边界合同怎么写责任就怎么定机器人不是凭空运行的它需要依赖各种平台和服务。对交易机器人来说可能是交易所的API、券商接口、行情数据源对一个工厂里的工业机器人来说可能是运动控制卡、通信协议、供电系统对一些娱乐型机器人来说可能是语音识别API、消息推送通道。这类责任链条比较简单谁提供平台看谁的服务协议。平台方的义务是保证服务达到约定的可用性标准比如API月度可用性、数据延迟上限、故障响应时间。一旦平台没有达到这些标准且直接导致了你的损失理论上可以索赔。但他们通常会设置一个“赔偿上限”一般是“你过去一个月或一年支付的费用”。也就是说哪怕你因为行情断流亏了五万块平台方最多赔给你当时支付的几十块钱API服务费。这种条款在法律上叫“责任限制条款”在商业服务中非常普遍你很难告赢它。所以我的建议是不要把关键资金、关键决策完全托付给单一平台。对交易机器人来说一定要有备用行情源和备用网络对工业机器人来说关键控制系统一定要有断电保护和急停回路。平台只能作为“大概率稳定”的依赖不能当作“绝对可靠”的保险。3.3 使用者的责任按下了启动键的人是最难“告”倒自己的说句不太中听的话在绝大多数“机器人害我输钱”的案例里最终责任都会落在使用者自己身上。原因有三点。第一使用者有最基本的注意义务。你运行一个自动交易程序之前有没有做过足够多的回测和模拟盘验证有没有在小资金账户上测试过有没有设置最大回撤阈值和单笔止损如果你什么都没做直接上来就满仓运行那机器人无论怎么亏钱都很难把责任推给别人。第二使用者需要对运行环境负责。你有没有检查过行情源的稳定性有没有给服务器配置自动重启有没有保证机器人24小时在线如果机器人半夜断线导致亏损这属于运行环境维护不到位。第三使用者需要对“是否授权”负责。很多人设置了“全自动交易”之后就不管了不盯盘、不看日志、不更新策略直到出现大亏才想起来检查。这种情况下你相当于把决策权完全交给了机器那就要做好承担后果的准备。4. 想追责先备好这三样“技术证据”如果你看完前三章仍然觉得自己确实有权追责那么你必须准备好一样东西——证据。法律讲究证据而机器人领域的技术证据比很多人想象中复杂得多。没有这些证据你连“告”的门都摸不到。4.1 日志机器人的“黑匣子”飞机上有一个黑匣子机器人也一样。日志就是机器人的黑匣子它记录了程序运行过程中的所有关键信息。没有日志你无法证明“机器人当时做了什么”也无法判断亏损到底是程序错误还是市场波动。一个合格的交易机器人日志至少要包含以下几类信息时间戳每条操作记录的具体时间精确到毫秒参数快照下单时的价格、数量、方向、滑点、手续费信号来源触发这次操作的指标值和条件判断结果异常记录程序报错、接口超时、数据断流等异常信息系统状态CPU占用、内存占用、网络延迟等运行状态我自己的习惯是给日志加上“可回放”能力。也就是说事后我可以根据日志完整重建当天机器人的运行过程包括它看到了什么行情、做了哪些判断、为什么执行这笔交易。就算不是用来打官司这个习惯对排查问题、复盘策略也极其有帮助。4.2 风控记录证明你尽了“理性人”义务光有机器人的执行日志还不够你还需要证明自己作为使用者尽到了合理的注意义务。什么叫“合理”在交易机器人场景里至少要能看到以下记录策略回测报告、模拟盘运行记录、最大回撤设定、单笔止损设置、单日亏损熔断阈值、小资金试运行结果。这些记录的意义在于如果出了事你能够证明自己不是毫无准备地“乱上车”而是通过一套相对严谨的流程后才让机器人接管资金。反过来说如果你什么都拿不出来说明你根本没有为可能的亏损做好基本准备那追责的说服力就会大打折扣。我自己会用一个简单的表格做“机器人运行审批单”每次上线或者调整参数都要更新一次记录清楚策略名称和版本号回测区间、回测最大回撤模拟盘运行时长、收益率、最大回撤上线资金量、仓位限制、止损阈值本次运行的策略评分和不同意见备注这套流程听着麻烦但在关键时候能救命。它既是技术证据也是自我约束。4.3 合同与服务协议别等出事了才翻最后一项证据最容易被忽视合同、服务协议和购买记录。很多人在注册API、购买软件、使用云服务时都是直接点“同意”从来不看条款。等到出了问题才发现条款里写着“本服务不保证不中断”“本公司不对任何间接损失承担责任”。所以我的建议是在开始运行机器人之前就把这几份东西读一遍、存好商业机器人软件的销售合同或订单页、API提供商的使用条款、云服务器服务协议、行情数据源的授权协议。重点看三个地方有没有“可用性承诺”比如SLA有没有“免责条款”比如“不承担因数据错误导致的损失”有没有“赔偿上限”比如“累计赔偿不超过12个月服务费”。这些细节直接决定了你能追责到什么程度。5. 与其纠结“告不告”不如让机器人先学会“不犯错”说实话写到这里我想把重心从“追责”转回“防范”。因为我见过太多人把大量时间花在“找谁负责”上却忽略了最本质的问题机器人是自己部署的风险和收益本来就是一个完整的系统。如果有人靠一个机器人就能躺赚那金融市场早就被机器人掌握了。所以我更愿意分享一套让机器人“少闯祸”的方法从源头上把“输钱”的概率压下来。5.1 回测所有自信和推责的前提回测是运行自动化主题之前最重要的一道关卡。所谓回测就是用历史数据模拟运行你的策略看看它在过去几年中会赚多少钱、亏多少钱、最大回撤有多大。很多策略在回测里就原形毕露了根本不需要等到实盘亏钱。做回测时要注意三个坑。第一别用未来函数。如果你的策略在今天使用了明天的数据那回测结果会非常漂亮但实盘完全无效。第二别只回测一段暴涨行情。要覆盖震荡、单边上涨、单边下跌不同市况才看得出策略的稳定性。第三回测要包含交易成本和滑点。如果忽略手续费和滑点回测利润会被严重高估。一套“能打”的策略至少应该在3到5年的历史数据上跑通并且最大回撤在你可承受范围内。5.2 仓位管理让任何一次错误都“输得起”机器人一定会出错这不是概率问题而是时间问题。既然它会出错你的仓位管理就必须保证即使出现最极端的情况你也不会亏掉全部资金。我常用的一个原则是“单笔风险不超过总资金的1%”。举个例子如果你有10万元资金单笔交易最大亏损控制在1000元以内。根据止损距离来反推仓位如果止损距离是5%那么这一笔最多只能买入2万元的仓位1000除以5%等于20000。这个计算方式简单但很有效。它保证了即使机器人连续亏损20次账户资金也还能保住八成不至于一次“事故”就崩盘。5.3 熔断机制给机器人装一个物理刹车机器人的最大问题是它不会累也不会慌更不会在连续亏损时主动停下来想一想。所以你必须替它装一个刹车也就是“熔断机制”。一个实用的熔断设计可以包含三层单笔止损每一笔交易都设定固定止损价格触发就无条件离场单日熔断当日累计亏损达到总资金的2%到3%当天不再开新仓连续亏损熔断连续亏损超过N笔比如5笔自动暂停策略这三层熔断的目的是隔离“坏运气”和“坏策略”。如果市场正常波动导致个别亏损单笔止损能挡住大部分伤害如果策略本身失效单日熔断和连续亏损熔断会强制让机器人停下来给你留出重新评估的时间。我见过太多人把机器人设置成全自动之后就不管了结果策略失效后连续几天亏损直到账户大幅缩水才反应过来。熔断机制就是弥补“人工盯盘不及时”这个问题的最直接手段。5.4 人在回路把关键决策留在自己手里最后一个建议听起来有点“反机器人”但它很重要不要做“全自动独立思考”的机器人最好做成“人在回路”的半自动模式。所谓人在回路就是让机器人完成分析、计算、预警、生成建议这些事但关键决策和最终执行必须经过你确认或者至少在你设定的严格风控框架内执行。比如机器人可以负责实时盯盘、计算信号、推送预警到钉钉群或飞书群由你决定是否下单或者机器人可以自动下单但仅限于在你预先设定的交易计划范围内运行超出计划就必须暂停人工介入。这样做的最大好处是你保留了“刹车权”。机器人再聪明它也只是你决策的辅助而不是你决策的替代品。出了问题你能更快地介入处理而不是眼睁睁看着它一路错到底。6. 我的真实体会机器人是工具责任是系统的一部分最后说一点我自己的真实体会吧。我开始认真思考“机器人害我输钱我能告他吗”这个问题是在一次连续亏损之后。那个机器人是我自己写的当时我很生气气得想把电脑砸了但冷静下来看日志才发现它从头到尾都在严格执行我写的策略是我根本没有设置熔断和止损。我生气的对象其实是我自己。从那以后我给自己立了一个规矩每一次运行机器人都要写一份“机器人运行说明书”里面包含策略逻辑、参数、风控设置、止损规则、回测结果和批准人。上线之后每天固定时间看一次日志每周做一次复盘每月做一次策略健康度检查。这些动作看起来很笨但坚持下来以后机器人的“事故率”确实降低了非常多。更重要的是即使出了事我也能非常清楚地判断出问题出在哪个环节不会陷入“不知道该怪谁”的窘境。所以回到最初的问题你能告它吗从法律角度讲你得看合同、看证据、看责任归属但从一个老开发者的角度看我更希望你永远不需要走到那一步。机器人是你的工具你可以信任它但也要监督它、约束它、给它装好刹车。把责任意识写进你的系统设计里比追责谁更有价值。