用于安全运行LLM生成代码的WASM沙箱。<p>代理拥有类似bash的命令行界面，只能调用您提供的工具，并遵循您定义的限制。没有Docker，没有子进程，没有SaaS——只需通过pip安装amla-sandbox。
返回首页
一周热榜
我是在2025年初开始接触构建/编程的，那时的编程工具变得更加易用。从那时起，我认为自己作为程序员有了很大的进步，但我仍然深感冒名顶替者综合症，担心人工智能过于依赖，而我并没有真正学习。
我已经完成了一些项目，始终会审查人工智能建议的代码，每天进行不依赖人工智能的编码练习，观看YouTube视频等，但仍然不确定自己是否找到了正确的平衡，或者是否真的可以称自己为程序员。
我经常看到有人说解决方案就是完全学习编程而不依赖人工智能（即“戒断”），这可能是最好的方法，但我在想，考虑到人工智能显然正在改变程序员的定义，最优的路径是否在两者之间。
我很好奇你们在过去几年是如何处理这种平衡的。更具体地说，你们使用了哪些策略来既高效又能快速交付，同时确保花时间真正理解和学习你们所做的事情？
嗨，HN，
我一直在开发一种名为 G 的编程语言。它旨在实现内存安全和极快的执行速度，并且注重小巧的占用空间。
整个解释器是用 D 语言编写的，大小仅为 2.4MB。我之所以构建它，是因为我想要一种现代的脚本语言，既轻量又具备高级语言的安全性。
主要特点：
```
小巧：二进制文件约 2.4MB。
快速：针对 x86_64 进行了优化。
安全：内存安全执行。
标准库：包含 std.echo、std.newline 等。
```
GitHub: https://github.com/pouyathe/glang
我非常希望能从社区获得一些关于语法或架构的反馈！
为了提高人工智能代理的效率，我们需要与真实系统建立反馈循环：部署、日志、配置、环境、仪表板。但在这一点上，问题就出现了。
大多数现代应用程序并没有细粒度的权限控制。具体例子：Vercel。如果我想让一个代理读取日志或检查环境变量，我必须给它一个令牌，这个令牌也允许它修改或删除内容。没有干净的只读或能力范围访问。
而这不仅仅是Vercel的问题。我在云仪表板、CI/CD系统和围绕可信人类设计的SaaS API中看到同样的模式，而这些系统并不是为自主代理设计的。
所以真正的问题是：今天人们在生产环境中是如何限制人工智能代理的？
你们是在构建强制执行政策的代理层吗？用白名单包装API？还是只是接受风险？
感觉我们正在尝试将自主系统连接到从未为其设计的基础设施上。
我很好奇其他人在实际设置中是如何处理这个问题的，而不是理论上的探讨。
大家好，
我想要一个可靠的方法来跟踪我的收据，而不需要把它们放在一个盒子里，因此我找到了无纸化（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)
我已经是一个网络小说的读者多年了（在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生成时发现了更好的模式来保持章节之间的一致性——代理工具的方法有效，但我相信还有改进的空间。
我是一名从事光影创作的电影制作人，已有十多年经验，同时我也在为自己、朋友和同事开发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实现完全本地的客户端，并整合本地模型。
一项通过Hacker News帖子跟踪开发者对AI辅助编码情感的调查。
我喜欢看到人们在这个网站上创建并发布的小游戏。<p>为了不忘记任何一个游戏，我建立了一个游戏目录/街机，并持续维护它。<p>欢迎查看，如果你的游戏缺失，可以添加上去，也请告诉我你的想法。谢谢！
我今天再次看到提到ICElist，所以我想再试着访问一下（最初由于流量过大而无法访问）。
它是一个媒体维基网站（太棒了！）。但是我想看看它实际包含哪些信息，以及我如何能从远处进行贡献。
我从代理人页面开始。此时维基上有1574名代理人，我随机选择了大约十个进行点击。每一个页面上除了一个链接到该人的LinkedIn个人资料外，几乎没有其他信息，显然是他们自我认同的地方。可以理解，但并不算特别有趣。许多代理人确实有一些不寻常的名字，这使得在网上挖掘更多细节成为可能。
事件部分更有趣。有377个事件，包含合理的细节和描述。确实是一个值得跟踪的好东西，因为这些事件很容易被遗忘或忽视。
未识别页面也有些有趣，因为它们包含大约50名未识别代理人的照片，但关于事件甚至地点的信息并不完整。有些甚至不明显是代理人，这让我对某些提交的内容产生了质疑。
车辆部分的数据可能是最完整的，因为有1142辆车辆的车牌号码。通过更新ICElist上观察到的事件中的车牌信息，是提供有价值信息的一种低风险方式。特别是如果ICE涉及换牌，这种行为是非法的。
抵制部分也很有趣，因为它包含了各种公司如何支持ICE的具体信息。虽然个人很难或几乎不可能通过抵制产生影响，甚至记住所有那些卑鄙公司的名字，但在你即将签订商业协议时，检查一下这些信息是很有用的。
还有其他人浏览过这个网站并有一些想法吗？
想收集一些关于因人工智能被解雇的人的故事。不是那种通用的“重组”，也不是新闻稿中所说的，而是因为人工智能的真实原因。有没有相关的证据？
我的妻子计划开一家微型面包店。我们查看了生产管理软件，但要么价格昂贵，要么过于通用。实际上，小批量生产的工作流程并不复杂，因此我自己开发了一个并将其开源。
Craftplan 处理食谱（版本化的物料清单和成本汇总）、库存（批次追踪、需求预测、过敏原跟踪）、订单、生产批次计划和采购。该软件使用 Elixir、Ash Framework、Phoenix LiveView 和 PostgreSQL 构建。
在线演示： [https://craftplan.fly.dev](https://craftplan.fly.dev) （测试邮箱：test@test.com / 密码：Aa123123123123）
GitHub： [https://github.com/puemos/craftplan](https://github.com/puemos/craftplan)