Trymodel
返回博客

我用 AI 排查了一次代码报错:真正省时间的不是生成代码,而是这套流程

面向开发者的 AI 编程工作流:如何准备上下文、让模型定位报错、逐步修改代码并完成测试验证。

2026年8月12日4 分钟阅读Trymodel Editorial Team

很多人第一次用 AI 编程,都会直接问一句:“帮我把这个功能写出来。”

结果往往不太理想。代码看起来完整,放进项目却跑不起来;模型给了很多建议,但没有真正定位问题。不是 AI 不会写代码,而是输入里缺少了项目上下文和验收标准。

我更推荐把 AI 当成一个可以持续协作的工程助手。打开 https://trymodel.chat/chat,从一个具体报错开始,让模型经历“理解、假设、修改、验证”四个步骤。

第一步:先给最小可复现上下文

一次提供下面四类信息就够了:

  • 使用的语言、框架和运行命令;
  • 出错文件中相关的最小代码片段;
  • 完整错误信息和发生步骤;
  • 你期望看到的正确行为。

不要一上来粘贴整个项目。上下文太大,模型容易把注意力放在无关文件上,回答也会变得模糊。

可以这样提问:

项目使用 React、TanStack Router 和 TypeScript。执行 pnpm build 时,src/routes/chat.tsx 报以下错误:……请先判断错误来自类型、路由还是运行时,不要修改文件,先列出需要核对的三项信息。

第一轮只做定位,通常比让模型直接改代码更稳。

第二步:让模型明确假设

当模型给出原因时,继续追问:

你的判断依赖哪些假设?哪些信息还没有确认?请把“已确认事实”和“推测”分开。

这一步很重要。AI 的回答可能听起来很确定,但其中一部分只是根据经验做出的推断。让它显式列出假设,你就知道下一步该查什么。

第三步:只接受小补丁

确认原因后,再要求模型给出最小改动:

只修改解决该错误所需的文件,不重构无关代码。给出补丁后,说明每一处修改为什么必要。

小补丁更容易审查,也更容易回滚。对于登录、支付、数据库和权限等敏感模块,尤其不要直接接受大范围重写。

第四步:把验证命令写进任务

一个完整的 AI 编程任务,结尾应该包含验证方法:

修改完成后运行最快的相关检查。如果检查失败,保留完整输出并解释下一步,不要假装任务已经完成。

你可以让模型同时生成单元测试、手工检查清单和上线前风险说明。这样输出就不只是代码,而是一份可审阅的交付结果。

Trymodel 为什么适合这种工作流

在 https://trymodel.chat/ 中,可以根据任务切换不同模型:复杂推理、代码解释、长文档阅读和快速改写不必使用同一种模型。

需要看截图或报错图片时,可以直接上传文件;需要查最新库文档时,可以打开 https://trymodel.chat/search。任务完成后,登录账号还可以从历史记录继续对话,不必重新解释全部背景。

最后检查四件事

在提交 AI 生成的代码前,至少检查:

  1. 改动是否只涉及需求范围。
  2. 是否引入了未审核的依赖或网络调用。
  3. 错误处理、权限和敏感信息是否完整。
  4. 构建、测试和关键路径是否真的跑过。

AI 编程真正省下来的,不只是敲代码的时间,而是定位问题、整理上下文和反复解释的时间。流程越清楚,模型越像工程助手;流程越含糊,模型越容易变成代码随机生成器。

从一个真实报错开始,在 https://trymodel.chat/chat 里把这套流程跑一遍,通常比继续收集“万能提示词”更有用。