第一次把AI带进真实工作：金融IT工程师的试潜

第一次使用AI，并不是第一次把问题输入聊天窗口。

真正的第一次，是我准备把它给出的结果，用到一项真实工作里。

那一刻，问题发生了变化。

在个人测试里，一个错误答案最多浪费几分钟；在金融机构的信息技术工作中，一个未经验证的判断，可能沿着脚本、配置和操作流程继续向下传递。

我突然意识到：从这一刻开始，我面对的不再是一个会聊天的新工具，而是一名速度很快、知识面很广，却不知道自己什么时候犯错的临时协作者。

那次任务并不惊险。没有核心交易故障，也没有生产系统中断，只是一组来自隔离测试环境的应用日志。某个服务间歇性超时，需要从大量记录中寻找共同特征，整理可能原因，并生成一个统计异常分布的小脚本。

这是一个足够真实、又足够低风险的起点。

像第一次进入陌生海域，我没有直接下到深处，而是选择了一次可以随时返回水面的试潜。

为避免披露真实系统和工作信息，本文将几次相近的实践整合为一次记录；涉及的系统名称、日志字段、参数和时间均已脱敏或重构，不对应任何具体生产事件。

一、下水前，我先给任务划了一条线

在把第一段材料交给AI之前，我花的时间比预想中更长。

我没有急着研究提示词，而是先问自己：哪些信息可以出现，哪些信息绝不能离开原有边界？

客户身份信息、账户与交易数据、生产环境地址、账号、密钥、访问令牌、完整系统拓扑、未公开的业务规则——这些内容全部被排除。

我只保留分析任务真正需要的部分：经过重命名的服务节点、错误时间、错误类型、响应耗时，以及少量能够说明调用关系的上下文。部分样例数据不是从原始日志直接截取，而是按照同样结构重新构造。

这一过程看起来有些保守，却让我第一次理解：使用AI的安全起点，不在聊天窗口，而在聊天窗口之外。

数据一旦越过边界，再补救已经太晚。

潜水员不会到了水下才检查气瓶、调节器和配重。数据脱敏也不应该等到内容已经发送之后才开始。

我为这次试潜定下三条最初的限制：

• 只使用脱敏或构造的数据；
• 不让AI连接任何真实系统；
• 所有结论只作为排查假设，不作为操作依据。

现在回头看，这三条限制并不复杂。但正是它们，让后面的尝试始终留在了一个可控范围内。

二、第一次下潜，它比我预想得更快

我先让AI解释日志结构，并从重复出现的异常中寻找模式。

它很快归纳出几处值得注意的特征：超时集中在同一类调用链路中，发生前往往伴随着连接等待时间上升，某些错误还会在相近时间窗口内成组出现。

这些观察并不等于根因，却把一片杂乱的日志变成了几个可以继续验证的方向。

接着，我让它生成一段统计脚本，把日志按照时间区间、错误类型和服务节点进行汇总。

第一版脚本并不完美，但框架已经具备：读取文件、解析字段、过滤异常、计算分布、输出结果。过去需要我一边查资料一边拼接的过程，被压缩成了一次连续对话。

我修改字段格式，补充边界条件，又让它加入异常行处理和结果校验。几轮之后，一个可用的原型出现了。

那一刻，我第一次清晰感受到，AI带来的变化不只是“少写几行代码”。

它缩短了从原始信息到形成假设之间的距离，也降低了把临时想法变成验证工具的成本。

但是，我没有把它给出的内容称为答案。

它更像一束强光，迅速照亮了海底的一片区域。光照到的地方值得观察，却不代表阴影已经消失，更不代表前方没有暗流。

三、最像正确答案的时候，风险出现了

真正让我警惕的，不是AI写错了一行代码，而是它给出了一段非常完整的错误判断。

在分析一组超时记录时，它认为问题与某项连接参数有关，并建议调整参数后重新加载服务。

这个答案看起来十分专业。

它解释了参数的作用，描述了可能的因果关系，列出了修改方式，甚至补充了验证步骤。如果只看表达，几乎没有明显破绽。

但当我回到官方文档和实际配置中逐项核对时，发现它提到的参数属于另一个组件版本。在我们构造的目标环境里，这个配置项根本不存在。

更值得注意的是，AI没有表现出犹豫。它没有提醒我“版本可能不同”，也没有主动要求补充环境信息，而是把缺失的部分填成了一个逻辑顺畅的故事。

最危险的地方不是它错了，而是它错得非常像对的。

如果那是一段普通说明文字，错误也许只会带来理解偏差；如果它被继续写入操作方案，甚至进入自动执行流程，风险就会被一层层放大。

