用结构化Checklist引导Kimi审查代码：先克隆仓库、定位变更文件，再按安全性、健壮性、可读性、规范性四类编写明确检查项；提示词需角色清晰、输入限定、Checklist嵌入，并附上下文说明；提交后验证输出是否含四级标题及具体漏洞定位。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用Kimi对开源项目代码做审查时，直接扔进大段代码往往漏掉关键缺陷，必须用结构化Checklist提示词引导它逐项排查安全、可维护性与规范性问题。
准备待审代码与Checklist框架
克隆目标开源项目仓库到本地，进入需审查的模块目录（如 src/utils/），用 git diff HEAD~1 --name-only 确认本次变更范围，只提取新增或修改的 .py/.js 文件内容，避免把整个仓库喂给Kimi。
新建纯文本文件 review_checklist.txt，按以下四类写明检查项（每类用空行分隔）：
【安全性】SQL注入点、硬编码密钥、不安全的反序列化调用
【健壮性】空值未判空、除零未捕获、第三方API超时未设限
【可读性】函数超过30行、变量名含缩写无注释、魔法数字未提取为常量
【规范性】未遵循 PEP8/ESLint 默认规则、缺少单元测试覆盖率声明
这一步不能跳过——Kimi不会主动识别“哪些地方该查”，没有明确Checklist就等于让它盲审。
构造带上下文的提示词
方法一：基础三段式提示
第一段交代角色：“你是一名资深开源项目安全审查员，专注Python/JavaScript项目”；
第二段限定输入：“我将提供一段代码及一份审查Checklist，仅基于这两者回答，不自行补充逻辑”；
第三段嵌入Checklist：“请严格对照以下四类检查项逐条分析：【安全性】……【健壮性】……”
使用 Moonshot Kimi API 的 $web_search 内置工具进行联网搜索。当需要进行网络搜索获取实时信息时使用，支持中文和英文搜索查询。需要配置 MOONSHOT_API_KEY。
方法二：增强上下文提示
在代码块前追加一行说明：“这是 【Django 4.2 中间件 auth.py 的 post-auth 钩子】，处理用户登录后的权限校验，调用外部 OAuth2 接口，需特别关注 token 透传与错误降级逻辑”；
Checklist中对应项同步强化：“【安全性】检查 token 是否经 request.META 透传、是否被日志明文打印；【健壮性】检查 OAuth2 调用是否设置 5s 超时与 fallback 返回默认权限”。
注意：Kimi对“中间件”“OAuth2”这类术语理解较准，但对“fallback”可能歧义，必须写成“fallback 返回默认权限”而非单写“fallback”。
向Kimi提交审查请求
打开 Kimi 官网或 App，选择「长文本」模式（非聊天窗口），粘贴构造好的提示词 → 粘贴精简后的代码（建议单次不超过 800 行）→ 点击发送。
第一步：等待响应时观察左下角状态，若显示“正在解析上下文”，说明提示词中的角色定义和Checklist已载入；
第二步：收到回复后立即核对输出结构——正确响应必含四级小标题（【安全性】/【健壮性】/【可读性】/【规范性】），每项下有“发现位置+代码片段+风险等级（高/中/低）+修复建议”；
第三步：重点检查【安全性】项是否命中真实漏洞，例如它指出 cursor.execute(f"SELECT * FROM users WHERE id = {user_id}") 存在 SQL 注入，且标注“高危”，即验证通过；若只泛泛说“避免拼接SQL”，则提示词需补强具体漏洞模式。
这一步操作起来很简单，直接把文件拖进去就行。但若Kimi返回“无法判断”或回避某类检查项，说明Checklist里那条描述太模糊，比如写“检查异常处理”就不如写“检查 try 块内是否有 except Exception: raise 且无日志记录”。
