开发者工具箱｜编程·开发工具·资源

绕过 TestFlight 万人测试上限的几种做法

TestFlight 是 iOS 生态内置的测试分发方案，但外部测试者上限为每个 App 1 万人。对多数应用够用，一旦遇到爆款或大规模公开测试，撞墙就会卡住节奏。以下方法可管理并突破这一限制。

先看限制本身：内部测试者最多 100 人，无需 Beta App Review，构建几乎即时可用，每人须为 App Store Connect 团队成员，可安装到最多 30 台设备。外部测试者每个 App 上限 1 万，通过邮箱或公开链接邀请，每个新版本的第一个构建须通过 Beta App Review。1 万上限按 App（Bundle ID）计算而非按组，可拆到最多 100 个组，但所有组共享同一名额池。若只需把构建交给少量 QA 或客户，OTA 安装链接可完全绕开审核等待。

策略一：清理不活跃测试者。1 万是活跃名额而非累计添加数，很多人装完就不再打开。在 App Store Connect → TestFlight 选择外部组，按 Status 或 Sessions 排序，删除 30 天内未安装或 0 次会话的用户。可用 fastlane pilot 脚本自动移除未启动最新构建的测试者。策略二：企业分发。面向超大型组织内部测试（如 5 万员工的公司），改用 Apple Developer Enterprise Program，可无限分发到组织自有设备，完全绕过 1 万上限。策略三：Apple Business Manager。面向 B2B 场景向特定合作伙伴或客户分发时，可私下分发应用到对方 VPP 账户，由对方通过 MDM 分发给用户。策略四：滚动式测试。有等待名单时建立轮换机制，邀请 1000 人测试两周后移除，再邀请下一批，长期可覆盖远超 1 万独立用户。终极方案：多 App ID。技术上限制按 App ID 计算，可创建 com.app.beta1、com.app.beta2 等各自独立的 TestFlight 组，但会割裂分析和崩溃报告，需管理多个应用记录，除非万不得已不建议。

若测试者数量真是瓶颈，也可完全不碰 1 万名额的数学题。BetaDrop 是免费的 TestFlight 替代方案：上传签名 .ipa 即可获得即时 OTA 安装链接和二维码，无测试者上限、无需测试者账户、无需 Beta App Review。测试者在手机浏览器打开链接点击安装即可，支持最大 512 MB 的构建，链接为临时性质，过期构建自动清理而不占名额。

撞上 1 万用户上限其实是「幸福的烦恼」，说明应用受欢迎。先从清理不活跃用户入手，若真需要大规模测试，不妨评估是否已该上架 App Store 正式发布。

#开发者 #工具 #TestFlight #iOS #BetaDrop #移动测试 #DevOps
@DevToolboxHub

2026 年 uptime 监控完整指南

监控服务是否正常响应、并在出问题时告警，目的是在客户之前发现真实故障，同时避免狼来了式的误报。指南梳理了 HTTP、keyword、heartbeat、TCP 四类检查的适用场景，以及如何用确认阈值和跨区域共识消除误报。

HTTP 检查通过请求 URL 并按状态码和耗时判断响应，适合网站和 API；keyword 检查在 HTTP 基础上断言响应体中是否包含特定词，200 但渲染错误页也会被判为宕机；heartbeat 是反向逻辑，cron 任务或 worker 每次运行 ping 监控端，预期窗口内未收到即视为宕机，适合没有公网 URL 的服务；TCP 检查则面向数据库、邮件服务器等非 HTTP 服务，直接连接主机和端口。

检查间隔通常为 1-2 分钟，单次失败很少能证明宕机——网络抖动、服务器卡顿、部署重启都可能造成瞬时故障。正确做法是要求连续多次失败才开启事件、连续多次成功才解除事件，确认窗口吸收瞬时抖动，同时快速捕获真实持续故障。宕机中途的短暂恢复不应拆成两个事件，确认恢复后再次失败则应视为新事件。

误报的另一大来源是检查的 vantage point：检查点与目标服务之间的网络问题，看起来和宕机完全一样。确认阈值能解决瞬时版本，但持续的区域性路径问题仍可能被单点误判。最强防御是从多个区域检查，且仅当多个区域一致时才开启事件。Sentivel 的做法是：配置两个及以上区域的监控会从每个区域分别检查，各区域结果先合并为共识结论再决定是否开启事件，单区域网络问题不会触发误报。配合 flap 阈值，一次宕机必须同时满足持续性和多区域可见才会告警。

