能复现的缺陷报告，让编码智能体真正动手

把一句“这个功能坏了”交给编码智能体，往往只能换来一轮猜测。智能体看不到你刚才的操作，也不一定知道你期待的结果。它需要的不是一篇长篇技术论文，而是一份能让别人重新遇到问题、判断修复是否成功的说明。

先把观察到的现象说清楚

开头用一两句话写出发生了什么，以及它影响了谁。例如，用户提交订单后，页面显示成功，但订单列表中没有新增记录。接着说明预期结果：提交成功后，订单应当出现在列表中。把实际结果和预期结果分开，智能体才能区分缺陷与正常行为。

尽量描述看到的事实，而不是把猜测写成结论。如果你怀疑是数据库没有保存，可以写“怀疑保存环节有问题”，同时保留页面提示和列表状态等证据。这样，智能体既能参考你的线索，也不会被过早限定在某一种原因上。

复现步骤应当从起点走到结果

一份可执行的报告要交代起始条件、操作顺序和出现问题的时刻。可以从一个具体例子入手：使用普通用户账户登录，将一件有库存的商品加入购物车，提交订单，再打开订单列表。每一步都应当足够具体，让没有参与现场的人也能照着尝试。

如果问题不是每次都发生，照实写出发生频率，例如十次尝试中出现三次，并说明是否只在特定账户、设备或网络条件下出现。不确定的地方也值得标明：目前只在手机上观察到，不代表电脑上一定正常。

环境与错误信息能缩小排查范围

告诉智能体使用的是哪个应用版本、浏览器或操作系统，以及问题从什么时候开始出现。如果你知道最近有相关改动，也可以提供改动的大致时间；不知道就不要猜。版本和时间线能帮助它判断问题是否与某次变更有关。

有错误提示时，提供完整、准确的提示内容，并说明它出现在哪个操作之后。截图可以补充页面状态，但不要让截图成为唯一证据；文字更方便搜索和比较。分享日志或截图前，先移除密码、访问令牌、个人信息和其他敏感数据。

验收条件让修复有明确边界

报告还应说明修好后要看到什么。对于订单例子，最低限度是提交成功后能看到新订单；还可以要求重复提交时不产生意外的重复订单。只列与当前问题有关的条件，避免把一次修复扩展成没有边界的产品改造。

如果项目已有相关测试，请告诉智能体在哪里可以找到或由谁提供；如果你不知道，也可以直接要求它检查现有测试，并为修复补充适当的回归测试。最终请它说明根本原因、修改范围和实际验证结果。没有运行过的测试应标明未运行，不能把推测当成通过。

工具选择不能替代清晰的报告

编码智能体可能需要读取项目、运行测试或询问缺失的信息。首次交付时，说明它可以检查哪些内容，以及哪些操作需要先征得同意，例如修改生产数据或执行可能影响其他人的操作。它提出澄清问题时，补充事实通常比催促它直接修复更有效。

本文由 BestRelay 发布。它提供按质量优先设计的接口转发服务，请求会转发给所指定的官方模型，不做模型替换。服务覆盖 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等模型系列，并支持 Claude Code、Codex、Gemini CLI 和使用 OpenAI 软件开发工具包的应用。

费用按供应方报告的词元数量计量，缓存读取和写入分别计价；会员邀请的人充值后，会员可获得推荐佣金。需要接入时，可以创建一个 BestRelay 账户。无论使用哪种工具，一份包含事实、步骤和验收条件的报告，都是让修复工作可靠起步的基础。