不想每次都从头解释：我用 Doubao-Seed-Evolving 做了一个「稿件接力站」

项目放了两天，再打开目录时，文件其实都还在。

几张活动截图、几张配置截图、一份文章草稿、一些临时记录，还有一个上次随手写下的交接文档。问题是，文件在，不代表上下文还在。

我知道上次做到哪了，大概。但「大概」对写作和开发都不够用。哪张截图对应哪个结论？哪条配置已经验证过？哪一段只是活动示例，不能写成本人已经实现的功能？哪个地方有 API Key、账户信息或者个人路径，发布前必须遮掉？这些判断分散在文件和聊天记录里，每次继续写，都要重新翻一遍。

如果只是自己一个人慢慢写，多花半小时还能接受。但当我开始用 AI 工具协助写作和开发时，这个问题变得更明显：每开一个新会话，就要重新解释项目背景、资料来源、技术环境、已有结论、隐私边界和下一步计划。交代少了，模型会重复做过的事；交代多了，我又像是在给自己的工作补文档，而不是推进工作。

前两天正好看到豆包的新模型 Doubao-Seed-Evolving ，我决定把这个真实问题交给它，来看看他的实际代码能力如何：做一个本地工具，把写作目录里的截图、文档、代码和测试结果一键整理成一份可以持续更新的上下文交接文档。

我给它起了个名字：稿件接力站。

Doubao-Seed-Evolving是什么来头

Doubao-Seed-Evolving 是火山方舟推出的面向 Coding 和 Agent 场景的新模型。和固定版本模型不同，它强调持续演进，适合放到真实任务里观察：能不能读懂上下文，能不能拆解工程问题，能不能在多轮修改中保持约束，能不能把代码、工具调用、测试和结果串起来。

这类模型真正有价值的测试，不是问一句「你是谁」，也不是让它写一段孤立代码，而是给它一个带边界的任务：

• 目录里既有 Markdown，也有图片、配置截图和代码。
• 原始文件不能移动、删除或覆盖。
• 结论必须能追溯到来源文件。
• 涉及 API Key、Token、手机号、邮箱、个人绝对路径时要先拦截。
• 二次运行时要识别新增、修改和删除，而不是每次从头生成一遍。
• 最终输出不能直接覆盖正式文档，必须先给用户预览确认。

这不是一个很炫的需求，但它很适合测试 Agent。因为它要求模型做的不是单点能力，而是一整条链路：理解需求、设计模块、写代码、跑测试、根据真实反馈继续优化，最后把结果做成可以持续使用的工具。

先把模型接入 Claude Code

我使用火山方舟的 Agent Plan，把 Doubao-Seed-Evolving 接入 Claude Code。接入前，我先在 Agent Plan 页面确认服务已经开通，并在模型列表里确认可以使用 doubao-seed-evolving。

这里有两个关键配置：

• Base URL 使用火山官方提供的 Anthropic 兼容链路。
• 模型名使用 doubao-seed-evolving。

我这次验证了两种接入方式：手动配置和通过 CC Switch 配置。

手动配置时，可以在 Claude Code 的 settings.json 里写入环境变量。下面只保留结构：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://ark.cn-beijing.volces.com/api/plan",
    "ANTHROPIC_AUTH_TOKEN": "你的 Token",
    "ANTHROPIC_MODEL": "doubao-seed-evolving"
  }
}

另一种方式是用 CC Switch 新增 Claude 配置。协议选择 Anthropic Messages，Base URL 填入同一条官方兼容链路，认证字段使用 ANTHROPIC_AUTH_TOKEN，模型名填 doubao-seed-evolving。这种方式的好处是切换直观，不需要频繁改配置文件。

配置完成后，确认 Claude Code 状态栏里显示的模型名，并让它开始处理当前目录里的真实需求文档。

我给它的真实任务

我希望它实现一个本地工具，目标很明确：

扫描一个写作资料目录，把 Markdown、TXT、JSON、Python 文件和图片资料整理成结构化索引，再生成一份可以持续更新的 写作上下文交接.md。

这个工具的边界也很明确：

• 原始目录默认只读，不移动、不删除、不重命名原文件。
• 程序负责文件 manifest、哈希、增量比较、敏感信息初筛、状态保存和版本备份。
• 模型负责理解内容、归类事实、提炼推测、识别待验证事项、绑定来源文件。
• 输出前由程序校验来源字段是否有效。
• 用户确认前，不覆盖正式交接文档。

最终我要求它保留两种使用方式：一套本地 Web 界面，方便我在浏览器里选择目录、查看结果；同时保留 CLI，方便自动化测试。

这个需求不是一次性抛给模型然后等结果。我在 Claude Code 里先让它阅读当前目录，理解已有文档和截图，再进入计划模式，给出实现方案，然后分阶段动手写代码。

