用 Claude AI 构建银行 KYC 文档管理模块实战

从模拟数据到真实业务：KYC 模块实战

在企业级贷款应用的开发系列中，KYC（Know Your Customer，客户身份识别）文档管理是绕不开的核心模块。本文记录了一位开发者如何借助 Claude AI，将原本只有模拟数据（mock data）展示的 KYC 页面，改造为一套能够与数据库实时交互的真实功能模块。

整个 KYC 模块覆盖了相当完整的证件类型：PAN 卡、护照、驾照、选民身份证（Voter ID）、GST 公司文件以及通用上传文件。开发目标明确——这些菜单不仅要能点开，还要像真实应用一样执行刷新、导出 Excel、更新证件号码、上传文档等操作，并且所有数据都要落库保存。

在改造之前，页面上的 PAN、Aadhaar 等信息都是写死的模拟数据，点击后只是静态展示。本次迭代的核心任务，就是把这套"花架子"变成能更新、能校验、能存储的生产级功能。

KYC（Know Your Customer）是金融监管领域的强制性合规要求，起源于反洗钱（AML）和反恐融资（CFT）法规框架。在印度，KYC 合规由印度储备银行（RBI）和证券交易委员会（SEBI）联合监管，贷款机构必须在放款前完成借款人的身份核实。PAN 卡（Permanent Account Number）是印度税务局颁发的唯一纳税识别号，Aadhaar 是印度政府的12位生物特征身份证号，两者都是信贷申请的必要材料。GST（Goods and Services Tax）公司文件则用于验证企业主体的合法注册状态。这套证件体系直接决定了 KYC 模块的数据结构设计——不同证件有不同的校验规则（如 PAN 的格式为 ABCDE1234F），这也是开发者选择"集中式文档表"而非为每类证件单独建表的重要原因之一。

两段式 Prompt：先审计，后实现

这个案例最值得借鉴的，是作者采用的两段式 Prompt 策略，而不是上来就让 AI 直接改代码。

第一段 Prompt 用于审计（Read-only Audit）。 作者在提示词中明确告知 Claude：这是一个企业级贷款应用的"第七部分"，现有的 KYC 页面已经存在，并逐一列出了页面名称。关键约束是——不要修改、删除、重命名或新建任何现有文件和数据库表。同时还提供了数据库实例信息、使用的 Windows 身份验证方式，以及已存在的数据表清单，避免 AI 产生误判。

Claude 返回的是一份完整的只读审计报告，确认"没有任何文件或数据库对象被改动"，并梳理了项目第三、四、五部分的既有记录。这一步相当于让 AI 先"读懂"整个代码库的现状。

第二段 Prompt 才是真正的实现指令。 作者要求将整个 KYC 文档模块从模拟数据转为真实的数据库后端模块，并提出了几条关键架构原则：

• 不要创建重复的 API 和架构
• 复用现有的服务、工具类和身份验证机制
• 在数据库层面，设计并创建最小必要的新表
• 优先采用集中式的文档表（centralized document table），而非为每种证件单独建表

值得一提的是，作者坦言这两段结构化 Prompt 都借助了 ChatGPT 来撰写——先把目标顺序讲清楚，ChatGPT 再将其转化为结构规范的提示词，最后交给 Claude 生成代码。这是一种"用 AI 辅助写 Prompt、再用另一个 AI 执行"的组合玩法。

"用 AI 辅助写 Prompt" 这一做法背后有其实践逻辑。直接向代码生成型 AI（如 Claude）描述复杂的企业级需求时，自然语言的模糊性容易导致模型做出过度假设——例如自行创建新表、重命名已有 API，或者忽略现有认证中间件。通过先用 ChatGPT 将目标整理成结构化、带约束条件的提示词，相当于把"需求分析"和"指令编写"这两步显式拆开。结构化 Prompt 通常包含：上下文背景（第几部分、技术栈）、明确的禁止项（not to do list）、输入参数（数据库连接方式、现有表名）和期望输出格式（文件清单 + SQL 脚本）。这种做法降低了 AI 的歧义空间，也让开发者在执行前就能审阅一遍指令的完整性，是一种低成本的"需求评审"替代手段。

