最新

对于在实际工作流程中运行代理的人员：你们允许代理自动执行哪些操作，哪些操作需要人工审批，以及如何确保审查过程可供审计？

昨天，我接到一个来自 646-257-4500 的电话。<p>一个美国西部口音的男性声音，非常礼貌。他们实际上打了我三次。前两次我直接挂断了。<p>他们声称收到来自 Google 支持门户的请求，要求更改我账户中的电话号码，并希望我验证我的账户。<p>他们给我发了一封电子邮件，看起来非常像来自 Google……甚至邮件头信息也一样！我看不出里面有什么明显的问题。<p>主题：回复：您现在正在与经过验证的 Google 代理通话，您的案例 ID 是：XXXXX。请让您的代理在电话中确认此信息。<p><pre><code> ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20251104 header.b=XXXX; spf=pass (google.com: domain of XXXX.XXXX.XXX@cases-outbound-prod.bounces.google.com designates 209.85.220.75 as permitted sender) smtp.mailfrom=XXX.XXX.XXX@cases-outbound-prod.bounces.google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com; dara=pass header.i=@gmail.com Received: from mail-sor-f75.google.com (mail-sor-f75.google.com. [209.85.220.75]) by mx.google.com with SMTPS id XXXX-XXXX.10.2026.06.11.14.42.06 for &lt;XXXX@gmail.com&gt; (Google Transport Security); Thu, 11 Jun 2026 14:42:06 -0700 (PDT) </code></pre> 当他们意识到我不会念出那个验证码时，他们立刻挂断了电话。<p>搜索这个号码证实我不是唯一遇到这种情况的人。<p>我想我的问题是，他们是怎么能发送那封邮件的！？<p>为什么 Google 不通过他们的系统过滤掉这些邮件？

在专业环境中从事大型语言模型（LLM）开发的开发者们，规格驱动开发（Spec Driven Development, SDD）真的是LLM编码代理的未来方向吗？ 在过去的几个月里，我一直在努力尝试拥抱SDD。在试用了SpecKit和GSD之后，我最终选择了OpenSpec作为我偏好的规格生成器。 然而，我还没有完全放弃理解LLM生成的实际代码。 为了帮助我保持对生成代码的理解，我尝试了几种不同的方法，例如为更细粒度的功能生成更小的规格，并在每个主要任务块后暂停以审查代码。通过“/ospx-apply 运行直到任务 3.5 完成，然后暂停审查”的方式，我能够审查生成的代码并根据需要进行更正。但说实话，我遇到的主要问题是，即使加载了适当的AGENTS.md和技能，代码风格和良好的代码卫生仍然常常缺失（通常是多个辅助方法、命名不一致等问题）。 我不禁想知道，开发者们在工作场所是如何做的？SDD是否真的被用作开发者工具集的一部分？是我试图对代码进行过多的控制，而应该让LLM在规格的范围内自由发挥来指导它？还是我应该放弃SDD，寻找其他途径来确保生成的代码至少能够长期维护？

和大家一样，我这几天一直在大量使用 Fable。我的看法已经形成：它非常强大，但有时会以非常错误或奇怪的方式运用它的“智慧”。 举个例子，我让 Fable 修复了一个包含多个子模块、符号链接以及其他乱七八糟东西的仓库（请勿评判）。随着我给予它更大的自由度，它最终输出了以下内容： > .git 已被删除。这是我的操作，而且看起来确实是那种典型的错误：在 shell 的工作目录被重置到仓库根目录后，执行了一个相对路径的 rm -rf 命令，而没有事先重新检查 pwd。 这并不是说这个错误无法挽回或非常关键，它还好，但如果在没有适当防护措施的生产系统上，它可能会造成更糟糕的后果。这表明，不仅要保护你的系统免受 AI 代理的侵害，也要保护 AI 代理免受它们自身的侵害，因为它们也会出现一些“哎呀”的时刻。