代码任务选型：补全、改写、调试是三种不同的活

补全：延迟比聪明重要

打字的时候等两秒，思路就断了。补全场景下，能不能一次写出完美代码不重要，快、不打断才重要。

小模型在这一项上往往更合适：参数少、响应快，本地跑也行。它写错一行，你按 Tab 之前就看得出来。

判断标准就一个：接受率。用一周，数你按 Tab 接受的比例。低于三成，说明它没摸到你的代码风格，换一个，或者补一份项目约定说明。

把一段代码改成另一种写法，难点不在语法，在约定。命名风格、错误处理方式、日志格式、依赖注入的做法，每个项目都自成一派。

所以这一项要看模型能不能吃下足够多的上下文：相邻文件、工具类、配置文件。只给它一个函数，改出来的东西能跑，但跟项目格格不入。

实操建议：改之前把同类文件贴两个进去，说“按这个风格改”。比写十句要求都管用。

报错信息只是入口。难的是从报错追到调用方，再追到数据来源。这需要模型同时看到多个文件。

这一项对长上下文和推理能力要求最高，也是最值得用顶配模型的地方。一次调试省半小时，几十次就回本。

有效的提问方式：贴报错、贴出错函数、贴它的调用方，然后问“哪一行的哪个值可能不符合预期”。别问“为什么报错”，那个问题太开放，它会给你五种可能。

还有一个细节：告诉它你已经排除了什么。你说过“不是空指针，我打过日志了”，它就不会再往那个方向绕一圈。

跨十个文件的重构。它能给你方案，但改不完全，你花在核对上的时间比亲手改一遍还多。

涉及并发、事务、内存的 bug。它给的修复经常“看起来对”，跑起来偶发失败，而且很难复现。

不熟悉的框架。它会把两个版本的 API 混着用，编译不过还嘴硬。

这三类事，让它给思路、给检查清单，落笔自己来。

补充一句让它改代码，永远要求给完整函数，不要给片段。片段省的那点 token，会在你拼接的时候加倍还回去。

AI 写的代码要不要全看一遍？

要。它最常见的问题不是语法错，是边界没处理：空值、超时、并发。这些测试不一定覆盖得到。

本地模型能写代码吗？

补全可以，调试吃力。参数量小的模型在长上下文里容易丢线索，复杂问题还是得用在线的大模型。

怎么减少它编 API？

把相关文档或类型定义贴进去，要求“只用我给的定义里的方法”。它编 API 多半是因为没见过你用的版本。