刚开始用Kimi Code，最容易遇到的情况是：需求已经说了，代码也改了，结果却总差一点。比如只是想修复登录报错，它顺手调整了页面结构；想补一个小功能，最后多出了几项依赖。想减少这种返工，关键在于把任务范围、现有条件和验收方式交代清楚。下面以Kimi Code CLI为主，整理日常开发中值得掌握的使用技巧和指令，示例可以按自己的项目替换后直接使用。
01｜Kimi Code怎么用？先让它读懂项目
Kimi Code CLI是运行在终端里的AI编程助手，可以读取和修改代码、搜索文件、执行命令，并根据执行结果继续处理任务。它接触的是实际项目，因此启动目录和任务边界都会影响结果。
完成安装和登录后，先进入项目根目录，再运行 kimi。如果尚未配置登录，可在交互界面输入 /login，按照提示完成授权或配置。
接手陌生项目时，建议把第一轮对话留给代码梳理：
请先阅读README、依赖配置和主要源码目录，说明项目使用的技术栈、启动方式、测试入口，以及登录功能涉及的文件。暂时不要修改代码；没有找到的信息请明确标注。
这一步能提前发现不少问题：项目使用哪一种包管理器、有没有现成组件、测试命令是否已经写好。先弄清这些，再让它动手，后面的沟通会轻松很多。
02｜Kimi Code常用指令：分清输入位置
终端命令在系统终端执行，斜杠指令在Kimi Code交互界面输入。 两者不要混用。刚开始不必背下所有参数，先记住下面这些。
终端中常用的命令：
kimi：在当前工作目录启动新的交互会话。kimi --continue：继续当前目录最近一次会话，也可写成 kimi -c。kimi --plan：以计划模式启动新会话，优先进行探索和规划。kimi --version：查看已安装版本。kimi --help：查看终端参数及帮助。进入会话后常用的指令：
/help：查看可用指令和快捷键。/init：分析代码库并生成项目说明文件AGENTS.md。/status：查看当前模型、工作目录、权限模式等运行信息。/model：切换当前会话使用的模型。/usage：查看Token使用、上下文消耗和额度信息。/compact：压缩当前对话上下文。/sessions：浏览历史会话并选择恢复。/new：开始新会话，清空当前对话上下文。上述用法依据Kimi Code官方文档整理。如果本地版本显示的指令不同，以当前版本的帮助信息为准。尤其要记住，/new 不会还原项目文件；/undo 用于撤回活动上下文中的近期提示，也不会撤销代码修改。
03｜提示词怎么写？把验收条件一起说清楚
“帮我优化一下”很难得到稳定结果。优化速度、精简代码、改善交互，往往对应完全不同的改动。比较实用的Kimi Code提示词模板是：任务目标＋相关位置＋修改限制＋验收标准。
请修复登录页面重复提交的问题。重点检查登录表单及其请求函数，沿用现有组件和状态管理方式，不新增依赖，不修改接口字段。请求进行中应禁用提交按钮，失败后恢复按钮状态，并保留已有错误提示。完成后运行相关测试，说明修改文件和验证结果。
如果不知道文件在哪里，可以让它先定位。真正需要说清楚的是用户看到了什么、希望变成什么，以及哪些行为必须保留。涉及多个页面时，最好再补一句：“发现需要扩大修改范围时，先说明原因。”
04｜修复Bug：先复现，再做最小修改
遇到报错，直接贴一句错误信息，往往还不够。最好同时提供触发步骤、完整报错、预期结果和实际结果。涉及运行环境时，再补充系统、运行时版本或最近的相关变更。
问题：提交空表单后页面一直显示加载中。复现步骤：打开登录页，不填写账号和密码，点击提交。预期：提示必填项，页面仍可操作。请先定位原因，再进行最小范围修复，并检查正常登录与请求失败两种情况。无法复现时，请说明缺少哪些信息。
这里最有用的是“最小范围”。修一个表单问题，通常没有必要重写整个页面。让它先指出导致故障的代码，再解释修改理由，比一次接受大批改动更容易判断是否修对了。
05｜长任务怎么推进？按阶段处理上下文
给一个老项目增加权限管理，如果只发一句“把权限做好”，中途很容易出现理解偏差。可以先梳理角色与接口，再确认方案，然后逐步修改路由、页面和服务端校验，最后集中验证。
复杂改动可以从 kimi --plan 开始，要求先列出涉及文件、实现步骤和验证方法。计划模式适合前期探索，但业务规则仍要由你说明，例如普通成员能否查看其他人的数据。
当同一个任务讨论得很长，可以使用带说明的压缩指令：
/compact 保留任务目标、已确认的接口约定、已修改文件、测试结果和未解决问题。
压缩能腾出上下文空间，但不能当作完整的项目记录。关键决定最好写进项目文档。换到无关任务时使用 /new；继续处理同一问题时，优先恢复原来的会话。
06｜重复要求写进项目说明，减少来回提醒
如果每次都要强调“使用pnpm”“不要修改生成文件”“新增页面沿用现有布局”，就适合把这些规则写进AGENTS.md。可以先运行 /init 生成初稿，再检查内容是否符合项目实际情况。
项目说明宜保留可以执行的约定：启动和测试命令、目录职责、代码风格、禁止直接编辑的文件，以及完成任务后的检查要求。像“代码必须优雅”这样的表述过于宽泛，不如写成“优先复用现有工具函数，新增依赖前说明用途”。
文件也需要维护。测试入口或目录结构已经调整，旧说明却没有更新，后续任务就可能反复走错路。
07｜代码改完之后，怎样判断任务真的完成？
Kimi Code回复“已完成”，还需要对应的验证依据。阅读代码差异时，重点检查有没有无关改动、是否误改接口，以及错误处理是否完整。涉及界面的功能，还应实际走一遍操作流程。
请总结本次修改的文件与原因，列出实际执行的检查命令和结果。没有执行的测试请单独说明，不要写成已通过；如果仍有已知问题或需要人工验证的页面，请明确列出。
例如，修复重复提交时，除了正常提交，还要检查连续点击、请求失败和失败后重试。测试能否覆盖原问题，比一段笼统的完成说明更有参考价值。
08｜指令查不到时，去哪里核对？
可以先查看本地 /help，再对照官方的入门指南、终端命令参考和斜杠指令参考。排查登录、模型或参数问题时，同时记录本地版本，避免把不同版本的教程混在一起。
Kimi Code用得顺不顺，往往体现在一些小地方：开始前多交代一句限制，修改前先确认问题，结束时认真看一次测试结果。先拿一个边界清楚的小任务练手，比如修复表单校验或补充一个测试，把这套流程跑通，再逐步交给它更复杂的工作，通常更容易得到可控、可检查的结果。