嘿，HN！我上周参加了一个ATProto的聚会，作为一个对学术出版感到厌倦的半学术人士，我觉得有一个很酷的机会可以在Octopus（<a href="https://www.octopus.ac/" rel="nofollow">https://www.octopus.ac/</a>）的基础上进行开发，所以我在周末有点兴奋，构建了Octosphere。<p>希望你们中的一些人会觉得它有趣！博客文章在这里：<a href="https://andreasthinks.me/posts/octosphere/octosphere.html" rel="nofollow">https://andreasthinks.me/posts/octosphere/octosphere.html</a>
返回首页
一周热榜
我在过去几周一直在使用Clawdbot，确实觉得它很有用，但运行它让我感到非常紧张。<p>OpenClaw有52个以上的模块，并在一个Node进程中运行具有近乎无限权限的代理。NanoClaw的核心代码大约有500行，代理在实际的Apple容器中运行，并实现文件系统隔离。每个聊天都有自己的沙盒上下文。<p>这不是一把瑞士军刀。它是根据我的具体需求而构建的。你可以分叉它，做成你自己的版本。
大家好，
我想要一个可靠的方法来跟踪我的收据，而不需要把它们放在一个盒子里，因此我找到了无纸化（paperless）——但现有的无纸化人工智能项目并没有将我的收据转换为可用的数据。
于是我创建了nutlope的receipthero的一个分支（实际上这是一个完整的重写，唯一保留的就是系统提示）。这个项目的目标是成为一个一站式服务，自动检测标记的文档并使用模式定义将其转换为JSON——这包括发票……我现在想不出其他的了，也许你能想到？如果有，请提出一个问题！
我非常欢迎任何反馈或问题，谢谢！
（附言：我确保它的设置非常简单，使用dockge/basic docker-compose.yml）
仓库链接： [https://github.com/smashah/receipthero-ng](https://github.com/smashah/receipthero-ng)
教程链接： [https://youtu.be/LNlUDtD3og0](https://youtu.be/LNlUDtD3og0)
一项通过Hacker News帖子跟踪开发者对AI辅助编码情感的调查。
Gigacode 是一个实验性的、纯粹为了好玩而创建的项目，它使 OpenCode 的 TUI + web + SDK 能够与 Claude Code、Codex 和 Amp 一起工作。
这不是 OpenCode 的一个分支，而是实现了 OpenCode 协议，并通过运行 `opencode attach` 来连接服务器，将 API 调用转换为底层代理。
我们构建这个项目是为了满足我们在不同任务之间快速切换编码代理的需求。例如，我们发现：
- Claude Code 是最佳的执行者和快速迭代者
- Codex（高版本）最适合复杂或长时间运行的任务
- OpenCode 适用于精确调整、完全按照我说的方式进行编辑
我个人认为，在 2026 年，工具的选择几乎与模型本身一样重要。OpenCode 允许你更换模型，但 CC 和 Codex 的工具 + 系统提示在实际应用中会产生很大的差异。
在技术层面上，这一切都由我们的 Sandbox Agent SDK 提供支持：
- Sandbox Agent SDK 提供了一个通用的 HTTP API，用于控制 Claude Code、Codex 和 Amp
- Sandbox Agent SDK 暴露了一个与 OpenCode 兼容的端点，使 OpenCode 能与任何代理进行通信
- OpenCode 通过 attach 连接到 Sandbox Agent SDK
我想强调的是：Anomaly 团队在 OpenCode 代理 + Zen + Black 上做了出色的工作。我会根据任务的不同，定期使用 OC、CC 和 Codex。Gigacode 之所以能够实现，是因为 OpenCode 极其灵活、可定制且文档齐全。
试试看：
```bash
$ curl -fsSL https://releases.rivet.dev/sandbox-agent/latest/gigacode-install.sh | sh
```
查看项目、架构和其他安装选项：
[https://github.com/rivet-dev/sandbox-agent/tree/main/gigacode](https://github.com/rivet-dev/sandbox-agent/tree/main/gigacode)
我是一名从事光影创作的电影制作人，已有十多年经验，同时我也在为自己、朋友和同事开发ArtCraft。
我所有的电影学院朋友都充满了雄心壮志，但制作行业的金字塔结构并不允许个人才能轻易展现。虽然有10,000名学生进入电影学院，但只有少数人能够以完全自主的方式执导自己想要的项目——而且几乎从未能获得足够的预算来实现他们的创意愿景。此外，行业内也存在很多裙带关系。
人工智能是电影行业的个人电脑时代，是数字音频工作站（DAW）。
我的一位朋友曾与真人演员一起进行过逐帧动画：
[链接](https://www.youtube.com/watch?v=Tii9uF0nAx4)
Corridor团队在这项技术上展示了很多创造力：
[链接1](https://www.youtube.com/watch?v=_9LX9HSQkWo)
[链接2](https://www.youtube.com/watch?v=DSRrSO7QhXY)
[链接3](https://www.youtube.com/watch?v=iq5JaG53dho)
我们自己也在制作一些搞笑短片：
[链接1](https://www.youtube.com/watch?v=oqoCWdOwr2U)
[链接2](https://www.youtube.com/watch?v=H4NFXGMuwpY)
秘密在于，许多工作室已经使用人工智能超过一年了。你可能没有注意到，他们也不会告诉你，因为这存在污名化。这就像“坏假发谬论”——只有在它很糟糕时你才会注意到，而他们永远不会告诉你其他情况。
Comfy很不错，但我与一些不擅长节点图的人合作，他们要么没有足够显存的显卡，要么无法管理Python依赖。基础模型都相当有竞争力，并且变得越来越可控——这才是关键——控制。因此，我一直在致力于用户界面/用户体验的控制层。
ArtCraft拥有2D和3D控制界面，其中3D部分可以作为强大且直观的ControlNet，用于“图像到图像”（I2I）和“图像到视频”（I2V）工作流程。这几乎就像所见即所得（WYSIWYG），我相信这就是技术将为创意专业人士发展而非以文本为中心的提示的方向。
我对像Gimp和Blender这样的工具感到沮丧已经有一段时间了。我不是用户体验/用户界面的专家，但我从来不喜欢复杂的工具——尤其是复杂的开源工具。商业级工具更好。Figma非常出色。一个为创意人士设计的集成开发环境（IDE）应该是简单、神奇且强大的。
ArtCraft让你可以轻松地从各种创意画布和资产库中拖放内容。它快速且直观。在文本到图像的快速原型制作、图像编辑、3D生成到3D合成之间的切换非常流畅。它更像是“创作”，而不是提示或节点图的巫术。
作为一款桌面应用，ArtCraft允许我们让你登录第三方计算服务。我非常支持使用和整合你所订阅的模型，无论你在哪里拥有它们。这让我们能够整合WorldLabs的Marble Gaussian Splats，例如，而其他人并没有做到这一点。我的计划是随着时间的推移添加每个提供商，包括像FAL和Replicate这样的通用API密钥计算提供商。我不在乎你是否为ArtCraft付费——我只希望它能对你有用。
两个声明：
ArtCraft是“公平源代码”的——我希望走Cockroach DB的路线，最终获得资金，但保持工具本身100%源代码可用，供人们自行构建和运行。就像Obsidian，但有源代码。如果我们做大了，我会花很多时间制作电影。
目前ArtCraft依赖于一个轻量级的云服务——我对此并不满意。这是一个选择，以便我可以重用一个旧项目并快速推进，但我打算很快让它完全离线工作。所有服务器代码都在单一代码库中，因此你可以自己运行一切。随着时间的推移，我确实设想一个便携的开源云，用于各种AI工具的读写，就像一个资产的Github，但这只是一个遥远的想法。
我在代码库中写了关于路线图的内容：我希望为每个计算提供商开发集成，重写前端用户界面/用户体验，使用Bevy实现完全本地的客户端，并整合本地模型。
我已经是一个网络小说的读者多年了（在Royal Road上花了太多时间），我一直在思考一个问题：哪些大型语言模型（LLMs）真正能够创作出让人想要继续阅读的小说？这就是我创建Narrator的原因（<a href="https://narrator.sh/llm-leaderboard" rel="nofollow">https://narrator.sh/llm-leaderboard</a>)——一个让LLMs生成连载小说并根据真实读者的参与度进行排名的平台。
事实证明，这个问题的答案出乎意料地难以找到。创意写作并不是单一的能力，而是一个流程：头脑风暴 → 写作 → 记忆。你需要生成有趣的前提，用优美的文笔将其执行，并在长篇叙事中保持一致性。大多数基准测试都是孤立地测试这些能力，但读者体验的是一个整体。
当前的评估环境是支离破碎的：
像FictionLive的记忆基准测试使用选择题来检查模型是否能在长上下文中记住情节细节。这是有用的，但记忆只是良好小说所必需的条件，而不是充分条件。一个模型可能在回忆方面表现出色，但仍然写出无聊的故事。
来自Novelcrafter等工具的作者使用数据表明了作家们偏好的模型作为副驾驶。但这只衡量了人类与AI合作时的实用性，而不是产生引人入胜的独立作品。作者和读者的需求是不同的。
将LLM作为评判者是评估散文质量的最常见方法，但在创意作品中却 notoriously 不可靠。模型存在系统性偏见（偏好冗长的文风、某些结构），而“好写作”在某种程度上是主观的，这与“正确的代码”截然不同。
缺少的是一个从读者角度出发的定量基准——一种衡量真实人类是否真正享受这些模型所创作内容的工具。这正是Narrator所填补的空白：浏览量、阅读时间、评分、书签、评论、回访次数。可以把它看作是一个“AI Wattpad”，其中模型就是作者。
五个月前，我在这里分享了一个基于DSPy的早期版本（<a href="https://news.ycombinator.com/item?id=44903265">https://news.ycombinator.com/item?id=44903265</a>）。最大的教训是：一次性生成不适合长篇小说。模型会丢失情节线索、忘记角色，且章节之间的质量会下降。
重写：从一次性生成到持久的代理循环
当前版本通过一个写作工具对每个模型进行处理，保持章节之间的状态。在生成之前，代理会审查结构化的上下文：角色表、情节大纲、未解决的线索、世界构建笔记。在生成之后，它会更新这些文档以便于下一章使用。基本上，每个模型都获得一个贯穿整个故事的“作家笔记本”。
这带来了可衡量的差异——在一次性版本中挣扎的模型在获得自己笔记的情况下显著改善了一致性。
细粒度过滤而不是单一评分：
我们在前期对故事进行分类，包括语言、类型、标签和内容评级。我们不再只有一个“创意写作”排行榜，而是可以深入具体：哪个模型写的西班牙喜剧最好？哪个模型对男性主角的LitRPG故事处理得最好？哪个在浪漫与恐怖之间表现更佳？
答案并不总是符合你对一般基准的预期。有些模型在整体排名中处于中游，但在特定细分领域中却表现出色。
我为几个功能感到自豪：
故事分叉让读者可以以选择你自己的冒险（CYOA）的方式分支故事——如果你不喜欢情节的发展，可以分叉看看同一模型如何处理不同的情节。这创造了自然的A/B比较。
视觉化的LitRPG是我个人想要解决的问题。与其用一堆[STR: 15 → 16]的文本，不如将统计数据和技能树呈现为实际的用户界面元素。例如：<a href="https://narrator.sh/novel/beware-the-starter-pet/chapter/1" rel="nofollow">https://narrator.sh/novel/beware-the-starter-pet/chapter/1</a>
我在寻找的：
更多的读者来扩展参与数据。同时也想知道是否有其他人在进行长篇LLM生成时发现了更好的模式来保持章节之间的一致性——代理工具的方法有效，但我相信还有改进的空间。
我是在2025年初开始接触构建/编程的，那时的编程工具变得更加易用。从那时起，我认为自己作为程序员有了很大的进步，但我仍然深感冒名顶替者综合症，担心人工智能过于依赖，而我并没有真正学习。
我已经完成了一些项目，始终会审查人工智能建议的代码，每天进行不依赖人工智能的编码练习，观看YouTube视频等，但仍然不确定自己是否找到了正确的平衡，或者是否真的可以称自己为程序员。
我经常看到有人说解决方案就是完全学习编程而不依赖人工智能（即“戒断”），这可能是最好的方法，但我在想，考虑到人工智能显然正在改变程序员的定义，最优的路径是否在两者之间。
我很好奇你们在过去几年是如何处理这种平衡的。更具体地说，你们使用了哪些策略来既高效又能快速交付，同时确保花时间真正理解和学习你们所做的事情？
我最近发现了一个小型的ESP32项目，觉得其设计理念非常有趣。<p>BPU（批处理单元）是一个轻量级的嵌入式调度核心，专注于在压力下保持输出管道的稳定（如UART背压、带宽限制、突发生产者）。<p>它并不通过阻塞或扩展无限队列来处理，而是：强制每个时钟周期的字节预算，合并冗余事件，在持续负载下优雅降级，并提供详细的运行时统计信息。<p>该代码库包括设计笔记、流程图和实际执行日志，使得运行时行为非常透明。<p>代码库链接：
<a href="https://github.com/choihimchan/bpu_v2_9b_r1" rel="nofollow">https://github.com/choihimchan/bpu_v2_9b_r1</a><p>我一直在为它开发一个ESP-IDF后端，阅读文档让我对小型系统中的可观察性和背压处理有了很多想法。<p>想知道其他人对这种方法的看法。
你好，HN。我是Maxime，LimaCharlie的创始人（<a href="https://limacharlie.io" rel="nofollow">https://limacharlie.io</a>），我们是一个为安全运营提供基础构件的超大规模平台，就像AWS为IT所做的那样。
我们在平台上开发了一款新产品，旨在解决一个紧迫的问题，充当你们的人工智能与外界之间的护栏：Viberails（<a href="https://www.viberails.io" rel="nofollow">https://www.viberails.io</a>）。
这里的朋友们可能对此并不陌生，但我们识别出了团队在使用AI工具时面临的四个挑战：
```
1. 审计工具的操作。
2. 控制工具调用（及其对世界的影响）。
3. 集中管理。
4. 轻松访问上述内容。
```
进一步解释：
审计日志是安全的基础，但在AI工具中，这一方面尚未跟上发展。能够在事件发生后回顾并说“实际上发生了什么”在事件处理和合规性方面极为重要。
工具调用是大型语言模型（LLM）与外界交互的方式，我们应该能够对其施加基本控制，例如：不读取凭证文件、不发送电子邮件、不创建SSH密钥等。能够不仅查看这些调用，还能阻止它们，对于防止事件发生至关重要。
一旦超出单一贡献者在一台设备上的操作，问题就变成了：如何通过为团队创建一个权威配置来扩展流程。拥有一个集中存放所有审计、检测和控制政策的地方变得至关重要。这与雪花服务器的情况类似。
最后，市场上有很多公司提供部分解决方案，但它们大致可以分为两类：
```
- 它们没有处理上述的“集中”点，意味着它们只是将信息发送到syslog，所有复杂的基础设施问题都留给你自己处理。
- 它们被“预约演示”、销售团队、合同以及随之而来的所有浪费精力的事情锁住。
```
我们开发了Viberails来解决这些问题。以下是它的特点：
```
- 开源客户端，使用Rust编写。
- 使用Curl进行安装，分享一个URL给你的团队以加入，完成。支持Linux、MacOS和Windows。
- 检测本地AI工具，你可以选择要安装的工具。我们为每个相关平台安装钩子，这些钩子使用CLI工具。我们支持所有主要工具（包括OpenClaw）。
- CLI工具将webhook发送到你在LimaCharlie的团队（称为组织）。与工具相关的钩子是阻塞的，以便进行控制。
- 阻塞webhook的往返时间大约为50毫秒。
- 你的LimaCharlie租户记录交互以便审计。
- 我们为你创建一组初始检测规则作为示例。默认情况下，它们不阻止。你可以创建自己的规则，没有不透明的黑箱。
- 你可以在云中查看审计、警报等。
- 你可以设置输出，将审计、阻止事件和检测发送到你选择的各种其他平台。简化版即将推出，目前这是在主LimaCharlie用户界面中完成的，而不是简化的Viberails视图。
- 检测/阻止规则支持各种操作符和逻辑，具有高度可定制性。
- 所有数据保留一年，除非你删除租户。数据中心位于美国、加拿大、欧洲、英国、澳大利亚和印度。
- 社区版的唯一限制是全球吞吐量为10kbps。
```
试试吧：<a href="https://viberails.io" rel="nofollow">https://viberails.io</a>
代码库：<a href="https://github.com/refractionPOINT/viberails" rel="nofollow">https://github.com/refractionPOINT/viberails</a>
总之，我们希望为各种开发者和团队提供一个超级简化的解决方案，让他们能够接触到保护其AI工具的基本内容。
感谢阅读——我们非常高兴能与社区分享这一内容！如有任何问题或反馈，请在评论中告诉我们。