从计划到代码：它开始把工具搭起来

真正进入开发后，Seed Evolving 没有只写一个大文件糊住功能，而是把项目拆成了几个相对清晰的模块。

从开发过程里可以看到，它先建立了项目结构，然后开始写核心模块：

• core/scanner.py：负责目录扫描、文件类型识别、哈希计算和 manifest。
• core/sensitive.py：负责 API Key、Token、手机号、邮箱、Windows 绝对路径等敏感信息检测。
• core/analyzer.py：负责调用模型接口，把文本和图片内容交给模型分析。
• core/generator.py：负责把结构化结果生成 Markdown 交接文档。
• web/server.py：负责提供 Web 接口。
• main.py：负责 CLI 入口、Web 启动和测试模式。

三段代码，看它如何把需求落到工程实现

比起只看 Claude Code 不断创建文件，核心代码更能说明模型怎样把需求落到实际工程中。我从项目里选了三段有代表性的实现。它们不复杂，但分别对应了这个工具最重要的三个约束：增量处理、图片输入和事实来源校验。以下代码均来自实际项目，展示时省略了部分类型标注和异常处理。

第一段是增量扫描。 程序不会只比较修改时间，而是为文件计算 SHA-256 哈希，再对新旧 manifest 做集合比较：

def compare_manifests(old_manifest, new_manifest):
    old_paths = set(old_manifest.keys())
    new_paths = set(new_manifest.keys())

    added = list(new_paths - old_paths)
    deleted = list(old_paths - new_paths)

    modified, unchanged = [], []
    for path in old_paths & new_paths:
        if old_manifest[path]["content_hash"] != new_manifest[path]["content_hash"]:
            modified.append(path)
        else:
            unchanged.append(path)

    return sorted(added), sorted(modified), sorted(deleted), sorted(unchanged)

这段代码对应界面里的「新增、修改、删除」统计。它说明模型没有把增量更新理解成一句产品文案，而是落实成了可测试的数据结构和比较逻辑。

第二段是图片进入模型的方式。 图片先以二进制读取并转成 Base64，再按照多模态消息格式加入请求：

base64_data = base64.b64encode(img_data).decode("utf-8")
file_data = {
    "type": "image",
    "path": rel_path,
    "base64": base64_data,
    "mime_type": mime_type,
}

user_content.append({
    "type": "image_url",
    "image_url": {
        "url": f"data:{file_data['mime_type']};base64,{file_data['base64']}"
    }
})

项目里还设置了单文件 100 KB、总文本内容 200 KB 的限制，避免不加控制地把整个目录塞进一次请求。相比只写一句「支持多模态」，这段实现更能说明图片是怎样真正进入分析链路的。

第三段是来源校验。 除了在提示词中要求模型为事实标注来源，程序还会检查 source 是否真的存在于本次允许分析的文件列表里：

valid_sources_set = set(valid_sources)

for fact in result.get("confirmed_facts", []):
    if not isinstance(fact, dict):
        continue
    if "content" not in fact or "source" not in fact:
        continue
    if fact["source"] in valid_sources_set:
        validated["confirmed_facts"].append({
            "content": str(fact["content"]),
            "source": fact["source"],
        })

这段代码是整个工具里我很喜欢的一处设计：让模型负责理解，让程序负责验证，形成两层保障。只有能够匹配真实文件路径的结果才会进入交接文档，这比单纯追求「生成得像不像」更接近真实工程。

我比较在意的一点是，它很早就把安全边界纳入了整体设计。敏感信息检测在项目搭建阶段就被拆成了独立模块。正则规则覆盖了常见的 API Key、Token、手机号、邮箱和 Windows 绝对路径。对写作素材整理工具来说，这一点很重要，因为截图和配置文档里经常会混入不适合公开的内容。

工具跑起来了

开发完成后，Claude Code 里启动了 Web 服务：

python main.py --web --port 8005

服务正常启动在 8005 端口，CLI、Web 和测试入口也都保留下来。截图里记录了这轮实现完成后的功能清单：

• 支持 Web 界面和 CLI 命令行两种使用方式。
• 支持增量扫描，通过文件哈希识别新增、修改和删除。
• 支持敏感信息检测，命中规则的文件可以跳过，不传给模型。
• 支持 Markdown、TXT、JSON、Python 和 PNG/JPG/JPEG 图片。
• 支持通过模型接口生成结构化分析结果。
• 校验模型返回结果中的来源路径是否有效。
• 保存新交接文档前自动备份旧版本。
• 提供模拟模式，不配置 API 也能测试全流程。

