程序员怎么用 AI 读别人的代码、做 Code Review、写技术文档、排查线上故障：国产模型分工（8 个提示词模板）

大多数「程序员怎么用 AI」的文章讲的是让 AI 写代码，但接手一个别人写了三年的项目、每天审同事的 PR、给新同事补文档、凌晨两点被告警叫醒——这些活加起来比写新代码多得多，也更适合交给 AI。关键不是「让 AI 写」，而是「让 AI 先读」：把代码、日志、监控数据、PR diff 完整喂进去，让它在你之前读完，你再基于它的整理下判断。 不同任务读的东西差别很大，模型也要换着用。

模型分工上：读整个模块、整份日志、整条调用链用 Kimi K3（一次能读几千行代码或几万行日志，见 Kimi K3 读长文档），写 commit message、PR 描述、接口文档、review 意见用 DeepSeek（快、准、格式服帖），从堆栈和指标往回推根因、分析并发和数据一致性问题用 DeepSeek R1（会一层一层往下追，见 DeepSeek R1 推理实战），写给产品、运营、老板看的技术说明用 GLM-5.1（说人话）。写代码本身怎么选模型见国产 AI 写代码，这篇只讲写代码之外的部分。全部在不墨 AI 助手同一个页面切换。

从接手项目到处理故障的分工

环节	模型	做什么
① 接手陌生代码	Kimi K3	读整个模块，画出调用关系、数据流和「改这里会影响哪里」
② Code Review	Kimi K3 + DeepSeek	K3 读完整 diff 和相关上下文，DeepSeek 写成能直接贴的 review 意见
③ 写 commit / PR 描述	DeepSeek	从 diff 写出「为什么改」而不只是「改了什么」
④ 写接口文档	DeepSeek	从代码生成接口文档，标出代码里没定义清楚的地方
⑤ 写技术方案	DeepSeek R1	逼出方案里没考虑的边界、失败路径和回滚方式
⑥ 排查线上故障	Kimi K3 + DeepSeek R1	K3 读日志找时间线，R1 从现象往回推根因
⑦ 写故障复盘	DeepSeek	按时间线 + 根因 + 改进项写，不甩锅
⑧ 向非技术同事解释	GLM-5.1	把方案 / 故障 / 排期翻成产品和老板听得懂的话

8 个提示词模板

1. 接手陌生代码 · Kimi K3

（上传：这个模块的全部源文件，或粘贴目录树 + 核心文件；有 README 和历史设计文档也一起给）
我要接手这个模块，语言 / 框架：【Java Spring / Go / Python Django / TypeScript Node……】
我接下来要做的改动：【一句话，比如 给订单增加「部分退款」状态】
请先读完再回答：
1. 这个模块对外暴露哪些入口（接口 / 消息消费 / 定时任务），每个入口的主流程走哪几个文件、哪几个函数，用文字画出调用链
2. 核心数据结构有哪些，哪些字段是在哪里被修改的（写操作的位置列全）
3. 我要做的这个改动，按你的理解需要碰哪些文件，改动后会影响哪些其他入口——按「必须改 / 可能受影响 / 应该不受影响」分三档
4. 代码里有哪些「看起来不对但可能是有意为之」的地方（特殊的 if 分支、魔法数字、被注释掉的逻辑、TODO），列出来我去问原作者
5. 有没有明显的坑：没处理的异常、没加锁的共享状态、没有幂等保护的写操作
只基于我给的代码回答，不确定的说不确定，不要猜测没给你的文件里有什么。

2. Code Review · Kimi K3 + DeepSeek

（K3 部分，上传：完整的 PR diff + 被改动文件的完整原文 + 相关的调用方文件）
PR 标题和描述：【粘贴】
这个仓库的规范：【命名 / 错误处理 / 日志 / 测试要求，有文档就上传】
请 Kimi K3 按以下顺序审：
1. 改动是否和 PR 描述一致？有没有描述里没提但 diff 里改了的东西（顺手改的）
2. 正确性：边界条件（空、零、负数、超长、并发）、错误处理是不是吞了异常、资源有没有释放、事务边界对不对
3. 兼容性：改了签名 / 返回结构 / 数据库字段的话，所有调用方都改了吗？我给的调用方文件里有没有漏的
4. 测试：新增逻辑有没有对应测试？测试覆盖了正常路径还是也覆盖了异常路径
5. 可读性：只指出真正影响理解的问题，不挑格式（格式交给 linter）
每条问题标出文件和行号，分「必须改 / 建议改 / 可以不改」三档，每条附一句为什么。

（把 K3 的输出贴给 DeepSeek）
请把上面的 review 意见改写成能直接贴到 PR 评论里的版本：每条一段，先说问题再说建议怎么改（给代码片段），语气是同事之间的、不是审判；「可以不改」的合并成一条「顺便提一下」放最后。

3. 写 commit / PR 描述 · DeepSeek

