最新

嗨，HN 我创建了ShellDock，旨在简化在不同环境中设置和运行开发工具的过程。 ShellDock是一个轻量级的命令行工具，允许您定义和执行一组精心挑选的命令，用于安装或配置工具——可以把它看作是一个便携式启动器，用于重复的开发环境设置。 与其复制粘贴冗长的安装脚本或在多台机器上维护分散的设置文档，不如使用ShellDock来： - 将相关的设置命令打包成可重用的工具定义 - 以交互或非交互的方式运行它们 - 在本地机器、服务器或全新虚拟机上标准化安装 - 确保团队的环境设置可重复 一个典型的用例是在新系统上一键引导工具，如Neovim、Docker、语言运行时或基础设施依赖项。 在启动新的开发环境或配置临时环境时，尤其有用，因为一致性非常重要。 我非常希望能收到以下方面的反馈： - 命令行用户体验 - 命令定义格式 - 可能我未考虑到的实际用例 - 任何感觉笨重或缺失的地方 仓库地址： [https://github.com/OpsGuild/ShellDock](https://github.com/OpsGuild/ShellDock)

嘿，HN， 我开发了Rigour，一个开源的命令行工具，旨在捕捉AI编码代理引入的质量问题。它作为你工作流程中的质量门控运行——在代理编写代码后、发货前。 v4版本增加了深度分析功能：抽象语法树（AST）提取确定性事实（行数、嵌套深度、方法签名），大型语言模型（LLM）解释这些模式的含义（上帝类、单一职责原则（SRP）违反、不要重复自己（DRY）问题），然后AST验证LLM没有产生幻觉。 我在PicoClaw（开源AI编码代理，约50个Go文件）上运行了它： - 总共发现202个问题 - 深度分析发现88个（SOLID违反、上帝函数、设计异味） - 88/88经AST验证（零幻觉） - 平均置信度：0.89 - 完整代码库扫描耗时120秒 示例发现：pkg/agent/loop.go — 1,147行，23个函数。深度分析识别出5个不同的职责（代理初始化、执行、工具处理、消息处理、状态管理），并建议了具体的文件拆分。 每个发现都包含可操作的重构建议，而不仅仅是“修复这个”。 该工具是本地优先的——你的代码不会离开你的机器，除非你明确选择使用自己的API密钥（--deep -k标志）。 技术：Node.js命令行工具，按语言解析AST，使用JSON模式强制结构化LLM提示，AST对每个LLM声明进行交叉验证。 GitHub: [https://github.com/rigour-labs/rigour](https://github.com/rigour-labs/rigour) 希望能收到反馈，特别是来自那些在生产环境中处理AI生成代码质量的朋友们。

Eliezer 是大约 7000 行的 TypeScript 代码，采用 MIT 开源许可。 - 移动/桌面端的渐进式网页应用（PWA），支持推送通知 - 自我编辑协议 - 在聊天中构建和展示互动应用/小部件 - 任务和定时任务 - “如果明天上午 10 点晴天则通知” - 持久化的 SQLite 内存 + 自动上下文压缩 - 支持自带 LLM API 密钥（Kimi/Claude/Grok 等） - 完全可见性/控制 - 您可以查看所有工具调用，并在任何状态下中止操作 代理库： [https://github.com/Eliezer-app/eliezer](https://github.com/Eliezer-app/eliezer) 聊天库： [https://github.com/Eliezer-app/clawchat](https://github.com/Eliezer-app/clawchat) 这个聊天最初是作为 OpenClaw 的一个插件构思的，最终也写了代理。

在机器人行业，从手动的“定制”工作流程转向标准化的持续集成和持续部署（CI/CD）是扩大运营规模的关键要求。机器人CI/CD涉及自动化构建、测试和分发专门针对异构硬件的软件，比如NVIDIA Jetson或其他边缘设备。 **机器人CI/CD：关键要求：** - **硬件与软件对齐**：与传统的云CI/CD不同，机器人需要管理多样化的硬件堆栈，并确保软件（例如，ROS2包、CUDA驱动程序）与特定的传感器和电机配置兼容。 - **边缘原生管道**：CI/CD必须扩展到网络边缘的“执行层”，以处理间歇性连接和带宽限制。 - **自动化验证**：标准实践现在包括使用仿真环境（如NVIDIA Isaac Sim）在代码接触物理硬件之前进行验证，从而降低灾难性故障的风险。 **车队管理与边缘成熟度：** 根据2025年Gartner战略路线图，边缘计算已成为数字化转型的基础部分，27%的企业已经部署，预计在两年内将翻倍。然而，许多组织在关注个别用例而非统一平台方面存在困难，导致技术出现“割裂的孤岛”。如今，大多数企业处于“独立边缘”阶段，具备一定程度的物联网。部署往往是定制的，没有共享的技术或架构。虽然有一些边缘AI的部署，但它们在管理和部署方式上往往是独特的。 - **手动**：没有物联网监控；机器人运行直到故障。 - **连接**：仅云处理，延迟高（2-8秒）。 - **条件**：边缘过滤处于活动状态；基本的基于阈值的警报。 - **预测**：机器人上的机器学习推理可以预测7-14天后的故障。 - **自主**：自愈车队；边缘AI触发自主安全停机或重新规划路线。 **车队管理挑战：** - **操作连接性**：安全地管理不稳定网络上的远程设备是主要障碍，需要提供无SSH连接和实时可观察性的工具。 - **互操作性**：管理异构车队，其中不同制造商使用专有的定位和通信系统，仍然是一个重要的“机器人操作”（RobOps）挑战。 - **资源优化**：高效的车队管理需要在边缘进行亚秒级的决策（低于50毫秒），以确保在网络中断期间的安全性和韧性。