返回首页
最新
嗨,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毫秒),以确保在网络中断期间的安全性和韧性。