企业官网建设流程全解析

我最初对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给我最大的自由度是能执行终端命令，但也正因为如此，权限控制必须提前想清楚。它执行命令的时候，不是所有操作都是安全的。

我一开始把所有权限都开放过，结果有一次它为了“整理项目结构”，自动移除了几个看起来没用的文件，其中包含一个被动态引用的配置。那次之后，我把权限收得很紧：涉及文件系统操作、安装依赖、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。

我把问题描述粘给它：

有一个bug：GET /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系列在“理解项目全局、生成合理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确实帮我省下了很多机械改代码的时间。如果你正被类似的脏活折磨，不妨从一个小文件开始试一次，它可能比你能想象到的要实用得多。