当医保飞检遇上服务器注销，历史数据面临永久丢失的危机。本文作者临危受命，在无文档、无专家、无退路的绝境中，借助豆包与Codex两大AI工具接力攻坚，从零开始连库、查表、写SQL，最终成功导出合规数据。这不仅是一次技术救援，更是一场关于AI实战价值的深度验证。

先说结论：很多人觉得 AI 没用，不是 AI 不行，而是你还没让它处理过一件真正的、棘手的、连你自己都没底的事。

就这两天，我接了一单看着就要”翻车”的活。

事情要从更早说起。之前从别的厂商手里接手了一批客户，客户的 HIS（医院信息系统）已经切换到我们的新系统。按惯例，切换之后，老服务器上还留着旧数据——这些历史数据，理论上应该保留一段时间，以防哪天需要查账、复核、应对检查。

结果呢？老服务器空跑了一年多，看着也没人再用，就有人提议：资源放着也是浪费，注销掉一部分吧。

于是，服务器被清理、注销了。

谁也没想到，变故来得这么快——医保飞检来了。有机构需要调取历史数据，应付合规检查。这一下，麻爪了。

客户找到我，说得很直接：老谭，这数据你得想办法给导出来。

其实最初，我们想的不是”导数据”，而是”把服务器找回来”。毕竟刚注销才两个多小时，理论上还能继续花钱把它供着，把旧环境重新拉起来。只要服务器能回来，后面的事就好办了。

可惜——没找回来。

服务器彻底够不着了，退路没了，只能走最险的一条：绕过服务器，直连数据库，把数据从数据库里捞出来。

问题是我自己心里也没底。这不是”打开客户端导个表”那么简单，而是要面对：

• 一台已经找不回来的老旧业务服务器
• 一套已经访问不了的老 HIS 系统
• 一个多年没人维护、只能直连的数据库
• 还有明确的、有时间范围和字段要求的医保数据口径

最关键的是——没有文档、没有在岗专家，原维护的同事也给不出可行方案。

这一仗，我没有退路，只能自己上。

今天，我把整个过程完整复盘一遍。不是为了炫耀，而是想用一个真实到不能再真实的生产案例，回答一个很多人都在问的问题：AI 到底能帮你干什么？

真正的难题，不是”不懂”，而是把陌生工作做成

很多人一听”导数据”，第一反应是：不就是写个 SQL 吗？

可我实际遇到的，是一个看起来像 SQL、实际却藏着四个问题的坑：

• 数据库怎么连？
• 机构在系统里的内部代码是什么？
• 处方和医保结算，分别落在哪些表里？
• “所有结算”到底怎么定义，才能不把预结算、退费和作废单据混进去？

而这四个问题里，最难、也最关键的一步，其实在最前面——先把这套已经访问不了的环境，重新连上。

对当时的我来说，服务器没有公网 IP、端口不知道、用户名密码更是没人记得。我要做的，是先把数据库连上。我没有亲手处理过这样具体的恢复工作，两眼一抹黑。

于是，我决定让 AI 来帮我打这场仗，而且用的是两个不同的 AI 接力：前半段用豆包，后半段用 Codex。

上半场才是硬仗：豆包帮我”把数据库连上”

要导数据，第一步不是写 SQL，而是——先把数据库连上。就这一步，就够我喝一壶的。

具体难在哪？我摊开讲：

• 没有公网 IP——服务器在内网，我在外面根本够不着它
• 不知道用户名和密码——账号密码早已无人记得
• 不清楚端口——不知道数据库监听在哪个端口

好在我电脑上有 DBeaver，连 Oracle 不用再装客户端，省了一道坎。剩下的难点就一句话：公网 IP、端口、用户名和密码——只要这对上，能连上就行。可偏偏，这三个我全没有。

这里，豆包成了我实时协作的技术搭档。我们的工作方式很朴素：我看到什么界面、遇到什么报错，就把截图和实际操作结果反馈给它；它负责识别问题、解释原因、给出下一步操作；我负责在现场执行和验证。

现场记录 1：豆包协助定位云服务器公网绑定问题

第一道坎，就是”没有公网 IP”。服务器在内网，我在外面连都连不进去。豆包根据我反馈的截图，一步步帮我把问题定位到网络可达性上——怎么才能让这台”看不见”的服务器被够到。

