DeepSeek版“Claude Code”出现：deepseek-builder把AI编程推进到项目级自主执行

最近，一个名为 **deepseek-builder** 的开源 CLI 工具开始受到开发者关注。

它并不是 DeepSeek 官方推出的产品，而是由第三方开发者维护的开源项目。项目当前托管在 GitHub 的 `cynchro/deepseekCLI` 仓库，并以 `deepseek-builder` 的名称发布到 Python 生态。

它试图解决一个越来越重要的问题：

**如果大模型已经能够理解代码、调用工具和进行长链路推理，开发者为什么还要逐个文件告诉 AI 应该修改什么？**

deepseek-builder 给出的答案，是把 DeepSeek 直接放进终端，让模型自己读取项目、搜索代码、修改文件、运行命令、执行测试，并根据测试结果继续修复。

换句话说，AI 编程正在从：

**“帮我写代码”**

进一步走向：

**“帮我完成这个开发任务。”**

从代码补全，到真正的 Coding Agent

图片

过去十年，AI 编程工具经历了明显的能力迁移。

第一阶段解决的是“下一行代码写什么”。

GitHub Copilot 等工具让开发者第一次大规模体验到 AI 代码补全，但核心工作流仍然是：

**人负责架构和任务拆解，AI负责局部代码生成。**

随后，随着大模型上下文窗口、推理能力以及 Tool Calling 能力提升，AI 编程开始进入第二阶段。

模型不再只读取当前文件，而是开始理解整个代码仓库，并能够执行：

**读取代码 → 搜索项目 → 修改文件 → 运行测试 → 查看报错 → 再次修改**

这样的循环。

deepseek-builder 正属于这一代工具。

它在项目 README 中直接将自己定位为一种类似 Claude Code 的终端编程 Agent：用户使用自然语言描述任务，Agent 则通过工具实际操作代码项目。

这意味着 AI 的角色已经从“代码生成器”逐渐变成“任务执行者”。

它到底是怎么工作的？

deepseek-builder 当前的核心已经不是简单的一次性 Prompt，而是一个持续运行的 **Agent Loop**。

当开发者输入：

> 给这个 FastAPI 项目增加一个 `/health` 接口，并补充测试。

Agent 首先会读取项目目录和相关代码。

随后搜索可能涉及的模块，理解现有代码结构和编码习惯。

确定修改方案之后，它调用文件工具写入或编辑代码。

代码修改完成后，再调用 Shell 执行测试、Lint 或程序本身。

如果测试失败，错误信息会重新进入模型上下文。

模型分析错误，再修改代码。

直到任务完成。

因此它真正形成的是：

**理解 → 操作 → 验证 → 反馈 → 再操作**

这样的闭环。

这与传统“一次 Prompt 生成一堆代码”的方式存在本质区别。

一个值得关注的设计：DeepSeek V4 Pro + Flash 分工

当前版本还采用了模型分层策略。

复杂的任务规划、核心代码编写、代码审查和验证主要交给 **DeepSeek V4 Pro**。

而大量低风险、高 Token 消耗的工作，例如：

代码阅读、项目摘要、上下文压缩以及部分机械化代码生成，则可以交给成本更低的 **DeepSeek V4 Flash**。

这实际上体现了 AI Agent 一个越来越明显的发展趋势：

**并不是所有任务都需要最强模型。**

未来成熟的 Coding Agent 更可能采用“强模型负责决策，快速模型负责执行和整理”的分层架构，以降低整个 Agent Loop 的运行成本。

不只是生成代码，它已经开始理解整个项目

图片

deepseek-builder 提供了一组面向代码仓库的工具。

包括文件读取、目录扫描、Glob、Grep、代码搜索、文件写入、局部编辑和 Shell 命令执行。

其中值得注意的是 `search_code`。

它可以使用本地 BM25 索引寻找与问题最相关的代码位置；安装额外组件后，还可以加入本地 Embedding，实现语义搜索。

因此开发者不必告诉模型：

> 打开 `src/auth/service.py` 第 143 行。

而可以直接说：

> 找一下项目里用户登录 Token 是在哪里生成的，把过期时间改成可配置。

Agent 自己寻找相关代码。

这正是 Coding Agent 与传统代码生成器之间非常关键的区别。

DEEP.md：让AI逐渐“认识”一个项目

另一个值得关注的设计是 `DEEP.md`。

开发者可以执行 `/init`，让 Agent 自动扫描项目，并生成包含技术栈、目录结构、运行方式、测试方法以及项目规范等信息的上下文文件。

此后 Agent 每次进入项目，都可以读取这些规则。

它的定位类似 Claude Code 中的 `CLAUDE.md`。

此外，项目仍然支持 `.deeprules`。

开发者可以写入：

> Python 必须使用 type hints> 测试统一放入 tests/> 不允许未经确认增加第三方依赖

这些规则会进入 Agent 的上下文。

因此未来 AI 编程一个很重要的变化可能是：

