AI 编程与量化开发环境

不要只说“帮我做一个量化策略”。你可以这样说：

我有一份历史日线 CSV。请计算 MA5 和 MA20，按前一个时点与当前时点的关系标记交叉，输出图表和信号表。暂不连接交易账户。缺少必要字段时直接报告，不要创建模拟行情。请说明假设，并用一个正常文件和一个缺少字段的文件验证。

这句话已经交代了六件事：范围、输入、处理方法、输出、限制、验收。AI 有了明确边界，你也有了检查答案的尺子。

举个反例。AI 生成一个网页小游戏，代码看起来完整，打开后棋盘却没有正确显示。问题不一定是 AI 不会写代码，而是“做完”没有被定义成用户真的能操作、结果真的能显示。写量化程序也是一样：运行成功只是第一关。

调试往往会占掉大量时间，有时比写代码本身还多。需求不清、上下文遗漏、环境冲突、逻辑错误，以及一次改动影响其他功能，都可能让调试变难。

你可以把规则分成两层。全局规则是每个项目都适用的偏好，比如用中文说明、先检查现有文件、不要暴露凭证、没有跑过的检查要如实说。项目规则是当前项目的约定，比如目录结构、字段名称、接口、运行环境和不能越过的边界。

一份量化学习项目的规则可以写成：

• 只做历史数据学习，不连接真实交易账户；
• 修改前先阅读现有实现，优先复用已经验证的函数；
• 只修改当前任务相关内容，保留已经完成的行为；
• 缺数据、权限失败或接口报错时明确报告，不拿模拟数据冒充真实数据；
• 输出保留证券代码、数据日期、来源和参数；
• 运行与安装依赖时，使用当前项目的解释器；
• 改动后检查相关计算和一个失败场景，没执行的检查要写明。

不同工具读取规则文件的方式不一样。不要因为文件名叫 rules，就假定它一定会自动生效。你还要注意上下文：AI 看到的是实际提供给它的文件，不是整个项目。检索可能漏掉依赖，聊天记录也不等于项目说明。不同模型能读的上下文长度不一样，代码行数也没法直接换算成固定的 token 数。

因此，让 AI 修改 B 前，先要求它定位已有的 A、B 和共用函数，列出准备改哪些文件。这样能减少两类问题：修改 B 时把 A 改坏，以及重新写已经调通的函数。保留短的项目说明，比期待 AI 永远记住聊天内容可靠。

开发时不要用大量 fallback 把错误藏起来。比如接口取不到价格，就悄悄用随机数；文件缺失，就塞入默认行情。曲线虽然能出来，结果却没有真实依据。合理降级可以存在：网络暂时失败时有限重试，缺少某个标的时跳过并记录原因，交易系统进入只读或暂停状态。关键是不能悄悄改变数据真实性、风险规则和结果含义。

同一个 AI 工具，通常可以用不同方式工作：

• Ask：解释代码、比较方案、理解报错。通常只给说明和建议，不改文件；
• Plan：面对多文件修改或重构，先列范围、步骤、验证方法和回退办法；
• Agent：目标明确，而且你已经授权执行时，才让它实际改文件和运行检查；
• Debug：错误可以复现时，提供最小复现步骤、预期结果、实际结果、报错和运行环境，让它找证据、判断原因、做最小修复，再复测。

复杂任务可以先让 AI 把方案写成 Markdown。你先检查依赖、范围和风险，再决定是否执行。方案不必很长，但必须能回答“改哪里、为什么、如何证明改对”。

不要把 AI 的自评分当成功概率。即使它说方案 90 分，也不表示经过校准，更不表示真实数据已经验证。更好的问法是：请列出假设、已有证据、未知条件、替代方案和失败情景。

调试时只发必要信息。日志里的密钥、账户号和个人信息要先删除或遮盖。让 AI 一次定位一个问题，不要遇到一个报错就要求它把整个项目重写。

简单任务可以先用响应较快的选择；如果任务复杂，或者同一个问题多次失败，再换推理能力更强的选择。这是工作方法，不是某个工具或模型永久有效的排名。