接下来，就是找回账号密码。端口配哪个、连接串怎么写、用户名密码从哪试起，全靠豆包根据我反馈的现场情况，一点一点拆解、试错、纠偏。

现场记录 2：根据实时反馈进入数据库运行环境，继续确认服务状态

这一路，绝不是”照着命令敲完就行”。公网 IP、端口、账号、密码，彼此相关，一处判断错误就会走进死路。

最终，靠着持续截图反馈和逐步纠错，数据库终于被我连上了。

别小看这一步。没有它，后面的一切都是空中楼阁。这是整个案例的地基。

上半场豆包帮我的，不是”写 SQL”，而是把数据库从”连不上”变成”连得上”。它愿意陪着我，在一个不确定、报错不断的现场，一点点试错、纠偏。而这一点，恰恰是绝大多数人用 AI 时最欠缺的——他们总想一步到位，遇到第一个报错就放弃了。

下半场：Codex 接手，把数据按正确逻辑查出来、导出来

数据库连上了，只是拿到了”钥匙”。真正的考验，是连上以后——怎么按正确的业务逻辑，把数据查出来、导出来。这一步，我交给了 Codex。

我把经过脱敏处理的连接参数，通过安全方式提供给 Codex（真实 IP、端口、账号密码，文章里一概不写）。它接手后没有盲目操作，先做最小化的连接验证——确认端口可达、账号能登录——然后就进入了正题。

最小权限 + 最小动作 + 可回退，这就是面对生产环境时，AI 该有的职业素养。它没有逞能，反而比我更谨慎。

先读数据字典，再判断业务表

进了正题，真正的考验才刚开始——面对一个陌生的 HIS 数据库，处方到底在哪张表？

这里，Codex 做了一个非常关键、也非常”专业”的动作：它没有立刻”全表 select *”，而是先读取了数据字典里的表名、表注释、列名和列注释。

这一步，就像到了一个陌生城市，先看地图，而不是闭着眼挨家挨户敲门。

通过”处方、医嘱、药品、剂量、频次、医保”这些关键词筛选，它帮我找到了完整的业务链：

• 处方主表：CLINICAL_SHEET
• 处方明细：CLINICAL_SHEET_DETAIL
• 门诊医令：OPD_MADE_ORDER
• 药品明细：OPD_MADE_ORDER_DRUG
• 药品基础档案：HOSPITAL_ORDER

更妙的是，表注释直接说明了关键关系：处方明细通过 OPD_ORDER_ID 连接门诊医令；门诊医令药品表保存剂量、单位、用法、频次；基础档案保存药品名称、规格、厂家和”处方药标志”。

现场记录 3：Codex 根据数据字典梳理处方表与医令表关系

你看，”找处方表”这件事，就从猜，变成了有证据的判断。

从机构名称，反查系统内部代码

需求里是两个真实机构，为了保护客户，文章里统一称为”机构 A”和”机构 B”，不披露名称、机构代码或任何可反查的地理信息。

这个看似简单的动作，其实是数据任务里最容易出错的一步：

• 如果把”机构名称”直接当成筛选条件，很可能查不到数据（系统里存的是内部代码）；
• 如果误用了相近的机构代码，结果就会悄悄变成另一家机构——这在大数据量下极难察觉。

Codex 先查询机构字典，再使用内部代码完成筛选，把这一步稳稳地锁死了。

机构 A

✓ 内部代码（已隐藏）✓ 查询截止日按需求设定

机构 B

✓ 内部代码（已隐藏）✓ 查询截止日按需求设定

把”医保结算信息”翻译成可审计的 SQL

需求里要的，是医保结算信息。好消息是，客户手里有一套现成的飞检脚本，提供了非常关键的参考。

Codex 读懂了这套脚本的逻辑，并把它翻译成了明确的规则：

结算表：正式医保结算使用 OPD_BILL_SETTLEMENT

结算类型：TYPE_ID = 2

结算号：SETL_ID 不能为空

关联：门诊登记、患者基础信息、门诊收据、门诊账单

排除：作废收据、挂号账单

最终查询，没有把逻辑藏在一个黑盒里，而是明确写出了每一条规则：

机构：使用内部机构代码筛选（代码不公开）

时间：从 2024-11-01 00:00:00 开始，截止日采用”次日零点之前”的半开区间

