事情是这样的。
为什么我想从零搓一个对账系统
最近我想把公司堆积如山的发票好好对一遍，找一款顺手的工具，看了几个现成的 SaaS，要么贵得离谱，要么对国内发票格式水土不服。于是冒出一个有点中二的念头，能不能用 AI 从零帮我搓一个。
正好火山方舟的 Seed Evolving 7 月 15 日刚升级了一次新版本，支持 1M 超长上下文，长程任务能力也上了一个台阶，官方说法是 Tokens 效率也优化了，整体往 Coding 和 Agent 方向加码。说人话就是，这模型现在啃下整个全栈项目应该问题不大。
行，那咱们就试试看。
先说说为什么我要搞对账这件事。财务每个月要处理成百上千张增值税发票，光是发票号码、金额、供应商、销售方这几项就够喝一壶的，更别说还要跟订单、合同、付款记录三方核对。重复票、金额拆分、订单金额不符这些坑，全靠人工 Excel 公式和肉眼扫表，时间长了谁都扛不住。
我想要的是这么个东西，丢一张发票进去，它能 OCR 出票面信息，自动去跟订单对得上，自动把金额拆分的、跟订单对不上的、号码重复的这些可疑项挑出来。说起来简单，真正能跑起来的东西其实不简单。
开工，把需求丢给 Seed Evolving
配置阶段挺顺利。把开发提示词塞给 Seed Evolving，然后告诉它我要什么，一套 OCR 抽取、对账引擎、风险检测、前后端全栈、带登录界面的票据智能对账系统，名字我都想好了，叫 IIRS。
模型上来就开始吐代码，一个文件一个文件地写，从数据库 schema 到 API 路由，从 OCR 流水线到前端组件，全栈一口气铺开。这一路上我没怎么插手，主要就看着它干活。
登录界面卡住了，401 刷屏
第一波代码写完，我琢磨着本机跑跑看。后端 FastAPI 起来，127.0.0.1 加上 8123 端口，前端静态文件搭好，我打开浏览器登录地址。
转圈。
我以为是网慢，等了一会，还在转圈。。。我打开浏览器开发者工具，切到 Console，一看日志，刷屏。
401。一片一片的 401。点开看，是前端在请求 /api/auth/me 和 /api/dashboard/stats，被后端鉴权中间件直接打回来了。登录界面也卡死在加载态，永远看不到那个表单。
我把这个现象丢回给 Seed Evolving，附上控制台报错。
第一轮诊断，模型判断错了
它给了一句让我哭笑不得的话，大意是「401 不是 bug，是登录令牌失效了，我们中间重启过几次后端，而且 .env 里的 SECRET_KEY 改过，你浏览器里之前存的 token 现在验不过了。解决很简单，在那个页面按 F12 打开控制台，输入 localStorage.clear() 回车，然后刷新页面，就会跳回登录页，用 admin / admin123 重新登录即可」。
我当时第一反应是这好像有点想当然。但人家是模型嘛，我跟你说，照做了，按 F12，清 localStorage，刷新。
还是 401。
还是转圈。
第二轮，模型找到了真正的根因
这下我知道，问题没那么简单。我把现象原样丢回去，跟它说「还是这样」。它这次想得久一点，Thought for 51s，给我来了一份更扎实的判断。
它说问题不在拦截器，而在组件挂载顺序。
原话是这样的，「我找到了真正的根因。问题不在拦截器，而在组件挂载顺序，你的页面结构是 Dashboard + AppShell，所以页面一挂载，Dashboard 的 useEffect 就立刻去请求 /api/dashboard/stats，这时候 AppShell 还没来得及确认登录态，于是带着旧 token 打出那个 401。等 AppShell 确认完才跳转，但那个 401 已经发生了。」
「正确做法是，未确认登录前，受保护页面绝不发任何数据请求。我给每个受保护页面加一道登录态闸门（useReady），没拿到之前不加载数据。这样 /dashboard/stats 的 401 就彻底消失，只剩 /me 那一次（用于清旧 token+跳转），且只发生一次，之后旧 token 被清除就再也没有了」。
我看到这里是有被爽到的。它自己想明白了，第一轮判断错了，第二轮能基于我扔回去的「还是这样」重新定位，这种修正能力是工程上真正稀缺的。
接着它顺手把 useReady.ts 写了出来。
我把这文件挪到前端工程对应的目录，重新跑，刷新页面。
闸门立起来了。控制台干净了，401 一夜之间从刷屏变成 0，登录界面终于出来了，admin / admin123 一登，跳到看板。
修复之后，全链路实测
修完没完，我还得跑一遍各页面看是不是真的稳。顺手截图存证，这东西后面写复盘有用。
登录页，表单正常加载，登录跳转无障碍。
财务看板，七张演示发票躺在那，价税合计 472,750 元，健康指数 66，高危风险 4 项，最近活动一目了然。
发票列表，七张示例发票，号码、销售方、金额、状态全部就位，状态统一标 done，OCR 抽取后进入对账流水线。
风险中心自动识别出六条风险事件，高危 4、中危 2，覆盖发票号码重复、金额拆分、金额与订单不符这些场景。
AI 助手入口也正常加载，对话能力留给后面慢慢接。
全链路过了，可以收工。
1M 上下文、长程任务、Tokens 效率，到底强在哪
说到这我想多聊两句，这次能跑通，跟 Seed Evolving 的能力是直接相关的。
1M 超长上下文这事不是说说的。我们前后端一摊子代码，几百 KB 不止，加上 OCR 流水线、对账引擎、风险规则、数据库 schema、AI 调用封装，零零碎碎几十个文件。它要在排障时能从 stack trace 一路追到具体的 useEffect，要在我扔回去一段控制台日志时能准确还原当时的代码路径，靠的就是把整个项目一次吃进去不分片。普通的上下文窗口，做这种跨文件的事得反复来回粘，1M 的好处就是不用这么折腾。
长程任务质量这一项更直接。这一轮我们聊了六轮对话，从最初的鉴权报错，到 token 失效的误判，到组件挂载顺序的真正根因，到 useReady.ts 的实现。模型能在第六轮还能精准调用第一轮我们说的那个鉴权问题，能在「还是不对」这种含糊的反馈里不重复同一个错误假设，这种稳定性才是工程上真正值钱的。
Tokens 效率优化我体感也很明显。我把报错原样丢回去，它给的方向很精准，不用我反复补充上下文，不用在好几个方向上试错，一次定位到组件顺序。这一发入魂的体验，对实际工程进度影响挺大。
最后，说点心里话
写到最后，想说点心里话。
也许你会说，从零搭一个发票对账系统听起来有点小题大做，市面上一堆 SaaS，何必自己造。说实话这想法也合理，我也理解这种感受，不是每个人都需要从零搓一个系统，工具该用就用，效率优先。
但我这次想试的不是「从零搓系统」本身，是想看看 Seed Evolving 这种聚焦 Coding 和 Agent 的模型，在真实工程现场到底是什么成色。怎么说呢，搭系统是顺带的，检验模型的能力才是目的。
以前觉得，让 AI 写代码，重点是它能不能吐出一份能跑的文件。现在觉得，重点其实是它能不能持续在长程任务里保持稳定，能记得前面的决定，能在新的报错里调用前面的判断，能在用户说「还是不对」的时候不犯同样的错。1M 上下文是个好东西，但 1M 上下文里能不能保持推理稳定，是个更难的事。
这次体验给我一个挺深的感受是，模型写代码这件事，真正卡脖子的不是单点能力，是持续稳定地不犯错。Seed Evolving 在这一点上这次表现确实可以。
如果你也想试试 Seed Evolving，火山方舟 Agent Plan 单月套餐 9.9 起，体验链接在这
模型卡片统一是 doubao-seed-evolving，一次接入、自动升级、零迁移成本，下次升级又能直接用上，不用改代码。现在还有体验奖励计划，调用成本立减 20%，可以顺手薅一下。
至于我自己搓的这套票据对账系统，回头我把它整理整理，争取把代码放出来。今天就先到这里。