diff：【粘贴 git diff 输出，或上传】
背景：【为什么要做这个改动——需求、bug 单号、线上问题】
请写：
1. commit message：第一行不超过 50 字符、动词开头、说清改了什么；空一行后写「为什么改」和「有什么需要注意的」，不超过 5 行；遵循【Conventional Commits / 我们的格式：粘贴示例】
2. PR 描述，按这个结构：
   - 改了什么（3 句以内）
   - 为什么这样改，有没有考虑过别的方案、为什么没选
   - 影响面：哪些接口 / 页面 / 任务受影响
   - 怎么验证：我本地测了什么，reviewer 可以怎么复现
   - 风险和回滚：上线后如果出问题，怎么回滚
3. 如果 diff 里有和描述无关的顺手改动，指出来，建议我拆成单独的 commit
不要写「优化代码」「修复问题」这种没有信息量的话，每句都要有具体内容。

4. 写接口文档 · DeepSeek

接口代码：【粘贴 controller / handler / router 及其用到的 DTO、参数校验、错误码定义】
文档格式要求：【OpenAPI / Markdown 表格 / 公司模板：粘贴示例】
请生成接口文档：
1. 每个接口：路径、方法、用途一句话、请求参数（名称 / 类型 / 必填 / 说明 / 示例）、响应结构（含每个字段的含义）、错误码及触发条件
2. 示例请求和响应各一份，数据要像真的（不要 "string" "0"）
3. 从代码里能看出的限制写进文档：分页上限、字段长度、枚举值、幂等要求、鉴权方式
4. **标出代码里没定义清楚的地方**：参数没校验就直接用的、错误码没枚举的、返回字段有时有有时没有的——这些我要去确认，不要替我编一个说法填上
5. 按调用方的视角补一段「常见用法」：先调哪个再调哪个
只写代码里能看出来的，看不出来的标【待确认】。

5. 写技术方案 · DeepSeek R1

需求：【一句话 + 详细说明，或粘贴 PRD 相关部分】
现有系统：【相关的服务、数据库、消息队列、缓存，各自的量级】
我初步的方案：【写出来，哪怕很粗】
约束：【上线时间、不能停机、不能改某张表、团队人数】
请逐层审我的方案：
1. 主流程能不能跑通？把每一步的输入输出写出来，找出我没说清的步骤
2. 失败路径：每一步失败了会怎样？数据会不会处于中间状态？怎么恢复？哪些操作需要幂等？
3. 数据一致性：涉及多个存储的写操作，先后顺序是什么？中间挂了怎么办？需不需要事务 / 补偿 / 对账？
4. 性能：按我给的量级，哪一步最可能成为瓶颈？粗算一下
5. 上线和回滚：能不能灰度？回滚需要回滚数据吗？新老版本共存期间会不会出问题？
6. 我的方案和「最简单能跑的方案」比，多出来的复杂度值不值？
最后给一个「方案评审时评审人最可能问的 5 个问题」，让我提前准备。不要直接给我一个新方案，先把我的方案审透。

6. 排查线上故障 · Kimi K3 + DeepSeek R1

（K3 部分，上传：故障时间段的应用日志、错误堆栈、相关服务的日志；有链路追踪的把 trace 导出）
现象：【什么时候开始、什么表现（报错 / 超时 / 数据不对）、影响范围（多少用户 / 哪些接口）】
时间线上的已知事件：【几点发了什么版本、几点改了什么配置、几点流量有变化】
请 Kimi K3：
1. 按时间排出日志里的关键事件：第一条异常出现在几点几分、之前 5 分钟有什么异常迹象、异常从哪个服务先开始、然后传到了哪里
2. 把错误按类型归类并计数，找出「第一个出现的错误类型」和「数量最多的错误类型」——这两个经常不是同一个
3. 有没有和已知事件（发版 / 配置 / 流量）在时间上吻合的
4. 日志里有没有被忽略的 warning 是和这次故障相关的

（把 K3 的时间线贴给 DeepSeek R1，再加上监控指标）
监控：【CPU / 内存 / 连接数 / QPS / 错误率 / 延迟的变化，有截图描述数值】
代码：【粘贴可疑位置的代码】
请 R1：
1. 列出能解释全部现象的根因假设，不超过 4 个，按可能性排，每个说清「如果是它，还应该看到什么现象」
2. 对每个假设给一个能在 5 分钟内验证或排除的动作（查某个指标 / 看某个日志 / 跑某条命令）
3. 如果现在还没恢复：止血动作是什么（回滚 / 扩容 / 降级 / 切流），各自的代价
4. 不要跳到「大概是 XXX 问题」，每一步推理要说明依据是哪条日志或哪个指标

7. 写故障复盘 · DeepSeek

