AI 开始让我们忘记什么是软件工程

最近几天，我在做一个费率套利机会扫描的项目。

我来描述一下最近几天干了什么：

• 10月28日，在 Vultr 上创建了一个 2v4G 的服务器，把资金费率相关的项目，从旧的服务器以及旧的代码仓库上，迁移到新的服务器和仓库，具体包括：

  1. 创建 GitHub 仓库、在服务器上准备好 Postgres 数据库、GitHub Action Runner、配置好 Grafana 的采集、Cloudflare 域名的 DNS 解析、代理等
  2. 也不是简单的复制代码，而是用 Rust 重写后端，所以所有的代码都在重构（当然是让 AI 写）
  3. 迁移了 5 种交易平台的 Accounts 和 Positions 模块，迁移但没有实际测试和完善
  4. 开始处理 KuCoin 分页、盘口适配等问题，比如原本的代码 KuCoin 分页结束得到 null 当成了接口出错处理导致进度异常；比如 Bitget 的 Orderbook 接口换成了 V3 版本的接口；
  5. 优化采集的 worker 程序，明确区分历史采集、公共采集和排名计算三类 worker；修复当时阶段的调度饥饿的问题，把服务器资源分配给 3 个 worker 轮转

• 10月29日，将采集数据和发布数据，从原本的手动触发、根据用户的请求触发，改为滚动采集 7 天历史数据、后台自动发布排名 Snapshot，细节包括：

  1. 采集层进一步优化调度问题，因为在重构为自动滚动采集数据后，调度问题变得重要，修复资金费与价格任务互相挤占、长期排队的问题
  2. 移除按用户参数创建快照的旧模型，改为冻结关键证据比如 Funding Rate 和 Orderbook depth 等需要采集的数据，发布全局共享的 Snapshot，然后再根据用户参数比如初始金额、杠杆倍数等，实时计算排名结果
  3. 实际测试和修复 Accounts、Positions 模块的功能，导入了 5 种平台的账号信息，参考旧平台的逻辑修复了匹配后仓位的收益计算方式；解决请求 Bitget 平台 api 参数多了个 ? 导致失败的细节问题；从原本的页面迁移过来配对仓位的历史收益图；
  4. 进行大量平台 api 请求的合并，以减少扫描 job 的数量；因为目前需要扫描 1000 多个代币 * 17 个平台 * 每个平台需要 spot price/ funding rate/ orderbook depth 三四类数据 * 1h/1d/7d 等不同时间周期，一开始这些因素叠加起来多达 45000 个扫描 job 排在队列里；首先要做的优化就逐个平台合并请求，这确实很有效，比如从 Bitget 的平台，能够一个请求几十个代币的 funding fee 数据，或者一个请求得到某个代币过去 7 天的价格数据等，这样大量合并请求后扫描 job 的数量下降到 15000 个左右；
  5. 一些常规的数据库操作优化，比如加好索引、排名数据加缓存、减少大对象的频繁读写等；当天下午 CPU 占用持续超过 100%，就把服务器升级到了 4v8G 的规格

• 10月30日，进一步优化采集数据和发布数据的效率问题，具体包括：

  1. 进一步合并和优化不同平台的请求方式，让常驻 job 队列从 1万多个下降到常驻 2000 多个
  2. 修复股票数据休市的处理逻辑，以前因为休市期间没数据直接把数据状态标记为不可用，修复后能正确识别股票的休市情况
  3. 新增 Live 榜单，以前的数据都属于回测数据，Live 榜单则是展示实时各平台的资金费率差异情况
  4. 去掉原本的 presets（预置筛选参数）的功能，改为针对代币的 favorites 功能，收藏的代币单独作为 tab 展开
  5. 改善采集数据的优先级，针对大平台、大代币，优先采集数据；发布数据方面则是分阶段发布的方式，在 favorites 列表里的代币会优先单独发布 Snapshot
  6. 增加 spot + coin-M perp 的示例，先接入了 Bybit 的 BTC/ETH，采集的数据源不同

