![86d745fb3428f5dcce99d225090904b5.png](https://developer.qcloudimg.com/http-save/yehe-11396077/ee89eabaa0df1e7f9333bc35cbfbd2bb.png)



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

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

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

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

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

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


## Doubao-Seed-Evolving是什么来头

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

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

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

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



## 先把模型接入 Claude Code

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

![95ef372242e4eea82a8bc815fca9ff45.png](https://developer.qcloudimg.com/http-save/yehe-11396077/6851466f9385e5a5bc16cc29c9072b3b.png)


![Agent Plan订阅配置2.png](https://developer.qcloudimg.com/http-save/yehe-11396077/f8ab3b0cff19e66f1c0c05c4b73ecc29.png)


这里有两个关键配置：

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

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

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

```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`。这种方式的好处是切换直观，不需要频繁改配置文件。

![CC Switch配置.png](https://developer.qcloudimg.com/http-save/yehe-11396077/871fd82336b78c396f800a8c49bfca0f.png)


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

![Claude code连接测试.png](https://developer.qcloudimg.com/http-save/yehe-11396077/6fbb030cb7cc8f806cf7d648b0f8e954.png)


## 我给它的真实任务

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

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

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

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

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

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

![开始开发.png](https://developer.qcloudimg.com/http-save/yehe-11396077/6688d5a7d1cb7e933fb4604d37b2f033.png)


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

真正进入开发后，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 启动和测试模式。

![开发过程.png](https://developer.qcloudimg.com/http-save/yehe-11396077/e2a99dba7653b9c10a2520928a058dda.png)


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

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

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

```python
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，再按照多模态消息格式加入请求：

```python
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` 是否真的存在于本次允许分析的文件列表里：

```python
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 服务：

```bash
python main.py --web --port 8005
```

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

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



![开发完成.png](https://developer.qcloudimg.com/http-save/yehe-11396077/362174ea3400e30886676ba208e8366a.png)

开发完成时，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`。

![中间迭代.png](https://developer.qcloudimg.com/http-save/yehe-11396077/569381661e5dab14ad945269d30bd6d7.png)


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

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

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

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

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



## 成果展示：稿件接力站

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

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

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

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

![成功展示1.png](https://developer.qcloudimg.com/http-save/yehe-11396077/632249dd40e83fae073b80fd2f00e87f.png)


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

![成功展示2 模型配置.png](https://developer.qcloudimg.com/http-save/yehe-11396077/3ca60f78241220f1086260f1771eea5b.png)


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

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

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

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

![成功展示3 分析.png](https://developer.qcloudimg.com/http-save/yehe-11396077/1b601dc028276904c9a4f0f86ef93bdc.png)


## 我对 Doubao-Seed-Evolving 的结论

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

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

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


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

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

前两天正好看到豆包的新模型 Doubao-Seed-Evolving ，我决定把这个真实问题交给它，来看看他的实际代码能力如何

人工智能

开发工具

后端

探索AI工具Doubao-Seed-Evolving如何解决写作开发中的上下文丢失问题。通过构建"稿件接力站"工具，实现自动整理项目文件、识别敏感信息、生成结构化交接文档。测试显示该工具能有效处理多格式文件、增量更新和来源校验，提升协作效率。

数据结构

代码解释

Windows

Python

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

不想每次都从头解释：我用 Doubao-Seed-Evolving 做了一个「稿件接力站」-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