逐个落地：数据库脚本与服务文件

Claude 给出的实现方案以插件形式交付，包含一段数据库 SQL 脚本和一批需要新建的源码文件。作者采取了逐个创建、逐个粘贴执行的保守做法：

• 先执行数据库脚本（db scripts）
• 在 server/src/middleware 下创建 upload.ts（文件上传中间件）
• 在 server/src/services 下创建 auditlog.service.ts（审计日志服务）
• 其余由 Claude 生成的文件也按文件名逐一创建并填入代码

完成所有文件后，作者重启了服务端与模拟环境，并通过检查 API 健康状态（API health）确认返回了成功响应。这种"一个文件一个文件地验证"的方式，虽然略显繁琐，但在企业级代码库中能有效降低一次性大规模改动带来的风险。

upload.ts 和 auditlog.service.ts 这两个文件在整个模块中承担不同职责，值得单独说明。upload.ts 是 Express/Fastify 中间件，通常基于 multer 或类似库封装文件上传逻辑，负责处理 multipart/form-data 请求、校验文件类型与大小、将文件写入服务器本地路径或对象存储，并将文件路径注入请求上下文供后续路由使用。auditlog.service.ts 则实现操作审计追踪——记录"谁在什么时间对哪条记录做了什么操作"，这在金融合规场景中是强制要求，监管机构可能随时要求提供完整的操作日志以证明 KYC 流程的合规性。将审计逻辑抽离为独立服务而非散落在各业务路由中，也体现了关注点分离（Separation of Concerns）的架构原则。

功能验证：完整的文档审核闭环

模块上线后，作者对各项功能逐一做了实测，验证了一个相对完整的文档审核工作流。

以 PAN 卡为例：从客户模块创建的四个真实客户（如 Ramesh）会同步出现在 KYC 页面。选择客户后，可以填写新的 PAN 号码、备注，并上传文档。上传成功后，系统提示"document uploaded successfully"，PAN 号码随即更新，文档状态初始为"pending（待审核）"。

审核环节覆盖了多种状态流转：

• Mark as verified：标记为已验证
• Reject：拒绝时必须填写拒绝原因
• Download / View：下载或查看已上传文档
• Delete：删除文档记录

同样的流程在 Aadhaar、护照、驾照、Voter ID、公司文件等各类证件上都验证通过。页面顶部的筛选器（verified / pending / rejected）正常工作，证件类型搜索、导出 Excel、刷新、记录统计（总数、待审核数）等功能也都能正常运行。

最后，作者直接查询了数据库表进行核验：所有操作过的数据——包括存储文件名、文件路径、审核状态——都真实落库，之前删除过的记录也确实已从库中移除。这证明前端操作与后端存储之间已完全打通。

对 AI 辅助企业开发的几点启示

这个案例虽然技术栈并不复杂（TypeScript 后端 + SQL 数据库），但它展示了一套可复制的 AI 辅助开发方法论：

1. 约束先行。在让 AI 动代码之前，用明确的 Prompt 框定"不许碰什么"，并提供数据库和架构的真实上下文，是避免 AI 乱改既有系统的关键。
2. 审计与实现分离。先让 AI 做只读分析、理解现状，再让它生成改动代码，比一步到位更可控。
3. 复用优于新建。强调复用现有服务、认证和工具类，用集中式文档表而非散落的多张表，体现了对架构整洁度的考量。
4. 人工逐步落地。即便 AI 生成了全部文件，开发者仍选择逐文件创建、重启验证，保留了人在回路中的把关。

作者表示，下一步将用同样的方法改造 Lead（线索）等其他模块，继续把模拟应用转为真实可用的业务系统。对于想用 Claude 或类似工具辅助企业级后端开发的团队来说，这套"两段式 Prompt + 逐步落地"的流程具有一定参考价值。