一个跨两个服务的小需求：AI 写代码只用了 6 分钟，剩下一天半花在了哪

TL;DR 一个很普通的需求，要改两个服务。AI 从开始写到两边都写完、单测都通过，只用了 6 分钟。可整个需求从读需求到测试环境跑通，花了一天半。

这篇没有什么新技巧，就是把这一天半的时间账摊开来看。结论很朴素：AI 让写代码几乎不花时间了，剩下的时间全花在了“写代码之外”的事情上。

一、需求是什么

需求一句话就能说清：把用户最近一次预审的结果存下来，做成一个风控变量，给策略使用。

预审：用户正式申请借款之前，系统先快速判断一下“大概能不能批”。策略同学希望在后面的流程里，能看到这个用户上一次预审的结果。

涉及两个服务（就是上一篇接手的那两个）：

审批服务：预审算完 ──写入──→ 一张 KV 存储表
                                    │
变量平台：新增一个取数插件 ──读取──┘ ──→ 作为变量返回给策略

注意，这两个服务不直接互相调用，而是通过一张共享的表交换数据。双方要对齐的不是接口，而是“表里存什么、存成什么格式”。

二、时间账

时间	做了什么	耗时
10-09 15:06	把需求丢给 AI，让它先出方案，不写代码
15:24	方案出稿，发到文档里	18 分钟
15:46 ~ 17:05	我审方案，改了 4 处	约 1 小时 20 分
17:05 → 17:11	AI 在两个服务各切新分支，写完代码，两边各 7 个单测全过	6 分钟
17:16 ~ 18:26	配置、测试环境的数据准备、打包问题	约 1 小时
10-10 14:34 ~ 15:53	让 AI 写一个可以反复跑的验收测试，连续失败 3 次才通过	约 1 小时 20 分
16:07	两个服务串起来的端到端测试跑通

真正写代码的时间是 6 分钟，占整个过程的零头。下面看剩下的时间都花在了哪里。

三、审方案：4 处修改都是业务判断

AI 的方案写得很完整，但这 4 处修改，没有一处是它能自己决定的：

另一条产品线不写入。方案默认两条产品线的预审都存，我决定只存一条；
数据不设过期时间，存量用户不回刷。上线前预审过的用户，变量先返回默认值；
能不能在测试环境和沙箱提前验证，避免上线当天才发现问题；
存预审接口返回的整个结果，而不只是需求要的那一个字段。以后要新字段，审批服务不用再改，变量平台多取一个字段就行。

AI 在这个阶段也补上了几处我没想到的地方：

沙箱连的是生产存储。如果沙箱也写那张新表，沙箱里的测试预审会覆盖真实用户的“最近一次结果”。所以沙箱必须配一张单独的表；
回测环境同样连着生产存储。回放历史预审时如果也写入，同样会覆盖真实数据。AI 主动把回测环境的写入开关设成了关；
测试环境两边连的不是同一个存储集群，不改配置的话，变量平台根本读不到审批服务写入的数据。

可带走的经验：方案阶段花的时间最值。“写哪些、不写哪些、存多少、在哪个环境写”是业务判断，要人来拍板；“这个环境连的是哪个集群”这种事，交给 AI 去翻配置，它比人细。

四、验收测试：连续失败 3 次，每次原因都不同

10 月 10 日，两个服务都部署到了测试环境。我让 AI 写一个可以反复运行的单测：直接调测试环境的变量平台，看能不能查到审批服务存进去的数据。

结果前 3 次都没通过，第 4 次才通过：

第几次	现象	原因	属于哪一层
1	返回默认值 `-99`	平台上“提取字段”配成了整个对象，没取到里面的值	配置
2	还是 `-99`	页面改了配置，但服务的缓存还没刷新	缓存
3	报“取数插件不存在”	部署的包里根本没有新代码：版本号没升，打包时从仓库里拉到了 9 月 17 日同版本号的旧包	发版
4	4 个用例全过	合并主干、升版本号、重新部署

第 3 次和第 4 次之间还有个插曲：AI 一开始建议改部署平台的构建命令。我说“这个从来没改过，正常默认应该就是都编译的啊，应该是要改版本吧”，它确认是自己判断错了。

然后又把两个服务串起来跑了一遍端到端：调用预审，再查变量，确认查到的正是刚才写入的那一条（时间戳和流程号都对得上）；另一条产品线预审之后，变量值不变。

这个过程里，单测本身没有任何技术含量，就是一次查询加几个断言。它的价值在于能反复跑：每次改完配置或重新部署，一条命令就知道这次好没好。如果每次都靠人工去页面上试算，这几轮会慢得多。

还有一个小插曲：端到端测试时，测试机刚被重新部署过，路由分组变了，预审直接报系统异常。AI 在测试代码里显式指定了路由，绕过去了，同时提醒我这台机器上其他请求也会受影响，如果不是我有意改的，建议问一下。

可带走的经验：

跨服务的需求，把验收写成可以反复跑的测试，第一次部署就写，不要等到最后；

测试失败时，先分清是哪一层的问题：代码、配置、缓存还是发版。这次 3 次失败，没有一次是代码的问题；

“部署成功”不等于“新代码上去了”。AI 那次是登录机器、打开 jar 包看类的编译时间才发现包是旧的。

五、如果是三个服务，A 依赖 B，B 依赖 C

这次只有两个服务，而且是通过共享存储解耦的。如果换成 A 调 B、B 调 C 的链式依赖，按这次踩过的坑推演，有几处会明显变难（以下是推演，不是这次的亲身经历）：

方面	两个服务（这次）	A → B → C
要对齐的约定	一处：表里的数据格式	两处接口，下游任何改动都会往上游传
发版顺序	两边相对独立	从最底层往上发：先 C，再 B，最后 A。回滚顺序正好相反
版本号问题	踩了一次：版本没升，部署的是旧包	风险翻倍：B 要依赖 C 的新接口包，A 要依赖 B 的。任何一层没升版本，上层可能编译通过、运行出错
验收方式	一个端到端测试，失败了逐个排查	分层验收：先单独验 C，再验 B 拿到 C 的数据后的输出，最后才做 A 的端到端。否则一次失败要在三层里找原因

核心思路和这次一样：每一层都有一个能反复跑的测试，从下往上逐层确认。

结语

这个需求让我对“AI 提效”有了一个更实际的认识：写代码的时间几乎被压缩到零，但需求的总时间并没有按比例缩短。 剩下的时间花在了三件事上：

方案里的业务判断，只能人来做；
环境之间的隔离（测试、沙箱、回测、线上分别连的是哪个存储），AI 帮着查，人来确认；
配置、缓存、发版这些代码之外的环节，靠一个能反复跑的测试来兜底。

所以现在拿到需求，我不再先想“代码怎么写”，而是先想“怎么验证它真的好了”。

下一篇：AI 是怎么操作你的浏览器的？系统脚本、MCP、直接调接口，三种方式的原理、场景和风险