我指挥 AI 写了个AI工具“解救”她

白水清风
94 阅读10分钟

起因：拒绝重复造轮子，更拒绝手动搬砖

故事的起因是我的爱人。做采购工作的她，每到月底就是“Excel 地狱”：打开表格 -> 翻文件夹找 PDF 合同 -> 肉眼找产品信息 -> 按计算器算产品单价 -> 填回表格。

这套动作每天重复上百次，不仅枯燥，而且肉眼在密密麻麻的合同条款里找数字，太容易出错了。

看着她在那叹气，我第一反应是：这活儿简直就是给 AI 量身定做的。

这不就是典型的信息抽取和格式化工作吗？与其让她当“人肉OCR”，不如写个工具自动跑。虽然是个小需求，但为了家庭和谐，这活儿必须接。我只负责想思路和提要求，代码实现全部交给 AI，自己再小修小改。

分工明确：我是 PM，AI 是程序员

在这个只有一天的“微型项目”里，我们的分工非常明确：

  • 我：负责业务逻辑拆解、技术选型决策、Prompt 设计（核心业务逻辑）、以及代码审查（改 Bug）。

  • AI：负责写具体的前端代码、写 CSS 样式、查 API 文档、处理数据转换的脏活累活。

我的核心策略是：纯前端、无后端、CDN 引入。怎么简单怎么来，最好连 npm install 都不要跑。

我告诉 AI 的技术栈指令总体如下：

基于Vue技术栈开发一个功能完善的纯前端自动对账工具。请按照以下详细需求进行完整方案规划与开发：

## 主要目标

1. 实现对账表格上传与解析功能，将上传的表格文件转换为结构化数据
2. 实现多合同文件上传与通过AI提取信息功能，从每个合同中提取订单编码和产品信息并输出结构化数据
3. 开发对账匹配系统，通过唯一约束遍历表格每一行，匹配合同中的产品单价信息并补充到表格中

## 技术架构与选型要求

- AI集成：设计灵活的API调用模块对接第三方大模型服务
- 本地存储：使用localStorage或IndexedDB实现数据持久化

## 功能模块详细开发需求

### 1. 对账表格数据上传模块

- 实现Excel文件(.xlsx, .xls)上传功能，包含：
  * 文件类型验证（仅允许.xlsx, .xls格式）
  * 文件大小限制（严格限制在10MB以内）
  * 上传状态反馈（进度指示、成功/失败提示）
- 数据解析配置功能：
  * Sheet选择（指定Sheet,默认为第1个Sheet）
  * 行范围设置（指定数据起始行，默认为第1行）
  * 表头识别和自主对应列(指定的数据起始行为表头，可以手动调整字段对应列)
  * 固定字段为 `orderNo`、`productName`、`color`、`qty`、`unit`、`price`
  * 日期格式化，对于日期格式的数据，进行`YYYY年MM月DD日`的格式化
- 数据预览界面：
  * 实现表格完整展示
- 文件管理：
  * 仅允许上传一个表格文件，新上传文件自动覆盖旧文件
  * 提供文件信息展示（文件名、大小、上传时间）
  * 支持重新上传与清除功能

### 2. 订单合同文件上传模块

- PDF文件处理功能：
  * 支持多文件上传（允许多个合同PDF同时上传）
  * 文件验证（仅PDF格式，大小限制20MB以内）
  * 文件管理（列表展示、单个删除、全部清除）
- PDF预览功能：
  * 实现内置PDF预览器，支持页面导航
  * 提供缩放、旋转、下载功能
- AI辅助信息提取：
  * 实现订单编号智能识别与提取
  * PDF中的表格数据提取与结构化：
    * 多产品表格处理：准确划分产品边界，提取各产品完整信息，总价是负数的数据直接跳过。参考图片提供的多产品表格
    * 单一产品多明细处理：汇总计算产品总单价（基础价格+各项费用），参考图片提供的单一产品多费用明细
  * 提取结果预览与编辑：展示AI提取结果，允许人工修正
  * 提取历史记录：保存提取结果，支持查看与重新提取
- 数据验证与处理：
  * 展示AI提取的结构化数据(表格形式)
  * 人工修正入口

### 3. AI大模型连接配置模块

- 配置界面设计：
  * 实现API连接参数表单（apiurl、apikey、apimodel）
  * 实现AI提示词的录入
  * 提供参数验证功能
  * 支持测试连接功能，验证配置有效性
- 安全机制：
  * 敏感信息加密存储
  * API密钥脱敏展示
- 扩展性设计：
  * 预留多模型支持架构
  * 实现请求超时处理与重试机制
  * 添加API调用频率控制

### 4. 对账匹配功能

- 匹配规则配置：
  * 支持多关键字段组合匹配（订单编号、项目名称、商品详情、数量、单位）
  * 允许用户调整匹配字段权重
  * 必须严格匹配
- 对账处理流程：
  * 实现表格逐行自动匹配功能
  * 单价信息自动填充到对应表格行
  * 匹配进度实时展示
- 异常处理机制：
  * 未找到匹配合同：标记为红色，提供手动匹配入口
  * 多个匹配结果：列出所有可能选项供用户选择
  * 数据不一致：高亮显示差异项，提供对比视图
- 人工干预功能：
  * 手动匹配界面（合同列表选择、产品选择）
  * 单价手动输入与编辑
  * 批量处理功能（批量忽略、批量应用）

### 5. 导出功能

- 结果导出：
  * 支持导出完整对账结果为Excel文件
