只需2步，2个小时拓展一个城市的养老金测算功能

今天继续拓展养老金测算工具的覆盖城市时，我把“新增一个城市支持”这件事重新拆了一遍。

表面看，它是一个工程问题：

查政策
补数据
写配置
接页面
跑测试
处理 warning
上线城市入口

但真正推进时会发现，最难的并不是写代码，而是让“查资料”和“写代码”之间形成稳定交接。

养老金测算很特殊。它依赖大量地区政策、官方通知、统计口径、缴费上下限、养老金计发基数、个人账户记账利率、Z/Q 平均缴费指数规则。这里面很多数据必须来自官方渠道，不能靠模型猜，也不能靠第三方文章直接入库。

所以今天我没有把流程设计成“让一个模型从头干到尾”。

我把它拆成了两步：

第一步：WorkBuddy 负责官方资料采集和数据清单修订。
第二步：Codex 负责数据准入、代码接入和测试验收。

这两个动作一分开，复杂度明显下降。

不是因为事情变少了，而是因为每一步的失败边界变清楚了。

工具分工：为什么先交给 WorkBuddy

新增城市支持，第一步不是写代码，而是确认这个城市到底能不能算。

比如一个城市至少要回答这些问题：

当前缴费上下限是多少？
养老金计发基数是什么？
基础养老金公式是否明确？
个人账户养老金公式是否明确？
有没有过渡性养老金？
历史个人账户记账利率缺不缺？
平均缴费指数 Z/Q 的分母规则是什么？
断缴、补缴、失业、异地转入怎么处理？

这些问题大部分都需要官方来源。

考虑到官方资料主要分布在人社、税务、政府公报、统计年鉴、政策解读等渠道，而腾讯生态里的 WorkBuddy 更适合做这种资料检索、网页访问和信息整理，我把“信息采集”这一步放给 WorkBuddy。

但当前还有一个现实限制：

Codex 还没有配置直接调用 WorkBuddy 的通路。

所以今天采用了一个最简单、也最稳的方式：

Codex 生成任务指令。
人复制这段指令。
人粘贴给 WorkBuddy。
WorkBuddy 在指定目录下更新数据清单。
人告诉 Codex：信息收集完成，请继续。
Codex 再读取数据清单，做准入检查和代码接入。

这个链路看起来不够“自动化”，但它有一个好处：每一步都可控。

在政策数据还没有完全结构化、工具之间还没有打通之前，先用“人转述任务”的方式跑通闭环，比追求一开始全自动更可靠。

数据交接：把城市资料变成数据清单

WorkBuddy 的任务不是“随便查一查这个城市的养老金政策”，而是按固定模板产出地区数据清单。

这个清单必须明确：

哪些数据已经找到官方来源？
哪些只有第三方线索？
哪些是政策推导？
哪些找不到？
找不到会影响什么？
是否允许进入 H5 接入？

今天重点强化的是“工资和基数”的拆分。

因为新增地区最容易出错的地方，就是把几个相似概念混成一个字段：

本地社平工资
全省全口径工资
在岗工资 / 非私营在岗工资
养老金计发基数
缴费基数核定工资
历史 Z 分母工资

这些词都像“工资”，但用途完全不同。

一个可能用于首页“历年社平工资”图，一个用于基础养老金公式里的 A，一个用于缴费上下限，一个用于历史平均缴费指数。

如果信息采集阶段没有拆清楚，代码阶段就会很危险。模型看到字段里有数，就可能顺手复用；页面也能画出来；测试也未必立刻报错。但结果的政策口径已经偏了。

所以第一步的核心不是“收集更多资料”，而是把资料整理成可交接的结构：

每条数据是什么概念？
用于哪个计算位置？
适用哪些年份？
来源等级是什么？
有没有 sourceUrl、sourceTitle、retrievedAt？
缺失时应该 warning、debug，还是阻止上线？

这一步完成后，Codex 才能接手。

工程接入：Codex 只接收通过准入的数据

WorkBuddy 更新完数据清单后，Codex 不应该立刻写代码。

第二步的第一件事，是数据准入检查。

也就是先问：

这个城市当前是否可计算？
是否缺少当前上下限？
是否缺少养老金计发基数？
是否缺少基础养老金公式？
Z/Q 规则是否足以支撑平均缴费指数？
缺失项会不会导致结果误导？

如果准入不通过，Codex 不继续编码，而是生成一段补充采集指令，再交给人转发给 WorkBuddy。

如果准入通过，Codex 再做代码接入：

写地区配置
接城市入口
接首页四张图
接测算页公式工资
接缴费上下限
接 warning/debug
补推荐方案口径
跑构建、lint、必要测试和浏览器验证

这一步里，Codex 的优势就很明显。

它适合在明确规则下做工程落地：改 TypeScript 类型、拆字段、同步地区配置、更新页面、补 warning、检查差异。

但前提是第一步已经把边界切清楚。

否则 Codex 的速度会变成放大器：边界正确，它放大效率；边界错误，它放大错误。

异常场景：已有初稿，但有瑕疵

真实工作里，最常见的不是“从零开始查一个城市”，而是：