监控的确认状态应驱动状态页上对应组件，让客户看到真实状态而无需人工切换。新监控在证明自己之前应显示为预热中，而不是过早显示绿色。

常见问题：HTTP 与 heartbeat 的区别在于前者主动请求 URL 并判断响应，后者由任务主动 ping 监控端、缺少预期 ping 即为信号；避免误报需连续失败才开启事件、连续成功才解除；检查频率通常 1-2 分钟一次，更频繁能更快发现但增加负载和成本，需配合确认阈值防止频率转化为噪音。

原文发布于

#开发者 #工具 #UptimeMonitoring #SRE #DevOps #Sentivel #监控
@DevToolboxHub

模板批量建站，内容为何翻车

开发者 Ravindra Reddy Chitla 分享了一次失败经历：他用模板为儿童教育网站 GamesMom 批量生成数百个页面，发布效率极高，几周后却被迫重写大量内容，返工耗时远超当初搭建。

他最初的做法是典型的开发者思维：复用组件、抽象模板、自动化重复工作。为内容站设计统一模板后，新增页面只需改标题、换内容、替换图片即可发布，流程快且可预测。
问题不在模板本身，而在于「不同页面」被默认等同于「不同价值」。许多页面标题、关键词、URL 各不相同，但读起来却在用相似方式回答相似问题。换几个段落并没有让内容更有用，精心设计的布局也弥补不了信息的重复感。
发布速度越快，越少追问一个关键问题：这个页面值得存在吗？如果删掉它对整个网站几乎没影响，那它贡献的价值就不够。速度悄悄成了目标，而它本不该是。
模板只会放大输入：一个出色的页面，模板帮你高效复制更多出色页面；一个平庸的页面，模板只会更快地制造几百个平庸页面。扩展从不创造质量，它只是放大质量。
返工比搭建更耗时。他重写整段内容、补充原创示例、扩展解释、重组信息、改进内链、清除站内蔓延的重复观点。原本不到一小时发布的页面，改善要花数小时。页面越多，清理量越大。技术债不只存在于代码，内容同样会积累债务。

他现在的做法是：模板仍用于定义结构，而非替代内容。每个页面先回答一个问题——用户在这里能找到什么别处不容易找到的信息？答不上来就不发布。这个习惯带来的内容质量提升，超过任何工作流、插件或自动化。

给内容型站点开发者的建议：模板用于一致性而非创意，复用布局而非观点；为用户的真实问题创建页面，而不是为关键词；把每个页面当作独立产品对待；定期复查旧内容，初版很少是最佳版本。发布只是开始，真正的工作往往在页面上线之后。

#开发者 #工具 #GamesMom #内容站 #模板 #SEO #技术债
@DevToolboxHub

把 Codex 工作流移植成轻量 Agentic 方法

Cole Medin 在视频里演示了一套基于 Claude Code 的 Agentic Coding 工作流。作者发现其核心价值不在 Claude，而在方法本身，于是把整套流程移植到 Codex，并整理成一篇实践记录。

原工作流的核心是「AI Layer」：仓库里存放 PRD、全局规则、参考文档、命令和 Skills，帮助编码代理理解要构建什么、如何构建、遵循哪些流程。其中命令（command）是用户显式启动的工作流，Skills 则是代理按需调用的能力。

移植到 Codex 时，作者把 Claude Code 的 Markdown 命令转成 Codex Skills，放在 .agents/skills/ 目录下，并通过 openai.yaml 里的 allow_implicit_invocation: false 禁止代理自动触发，保证 $create-prd、$prime、$execute 等流程只能显式调用。全局指令文件也从 CLAUDE-template.md 转为项目根目录的 AGENTS.md。

验证环节用一个 todo list 应用跑通全流程：先让 Codex 提问澄清需求，再用 $create-prd 生成 PRD.md，$create-rules 扩充 AGENTS.md，$prime 在新会话重建项目心智模型，随后进入 PIV 循环——$plan-feature 产出持久化计划文件，$execute 在新会话执行计划，最后运行 typecheck、lint、build、test 并用 agent-browser Skill 做界面验证。Git 提交记录则充当长期记忆，供后续 $prime 回顾项目演进。

整套方法只用 PRD.md、AGENTS.md、少量持久化计划和几个 Skills 构成，相比 BMAD 这类完整框架更轻量。作者认为，用编码代理不失控不一定需要更多自动化，少量清晰工件、显式步骤和不跳过规划与验证的纪律就足够。

