欢迎光临
我们一直在努力

老项目翻新实录|拿AI记账系统实测 Seed Evolving,这次真的能打

拿一个 15 张表、20+ 前端文件的老项目开刀,实测 Seed Evolving 8 月升级的 Coding、Agent 和幻觉控制三大能力

01 一个老项目,等来了新模型

作为一个技术博主,我手头维护着一个开源的 AI 智能记账系统——Smart Ledger。这个项目从最初一个简陋的单页面 demo,一步步长到了 15 张数据库表、13 个后端路由文件、90 多个预置分类的规模。前端一开始只有 H5 移动端,这次用 AI 编程工具改造后,全新的 PC 网页端也做出来了。系统后端目前接入了豆包 doubao-seed-2-0-lite-260215 和智谱 GLM-4-Flash、GLM-4V-Flash 做自然语言记账、OCR 小票识别和账单分析。

图片

代码越积越多,技术债也越来越重。移动端的 CSS 和 JS 文件各有 7 个,PC 端做完后又多了 7 个 HTML 页面加 9 个 CSS、9 个 JS 文件。每次想加一个新功能,都得在移动端和 PC 端各写一遍,维护成本很高。更头疼的是,早期写的 AI 接入代码比较粗糙,prompt 工程全靠手感,NLP 解析失败率不低,错误处理也不完善。

8 月初,火山方舟的 Seed Evolving 完成了第二次重大升级,主打三个方向:Coding 工程能力、Agent 检索能力、幻觉控制能力。我决定拿 Smart Ledger 这个老项目当"试金石",在 TraeWork 里接入 Seed Evolving 作为我的 AI 编程助手,看看它到底能不能帮我把代码翻新一遍。

先强调一句:Seed Evolving 是我写代码时用的 AI 助手,不是记账系统里调用的模型。这两者别搞混了。系统里给用户提供 AI 记账、OCR、账单分析的,还是豆包 lite 和智谱的模型;Seed Evolving 是我坐在电脑前敲代码时,帮我读代码、写代码、改代码、重构代码的"AI 同事"。

图片

项目体验地址:

​​​​​​​PC 端:https://izhangben.xunnan.net/pc/login.html

H5 移动端:https://izhangben.xunnan.net/login.html

体验账号:admin / 123456(建议注册新账号体验,避免账单数据混淆)

开源地址:https://gitee.com/xiangxiang088/smart-ledger

02 项目档案:Smart Ledger 是个什么系统

先简单介绍一下这个项目的体量,方便后面理解测试的难度。

Smart Ledger 是一个功能完整的个人/家庭记账系统,技术栈是 Node.js + Express + MySQL 后端,前端用原生 HTML/CSS/JS,没有引入任何框架。核心功能包括多账户管理(现金、微信、支付宝、银行卡、信用卡等),每个账户都有余额变动审计流水;二级分类体系,支出 11 个一级分类、收入 7 个,加上 90 多个预置二级分类;借贷中心,支持借出/借入、分期还款、到期提醒;多账本协同,可以邀请家庭成员一起记账;通知公告系统,还款到期前自动提醒。

图片

系统里的 AI 功能目前接入了豆包 doubao-seed-2-0-lite-260215 和智谱 GLM-4-Flash、GLM-4V-Flash 三个模型,实现了七项能力:

AI 功能

实现方式

自然语言记账

输入"今天午餐外卖30元",自动识别类型/金额/分类/账户

OCR 小票识别

拍照上传小票,GLM-4V-Flash 多模态模型提取金额和商家

AI 账单分析

按周/月/季/年分析消费结构,输出财务健康评分

异常消费检测

对比近 30 天与前 30 天数据,发现支出突增分类

月底收支预测

根据日均消费线性预测月底结余

智能预算推荐

基于 3 个月历史数据推荐分类预算

AI 饮食健康顾问

分析餐饮消费记录,支持多轮对话追问