比较时，不要只看榜单分数或一次聊天的感觉。给不同选择同一个小任务，检查它们是否：读懂已有代码、保持交易规则、报告没有运行的测试、不编造接口，以及需要几次才能修好。更强的模型也可能把收益、索引或仓位逻辑写错。

自动选模型省操作，手动选模型便于比较和控制成本。编程工具只是界面和执行环境，不能因为按钮名字好听，就判断策略可信。命令行工具还可能依赖 Node.js 或 npm；是否需要，以当前工具说明为准，不必为了量化学习把所有工具都装上。

“明明装过这个库，运行时却说找不到”，常见原因不是库消失了，而是你有多个 Python：系统 Python、独立安装的 Python、Conda 环境，编辑器运行的是一个，安装依赖用的是另一个。

过去常见的建议是 Python 3.10 及以上，但版本选择不能永久照搬。先检查课程项目和依赖支持什么版本，再固定环境。版本太新，某些二进制库可能还没有适配。Windows 还可能需要配置 PATH；Mac 和 Linux 的命令名称、路径也可能不同。

在准备运行代码的同一个终端里检查：

import sys
print(sys.version)
print(sys.executable)

sys.executable 会告诉你实际运行代码的解释器路径。安装依赖时，使用这个解释器对应的 python -m pip，并在编辑器里选择同一个项目解释器。隔离环境可以减少不同项目互相影响，但创建命令按你的系统和项目约定执行。

先把环境确认清楚，再让 AI 给命令。否则它可能套用错误的系统命令，或者帮你把包装到了另一个环境。

把依赖想成不同岗位，不要一次装齐：

• Pandas 等数据处理工具：处理表格和时间序列，做窗口计算，读写文件。读写 Excel 可能还需要对应引擎；
• 行情和财务数据服务：提供行情或财务字段。字段、覆盖范围、权限和调用限制要逐项核对；
• 券商通信工具：例如 XtQuant、miniQMT 这类环境，用于连接指定本地终端和相应业务。包存在，不代表终端、账户和交易权限已经可用；
• 大模型 SDK：例如 DashScope 这类云服务 SDK，用于调用文本或视觉模型。模型名、SDK 和鉴权方式会变，使用前要看当前文档；
• Jupyter：可以分段运行代码、查看中间变量和图形，是可选的交互学习工具，不是回放必需品；
• Node.js/npm：某些命令行编程工具的运行依赖，是否需要取决于工具本身。

云端模型和本地模型是两种部署方式。云端不用自己部署模型，但仍要考虑网络、凭证、费用和发送哪些数据。聊天工具的额度，也不能直接当成程序 API 的额度。

Jupyter 有一个隐蔽问题：单元格不按顺序运行时，内存里可能还留着旧变量。最后要重启内核，按顺序完整运行；或者把核心流程整理成能重复执行的脚本。

一个适合入门的项目，可以分成五个位置：原始数据、处理后的数据、策略代码、结果、说明文档。原始数据要保留来源和版本，清洗时不要覆盖唯一副本。

第一个任务只做历史指标：读本地 CSV，检查必要字段，计算均线，输出图和信号表。先不接行情 API，也不接交易端。这样，算法错误和网络、权限错误不会混在一起。数据链路稳定后，再加数据服务；最后才讨论模拟执行，并把真实账户隔离开。

可以给 AI 这样的实施请求：

先阅读现有目录和字段说明，复用已有读取函数。增加 MA5 与 MA20 交叉信号，信号由前一个时点与当前时点比较得到。输入缺少日期或收盘价时停止并说明，不创建模拟行情。输出证券代码、信号日、参数和原始文件名。完成后运行一个正常样例和一个缺失字段样例，报告实际结果。

完成后先看实际改了哪些文件。再用一份可以手算的小数据核对均线，检查重复日期和缺失值。测试不是越多越好，而是要抓住真实错误；如果测试和实现写得一模一样，可能只是证明代码能通过自己的假设。