背景介绍
掌握技能最快的方法就是用技能创造产品，前一阵子对 GPT 辅助编程与项目生成做过较多的调研，但是一直处于试水阶段，没能发挥出 GPT 辅助编程的能力。
本次从新领域入手，借助 GPT 的力量，从 0 手撸一个量化交易回测平台，从这个过程看看 GPT 辅助编程到底有多强，能多大程度帮助程序员，是否有可能替代程序员。
效果展示
实际花费 2 周的休息时间，耗时 116 个番茄钟，从 0 撸出一个量化交易回测的服务。当前支持了 Windows，Linux，Mac 平台，支持本地一键启动，一秒化身量化交易回测服务器。效果如下：
接入了实时和离线的数据源，实时数据源来自于 yahoo finance，内置了 KDJ, MACD, 突破，动量与海龟策略，支持策略参数动态调节：
回测效果支持了交易回测 K 线图，账户价值变动与年化收益率曲线，最重要的还支持了详细交易记录的展示与导出：
最后还给他配上一个亮闪闪 icon，方便随开随用：
当然时间精力有限，而且没有设计师协助，页面目前还基本上工程师审美阶段，但是流程基本上完备了，自我感觉算是一个合格的 MVP 产品。
大模型工具
在本次实践过程中，主要尝试了下面的一些大模型工具：
- GPT Engineer， 一款类似之前大热的 Auto GPT 的项目代码生成工具，可以根据需求描述直接生成完整的项目代码；
- chatALL，一个多 GPT 同时响应问题的工具，可以同时对接多个 GPT，提升 GPT 查询效率；
- Github copilot，微软出的编程协助工具，直接在编程 IDE 开发中帮助生成代码，提升编程效率；
实践过程
项目生成尝试
在之前 GPT Engineer 实践与源码解析 的文章中提出过一个想法，基于 GPT Engineer 根据原始需求直接生成项目代码，然后基于编程辅助工具 Github copilot 进行高效的二次开发，那么程序员开发的效率应该可以得到极大的改善。本次就来验证这个想法的可行性。
实际测试时提供给 GPT Engineer 的 prompt 如下所示：
请实现一个量化交易回测 web 服务，支持接入离线和实时数据，并支持多种量化策略，并支持可视化展示回测效果
最终实际生成了下面的基于 Flask 的 Web 服务:
对项目模块做了很好的分拆，其中 data_manager.py 用于数据管理，strategy.py 用于策略管理，visualization.py 用于可视化，甚至包含相关依赖文件和启动脚本。看起来一切就绪？
远没那么简单，在这个相对复杂的需求前就可以看到 GPT Engineer 的不足之处。GPT Engineer 可以帮助搭建一个简单的代码框架，但是没有任何的实现细节。生成的内容对于不知道怎么搭建一个 Flask 的 Web 服务的小白可能有一些作用，但是对于重点在如何做一个量化交易回测服务没有任何的帮助。
后续又补充了必要的技术选型的细节, 使用 GPT Engineer 生成，依旧表现不佳，只能生成偏框架流程的代码，看起来 GPT Engineer 靠单纯组织 prompt 希望实现一个完备的项目只能适用于极小的项目需求，复杂需求下不太实用。
技术选型
依赖 GPT 直接生成项目不可行，接下来就考虑可以建立在哪些库的基础上实现完项目。合适的技术选型可以帮助尽可能减少开发工作量，同时保证项目的质量。
接下来就需要拆分量化交易平台的需求，至少包含哪些部分：
- 数据来源接入，考虑支持离线和实时数据，实时数据接入的来源；
- 量化回测库的选择；
- 可视化交互支持；
这个时候就可以用上 chatALL，同时对接上多个 GPT，避免单个大模型知识来源有限，胡说八道的问题。通过选择多个 GPT 答案中的交集，大概率是靠谱的。在 chatALL 中我一般选择的模型是 GPT3.5, Bard 和 Bing，在 Bing 使用报错切换为 Claude，这几个是在免费版本中最强的。在多个 GPT 都无法解决的复杂问题，则会使用付费的 GPT 4 的 API。这个时候就体现出 chatALL 的优势所在，在不同大模型之间无缝切换，体验极其丝滑。
对于完全不熟悉的情况下做技术选型，我实际尝试时会将其拆分为两步：
- 描述业务需求，让大模型给出所有的备选项，综合多个 GPT 的结果，根据高频结果大概就能知道合适的范围，人工初筛排除掉完全不靠谱的；
- 描述业务需求与自己关注的点，提供备选库列表，让 GPT 描述不同备选方案的优劣点，适合什么场景，使用中可能会存在什么风险，让其推荐最适合的，结合 GPT 的推荐与适合场景选择最佳方案；
基于确定的技术选型框架组合，可以利用 GPT 快速生成的 demo 的能力，得到基础版本的的 demo，通过实际测试和验证，确定技术选型的可行性与正确性。类似如下所示的效果：
针对量化回测的需求，出于交互实现最简化，上手门槛最低，而且考虑到基础库的可维护性，最终选择了 Dash + Backtrader 的组合。
Dash 可以快速搭建可视化 Web 服务，开源版本的 Dash 包含的组件的丰富度和美观度都相对较好。Backtrader 框架提供的能力完备，而且可维护性强，关键是相对其他库上手成本低。
模块级开发实践
常规的项目开发时，一般都会先搭建整体的服务框架，然后在服务框架的基础上填充功能。本次在人 + GPT 协作开发全新的服务过程中，实际尝试下来感觉积木组装的方式可能效果更好。
根据前面 GPT-Engineer 的实践以及之前更强大的全自动的 Auto-GPT 使用的效果来看，目前阶段 GPT 很难支撑全自动复杂框架的开发，但是范围边界明确的小模块的开发是可行的。为了充分利用 GPT 现有的能力，因此人工可以对完整的需求进行拆分，然后用更小的模块进行代码生成，之后进行积木式的组装。
在实际的量化交易回测的服务中，将原始的需求拆分为如下所示的模块：
- 数据接入的支持；
-
基于 backtrader 算法实现；
- KDJ 策略
- MACD 策略
- 突破策略
- 动量策略
- 海龟策略
-
可视化交互；
- 回测操作区的可视化
- 回测效果展示的可视化（这一块存在很多不确定性，需要进一步确认）
虽然每个模块拆分后可以分块按照顺序推进，但是考虑到新领域的不熟悉，可能存在很多不确定性，因此采取敏捷管理的思路，先生成部分小模块，组装出一个小积木。因此先实现离线的数据管理模块，然后实现 KDJ 策略，再完成回测效果的可视化，组装出一个最小的 MVP。
实际生成单个模块的体验还是比较友好的，在框架和需求明确的情况下，GPT 们都会给出对应的代码实现：
看起来是不是很轻松，GPT 甚至连测试代码都生成好了，看起来程序员需要做的就复制粘贴，然后组装起来就好。但是实际中还是会碰到一些问题，主要的问题在于人往往有自知之明，但是 GPT 显然没有。GPT 有时候会给出看起来正确，但是实际存在问题。
有时候的是因为第三方库的接口发生了变更，而 GPT 实现的依旧是老版本的代码，有时候使用不存在的库或其他的问题，但是 GPT 带来的好处依旧是有的，因为测试代码一般都是配套生成的，有些不靠谱的实现很快就能排除。
关于 GPT 容易犯错，稍微复杂的问题搞不定的问题，我实践出下面相对靠谱的补充方案：
1、先请 GPT 介绍对应的原理，并包含实现的步骤，根据其中的原理可以方便判断 GPT 给出的实现方案是否靠谱；
2、如果原始问题对于 GPT 过于困难，可以对其进行进一步分解，使用 GPT 实现更小模块的开发；
比如实现 KDJ 策略不正确，从原理上了解到实现是先确定 K,D,J 三个指标，然后基于指标确定买入卖出机制。因此可以让 GPT 先生成三个正确的指标，确定指标的实现的正确性之后，再基于指标实现金叉买入，死叉卖出等交易机制。
在完成各个模块的开发之后再进行必要的组合，甚至可以将组合的过程也看成一个特定的模块，使用 GPT 进行生成然后整体合并。
即便如此，实际中还是碰到一些 GPT 无法解决，需要自行研究官方文档去了解基础框架的实现原理，考虑到项目中使用的基础框架确定后就会存在对框架的严重依赖，而 GPT 对基础框架的了解存在时效性或知识不足的问题，因此一个可能的解决方案就是基于 RAG, 通过外接向量化的官方文档知识库解决 GPT 存在的时效性和知识不足的问题，目前已经存在一些基于 langchain 的解决方案，比如 langchain-chatchat，这个后续会抽空做一些调研，希望能进一步提升开发效率。
总结
文章本来是希望介绍量化交易回测工具的从 0 手撸的实现过程，但是实际想想，授人予鱼不如授人予渔，单个量化交易回测工具作用有限，但是如果用好了 GPT 工具，只需要花上一丢丢时间，你也能创造一个。
关于程序员是否会被 GPT 替代的问题，我个人的感受是不必焦虑，人类与动物最重要的区别就在于是否善用工具。GPT 目前来看还不足以替代人工，但是从长期来看，最终善用 GPT 的程序员终究会替代史前时代的程序员，就像善用电脑的技术人员终究会替代擅长心算的技术人员。滚滚的历史洪流，我们总归需要随波向前。
