当时我的第一反应是骂 AI 傻。但冷静下来想,这其实是所有 AI 编程工具的共性问题:agent 不知道代码被手改过,它只知道自己上次写的是什么。你让它再改一次,它拿着旧快照就把你的修改覆盖了。
v0.1.26 修的就是这件事。

一个使用场景让我发现
说实话,这个问题在「纯 AI 写代码」的场景下不太突出——如果整段代码都是 agent 生成并写入的,手动修改发生在保存后,agent 确实无从感知。
但当你同时使用 AI 和手动编辑时,冲突是必然的。比如你用 agent 写了文件主体,自己去调 CSS、修 import 路径、补类型声明——这些都是很常规的操作。然后下一条 prompt 让 agent「在这个文件里加个函数」,你期待的只是加函数,但 agent 打开文件时可能做了更多事。
v0.1.26 的做法是:用快照机制检测到手动修改后,自动追加一条 system prompt 告诉 LLM「这个文件被手改过,不要无脑覆盖」。 不是禁止 LLM 碰其他代码,而是提示它——你的 plan 需要把已有修改考虑进去。
这个设计的关键判断在于:它没选择「加锁」或「冲突检测」,而是通过 system prompt 把修改信息传递给 LLM,让 LLM 自己决定怎么处理。好处是灵活——LLM 的策略比固定规则更适应上下文。缺点是依赖 LLM 的指令跟随能力——如果模型不够聪明,看完 system prompt 还是会覆盖。
对于 DeepCode 这类前端 AI CLI 工具来说,这个选择可以理解。因为 DeepCode 本身就假设了模型是强模型(Codex / Claude 级别),instruction following 不是瓶颈。
编辑工具增强:empty old_string 的哲学
另一个值得展开的是 Edit 工具的 empty old_string 支持。之前 Edit 工具要求 old_string 不能为空——也就是说,你必须指定「把 A 替换成 B」。但有些场景下你想做的是「插入一段代码」,而不是替换。
新版本支持了空 old_string 的替换,加上 full-file 支持和强制 snippet_id。具体来说,如果你传了空 old_string,Edit 认为你想做的是「在指定位置插入代码」而不是「替换现有内容」。snippet 处理的增强则在多文件批量修改时更可靠——之前 snippets 之间的拼接偶尔会产生重复或遗漏,现在系统会强制使用 snippet_id 来保证每个文本段落的唯一性。
/undo 恢复快照的问题也修了
同样是快照机制的问题:之前 /undo 恢复快照时,在某些条件下会跳过关键状态——比如在文件被 LLM 写了一半时取消,快照状态和实际文件状态不一致。修复后 /undo 的恢复路径更加完整了。
这个修复和上面 agent+manual 混合编辑优化是同一根线上的珠子:快照机制是 DeepCode 整个编辑流程的底层,修好它才能修好其他依赖快照的功能。
顺便提的:会话内存泄漏修复
fix(session) 修复了会话清理的内存泄漏。这个可能不太起眼,但对长时间运行的 DeepCode 进程来说影响不小。如果你开一个会话连用一整天(比如在 CI 环境或长期追踪的修复任务里),会话对象之间的循环引用导致 GC 无法回收,内存占用会逐渐增长到几百 MB。回归测试也补上了。
另外 Ink 依赖更新到了 7.0.4——这是 DeepCode 的终端渲染引擎,版本对齐主要是为了后续功能(比如更稳定的终端渲染和键盘事件处理)铺路。
关于遥测
v0.1.26 还把遥测模块提取成了独立模块,并加入了开关。这个说大不大、说小不小。之前遥测逻辑散落在各个 handler 里,想关也不能直接关——重构抽离后,enable/disable 是一个明确的 toggle。对于企业用户来说,这个改动可能比功能更新更重要。
npm update -g @vegamo/deepcode-cli
或全新安装:
npm install -g @vegamo/deepcode-cli
完整更新日志:GitHub Release
📢 关注我,获取最新开源更新日志和开发者工具动态。如果觉得这篇文章有用,欢迎转发给身边的开发者朋友。
#DeepCode #AI编程 #CLI工具 #开源 #编辑增强