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

Cohere发布218B参数稀疏翻译模型 North Small Translate

Cohere 推出了 218 B 参数的 Mixture‑of‑Experts（MoE）翻译模型 North Small Translate，专门为机器翻译设计。模型采用稀疏架构，128 个专家中每个 token 仅激活 8 个，实际活跃参数约 25 B。支持 50 种语言，WMT26 评测得分 83.60，使用多轮自我校正可提升至 84.36。

该模型的硬件需求相对可控：4‑bit 量化版可在单个 NVIDIA B200 或两块 H100 上运行；BF16 精度需四块 B200 或八块 H100。为生产环境提供商业许可与 Model Vault 部署。

对开发者而言，North Small Translate 让翻译任务从复杂提示转为直接函数调用，减少工程成本。可通过 API 或下载权重（CC BY‑NC 4.0）进行评估。

GitHub: GitHub

🔗 原文：点击查看

#开发者 #工具 #Cohere #MoE #翻译模型 #NVIDIA #HuggingFace #PythonSDK
@DevToolboxHub

Postgres逻辑复制磁盘暴涨之谜

逻辑复制从 Postgres 10 起就是内置功能，但很少有人注意到 CREATE SUBSCRIPTION 语法里那个不起眼的 WITH 子句。它展开后有十多个选项，其中几个直接决定逻辑复制如何消耗存储资源。默认情况下，不带任何参数的订阅完全能正常工作，所以大多数生产环境的订阅都从未调整过这些选项。

问题往往在不知不觉中出现：生产系统挂着多个下游逻辑副本，某天磁盘监控突然报警，pg_replslot 目录被成千上万个匿名文件塞满。这些文件是逻辑解码过程中产生的 spill 文件——当解码事务超出 logical_decoding_work_mem（默认 64MB）的内存预算时，剩余内容会被写入磁盘。每个复制槽对应一个 walsender 进程，各自维护独立的 reorderbuffer，N 个订阅就意味着 N 份解码、N 份 spill，互不共享。

根本原因在于 walsender 必须等待事务提交记录出现，才能把完整事务交给输出插件发送给订阅端。WAL 并非按提交顺序写入，并发事务的 WAL 记录交错排列，还可能中途回滚，所以解码出的变更只能先暂存在 reorderbuffer 里。内存放不下就溢出到 pg_replslot 目录，长事务或大事务会让 spill 文件迅速膨胀。Postgres 17 及更早版本中 streaming 参数默认 off，发布端必须先把整个事务解码并存储完毕才能传输。

实测中，一个 30 万行的单事务在三个订阅节点上各产生 114MB spill 文件，发布端 pg_replslot 目录总计占用 342MB。同一份 WAL 被解码三次、写盘三次。把 logical_decoding_work_mem 调低到 64kB 后，单事务 spill 次数高达 1775 次。更隐蔽的是，事务提交后目录立即清空，只剩累计计数器，现场证据几乎为零。

Postgres 18 已把 streaming 默认值从 off 改为 on，发布端解码后直接转发给订阅端，不再本地落盘。但 TOAST 大字段仍可能触发本地 spill，只是暴露面大幅缩小。Postgres 16 起还支持 parallel 模式，变更直接交给订阅端的并行 apply worker，连临时文件都不需要。pg_stat_subscription 视图里能看到 parallel apply worker 的行，其 leader_pid 为空。

Postgres 17 及更早版本的用户只需一条 ALTER SUBSCRIPTION ... SET (streaming = on) 即可启用流式传输，无需重启，apply worker 会自动重启生效。Postgres 13 及更早版本不支持 streaming 选项，建议尽快升级。文档对 reorderbuffer 和 spill 风险的描述相当简略，DBA 排查时很难联想到这个参数。检查一下自己的订阅配置，pg_subscription 表里 substream 列一眼就能看出当前设置。

#开发者 #工具 #Postgres #逻辑复制 #数据库 #DBA #流式复制
@DevToolboxHub

PostgreSQL max_connections 详解：内存、连接数与性能的平衡