数据库有 15 张表,主键全部用雪花算法生成 18 位数字 ID,所有业务表支持逻辑删除。后端 13 个路由文件,每个几百行代码。AI 路由文件 ai.js 单独就有 1030 行,包含 8 个 AI 接口。

图片

这个体量的项目,用来测试模型的 Coding 工程能力和 Agent 能力,再合适不过。

03 接入 TraeWork:配置 Seed Evolving 当编程助手

我平时用 TraeWork 做开发,接入 Seed Evolving 非常简单。操作步骤:

我是用TraeWork工具进行开发,接入Doubao-Seed-Evolving来工作很简单,如下图,点击底部头像–>设置–>模型–>添加模型

图片

然后服务商选择:火山引擎

图片

模型选择:Doubao-Seed-Evolving

图片

密钥到火山方舟官网获取:

图片

就这样,配置就OK了

图片

图片

04 Seed Evolving 8 月升级:三个关键变化

Seed Evolving 是火山方舟面向 Agent 与 Coding 场景打造的 Seed 系列模型。2026 年 8 月 1 日的升级,带来了三个关键变化:

三项核心提升

Coding 能力:复杂仓库修复、跨文件修改、真实功能开发和长程工程任务表现更好,适合 Coding Agent、代码修复与生成、仓库级开发。

Agent 能力:复杂 Agent 执行、长上下文信息定位和业务流程自动化能力提升,多工具并行调用与结果回传更稳定。

幻觉控制:搜索幻觉、工具调用幻觉以及抗误导、状态幻觉等能力均明显改善,模型更少基于错误检索结果继续作答。

另一个关键参数是上下文窗口:1024k token,最大输入 1024k,最大输出 256k。这意味着我可以把整个项目的核心代码文件一次性喂给模型。老模型的 128k 上下文窗口只能塞进 3-5 个文件,后面的就"忘"了。

更多可以查看官方文档:https://console.volcengine.com/ark/region:cn-beijing/subscription/agent-plan

05 实测一:Coding 工程能力 — 一次喂进十几个文件

先测最关心的 Coding 工程能力。

老模型的问题在于"记不住"。我之前的做法是把文件一个一个喂给模型,每喂一个就让它总结。但文件一多,模型就开始忘记前面的内容,给出的修改建议跟现有代码对不上——要么引用了不存在的函数,要么重复造轮子。

这次我把项目核心文件一次性喂给了 Seed Evolving:ai.js(1030 行)、records.js、accounts.js、categories.js、books.js、auth.js、db.js、server.js、settings.js、loans.js、reports.js,加上前端的 common.js 和 bills.js,一共十几个文件,加起来超过 8000 行代码。

图片

模型的第一反应让我吃了一惊。它没有急着给修改建议,而是先输出了一份项目结构分析:

这是一个基于 Node.js + Express 的记账系统后端,使用了 MySQL 连接池、JWT 认证、雪花算法 ID 生成。AI 模块通过 fetch 调用外部 API,包含账单分析、NLP 解析、OCR、异常检测、预测、预算推荐、饮食分析、饮食对话 8 个接口。数据库涉及 15 张表,使用逻辑删除(del_flag)和审计字段(created_by/updated_by)。前端分 H5 移动端和 PC 端两套独立代码,PC 端已有侧边栏+顶栏布局框架。

这段分析完全准确。它甚至注意到了 AsyncLocalStorage 透传用户 ID 的设计——这是项目里比较隐蔽的一个细节,通过 auditContext.js 实现操作日志的自动写入。

接下来我给它布置了一个真实的重构任务:早期写的 ai.js 里 8 个 AI 接口的错误处理非常粗糙,很多地方只做了简单的 try-catch,JSON 解析失败就直接 500,没有降级方案;另外 NLP 解析的 prompt 写得很随意,分类匹配经常出错。让 Seed Evolving 帮我整体重构这个文件。

图片

模型给出的重构方案有几个亮点:

第一,它没有粗暴地重写整个文件,而是保留了我原有的接口设计和路由结构,只针对有问题的部分做改进。比如每个 AI 接口都加了统一的错误处理封装,当 AI API 调用失败时,预算推荐和月底预测这两个接口会自动降级到纯算法计算,不会让前端看到 500 错误。

第二,它发现了我自己都没注意到的一个 bug:OCR 接口里图片 base64 数据没有做大小校验,用户上传大图可能导致请求体过大。它主动在路由里加了 4MB 的大小限制,并给出了友好的错误提示。

第三,最有价值的是 NLP 解析 prompt 的重构。原来的 system prompt 只列了 7 条简单规则,分类列表只是平铺 id 和 name。Seed Evolving 理解了我现有的二级分类体系后,建议把每个分类的完整层级路径都传给模型(比如"支出 > 餐饮 > 外卖"而不只是"外卖"),同时在 prompt 里增加了几个典型的匹配示例。下面是它重构的核心片段:​​​​​​​

// Seed Evolving 重构后的 NLP 解析 prompt(节选)
const systemPrompt = `你是一个智能记账助手,负责将用户的自然语言描述解析为结构化的记账数据。

请严格按照JSON格式返回,不要返回任何其他文字说明。
【分类匹配规则】
1. 优先选择最细分的二级分类,不要选一级分类
2. 注意区分易混淆分类:
   – "打车/地铁/公交/加油" → 支出 > 交通
   – "外卖/午餐/晚餐/奶茶/咖啡" → 支出 > 餐饮
   – "买衣服/买鞋/网购" → 支出 > 购物
   – "房租/水电/物业费" → 支出 > 居住
   – "看病/买药/体检" → 支出 > 医疗
3. 如果用户说"还钱给我"是收入,"我还钱"是支出/转账
【返回格式】
{"type":"expense|income|transfer","amount":数字,"category_id":数字,
 "account_id":数字,"to_account_id":数字或null,
 "record_date":"YYYY-MM-DD","note":"备注文字"}`;
// 重构后的分类列表包含完整层级路径
const catList = cats.map(c => {
  let path = c.name;
  let p = c.parent_id ? catMap[c.parent_id] : null;
  if (p) {
    path = p.name + ' > ' + path;
    let gp = p.parent_id ? catMap[p.parent_id] : null;
    if (gp) path = gp.name + ' > ' + path;
  }
  return `{"id":${c.id},"path":"${path}","type":"${c.type}"}`;
}).join(',');

这段代码和 prompt 改完后,"打车去公司25块""晚上跟朋友聚餐AA80""还信用卡2000"这类容易误分类的输入,解析正确率从原来的 70% 左右提升到了 90% 以上。注意:记账系统里调用的还是原来的模型,效果提升完全来自 prompt 工程和代码逻辑的优化,这是 Seed Evolving 作为编程助手帮我做到的。

图片

06 实测二:Agent 能力 — 从读懂到自动生成

Agent 能力的测试,我设计了一个更有挑战性的任务:让模型根据移动端代码,自动生成 PC 端的对应页面。

Smart Ledger 的 PC 端原本只有基础框架和首页、账单两个页面。移动端有完整的账单、账户、报表、借贷、个人中心 7 个页面,PC 端还差 5 个页面没做。我需要把剩下的页面补齐,同时完善还款提醒、通知中心这些新功能。

图片

这个任务的复杂度在于:模型不能简单照搬移动端代码。PC 端的布局完全不同——移动端是底部导航的响应式布局,PC 端是侧边栏加顶栏的桌面布局。CSS 和 JS 完全隔离,但调用的后端 API 是同一套。而且 PC 端的组件风格已经在已有的两个页面里定下来了,新页面必须保持一致。

我把移动端的 accounts.js(账户管理逻辑,约 500 行)和 PC 端已有的 pc-bills.js(约 500 行)一起喂给模型,让它理解两端的差异,然后生成 PC 端的 pc-accounts.js 和对应的 CSS。

模型的执行过程展现了明显的 Agent 特征,分四步完成:

第一步,功能分析。它列出了移动端 accounts.js 的功能清单:账户 CRUD、余额调整、流水查询、信用卡账单日/还款日管理、账户类型分组展示、净资产汇总。

第二步,风格提取。它对比了 pc-bills.js 的代码风格,提取出 PC 端的编码模式:使用 pcFetch 封装请求、侧边栏导航高亮切换、Canvas 图表绘制、弹窗组件复用 pc-modal、顶栏徽章通知更新。

第三步,代码生成。它一次性生成了 pc-accounts.js(约 600 行)和 pc-accounts.css(约 200 行)。关键功能包括账户卡片网格展示、信用卡到期醒目标记、流水明细分页加载、余额调整弹窗、净资产总览卡片。

第四步,自检清单。最让我意外的是,模型在生成代码后主动列出了一个待检查清单:

模型自检清单

1. 确认 /api/accounts/:id/transactions 接口在 PC 端的分页参数(page/page_size)是否与移动端一致

2. 确认信用卡账单日和还款日字段在 PC 端表单中是否需要日期选择器组件

3. 确认余额调整流水的弹窗是否需要复用移动端的 audit log 时间轴展示

4. PC 端账户卡片点击后弹出流水,弹窗宽度建议设为 600px,表格列是否够放

这四个点都是实际开发中容易遗漏的边界情况。模型不是在"生成代码",而是在"理解需求、设计方案、实现代码、验证完整性"。这就是 Agent 能力和单纯代码生成的本质区别——它有一个完整的任务规划和自检链路。

图片

除了补页面,我还让它帮我做了一个批量删除账单的功能。整个过程我只说了一句话:"帮我在 records.js 里加一个批量删除接口,前端也要加上批量选择的 UI。"它自己完成了:后端接口加事务包裹、复用 del_flag 逻辑删除、权限校验、操作日志记录;前端加复选框、全选/反选、批量删除确认弹窗、删除后自动刷新列表。全程没有让我一步步指挥。

老模型做同样的任务,我得至少交互四五轮,每次告诉它"你漏了什么""这里风格不对""还要加事务"。Seed Evolving 可以一次对话里把整条链路跑完。PC 端 5 个页面的补齐,如果纯手写大概要一周;借助 Seed Evolving,两天就完成了初版,而且代码风格跟我手写的一致。

07 实测三:幻觉控制 — 告别"一本正经胡说八道"

幻觉问题是我用老模型时最头疼的事。

举个例子,我之前让老模型帮我优化 NLP 解析的 prompt,它建议我调用一个叫 parseFinancialEntity() 的工具函数来预处理用户输入。问题是,项目里根本没有这个函数,它是模型"编"出来的。更麻烦的是,模型还会编造数据库字段名,比如建议我查询 sl_biz_record.merchant_id 字段——这个字段不存在,实际用的是 note 字段存商家名。如果你不仔细检查直接用,跑起来全是报错。

这次我专门设计了几组幻觉测试。

测试一:项目结构描述

让模型描述 Smart Ledger 的数据库表结构。它准确列出了 15 张表的名字和用途:sl_sys_user、sl_ledger_book、sl_acc_account、sl_acc_transaction、sl_biz_category、sl_biz_entity、sl_biz_record、sl_biz_budget、sl_biz_loan、sl_biz_loan_record、sl_ai_analysis、sl_sys_config、sl_sys_notice、sl_sys_notification、sl_sys_feedback……没有多编一张,也没有漏掉一张。作为对比,老模型之前"发明"了一张叫 sl_biz_tag 的标签表——项目里根本没有标签功能。

图片

测试二:API 路由列举

让模型列出 ai.js 中定义的所有 API 接口。它给出了 8 个接口,路径和功能描述都正确:/api/ai/analyze、/api/ai/parse、/api/ai/ocr、/api/ai/anomaly、/api/ai/predict、/api/ai/budget-recommend、/api/ai/diet、/api/ai/diet-chat。没有多编,也没有漏。它甚至注意到了 diet-chat 是多轮对话接口,跟其他一次性分析接口的区别。

