企业官网建设流程全解析

一、引言

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 Store（src/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.get<PaginatedResponse<ComplianceRecord>>('/api/compliance/list',{params});exportconstgetComplianceDetail=(id:string)=>request.get<ComplianceRecord>(`/api/compliance/${id}`);exportconstsubmitComplianceReview=(data:Partial<ComplianceRecord>)=>request.post<void>('/api/compliance/review',data);

// src/stores/compliance.ts —— AI 生成，我补充了业务逻辑import{makeAutoObservable,runInAction}from'mobx';import{getComplianceList,getComplianceDetail}from'@/api/compliance';importtype{ComplianceRecord}from'@/types/compliance';classComplianceStore{list:ComplianceRecord[]=[];current:ComplianceRecord|null=null;loading=false;constructor(){makeAutoObservable(this);}asyncfetchList(params:ComplianceQuery){this.loading=true;try{constres=awaitgetComplianceList(params);runInAction(()=>{this.list=res.data.records;});}finally{runInAction(()=>{this.loading=false;});}}}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:ColumnsType<KnowledgeRecord>=[// ... 其他列{title:'操作',key:'action',render:(_,record)=>(<Space><Button onClick={()=>handleEdit(record.id)}>编辑</Button>{/* AI 的判断逻辑：只对 admin 显示删除按钮 */}{userStore.role==='admin'&&(<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 容易产生幻觉

第三问：我能不能把它写对？

这可能是最重要的一问。如果你自己都搞不清楚这段逻辑，AI 生成的代码你也没法判断对错。

我的原则很简单：AI 放大你的能力，但不替代你的判断。你强的地方，AI 让你更强；你模糊的地方，AI 让你更模糊。

五、我们的 AI 使用规范

基于以上踩坑经验，我们团队沉淀了几条硬规则。这些规则不追求"全面"，追求的是"可执行"：

规则 1：Prompt 脱敏检查（强制）

在粘贴任何内容到 AI 工具前，检查以下字段是否出现： □ customer_name / customer_id □ id_number / phone / email □ account_id / balance / position □ token / password / secret □ 生产环境日志 / 报错堆栈（除非已脱敏）

违反这条的生产事故，按信息安全制度处理。这不是小题大做——金融科技公司每年都有第三方工具数据泄露的案例。

规则 2：高风险代码禁用 AI（强制）

以下类型的代码，禁止 AI 直接生成逻辑（可以生成类型定义和测试）：

• 权限判断逻辑
• 金额/费率计算
• 状态机转换
• 数据脱敏/加密相关
• 合规审计相关

规则 3：AI 辅助代码必须标记（建议）

在 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 个月真实体验。如果你也在类似行业做技术转型，欢迎交流。