创建 Bug
将症状、日志或观察到的回归问题转化为一个其他工程师无需猜测即可复现并修复的 Bug。
工作流
- 从请求、仓库远程源或可用的提供商工具中识别目标仓库和问题提供商。如果没有可用的可写提供商，则生成一份供应商中立的 Markdown 草稿。
- 搜索已打开和已关闭的问题，查找与行为、组件和独特错误文本相关的内容。链接一个真实的重复问题，而不是创建另一个问题。
- 检查相关代码、测试、配置和最近的更改。将观察到的证据与假设分开。
- 在安全且可行的情况下复现 Bug。记录最小的确定性步骤、输入、环境、实际结果和预期结果。切勿声称您未运行过的复现结果。
- 评估影响范围：受影响的用户或工作流、严重性、回归状态、变通方案以及数据/安全风险。明确标记未知项。
- 要求添加一个回归测试，该测试在修复前失败，在修复后通过。当仓库证据支持时，指定适当的测试层和测试夹具。
- 使用下方的模板起草 Bug。除非用户已经明确授权创建，否则在创建或修改外部工单之前，先显示最终草稿。
- 当可用时，使用原生提供商能力创建问题，然后返回其 URL。否则，返回完整的 Markdown 草稿和缺失的提供商操作。
Bug 模板
## 摘要
<一句话描述被破坏的行为和受影响的用户>
## 复现步骤
1. <最小的确定性步骤>
2. <下一步>
3. <观察到的结果>
## 预期行为
<应该发生什么，基于某个需求、测试或既定行为>
## 实际行为
<实际发生了什么，包括有用的精确错误文本>
## 影响
<谁受到影响、严重程度、频率、变通方案、回归状态>
## 证据
- <代码路径、测试、日志、截图、修订版本或链接的问题>
## 回归测试
- [ ] <特定的测试，在修复前失败，在修复后通过>
## 环境
- 版本/修订版：
- 操作系统/运行时/浏览器：
- 配置：
## 未解决的问题
- <仅列出可能影响范围和严重性的未解决事实>
安全规则
- 不要将访问令牌、凭据、个人数据或不必要的客户内容粘贴到公共问题中。
- 在日志中编辑机密信息，同时保留有用的错误结构。
- 在没有证据的情况下，不要将怀疑的原因当作事实。
- 不要实现修复、提交、推送或更改问题状态，除非用户要求。
由 aictrl.dev 构建。 此技能教授工作流；aictrl 将其付诸实践 — 基于您的待办事项、团队标准和代码库知识图谱。了解详情 →