那次经历让我形成了一个到现在仍然保留的判断：

从那以后，我开始主动要求它说明假设、列出不确定项、给出需要核验的来源，并把“听起来合理”和“已经验证”严格分开。

AI可以帮助我更快地产生假设，但证据链必须由人重新建立。

四、我没有让AI直接触碰任何系统

随着使用深入，一个很自然的诱惑出现了：既然AI能够分析日志、生成脚本，能不能让它直接执行？

技术上，这件事并不神秘。给模型配置工具、权限和接口，它就可以读取文件、调用系统、修改内容，甚至连续完成多个步骤。

但在金融信息技术环境里，“能够执行”与“应该执行”之间有很长的距离。

模型不了解完整的业务影响，不承担操作责任，也无法自动继承现有的审批、复核和审计要求。如果权限过大，一个错误判断就可能从文字答案变成真实动作。

因此，这次试潜始终遵循一条明确流程：

原始材料由人工脱敏，AI负责分析与生成；输出由人工复核，脚本在本地隔离环境测试；结果与原始材料比对，真正的系统操作仍然遵循既有的授权、审批与变更流程。

AI可以生成命令，但不能替我按下回车键。

AI可以提出配置建议，但不能接触生产配置。

AI可以归纳故障方向，却不能跳过测试、复核、审批和回退准备。

这并不是拒绝自动化，而是在自动化之前先设计刹车、深度限制和上升路线。

潜水时，我可以根据海图规划方向，却不能把气量检查、浮力控制和上升决策全部交给一张海图。AI也一样：它可以参与判断，但不能取代责任。

五、第一次试潜留下的五条安全线

任务结束后，我把这次过程重新梳理了一遍，形成了五条简单但实用的安全线。

第一条是数据脱敏。

不把不能公开的信息直接交给模型。必要时只保留结构，使用重新构造的样例数据代替真实内容。脱敏不是最后一道检查，而是所有AI任务的入口。

第二条是权限最小化。

AI只获得完成当前任务所必需的信息与工具。能只读就不写入，能在测试环境完成就不连接生产，能由人执行就不提前授予自动操作权限。

第三条是人工确认。

涉及命令执行、文件修改、系统配置、权限变化和外部发布的动作，必须由人明确确认。越接近真实业务，确认点就越不能被省略。

第四条是结果验证。

代码要运行测试，结论要核对原始材料，引用要回到可信来源，命令要确认作用范围、依赖条件和回退方式。AI输出的完整程度，不能代替验证强度。

第五条是过程留痕。

记录任务目的、输入范围、模型输出、人工修改和验证结果。只有留下过程，才能在出现偏差时知道问题发生在哪一步，也才能逐渐认识AI在哪些场景可靠、在哪些场景容易犯错。

我还把AI输出分成三个等级：

• 可以直接作为启发和参考的信息；
• 必须经过独立验证的分析与代码；
• 绝不能未经确认执行的操作。

这套分类没有复杂的模型，也没有宏大的名称，却让我第一次真正建立起“与AI协作”而不是“向AI提问”的工作方式。

六、回到水面，我重新理解了效率

那次任务结束后，AI没有替我解决所有问题。

它读了日志，生成了脚本，提出了几个值得验证的方向，也给出了一个十分可信的错误判断。

最终完成排查的，仍然是技术文档、测试结果、系统上下文和人的专业判断。

但我的工作方式确实发生了变化。

过去，我常常需要独自在日志、代码、技术论坛和文档之间来回切换；现在，我身边多了一名速度很快的临时协作者。它不会疲倦，也不怕重复，可以快速帮助我整理信息、形成原型和暴露思路中的空白。

与此同时，我也承担了新的工作：定义边界、检查输入、验证输出、控制权限，并对最终行动负责。

所以，AI带来的效率并不是简单地“把人从流程中删除”。

真正有价值的效率，是让机器承担更多机械整理，让工程师把时间集中在定义问题、判断证据和控制风险上。

第一次试潜没有让我相信AI无所不能。

它让我学会了另一件更重要的事：怎样在不放弃责任的前提下，让一个不完全可靠的智能系统参与真实工作。

潜水结束后，潜水员会记录深度、时间、气量和遇到的问题。对我来说，这篇文章就是那次试潜的日志。

我看见了新的风景，也遇到了第一股暗流。

下一次下潜，我想把视线从一项具体任务移向更广阔的金融领域：当越来越多的AI从“回答问题”走向“执行任务”，它们会改变哪些业务，又会带来哪些新的风险？

—— Recall_li

PREVIOUS DIVE · 回看第一篇《AI时代来了：一个金融机构IT工程师的水面之上与水面之下》