我最初对Kilo Code这类“会动手改代码”的插件是有点抵触的平时用代码补全工具已经能省不少事真让一个AI去读文件、改文件、跑命令总觉得哪里不踏实。直到接手一个老Node.js项目里面几十个回调嵌套要全部改成async/await我才决定认真把Kilo Code用起来。那次重构大概涉及二十多个文件互相还有耦合手动改不仅费眼还特别容易漏改某个分支。Kilo Code这个VS Code插件恰好能做到“对话里给需求它自己读项目、出diff等你确认后落地”。如果你也经常被跨文件重构、老代码迁移这类脏活拖住这篇文章里记录的用法、提示词、踩坑和成本控制应该能给你一些参考。我会直接讲实际项目里的操作过程不会绕概念。1. 从一次磨人的重构说起Kilo Code是怎么挤进我的工作流的先还原一下当时的项目背景。那是一套三年前写的订单服务Node.js Express数据库操作用的是原生回调。典型代码长这样一个接口里叠了三层回调每层还要做错误处理中间穿插着公共函数和日志逻辑。要改成async/await不是简单地把callback换成await就行因为很多回调函数的返回值在其他地方被消费改一个函数可能要连带改三个调用方。我最开始还是习惯手动改。改到第二个文件的时候发现不对劲有个函数被两个模块引用一个调用方期望回调风格另一个已经改成Promise风格如果我把这个函数改成async就必须同时把旧调用方也改掉。这种“改了A忘了B”的问题在纯手工模式下特别容易发生。Copilot那种补全工具能帮我少打字但没法帮我梳理跨文件的调用链。所以我开始关注Kilo Code这类“能自己动手”的插件。它跟普通聊天式AI不一样的地方在于它直接住在VS Code里能读取我打开工作区的文件结构能看文件内容能生成修改后的diff还能在我的允许下执行终端命令。这意味着我不需要像以前那样把代码复制到网页对话框里粘贴回来再手动合并文件。Kilo Code可以在一个闭环里完成“理解项目—生成方案—落地修改”整条链路。1.1 为什么当时的我需要一个“会改代码”的工具说得更直白一点补全工具解决的是“单点输入效率”聊天式AI解决的是“单文件问答效率”但重构这种活真正难的不是敲代码而是“掌握全局上下文”。举个例子我手动改回调函数的时候最怕的是隐式共享状态。有些回调里的变量是从外层闭包带上来的改成async/await之后闭包关系变了作用域可能也跟着变。只看一个文件根本看不出来必须同时打开调用方和定义方。Copilot在单个缓冲区里再聪明也没法告诉我“这个函数还被另一个文件引用那边还在用老签名”。Kilo Code的价值在于它可以把多个文件内容放进上下文里再结合对话要求生成修改方案。我不需要把代码复制来复制去只需要在对话框里说清楚“我想改成什么、哪些不能碰、这个文件跟谁有依赖关系”它就能给出一个带着改动原因的方案。对长期做维护性开发的团队来说这种能力特别实用。1.2 Kilo Code的工作方式读文件、出diff、执行操作我第一次用Kilo Code时并不清楚它到底会怎么“动手”。后来拆解下来它的工作方式其实分三步读取上下文它会根据我的指令读取工作区内相关文件的内容也可以通过#符号或一些快捷方式把指定文件塞进上下文。生成diff它不是直接改文件而是先生成修改后的差异说明类似git diff里的那种格式让我逐行看。执行操作在我确认diff之后它才会把改动写入文件如果任务里涉及跑测试、装依赖或者执行脚本它会请求对应权限。重点是这个“确认”步骤。很多人怕AI乱改代码就是因为把这一步跳过了。Kilo Code默认会把审批权交给我我可以接受部分diff也可以让它重新改。我后来养成的习惯是每个文件都看一遍diff没问题再批准太多无关改动就直接让它回滚重来。2. 第一次实战让Kilo Code独立完成一次“回调改async/await”的小任务了解工作方式之后我先挑了一个相对简单的文件做实验src/services/order.ts这个文件里有三个回调风格的函数改动范围可控不会牵连太广。我的诉求很简单让Kilo Code把这个文件里的异步逻辑改成async/await但不能动业务逻辑、不能调整函数入参顺序、不能顺手格式化其他无关代码。2.1 从需求描述到diff的完整过程我当时给的提示词类似这样请扫描 src/services/order.ts 里所有使用回调风格的异步函数把它们改成 async/await 形式。 要求 1. 不要改动文件里的业务逻辑。 2. 不要修改函数入参顺序。 3. 不要把其他无关代码格式化。 4. 动手前先列出你会修改哪些函数然后再给 diff。Kilo Code先列出它打算改的三个函数然后生成了对应的diff。我印象比较深的是其中一个函数原本写法是- function getOrder(id, cb) { - db.query(SELECT * FROM orders WHERE id ?, [id], function(err, row) { - if (err) { - return cb(err); - } - cb(null, row); - }); - } async function getOrder(id) { const row await db.query(SELECT * FROM orders WHERE id ?, [id]); return row; }这里有个细节原代码里的db.query其实是回调风格但封装层已经支持返回Promise所以才能在改成await之后直接工作。如果底层库不支持Promise这个改法就会出错。让我比较放心的是Kilo Code在执行修改前先检查了db.query的返回值处理方式然后在备注里提醒我确认依赖版本。我把diff逐行看了一遍确认没有额外改动后点了接受。随后我跑了几个关联用例功能是正常的。这个成功的尝试让我对它的信任度提高不少也让我明白了一个道理提示词里写清楚“不要动哪些东西”比单纯说“帮我改”重要得多。2.2 为什么把任务拆小再交给AI更可靠第一次尝试成功之后我犯了个经验主义错误第二句话就让它把整个src/services/目录下所有回调都改了。结果它打开了一堆文件上下文一下子变得很乱改到第三个文件的时候前面的逻辑已经开始含糊甚至在一个文件里重复改了两次同名函数。后来我调整了策略把任务拆成“一次只改一个文件或者一次只改一组强耦合的函数”每完成一个文件就跑一遍测试通过之后再继续下一个。这个策略听着保守实际上效率反而更高因为Kilo Code在上下文干净的时候生成的diff质量更高我也更容易审查。打个比方这就像让新同事干活你一次性把所有需求都丢过去他大概率会在某个角落跑偏但你给他一个明确的子任务告诉他边界和验收标准他反而能做得又快又稳。AI辅助开发也是同一个逻辑拆小任务不是低估它而是配合它当前的能力边界。3. 踩坑盘点上下文窗口、权限控制与循环卡死用了两三周之后我开始在一些稍微复杂的项目里尝试让Kilo Code独立处理多文件任务。踩坑也随之而来。这里把我觉得最值得说的几个问题整理一下都是真实会在日常开发里碰到的。3.1 上下文窗口不是无限大文件多的时候它会“假装记得”Kilo Code的上下文窗口虽大但也不是无限大。一旦对话里涉及的文件过多它会出现一个特别迷惑的行为前面说过的东西好像记住了后面又会自己编造一些不存在的逻辑。我有一次让它分析某个订单模块的十个文件然后去改其中第五个文件的字段映射。它给出的diff大概是对的但注释里引用了一个根本不存在的函数名。我一开始以为是它能力不行后来才发现是上下文太拥挤了早期文件的内容已经被挤出“活跃记忆”它只能靠剩余信息猜测。应对办法主要是三个尽可能用#或路径明确提及当前要改的文件而不是说“整个目录”。如果任务比较复杂先让它做“信息整理”把结论输出到临时文档里再在新的会话中把结论塞给它。长对话进行到一半时如果发现它开始答非所问果断开一个新会话把关键约束重新粘贴进去。这里需要强调一点不要相信AI在长会话中的记忆力。它在上下文窗口内确实能“想起来”但超出之后就会开始脑补。这跟人一样不能怪它但可以靠工作习惯规避。3.2 权限控制比想象中重要什么该让Kilo Code自己跑Kilo Code给我最大的自由度是能执行终端命令但也正因为如此权限控制必须提前想清楚。它执行命令的时候不是所有操作都是安全的。操作类型实际风险我采用的策略修改单个文件内容低但可能改动不想要的代码每次都看diff再接受运行测试命令中耗时且可能连带副作用允许跑测试但会先等diff确认安装依赖包高可能拉入大量未知依赖默认禁止特殊情况单独放行格式化、清理临时文件中可能造成无关改动除非明确需要否则不允许执行git push、删除分支等极高从不让它自动执行我一开始把所有权限都开放过结果有一次它为了“整理项目结构”自动移除了几个看起来没用的文件其中包含一个被动态引用的配置。那次之后我把权限收得很紧涉及文件系统操作、安装依赖、git写操作全部设为“需要额外确认”。可能有人觉得这样很烦每次都要多点一下。但实际用过就会明白这种“摩擦”其实是安全缓冲。它逼着我每次都看到Kilo Code究竟要干什么而不是让它蒙着眼睛在项目里横冲直撞。3.3 循环追问与“过度修改”提示词里需要明确边界另一个很常见的踩坑是循环追问。Kilo Code有时会在改到一半的时候问一句“需要继续处理下一个文件吗”、“是否需要我同时补充测试”。如果我不回复它会一直等着任务就悬在那里。更麻烦的是“过度修改”。有一次我让它修复某个接口的鉴权逻辑它除了改鉴权文件还顺手给另一个文件加了注释、调整了导入顺序、重命名了一个局部变量。这些改动不是错但会把diff搞得非常大审查成本直线上升。后来我在提示词里养成了加一段“边界控制”的习惯直接执行任务不要反复询问确认。 只允许修改我指定的文件。 不要格式化、不要重命名变量、不要调整导入顺序。 如果发现改动会影响其他模块停下来告诉我而不是直接改。这段提示词非常有效。它把“AI的自由发挥”限制在一个可控范围内。本质上Kilo Code这类工具更像一个能力很强但不太熟悉项目规矩的新人你需要把规矩说在前面否则它就会按自己的默认审美做事。4. 跨文件Bug排查实战一个接口字段丢失问题的定位全过程相比机械重构我更推荐把Kilo Code用在跨文件Bug排查上。因为排查本身是“读代码—找线索—验证假设”的过程这正是大模型比较擅长的部分。下面是一个我实际遇到的案例环节比较典型。4.1 现场前端拿不到字段接口返回里少了一个属性项目环境是Fastify TypeORM。前端说订单详情页一直拿不到userName但我看数据库里订单和用户表关联关系是存在的。手动排查的话得从路由层开始一层层看到service、repository、entity映射链路大约跨五个文件。这种活很烦但恰好适合交给Kilo Code。我把问题描述粘给它有一个bugGET /api/orders/:id 返回的 JSON 里没有 userName 字段。 请你从路由文件开始把完整的调用链相关文件列出来找出字段在哪个环节被漏掉。 先不要改代码先列出可能性最大的文件和行号并解释依据。它花了大约半分钟列出了从route到controller到service到repository再到entity的完整调用路径最后指向repository里的查询语句。问题出在查询时没有显式指定user关联关系TypeORM虽然实体里配了ManyToOne但查询方法里没有加relations所以默认不会自动带出这个字段。4.2 让Kilo Code把调用链完整铺开这个案例里最值得说的不是它找到了问题而是它的排查方式是“可复现”的。它不是一拍脑袋说“应该是这里”而是把每层文件都列了一遍并在关键位置标注了“这里没有传递字段”“这里少了一个select条件”。我顺着它的提示去翻代码发现它说的全对。排查类任务和重构类任务的提示词风格其实很不一样。重构任务需要的是强约束比如“不要改A、只改B”排查任务则需要它“先给证据链再下结论”。所以我会在提示词里刻意加上“先列出调用链”“指出行号”“不要急着改代码”这些要求。排查过程中还有一个重要操作每完成一个步骤我都让它用一两句话说明判断依据。比如你刚才说问题出在 repository 层请说明你是通过什么线索排除掉 controller 层的。这个步骤能有效避免AI“猜对答案但给不出理由”的情况。如果它的解释合理我就继续往下追如果解释含糊我会立刻打断让它重新分析。事实证明这种“让AI解释给人类听”的节奏能让最终结论可靠很多。4.3 让AI解释每个改动理由定位到问题之后我给了第二段提示词现在请修复这个问题让接口返回包含 userName。修改范围控制在 repository 和 entity 两个文件内其他地方不要动。每处修改都要在 diff 里说明原因。Kilo Code给出了一个比较规范的修复在repository的查询选项里补上relations: [user]并且在entity关联字段上确认了select: true。每个修改点后面都写了注释说明。我看完之后接受改动重新跑接口userName正常返回。整个过程大概十五分钟比我手动追调用链快了不止一倍。更重要的是它能同时把五个文件的上下文放在眼前不会像我一样翻着翻着就忘了前面看过什么。这种“跨文件追踪”的场景是目前我用Kilo Code觉得性价比最高的用途。5. 模型选择与成本控制我对Kilo Code的配置心得Kilo Code本身是一个壳真正干活的还是底层模型。它支持多种模型接入不同模型在同样的任务里表现差异很大直接影响到效果和成本。这个部分我想聊聊自己的配置心得以及怎么把token消耗控制在合理范围。5.1 我试过的几个模型和实际感受我用过几类模型配置方式都不复杂主要在界面里选择供应商和模型名称即可。真实感受如下模型擅长场景成本感受我主要用来做什么Claude系列长上下文、跨文件推理能力强偏贵但输出质量高复杂重构、跨文件Bug排查GPT系列通用任务表现均衡中等生成测试用例、解释代码片段Gemini系列响应速度快免费额度友好便宜简单补全、代码总结、快速问答本地模型隐私敏感项目可用需要硬件投入处理小文件、脱敏代码、学习实验就我自己的体会如果在同一个任务上做横向比较Claude系列在“理解项目全局、生成合理diff”上表现最好尤其是跨文件改动它的衔接更细腻。GPT系列在单文件问答和测试生成上够用。Gemini适合干一些轻量活胜在成本低。本地模型我只在实验环境里跑过处理几百行的小文件还行项目一大就会吃力。这里要说个容易被忽略的点模型的输出质量和会话长度强相关。同样一个模型在上下文干净的时候表现非常可靠一旦上下文变得臃肿再好的模型也会犯低级错误。所以模型不是越贵越好关键看你给它喂多少“噪音”。5.2 控制token消耗的几个实用措施Kilo Code虽然好用但底层模型是收费的。如果不加控制一次聊天烧掉很多token也很正常。我自己有几个省钱又实用的做法把不需要扫描的目录排除掉在配置里把node_modules、dist、build这类大目录设置为忽略避免Kilo Code把它们读进上下文。只把相关文件加入上下文能用#指定具体文件就不要说“扫描整个src目录”。短任务优先用便宜模型像“解释这段代码含义”“给这个函数生成注释”这类活用便宜模型就够了没必要一上来就开最贵的。让它输出简短内容在提示词里加一句“尽量用列表和关键结论不要复述代码全文”能省下大量输出token。拆分长会话如果发现一个任务越聊越长果断拆会话把阶段性结论整理成文本再递进。这样既省钱还能避免输出质量下降。成本控制这件事本质上是在“上下文清晰度”和“费用”之间找平衡。我给自己的底线是宁可每次让Kilo Code看小范围文件多开几轮会话也不要让它一口气读整个项目然后开始猜。6. 工具边界与后续玩法Kilo Code不是替身是副驾用了几个月之后我对Kilo Code的定位逐渐清晰。它不是一个能一键接管项目的自动驾驶更像一个坐在副驾上的高级助理。你告诉它目的地、路线偏好、哪里不能走它能把大部分机械操作接过去但最终方向还得你来定。6.1 哪些任务适合交给Kilo Code哪些不适合根据我的经验适合交给Kilo Code的任务有几个共同点规则明确、重复度高、需要跨文件协同。例如批量把回调改成Promise、统一错误处理格式、生成单元测试、重构相似结构的多份配置、根据注释自动补充文档。不适合的任务则是那些“需要业务决策”的活。比如接口字段要不要暴露给前端这个需要产品判断比如要不要拆分一个巨无霸服务这个需要架构取舍。Kilo Code可以帮忙分析利弊但不能替我做决定。还有一类是老项目完全没有测试覆盖这种项目让AI自动改代码风险很高因为它没有反馈机制来验证自己是否改坏了。6.2 我现在的高频用法和后续扩展固定下来的工作流是这样的遇到一个新任务先让Kilo Code做一个“侦察报告”也就是整理相关文件、列出改动范围确认范围没问题再让它动手改每次只接受一个文件的diff改完立刻跑测试测试通过后再把变更提交。除了改代码我还会用它做不少杂活。比如让Kilo Code根据git diff生成commit message让项目提交记录整洁很多让Kilo Code解释一段新人看不懂的旧代码逻辑甚至让它帮忙给接口文档补字段说明。这些场景不需要它改代码但对效率提升非常明显。后续我还想尝试的是把项目的约束规则写成一个固定的说明文件让Kilo Code每次开工前自动读取。比如“本项目禁止使用any”“所有新代码必须有对应测试”“异常必须走到统一错误处理”。这样能让AI的行为更贴近团队规范。回到开头的场景那个二十多个文件的老项目重构最后用了不到两天就全部收尾大部分机械修改确实靠Kilo Code完成了但我依然从头到尾review了每一处diff。如果要给一句个人体会它更适合当一个能力很强的初级工程师来带你必须先讲清楚任务范围、验收标准、哪些不能碰然后再让它动手。目前我还没敢让它一键处理整个仓库但用这种“小步快跑人工审查”的方式Kilo Code确实帮我省下了很多机械改代码的时间。如果你正被类似的脏活折磨不妨从一个小文件开始试一次它可能比你能想象到的要实用得多。 
长河君 · 2026/9/17 5:47:37 · 阅读 1.2k Kilo Code实战：AI辅助跨文件重构与async/await改造
我最初对Kilo Code这类“会动手改代码”的插件是有点抵触的平时用代码补全工具已经能省不少事真让一个AI去读文件、改文件、跑命令总觉得哪里不踏实。直到接手一个老Node.js项目里面几十个回调嵌套要全部改成async/await我才决定认真把Kilo Code用起来。那次重构大概涉及二十多个文件互相还有耦合手动改不仅费眼还特别容易漏改某个分支。Kilo Code这个VS Code插件恰好能做到“对话里给需求它自己读项目、出diff等你确认后落地”。如果你也经常被跨文件重构、老代码迁移这类脏活拖住这篇文章里记录的用法、提示词、踩坑和成本控制应该能给你一些参考。我会直接讲实际项目里的操作过程不会绕概念。1. 从一次磨人的重构说起Kilo Code是怎么挤进我的工作流的先还原一下当时的项目背景。那是一套三年前写的订单服务Node.js Express数据库操作用的是原生回调。典型代码长这样一个接口里叠了三层回调每层还要做错误处理中间穿插着公共函数和日志逻辑。要改成async/await不是简单地把callback换成await就行因为很多回调函数的返回值在其他地方被消费改一个函数可能要连带改三个调用方。我最开始还是习惯手动改。改到第二个文件的时候发现不对劲有个函数被两个模块引用一个调用方期望回调风格另一个已经改成Promise风格如果我把这个函数改成async就必须同时把旧调用方也改掉。这种“改了A忘了B”的问题在纯手工模式下特别容易发生。Copilot那种补全工具能帮我少打字但没法帮我梳理跨文件的调用链。所以我开始关注Kilo Code这类“能自己动手”的插件。它跟普通聊天式AI不一样的地方在于它直接住在VS Code里能读取我打开工作区的文件结构能看文件内容能生成修改后的diff还能在我的允许下执行终端命令。这意味着我不需要像以前那样把代码复制到网页对话框里粘贴回来再手动合并文件。Kilo Code可以在一个闭环里完成“理解项目—生成方案—落地修改”整条链路。1.1 为什么当时的我需要一个“会改代码”的工具说得更直白一点补全工具解决的是“单点输入效率”聊天式AI解决的是“单文件问答效率”但重构这种活真正难的不是敲代码而是“掌握全局上下文”。举个例子我手动改回调函数的时候最怕的是隐式共享状态。有些回调里的变量是从外层闭包带上来的改成async/await之后闭包关系变了作用域可能也跟着变。只看一个文件根本看不出来必须同时打开调用方和定义方。Copilot在单个缓冲区里再聪明也没法告诉我“这个函数还被另一个文件引用那边还在用老签名”。Kilo Code的价值在于它可以把多个文件内容放进上下文里再结合对话要求生成修改方案。我不需要把代码复制来复制去只需要在对话框里说清楚“我想改成什么、哪些不能碰、这个文件跟谁有依赖关系”它就能给出一个带着改动原因的方案。对长期做维护性开发的团队来说这种能力特别实用。1.2 Kilo Code的工作方式读文件、出diff、执行操作我第一次用Kilo Code时并不清楚它到底会怎么“动手”。后来拆解下来它的工作方式其实分三步读取上下文它会根据我的指令读取工作区内相关文件的内容也可以通过#符号或一些快捷方式把指定文件塞进上下文。生成diff它不是直接改文件而是先生成修改后的差异说明类似git diff里的那种格式让我逐行看。执行操作在我确认diff之后它才会把改动写入文件如果任务里涉及跑测试、装依赖或者执行脚本它会请求对应权限。重点是这个“确认”步骤。很多人怕AI乱改代码就是因为把这一步跳过了。Kilo Code默认会把审批权交给我我可以接受部分diff也可以让它重新改。我后来养成的习惯是每个文件都看一遍diff没问题再批准太多无关改动就直接让它回滚重来。2. 第一次实战让Kilo Code独立完成一次“回调改async/await”的小任务了解工作方式之后我先挑了一个相对简单的文件做实验src/services/order.ts这个文件里有三个回调风格的函数改动范围可控不会牵连太广。我的诉求很简单让Kilo Code把这个文件里的异步逻辑改成async/await但不能动业务逻辑、不能调整函数入参顺序、不能顺手格式化其他无关代码。2.1 从需求描述到diff的完整过程我当时给的提示词类似这样请扫描 src/services/order.ts 里所有使用回调风格的异步函数把它们改成 async/await 形式。 要求 1. 不要改动文件里的业务逻辑。 2. 不要修改函数入参顺序。 3. 不要把其他无关代码格式化。 4. 动手前先列出你会修改哪些函数然后再给 diff。Kilo Code先列出它打算改的三个函数然后生成了对应的diff。我印象比较深的是其中一个函数原本写法是- function getOrder(id, cb) { - db.query(SELECT * FROM orders WHERE id ?, [id], function(err, row) { - if (err) { - return cb(err); - } - cb(null, row); - }); - } async function getOrder(id) { const row await db.query(SELECT * FROM orders WHERE id ?, [id]); return row; }这里有个细节原代码里的db.query其实是回调风格但封装层已经支持返回Promise所以才能在改成await之后直接工作。如果底层库不支持Promise这个改法就会出错。让我比较放心的是Kilo Code在执行修改前先检查了db.query的返回值处理方式然后在备注里提醒我确认依赖版本。我把diff逐行看了一遍确认没有额外改动后点了接受。随后我跑了几个关联用例功能是正常的。这个成功的尝试让我对它的信任度提高不少也让我明白了一个道理提示词里写清楚“不要动哪些东西”比单纯说“帮我改”重要得多。2.2 为什么把任务拆小再交给AI更可靠第一次尝试成功之后我犯了个经验主义错误第二句话就让它把整个src/services/目录下所有回调都改了。结果它打开了一堆文件上下文一下子变得很乱改到第三个文件的时候前面的逻辑已经开始含糊甚至在一个文件里重复改了两次同名函数。后来我调整了策略把任务拆成“一次只改一个文件或者一次只改一组强耦合的函数”每完成一个文件就跑一遍测试通过之后再继续下一个。这个策略听着保守实际上效率反而更高因为Kilo Code在上下文干净的时候生成的diff质量更高我也更容易审查。打个比方这就像让新同事干活你一次性把所有需求都丢过去他大概率会在某个角落跑偏但你给他一个明确的子任务告诉他边界和验收标准他反而能做得又快又稳。AI辅助开发也是同一个逻辑拆小任务不是低估它而是配合它当前的能力边界。3. 踩坑盘点上下文窗口、权限控制与循环卡死用了两三周之后我开始在一些稍微复杂的项目里尝试让Kilo Code独立处理多文件任务。踩坑也随之而来。这里把我觉得最值得说的几个问题整理一下都是真实会在日常开发里碰到的。3.1 上下文窗口不是无限大文件多的时候它会“假装记得”Kilo Code的上下文窗口虽大但也不是无限大。一旦对话里涉及的文件过多它会出现一个特别迷惑的行为前面说过的东西好像记住了后面又会自己编造一些不存在的逻辑。我有一次让它分析某个订单模块的十个文件然后去改其中第五个文件的字段映射。它给出的diff大概是对的但注释里引用了一个根本不存在的函数名。我一开始以为是它能力不行后来才发现是上下文太拥挤了早期文件的内容已经被挤出“活跃记忆”它只能靠剩余信息猜测。应对办法主要是三个尽可能用#或路径明确提及当前要改的文件而不是说“整个目录”。如果任务比较复杂先让它做“信息整理”把结论输出到临时文档里再在新的会话中把结论塞给它。长对话进行到一半时如果发现它开始答非所问果断开一个新会话把关键约束重新粘贴进去。这里需要强调一点不要相信AI在长会话中的记忆力。它在上下文窗口内确实能“想起来”但超出之后就会开始脑补。这跟人一样不能怪它但可以靠工作习惯规避。3.2 权限控制比想象中重要什么该让Kilo Code自己跑Kilo Code给我最大的自由度是能执行终端命令但也正因为如此权限控制必须提前想清楚。它执行命令的时候不是所有操作都是安全的。操作类型实际风险我采用的策略修改单个文件内容低但可能改动不想要的代码每次都看diff再接受运行测试命令中耗时且可能连带副作用允许跑测试但会先等diff确认安装依赖包高可能拉入大量未知依赖默认禁止特殊情况单独放行格式化、清理临时文件中可能造成无关改动除非明确需要否则不允许执行git push、删除分支等极高从不让它自动执行我一开始把所有权限都开放过结果有一次它为了“整理项目结构”自动移除了几个看起来没用的文件其中包含一个被动态引用的配置。那次之后我把权限收得很紧涉及文件系统操作、安装依赖、git写操作全部设为“需要额外确认”。可能有人觉得这样很烦每次都要多点一下。但实际用过就会明白这种“摩擦”其实是安全缓冲。它逼着我每次都看到Kilo Code究竟要干什么而不是让它蒙着眼睛在项目里横冲直撞。3.3 循环追问与“过度修改”提示词里需要明确边界另一个很常见的踩坑是循环追问。Kilo Code有时会在改到一半的时候问一句“需要继续处理下一个文件吗”、“是否需要我同时补充测试”。如果我不回复它会一直等着任务就悬在那里。更麻烦的是“过度修改”。有一次我让它修复某个接口的鉴权逻辑它除了改鉴权文件还顺手给另一个文件加了注释、调整了导入顺序、重命名了一个局部变量。这些改动不是错但会把diff搞得非常大审查成本直线上升。后来我在提示词里养成了加一段“边界控制”的习惯直接执行任务不要反复询问确认。 只允许修改我指定的文件。 不要格式化、不要重命名变量、不要调整导入顺序。 如果发现改动会影响其他模块停下来告诉我而不是直接改。这段提示词非常有效。它把“AI的自由发挥”限制在一个可控范围内。本质上Kilo Code这类工具更像一个能力很强但不太熟悉项目规矩的新人你需要把规矩说在前面否则它就会按自己的默认审美做事。4. 跨文件Bug排查实战一个接口字段丢失问题的定位全过程相比机械重构我更推荐把Kilo Code用在跨文件Bug排查上。因为排查本身是“读代码—找线索—验证假设”的过程这正是大模型比较擅长的部分。下面是一个我实际遇到的案例环节比较典型。4.1 现场前端拿不到字段接口返回里少了一个属性项目环境是Fastify TypeORM。前端说订单详情页一直拿不到userName但我看数据库里订单和用户表关联关系是存在的。手动排查的话得从路由层开始一层层看到service、repository、entity映射链路大约跨五个文件。这种活很烦但恰好适合交给Kilo Code。我把问题描述粘给它有一个bugGET /api/orders/:id 返回的 JSON 里没有 userName 字段。 请你从路由文件开始把完整的调用链相关文件列出来找出字段在哪个环节被漏掉。 先不要改代码先列出可能性最大的文件和行号并解释依据。它花了大约半分钟列出了从route到controller到service到repository再到entity的完整调用路径最后指向repository里的查询语句。问题出在查询时没有显式指定user关联关系TypeORM虽然实体里配了ManyToOne但查询方法里没有加relations所以默认不会自动带出这个字段。4.2 让Kilo Code把调用链完整铺开这个案例里最值得说的不是它找到了问题而是它的排查方式是“可复现”的。它不是一拍脑袋说“应该是这里”而是把每层文件都列了一遍并在关键位置标注了“这里没有传递字段”“这里少了一个select条件”。我顺着它的提示去翻代码发现它说的全对。排查类任务和重构类任务的提示词风格其实很不一样。重构任务需要的是强约束比如“不要改A、只改B”排查任务则需要它“先给证据链再下结论”。所以我会在提示词里刻意加上“先列出调用链”“指出行号”“不要急着改代码”这些要求。排查过程中还有一个重要操作每完成一个步骤我都让它用一两句话说明判断依据。比如你刚才说问题出在 repository 层请说明你是通过什么线索排除掉 controller 层的。这个步骤能有效避免AI“猜对答案但给不出理由”的情况。如果它的解释合理我就继续往下追如果解释含糊我会立刻打断让它重新分析。事实证明这种“让AI解释给人类听”的节奏能让最终结论可靠很多。4.3 让AI解释每个改动理由定位到问题之后我给了第二段提示词现在请修复这个问题让接口返回包含 userName。修改范围控制在 repository 和 entity 两个文件内其他地方不要动。每处修改都要在 diff 里说明原因。Kilo Code给出了一个比较规范的修复在repository的查询选项里补上relations: [user]并且在entity关联字段上确认了select: true。每个修改点后面都写了注释说明。我看完之后接受改动重新跑接口userName正常返回。整个过程大概十五分钟比我手动追调用链快了不止一倍。更重要的是它能同时把五个文件的上下文放在眼前不会像我一样翻着翻着就忘了前面看过什么。这种“跨文件追踪”的场景是目前我用Kilo Code觉得性价比最高的用途。5. 模型选择与成本控制我对Kilo Code的配置心得Kilo Code本身是一个壳真正干活的还是底层模型。它支持多种模型接入不同模型在同样的任务里表现差异很大直接影响到效果和成本。这个部分我想聊聊自己的配置心得以及怎么把token消耗控制在合理范围。5.1 我试过的几个模型和实际感受我用过几类模型配置方式都不复杂主要在界面里选择供应商和模型名称即可。真实感受如下模型擅长场景成本感受我主要用来做什么Claude系列长上下文、跨文件推理能力强偏贵但输出质量高复杂重构、跨文件Bug排查GPT系列通用任务表现均衡中等生成测试用例、解释代码片段Gemini系列响应速度快免费额度友好便宜简单补全、代码总结、快速问答本地模型隐私敏感项目可用需要硬件投入处理小文件、脱敏代码、学习实验就我自己的体会如果在同一个任务上做横向比较Claude系列在“理解项目全局、生成合理diff”上表现最好尤其是跨文件改动它的衔接更细腻。GPT系列在单文件问答和测试生成上够用。Gemini适合干一些轻量活胜在成本低。本地模型我只在实验环境里跑过处理几百行的小文件还行项目一大就会吃力。这里要说个容易被忽略的点模型的输出质量和会话长度强相关。同样一个模型在上下文干净的时候表现非常可靠一旦上下文变得臃肿再好的模型也会犯低级错误。所以模型不是越贵越好关键看你给它喂多少“噪音”。5.2 控制token消耗的几个实用措施Kilo Code虽然好用但底层模型是收费的。如果不加控制一次聊天烧掉很多token也很正常。我自己有几个省钱又实用的做法把不需要扫描的目录排除掉在配置里把node_modules、dist、build这类大目录设置为忽略避免Kilo Code把它们读进上下文。只把相关文件加入上下文能用#指定具体文件就不要说“扫描整个src目录”。短任务优先用便宜模型像“解释这段代码含义”“给这个函数生成注释”这类活用便宜模型就够了没必要一上来就开最贵的。让它输出简短内容在提示词里加一句“尽量用列表和关键结论不要复述代码全文”能省下大量输出token。拆分长会话如果发现一个任务越聊越长果断拆会话把阶段性结论整理成文本再递进。这样既省钱还能避免输出质量下降。成本控制这件事本质上是在“上下文清晰度”和“费用”之间找平衡。我给自己的底线是宁可每次让Kilo Code看小范围文件多开几轮会话也不要让它一口气读整个项目然后开始猜。6. 工具边界与后续玩法Kilo Code不是替身是副驾用了几个月之后我对Kilo Code的定位逐渐清晰。它不是一个能一键接管项目的自动驾驶更像一个坐在副驾上的高级助理。你告诉它目的地、路线偏好、哪里不能走它能把大部分机械操作接过去但最终方向还得你来定。6.1 哪些任务适合交给Kilo Code哪些不适合根据我的经验适合交给Kilo Code的任务有几个共同点规则明确、重复度高、需要跨文件协同。例如批量把回调改成Promise、统一错误处理格式、生成单元测试、重构相似结构的多份配置、根据注释自动补充文档。不适合的任务则是那些“需要业务决策”的活。比如接口字段要不要暴露给前端这个需要产品判断比如要不要拆分一个巨无霸服务这个需要架构取舍。Kilo Code可以帮忙分析利弊但不能替我做决定。还有一类是老项目完全没有测试覆盖这种项目让AI自动改代码风险很高因为它没有反馈机制来验证自己是否改坏了。6.2 我现在的高频用法和后续扩展固定下来的工作流是这样的遇到一个新任务先让Kilo Code做一个“侦察报告”也就是整理相关文件、列出改动范围确认范围没问题再让它动手改每次只接受一个文件的diff改完立刻跑测试测试通过后再把变更提交。除了改代码我还会用它做不少杂活。比如让Kilo Code根据git diff生成commit message让项目提交记录整洁很多让Kilo Code解释一段新人看不懂的旧代码逻辑甚至让它帮忙给接口文档补字段说明。这些场景不需要它改代码但对效率提升非常明显。后续我还想尝试的是把项目的约束规则写成一个固定的说明文件让Kilo Code每次开工前自动读取。比如“本项目禁止使用any”“所有新代码必须有对应测试”“异常必须走到统一错误处理”。这样能让AI的行为更贴近团队规范。回到开头的场景那个二十多个文件的老项目重构最后用了不到两天就全部收尾大部分机械修改确实靠Kilo Code完成了但我依然从头到尾review了每一处diff。如果要给一句个人体会它更适合当一个能力很强的初级工程师来带你必须先讲清楚任务范围、验收标准、哪些不能碰然后再让它动手。目前我还没敢让它一键处理整个仓库但用这种“小步快跑人工审查”的方式Kilo Code确实帮我省下了很多机械改代码的时间。如果你正被类似的脏活折磨不妨从一个小文件开始试一次它可能比你能想象到的要实用得多。