编码代理是否暴露了我们规格的糟糕程度？
摘要
文章认为，AI编码代理的许多失败源于模糊的规格，而不仅仅是模型弱点。它建议，编写更清晰、更详细的工作包可能是使用编码代理的开发人员的下一个基本技能。
我开始觉得，很多编码代理的失败不仅仅是模型失败，而是规格失败。人类开发者通常可以从会议、Slack历史记录、产品直觉或仅仅是对团队工作方式的了解中填补缺失的上下文。编码代理并不真正具备这些。如果工单描述模糊，代理仍然会生成一些东西。这就是奇怪的地方：它不会停下来并说“这个规格不明确”。它常常猜测、编写代码，并让输出看起来自信满满。所以，也许下一个技能不仅仅是“提示工程”。也许是编写更好的工作包：我们要解决什么问题？什么不应该改变？哪些文件或区域在范围内？哪些边缘情况重要？“完成”到底意味着什么？代理在接触代码之前应该问什么问题？对于认真使用编码代理的人：代理是否让你编写了更好的规格/工单？还是你仍然主要给出粗略的指令，然后在事后修复输出？
相似文章
为AI编码代理编写规范的人？
本文探讨了为AI编码代理编写规范的不同方法，并向社区征集有效方法的意见。
AI编码代理是否遇到了瓶颈，还是我们衡量它们的方式出了问题？
本文探讨了AI编码代理的炒作与现实之间的差距，认为它们对于加速工作流程的某些部分有效，但在架构、调试和审查方面仍需人工监督，并质疑当前基准测试是否衡量了正确的东西。
没有人对AI编码代理进行足够测试
本文讨论了AI编码代理测试不足的问题，强调了在确保其在软件开发中的可靠性和安全性方面存在关键差距。
规格驱动的智能体编程正在悄然削弱我们监督智能体的能力
作者认为，过度依赖 AI 编程智能体会导致人类开发者逐渐丧失关键的技术直觉和代码审查技能，并提出了诸如强制手动编码日等措施，以维持监督能力。
AI代理的失败方式鲜有人论及。以下是我亲眼所见。
文章强调了AI代理工作流程中实际的系统级失败，例如上下文泄漏和幻觉细节，认为这些通常是基础设施问题而非模型缺陷。