GitHub

#开发者 #工具 #Codex #AgenticCoding #ClaudeCode #AGENTSMD #PIV #Skills #AI编程
@DevToolboxHub

Termux App Store：Android 上的社区包管理器

Termux App Store 是一个面向 Android 上 Termux 的社区驱动型 TUI 和 CLI 包管理器。它旨在让用户更轻松地发现、安装、构建、更新和管理社区包，解决在官方仓库中找不到或难以安装 CLI 工具的问题。

该项目采用离线优先设计，无账户、无遥测、无后台服务。它支持二进制预编译包（.deb）和源码构建两种安装方式，并提供 SHA256 校验。用户可通过 termux-app-store 或 tas 命令启动交互式界面，或使用 search、install、update 等 CLI 命令。

项目还包含 termux-build 包验证工具和 tasctl 管理器控制工具。开发者可通过 build.sh 文件定义包，并通过 PR 提交到社区仓库。目前已有 88+ 个社区包，支持 aarch64、arm、x86_64、i686 等多种架构。项目采用 MIT 许可证，独立于官方 Termux 项目。

GitHub: GitHub
PyPI: PyPI

#开发者 #工具 #Termux #Android #CLI #包管理器 #开源 #社区驱动
@DevToolboxHub

SSH 入门指南：每位 DevOps 工程师必知的核心技能

SSH（Secure Shell）是远程管理服务器、Kubernetes 节点、CI/CD 运行器和 Linux 机器的标准协议。几乎所有云服务器都通过 SSH 进行管理，它是 DevOps 工作流的基础工具。

本文覆盖 SSH 的核心概念与实操：什么是 SSH、公钥与私钥的区别、如何生成密钥对、连接远程服务器、管理 SSH 配置、使用 SCP 安全传输文件。SSH 通过加密通信解决了 Telnet 等旧协议明文传输密码的问题。连接过程分两步：服务器身份验证（首次连接时确认指纹并存入 ~/.ssh/known_hosts）和用户认证（密码或密钥认证）。密钥认证是行业标准，私钥留在本地，公钥部署到服务器，无需输入密码且抗暴力破解。
生成密钥对使用 ssh-keygen -t ed25519 -C "your_email@example.com"，生成 id_ed25519（私钥，严禁分享）和 id_ed25519.pub（公钥，可安全分发）。将公钥添加到服务器有三种方式：云平台自动注入、ssh-copy-id 命令、或手动追加到 ~/.ssh/authorized_keys。连接时使用 ssh username@server_ip，指定密钥用 -i 参数。常见权限错误可通过 chmod 400 key.pem 修复。通过创建 ~/.ssh/config 文件可简化多服务器管理，例如配置 Host my-ec2-server 后直接 ssh my-ec2-server 即可连接。SCP 命令用于安全文件传输，语法与 cp 类似，远程路径格式为 user@host:/path。

SSH 是管理云基础设施、部署应用、配置 CI/CD 和排查生产问题的安全网关，掌握它是进入 AWS、Docker、Kubernetes、Terraform 等生态的基础。

#开发者 #工具 #SSH #DevOps #Linux #SCP #密钥认证
@DevToolboxHub

你的AI聊天记录，已经完成了攻击者的侦察

在一次AI工作坊上，一位女性说ChatGPT是她最喜欢的工具，不是因为写邮件或总结文档，而是因为它“理解她”——她一直在向它咨询感情问题。当被问及“如果有人现在打开你的账户，他们会不会了解你的一切”时，她迟疑地承认了。房间里安静了下来。

她并没有粗心大意，只是按设计使用产品。而AI聊天工具的设计，恰恰产生了一份可搜索的、第一人称的私人记录：你在担心什么、谁在你生活中、你私下如何说话。过去，社会工程攻击需要花几天时间从LinkedIn等公开信息中拼凑你的画像。现在，一个AI账户就是一份你自己写好的完整简报——包括你永远不会公开发布的内容。账户本身不是攻击目标，而是已经完成的侦察。

