策略条件由需求方来写，开发方只负责把它变成规则
量化软件定制里最常见的分歧，是「条件到底谁来定」。合理的分工是：入场、出场、过滤的逻辑由需求方给出，开发方负责实现、测试，并指出其中无法执行或自相矛盾的地方。原因很直接：一旦开发方替你补全模糊条件，补出来的那部分就成了策略的一部分，而它并不是你的判断。后续结果不如预期时，你无法区分是想法有问题，还是实现时的默认选择有问题。所以下单前要先确认，这份条件文档的作者是你，而不是在沟通中逐步由开发方「补齐」。
信号要写到两个人用同一份数据能算出同一个结果
「放量突破」不是条件，只是一个标签。可执行的写法要包含：用哪个周期的 K 线，成交量与过去多少根的均值比较、倍数是多少，价格突破的是过去多少根的最高价，用收盘价还是盘中价，比较是大于还是大于等于。自检方法是拿一张真实的行情表，让两个人各自按你的描述手工判断，结果不一致就说明条件还没写完。常见的遗漏有三类：参数没有数值，时间窗口没有起止，多个条件之间的关系（同时满足还是满足其一）没有说明。指标本身如均线、RSI，要写明计算口径和参数，不要只写名称。
触发频率决定数据获取方式，也决定能不能稳定运行
频率不是一个可以事后调整的小参数。按 K 线收盘触发，只需要在周期结束后拉取一次数据，实现简单，信号也不会反复。按盘中实时条件触发，通常要订阅推送或高频轮询，要面对交易所的请求限频、断线重连和数据延迟，服务器和维护成本都更高。还有一个常被忽略的点：在未收盘的 K 线上判断信号，条件可能在收盘前消失，提醒发出后又不成立。所以要写清楚：信号以收盘为准还是盘中为准，同一信号在多长时间内不重复提醒，监控的标的数量大约多少。具体限频规则以交易所当时的接口文档为准，这些数字会变，不应写死在需求里。
输出格式要按下游怎么使用来定，而不是按开发方习惯
同样是一个信号，输出给人看和输出给程序读，格式完全不同。给人看的提醒，通常需要标的、方向、触发时间、触发价格、命中的条件摘要，以及使用的语言和时区。给程序读的接口或文件，则需要固定的字段名、数据类型、时间戳格式，比如 CSV 的列顺序或 JSON 的结构。建议在需求里直接贴一条你期望看到的样例输出。同时约定：重复信号是否去重、失败时是否重试、日志记录哪些字段、策略参数有版本号时是否随信号一起输出。格式在开发后期才改，往往会连带改动数据结构和测试，成本远高于一开始写清。
自己还没有成形的条件时，先别下单
有些需求方带来的只是一个方向，比如「想做一个趋势类的提醒」。这种情况下，开发方可以提供常见指标的标准实现作为参考，但参数取值仍然需要你自己决定，这些参考值也不代表任何收益表现。如果你无法回答前面三部分里的任何一项，更稳妥的做法是先用手工方式对着历史行情把条件跑几遍，写成文字，再进入定制。另一个停止信号是：开发过程中条件被反复推翻。若同一份条件改动超过两三轮，说明需求还没有稳定，应当暂停开发，重新整理文档，并把后续改动按新需求评估，而不是在原范围内继续堆叠。
下单前的核对清单与暂缓标准
可以把核对内容压缩成一页纸：标的与周期范围；每条信号的完整判断规则和参数；收盘触发还是盘中触发，以及去重规则；输出渠道、字段、样例；数据来源和是否需要历史数据；条件变更如何计费和排期。判断标准很简单：这一页里任何一项需要开发方「帮你想」，就还没到下单时间。能全部由你自己填完，并且别人读完不会产生歧义，再进入报价和排期，后续的验收也才有明确依据。交付范围、费用与周期以双方书面确认为准。