max_connections 不是决定查询并发数的参数，而是 PostgreSQL 为每个客户端后端预留共享内存的预算。默认 100，范围 1–262,143。它决定：

- 允许的客户端后端数目；
- 预留的共享内存大小（每个后端占用 PGPROC、pg_stat_activity 行、锁表等）。
- 需要在主机重启后才能修改。

在 18.6 上，默认 shared_buffers 时，max_connections=100 时共享内存约 150 MB；1,000 时 197 MB；5,000 时 389 MB。锁表占用随连接数线性增长。热备机必须与主机使用相同或更大的 max_connections，否则启动失败或在 WAL 中警告。

连接成本
空闲后端仅占约 1 MB 私有内存；活跃后端会消耗 work_mem、hash join 内存等。超过核心数的活跃连接会导致上下文切换、锁竞争，吞吐量下降。

云服务默认值
- Heroku：500 → 5,000（Advanced tier）
- AWS RDS：公式 LEAST(DBInstanceClassMemory/9531392, 5000)
- Azure：MIN(memoryGib*0.1049164697034809, 5000)
- Google Cloud SQL：16 GB 仅 500。

默认值已从 100 提升至 17–50 倍，取决于内存。建议使用 RDS Proxy 等连接池器来避免“too many clients”错误。

实践建议
1. 先在备机调高 max_connections，再在主机调高；反之则会导致恢复暂停。
2. 监控 pg_stat_activity、wait_event_type、load average，及时发现锁竞争。
3. 对高并发应用使用连接池，避免直接打开数百连接。

#开发者 #工具 #PostgreSQL #max_connections #云数据库 #RDSProxy
@DevToolboxHub

应用零改动迁EKS实测

作者把同一套 Node.js 应用从家庭 k3s 服务器迁到 Amazon EKS，应用代码、容器镜像、Helm chart 与 GitOps 交付模型全部原样保留，但平台层暴露了三个家庭环境不存在的假设：网络、工作节点规格与 AWS 访问。

测试用 Terraform 创建了最小环境：一个 EKS 1.36 集群、一个托管 AMD64 工作节点、两个跨可用区公共子网、AWS Load Balancer Controller 与 Argo CD Core。控制平面创建耗时 5 分 51 秒，CI 检查 13 秒完成，Argo CD 部署两个健康副本，并在 5 秒内纠正了一次手动扩缩容漂移（k3s 上同类测试为 42 秒）。

过程中踩了三个坑：工作节点因私有访问未开启无法加入集群；计划中的 t3.medium 被 AWS 拒绝，改用 c7i-flex.large（2 vCPU / 4 GiB）；交互式登录刷新不稳定，临时创建角色完成剩余操作后清理。预估环境成本约 0.24-0.27 美元/小时，清理脚本在测试后完整执行。

结论清晰：Kubernetes 让工作负载可移植，但网络、实例选择、身份与负载均衡集成仍需 AWS 特定工程。家庭 k3s 仍是日常学习环境，EKS 只作为短期验证目标。

#开发者 #工具 #Kubernetes #EKS #ArgoCD #Terraform #GitOps #k3s #AWS #Helm
@DevToolboxHub

OpenAI推出金融版ChatGPT

OpenAI宣布推出ChatGPT for Financial Services，这是ChatGPT Work的定制版本，面向金融服务团队，结合内置金融数据与GPT-6 Astra推理能力。

官方定位的三个核心用途：团队可用于开展研究、构建金融模型、制作定制化客户材料。三者可相互衔接，研究支撑建模，模型输出再转化为客户演示材料，减少起草、分析与沟通之间的交接。

公告未披露定价、数据源、部署选项、地区可用性及技术控制细节，也未说明是否支持导入专有数据、连接外部系统、生成电子表格或自动化审批。金融研究、模型与客户材料可能影响重要决策，团队需自行建立输出审查机制。

#开发者 #工具 #OpenAI #ChatGPT #金融科技 #GPT6Astra #AI
@DevToolboxHub

Cloudflare Workers 搭配 Hono + Supabase 实现无服务器 API

