最新

Flowctl 是一个自助服务平台，用户可以通过它安全地访问复杂的工作流程，所有功能都集成在一个二进制文件中。这些工作流程可以是任何内容，例如为实例提供 SSH 访问权限、配置基础设施或自定义业务流程自动化。Flowctl 中的执行者范式使其与特定领域无关。 此次初始发布包括： - 支持 OIDC 的单点登录（SSO）和基于角色的访问控制（RBAC） - 通过 SSH 在远程节点上执行（完全无代理） - 审批功能 - 基于 Cron 的调度 - 流程编辑器用户界面 - 加密的凭据和秘密存储 - Docker 和脚本执行器 - 命名空间 我之所以构建这个工具，是因为我需要一个简单的工具来管理我的家庭实验室，尤其是在旅行时，它可以作为脚本的用户界面。在工作中，我也在寻找将重复的运维/基础设施任务转变为自助服务产品的工具。我尝试过 Backstage 和 Rundeck 等工具，但它们要么过于复杂，要么开源版本缺乏重要功能。 Flowctl 可以简单地描述为一个管道（类似于 CI/CD 系统），用户可以根据需要触发并提供自定义输入。 我很想听听你们可能如何使用这样的工具！ 演示 - [https://demo.flowctl.net](https://demo.flowctl.net) 主页 - [https://flowctl.net](https://flowctl.net) GitHub - [https://github.com/cvhariharan/flowctl](https://github.com/cvhariharan/flowctl)

发布 mcp-bash-framework 的 v0.1.0 版本，这是一个轻量级的 Bash 实现的模型上下文协议（MCP）。它允许您将 shell 脚本和命令行工具转变为与 MCP 兼容的服务器，从而实现与 AI 代理的无缝集成——无需 Python、Node.js 或其他运行时环境。 <p>主要特点： - 零依赖：可在 macOS、Linux 和 Windows（通过 Git Bash/WSL）上运行。 - 核心 MCP 支持：工具/资源/提示处理、模式验证、进度流、取消和分页。 - 自动发现脚本，便于设置。 - 脚手架生成器，帮助快速启动项目。 - 包含示例，例如基于 ffmpeg 的视频工作室。 <p>非常适合快速进行 AI 实验、原型设计或在最小环境中使用。 <p>欢迎反馈和贡献！ <p>代码库：<a href="https://github.com/yaniv-golan/mcp-bash-framework" rel="nofollow">https://github.com/yaniv-golan/mcp-bash-framework</a> 发布说明：<a href="https://github.com/yaniv-golan/mcp-bash-framework/releases/tag/v0.1.0" rel="nofollow">https://github.com/yaniv-golan/mcp-bash-framework/releases/tag/v0.1.0</a>

我曾是一名律师，负责制定一些应用程序的隐私政策。现在，我开发了一款软件，可以扫描项目并生成隐私政策。

我正在为一款客户支持产品进行早期研究，试图了解人们在 CRM 系统（如 Intercom、Zendesk、Freshdesk、HubSpot 等）中实际使用聊天机器人的情况。 对于任何与客户支持、运营或工程相关的人士： 您在 CRM + 聊天机器人设置中遇到的最大痛点是什么？ 我感兴趣的一些领域包括： 1. 答案的质量 2. 配置的复杂性 3. 聊天机器人转接到人工客服的情况 4. 速度/性能问题 5. 集成限制 6. 价格与价值的关系 7. 聊天机器人的准确性/可靠性 8. 支持团队的工作流程问题 9. 知识库的维护 10. 容易出故障的自动化 11. 聊天机器人增加工作负担而非减少的情况 我并不是想推销什么，只是在收集模式和真实的经验。 希望能听到创始人、客户体验团队、支持工程师或任何实施或维护这些系统的人的反馈。

自从我开始进行opencv-python打包项目以来，已经快10年了。将其扩展到超过1亿次下载的副项目让我意识到，安装的便捷性和适当的包分发对用户的重要性。这给计算机视觉生态系统带来了显著的推动。现在，我有了一个新想法，希望能帮助更广泛的软件工程领域中的更多人。 不久前，我意识到每当我的团队成员和朋友遇到无法轻易解决的编程问题时，我总是给出相同的建议：去GitHub看看别人是如何解决的。 开源社区中有大量未被充分利用的示例材料。开发者面临的大多数问题并不新颖。经过深入挖掘，总有人已经用代码解决了同样的问题，或者至少在某个问题或讨论线程中发布了一个解决方法。 问题在于，GitHub的搜索功能有限，仅在你已经知道正确关键词时才有效。你还需要时间和耐心去浏览和阅读所有结果，连接跨文件、库、问题、讨论和其他元数据的信息，然后将其转化为一个可行的解决方案。Stack Overflow和其他搜索工具也面临同样的限制。 大型语言模型（LLMs）改变了很多，但并没有改变这一点。它们在所有编程语言上的表现并不均衡，且训练数据总是过时。它们无法可靠地展示如何像真实项目那样结合多个库。在这些以及其他许多情况下，它们需要一个真实的、规范的代码示例，而不是为人类编写的过时文档。 这就是我开始构建GitHits的原因。它旨在处理人类和AI编码代理所面临的挑战：在真实的代码库中找到真实的解决方案，并在开源生态系统中连接各个点。 GitHits在代码层面搜索数百万个开源库，找到与您阻塞问题意图相匹配的真实代码及其周围的元数据，并将其提炼成一个示例。 初始产品目前处于私有测试阶段，支持MCP将GitHits连接到您喜欢的编码代理IDE或CLI。 它与Context7和其他通用文档搜索工具的不同之处在于： - 它围绕解除阻塞而构建，而不是一般搜索 - 它不需要手动索引工作 - 它通过Web UI为人类工作，通过MCP为代理工作 - 它在库中聚类相似示例，以便您可以看到真实工程师所走的共同路径 - 它使用多种信号对来源进行排名，以提高质量：所选来源可能是代码文件、问题和文档的组合 - 它基于真实来源生成一个高效的代码示例 它还不是完美的。目前，GitHits仅支持Python、JS、TS、C、C++和Rust。更多语言和更深入的覆盖正在开发中，我非常希望在测试版仍在形成的过程中获得早期反馈。如果您曾因一个您知道别人已经解决的阻塞问题而浪费了数小时，我很想听听您的想法。