Datawhale干货 

作者：筱可，Datawhale成员

我有一个维护中的开源项目 HearSight——一个基于 AI 的视频辅助阅读工具：https://github.com/li-xiu-qi/HearSight。

最近项目新的需求是：希望支持多源内容导入——不仅仅是 Bilibili，还要能从小宇宙播客、YouTube 等平台导入内容。

这类改造虽然代码不复杂，但涉及前后端多模块协同，任何一次改动都必须同时协调两端。如果其中一端实现有误，测试和回溯的成本就会比较高。这种信息量大、系统复杂，人脑无法同时 hold 住所有上下文的情况就很适合使用AI来协助编程。

所以我用了火山引擎新发布的豆包编程模型 Doubao-Seed-Code，主打 Agentic Coding 优化，并提供 256K 的原生长上下文，契合我这种复杂、跨文件的修改任务。

从公开测评结果来看，在Terminal Bench、SWE-Bench-Verified-Openhands、Multi-SWE-Bench-Flash-Openhands等主流测评集中，Doubao-Seed-Code 表现出色，仅次于Claude Sonnet 4.5。

我使用火山引擎的 veCLI 终端搭配 Doubao-Seed-Code 模型进行了本次重构。

第一步：目标确认

原系统需要先打开网页随便选一个小宇宙的播客链接，输入进 HearSight 的输入框，然后提交到后端，我们可以看到前端这边开始的时候是只能支持 bilibili 的视频链接进行导入，我们没法输出小宇宙播客链接的内容提交到后端里面。所以改造目标很明确：

后端： 重构媒体文件下载功能，支持小宇宙、Bilibili 和 YouTube。

前端： 修改链接提交逻辑，放开对小宇宙、Bilibili 和 YouTube 链接的限制。

第二步：结果验证

经过与 Doubao-Seed-Code 的多轮协作和代码修改后，HearSight 成功实现了对小宇宙播客链接的导入。前端能正常显示进度条，整个流程与旧系统效果几乎一致。

之前很多朋友在谈论到 AI 编程的时候就经常说 AI 一天天的尽给我们搞破坏，写着写着原有功能就没了，更糟糕的事，新的功能也没实现。

说实话我自己就遇到过挺多次类似的情况，万幸的是我一般都会有使用git commit保存最新的版本，方便我回滚项目功能，并重新进行开发。

这次的 AI 辅助开发过程中，令我感到比较惊喜的是 ，Doubao-Seed-Code 没有将原有的已有功能破坏。小到下载的进度条返回，大到文稿的转换和总结功能，在集成新代码后全部保持了正常的运行状态。

本次重构的成功，很大程度上得益于 Doubao-Seed-Code 的长上下文能力，以及一套我自己沉淀下来的行之有效的 AI 编程协作方法论——即遵循“阅读先行，编辑授权”的核心原则。

第一步：阅读先行——用对话式讨论进行上下文构建

在启动任务时，我采取了对话式讨论的策略，没有直接给出修改指令，而是先让模型阅读相关的后端文件，并询问它们之间的差异，来逐步建立有效的上下文：

即使模型的第一次回答不够精准，第二次重新补充信息之后立马就能表达出来我所想要表达的意思，模型也能迅速矫正，立马理解了任务的核心意图。

这里可以看出 Doubao-Seed-Code 在指令遵循方面的能力做的不错，对于表达能力稍微欠缺的小伙伴，会挺有帮助。

我还发现在这个文件阅读的过程中，Doubao-Seed-Code 的 Agentic 能力有不错的表现，主要体现在主动感知与文件反哺方面。

举个例子，当接收并分析完我提供的目标文件后，Doubao-Seed-Code 主动发现了另一个与本次任务高度相关的文件——即负责封装下载服务的进度条功能文件download_service.py。

估计是 Doubao-Seed-Code 能够通过文件名关联或模块导入关系，顺藤摸瓜找到完整的代码执行路径，避免了由于人工遗漏相关文件而导致的上下文残缺，确保后续代码修改操作的完整性和可行性。