Cloudflare Workers 让你在 24/7 运行的无服务器环境中，轻松托管 API。
使用 npm create cloudflare@latest 创建项目后，直接在 Typescript/JavaScript 中编写 Hono 路由，调用 supabase-js 访问数据库。
Wrangler CLI 支持手动部署（npx wrangler deploy）或 GitHub 自动化部署，日志与可观测性已内置，无需额外 Jaeger/Prometheus。
Workers 还支持自定义域、自动邮件、Zero Trust 集成，甚至可通过 Workers AI 与 Claude 等 LLM 监控状态。

代码示例
```ts
const app = new Hono<{ Bindings: Bindings }>();
function makeSupabaseClient(c: AppContext) {
return createClient(<<yoururlhere>>, <<yourkeyhere>>);
}
async function respond<T>(c: AppContext, query: PromiseLike<{ data: T | null; error: { message: string } | null }>) {
const { data, error } = await query;
c.header('cache-control', 'public, max-age=300');
if (error) return c.json({ error: error.message }, 500);
return c.json(data ?? []);
}
app.get('/example/:param', async (c) => {
const supabase = makeSupabaseClient(c);
const { param } = c.req.param();
return respond(c, paginate(c, supabase.from('somedatabase').select('mycolumns').eq('param', param)));
});
```

资源
GitHub

#开发者 #工具 #CloudflareWorkers #HonoJS #Supabase #Wrangler #无服务器API
@DevToolboxHub

Kubernetes 正在主导企业 AI 基础设施

Kubernetes 已经成为企业 AI 推理的默认平台。随着 GPU、模型路由和 AI 运营需求的出现，Kubernetes 通过 Dynamic Resource Allocation、Kueue 和 Gateway API Inference Extension 等项目，将加速器调度、工作负载配额和模型感知路由直接嵌入核心 API，解决了资源分配、流量管理、可观测性和成本控制等运营痛点。

企业大多使用预训练模型，重点在于可靠、安全、经济地服务。Kubernetes 的控制平面已能满足调度、扩缩、身份、版本回滚等需求，AI 只需在现有微服务栈中添加相应插件即可。CNCF 的 Certified Kubernetes AI Conformance Program 已覆盖 31 家平台，证明行业已统一标准，而非创建全新基础设施。

详细技术细节与性能评估请参阅 Techstrong 的《The Great Unification》报告。

#开发者 #工具 #Kubernetes #AI #CNCF #DynamicResourceAllocation #GatewayAPIInferenceExtension
@DevToolboxHub

Claude Code 设置文件作用域揭秘

在项目目录下的 .claude/settings.json 中添加 autoMode 等键时，发现无效。原因是 Claude Code 的配置键有作用域限制，只有在对应作用域文件中才生效。
- ~/.claude/settings.json：用户作用域
- settings.local.json：本地作用域
- ~/.claude.json：全局作用域

例如 autoMode 只能在用户或本地作用域中使用，放在 settings.json（共享文件）会被忽略。
同理，useAutoModeDuringPlan、syncClaudeAiSkills、skipDangerousModePermissionPrompt 等键也只在 settings.local.json 有效。

如何正确配置
1. 将需要的键放入对应作用域文件。
2. 若想团队共享，先在 settings.local.json 验证无误，再迁移到 ~/.claude/settings.json。
3. 使用 npx @quintetkit/ccheck 检查键是否在正确作用域。

实用工具
- quartet：将 Claude Code 拆分为 Architect、Coder、Reviewer、Conflict Resolver 等角色，MIT 许可。
- mdlinkcheck：基于同一工作流构建的链接检查工具。

资源
GitHub
GitHub

#开发者 #工具 #ClaudeCode #设置作用域 #quartet #mdlinkcheck
@DevToolboxHub

Cypress 与 Grafana Cloud 监控集成

Cypress 通过插件钩子可在每个 spec 完成后获取测试结果。将这些结果转为 Prometheus 格式后，推送到 Pushgateway；Alloy 定时抓取 Pushgateway 并远程写入 Grafana Cloud Metrics。这样即可在 Grafana 中查看每个 spec 的通过/失败计数、耗时、单个测试的稳定性，并可设置告警。