开发完成时，Claude Code 显示 7 个测试用例全部通过。为了确认截图之外的项目状态，我又在本机执行了一次 python -m pytest tests -q，结果是 7 passed in 0.23s。测试覆盖了目录扫描、文件哈希、增删改判断、敏感文件拦截、Markdown 生成，以及旧交接文档自动备份。Claude Code 界面里记录的本轮开发耗时约 5 分 13 秒。这个时间不能简单等同于完整项目成本，因为前面还有需求整理和人工判断，但它能说明一点：在需求边界清楚时，Seed Evolving 推进这种小工具的速度很快。

从「能跑」到「更稳」：把真实反馈变成工程能力

第一版完成后，目录扫描、敏感信息识别和交接文档生成流程已经可以运行。接下来我关闭模拟数据，开始用 Doubao-Seed-Evolving 对真实目录进行分析。

这次输入不再是一两个示例文件，而是一个包含 28 个文档、代码文件和图片的实际项目目录。扫描阶段顺利完成，并准确列出了 4 个发生修改的文件；进入模型分析阶段后，界面提示 The read operation timed out。

这个反馈反而让项目进入了更有价值的一轮迭代。因为它对应的不是简单页面效果，而是 Agent 在真实资料目录中必须处理的问题：多种文件格式要统一读取，图片要转换成多模态消息，文本和图片的输入规模要受控，长请求还要有明确的超时策略。

我把这次运行结果继续交给 Seed Evolving。它很快把反馈落实成了几项工程优化：

• 为单个文件设置 100 KB 的处理上限，超出范围的文件不进入本轮请求。
• 为文本内容设置 200 KB 的总预算，主动控制单次请求规模。
• 为连接建立和完整分析分别设置超时时间，给多文件任务留出足够的处理窗口。
• 针对连接状态、请求时长、接口返回和 JSON 解析提供分类清晰的提示信息。
• 保留结构化结果和来源路径校验，让优化后的链路仍然遵守最初约束。

我比较喜欢这一轮的地方，是 Seed Evolving 没有把反馈处理成一次性的补丁，而是顺着「文件读取、输入构造、模型请求、结果解析」这条链路补齐了保护措施。最终版本不仅完成了真实模型调用，也成功生成了带来源引用的交接文档预览。

这比一次生成出看似完整的代码更能体现 Evolving 的价值：任务在运行中出现新的边界后，它还能继续理解上下文，在原有架构上完成针对性迭代。

成果展示：稿件接力站

最终 Web 界面很简单。顶部输入写作工作目录路径，然后点击「扫描目录」。工具会读取目录下支持的文件，生成扫描结果。

在我的测试目录里，它识别到：

• 总文件数：31
• 新增文件：3
• 修改文件：5
• 删除文件：0

下面还列出了待分析文件，包括 .claude/settings.local.json、README.md、核心代码文件和多张交流截图。

模型配置也放在 Web 界面里。API 密钥以掩码展示，模型名使用 doubao-seed-evolving。这里的设计重点不是把密钥持久化保存，而是让当前会话可以完成一次分析测试。页面里也明确提示：配置只在当前会话生效，不会上传或持久化存储。

点击「分析内容生成预览」后，工具会生成交接文档预览。这个预览不是简单摘要，而是按来源组织内容。

可以看到，它把代码模块、测试数据、Web 服务、CLI 参数、模型配置、迭代过程和扫描结果等内容整理成条目，并在每条后面标注来源文件。例如：

• 目录扫描模块来自 core/scanner.py。
• 模型调用模块来自 core/analyzer.py。
• Markdown 生成来自 core/generator.py。
• Web 接口来自 web/server.py。
• CLI 参数来自 main.py。
• 中间迭代和运行结果来自对应的交流截图。

这正是我做这个工具想要的效果：不是替我写结论，而是把散落的信息整理成「可以继续工作的上下文」。

我对 Doubao-Seed-Evolving 的结论

这次实测让我印象最深的，不只是 Seed Evolving 生成代码的速度，而是它能把一个真实需求持续推进到可用状态。

• 能处理完整的 Agent 开发链路。 它可以阅读目录、理解约束、拆分模块、编写代码、调用工具并运行测试，不只是完成一次性的代码问答。
• 能根据真实反馈继续迭代。 面对多文件和图片分析带来的输入规模问题，它继续补充了文件限制、内容预算、超时管理和异常提示，并在原有架构上完成优化。
• 能把多模态理解落进可靠流程。 图片和文本可以共同进入分析，生成的事实会绑定来源，再经过敏感信息检测、路径校验和预览确认，最终形成可追溯的交接文档。

从散乱素材到能够实际运行的「稿件接力站」，Doubao-Seed-Evolving 展现出的核心优势，是复杂上下文理解、长任务持续推进和工程化迭代能力。对于需要多轮协作的 Coding 与 Agent 场景，这种把任务真正做完的能力，比单次生成一段代码更有价值。