一、这类文章为什么容易“像营销稿”：因为缺了验收标准
把 AI 和量化放在一起，很容易出现一种写法：用一堆概念词讲“效率革命”，但读者回去依然写不出能运行、能回测、能上线的策略。根因不是 AI 不够强，而是你没有把策略写成可验收的规格。只要规格不清晰，DeepSeek 生成的代码就会变成“看起来像策略，实则不可复盘的脚本”。
这篇文章给一个能长期复用的工作流：先把自然语言拆成“输入/输出/约束/验收”，再让 DeepSeek 生成代码骨架，最后用 iTick 的历史与实时数据做闭环，并把实盘风险写进护栏。你最终得到的不是一段代码，而是一套可以反复迭代的工程化流程。
二、先写策略规格（Strategy Spec），再写 Prompt
建议你把每个策略想法写成一页纸的规格，格式尽量固定：
- 目标：策略要捕捉什么现象？趋势、均值回归、事件冲击、还是波动变化？
- 输入数据：需要的品种、频率、价格口径（last/mid/bid/ask）、是否需要复权。
- 信号规则：用条件表达式写触发与退出，避免“强势”“企稳”这类形容词。
- 交易约束：最大持仓、最小成交量、最大点差、交易时段、冷却时间。
- 风控规则：单笔风险、最大回撤、熔断条件、日内最大交易次数。
- 验收用例：给出 3~5 条可自动化的测试（例如“当输入缺失时必须拒绝下单”）。
这一步的价值是：你把“判断标准”从脑子里落到了文本里，DeepSeek 生成的代码才有明确目标可对齐。
三、把 Prompt 设计成“约束驱动”，别让模型自由发挥
很多人写 Prompt 只写“帮我写一个策略”，结果模型会把注意力放在“看起来完整”，而不是“可运行可验证”。更有效的 Prompt 是：先列出不可违反的约束，再列出需要生成的模块边界。
你可以用这样的结构（不需要很长，但要具体）：
- 你必须输出：数据接入层、指标层、信号层、执行层、风控层、日志与回放层。
- 你必须显式处理：UTC 时间戳、去重、乱序、断线重连、缺口补洞、参数快照。
- 你必须提供：最小可运行 demo + 单元测试样例（至少覆盖空数据/异常值/边界条件）。
当 Prompt 把边界画清楚，模型生成的东西会更像工程，而不是像“文章配套代码”。
四、iTick 数据接入要先标准化，否则回测/实盘永远对不上
无论策略多复杂，数据口径错了就会全盘崩溃。建议你先定义内部行情模型（哪怕只用 5 个字段），并在接入层完成转换：
- symbol：统一命名（例如
US:AAPL） - ts：UTC 毫秒
- price：明确用 last/mid
- bid/ask：如果可用，保留用于点差与滑点过滤
- source：
itick
示例（Python 拉快照，只用于演示接入形态）：
import requests
BASE = "https://api.itick.org"
TOKEN = "your_api_token"
headers = {"accept": "application/json", "token": TOKEN}
params = {"region": "US", "code": "AAPL"}
r = requests.get(f"{BASE}/stock/quote", params=params, headers=headers, timeout=15)
r.raise_for_status()
print(r.json())
工程上最关键的不是这段请求，而是围绕它的“稳定性层”：超时、重试、限流退避、字段校验、以及数据落库的幂等写入。你越早把这些写进去，后面策略迭代越快。
五、把“回测”变成验收，不要把回测当展示
AI 生成策略后，最常见的失败模式是：回测看起来不错，但一上线就不工作，或者收益完全变形。为了避免这个问题，你需要把回测设计成“验收流程”，至少包含三类检查：
- 口径一致性：同一段历史数据，用同一份数据模型，回放时信号必须一致。
- 鲁棒性：对缺失值、异常点、停牌/极端波动要有明确处理（跳过、填充、停机）。
- 交易可行性：加入点差/滑点/手续费/成交限制后，策略是否仍然成立。
如果策略的优势来自“极端精确的入场点”，那往往意味着它依赖不现实的成交假设，需要在执行层重写，而不是在指标层继续堆复杂度。
六、实盘护栏（Guardrails）要写在代码里，不要写在结尾一行“风险提示”
很多文章会在最后一句说“注意风险”，但实盘风险从来不会因为你写了提示就变小。更有效的做法是把护栏写成不可绕过的规则：
- 风险预算：仓位大小与波动绑定，波动上升自动降风险。
- 频率限制：冷却时间 + 最大日内交易次数，防止噪声反复触发。
- 数据健康：延迟过大、连续缺口、点差异常时，直接停机或降级，不输出交易信号。
- 版本与参数快照：每次运行记录策略版本、参数、数据源口径，保证可复现。
当护栏存在，AI 生成的策略才有机会从“能跑”变成“能长期跑”。
七、一套可复用的“人机协作”检查清单
你可以把下面这份清单当成每次让 DeepSeek 写策略后的固定流程：
- 规格是否完整：输入/输出/约束/验收是否明确？
- 代码是否分层：接入/指标/信号/执行/风控/日志是否拆开？
- 时间戳是否统一：是否显式使用 UTC？是否有乱序与去重？
- 数据是否可回放：能否用同一份数据重放并得到同一信号？
- 假设是否现实：成交、滑点、手续费、交易时段是否被计入？
当你把流程固定下来，DeepSeek 的价值会非常稳定：它负责把你写好的规格快速翻译成代码骨架，而你负责把“正确性与风险”写进验收与护栏。长期看，你沉淀的是可复用的规格与测试资产，而不是一次性的代码片段。
八、示例：把一句自然语言想法拆成可验收的规格
假设你的想法只有一句话：“想做一个 AAPL 的日内均线策略，趋势向上就做多，跌破就出场。”这句话对人类直觉够用，但对工程与验收完全不够。你可以按下面的方式把它拆开（不追求漂亮，追求可执行）：
- 输入：1 分钟 bar（OHLCV），价格口径为复权还是不复权；时间戳统一 UTC；交易时段限定美股常规交易时段。
- 指标：EMA(20) 与 EMA(60)，计算基于 close；首次启动需要至少 60 根 bar 才允许产出信号。
- 信号：EMA20 上穿 EMA60 且最近 30 分钟波动低于阈值时允许开仓；EMA20 下穿 EMA60 或达到止损/止盈条件时平仓。
- 交易约束：同一时间只允许 1 个方向持仓；平仓后冷却 10 分钟；点差/滑点超过阈值时只记录信号不下单。
- 风险：单笔风险 r%，止损距离用 ATR(14) 的倍数定义；当日回撤超过上限停止交易并记录原因。
- 验收：给出至少 5 条可验证用例，例如“缺失数据时不得发出交易指令”“乱序输入时信号序列不应回退”“回放同一段数据，信号必须一致”。
当这份规格写出来，你会发现很多“策略想法”其实是在逃避细节：一旦细节落地，就会暴露出数据需求、执行假设与风控边界。越早暴露，越省钱。
九、把模型输出变成可维护代码：三个小技巧
- 先让模型写接口，再写实现：你要求它先输出 TypeScript 的类型定义与模块边界（数据接入/指标/信号/执行/风控/日志），第二轮再填实现，这比一次性生成完整项目更稳定。
- 让模型输出“失败路径”：同一份 Prompt 里要求它列出 10 个可能失败的边界（断线、重复 tick、异常价格、时区错位、限流、停牌、极端波动），并对每个边界给出处理策略。你会得到更像生产代码的结构。
- 用“对账点”锁住一致性：要求每个阶段输出可对账的中间结果（例如标准化后的 tick、聚合后的 bar、指标值、信号值、仓位状态），这样你可以在回放时定位差异，而不是在最终收益上猜原因。
十、结语：你真正沉淀的资产不是代码，而是规格与验收
如果你把 AI 当作“写代码的捷径”，那它确实会让你更快地写出更多代码，但也会更快地产生更多不可维护的分叉版本。反过来，如果你把 AI 当作“把规格翻译成代码的编译器”，你的核心资产就会变成两件事：稳定的数据口径与可复用的验收用例。代码会迭代、模型会变化，但规格与验收会让你的系统长期可控。