Doubao-Seed-Code 读取了py文件之后，又找到了几个相关的文件，考虑到当前仍有宽裕的上下文空间，我选择继续让它加载这些相关文件，可以让它继续了解相关的信息方便他进行进一步的代码编辑。

通过多次提供上下文相关文件内容，我们已成功地让 Doubao-Seed-Code 掌握了文件下载的后端链路信息。此时我发现，模型在读取完了后端所有需要修改的文件内容后，还提到想要进一步了解前端的内容。

不过我觉得可以先不用让 Doubao-Seed-Code 读取前端的内容，虽然Doubao-Seed-Code 具有256k的上下文，对比其他的128k上下文的模型已经多出了一倍，但是过于多的相关信息，会导致信息密度降低，从而导致系统的重构出现意外。只有有效的代码信息进入上下文，才能避免不必要的信息污染。

我必须尽量保证 Doubao-Seed-Code 重构后端的成功率，那么上下文信息提供到这里，就可以进一步让 Doubao-Seed-Code 开始对代码进行编辑了。

第二步：编辑授权——开发者审核策略，AI 执行

在上下文建立完毕后，就进入了授权编辑的阶段。在开始编辑之前，我提供了详细的编程偏好说明，并要求模型先列出修改计划（TODO List）进行审核。这属于 AI 编程中的中间授权层级，即开发者审核策略，AI 执行。

为什么我会先让 Doubao-Seed-Code 生成计划大纲，审核之后才决定是否允许它进行编辑呢？

这其实可以用管理学中的授权层次来解释：

最低层次：员工只带着问题来找你，等着你给出策略，他只负责执行。

中间层次：员工不仅提出问题，还带上几套解决方案，由你判断哪一种可行。这已经体现出主动性与思考力。

最高层次：你只需告知目标，员工便能独立完成，甚至无需汇报过程。

在 AI 编程场景中，我给予 AI 的正是中间层级授权。因为就纯编程能力而言，AI 已经非常强大；但结合具体项目背景，它仍然不及我们人类全面。当然，如果控制AI的人本身不懂相关的技术，那么可能只能选择最高层级授权了，疑 AI 不用，用 AI 不疑。

正式进入编辑阶段后，模型始终清晰地记着我的要求，包括“单个文件的代码量不要超过 300 行”等代码规范偏好。

这在多轮复杂的后端开发任务中十分难得。得益于Doubao-Seed-Code 有着 256K 的长上下文，它能够持续保持这种细节化的规范记忆，减少 AI 在开发中“写着写着就忘记了规范”的常见问题。

在前端文件修改中，Doubao-Seed-Code 展现出更高的自动化与整体思维：不会“改一处，思考一下，再改下一处”，而是表现出像 Cursor 或 Copilot 这类深度集成工具的特点——能一次性编辑多个文件中的多个位置，然后统一汇报结果。

在我以往的测试中，不少模型在终端接入时的执行方式是串行且割裂的。相比之下，Doubao-Seed-Code 的修改行为会更加连贯高效——能一次性完成多处同步修改，有时候甚至能一次修改五处内容。这种高效率的批处理式的编辑能力，正是 Agentic 能力更强的体现，显著提升了跨文件重构的效率。

任务完成了，我习惯性地会复盘一下工具的成本。

我看了下它在火山方舟上的定价，目前开发者有两种选择：

一种是 Coding Plan。Lite 套餐首购首月是 9.9 元，我用的就是这个，点击文末的阅读原文可以查看。

另一种是按量付费的 API 调用。这对用量不固定，或者想集成到自己工具流的开发者来说更加友好。在最常用的 0–32k 区间，输入仅为 1.20 元/百万 Tokens。

这次项目重构中，我一共使用了七百多万 Tokens，调用了 171 次，全都被 Coding Plan 的 Lite 套餐覆盖了，花费差不多一杯瑞幸的价格。

整体体验下来，Doubao-Seed-Code 的 Agentic 规划能力和 256K 超长上下文带来了比较大的帮助。它不再只是一个代码助手，而成为了理解系统结构、能自主规划并验证跨越代码边界修改的 Agentic Coder。

在日常开发中有编程需求的，可以上手体验起来。

附9.9元地址。

阅读原文

跳转微信打开