• 10月31日（今天），重点解决采集数据进度，以及发布的排名数据不全的问题：

  1. 先是修复昨晚因为给数据发布的逻辑加上了优先级、分阶段发布，导致新的、排名不全的榜单数据覆盖旧榜单的问题
  2. 排行榜没数据的问题，还有几个口径过于严格的原因：1) 如果代币的身份未验证，也就是合约地址没有实锤，就不会参与到排行数据的计算；这一点阻塞了大量代币的数据，因为平台多、代币多、有大量得不到证据信息的代币；2）如果两腿合约的 orderbook 数据时间差距超过 20秒，也不会参与计算；这一点影响很大，因为 orderbook 数据恰好匹配的概率不高，现在放宽到了 2分钟，以及数据不新鲜也要计算；
  3. 排名数据计算时间过长的问题，因为有 1000 多个代币在 17 个平台两两配对，有 1万多种组合（得先计算 APR 数据再聚合），所以光是从现有的数据库读出数据后进行排名数据的计算（CPU 计算密集型），时间超过 1 分钟；目前的解决方式是把 OI 和 Orderbook depth 作为过滤参数设置为 100k，过滤后只剩下 200 多种组合，加载和计算速度都很快；
  4. live 榜单增加实时 orderbook depth、OI、成本数据，优先请求和计算第一页榜单的代币数据；
  5. 另外还是优化 job worker 的调度问题，因为 orderbook 时刻都在过时、时刻都需要刷新，导致每分钟生成几百个新的 job 到队列里，阻塞 spot price 和 OI 的索引迟迟不推进，优化了这部分调度问题；
  6. 列表增加 compare 模式，可以对比两个不同 period 的列表数据

这些改动都是我有印象的、遇到的和解决的问题，因为现在让 AI 改功能，有些小问题 AI 自己就消化解决了，我都不需要知道问题的存在。

我为什么要列举这些具体的工作呢？因为今天开会的时候，同事描述了一个场景：在他的 Mac 电脑上，让 Claude 指定几十种代币采集 2 天的资金费率和价格数据、采集七八个主流平台、汇总分析、出页面，只需要十几分钟的时间。为什么 Funding Spy 这个项目索引数据这么慢？

其实我也不知道为什么这么慢，我也说不上来；我只知道遇到了很多小问题、在不断修复和优化那些问题，我也不知道为什么这么慢，数据还总是不全。

为什么呢，可能是因为 AI 的存在，让大家忘记了软件工程本应该有的样子。做一个 Demo，和建设一个能够持续运转的、滚动采集全量数据的平台之间，有没有很大的距离。以前车马慢，大家做项目， 1个月设计原型、3个月出 Demo、6个月开发成型，如果遇到行情不好，持续开发迭代个一两年都是家常便饭，有可能成功有可能失败。

后来有了 AI，原型不用出，做一个 Demo 两小时，开发一个产品两三天。效率提升了，速度变快了，但是大家似乎忘了软件工程客观存在的复杂度和应有的规律，认为这么快的迭代速度本就是软件开发应有的样子。这么快有问题吗？好像也没问题，时代发展就是这样。只是 AI 让程序员的开发效率提高了，却没有减少程序员的工作量，而是相应的让软件开发的工期变短了，你看这事闹的。

猜一猜我解决上面列出来的那些问题，每天需要花多少时间和注意力在工作上？我说个数字，10月28日到10月31日，这 4 天时间，一共 commit 代码 281 次，触发自动部署的工作流 258 次，每次部署的时长大概 5 分钟到 10分钟，部署完成后才能验收代码的运行结果、继续下一次改动。

对了，我最近仍然在复习去年学习的 视频课 的练习题。比如我现在能写得出二元表达式语言的解释器，就是去年课后提到过的 这个。然后呢，我理解了解释器的基础原理，跟真正开发一种编程语言之间，有多大的距离呢。我知道差距非常大，因为编程语言是工程化的产物，和理解原理不是一回事。

对了，我稍后还会再总结一遍做课程练习题的 体会。