关键步骤

- 在 cypress.config.js 的 setupNodeEvents 中使用 before:run 记录一次 run_id，after:spec 生成并推送指标。
- 生成的指标包括 cypress_tests_total、cypress_spec_duration_seconds、cypress_test_success 等，统一使用 spec、run_id、ci_run_id 三个标签。
- 推送通过 PROMETHEUS_PUSHGATEWAY_URL 环境变量配置；若未设置则跳过。
- 在 CI（如 GitHub Actions）中同样设置 PROMETHEUS_PUSHGATEWAY_URL，Cypress 自动使用 GITHUB_RUN_ID 作为 ci_run_id。
- Alloy 配置文件 config.alloy 设定抓取 Pushgateway 并写入 Grafana Cloud，凭证通过 GRAFANA_CLOUD_RW_URL、GRAFANA_CLOUD_USER、GRAFANA_CLOUD_TOKEN 提供。

部署示例

```bash

# 1. Pushgateway
docker run -d -p 9091:9091 prom/pushgateway

# 2. Alloy
export GRAFANA_CLOUD_RW_URL=
export GRAFANA_CLOUD_USER=YOUR_USER_ID
export GRAFANA_CLOUD_TOKEN=YOUR_TOKEN
alloy run config.alloy

# 3. Cypress
PROMETHEUS_PUSHGATEWAY_URL= npm run test:prometheus
```

在 Grafana 中即可创建面板，监控测试通过率、耗时趋势，甚至设置告警触发。

资源链接

GitHub: GitHub

#开发者 #工具 #Cypress #GrafanaCloud #Prometheus #Alloy #CI_CD #Nodejs #WebTesting
@DevToolboxHub

Google 推出 AI Ultra 订阅，提升 Gemini 与 Gmail 效率

Google 在 2026 年 I/O 会议上公布了 AI 订阅新方案。新增两档 Ultra 级别：
- $100/月：Gemini 与 Antigravity 使用量提升 5 倍，含 20TB 存储、YouTube Premium、优先 Antigravity 访问。
- $200/月：使用量提升 20 倍，包含同样福利，并可全球使用 Project Genie。

两档均支持 Gemini Spark（美国先行）和 Gemini Omni、Gemini 3.5 Flash 等模型。
新增功能：
- AI Inbox（Gmail）— 先在美国开放，后续将推至 Plus、Pro。
- Daily Brief（Gemini）— 生成基于 Gmail、Calendar 与 Gemini 对话的晨报，初期仅限美国。
- 语音功能即将加入 Gmail、Docs、Keep。

计费方式改为按 计算量 而非每日提示数，刷新周期为 5 小时；达到上限时自动降级至小模型。
Google 亦提供 按需 AI 信用 充值，支持 Antigravity 与 Flow，Gemini 版即将上线。

适用场景
- 需要高 Gemini/Antigravity 额度的开发者或创作者。
- 依赖 Gmail/Calendar 进行任务梳理的团队。
- 想通过 AI 自动化提升工作效率的企业。

详细功能与地区可用性请参阅 Google 官方 AI 订阅概览。

#开发者 #工具 #GoogleAI #Gemini #Gmail #AIInbox #DailyBrief #UltraTier
@DevToolboxHub

pgSafe：用 Go 重写 PostgreSQL 备份工具

pgSafe 是从零开始用 Go 编写的 PostgreSQL 备份工具，目标是与 pgBackRest 在常见部署场景下实现功能等价：完整与增量备份、PITR、支持 PostgreSQL 13‑18、五种存储后端（POSIX、S3、Azure Blob、GCS、SFTP）。
它遵循的核心原则：
- 只学习 pgBackRest 的规则，不复制 C 代码；
- 所有模块都封闭、公开接口最小化；
- 采用 TDD（单元、集成、端到端）保证每行代码都有意义；
- 只使用标准库与云 SDK，避免自研网络、TLS、JSON 等。

