我在金融科技公司用 AI 辅助开发的得与失：一个 3 年前端开发者的边界感思考

一、引言2024 年初公司内部开始试点 AI 辅助编程工具。作为 KMS 知识管理平台的前端负责人我是第一批体验者。半年过去了我想用一个数据开场在我经手的 200 个 commit 中AI 直接生成的代码约占 25%但最终合并到主分支的 AI 代码只有其中 60%。剩下 40% 去哪了有的是被 Code Review 打回来的有的是我事后重构掉的还有一小部分是差点上线的安全隐患。金融科技行业的特殊性在于这里的容错率比其他行业低一个数量级。你写的代码可能涉及客户的持仓数据、交易流水、合规审计。在这个前提下AI 辅助开发不是用不用的问题而是怎么用、什么时候用、什么时候必须不用的问题。这篇文章是我半年来的真实体验——不吹不黑既有提效的甜头也有踩坑的教训。希望能给同在传统行业做技术转型的读者一点参考。二、得三个真实提效场景场景一boilerplate 代码生成——从半小时到 5 分钟KMS 是 Lerna Monorepo 架构包含 Web、Dashboard、H5 三个子包。每新增一个业务模块需要创建API 接口层src/api/MobX Storesrc/stores/页面组件src/pages/路由配置src/routes/类型定义src/types/这些文件的骨架高度模板化。以新建一个合规审查模块为例// src/api/compliance.ts —— AI 生成我只改了接口路径importrequestfrom/utils/request;importtype{ComplianceRecord,ComplianceQuery}from/types/compliance;exportconstgetComplianceList(params:ComplianceQuery)request.getPaginatedResponseComplianceRecord(/api/compliance/list,{params});exportconstgetComplianceDetail(id:string)request.getComplianceRecord(/api/compliance/${id});exportconstsubmitComplianceReview(data:PartialComplianceRecord)request.postvoid(/api/compliance/review,data);// src/stores/compliance.ts —— AI 生成我补充了业务逻辑import{makeAutoObservable,runInAction}frommobx;import{getComplianceList,getComplianceDetail}from/api/compliance;importtype{ComplianceRecord}from/types/compliance;classComplianceStore{list:ComplianceRecord[][];current:ComplianceRecord|nullnull;loadingfalse;constructor(){makeAutoObservable(this);}asyncfetchList(params:ComplianceQuery){this.loadingtrue;try{constresawaitgetComplianceList(params);runInAction((){this.listres.data.records;});}finally{runInAction((){this.loadingfalse;});}}}exportdefaultnewComplianceStore();提效量化以前手动搭这些骨架需要 25-30 分钟现在 AI 生成 人工调整约 5 分钟。对于每月 3-5 个新模块的节奏累计节省的时间非常可观。场景二单元测试补全——最省心的场景这是我觉得 AI 辅助开发最安全、最成熟的应用场景。单元测试的特点是输入输出明确边界条件可枚举出错不会影响线上以 MobX Store 的单元测试为例// AI 生成 complianceStore 的测试用例覆盖率达到 92%describe(ComplianceStore,(){beforeEach((){complianceStore.reset();});it(fetchList should update list on success,async(){constmockData{data:{records:[{id:1,name:合规审查-001,status:pending},{id:2,name:合规审查-002,status:approved},],},};jest.spyOn(api,getComplianceList).mockResolvedValue(mockData);awaitcomplianceStore.fetchList({page:1,pageSize:10});expect(complianceStore.list).toHaveLength(2);expect(complianceStore.loading).toBe(false);});it(fetchList should keep loading false on error,async(){jest.spyOn(api,getComplianceList).mockRejectedValue(newError(Network Error));awaitcomplianceStore.fetchList({page:1,pageSize:10});expect(complianceStore.list).toHaveLength(0);expect(complianceStore.loading).toBe(false);});});AI 在这里的优势是它能自动识别 MobX Store 的方法签名补全 mock 数据结构和异常分支。我只需要核对断言逻辑是否合理。场景三TypeScript 类型体操——减少心智负担KMS 项目中有一个典型的类型场景API 返回的数据结构需要经过多层转换才能在组件中使用。手动维护这些类型定义又累又容易出错。// 后端返回的原始类型字段名为 snake_case含冗余字段interfaceApiKnowledgeBase{id:string;kb_name:string;kb_type:number;created_at:string;updated_at:string;creator_info:{user_id:string;user_name:string};permission_config:string;// JSON string}// 前端使用的类型camelCase解析后的结构interfaceFrontendKnowledgeBase{id:string;kbName:string;kbType:KnowledgeBaseType;// enumcreatedAt:Date;updatedAt:Date;creatorName:string;permissions:PermissionConfig[];// 解析后的数组}AI 能一步到位生成转换函数包括snake_case→camelCase的映射和 JSON 字段解析。这种场景人力去做大概 15 分钟AI 10 秒人工校验 2 分钟。这三个场景的共同特点是代码结构化、逻辑确定性高、出错后果可控。这也是我使用 AI 的安全区。三、失三个踩过的坑坑一敏感数据误入 Prompt —— 最接近事故的一次有一次我需要写一段数据脱敏的工具函数顺手把一段生产日志贴进 prompt 让 AI 帮我分析规律。那段日志里混着一条未脱敏的客户姓名。虽然我立刻删掉了但在金融科技行业把任何生产数据贴进第三方 AI 工具本身就是合规红线。即使代码在本地运行即使 “只是日志”即使 “只有一条”。教训永远用脱敏后的 mock 数据与 AI 交互。我们在团队规范里明确写了这一条——任何包含customer_name、id_number、phone、account_id等字段的真实数据禁止出现在 prompt 中。坑二看起来对的代码 —— AI 的自信幻觉有一次我让 AI 帮我写一个 Ant Design Table 的列配置其中一列需要根据权限动态渲染操作按钮// AI 生成的代码 —— 看起来对但实际有问题constcolumns:ColumnsTypeKnowledgeRecord[// ... 其他列{title:操作,key:action,render:(_,record)(SpaceButton onClick{()handleEdit(record.id)}编辑/Button{/* AI 的判断逻辑只对 admin 显示删除按钮 */}{userStore.roleadmin(Button danger onClick{()handleDelete(record.id)}删除/Button)}/Space),},];问题在于userStore.role是一个 MobX observable这里的判断方式是同步的、前端层面的。而 KMS 的权限模型是 RBAC 资源级权限——即使用户是 admin也不一定有删除这条特定知识条目的权限。AI 的盲区它不了解 KMS 的权限体系设计只看当前文件的上下文给出了看起来合理但实际上绕过了后端权限校验的代码。教训涉及权限、金额、状态机、数据校验的代码AI 生成的必须逐行审查。这些是不能错的代码。坑三过度依赖导致的代码理解退化使用 AI 辅助开发的第三个月我发现一个危险的趋势当我遇到一个不熟悉的模块时第一反应变成了贴给 AI 让它解释而不是打开源码自己读一遍。有一次 Code Review同事问我你这段逻辑为什么用useMemo而不是useCallback我愣住了——因为这是 AI 建议的我没有深究原因。这不是 AI 的问题是我的问题。工具越强越容易让人跳过自己理解这一步。但写代码的本质不是把需求翻译成代码而是理解问题并设计解决方案。如果这个核心能力退化有了 AI 反而会写出更差的软件。教训我给自己定了一条规矩——凡是 AI 生成的代码我能讲清楚每一行为什么这样写才能提交。讲不清楚的要么搞懂要么重写。四、边界感一个决策框架经过半年的摸索我总结了一套能不能用 AI的判断框架。这不是什么权威理论只是我个人踩坑后的经验沉淀。这个框架的核心是三个问题按顺序问自己第一问这段代码错了的代价有多大风险等级典型场景AI 使用策略 高风险权限校验、金额计算、状态机、数据脱敏禁止 AI 直接生成逻辑只允许生成类型定义和接口骨架 中风险复杂业务逻辑、表单校验规则、API 参数构造AI 可生成初版必须逐行 Review 单元测试覆盖 低风险Boilerplate、单元测试、类型体操、UI 布局AI 直接生成人工验收即可第二问这段代码需要多少项目上下文项目上下文指的是业务规则、架构约定、历史遗留约束。上下文依赖低如工具函数、通用组件→ AI 表现好上下文依赖高如权限判断、业务状态机→ AI 容易产生幻觉第三问我能不能把它写对这可能是最重要的一问。如果你自己都搞不清楚这段逻辑AI 生成的代码你也没法判断对错。我的原则很简单AI 放大你的能力但不替代你的判断。你强的地方AI 让你更强你模糊的地方AI 让你更模糊。五、我们的 AI 使用规范基于以上踩坑经验我们团队沉淀了几条硬规则。这些规则不追求全面追求的是可执行规则 1Prompt 脱敏检查强制在粘贴任何内容到 AI 工具前检查以下字段是否出现 □ customer_name / customer_id □ id_number / phone / email □ account_id / balance / position □ token / password / secret □ 生产环境日志 / 报错堆栈除非已脱敏违反这条的生产事故按信息安全制度处理。这不是小题大做——金融科技公司每年都有第三方工具数据泄露的案例。规则 2高风险代码禁用 AI强制以下类型的代码禁止 AI 直接生成逻辑可以生成类型定义和测试权限判断逻辑金额/费率计算状态机转换数据脱敏/加密相关合规审计相关规则 3AI 辅助代码必须标记建议在 commit message 或 PR 描述中标注 AI 辅助的部分方便 Reviewer 重点审查feat(compliance): add compliance review module AI-assisted: API layer boilerplate, type definitions Manual: permission logic, store actions, validation rules规则 4生成→理解→提交建议每段 AI 生成的代码提交前问自己这段代码的每一行我都能解释清楚吗如果这段代码出 bug我知道从哪里排查吗答不上来就回去看源码搞懂了再提交。六、总结回到开头的数据AI 直接生成的代码占 25%最终合入主分支的只有其中 60%。这 60% 不是 AI 的能力上限而是在我的判断框架下AI 真正适合做的部分。剩下 40% 不是 AI “写错了”而是不该让 AI 写。我的核心观点其实很简单AI 辅助开发的价值不在于替你写代码而在于替你省下脑容量。把省下来的时间和精力投入到更需要深度思考的事情上——理解业务、设计架构、做出更好的技术决策。在金融科技这个容错率极低的行业这个边界感尤为重要。你可以踩着 AI 的肩膀看得更远但脚必须踩在自己确认过的地方。这篇文章来自我在金融科技公司使用 AI 辅助开发的 6 个月真实体验。如果你也在类似行业做技术转型欢迎交流。