这个城市已经有数据文件初稿。
里面有不少内容。
但来源等级不统一，字段缺失，口径混在一起，部分结论语气过强。

这时流程不能退回到“人自己整理一遍”。

预期动作应该是：

Codex 读取现有初稿。
Codex 找出缺口和风险。
Codex 生成一段可复制的 WorkBuddy 优化指令。
人复制粘贴给 WorkBuddy。
WorkBuddy 按指令修订原数据清单。
Codex 再做准入检查。

这就是“人转述任务”模式的价值。

人不需要重新组织全部细节，只负责把任务从 Codex 递给 WorkBuddy。真正复杂的缺口描述、修订范围、输出格式，由 Codex 根据现有文档生成。

今天处理广州、天津、北京、上海、重庆等地区数据时，这个模式尤其明显。

有些地区不是没有资料，而是资料已经有了，但还差关键整理：

工资和基数概念没有独立章节。
首页四图的数据来源没有明确。
计发基数和社平工资的关系没有写清。
第三方来源被放得太靠前。
缺失数据没有说明影响范围。

这些问题不需要推翻重来。

只要 Codex 能把“需要 WorkBuddy 修哪里”写成明确指令，流程就不会崩。

异常场景：信息真的找不到

第二类异常更重要：

有些信息就是找不到。

比如某些年份的地方个人账户记账利率、早期缴费上下限、历史 Z 分母口径、特殊身份的补缴规则、异地转入指数重算细则。

这种情况不能靠模型硬补。

更不能为了让城市上线，把缺失值悄悄塞成默认值。

今天形成的处理原则是：

找不到，就承认找不到。
能降级，就明确降级。
不能降级，就阻止上线。

具体到系统里，可以有几种退化处理：

缺少首页展示序列：可以不展示该图，或显示短序列，但不能伪造成连续历史线。
缺少养老金计发基数：不能做官方口径待遇测算。
缺少 2016 年前地方记账利率：可以用于未来缴费粗估，但历史账户反推必须 warning。
缺少异地转入细则：不能把转入账户余额自动折算成更高历史 Z。
缺少深圳历史社平核验：不能用临时占位数据生成连续估算图。

退化不是失败。

退化是让系统诚实地告诉用户：这部分我们能算，这部分只能估，这部分暂时不能算。

对养老金工具来说，这比“看起来完整”重要得多。

方法价值：把复杂任务变成可重复管线

今天把流程拆成两步后，新增城市支持不再是一团复杂任务，而变成一个可重复管线：

WorkBuddy：找官方资料，修数据清单。
Codex：做数据准入，接入 H5，跑验证。

人的角色也变得清楚：

人不是手工搬运所有资料。
人是当前工具链之间的路由器。

在 Codex 还不能直接调用 WorkBuddy 的阶段，人负责复制粘贴任务，确认 WorkBuddy 产出已经落到指定文件，再让 Codex 继续。

这一步很轻，但很关键。

它把两个模型的能力接起来了。

能力边界：模型和人到底差的是什么

模型和人的差距，不主要在勤奋程度，也不主要在记忆量。

模型可以读文件、找差异、生成指令、改代码、同步模板、补测试。

但人真正不可替代的地方，是对概念的洞察，以及在相似概念之间灵活迁移的能力。

比如，当我们发现天津的“养老金计发基数”和“全市职工月平均工资”必须分开时，真正有价值的不是记住天津这个结论。

真正有价值的是意识到：

北京、上海、重庆、广州、深圳也要重新检查：
首页社平图用什么？
计发基数图用什么？
增长率到底来自哪条序列？
测算页公式工资是否和首页展示同源？

这就是迁移能力。

复制是把一个答案搬过去。

迁移是把一个问题结构搬过去。

模型很擅长复制和执行，但人要负责识别“这里真正可迁移的是结构，不是数值”。

长期收益：物理时间中的思维升级

这套两步法不是一开始就想完整的。

它是在真实具体工作里逐渐长出来的：

先发现广州不能把省级缴费参数表和计发基数混成一张线。
再发现深圳不能用临时社平占位生成连续估算图。
再发现天津的待遇公式工资和全市职工月平均工资必须分图。
再回头意识到，北京、上海、重庆也需要显式说明是否同源。
最后把这个发现写进数据采集指南、H5 实现指南、任务模板和代码字段。

这不是“想明白一个道理”。

这是在真实推进中，被数据、代码、文档和异常情况反复校正出来的。

所以我越来越觉得，AI 时代的思维升级不是脱离工作发生的。

它发生在物理时间里：

遇到一个模糊概念。
拆开它。
遇到一个失败边界。
写成契约。
遇到一个工具断点。
用人做临时路由。
等流程跑通，再考虑自动化。

今天这套方法最后可以总结成一句话：

新增一个城市的养老金测算功能，只做两步：
先让 WorkBuddy 把官方资料整理成可审计数据清单；
再让 Codex 基于准入规则完成接入和验证。

看起来是工具分工，底层其实是思维分工。

人负责定义问题结构。

模型负责在结构里高速执行。

定义准了，模型会把速度释放出来。

定义错了，模型只会把错误规模化。