上个月，我们迎来了一件所有人都头皮发麻的事。
等保三级复测，整改清单里有一条：
全系统敏感数据落地加密，包括但不限于：手机号、身份证号、银行卡号、家庭住址。
我当时看到这条，脑子里只有一个念头：
这活儿，至少要一个月。
背景：这件事为什么难
先说清楚规模。
我们有大大小小数十个业务系统 ，分布式架构，涉及的数据库有十几个 ，表的数量加起来上百张。
代码库也是十几个独立仓库，分散在不同的项目里。
难点不是加密算法本身，AES-256，成熟方案，闭眼都能写。
难点在于：
第一，光是摸清楚"要改哪些"就是个大工程。
上百张表，不是每张表都有敏感字段。但你不一张一张看，你不知道哪张有哪张没有。十几个代码仓库，不是每个项目都涉及敏感数据。但你不逐个扫，你不知道漏了哪里。
这个"排查"本身，就够让人崩溃的。
第二，存量数据。
涉及敏感字段的那些表，里面已经有几百万条明文数据。新数据加密容易，老数据怎么迁移？迁移期间服务能停吗？不能停，那怎么保证新老格式兼容？
第三，系统之间耦合。
数十个系统，部分共用同一套用户数据。A系统改了加密逻辑，B系统的查询会不会受影响？谁先改，谁后改，顺序错了就是线上故障。
第四，改动量巨大。
敏感字段散落在十几个数据库、上百张表里，涉及数十个系统的几十个Service、上百个接口。每个字段的读写逻辑都要改，改完还要回归测试。
第五，工期死死的。
复测时间定了，不能推。
Leader开完会回来，把任务分给了我们仨：我，老赵，小林。
三个人，七天。
老赵直接说了一句："搞不定。"
第一天上午：最难的一步------先摸清楚要改哪些
以前遇到这种活儿，第一天肯定是分工然后各自开干。
这次我们改了策略，第一天上午一行代码没写，全用来做一件事：
把所有需要改的东西找出来。
这件事如果靠人工，三个人每人扫几个系统，互相还可能有遗漏，光这一步就要两三天。
我们的做法是：用AI批量扫描，人来判断确认。
步骤一：数据库层面，扫描所有表的字段名。
写了一个脚本，连接十几个数据库，把所有表的字段名全部导出来，然后让Claude做语义识别：
以下是我们所有数据库的表字段清单，请识别出可能包含敏感信息的字段，
敏感信息包括：手机号、身份证号、银行卡号、姓名、地址、邮箱、IP地址等。
请按照"数据库名.表名.字段名"的格式列出，并标注敏感类型。
[粘贴字段清单]半小时后，得到了一张完整的疑似敏感字段清单。
我们三个人对着清单逐条确认：哪些确实是敏感字段，哪些是误判（比如有个字段叫 user_card_type，存的是会员卡类型，不是银行卡号）。
最终确认：涉及敏感字段的表，共87张，字段共计143个。
这个数字，比我们预估的多了不少。如果靠人工逐张表翻，肯定会漏。
步骤二：代码层面，扫描十几个代码仓库。
这一步更复杂。
有了字段清单，我们需要知道每个字段在代码里被哪些地方读写------这才是真正要改的地方。
用Cursor逐个仓库做全局搜索，搜索维度有三个：字段名（如phone、id_card、bank_no）、实体类名、以及WHERE条件里用了敏感字段的SQL。
每扫一个仓库，让AI把结果归类：
类型A：写入时需加密（INSERT/UPDATE场景）
类型B：读取时需解密（SELECT后处理）
类型C：查询条件中使用（WHERE phone = ?）→ 需要特殊处理
类型D：日志打印中出现 → 需要脱敏
类型E：接口返回值中直接透传 → 需要脱敏或加密传输类型C是最麻烦的。
加密之后，WHERE phone = '138xxxx' 就没法用了------数据库里存的是密文，你不能用明文去比对。
这个问题，我们第一天就想清楚了：对用于查询的敏感字段，要额外维护一个确定性加密索引（同样的明文始终加密成同样的密文），用于查询；存储字段用随机IV的AES，保证安全性。
步骤三：汇总成改造清单，按系统分工。
扫完所有仓库之后，我们得到了一张完整的改造清单，标注了每个系统涉及哪些数据库、哪些表、哪些字段、哪些仓库需要改。
到这里，"要改哪些"终于清楚了。
整个摸排过程，花了一天。
如果靠纯人工，保守估计要三到四天，而且不敢保证没有遗漏。
第一天下午：把改造方案定下来
摸排清楚之后，下午用来做方案设计。
核心决策只有一个，但这个决策决定了后面所有的效率：
不在每个Service里手动加解密。
如果那样做，143个字段，散在数十个系统、几十个Service里，要改几百处。改一个漏一个，上线必出事，而且回头review也是噩梦。
我们选的方案是：在MyBatis层做统一拦截，注解驱动，业务层完全无感知。
写入时自动加密，读出时自动解密，业务代码唯一需要动的，就是在实体类字段上加一个注解：
java
@SensitiveField(type = EncryptType.RANDOM)
private String phone;这个决策，是整个方案里最重要的一步。
前期多花一天搭基础设施，后面143个字段的改造成本，会低到难以置信。
把改造分成三个阶段，定好顺序：
阶段一：基础设施搭建（加密工具类 + MyBatis拦截器 + 配置）
阶段二：字段改造（按系统，逐张表逐个字段）
阶段三：存量数据迁移（分批，灰度，可回滚）顺序想清楚，才能三个人并行，不互相踩。
这一天，老赵还是觉得来不及。
我说先干，干了再说。
第二天：基础设施，Cursor一天搭完
阶段一的活，我来做。
核心是三个东西：
1. 加密工具类
给Cursor的Prompt：
帮我实现一个AES-256加密工具类，要求：
1. 支持两种模式：
- 随机IV模式（用于存储，安全性高，同明文每次密文不同）
- 确定性模式（用于查询索引，同明文始终同密文）
2. 密钥从配置中心读取，支持密钥轮换（同时支持新旧两个密钥解密）
3. 加密结果Base64编码，方便数据库存储
4. 加密结果加固定前缀标识（用于迁移期间区分明文和密文）
5. 所有异常封装成业务异常，不能把加密细节暴露给上层
6. 技术栈：Java 17 + Spring Boot 320分钟，Cursor生成了完整实现，我review了一遍，改了两处：一处是密钥轮换的优先级顺序，一处是异常日志不能打印原始数据。
2. MyBatis拦截器
给Cursor的Prompt：
帮我实现一个MyBatis拦截器，拦截INSERT/UPDATE操作时自动加密指定字段，
拦截SELECT结果时自动解密指定字段。
字段标识方式：在实体类字段上加自定义注解 @SensitiveField(type = EncryptType.RANDOM)
要求：
1. 注解驱动，新增加密字段只需加注解，不需要改业务代码
2. 查询索引字段用 @SensitiveField(type = EncryptType.DETERMINISTIC)
3. 迁移兼容：读取时判断是否有加密前缀，没有则直接返回明文（兼容期）
4. 拦截器要处理MyBatis-Plus的分页查询结果
5. 性能敏感，避免反射开销，使用缓存这个Cursor生成完，我花了半天review，重点看了两个地方：
- 反射缓存的并发安全性（用了ConcurrentHashMap，没问题）
- 分页结果的解密是否遗漏（测了几个边界case，补了一个）
3. 配置和注解定义
这个简单，Cursor 10分钟搞定。
下午三点，基础设施全部完成，单元测试覆盖率83%。
老赵发来消息："这拦截器真的行？"
我说："你加个注解试试。"
他在测试库的实体类加了一个 @SensitiveField，跑了一下：数据库写进去是密文，读出来是明文，查询正常，分页正常。
他回了两个字："牛逼。"
第三天到第五天：数十个系统并行改造
基础设施就位之后，三个人开始按系统并行。
老赵负责一批系统，小林负责一批，我负责剩下的，同时做协调和review。
每个字段的改造标准流程：
1. 在实体类字段上加 @SensitiveField 注解（1分钟/字段）
2. 检查该字段是否用于WHERE查询条件
→ 如果是，同步处理查询索引字段
3. 检查日志打印是否包含该字段
→ 如果是，添加脱敏处理
4. 检查接口返回值是否直接透传该字段
→ 如果是，确认是否需要脱敏
5. 跑单元测试
6. 跑集成测试（含存量数据兼容性验证）Cursor在这里帮了大忙------不是生成复杂逻辑，而是批量处理高度重复的工作。
第一天排查时已经有了改造清单，每个实体类需要加哪些注解，一清二楚。我把实体类喂给Cursor，让它按清单加注解，处理边界情况，然后我来review。
单个实体类平均用时从之前估计的30分钟压到了8分钟。
143个字段，三个人并行，三天全部改完，集成测试全部通过。
中间踩的一个坑：
有个老系统的接口，手机号直接拼进了SQL字符串（是的，还有这种代码）：
java
String sql = "SELECT * FROM user WHERE phone = '" + phone + "'";这种情况拦截器拦不到。
小林发现之后，让Cursor帮她在该系统的所有仓库里搜类似的写法，找到了 5 处，全部改成了参数化查询，同时加上了查询时的加密转换。
这 5 处如果靠人工在多个仓库里逐文件找，可能真的会漏。
第六天：存量数据迁移------最危险的一步
前五天相对顺利，第六天是真正的硬骨头。
几百万条存量明文数据，散在十几个数据库里，要在服务不停机的情况下全部迁移成密文。
迁移策略我们想了很久，最终选了双读兼容 + 分批迁移：
迁移期间的读取逻辑（拦截器里已内置）：
1. 读出数据
2. 判断是否有加密前缀
3. 有前缀 → 解密返回
4. 无前缀 → 直接返回原始明文（兼容明文存量数据）
迁移脚本：
- 按数据库逐个跑，互不干扰
- 每次迁移 1000 条
- 间隔 500ms（控制数据库压力）
- 每批迁移完做校验（解密后和原文比对）
- 支持断点续跑
- 出错自动暂停，等人工介入迁移脚本的核心逻辑让Cursor生成，但迁移策略是我们自己设计的。
这里有一个细节很关键：迁移脚本要先在测试库完整跑一遍，验证数据一致性，再上生产。
测试库跑完，解密校验零错误。
生产库按数据库分批，选在凌晨流量低谷执行，全程监控，没有任何异常。
早上六点，所有数据库迁移完成。
第七天：回归、收尾、提交整改报告
最后一天做了三件事：
全量回归测试，所有涉及敏感字段的接口，全部过了一遍。
日志审查，确认没有任何接口还在日志里打印明文敏感数据。
整改报告，把加密方案、改动范围、测试结果整理成文档，提交给合规团队。
复测当天，审计方对数据库做了抽查：所有敏感字段，全部密文存储，查询正常，接口响应正常。
一周，过了。
复盘：AI做了什么，没做什么
做完之后，我认真想了一下，如果没有Cursor，这件事会怎么进行。
没有AI的情况：
十几个数据库、上百张表的字段排查：至少3天，而且不敢保证不漏。
十几个代码仓库的敏感字段使用位置扫描：至少2天。
基础设施搭建：至少2天。
143个字段改造，三人并行，每个字段平均30分钟：合计约24小时，3天。
迁移脚本开发和调试：1-2天。
总计：11-12天以上，还没算回归测试的时间。
一周根本不够，结论是改不完。
有了AI的情况：
摸排1天，基础设施1天，字段改造3天，迁移1天，回归1天，刚好7天。
AI提速的不是思考，是执行。
加密工具类怎么设计密钥轮换，拦截器要不要缓存反射结果，迁移策略用双读还是停写，系统之间的改造顺序------这些判断是我们自己做的，不是AI做的。
AI做的是：把这些判断落成代码的速度，快了3-4倍。
还有一件事同样重要：
AI帮我们减少了遗漏。
十几个数据库、上百张表、143个字段，分散在十几个代码仓库里，靠人眼逐个扫，无论如何不敢说一个不漏。AI批量扫描加语义识别，找出了那5处手拼SQL，找出了日志里打印的敏感字段，找出了接口返回值里直接透传的字段------这些散落在各个角落的问题，人工找起来成本极高，而且容易漏。
写在最后
等保整改，大部分公司都经历过或即将经历。
敏感数据加密，是里面看起来清晰、实际最繁琐的一项。
如果你也面对类似的事，我的建议是两条：
第一，先摸清楚要改哪些，再开始动手。
上百张表、十几个仓库，不先摸清楚，开干之后必然遗漏，漏了再补比从头来还痛苦。用AI批量扫，比人工快3倍以上，而且更准。
第二，把加解密收拢到一处，不要分散在业务代码里。
拦截器统一处理的方案，前期搭建成本高一天，但后面每个字段的改造成本极低，总体效率反而高很多。143个字段如果分散手写，改漏的返工成本会让你崩溃。
AI可以帮你快速执行，但你得先把架子搭对。
架子搭对了，后面的事AI能帮你快3-4倍。
架子搭错了，AI帮你更快地走向错误的方向。
你们公司做过等保整改吗？有没有踩过类似的坑？欢迎评论区聊聊。
后端AI实验室 不讲概念，只谈实战 代码开源，每周更新