装修刚结束时我觉得家里的事自己肯定忘不了。电视墙哪一段走了电线书房网口接在弱电箱几号端口厨房水槽下面留了哪些接口配电箱每一路管什么……那阵子天天和这些东西打交道闭着眼都能说出来。两年后我准备在电视墙上装个架子拿着电钻却迟迟不敢下手。施工照片还在手机里报价单和验收表也没有丢施工群的聊天记录更是一条不少。问题是它们散在相册、文件夹和聊天记录里。真要找某一面墙、某一个插座仍然得从头翻。我这才意识到房子交付时少了一样东西一本属于它自己的使用说明书。这本说明书不能只是网盘。点开一个房间相关图纸、照片和验收记录应该跟着出现问“书房网口接在哪里”答案需要带原始出处资料里没写的事也该老老实实说不知道。于是我动手做了“栖居档案”。这个项目刚好撞上 Evolving 的两次更新我是在火山方舟 Agent Plan 里用 Doubao-Seed-Evolving 开始这个项目的。8 月 3 日的更新里我在意的是三件事复杂工程和跨文件修改更稳了Agent 检索零散信息的能力加强了遇到证据不足时也更少顺着错误结果继续回答。再往前一轮模型已经支持 1M 超长上下文并加强了长程任务稳定性。这几项能力放在房屋档案里很具体。系统既要写前端、后端和数据库又要读户型图、照片、表格和聊天摘录任务中间还会不断改需求。更麻烦的是装修知识听起来都很像那么回事模型一旦把常识当成这套房的事实结果反而危险。我使用统一的 doubao-seed-evolving Model ID通过 Responses API 接入。它并非等系统写好后才负责问答。从需求拆解、数据表设计到 React 页面、Express 接口、数据存储、资料解析、向量检索、Three.js 场景和自动化测试Doubao-Seed-Evolving 一直在同一条开发链路里工作。产品跑起来以后它又继续处理用户上传的房屋资料。开发和联调告一段落时Agent Plan 控制台记录了约 2.1 万 AFP 的实际使用量。它不是一上来就长这样一开始我做了一个固定户型的 3D 页面。画面能转、房间能点看起来已经像个产品了。很快我就发现方向不对每个人的房子都不一样固定户型做得再精致也只是别人的家。我把这个问题继续交给 Doubao-Seed-Evolving。接下来改动的不只是一个上传按钮。数据库要保存每个项目自己的房间、多边形、门窗和水电点位后端要让视觉识别结果进入项目数据前端还要把二维坐标转换成 Three.js 几何。旧项目没有完整坐标也得有兼容方案不能升级一次就打不开。现在用户可以上传自己的户型图。模型会识别空间名称、房间边界、中心点以及图中明确画出的家具、插座、网口、阀门和线路。识别结果先进入“待确认”状态用户可以修改房间名称也可以拖动定位点校正位置。截图里的户型共有 8 个空间主卧、儿童房、书房、客餐厅、玄关、卫生间、开放式厨房和生活阳台。8 个名称都识别出来了随后被转换成这套房自己的 3D 空间。3D 版本也返工过几轮。房间起初太空我补了跟随空间尺寸变化的家具家具加上以后水管、电线和插座又无处可查点位放进去后场景的光影太重墙线和标记看不清把 3D 塞在双栏页面里操作区域又显得局促。这些问题都不是改一个样式就能结束。Doubao-Seed-Evolving 持续修改了几何生成、材质、灯光、后处理、对象拾取、图层状态和页面路由后来才有了独立的 3D 页面。木地板、石材、布料、金属、陶瓷和玻璃使用 PBR 材质场景保留环境反射与软阴影Bloom、SSAO 和暗角只留一点层次不再把画面压暗。画布使用原生像素倍率和 4 倍多重采样门窗也从贴在墙上的符号变成了实际洞口。房间里的东西可以点击。点主卧衣柜浮层会说明它是图纸识别还是陈设示意档案里若有衣柜板材记录也会同时给出来源编号。这样一来3D 里的家具不会被误认成这套房真实购买过的物品。插座、水管和证据也放回房间里3D 页面上有家具、电气、给排水三个开关。橙色标记负责插座、网口、配电设备和隐蔽线路蓝色标记负责给水、阀门和排水绿色标记指向现场证据。这里有一条我一直没有放松的规则位置不够明确就不能画得像施工坐标一样准确。资料里写了“书房网口在桌面左侧”“厨房预留净水插座和冷水三通”“玄关柜下有总阀”这些事实可以确认但文字无法还原厘米级位置。因此页面会标注“档案事实·点位示意”。图纸明确画出的线路使用实线文字资料推导出的关系使用虚线。点击玄关配电设备页面会切到玄关并显示安装位置、核验状态和原始资料编号。一个物件从此能顺着空间找到事实再顺着事实找到文件。2D 原图仍然保留。识别结果有偏差时可以直接拖动定位点没有户型图时页面就保持空白不会自动套一张看起来很完整的通用户型。文件上传以后整理工作才刚开始房屋资料很少整整齐齐地放在一种格式里。这个项目同时放进了户型图片、施工照片、表格、Markdown 验收记录和施工群聊天摘录。“栖居档案”先保存原始文件再由 Doubao-Seed-Evolving 提取空间、事实、状态和维护事项随后建立检索索引。当前项目的 6 份资料全部处理完成待处理 0 份、失败 0 份一共整理出 33 条结构化事实和 7 项维护记录。我把事实分成“已核验”“待确认”“未找到”三种状态。照片里如果只能看见配电箱中有多路断路器却看不清品牌和回路标签系统只记录看得见的部分。型号和线路用途会留空等后续补资料。这个小设计后来成了整套产品里我很看重的一部分。房屋维修涉及打孔、电气、燃气和防水少填一个空白远比补一个顺口的答案稳妥。我用两个问题试了它资料整理好以后我先问“书房网口对应弱电箱哪个端口”页面回答“03 号端口”并附上原始来源。点击编号可以直接打开对应的验收记录。这次检索命中 1 份直接来源相关度为 0.489状态为“已核验”。接着我故意问了一个资料里没有答案的问题“生活阳台的设计承重是多少”这类问题很容易得到一个听起来合理的住宅经验值但那不是这套房的证据。本次检索得到的相关度是 0.278946低于系统设置的 0.28 阈值。页面返回“未找到”来源数量为 0并提示补充结构图纸或验收记录。这次拒答让我对 Doubao-Seed-Evolving 的幻觉控制有了比较具体的感受。它没有顺着一个低相关结果继续编数字服务端也会过滤掉不在候选列表中的来源编号。到了这里“少幻觉”已经变成能在页面上复现的行为。近 5,000 行代码难点在于一直改下去目前仓库有 36 个工程文件、4,893 行代码和 245,823 个字符。去掉测试文件非测试工程代码有 28 个文件、4,660 行其中前端与 3D 部分 2,924 行服务端 1,240 行其余是构建、数据升级和视觉验证脚本。后端提供 15 个 API 路由和 6 张 SQLite 数据表文件解析覆盖图片及 13 种文档扩展名。这些数字不算庞大的商业系统但已经足以让一次修改牵动多个位置。比如把固定户型改成独立户型时数据库、上传接口、识别提示、前端状态和 3D 几何要一起变化后来处理“浏览器打开没有数据”又涉及启动端口、环境配置、样例项目选择和生产服务。再到 3D 独立页面、光影调整和字号优化模型需要一直记得前面留下的约束。这正是 1M 上下文和长程任务能力在本项目里的用处。它不需要每次从零理解工程可以沿着已有代码继续改并在修改后补测试、重新构建、打开浏览器检查。我还让 Doubao-Seed-Evolving 对主要源码做了一轮独立审查。34.7 秒后它给出 6 条带文件路径的建议。我逐条检查采纳了过滤无效向量、加强上传前校验、将自动识别户型标为“待确认”这 3 条另外 3 条与代码现状不符没有硬改。这个结果反而让我放心模型的建议可以快但是否成立仍然要回到代码和运行结果。工程目前有 8 个测试文件20 项测试全部通过生产构建也通过。3D 场景实际生成了 24 件家具、8 个水电对象和 18 个门窗洞合计 50 个空间对象。浏览器检查中桌面画布采样到 1,378 种颜色模拟旋转后有 36.02% 的像素发生变化家具、电气和给排水图层分别关闭时画面也出现对应变化。它确实在实时渲染不是一张预先准备好的效果图。移动端也跑了同样的检查。对象详情面板、工具按钮和房间标签不会挤在一起资料库、证据抽屉、有来源回答、拒答状态和定位点持久化都走过了浏览器流程。写在后面这次做“栖居档案”我原本只是想解决一个很小的问题下次在墙上打孔之前别再对着几百张照片发愁。做着做着它变成了一套完整产品。每套房有自己的户型家具和水电点位能在 3D 空间里查看零散资料能被整理成带来源的事实找不到答案时也会停下来。Doubao-Seed-Evolving 全程参与了系统从需求到可运行版本的开发又在产品里继续承担资料理解、检索和问答。Coding、Agent 检索、长上下文和幻觉控制这些能力我没有单独做几道题去测而是让它们一起经受一个具体需求的反复修改。房子住得越久维修、替换和改造记录只会越来越多。以后再换净水器、加插座或者重新刷墙我希望打开这本说明书就能知道哪里有依据哪里还得回到现场确认。