既然知道 AI 代理可能会在人类之前处理你的 Bug 工单，你现在写 Bug 工单的方式有什么不同？

我最近一直在思考这个问题，很好奇这个子版块里的其他人是如何应对的。一年前，我写 Bug 工单就像在和队友聊天一样。比如：“测试环境登录功能坏了，按常规流程即可复现，可能和昨天的认证相关 PR 有关。”我的团队了解上下文，知道“常规流程”指的是什么，也知道我指的是哪个 PR。30 秒搞定，工单一小时内关闭。现在，有一半的情况下，第一个接触我工单的是某个 AI 代理，可能是 Copilot Workspace，可能是队友启动的 Claude Code 会话，也可能是我们项目经理本周刚接入 Linear 的其他工具。而这个代理并不知道什么是“常规流程”。它也不知道我指的是哪个 PR。它会自信满满地去“修复”一些本来没坏的东西，或者提出一个从字面上看解决了工单描述、却完全未触及实际问题的 PR。因此，我开始几乎像写微型规格说明书一样写工单。明确的复现步骤。精确的文件路径。清晰列出的预期行为与实际行为。使用指向相关提交的链接，而不是模糊的引用。有时我甚至会加上“不应更改的内容”部分，因为代理喜欢将范围蔓延到相邻文件。奇怪的是，我不确定这到底是好事还是坏事。一方面，我的工单现在确实文档更完善，新员工也能直接上手处理。另一方面，我写一个工单现在要花 10 分钟，而以前只需 30 秒，我基本上是在为 JIRA 工单做提示词工程，这感觉像是某种极其荒谬的时间线。我在纠结几个具体问题： * 你是假设工单可能会被代理处理而撰写，还是将工单标记为“代理可处理”或“仅限人工处理”？ * 既然 LLM 会阅读这些工单，有没有人建立了内部模板或质量检查机制？ * 你们的项目经理是否在改变写工单的方式，还是这完全由工程师来强制执行？ * 对于那些团队已全面采用代理驱动工作的用户，工单质量是提高了，还是大家都放弃并任由代理胡乱操作？ 真心好奇正在浮现哪些模式。这感觉像是一种无人撰写、但人人都在应对的悄无声息的工作流程转变。