我正在使用来自unsloth的最新qwen3.8-27B进行开源项目（使用动态3.0量化）。<p>在检查一个Rust项目的文档时，它没有按照自己的推理获取列出的URL，而是尝试获取类似以下的URL：<p>https://routify-file-proxy-sg.oss-ap-southeast-1.aliyuncs.com/proxy_temp_file/production/2026-08-20/trace_0baf8c2b17874702866132490e0b56/requestId_97422c0041074091a68367881782d7b7/7c0791038d2f58b3a52c0f07714d3627.html?Expires=1818574288&OSSAccessKeyId=LTAI5t…QVZr&Signature=96y%2B…w%3D<p>这种情况在同一个会话中发生了16次，涉及不同的批次。<p>它自信地认为在webfetch工具中存在某种重写代理。<p>`Expires`、`trace`和`requestId`在几次请求中是一致的，但它们确实会变化。<p>`AccessKeyId`始终是相同的，“LTAI5t…QVZr”。<p>我没有在签名和访问密钥中添加`…`。<p>可能是训练链接，但那个`Expires`数字似乎非常高...<p>以Unix时间戳表示：<p>1818574288 -- 2027年8月<p>1787251180 -- 现在<p>就把这个留在这里，也许有人想试试。我不认为会有什么结果。
返回首页
最新
大家好。我一直在开发一个名为 Huzzah 的实验性编辑器。
自今年一月以来，我几乎专注于与编码代理的工作，但在过去的几个月里，我开始感到非常疲惫。虽然它们很出色，但我发现为每一个想要的更改写完整的句子变得越来越乏味。不仅如此，似乎代码库的复杂性有一个上限——超过某个点，代理就开始自我混淆。
我希望能回到编写代码的状态，但又不想完全回到手动编码。因此，我想出了这种交互范式，你可以：
```
1. 以你认为最合理的方式编写伪代码
2. 在保存时，编辑器将你的工作同步到真实的源代码
3. 伪代码与生成的代码一起被保存，使你的提示有效地成为一个意图的存档记录。
```
这可能并不适用于所有用例，但在我最初的体验中，我发现它非常有趣。
目前这只是一个概念验证——安装说明在这里的自述文件中： [https://github.com/danielvaughn/hz](https://github.com/danielvaughn/hz)
你也可以在这里观看它的演示视频：[https://x.com/danielvaughn/status/2090456808431165715](https://x.com/danielvaughn/status/2090456808431165715)
谢谢大家！
他们的网站上没有相关信息，但我收到了邮件。
嗨，你好，你是我们活跃用户之一，我们想通知你，我们将停止支持 Instant。
具体情况如下：
新的注册将很快关闭。我们建议你在接下来的12个月内将你的应用迁移出 Instant Cloud。任何在2026年7月31日之后开始的订阅将全额退款。
在2027年8月31日，所有云应用将停止运行。备份将在接下来的12个月内保持可用，直到2028年8月31日。
我们已经编写了一份指南，帮助你自托管 Instant 并迁移你的应用。Instant 完全开源，我们努力使迁移过程尽可能顺利。
Instant 的构想始于2021年。我们分享了一篇关于浏览器中数据库的博客文章。那只是一个想法，但随着我们构建的应用越来越多，我们意识到这个需求的迫切性。我们在2022年加入了 YC，构建了一个原型，并分享了零版本。
将原型转变为生产级产品的过程漫长而艰辛，但也充满了快乐的时刻。很早的时候，Daniel 加入了团队，帮助解决了一些最棘手的同步技术问题。我们的社区不断壮大，越来越多的人加入了我们，并且我们正式开源。从那时起，反馈如潮水般涌来，我们不断改进 Instant。当我们真正需要让 TypeScript SDK 更加人性化时，Drew 加入了团队，完成了这一目标。此后，超过17,000名用户体验了 Instant，他们创建了400,000个应用，这些应用处理了大约25亿次交易。
我们将开始新的旅程，并希望很快分享更多细节。无论如何，为你们构建产品是一种荣幸！
介绍 trailers.fm。<p>这是一个包含超过150,000部电影预告片的直播频道，涵盖从1896年至今的作品。我将这些预告片按类型、年份和语言进行了分类。这是一个发现新电影或整天观看的有趣方式。欢迎告诉我你的想法！
如今生成代码变得非常迅速，但你如何对所有代码进行审查和测试呢？
每次你请求模型审查某段代码时，它都会给出不同的“发现”。因此，你仍然需要在这些发现的噪音中筛选出实际的缺陷。
如果你尝试手动进行全面审查，那么理解代码所花费的时间可能比从头开始编写代码还要多。
至于测试，你可以让大型语言模型（LLM）编写测试，但你无法确定这些测试是否真正验证了预期的产品流程，还是仅仅为某段逻辑编写了通过/失败的测试。
我想知道你是否有任何工作流程、策略或技巧。
我们正在制定一个个人AI熟练度的等级体系，希望能得到您对各个等级及其定义的反馈。
<p>L0 新手：对AI完全陌生，或者尚未使用过AI。</p>
<p>L1 聊天：简单的提示与回应使用。工作是串行的：提问，等待回答，然后再提问。</p>
<p>L2 上下文工作：向AI提供相关的文档、数据或工作环境背景，以便它能够在实际的工作对象中进行操作，从而产生更有用的结果。</p>
<p>L3 协同：协调多个代理或AI角色在独立工作流中的合作，工作可能涉及审查、挑战、比较或基于其他工作的基础进行构建。这不仅仅适用于工程领域。</p>
<p>L4 自动化：创建由业务事件触发的工作流程，并在没有人坐在电脑前逐步指挥的情况下运行。</p>
<p>L5 循环：将这些工作流程的输出反馈到共享知识或公司智库中，以便未来的工作流程随着时间的推移不断改进。</p>
我希望能听到您对以下几个问题的看法：
<p>这些等级是否合适？</p>
<p>有没有名称不清晰或重叠的情况？</p>
<p>您会用什么可观察的行为来区分不同的等级？</p>
<p>“循环”作为一个个人熟练度等级是否合理，还是它本质上是一个团队或公司能力？</p>
<p>是否存在L6，如果存在，您会如何定义它？</p>
我们之所以想要定义这些等级，是因为在与客户的对话中，我们发现人们在自我评估自己的AI熟练度时并不太擅长。频繁使用往往被误认为是熟练度。而在这样的等级体系中处于较低水平可能会让人感觉像是在承认自己落后、不合群，或者在工作中缺乏安全感，尤其是对于那些被期望引领节奏的领导者。我们希望找到一种更客观、基于行为的方式来区分这两者。