这并非假设。Group-IB发现，2022年6月至2023年5月间，暗网市场上超过10.1万份ChatGPT凭证来自信息窃取日志，单月峰值达26,802条；次年这一数字升至约22.5万条日志文件。这些几乎都不是通过攻破OpenAI获得的，而是普通恶意软件从浏览器保存的密码中窃取的。2025年1月，DeepSeek的一个数据库在开放互联网上暴露，包含超过100万条聊天记录。同年，Meta AI用户误将“分享”当作“保存”，将医疗问题、监护权纠纷和忏悔以真实姓名发布到公共信息流。OpenAI在2025年8月因共享对话出现在谷歌搜索结果中，撤回了其可发现链接选项。2025年11月Mixpanel事件中，虽无聊天内容泄露，仅姓名、邮箱和粗略位置被暴露，OpenAI仍警告用户警惕后续的精准钓鱼。FBI在2025年5月的公告中描述了攻击者使用AI克隆语音建立信任、入侵个人账户，再以此攻击其联系人。该局在2025年记录了超过2.2万起AI相关欺诈投诉，报告损失超过8.93亿美元。
在喀麦隆，一部安卓手机就是整个网关：移动支付、WhatsApp、邮件、AI应用以及保护这一切的OTP。没有第二台设备，没有留在办公室的工作笔记本。“使用单独设备处理敏感工作”在这里不是一个权衡，而是一个不可能的选择。手机不是多个因素之一，而是所有事情成败的单一节点。银行账户有欺诈部门和撤销流程，而聊天记录没有，且它更有价值——因为它正是让欺诈变得可信的源头。

作者随后做了一些小改动：为AI账户单独设置唯一密码和2FA；停止粘贴任何能识别他人的信息（客户名、真实子域名、他人号码），改用占位符；默认关闭记忆功能，对不愿被陌生人听到的内容使用临时聊天；与两三个可能因他一句话而转账的人约定验证词。但问题依然存在：如何检测这种攻击？被盗的信用卡会留下交易记录，而有人在凌晨3点阅读你两年的对话，只会留下一个来自陌生城市的登录记录——在几乎没人打开过的设置页面上。

#开发者 #工具 #AI安全 #隐私 #社会工程 #ChatGPT #DeepSeek #MetaAI #OpenAI #FBI #喀麦隆
@DevToolboxHub

ElevenLabs 发布图像与视频工具，支持 AI 辅助发布视频制作

ElevenLabs 公开了一套多模态创意工具，包括 Image & Video（Beta）和 ElevenCreative 中的 Flows，可支持 AI 辅助的发布视频制作。团队能从提示词和参考素材生成视觉资产，再结合旁白、唇形同步、音乐和编辑工具，在同一个工作流中完成创作。

Image & Video（Beta）可从文本提示词生成图像和视频，支持参考素材输入。
Flows 在 ElevenCreative 中提供集成画布，将图像和视频模型与 ElevenLabs 的音频工具（文本转语音、唇形同步、音乐）结合。
这套组合旨在连接视觉生成和音频制作，减少传统制作中多个环节的交接成本。
需注意：Image & Video 明确标注为 Beta 阶段，素材中未提供名为 Fable 的独立产品发布计划或定价。

对于已使用合成语音工具的团队，整合视觉和音频制作能简化实验流程。实际效果取决于执行，而非仅靠生成工具本身。AI 生成的发布素材最适用于早期创意探索、本地化变体、社交片段或快速测试等场景。

#开发者 #工具 #ElevenLabs #AI视频 #多模态 #图像生成 #文本转语音 #Beta
@DevToolboxHub

用 GitHub Actions 自动部署 Laravel + Vue 到 cPanel

每次改完代码都要手动打包 ZIP、上传 cPanel、解压、跑迁移、清缓存，部署时间远超编码时间。这套方案让你只需 git push，GitHub Actions 自动完成构建、上传、迁移和健康检查。

工作流会在每次推送到 main 分支时：安装 Laravel 生产依赖、构建 Vue 和 Vite 资源、打包应用、通过 SSH 连接 cPanel、上传并解压新版本、保留生产环境的 .env 和 storage 目录、运行数据库迁移和 Laravel 优化命令、重启队列 worker、检查生产站点是否正常响应。

关键步骤：在 cPanel 生成 SSH 密钥并添加为 GitHub 仓库的 Deploy Key → 在本地生成另一对密钥，公钥加入 cPanel 授权，私钥存入 GitHub Secrets → 在仓库创建 production 环境并配置 CPANEL_SSH_PRIVATE_KEY、CPANEL_SSH_HOST、CPANEL_SSH_PORT 等 Secrets 和 APP_DIR、CPANEL_USER、PHP_BIN、APP_URL 等 Variables → 在 .github/workflows/ 下创建 deploy-cpanel.yml 工作流文件。

