「AI API 客户端生成流程」这种开发任务，AI 很容易显得很能干。它能马上给代码，甚至解释得头头是道。但真正让我放心的，从来不是回答，而是后面的 diff 和测试。
我会让 GitHub Copilot、ChatGPT、Claude 各站一段：先读现有代码，再补局部实现，再看风险。「API 客户端生成」不能只靠一段生成结果，项目里的命名、测试和旧约定都要进来。
这句听起来不够漂亮，但挺有用。「API 客户端生成」 先留一点笨拙，后面的人才知道该从哪里改。
先读仓库脾气
做「AI API 客户端生成流程」之前，我会先找三处相似实现。这个动作有点慢，但能让 AI 少写那种“看起来正确、风格完全不贴项目”的代码。
如果「API 客户端生成」只剩一句“帮我做一下”，我会先停住。需求越短，越要补上下文。
把不能碰的地方写清楚
材料不用多，但要真实。围绕「API 客户端生成」，我会把已有素材、不能编的事实、还没确认的地方放在一起。AI 看到的东西越具体，它越不容易装得很懂。
提示词我会写得很像工单：背景、材料、限制、输出给谁、哪些地方必须标成不确定。写「API 客户端生成」时，这种笨办法比“请你专业地分析”更耐用。
我有时会顺手留一个很小的接口草稿，不是为了显得规范，只是怕自己第二天忘了当时到底让 AI 看什么。
type ApiClientDraft = {
endpoint: string;
method: "GET" | "POST";
responseShape: "known" | "draft";
owner: string;
review: "pending" | "passed";
};
助手不要包办
这里最怕工具互相抢活。做「API 客户端生成」时，我会先把它们放到不同工位上。GitHub Copilot 适合贴着编辑器补函数、样板代码和测试片段。它适合小步补，不适合替你定方案。ChatGPT 我会放在拆需求、列验收、解释错误日志的位置。它适合把模糊问题先拆成几条可检查的线。Claude 更适合读长上下文、审查方案和整理迁移风险。它不是来替你点“通过”的，是帮你把遗漏摊出来。这样看起来慢一点，可交接时会少很多含糊话。
这里不需要把流程画得很豪华。只要能看出「API 客户端生成」的输入、输出、人工判断和沉淀位置，已经比一段很完整的 AI 回答可靠。
测试是最后一句话
顺滑只是最低标准。对「API 客户端生成」来说，更重要的是 diff、测试、命名、复用和无关文件改动。这些地方如果含糊，后面一定会返工。
还有个容易忽略的小坑：别在文章里写死 GitHub Copilot、ChatGPT、Claude 的实时价格、套餐额度或地区可用性。这些东西变得太快。写清它们在「API 客户端生成」里的位置，就够了。
可以先拿「API 客户端生成」里的一个小改动试。限制文件范围，写清验收命令，改完马上跑测试。它如果连小 diff 都解释不清，就别让它继续扩大范围。
到这里就可以先停。不是说「API 客户端生成」已经完美，而是它有了一条能被看见、能被改、也能被别人接住的小路径。