- 导出优化：
  * 大数据量导出性能优化
  * 导出进度提示与完成通知

### 6. AI大模型连接配置模块

- 开发参数配置界面，用于设置AI大模型连接信息，包含以下必填参数：
  * apiurl：AI服务接口地址
  * apikey：API访问密钥
  * apimodel: AI模型名称
  * promote：AI提示词
- 配置管理：
  * 支持配置保存与加载
  * 提供测试连接功能
  * 错误处理与提示机制

### 7. 整体系统要求

- 用户界面设计：
  * 直观友好的操作流程，减少学习成本
  * 响应式设计，适配桌面端与平板设备
  * 清晰的视觉层次与操作引导
  * 统一的交互模式与反馈机制
- 数据持久化：
  * 实现本地数据存储，确保页面刷新或浏览器重启后数据不丢失
  * 存储内容包括：上传文件、解析结果、匹配结果、AI配置
  * 提供数据清除功能
- 性能优化：
  * 实现大型文件处理的异步加载与处理
  * 优化表格渲染性能，支持万级数据流畅操作
  * 实现数据缓存机制，减少重复计算

## 开发与测试要求

- 代码规范：遵循ESLint规范，使用Prettier保持代码风格一致
- 组件设计：实现组件化开发，确保组件复用性与可维护性
- 状态管理：合理设计数据流向，避免状态混乱
- 错误处理：全面的异常捕获与友好提示

## 交付物

- 完整的源代码（包含注释）
- 开发文档（架构设计、模块说明、API文档）
- 用户操作手册

请基于以上需求进行详细技术方案设计，包括系统架构图、数据流程图、UI/UX设计稿，然后进行分模块开发实现。

用 AI 解决“格式地狱”

这一步是整个项目的灵魂。

最开始我想过用正则提取价格，但马上放弃了。合同格式五花八门：有的表格有线，有的没线，有的单价在左边，有的在备注里写着“含运费”。用正则写规则根本无法无法实现。

这时候就该 大模型 上场了。我把上一步提取出来的乱七八糟的文本直接扔给 API，提示词（Prompt）的核心思路就是：“你是个会计，帮我把这些字里的产品名、数量、单价找出来，如果有折扣或者运费，你自己算好最终单价，给我返回 JSON。”

Prompt 的关键点：

你是一个专业的合同信息提取助手。请从以下合同内容中提取信息，并以JSON格式返回。

需要提取的信息：
1. orderNo: 订单编号/合同编号
2. products: 产品列表数组，每个产品包含：
   - name: 产品名称
   - color: 颜色
   - package: 包装
   - quantity: 数量
   - unit: 单位
   - unitPrice: 单价（数字类型，如有多项费用请计算总单价）
   - remark: 备注（可选）

注意事项：
- 如果有多个产品，请分别提取
- 跳过总价或单价为负数的产品
- 单价需要包含所有附加费用（如开模费、定制费、加工费、运费、安装费等）
- 如果费用没有单价，需要使用总价/数量计算出单价，保留两位小数
- 如果备注中表示需要加收的金额，也需要增加到单价中
- 如果备注中表示单价已包含加收,则不需要增加到单价中
- 如果信息不完整，用null表示
- 仅返回JSON，不要其他说明

示例输出格式：
{
  "orderNo": "PO-2024-001",
  "products": [
    {"name": "产品A", "color": "红色", "package": "中文包装", "quantity": 500, "unit": "个", "unitPrice": 15000.00}
  ]
}

这样一来，我就不需要写复杂的逻辑判断，AI 帮我把非结构化的文本变成了结构化的 JSON。

开发体验总结：编程方式变了

整个开发过程大约只花了 1 天。如果按传统方式开发，光是处理 PDF 格式兼容性和编写 UI 样式（Tailwind 的 class 写起来很长），可能就不只1天。

在这个过程中，我发现 “编程”的定义变了：

  1. 从“怎么写”到“要什么”：我不再纠结于 API 怎么调用、样式类名是什么，而是专注于逻辑流是否通顺、异常情况怎么处理（比如 AI 提取失败了怎么办，存储空间满了怎么办）。

  2. Prompt Engineering 即业务逻辑：以前业务逻辑写在 if/else 里，现在复杂的模糊逻辑（比如“判断备注里的费用是否包含在单价中”）全部写在了给 API 的 Prompt 里。

  3. 门槛降低，上限提高：虽然代码是 AI 写的，但我必须懂技术才能知道这样实现是否合适，才能看懂 AI 有没有在瞎写。

部分截图如下

image1.png

image2.png

image3.png

image4.png

image5.png

成果与反馈

最终交付给“甲方”(我媳妇)的产品虽然底层代码不是我一行行敲的，但架构和灵魂是我的。

反馈如下：

  • 效率起飞：原本半天的活，现在拖拽进去，去喝杯咖啡，回来核对一下就行。
  • 准确度惊人：得益于大模型的理解能力，它比我也想写的正则匹配准确太多了。
  • 家庭地位+1：这是最重要的。

一点感想

这个项目没有什么高大上的架构，代码量也很少，但它是我近期最有成就感的项目。

有时候我们过于追求技术的高深，却忘了技术的初衷——解决问题。能用几十行代码 + 一个 API 接口把家人从繁琐的重复劳动中解放出来，这种感觉非常好。

这个项目中AI提取PDF中产品信息的部分已开源，虽然代码大都是 AI 生成的，但思路值得大家参考。与其自己死磕代码细节，不如学会指挥 AI，把精力花在解决实际痛点上。

avatar
文章
阅读
粉丝