工作流会排除 .env、storage、public/storage、public/.well-known 等目录，确保数据库凭据、用户上传、日志等不被覆盖。安全提醒：不要将敏感信息放入 VITE_ 开头的变量，不要提交 .env 文件，不要使用 chmod 777。

首次配置需要仔细处理 SSH 密钥、路径、PHP 版本和生产环境密钥。配置完成后，日常部署简化为 git add .、git commit -m "描述变更"、git push origin main，GitHub Actions 自动完成后续所有步骤。

#开发者 #工具 #Laravel #Vue #GitHubActions #cPanel #PHP #DevOps #CICD #自动化部署
@DevToolboxHub

RAGAS 与 DeepEval 对同一编造回答给出 0 分和满分

一份 RAG 系统输出声称了上下文从未给出的定价信息。作者用两个最流行的 LLM-as-judge 忠实度指标各测五次，gpt-4o 温度 0。RAGAS 给出 0.000，DeepEval 给出 1.000，五次重复一致，并解释“实际输出与检索上下文之间没有矛盾”。两个指标都叫 faithfulness，只有其中一个发现了编造。

作者为医疗 AI 工具构建了 OpenGATE，所有检查都是输出与人工标注金标的纯函数：要求事实必须出现、数字必须可追溯、上下文无法回答时必须弃权。随后与 RAGAS 和 DeepEval 做了对照实验。

实验使用 27 个冻结输出，包含生产系统输出和注入单一已知缺陷的突变体。缺陷按范围分组，检测以注入缺陷后的反应相对于未突变输出来衡量，且输出必须在每次重复中都被标记才算检出。

法官模型在语义反转上胜出：RAGAS 捕获 4/5，DeepEval 捕获 5/5，确定性检查捕获 0/5。但在遗漏上失败：缺失的抗生素剂量不构成矛盾，法官模型捕获 0/5 和 1/5，确定性锚点检查捕获 5/5。成本方面，RAGAS 每千次评估 11.49 美元，DeepEval 8.29 美元，确定性检查免费。速度上，法官模型每次重复 194 和 119 秒，确定性检查 3.8 毫秒。定位上，确定性检查会命名失败原因，RAGAS 返回标量，DeepEval 的推理有时好有时是“没有矛盾”。

定义性差异是关键：RAGAS 问“每个声明是否都有上下文支持”，DeepEval 的 faithfulness 问“是否有声明与上下文矛盾”。编造的数字不矛盾任何内容，因此在六个输出中 RAGAS 捕获 5 个，DeepEval 捕获 0 个。团队若未阅读实现就采用 LLM-as-judge faithfulness，等于无意中选择了对哪种失败模式视而不见。

在 gpt-4o 温度 0 下，法官模型稳定性尚可，但 gpt-4o-mini 上 11/27 输出在重复间改变判定。不将构建门控放在法官模型上的理由在于遗漏盲区、定义分歧和成本，这些都不是更好的法官模型能修复的。

确定性门控在生产中捕获了：静默解析失败导致约 50% 的多声明判定默认为“不支持”；去标识引擎的两个名称捕获 bug；简化器从出院小结中删除抗生素剂量。几个月后，同一系统产生了编造的血红蛋白数值，因为之前的提示修复只禁止遗漏数字，未禁止编造数字。

作者建议两者并用：LLM 法官处理语义，确定性检查作为门控。确定性检查 MIT 许可，一行命令运行，无需 API 密钥。

Repo: github.com/nickjlamb/opengate · Paper: doi.org/10.5281/zenodo.21365095

#开发者 #工具 #RAGAS #DeepEval #OpenGATE #LLMJudge #Faithfulness #RAG #AITesting
@DevToolboxHub

OpenAI 前沿治理框架引发 AI 发展节奏讨论

OpenAI 于 2026 年 5 月 28 日发布《前沿治理框架》，阐述如何评估和缓解前沿 AI 的系统性风险，涵盖网络攻击、CBRN、有害操控和失控四个风险领域。该框架聚焦安全评估、缓解措施、报告机制、外部专家意见以及与新兴法规的对齐，但并未制定正式政策来放缓前沿模型开发。

