最新

其他人是否注意到 Claude 在其工作中留下了大量大段的代码注释？ 我的一些人类工程师对此表示不满，并指示 Claude 除非绝对必要，否则不要留下注释，但我很想知道大家的看法。就我个人而言，我写和读大量的代码注释，所以我对为什么这些特定的注释会冒犯我的同事感到困惑。 我有两个问题： 1. 它为什么会这样做？ 2. 你对此有什么看法？ 代理是否在为其他代理留下“面包屑”？这些注释是否能改善未来由代理生成的代码的输出，还是仅仅是一种风格选择？ 我不想陷入关于代码注释总体用途的讨论。相反，我想知道代理留下的特定注释背后是否有某种目的。

<a href="https:&#x2F;&#x2F;seaticket.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;seaticket.ai&#x2F;</a><p>自 2012 年以来，我们一直在维护开源文件同步软件 Seafile。在这十四年间，“去看看是否有人已经报告过这个问题”成了我们团队聊天中最常说的一句话。因为同一个 bug 经常会重复出现。在我的团队偶然想起“那个东西”在别处也出现过之前，GitHub 和 Discord 的问题之间没有任何联系。</p><p>SeaTicket 是我们为了解决这个问题而自行开发的产品，之后才对外开放。它将 GitHub Issues 和 Discord 与 Notion、Confluence、Linear、Jira 等其他一些来源整合到一个工作空间中。当有新问题出现时，AI 代理会汇总相关问题、过往解决方案以及知识库中的任何相关信息，并提出下一步操作建议。它不会自行发送、回复或关闭任何内容，因为它会等待建议获得批准。我们不希望发布一个可以自行与用户沟通的产品，因此我们也不要求其他人这样做。</p><p>真正困难的部分在于，如何跨越那些几乎没有共享词汇的来源匹配同一个潜在问题，例如一个两行的 Discord 评论和一个十行的 GitHub Bug 可能指向同一个 bug，但却没有任何关键词的重叠。如果 HNPs 感兴趣，我很乐意在评论区详细介绍我们是如何解决这个问题的；这是我最希望被深入探讨的部分。</p><p>它专为问题不会通过单一渠道进入的团队而设计，尤其是开源维护者，同时也适用于管理多个代码仓库和 Discord 服务器的产品和支持团队。它并非有意成为 Zendesk 或 Fin 的替代品：那些工具假设有一个支持团队在处理共享的工单队列，而我们则认为您的团队已经在使用 GitHub，并希望在那里处理问题，而不是在一个单独的工具中。所有套餐（包括免费套餐）均无按用户收费的定价。</p><p>我认为分散在不同代码仓库和 Discord 中的 bug 报告必须有一个统一的解决地点。我想了解这是否真的对您有用，或者我们是否在解决一个您并不存在的问题。我很乐意回答关于其内部工作原理的任何问题。</p>

大家最近在忙些什么呢？<p>你们现在在开发什么？<p>应用、工具、实验、奇特的副业项目，什么都可以。很想看看大家都在做什么。