结算：OPD_BILL_SETTLEMENT.TYPE_ID = 2 且 SETL_ID IS NOT NULL

有效性：排除 VISIT_STATUS_ID=5、作废收据和挂号账单

医生：按需求提供的医生名单筛选（姓名不公开）

这里还有一个特别小的细节，但特别关键：原始名单里，有姓名分隔不清的情况。

Codex 没有擅自猜测，而是结合系统中的规范姓名进行核对，并在交付说明里记录了处理规则。这种”不猜、只查证”的态度，正是面对真实数据时最需要的品质。

导出来不算完，还要做一次”数据体检”

查询完成，Codex 把结果导出为 UTF-8 with BOM 编码的 CSV，方便 Excel 直接打开。

但真正让我放心的是最后这一步——它没有”导出来就交差”，而是又做了一轮快速体检：

• 检查行数
• 检查结算 ID 是否重复
• 检查医生数量
• 检查最早和最晚结算时间

机构 A · 已完成

✓ 唯一性已核验✓ 覆盖时间符合要求

机构 B · 已完成

✓ 唯一性已核验✓ 覆盖时间符合要求

这一步验证了两个重要事实：结果没有重复的结算 ID；实际数据覆盖范围符合需求设定。

（为了保护客户隐私，文章不展示患者数量、精确日期、医生分布等任何可反推的数据统计。）

会写 SQL 的 AI 很多，但肯在交付前替你做数据体检的 AI，才是真正能扛事的那种。

还没完：今天核查数据，发现取数逻辑错了

到这里，你可能以为故事该收尾了。

并没有。

今天，我又继续和客户一起核查数据。一核对，问题来了——有些取数逻辑是错的。

具体错在哪？比如”总费用””纳入统筹额””基金支付额”这些医保口径，字段和真实业务对不上。客户指出来，我才意识到：逻辑错了，导出来的数字就是错的。这要是直接交出去，后果不堪设想。

这时候，我又把问题丢给了 Codex，开始了一轮又一轮的对比、核对、修正：

• 客户确认哪条规则是对的
• 我把规则原话反馈给 Codex
• Codex 对照真实字段，一条条修正取数逻辑
• 再核一遍，确认口径终于对上了

现场记录 4：和客户核对字段口径后，Codex 修正取数逻辑并固化为可复用 SQL

修正之后，Codex 顺手把这份查证过的逻辑固化成了一份可复用的 SQL（我们管它叫”已核验口径”的版本），以后这套 HIS 再要导医保数据，直接拿来用就行，不用再从头捋一遍。

这个环节，让我对”AI 能不能真扛事”又有了更深一层的认识：AI 第一次写的可能不全对，但它最大的价值，是能陪你在一轮轮的对比里，把错误一点点揪出来、修干净，最后固化成一个经得起核查的结论。

会写 SQL 的 AI 不稀奇；肯陪你把口径反复磨对、还能把正确结果固化下来的 AI，才是真的能交付。

真正要掌握的，不是 SQL，而是”闭环”

回看整个过程，最难的部分，其实不是导出 CSV，而是先把一个失去维护的服务器和数据库环境，重新变成可用的生产能力。

我到底做了什么？说穿了很朴素：

• 说明真实的业务目标
• 提供现场看到的界面和报错
• 按步骤执行
• 指出参考脚本
• 确认机构名称
• 核对医生名单
• 查看结果摘要
• 和客户核对口径，反馈修正意见

而 AI 做的，是把这些信息翻译成：环境排查、数据字典检索、表关系判断、SQL 条件、文件导出、结果校验，以及取数逻辑的反复修正与固化。

这条完整链路里，分工很清楚：豆包负责解决前半段最难的”连接”问题——没有公网 IP、没有客户端、不知道端口和账号密码，把数据库从”连不上”变成”连得上”；Codex 接手后半段的数据库连接复核、表结构分析、SQL 复用、数据导出，以及和客户反复核对口径后修正取数逻辑、固化为可复用 SQL。而我，始终负责说明真实业务目标、核对条件和确认交付结果。

这种协作的核心，不是”让 AI 自己干活”，而是建立一个可验证的闭环：

1 先做最小验证，不要一上来就执行大动作

先连网络、再验账号、最后才碰业务表

2 先读说明和元数据，再决定查哪张表

先看数据字典，而不是盲目 select *