故障事实：【时间线、影响范围、根因、怎么恢复的——粘贴模板 6 的结论和排查记录】
参与处理的人和各自做的事：【列一下】
复盘格式：【公司模板，或用下面的默认结构】
请写故障复盘报告：
1. 摘要：一段话，什么时候、什么影响、根因是什么、多久恢复
2. 影响：量化——多少请求失败、多少用户受影响、持续多长时间、有没有数据需要修复
3. 时间线：从第一个异常迹象到完全恢复，每个关键动作一行，标清「发现 → 定位 → 止血 → 恢复」各自花了多久
4. 根因：直接原因是什么，为什么它会发生（往下追两层：代码为什么这样写、流程为什么没拦住）
5. 为什么没有更早发现 / 更快恢复：告警、预案、工具哪里缺
6. 改进项：每项写「做什么、谁负责、什么时候完成、怎么验证做到了」，分「防止再发生」和「缩短下次恢复时间」两类
要求：只写事实和改进，不写「XX 同学操作失误」这种个人归责——写「流程上缺少 XX 检查」；不写「加强意识」「提高警惕」这类不可验证的改进项。

8. 向非技术同事解释 · GLM-5.1

技术内容：【粘贴技术方案 / 故障复盘 / 排期说明】
听众：【产品经理 / 运营 / 老板 / 客户】，他们关心的是：【什么时候能上 / 会不会再出问题 / 要不要加人 / 对用户有什么影响】
场景：【周会口头汇报 / 一条群消息 / 一页文档】
请改写：
1. 第一句就回答他们最关心的那个问题，不要从技术背景讲起
2. 全文不出现他们听不懂的词（不说「幂等」「分布式锁」「连接池」，要说就用一个比喻带过）
3. 需要他们做决定的地方单独列出来：选项是什么、各自的代价是什么、我建议选哪个
4. 如果是故障，说清楚「对用户的实际影响」和「以后会不会再发生」，不要解释技术细节
5. 篇幅：口头汇报 1 分钟以内、群消息不超过 5 行、文档不超过一页
最后帮我预判他们会追问什么，各准备一句回答。

5 条防「AI 一本正经地编 API」规则

1. 上下文喂全，不要只贴一个函数。 AI 读代码最大的坑是只看到局部就下结论——你贴一个函数，它不知道调用方怎么传参、被调方怎么抛异常。模板 1、2、6 都要求把相关文件一起上传，K3 读得下。
2. 它说的 API、参数、配置项，跑之前先查一遍。 所有模型都会编不存在的方法名或者混淆版本之间的差异，尤其是不常用的库。模板 4 要求「看不出来的标【待确认】」，你自己也要养成「AI 给的每个 API 名先 grep 一下」的习惯。
3. 故障排查不许跳结论。 「大概是数据库连接池满了」这种话在排查时是有害的——它会让你顺着一条可能错的线走 20 分钟。模板 6 强制 R1 每个假设都给验证动作和依据，先排除再深入。
4. Review 意见按「必须 / 建议 / 可以不改」分档。 AI review 最讨人厌的是一条改变量名的建议和一条并发 bug 混在一起，reviewer 和作者都得重新分拣。模板 2 强制分档，「可以不改」合并到最后。
5. 复盘不归责到人。 AI 写复盘容易顺着你给的事实写出「XX 操作时未检查」，这在团队里是毒药。模板 7 写死了只写流程和系统缺口。

常见问题

代码能上传吗，安全吗？ 公司内部代码上传前看一下公司政策。通常做法是：脱掉密钥、内网地址、客户数据，只上传逻辑代码；核心算法或有合规要求的模块不传。日志里的用户信息（手机号、身份证）要先脱敏。

为什么 review 要先用 K3 再用 DeepSeek，直接一个模型不行吗？ 可以，但大 PR 加上相关文件经常超过普通模型的上下文，K3 一次读得全；读完之后的「改写成友好的评论」是个短任务，DeepSeek 更快。小 PR 直接用 DeepSeek 一步做完。

AI 排查故障靠谱吗？ 它不能替你看监控和登服务器，但在「从几万行日志里排时间线」和「列出所有可能的根因让你逐个排除」这两件事上比人快得多，尤其是凌晨两点脑子不清楚的时候。最终判断还是你的。

GLM-5.1 和 DeepSeek 都能写中文，为什么解释给非技术同事要用 GLM？ 实测 GLM-5.1 在「把技术翻成人话」上更少残留术语，语气也更像同事在说话；DeepSeek 写技术文档更准。两个都试一下，用顺手的。

要花钱吗？ 登录送免费额度，每天审几个 PR、写几条 commit 够用。整个模块一次读、每天几万行日志排查、频繁做方案评审的看会员方案。

一句话总结

程序员用 AI 最省时间的地方不是写新代码，而是读：接手陌生模块、审 PR、排查故障，都先让 Kimi K3 把代码、diff、日志完整读一遍，排出调用链和时间线；然后 DeepSeek 写 commit、PR 描述、接口文档和 review 意见，DeepSeek R1 从现象往回推根因、把技术方案的失败路径一层层逼出来；最后 GLM-5.1 把这些翻成产品和老板听得懂的话。上下文喂全、AI 给的 API 先 grep、排查不跳结论、复盘不归责到人，剩下的判断还是你自己的。