pgSafe 通过三种模式工作：
1. simple：单连接、pg_basebackup tar 流；
2. remote‑parallel：多连接读取文件，适用于无 shell 访问的主机；
3. pgSafe mode：在数据库主机上启动 worker，直接通过 OS syscalls 并行读取文件，凭证仅在内存中。

核心 invariant（如顺序、检查点、保留策略）已在 INVARIANTS.md 中列出并通过自动化测试验证。
目前处于 alpha 阶段，功能完整性与性能仍在验证中。欢迎贡献、测试与反馈。

github.com/vyruss/pgSafe

#开发者 #工具 #PostgreSQL #pgSafe #pgBackRest #Go #备份 #PITR #云存储
@DevToolboxHub

AI 语音学习助手：从单一对话到多智能体系统

通过 LiveKit、Deepgram Nova‑3、Google Gemini 与 Murf Falcon 的组合，构建了一个实时语音学习助手。它能识别用户语音、自然回应、记忆学习者偏好、提供即时练习反馈、在需要时请求人工帮助，并将数学类问题无缝交给专门的 Maths Agent。

- 记忆与个性化：使用 SQLite 存储学习者信息，支持持续更新。
- 交互练习：通过 voice‑based exercises.json 提供练习，评估结果用于跟踪学习效果。
- 人机协作：生成唯一 escalation ID，前端仪表盘实时显示总呼叫、成功与失败。
- 多智能体切换：主助手与 Maths Specialist Agent 之间保持上下文，避免重复提问。

详细实现
• 语音管道：LiveKit → Deepgram Nova‑3 → Google Gemini → Agent Tools / Memory / Specialist → Murf Falcon
• 前端采用 Next.js + React + TypeScript，Tailwind CSS 视觉反馈
• 关键技术：Silero VAD、LiveKit Turn Detector、SQLite、Google Gemini LLM
• 迭代日程：从基础对话、人格设定、前端 UI、语言支持，到人类升级、分析仪表盘、专属代理、完整文档

项目链接
GitHub

#开发者 #工具 #AI语音学习 #LiveKit #Deepgram #GoogleGemini #MurfFalcon #多智能体系统
@DevToolboxHub

Kubernetes v1.37 重大升级：Workload‑Aware Scheduling 进入 Beta

Kubernetes v1.37 将 Workload、PodGroup、Workload‑Aware Preemption 及 DRA ResourceClaims 推升至 Beta，标志着全局“全或无”调度已进入成熟阶段。核心改动包括：

- PodGroup 只排队一次：所有成员 Pod 共享同一排队行为，提升调度效率。
- minCount 可变：动态调整 gang 最小规模，支持弹性工作负载。
- CompositePodGroup API：支持多层次拓扑约束、gang 调度与预emption，天然兼容 JobSet、LeaderWorkerSet 等高级 API。
- 调度器改进：一次性运行调度算法，减少预emption 计算成本；默认预emption 现在尊重 PodGroup 的 disruptionMode。
- Controller 集成：提供统一的 controller‑integration API 与 workloadbuilder Go 库，简化自定义控制器与 WAS 的对接。
- Job 控制器升级：Job 现在可显式声明 schedulingPolicy、schedulingConstraints、disruptionMode 与 resourceClaims，支持更细粒度的调度策略。

详细实现与使用示例请参考官方 KEP 文档（如 KEP‑4671、KEP‑5732 等）。

GitHub: GitHub

#开发者 #工具 #Kubernetes #WorkloadAwareScheduling #CompositePodGroup #JobSet #DRAResourceClaims #workloadbuilder #CICD
@DevToolboxHub

PostGIS 3.7.0rc2 发布：兼容 PostgreSQL 19 Beta 3 与 GEOS 3.15.0