图片

测试三:代码修改准确性

让模型在 records.js 中添加一个"批量删除"接口。它正确引用了现有的 del_flag 逻辑删除字段、snowflake.nextId() ID 生成、getBookRole() 权限校验、auditContext 审计日志,以及数据库事务。所有引用的函数和字段都在项目中真实存在,没有一个编造。连我自己都忘了加的操作日志,它主动加上了。

测试四:抗误导能力

我故意在提示中加了一句错误信息:"项目的用户表叫 sl_users,帮我在上面加个字段。"模型没有盲从,而是纠正说:"根据代码中的数据库初始化脚本,用户表名是 sl_sys_user,不是 sl_users。请问你是要在 sl_sys_user 表上添加字段吗?"这个抗误导能力在老模型上几乎看不到——老模型通常会顺着你的错误前提继续往下写。

Seed Evolving 在幻觉控制上的改善,用官方的说法是"模型更少基于错误检索结果或错误工具调用继续作答"。在实际开发中,这意味着我不再需要花大量时间去验证模型给出的代码引用是否正确。以前用老模型,每段生成的代码我都得人工核对一遍函数名和字段名;用 Seed Evolving,核对的工作量减少了至少 80%。

08 量化对比:改造前后数据一览

几轮测试下来,我把关键数据汇总成了一张表:

对比维度

之前用的编程模型

Seed Evolving

上下文窗口

128k token

1024k token

单次可读文件数

3-5 个就开始串

10+ 个稳得住

代码生成可用率

约 60%,需 2-3 轮修改

约 85%,多数一次可用

幻觉率(引用不存在的函数/字段)

较高,每轮约 2-3 处

极低,多轮测试未出现

PC 端页面生成

不敢让它独立做

基于移动端代码生成,需少量调整

Agent 任务链路

单步执行,需人工逐步引导

可完成"分析-设计-实现-验证"全链路

项目结构理解准确率

部分准确,有遗漏和编造

准确率 > 95%

抗误导能力

容易被错误信息带偏

能主动纠正错误前提

需要说明的是,"代码生成可用率"是一个主观估计,标准是生成的代码能否在不做大的结构性修改的前提下直接运行。Seed Evolving 的 85% 是几轮测试的综合感受,不代表所有场景。但跟老模型的 60% 相比,体感差距非常明显。

09 打工人总结

几轮测试下来,Seed Evolving 给我最深的感受是:它不是在"写代码片段",而是在"做工程"。

以前的 AI 编程助手更像一个打字快的实习生——你说一句它写一段,但不太管上下文,经常写出跟现有代码风格不一致的东西,还会编造不存在的函数,最后还得你来查错擦屁股。Seed Evolving 更像一个能读懂整个项目的高级工程师——给它十几个文件,它能理清架构;让它做改造,它会先理解再动手;生成的代码,函数命名、错误处理、代码风格都跟现有代码一致;做完了还会自己列清单让你检查。

对于一个维护着 15 张表、20 多个前端文件的老项目来说,这种能力意味着什么?意味着我可以把"重构"和"补功能"这件事真正交给 AI 来主导,而不是自己一行行敲。PC 端 5 个页面的补齐,纯手写大概要一周;借助 Seed Evolving,两天就完成了初版。ai.js 1000 多行代码的重构,包括错误处理、prompt 优化、bug 修复,一个下午就搞定了。还款提醒、通知中心这些新功能,也都是在它的辅助下快速完成的。

图片

如果你也有一个积压了技术债的老项目,不妨在 TraeWork 里接入 Seed Evolving 试试。一个 Model ID doubao-seed-evolving,配置简单,拿你的真实代码去测,比看任何 benchmark 都直观。

赞(0)
未经允许不得转载:171主机测评 » 老项目翻新实录|拿AI记账系统实测 Seed Evolving,这次真的能打
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址