先分清工具只做提醒、回测，还是会触达下单
需求文档里最先要写死的是工具边界。只做行情提醒，数据流向是单向的：数据源进来，规则判断，通知出去。做回测，还要有历史数据、成交假设和结果统计。一旦接入券商或交易所的下单接口，就多了密钥保管、权限范围、风控和责任归属的问题，报价与工期都会明显不同。建议第一期只做提醒加回测，不碰资金和下单权限。判断标准很简单：如果工具能让用户的资金发生变动，就不要和提醒工具混在同一个需求里评估。
数据源要确认授权、口径和延迟，而不是只看能不能拉到数据
下单前至少要核对六项：来源是交易所、聚合商还是爬取；许可条款是否允许在你的产品里展示和再分发；行情是实时、延迟还是仅日线；复权方式是前复权、后复权还是不复权；时间戳的时区和精度；缺失值与事后修正的处理。免费接口常见的问题是限频、字段随版本变化和商用条款模糊。回测与实时提醒必须使用同一口径，否则回测里成立的信号，实时环境里会因为复权或延迟不同而对不上。如果无法拿到明确的商用授权，应在报价阶段就换数据源，而不是上线后再补。
触发规则要写成能被重复验证的条件
「突破压力位提醒我」不是规则，下面这些才是：使用哪个周期的 K 线，以收盘价还是盘中价判断，突破幅度的阈值，是否要求连续 N 根确认，同一标的触发后的冷却时间，多条规则同时命中时的优先级与去重方式，以及数据中断后恢复时是否补发。盘中价判断会让信号在 K 线收盘前出现又消失，用户会看到提醒却在图上找不到信号。一个实用的验收标准：同一条规则在同一段历史数据上重跑两次，结果必须完全一致；实时运行的提醒记录，也应能用回测引擎复现。做不到，说明规则里有隐含状态没写出来。
回测结果可信与否，取决于几个常被省略的假设
回测最常见的失真来自四处：使用了当时还不可得的数据（未来函数）、只保留现存标的（幸存者偏差）、忽略手续费与滑点、复权处理不一致。验收时应要求工具输出成交假设：以信号下一根开盘价还是当根收盘价成交，费率如何设置，是否考虑停牌和涨跌停无法成交。还应保留样本内外的划分。如果去掉手续费假设后收益明显改善、加上后接近零，这个策略对成本过于敏感，应停下来复核，而不是继续优化参数。回测结果只描述历史，不应在产品页面里表述为收益预期。
若要做成安卓应用上架，账号类型要在开发前定下来
提醒和回测工具常以 App 形式交付，安卓端需要谷歌开发者账号。这里要提前核对的不是技术，而是主体：应用属于个人还是公司，账号是个人号还是组织号，收款和税务信息归谁，后续换主体是否会影响已发布应用。涉及行情、投资类内容的应用，通常还要面对商店对金融类功能的声明和说明要求，具体条目与审核口径以平台当时的页面为准，不应凭记忆判断。如果通过发芽购买现号或带 App 的老号，应在下单前把应用类型、数据源授权主体和账号持有人是否一致，一并写进核对清单。账号只是发布载体，不能替代数据授权和合规说明。