3 把业务口径写成明确条件，而不是依赖模糊理解

每一条规则都写清楚、可审计

4 每次查询后都做数量、唯一性、时间范围检查

交付前先做一轮数据体检

5 涉及敏感数据时，坚持最小权限和脱敏交付

身份证号、账号密码、生产库，绝不马虎

为什么你感觉不到 AI 的强大？

故事讲完了。现在我想认真聊聊这个问题。

我见过太多人，试了几天 AI 就说”也就那样”，然后把它扔在一边。他们的问题，往往不是 AI 不行，而是从来没让 AI 处理过一件真正棘手的事。

你让 AI 帮你写一篇周报、生成一张图片、翻译一段文字——这些都是”低难度任务”，AI 做得好是应该的，做不好你会觉得它蠢。所以你的体验是：平淡。

但你有没有试过，把一件你心里完全没底、甚至想放弃的事，丢给它？

• 一台被注销、不知道还能不能进去的服务器
• 一个陌生数据库，连表在哪都不知道
• 一个时间紧迫、出错要担责的合规任务

当任务难度足够高、不确定性足够大、后果足够严重时，AI 的价值才会被真正逼出来。

不是 AI 不够强，是你还没让它上过”真正的战场”。或者换句话：你根本就不会用 AI。

什么叫”会用 AI”？不是会提问、会写 prompt，而是知道：

• 在什么环节让 AI 接手
• 给它什么样的上下文和约束
• 如何把它的输出接回现实，验证、纠错、闭环

这次的经验，正好印证了我一直在专栏里讲的一个观点：AI 时代最值钱的能力，不是”让 AI 替你干活”，而是”你如何定义问题、拆分任务、验证结果、对交付负责”。

换句话说，AI 不是替你”装懂”，而是帮你把一个个未知问题，拆小、拆可解、拆成能一步步推进的动作。

这次，我没亲手做过服务器恢复，没亲手摸过这套 HIS 数据库——但我把事情做成了。因为我会用 AI，把它变成了一支能陪我上战场的团队。

没花钱，我拥有了一个超级团队

复盘到这儿，我想给你一个更直观的比喻。

第一阶段，豆包就像我请来的一个远程顾问——不慌不忙、经验丰富，陪着我在这台又旧又陌生的服务器面前，一个报错一个报错地排查。它考我的，是耐心：愿不愿意把问题说清楚、把现场反馈给它、一步步跟着它试。

第二阶段，Codex 就像我请来的一个技术专家——接手之后，稳准狠地搞定数据字典、表关系、SQL 逻辑和数据导出。它考我的，是技术：能不能把业务口径说清楚，让它在正确的逻辑下把数据查对、导对。

一个远程顾问，一个技术专家，就这么被我”组队”了。

关键在哪？没花一分钱。我却在一夜之间，拥有了过去只有大公司才养得起的”超级团队顶级能力”。

还有一个数据，我想单独拎出来说——

这一整件事，从服务器找不回来、直连数据库，到理清表结构、写对 SQL、导出两家机构的数据，主体工作，发生在一个晚上，两个小时内。

而在动手之前，我心里想的还是：这一整天，都未必能把它搞定。

结果呢？两个小时，搞定。

今天再核对，又发现取数逻辑有几处对不上，Codex 又陪着我多轮对比、修正、固化——但这一次，已经没有当初那种”心里没底”的慌了，因为我知道，只要把问题说清楚，它能陪我把坑一个个填平。

这就是用好 AI 的生产力——不是把一件一整天的工作，压缩成十个小时；而是把一件你原本以为”一整天都未必能做成”的事，直接做成、做完、做对，连后续的核查修正，都变得踏实。

同样一件事：过去靠堆人力，现在靠调度 AI；过去靠撞运气，现在靠对的方法。差别，就在”会不会用”这三个字上。

这就是我一直说的——AI 超级个体（OPC，One Person Company）。

一个人，不用招人、不用养团队、不用付高薪，只要懂得如何定义问题、如何调度 AI、如何对结果负责，就能撬动一支过去根本无法企及的”虚拟军团”，去完成过去一个人根本扛不下来的事。

这场医保飞检，就是一个小小的、真实的缩影：一个被注销的服务器、一个陌生数据库、一个紧迫到不行的合规任务——我一个人，加上两个 AI，把它做成了。

这就是 AI 超级个体的样子。