6 月 3 日，OpenAI 又发布《前沿 AI 民主治理蓝图》，主张建立美国国家框架、强化 CAISI 并做好韧性规划。两份文件共同确立了治理方向：将前沿 AI 安全视为技术风险管理、机构监督和监管协调的结合。对于企业而言，前沿 AI 治理正成为与能力、成本、安全和集成并列的运营考量因素。部署先进模型的组织应预期系统性风险和监管问责讨论将越来越多地影响供应商评估、采购流程和内部 AI 治理。

三个实际影响：风险治理可能更具体，需针对滥用、安全暴露、人工监督和升级路径制定政策；监管对齐仍是移动靶标，跨国 AI 项目需同时关注公司实践和适用法律要求；长期规划应将政策与猜测分开，企业可准备更严格的治理预期，但无需假设模型可用性、API 或发布节奏会发生变化。

OpenAI 的治理材料未定义发展节奏的具体含义、由谁设定或适用何种机制，也未公布触发不同开发方式的模型能力阈值或国际协调机制。企业应加强 AI 风险管理、监督、安全审查和监管监控，同时避免对未公布的模型访问或 API 政策变化做出假设。

#开发者 #工具 #OpenAI #前沿AI #AI治理 #AI安全 #监管对齐 #CAISI #EUAIAct
@DevToolboxHub

用 HazelJS 构建法律文档分析器

一篇技术文章展示了如何用 HazelJS 构建一个法律文档分析器，自动完成文档解析、术语提取、风险评估和义务总结。

该工具采用多智能体架构，包含 DocumentParserAgent、TermExtractorAgent、RiskAnalyzerAgent、ObligationSummarizerAgent 和 LegalManagerAgent，后者通过 supervisor routing 协调各智能体工作。RAG 集成支持对法律文档库进行语义搜索，可识别合同类型、关键条款、风险等级等信息。

各智能体分工明确：DocumentParserAgent 提取文档结构与元数据；TermExtractorAgent 识别法律术语并提供定义与上下文；RiskAnalyzerAgent 评估风险等级并给出缓解策略；ObligationSummarizerAgent 提取义务、截止日期与责任方。系统还集成了 OpenTelemetry 可观测性、重试与熔断机制、速率限制、PII 脱敏等生产级特性。

运行方式：npm install && npm run build && npm run dev，应用运行在 localhost:3000，HazelJS Inspector 可在 /__hazel 访问。

完整项目代码和 HazelJS 文档已提供，可自行部署测试。

#开发者 #工具 #HazelJS #法律文档分析 #RAG #多智能体 #NodeJS #TypeScript
@DevToolboxHub

HazelJS 打造密室逃脱谜题设计器

密室逃脱设计师常面临谜题创建、难度平衡、渐进提示和解答追踪等挑战。开发者 Nisa Fatima 用 HazelJS 构建了一个 Escape Room Puzzle Designer，通过多智能体架构和 RAG 搜索自动生成平衡谜题。

该工具基于 HazelJS 的多智能体架构，包含五个专用 Agent：
PuzzleDesignerAgent：设计谜题（类型、难度、主题、解法）
DifficultyBalancerAgent：平衡难度和期望时间
HintProviderAgent：提供四级渐进提示（微妙、适中、直接、完整解法）
SolutionTrackerAgent：验证玩家解答，通过编辑距离计算相似度
PuzzleManagerAgent：利用 Supervisor 路由协调上述 Agent

关键功能之一是 RAG 增强的谜题搜索，使用 HazelJS 的 RAGPipeline 和 MemoryVectorStore 对谜题数据库进行语义检索。难度平衡器会根据当前与目标难度进行调整，提示系统上下文感知并追踪进度。

该工具还包含生产级特性：OpenTelemetry 可观测性、重试与熔断、限流、PII 脱敏及内容安全防护。本地运行需要 NodeJS，通过 npm install && npm run build && npm run dev 启动，在 localhost:3000 调试。

这个例子展示了 HazelJS 在多智能体协作、RAG 集成和生产级模式上的能力，适合构建创意类 AI 应用。

#开发者 #工具 #HazelJS #TypeScript #NodeJS #RAG #密室逃脱 #AI #多智能体 #游戏开发
@DevToolboxHub

NPMScan 为 AI 编码代理添加 MCP 服务器

AI 编码代理在选取 npm 包时依赖模型知识或不完整的搜索，可能遗漏安全信息。NPMScan 现在提供公共 MCP 服务器，兼容 Claude Code 等代理，无需 API 密钥，可查询包元数据、版本、安装脚本、维护者、已知漏洞及最新安全公告。

