「用 AI 改进错误提示」这种开发任务，AI 很容易显得很能干。它能马上给代码，甚至解释得头头是道。但真正让我放心的，从来不是回答，而是后面的 diff 和测试。
我会让 ChatGPT、Claude、Cursor 各站一段：先读现有代码，再补局部实现，再看风险。「用 AI 改进错误提示」不能只靠一段生成结果，项目里的命名、测试和旧约定都要进来。
不用急着把它写圆。「改进错误提示」里那些疑问、半成品和人工判断，最好一开始就露出来。
先框住改动范围
做「用 AI 改进错误提示」之前，我会先找三处相似实现。这个动作有点慢，但能让 AI 少写那种“看起来正确、风格完全不贴项目”的代码。
这里先别谈大方案。先说「用 AI 改进错误提示」明天要被谁打开，打开以后他要做什么决定。这个问题一旦清楚，很多花哨步骤都会自动消失。
让 AI 先读旧代码
我会先准备一页纸，写清现有实现、文件范围、测试命令和边界条件。不用写成正式文档，能让同事看懂就行。对「用 AI 改进错误提示」来说，这页纸比一段很长的提示词更重要。
提示词我会写得很像工单：背景、材料、限制、输出给谁、哪些地方必须标成不确定。写「用 AI 改进错误提示」时，这种笨办法比“请你专业地分析”更耐用。
小 diff 比大方案可靠
工具分工不用漂亮，但要说得过去。围绕「用 AI 改进错误提示」，我宁愿每个工具只做一件小事。ChatGPT 我会放在拆需求、列验收、解释错误日志的位置。它适合把模糊问题先拆成几条可检查的线。Claude 更适合读长上下文、审查方案和整理迁移风险。它不是来替你点“通过”的，是帮你把遗漏摊出来。Cursor 适合项目级阅读和跨文件修改。前提是文件范围、验收条件和测试命令先写清楚。这样看起来慢一点，可交接时会少很多含糊话。
对「用 AI 改进错误提示」来说，工具链越长，越要保留人工停顿点。没有停顿点，错误会一路顺着流程跑下去。
跑测试再说
复核「用 AI 改进错误提示」时，我不会只看它顺不顺。我要看 diff、测试、命名、复用和无关文件改动。有一项说不清，就先别把它当成完成。
还有个容易忽略的小坑：别在文章里写死 ChatGPT、Claude、Cursor 的实时价格、套餐额度或地区可用性。这些东西变得太快。写清它们在「用 AI 改进错误提示」里的位置，就够了。
可以先拿「用 AI 改进错误提示」里的一个小改动试。限制文件范围，写清验收命令，改完马上跑测试。它如果连小 diff 都解释不清，就别让它继续扩大范围。
跑完以后，我只记三件事：哪里真的省了时间，哪里让人更糊涂，哪里必须早点交给人判断。「用 AI 改进错误提示」能留下这些记录，就已经不是一次性生成了。