PostGIS 3.7.0rc2 作为即将正式发布的候选版本，支持 PostgreSQL 14‑19beta3、GEOS 3.10+、Proj 6.1+、libgmp，并在 GEOS 3.15+ 与 SFCGAL 2.3.0+ 下解锁全部新功能。若使用 postgis_raster 扩展，还需 GDAL 3+。该版本修复了自 3.7.0rc1 以来的多项错误，并引入了多项新特性：改进的 loader 参数、ST_MaxDistance 单几何变体、ST_CoverageEdges、ST_MinimumSpanningTree、ST_Multi TIN 支持、ST_CatmullSmoothing、ST_3DInterpolatePoint 等。

主要改动
• 兼容 PostgreSQL 19 Beta 3 与 GEOS 3.15.0
• 移除对 PostgreSQL 12/13 的支持
• 移除对 GEOS < 3.10 的支持
• 新增 ST_MaxDistance、ST_LongestLine 单几何变体
• ST_CoverageEdges、ST_MinimumSpanningTree 等拓扑函数
• ST_CatmullSmoothing、ST_3DInterpolatePoint 等几何处理
• ST_Multi 支持 TIN 与曲面
• ST_AsGeoJSON、ST_DumpAsPolygons 等 raster 函数改进
• 其它多项性能与安全优化

使用建议
• 确保 GEOS 3.15+、SFCGAL 2.3.0+、GDAL 3+ 已安装
• 通过 make -C regress visual-examples 生成文档
• 关注官方文档与 Cheat Sheets 以快速上手

#开发者 #工具 #PostGIS #PostgreSQL #GEOS #SFCGAL #GDAL #拓扑 #几何处理
@DevToolboxHub

OpenAI 推出 GPT‑6 Astra：更快的计算任务与多渠道部署

OpenAI 正式推出 GPT‑6 Astra，定位为在推理、编码、网络安全及专业工作上的显著提升。Astra 以 1.9 倍的速度完成 Mind2Web 计算任务，并在 OSWorld、FrontierMath 等基准上表现优异。其核心优势在于多步骤目标与计算机环境交互的能力，适用于界面导航、表单处理和操作流程等场景。

Astra 现已在 ChatGPT、OpenAI API、Microsoft Azure 与 AWS Bedrock 上逐步开放。企业可通过 ChatGPT 订阅直接体验，或通过 API 将模型嵌入内部工具与自动化流程。定价为每百万输入 token $10、输出 token $50，已包含在现有订阅额度内，Astra Pro 版面向更高阶计划。

对于业务团队，建议先在受控流程（如研究支持、草稿生成、编码协助或表单处理）中测试模型，评估质量、成本与人工复核需求，再决定是否扩展至更广泛的自动化。

GitHub: GitHub

#开发者 #工具 #OpenAI #GPT6Astra #ChatGPT #Azure #AWSBedrock #AI模型 #计算任务 #安全对齐
@DevToolboxHub

把 Cursor 变成可靠的编码伙伴

在使用 Cursor 时，直接输入 “build this” 常导致代码不符合项目结构。
核心问题：Cursor 缺乏上下文，随意填充默认模式，输出往往与实际代码不匹配。

解决方案

1. 先写 .cursorrules：在项目根目录放置规则文件，声明架构、命名、依赖等。
2. 细化任务：把大功能拆成小步骤，例如 “创建 AuthRepository 登录方法”，并给出参考文件路径。
3. 模板化提示：
- Context：功能描述
- Constraints：架构、库、命名规则
- Task：具体实现
- Reference：已有文件示例
- Output：生成代码并说明假设
4. 二次审查：生成后再让 Cursor 复查错误处理、命名一致性等细节。

实战示例
- Flutter：使用 Clean Architecture、Riverpod、Dio，生成 AuthRepository，返回 Result<User>。
- Laravel：使用 Sanctum、Repository+Service 模式，生成登录端点，返回 token。

最佳实践
- 每次只请求一个小任务。
- 保持 .cursorrules 及时更新。
- 参考现有文件，确保风格一致。
- 先让 Cursor 解释思路，再生成代码。

结论
给 Cursor 足够的上下文、约束和参考，才能让它输出可直接投入生产的代码，而不是需要重写的“半成品”。

#开发者 #工具 #Cursor #Flutter #Laravel #PromptEngineering
@DevToolboxHub