连接 Claude Code（示例）：

claude mcp add --transport http npmscan https://npmscan.com/api/mcp

确认连接：

claude mcp list

当前 MCP 工具包括：

• search_packages – 搜索 npm 包

• get_package / get_package_version – 查看元数据与版本

• query_vulnerabilities – 查询已知漏洞

• batch_query_vulnerabilities – 批量检查多个包

• get_latest_advisories – 获取最近安全公告

示例提示：检查 axios 的已知漏洞后安装；从安全角度比较 axios 和 ky；审查某个包的安装脚本与维护者；批量检查 axios、express 等依赖的漏洞；展示最新 npm 安全公告。

为其他 MCP 客户端（支持 HTTP 远程服务器）配置：

```json
{
"mcpServers": {
"npmscan": {
"type": "http",
"url": ""
}
}
}
```

仅支持本地 stdio 的客户端可使用 mcp-remote 桥接。

MCP 服务器旨在让 AI 代理在推荐或安装包之前获取结构化安全信息，不替代人工审查，但提供比模型生成知识更可靠的包情报。

#开发者 #工具 #NPMScan #MCP #安全
@DevToolboxHub

AI Agent 能调一切 API，唯独银行不行 —— 问题出在哪儿

你的 AI agent 可以读日历、提工单、查数据库，但面对银行 API 大门紧锁。问题不在银行没有 API ——PSD2 已强制欧盟银行开放接口，但认证层只为机构设计，不为 agent 服务。第三方调用银行 API 必须持有 eIDAS QWAC + eSEAL 证书，由 QTSP 签发，审批耗时数周，年费 €2,000–10,000。没有任何 agent 框架内置能生成合格电子印章的工具，也没有独立开发者会为搭一个 MCP 服务器去申请这东西。结果：agent 浪潮席卷其他所有 API，但在银行面前直接撞墙。

这解释了为什么开放银行领域被聚合器（Yapily、TrueLayer、Tink、Plaid）垄断 —— 不是技术更好，而是它们愿意且有能力承担“证书税”：买 eIDAS 证书、完成 AISP/PISP 监管注册、维护每家银行的连接器（各家对 Berlin Group NextGenPSD2 标准的实现都不相同），然后卖给你一把 REST 密钥。副作用是：银行数据成为唯一不能直接对接源头的 API 品类，合规门槛六位数起。
MCP（Model Context Protocol）让情况更尖锐。今年 agent 运行时靠 MCP 服务器注入工具：暴露几个工具，agent 发现并调用。对多数领域就是包一层 REST API 返回 JSON，但银行场景第一步就卡住 —— 包装器需要客户端证书才能完成 TLS 握手。这不是粘贴一个配置值，而是绑定到一个通过监管审查的法律实体的凭据。你发布到 registry 的 MCP 服务器不可能携带它。所以今天的“银行 MCP 服务器”只能对接聚合器，而非银行。
真正值得设计的 agent 原生银行访问模式是：无需强制 agent 栈经过中介，就能获得对自己账户数据的读取权限。PSD2 已经区分了 AIS（读取）和 PIS（写入），两者都有证书负担，但风险画像天差地别 —— 经你同意的只读余额与交易记录，和发起支付完全不同。然而两者都挡在同一堵 eIDAS 墙后。
几种可行的 agent 友好路径已在边缘浮现：1) 沙箱优先、免证书 —— 许多银行开发者门户和聚合器沙箱只需 API 密钥就能暴露测试数据，MCP 服务器可以直接发布并开发；2) AISP-lite / 托管 agent 授权 —— 由持 AISP 牌照的实体向 agent 进程发放作用域受限、绑定用户同意的只读令牌，agent 自身不持有证书；3) 免证书生产读取层 —— 用 API 密钥认证提供经同意的读取访问，证书负担由 API 提供方吸收。这正是作者通过 open-banking.io 构建的方向。
代码层面，一个 MCP 的 list_transactions 工具定义和处理器很简单：只需要 API 密钥和用户同意，无需 mTLS 或 eIDAS。难点在上游：同意流、银行连接器、让集成者跳过 eIDAS 的监管吸收层。

结论：你的 agent 能读 GitHub 但读不了银行流水，不是集成缺失，而是监管设计选择 —— 证书税。随着 MCP 生态吞噬其他 API 表面，银行将成为明显的孤岛，除非我们构建不需要每个集成者都成为金融机构的读取层。免证书、经同意、只读优先的访问是解锁点。