**项目不仅拥有 README，也开始拥有专门写给 AI Agent 阅读的“项目说明书”。**

更大的变化：AI开始能够连续工作数小时甚至数天

当前 deepseek-builder 还加入了一个很有意思的功能：

`deep autobuild`

它面向的已经不是一次几十秒的代码生成，而是持续数小时甚至数天的大型开发任务。

开发者可以准备一个任务 backlog。

Agent 每完成一轮工作，就重新检查还有哪些任务没有完成。

如果还有任务，则启动下一轮。

运行状态会保存到 `.deep/autobuild_state.json`，因此即使终端中断或机器重启，也可以继续之前的工作。

项目还加入了“停滞检测”机制：

如果连续多轮没有产生新的 Git Commit，可以自动停止，避免 Agent 陷入循环持续消耗 API Token。

这意味着 Coding Agent 正在从：

**一次对话**

转向：

**持续运行的软件工程进程。**

手机也可以接管AI编程任务

图片

deepseek-builder 还有一个容易被忽略、但非常有意思的方向。

它支持：

`deep serve –https`

在电脑上启动 Web/PWA 界面。

配合 Tailscale，开发者可以从手机访问运行在自己电脑上的 Coding Agent，而不需要直接把开发环境暴露到公网。

更进一步，当前版本已经支持同一个 Agent Session 同时连接终端和手机。

例如：

开发者在电脑上启动一个大型重构任务。

离开电脑之后，可以从手机查看 Agent 正在读取哪些文件、执行哪些命令以及测试是否通过。

如果 Agent 请求文件写入或命令执行权限，也可以直接在手机上确认。

这已经开始接近：

**“随身携带的软件开发 Agent”。**

但它距离“自动开发软件”仍然很远

这种工具最容易产生的误解，是把“能够自主调用工具”理解成“能够自主完成软件工程”。

两者并不是一回事。

AI 可以执行：

**读代码 → 写代码 → 跑测试 → 修 Bug**

并不意味着它真正理解所有业务需求。

测试通过，也不代表软件没有逻辑漏洞、安全问题、性能问题或者架构债务。

尤其需要注意的是，Coding Agent 拥有的权限远高于普通聊天机器人。

它可能拥有：

**文件写入权限、Shell 执行权限、依赖安装权限，甚至浏览器控制能力。**

因此权限设计反而成为这类工具最重要的安全边界之一。

deepseek-builder 当前提供 `ask`、`auto`、`plan` 和 `yolo` 四种权限模式。

其中 `plan` 模式只允许 AI 阅读和分析项目，在用户批准方案之前不能修改文件或执行具有副作用的操作。

而 `yolo` 则允许 Agent 自动执行操作。

对于真实生产项目，显然不应该把最高权限模式当成默认选择。

一个细节说明它仍然处于早期阶段

截至目前，该项目仍然是一个规模很小的开源项目。

GitHub 页面显示的社区规模还非常有限，项目元数据也将其标记为 **Beta**。

因此现在更合适的定位不是：

**“新的成熟 AI IDE 出现了。”**

而是：

**“DeepSeek 生态开始出现真正面向 Agentic Coding 的开发工具。”**

它更值得关注的是方向，而不是当前市场规模。

谁最值得尝试？

现阶段最适合尝试这类工具的，是已经具备一定开发能力、同时希望提高原型开发速度的人。

例如独立开发者可以快速构建 MVP；全栈开发者可以让 Agent 完成重复性 CRUD、测试和重构工作；小团队可以把部分明确、可验证的开发任务交给 Agent。

对于学生和初学者，它同样可以降低进入真实代码仓库的门槛。

但这里存在一个悖论：

**越是不懂代码的人，越容易感受到 AI 编程的便利；但越是不懂代码，也越难判断 AI 写出来的东西到底有没有问题。**

所以“自然语言编程”降低的是代码生成门槛，却没有消除软件工程判断能力的重要性。

真正值得关注的不是deepseek-builder，而是“描述即执行”

deepseek-builder 本身可能最终成为一个热门项目，也可能只是快速变化的 AI Coding Agent 生态中的一个实验。

真正值得关注的是它背后的趋势。

软件开发的人机分工正在发生变化：

过去是：

**需求 → 人设计 → 人编码 → AI辅助**

现在正在变成：

**需求 → AI规划 → AI修改 → AI测试 → 人审核**

下一阶段可能进一步演变成：

**目标 → Agent持续执行 → 人处理关键决策和验收**

届时，开发者真正稀缺的能力可能不再只是“能不能把代码写出来”。

而是：

**能不能把需求描述清楚，能不能设计合理的系统边界，能不能建立可靠的测试和验收标准，以及能不能判断 AI 的结果到底值不值得上线。**

这可能才是 deepseek-builder 这类工具真正值得关注的地方。

它展示的不是“DeepSeek 又多了一个 CLI”。

而是一种正在快速成形的软件开发模式：

**从 Code Completion，走向 Agentic Software Engineering。**