网易三面:“你看过claude源码，那我问下Code Agent是怎么改代码的？“ 我愣住了，连忙说我只看过上下文压缩和记忆那块，其它的没咋看
前段时间去网易面试，三面的时候面试官看了眼我的简历，说：“你写看过Claude源码，那我问一下——Code Agent是怎么改代码的？”
我当时愣了一下。说实话，我确实看过一些，但主要看的是上下文压缩和记忆管理那块，关于文件编辑的具体机制，我只知道大概有个字符串替换，细节还真没怎么研究过。
我硬着头皮回答：“应该是模型生成一段替换指令，然后工具去执行字符串匹配替换？”
面试官点点头，追问了一句：“那如果文件里有五处一模一样的代码，工具怎么知道改哪一处？”
我想了想，说：“应该是根据上下文来定位吧？”
面试官笑了笑，继续问：“那如果模型看到的文件内容是十轮对话之前的，中间已经被改过了呢？”
这下我真卡住了。我挠了挠头，说：“这个……我没仔细想过。”
面试官没有为难我，只是说了句：“这个细节挺重要的，回去可以看看。”
回来之后我认真研究了一下，发现这个问题比我想的要深得多——它不只是"字符串替换"那么简单，背后涉及到三代方案的演进，还有好几个容易踩坑的边界情况。
今天就把这个说清楚。
◆ ◆ ◆
Code Agent 是怎么"看懂"你的代码并动手改的?
如果你用过 Claude Code 或者 Cursor 这类工具的话呢，大概率是见过这样一种场景的。就是你随口说一句嘛，比如说"把这个函数的错误处理给改一下"，然后呢，过了几秒钟之后，代码就自己改好了。而且改得还挺准的，不多不少，正好就是你想要改的那一小段。
这背后呢，其实藏着一个挺容易被忽略的工程问题。那就是大语言模型本身是不会去"编辑文件"的。模型能做的事情嘛，永远就只是生成一段文本而已。至于说这段文本怎么变成磁盘上面文件的真实改动呢，那就要靠模型外面那一层工具设计了。而这一层设计呢，恰恰就是决定一个 Code Agent 到底好不好用的关键分水岭。
今天就来聊聊这个具体但是很少有人细讲的问题。那就是文件编辑工具，到底应该怎么去设计才好呢。
先想清楚一件事：模型的"眼睛"和"手"是分开的
要理解编辑工具的设计呢，首先得理解一个基本事实。那就是模型和文件之间，是隔着一层工具调用的。模型是看不到文件本身的，它所看到的是工具返回过来的文本。模型也改不了文件本身，它能做的就只是去"告诉"某个工具说"我要这样改"，然后呢由工具去执行。
这就意味着嘛，编辑这件事情就被拆成了两半。
一半是模型这边，需要用某种方式，精确地去表达"我要在哪里、做什么改动"。
另一半是工具这边，需要把这种表达，可靠地翻译成对文件的实际写入。
问题呢，就出在这个"翻译"这个环节上面。模型的表达能力和文件系统的严格性之间，天然就存在着落差。模型是擅长理解语义的，也擅长生成自然语言和代码片段。但是呢，它并不擅长去精确计数行号，也不擅长去追踪字符偏移量这类需要绝对精确的操作。
如果工具设计得不好的话呢，这个落差就会变成大量的编辑失败啊、幻觉啊、误伤无关代码之类的问题。
三种方案的进化史
第一代呢，叫做全文件重写。
最直接的做法就是，让模型看到整个文件，然后输出修改后的整个文件，工具直接覆盖写入就完事了。
这个方案的好处呢，就是简单粗暴，不需要任何"定位"逻辑。但是代价也很明显。如果文件有几百行的话呢，模型只想改一行，却要把整个文件重新生成一遍。这既浪费大量的 token，也拖慢响应速度。而且还多了一层风险，就是生成越长的话呢，中途出错或者被截断的概率就越大。对于现代动辄上千行的代码文件来说，这个方案基本上是不可行的。
第二代呢，叫做 Diff 或者 Patch 格式。
既然全量重写太浪费了，那能不能只描述"改动"本身呢？这就是 diff 方案的思路。模型输出类似 unified diff 的格式，标明在第几行、删除了什么、增加了什么，然后工具负责把这个 patch 给"打"到文件上面去。
这个方案在传统软件工程里面是非常成熟的，Git 本身就是靠 diff 和 patch 来运作的。但是呢，放到 LLM 身上去用的话，就会暴露出一个致命的问题。那就是模型数行号会数错。尤其是文件比较长的时候，或者对话中文件已经被改动过几次之后呢，模型脑子里面的行号和文件实际的行号就很容易对不上了。一旦行号错位的话，patch 应用要么直接失败，要么呢更糟糕，悄悄应用到了错误的位置上面去。
第三代呢，叫做字符串精确匹配替换。
于是呢，业界包括 Claude Code 和 Cursor 在内的主流工具，就逐渐收敛到了目前这个方案。模型不再需要去指定行号了，而是提供两段文本。一段是"文件里原本长这样的一段内容"，另一段是"我要把它换成这样"。然后工具拿着"原文"去文件里面做精确字符串匹配，找到就替换，找不到或者匹配到多处就报错。
这个方案的精妙之处呢，就在于它把"定位"这件事情，从"数数字"变成了"认内容"。模型是不擅长数行号的，但是非常擅长去"复现看到过的一段文字"。这正好就是利用了模型的强项，规避掉了它的弱项。
字符串替换方案里面那些不起眼但是很致命的细节
方案定下来呢，只是第一步而已。真正决定工具好不好用的，是一堆容易被忽略的边界情况。
首先是唯一性问题。如果你告诉工具说"把 return true 换成 return false"，但是呢文件里面有五处 return true 的话，工具应该改哪一处呢？正确答案是都不改，直接报错。让模型带着更多上下文，比如说连同上下几行一起，重新去尝试。直到这段"原文"在文件里面只出现一次为止。看起来呢，这会增加一次交互开销。但是这恰恰就是防止"误伤"的关键防线。比起改错代码来说，多问一轮便宜太多了。
然后是行号污染问题。工具通常还会配一个"查看文件"的功能，方便模型知道文件现在长什么样。为了方便阅读呢，查看结果往往会带上行号前缀，比如这样：
12→def calculate_total(items): 13→ return sum(items)这里有个陷阱。如果模型原样把这段带着行号前缀的内容当作"原文"传给编辑工具去匹配的话，匹配一定会失败的。因为文件里面根本没有 12→ 这几个字符嘛。所以工具设计上必须清楚地告诉模型，行号只是给你看的，复制的时候不能带上它。这是一个很小的细节，但是决定了工具是"一用就崩"还是"顺手好用"。
接下来是过期视图问题。对话可能很长，模型对文件内容的印象呢，可能是十轮对话之前查看的结果。如果这期间文件已经被改过了，模型脑子里面的"原文"其实已经不是文件的真实内容了。成熟的做法是，每次编辑成功之后呢，让模型此前看到的文件视图给"过期"掉。如果还要继续编辑同一个文件的话，必须重新查看一次，拿到最新内容再动手。这是用一点点强制性，来换取正确性。
最后是新建和编辑要分开的问题。看起来"新建文件"和"编辑已有文件"可以合并成一个万能的"写文件"工具，但是实践证明分开会更好。一个专门用于全新文件，如果文件已存在就报错拒绝。另一个专门用于对已有内容做局部替换。这样可以避免一种很常见也很危险的误操作，就是模型以为在"编辑"，实际上却整个覆盖掉了一个已经存在、有内容的文件。
如果自己去设计的话，大概长这样
把上面这些经验揉在一起呢，一个合理的编辑工具签名大概是这样的：
str_replace(path, old_str, new_str, description)这里面 path 呢，是用绝对路径，来减少"到底是哪个文件"的歧义。
old_str 呢，必须在文件中唯一匹配。匹配失败的时候，不管是不存在还是存在多处，工具都要明确返回失败原因，引导模型带更多上下文重试。
new_str 呢，是替换后的内容，允许为空，等价于删除这段内容。
description 呢，是说明这次编辑的目的。这个参数并不是给程序逻辑用的，而是去"逼"模型在动手之前，先把"我为什么要这么改"给讲清楚。某种意义上呢，这就是把思维链嵌进了工具调用本身，间接提升了编辑的准确率。
配套的呢，还需要一个只读的"查看"工具。支持看整个目录结构，也支持看某个文件的内容，带行号方便引用。还支持只看某个范围，避免大文件全量塞进上下文，既贵又没必要。以及一个专门"新建文件"的工具，遇到路径已存在就直接报错，绝不静默覆盖。
三个工具各司其职，而不是揉成一个"万能读写工具"。这种拆分粗看是多了几个接口，实际上是用清晰的边界换取了更少的误用。模型在使用一个职责单一的工具时呢，犯错的空间也更小。
写在最后
从全文件重写，到行号 diff，再到字符串精确匹配。这条演进路径呢，其实是在反复回答同一个问题。那就是怎么让"擅长语义、不擅长精确计数"的模型，和"只认精确指令、不容任何模糊"的文件系统，好好协作。
答案呢，不是让模型变得更精确。这个很难，也不该是解法。而是设计一层工具，让模型只需要发挥它最擅长的能力，也就是理解和复现内容。剩下需要绝对精确的部分呢，交给代码逻辑去把关、去拒绝、去要求重试。
这大概也是所有 Agent 工具设计背后共通的思路吧。那就是不是教会模型做它不擅长的事，而是把它不擅长的事，从它的任务清单里面给挪走。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～