#开发者 #工具 #MCP #PSD2 #eIDAS #OpenBanking #APISecurity #Aggregators #AISP #PISP
@DevToolboxHub

AI Sandbox 项目一拆为三，正式独立发布

AI Sandbox Environment 原是一个单体仓库，集成了 devcontainer 模板、宿主侧 MCP 服务器和容器内脚本/工具发现服务器。作者此前已私下拆分为三个独立仓库，并基于拆分后的架构构建并交付了一款真实 iOS 应用，过程中暴露了模板所没有的实际摩擦：Xcode 构建需要宿主 OS、工具超时需要按脚本声明、复用性提升。正式版本现已公开。

三个仓库分别为：
ai-sandbox：devcontainer 模板，负责秘密隐藏、项目结构与斜杠命令，运行于 Docker（VS Code / CLI）。
hostmcp（原 DockMCP）：宿主侧 MCP 服务器，提供容器管理、宿主工具与系统命令访问，运行于宿主 OS。
sandbox-mcp：容器内脚本/工具发现 MCP 服务器，通过 stdio 运行于容器内。
拆分后两个新仓库新增了：hostmcp 的 Go 安装命令、宿主路径掩码（防止用户名泄露到 AI 视野）、危险模式（只读调试命令且仍受路径限制）、大输出处理；sandbox-mcp 则增加了嵌套 Git 仓库检测能力。
拆分理由：独立安装（已有 devcontainer 的用户可单独使用 hostmcp 或 sandbox-mcp）、独立发布节奏（hostmcp 更新不再依赖模板）、真实使用暴露真实对接——Xcode 工具与按工具超时不是设计出来的，而是撞出来的。

不变的是：.env 文件与私钥物理级缺失（非规则屏蔽）；AI 只能观察，人类操作基础设施（HostMCP 不会让 AI 自行重建镜像或执行 docker-compose up）；仍仅依赖 Docker + MCP，不锁定特定 AI 工具。

现在新项目可直接使用 ai-sandbox 模板，已有 devcontainer 的用户可单独安装 hostmcp，想发现本地脚本/工具则可安装 sandbox-mcp。

#开发者 #工具 #aisandbox #hostmcp #sandboxmcp #Docker #MCP #AI #Devcontainer #安全
@DevToolboxHub

Coding Agents：技能描述才是路由瓶颈

你的 agent skill body 写得再完美，代码示例和检索测试都通过，但模型可能压根没打开 skill body——它只看 frontmatter 那一行描述。描述只要让模型以为自己已经知道怎么做，它就执行一个简化版本；描述如果和相邻 skill 难以区分，深层的 skill 永远不会被加载。

两种故障模式要排查。一是描述本身成了可执行的步骤。例如「Verifies finished work by running tests…」模型读到就自己跑了一遍测试，不会去 body 里看更严格的 diff 检查逻辑。修复方向：描述只写触发条件（Use when…），不包含任何 procedure verb（run, check, verify）。二是描述首句相同导致一个 skill 永远掩盖另一个。例如 A「Testing best practices for this repo」、B「Testing best practices - integration harness…」，所有测试任务都匹配到 A，B 的 body 再精良也没用。需要在描述层加区分性触发词（比如明确 NOT for……）。

每一条 skill 的描述应该回答「现在要不要加载这个技能」，而不是「加载后它会做什么」。如果能从描述中直接执行，说明内容放错地方了。测试时可以让 subagent 只看描述列表，喂真实任务提示，看它选哪个 skill；如果选错、不选或觉得「描述已经告诉我怎么做」——那就是描述失败，改句子而不是改 body。
@DevToolboxHub

Volare：免构建的 Web 3D 模型查看器

Volare 是一个开源、基于 Three.js 的 JavaScript 3D 模型查看库，主打免构建、零配置。开发者只需导入库、加载模型、定制外观，即可在浏览器中部署交互式 3D 内容，无需复杂的打包工具或框架。

核心能力：
• 交互式 3D 浏览
• HDRI 环境光照
• 相机控制
• 主题自定义
• 浏览器端渲染。用法简洁——一行 import { createVolareViewer } from "volare" 即可创建查看器，随后加载模型并定制体验

GitHub

#开发者 #工具 #Volare #Threejs #Buildless #3DModelViewer #OpenSource
@DevToolboxHub