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

AWS Launch Wizard 简化云部署流程

AWS Launch Wizard 是一项引导式部署服务，帮助用户在 AWS 上部署受支持的应用程序与基础设施。用户通过引导界面填写应用需求，服务即可推荐合适的资源、校验配置、估算成本，并在确认后完成部署，省去手动配置 EC2、VPC、子网、安全组、存储等环节的繁琐工作。

支持的工作负载包括 Microsoft SQL Server、SAP、Microsoft Active Directory、Remote Desktop Gateway，具体可用项取决于 AWS 区域。

工作流程为：填写需求 → 资源推荐 → 配置校验 → 成本估算 → 部署。部署过程使用 AWS CloudFormation 完成资源编排，生成的模板可复用，便于在开发、测试、生产环境建立一致的基础设施基线。

关键能力包括：根据 CPU、内存、带宽、存储性能等需求推荐实例类型与 EBS 卷；提供基于按需定价的成本估算，配置变更时同步更新；部署前进行早期校验，提前发现资源配额不足或基础设施不满足前置条件等问题。

适用场景方面，学生团队部署 SQL Server 数据库项目时，可指定 CPU、内存、存储、节点数等需求，由服务推荐基础设施并给出成本估算；企业部署高可用 SQL Server 时，可跨多个可用区配置 Always On 可用性组，提升故障恢复能力。

需要注意：Launch Wizard 本身不额外收费，但生成的资源（EC2、EBS、网络等）会产生 AWS 费用；它简化部署但不替代对 VPC、IAM、EC2 等基础概念的理解；不构成完整的自动扩缩容方案；安全责任仍由用户承担，需自行管理 IAM 权限、安全组与凭据。

对刚接触 AWS 的开发者来说，Launch Wizard 提供了一个观察多个 AWS 服务如何协同组成完整应用环境的实际案例；对需要重复部署相似环境的企业，它也能减少手工配置工作量，让部署过程更可重复、更可控。

🔗 原文：点击查看

Postgres 开发活动数据盘点

Postgres 开发者 Tomas Vondra 在博客中发布了一组关于项目开发活动的统计图表，覆盖 pgsql-hackers 邮件列表和 git 仓库两个维度，量化了社区多年来的变化趋势。

邮件列表消息量从早期每天约 25 条增长至目前约 100 条，峰值可达每天 200 条，出现在每年 3 月（下一大版本特性冻结前）。消息总大小在 2009 年前保持平稳，之后约翻倍至每天 200kB，2016 年起逐步增长至约 2MB/天。

附件方面，每条消息的附件大小从约 10kB 增至约 80kB；带附件（很可能为补丁）的消息占比从 2008 年前约 5% 升至约 25%。补丁拆分趋势明显，平均约 1.6 个部分，90% 补丁为单一部分，99% 少于 10 个部分，但存在多达 76 个部分的补丁。

git 提交方面，每周约 50 次提交，2010 年约为每周 25 次，增长与活跃提交者数量同步（同期约增长 2 倍）。提交大小多数时间稳定在每周约 512KB，但每年 5 月会出现约 20MB 的峰值，对应翻译文件更新。1996 至 2026 年间，仓库累计新增约 440 万行（含注释、文档、测试等，非仅代码行）。

这些数据印证了社区规模与开发节奏的持续增长，也反映出补丁提交和讨论方式随 commitfest 机制引入而发生的变化。

🔗 原文：postgr.es/p/9uw

K8s 代理修复：写权限易，验证难

给 AI 代理开放集群写权限如今已不复杂，真正难的是确认变更确实生效、没有产生意外的重复效果，并且最终达到了运维人员想要的结果。业界目前只交付了前半部分，后半部分却被忽略了。

四层验证，而非一个结果

代理不应仅凭工具调用成功就推断修复成功。一次返回“成功”的调用，并不能证明集群状态已按预期改变、只改变了一次，也不能证明应用真的恢复了。这其实是四个独立的事实：调用被接受、状态无重复地改变、期望状态已验证、服务结果已验证。把四者混为一谈，代理的下一步决策就可能建立在错误的世界图景上。

意图缺口比执行缺口更隐蔽

即使代理完整走完上述四层——调用成功、状态干净变更、预期条件已验证——结果仍可能偏离运维人员的真实意图。例如，代理被要求停止崩溃循环，可能直接把 deployment 缩容到零。崩溃循环确实解决了，服务也下线了。执行完美无缺，结果却是失败，因为代理意图与运维意图从未对齐。因此结果验证不能只问“我的操作是否产生了预期效果”，而要问“系统是否收敛到运维人员真正想要的状态”。这需要代理对照独立的服务健康信号（错误率、SLO 延迟、合成事务、队列深度或业务指标）来检查，而不是对照自己的预期。

闭环作为设计契约

好消息是答案的形态已知：这些是分布式系统老问题的新外衣，新的是调用者，不是故障模式。两个机制承担主要工作，且解决不同问题：幂等性——由编排层将客户端提供的操作键与变更及结果持久关联——在确认丢失或请求重试时减少重复效果，对非天然幂等的操作（相对变更、重复回滚、多步流程）尤其重要；后置条件验证——系统在重新观察集群并确认期望状态前不宣布修复成功——解决的是代理误信工具返回值的另一类失败。生产级代理修复还应暴露结构化的生命周期状态，而非简单的成功/失败响应。

🔗 原文：点击查看

Auterix：让AI编码助手守住架构约束

用 Cursor、Claude Code 或 Copilot 改代码时，会话超过十几轮后，模型常会忘记你开头定下的架构约束——覆盖核心工具文件、重复实现已有函数、改 A 文件不管 B/C/D 是否被破坏。作者认为问题不在模型能力，而在上下文没有被当作协议契约对待，于是开源了 Auterix 来强制 AI 在执行前先验证上下文。

会话上下文窗口有限，5–10 轮后早期约束会被新信息挤掉优先级。单文件修改没问题，多文件改动就暴露弱点：助手忘记代码库的特定错误处理模式、不知道某个工具已存在而重复实现、套用与自定义配置冲突的框架约定。

作者在 Next.js 项目里同时用 Claude Code、Cursor 和 GitHub Copilot，三者的规则文件各不相同（.cursorrules、CLAUDE.md、.github/copilot-instructions.md），中途切换工具时新助手对项目的理解不一致，一周内出现静默回归、重复解释架构决策、代码评审兜底本应前置拦截的漂移。

Auterix 强制四阶段工作流：先让助手说明要改什么、为什么，重读代码库相关部分并核对规则文件；再生成明确的 diff 展示改动范围；你确认后它才动文件；执行后跑测试、检查级联失败并回报。把「希望助手记得约束」变成「助手证明它理解了约束」。

工具还提供 npx auterix doctor 诊断，检查各工具配置是否同步、Git hooks 是否就位、规则文件是否匹配、上下文 SHA-256 哈希是否变化、是否有违反规则的未提交改动等。Web Studio 可在线选技术栈配置规则并导出 .cursorrules，无需安装 CLI。

Auterix 为 MIT 协议开源，纯 Node.js ESM，无运行时依赖，支持同步 21 种 AI 编码工具的规则配置。作者同时在做商业版 Auterix Pro，提供生产蓝图、常见框架预置防护和 CI/CD 集成，核心功能保持开源免费。

GitHub

🔗 原文：点击查看

AI Agent 失败根源在上下文缺失

2026 年构建一个可用的 AI Agent 已接近解决：持久状态、沙箱执行、可观测性都成了平台原语，不再是耗时数季度的工程。真正让 Agent 在生产环境翻车的不是模型，也不是脚手架，而是缺失的上下文——代码和工单之外的那些决策、讨论与团队隐性知识。解决办法是构建一个专门的上下文层。

基础设施已被 Cloudflare Agents SDK、Vercel AI SDK、Mastra 等平台和框架商品化。如今定义一个 Agent 基本只剩四个决定：用哪个模型、什么指令、哪些工具、代码跑在哪。

Agent 失败是因为它基于组织的不完整图景做推理。典型场景：Agent 被要求排查 QA 流水线性能回退，它查了工单和代码，自信地建议重新启用异步分发——但几天前正是这个改动导致过宕机，工程师特意禁用了它。这个决定只存在于 Slack 线程和事后复盘工单里，Agent 读的代码中根本看不到。

2026 年 7 月提交的 arXiv:2607.14275 论文系统验证了这一点：可测量的上下文属性直接预测失败模式——grounding sufficiency 预测幻觉抵抗，guardrail coverage 预测操纵抵抗，instruction consistency 预测指令遵循，tool-schema quality 预测工具调用正确性。Agent 不是单独失败的，是它的上下文先失败了。

MCP 解决的是访问问题，不是理解问题。原始连接器输出会淹没上下文窗口、把冲突裁决推给模型。上下文层位于 MCP 连接的源与 Agent 之间，做检索、调和、排序和权限限定，让 Agent 基于经过核验的摘要推理，而不是面对数据洪流。

落地五步：先加追踪，完整读取 Agent 运行轨迹；盘点组织里决策实际存放的位置；通过 MCP 或直连接入可搜索存储；在检索前定义冲突规则（时效、来源权威性、人工覆盖）；按任务返回排序、权限校验、综合后的摘要，并用论文中的四个上下文质量属性做发布前检查。

如果你在 2026 年构建真实业务 Agent，稀缺资源不再是脚手架，而是组织上下文。把省下的基础设施时间花在审计 Agent 能看到什么上，把每次「自信地错」当作上下文 bug 而非模型 bug。先看追踪，连接孤岛知识，集中调和，交付摘要而非数据洪流。

🔗 原文：点击查看

Cursor 推出代码托管服务 Origin

Cursor 于 2026 年 8 月 17 日发布 Origin 早期测试版，这是一套内置于 Cursor 应用的 Git 兼容代码托管服务，支持仓库、Pull Request、代码浏览，并与 GitHub 双向实时同步。Origin 面向所有付费 Cursor 套餐（Pro、Teams、Enterprise）分阶段开放，无免费层。上线当天恰逢 GitHub 全球性宕机约 8 小时。

Origin 的入口是新增的 Codebase 标签页。用户可直接在 Cursor 内创建仓库、推送代码、发起和审查 PR、浏览与搜索代码库，无需离开应用。仓库与普通 Git 仓库行为一致，可本地 clone、添加 Origin 为 remote 并从命令行推送。

Origin 支持两类仓库并存：在 Cursor 内创建并托管于其基础设施的 Origin 仓库，以及连接 GitHub 账号后拉入的 GitHub 同步仓库。同步仓库实时更新，推送仍走 GitHub，GitHub 保持为同步仓库的事实来源；PR 与评论双向同步，可随时断开同步。

与 GitHub 同步的仓库中，Cursor 的 agent 可直接回答关于所浏览代码的问题、做出修改、更新 PR 或推送分支，无需本地 clone。官方称更深层的 agent 原生能力（理解 agent 编写代码的工具、自动将 PR 推向可合并状态的自动化）即将推出。

启动时已接入 Vercel、Depot 与 Buildkite：每个 PR 可获得 Vercel 预览部署，Depot 与 Buildkite 可运行现有 GitHub Actions 工作流，Buildkite 还支持其原生流水线。

本次发布也是 Cursor 作为 SpaceX 全资子公司后的首个产品。据 The New Stack 报道，SpaceX 对 Cursor 的收购（报道称 600 亿美元）于 2026 年 8 月 14 日正式完成，三天后 Origin 上线。

Origin 工程师 Tomas Reimers 在 Hacker News 上承认，当前托管功能与 GitHub 差异「非常小」，团队有意在功能上正面竞争；真正的差异点在于仓库、PR 与 coding agent 同处一个产品。若你已在付费使用 Cursor，开启 GitHub 同步无需额外成本，即可让 agent 进入 PR 工作流；但现阶段仍不宜将其作为关键生产仓库的主托管，agent 原生能力尚在路线图上。

🔗 原文：点击查看

Kubernetes v1.37：Memory QoS 进入 Beta 并默认开启

Kubernetes 1.37 将 Memory QoS 升级为 Beta，并在所有节点上默认启用。该功能利用 cgroup v2 的内存控制器，为内核提供更精准的容器内存管理指引。默认情况下，kubelet 不会写入 memory.high、memory.min 或 memory.low，除非你显式配置。

如何开启或配置

- 开启内存限速
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9
```
该值在 0–1 之间，用于计算 Burstable 与 BestEffort 容器的 memory.high。

- 开启分层内存保护
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryReservationPolicy: TieredReservation
```

- 同时开启限速与分层保护
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9
memoryReservationPolicy: TieredReservation
```

- 完全禁用
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
MemoryQoS: false
```

已知限制

- 分层保护是节点级别的，所有 pod 共享同一策略；无法单独为某些 pod 开关。
- 采用硬性保留时，容器的 page cache 也会被计入，可能导致大文件读取占用过多内存。

后续计划

Memory QoS 将继续收集 Beta 期反馈，随后推进至 GA。若遇到问题，请在 kubernetes/kubernetes 提交 issue。

🔗 原文：点击查看

Grafana Cloud 数字体验监控更新

生产环境出问题时，仅靠指标很难回答几个关键问题：谁受影响、用户实际看到了什么、是否值得叫醒值班人员。Grafana Cloud 的 Digital Experience Monitoring（DEM）把 Frontend Observability 与 Synthetic Monitoring 结合起来，用真实用户体验数据配合主动测试，帮助团队判断问题影响范围、定位原因并更快恢复。

核心能力包括四块：真实用户可见性，了解用户实际体验而非只看后端指标；主动检测，对关键用户旅程跑自动化检查，赶在用户之前发现问题；端到端关联，把前端信号与背后的后端 trace 连起来；更快恢复，把平均恢复时间从小时级压缩到分钟级。

Session Replay 由 Grafana 开源 JavaScript 埋点库 Faro 驱动，可回放用户在 Web 应用中的操作，并与 Core Web Vitals、用户行为、trace 等真实用户监控信号关联。配置时在 Faro 初始化里加上 ReplayInstrumentation 即可，默认隐私优先，可调整掩码、隐私和采样选项，比如只录制一定比例的会话。

回放播放器支持播放、暂停、前后跳 10 秒，速度从 0.25x 到 16x 可调，可跳过空闲片段，还能复制特定时刻的分享链接。侧边栏展示带时间戳的用户旅程，可查看错误、直接跳转并筛选排序。由于回放与 Faro 遥测数据关联，可以从仪表盘上的前端错误直接跳进对应会话的回放，看用户出错时的操作，再深入关联的 trace。

Synthetic Monitoring 与 Frontend Observability 的集成也有更新。每次 Synthetic Monitoring 浏览器检查运行时会自动创建一个对应的 Frontend Observability 会话，这是一个完全可控、可重复的真实用户旅程。从检查内部可直接拉取 Frontend Observability 数据，跳进该次运行创建的会话，查看会话回放、用户旅程和 trace。合成检查不再只是通过或失败，每次运行都有反馈，失败时能看清具体发生了什么，回答值班工程师最关心的问题：这个失败检查是否影响真实用户、影响了多少人。

从告警到失败执行再到回放，现在只需几次点击就能完成排查。Grafana Cloud 免费层包含每月 10 万次测试执行。

🔗 原文：点击查看

触发自主代理的最佳方式：从诊断而非警报

在 Anthropic 的 AI‑Native SDLC Playbook 中，Stage 6（维护）通过脚本监控生产指标，当控制带被突破时启动 Claude 会话。传统做法是先检测异常，再让代理自行推断根因，导致代理在最昂贵的阶段花费大量 token 进行排查。Causely 通过先生成诊断（Issue）并携带因果链，直接把诊断作为触发点，让代理从根因开始行动，省去多余的推理步骤。

- 控制带：脚本基于滚动基线和 Western Electric 规则设定 1σ、2σ、3σ 阈值，分别记录、只读诊断、或直接打开 PR。
- 诊断触发：Causely Issue 包含受影响实体、主诊断和证据链，代理收到后立即获取诊断细节，直接定位根因。
- 自动修复：代理读取代码、编辑、提交并打开 PR，所有操作在仓库内完成，避免再次访问监控系统。
- 成本与噪声控制：只对 Critical/High 严重度 Issue 触发，避免无效循环。

示例流程
1. 监控脚本检测到外部支付 API 超时，生成 Severity Critical 的 Issue。
2. 接收器将 Issue 转为代理首条消息，代理调用 get_issue_details 获得因果链。
3. 代理定位 payment-adapter 的慢调用，编辑 main.go 添加断路器和超时，提交 PR。
4. PR 说明根因与修复，审核后合并。整个过程从 Issue 到 PR 仅耗 4 min 54 s，诊断时间 17 s。

如何实现
- 在外部系统中部署一个 FastAPI 接收器，将 Issue 事件转为代理会话。
- 仅发送 Critical/High 级别的 Issue，避免触发无效循环。
- 通过 PR 审核确保诊断正确，分支保护防止代理自行合并。

下一步
克隆示例仓库，使用本地 kind 集群观察从 Issue 到 PR 的完整流程。随后可对比有无因果上下文的多种场景，评估 token 消耗与诊断时间。

🔗 原文：点击查看

PG Summit 2026 演讲：Postgres 硬件基准测试

Richard Yen 将在 10 月 1 日的 PG Summit 2026 上分享用 Postgres 做硬件基准测试的经验，并提前聊了聊选题动机。

想测磁盘速度用 fio，想测 CPU 单项操作也有更合适的工具，这些组件级测试能说明单个部件的情况。但 Postgres 基准测试的目标不是复现产品页上的营销数字——比如三星 EVO Plus 990 标称读写 7,150/6,300MB/s，但正经的 Postgres 集群很难跑到这个值。

Postgres 是包含内存、并发、缓存、WAL、检查点、后台进程和多种维护机制的复杂系统，这些可能同时发生。跑十秒的基准可能只测到系统里又热又快的一小片，却漏掉了生产环境真正值得关注的部分。有经验的 DBA 或 DBRE 知道 autovacuum 会在负载运行时产生额外工作，检查点会带来 I/O 突发，高并发负载可能在存储设备忙起来之前就撞上锁竞争或连接数上限，缓存状态也会改变问题本身。

所以该问的问题不是「这块 SSD 多快」，而是「这个工作负载在这套系统上能否跑得可接受，系统还能承受多少」。定义工作负载是基准测试的第一步：是大量小并发事务的 OLTP，还是大扫描大 join 的分析型负载，或是宽 JSON 文档、可压缩值、高写入量的场景。确定负载后，在受控步骤中调参并监控不同指标，当吞吐停止增长、延迟超标或某资源饱和时，就能更清楚数据库整体的能力边界，第一个瓶颈也指明了下一步方向。

可信的基准要跑足够久以覆盖几个 autovacuum 和检查点周期，并且可重复。应记录配置、数据集、客户端位置、预热期、测量窗口和验收标准，还要测试系统过载后能否恢复。严格的硬件基准测试仍有其位置，但应单独做——fio 适合回答存储性能问题，Postgres 基准测试的目标是理解特定数据库负载能否跑在特定系统上、在哪里停止扩展、先遇到哪个约束。

演讲将深入这套流程，涉及 HammerDB、pgbench、工作负载设计，以及帮助定位真正瓶颈的证据。

🔗 原文：postgr.es/p/9uu

Chrome 扩展：自动计算 SIU Guaraní 学分

这款名为 Calculadora SIU CrediUPE 的 Chrome 扩展，专为 Universidad Provincial de Ezeiza 的学生设计。它直接在 SIU Guaraní 学习计划页面读取 DOM，自动筛选需要的课程，提取学分信息，计算并显示可用的免费学分。用户无需手动复制或手工计算，所有步骤在页面内完成，极大简化了学分管理流程。

扩展通过 JavaScript DOM API 与页面交互，保持对原页面的最小干扰。发布后已超过 800 次下载，用户超过 250 人，证明其在校园内的实用性和受欢迎程度。

该工具属于开发者工具库｜工程效率频道的内容范围，符合本频道主题。

🔗 原文：点击查看

生产安全测试：云原生应用的必备防线

云原生应用在部署后持续演变，传统的预生产安全测试已无法覆盖真实风险。生产安全测试通过受控、非破坏性的方法，在不影响可用性的前提下验证运行时的漏洞、误配和访问控制缺口。它将安全评估与实际运行环境紧密结合，提供即时、准确的风险反馈。

与预生产环境相比，生产测试能捕捉到配置漂移、微服务交互、自动扩容导致的安全缺口以及第三方组件变更带来的新威胁。通过速率限制、只读测试账户和精确范围控制，安全团队可以在 CI/CD 流水线中持续验证，避免因停机或性能下降而被迫中断。

持续的生产安全验证让团队及时发现并修复漏洞，缩短攻击窗口，保持安全姿态与业务需求同步。

🔗 原文：点击查看

GBP 资料审计自动化脚本

多市场 B2B SaaS 的 Google Business Profile（GBP）资料容易漂移：分类被随意改动、NAP 数据过期、节假日营业时间未更新，排名悄悄下滑时才被发现。MarkoMetrics 为东南亚多市场 SaaS 客户管理 GBP 列表，手动每周检查不可扩展，于是用 Google Business Profile API 写了一个轻量审计脚本，自动标记不一致项。

脚本检查四类问题：主/次分类与预期分类列表是否匹配；按国家校验电话号码格式（用 phonenumbers 库）；地址字段与 CRM 规范记录是否一致；营业时间是否有空缺或重叠，以及资料是否已验证、未被暂停。

依赖安装：google-api-python-client、google-auth-oauthlib、phonenumbers、pandas。需要启用 Business Profile API 的 Google Cloud 项目，以及有资料访问权限的 OAuth2 凭证。

核心逻辑：从 CANONICAL 字典读取每个位置的预期分类、国家代码和电话，调用 API 拉取资料后逐项比对，把问题汇总成 CSV 输出。每周用 cron 或 GitHub Actions 跑一次，把结果推给 Slack 或邮件。

自动化后，分类和电话格式问题在一周内就能被发现，而不是等到季度人工审查——过去多市场 SaaS 环境下，至少有一个市场的本地可见性会悄悄降级数周。扩展方向：加 diff 追踪层只报变化、CANONICAL 改为从 CRM API 动态拉取、用 Reviews API 追踪评论响应延迟。

🔗 原文：点击查看

寻找 LM Studio 插件与 MCP 服务器的统一目录

LM Studio 运行模型后，若想让其搜索网页、处理文件或剪辑视频，需要合适的插件或服务器。Local AI Tools 是一个免费、开源的目录，聚合了 LM Studio 原生插件和 MCP 服务器，支持按功能搜索并查看兼容性、安装步骤与运行时信息。无需账号，直接浏览即可。

使用方法：打开 Local AI Tools，选择“LM Studio 插件”或“MCP 服务器”，输入关键词（如 video、web search 等），查看详情页获取安装说明。插件可通过 LM Studio 直接安装，MCP 服务器则需在 mcp.json 或使用“Add to LM Studio”链接配置。目录会标注是否已准备好、是否需要额外设置或兼容性未知，帮助快速判断是否可直接使用。

该项目 MIT 许可，源码托管在 GitHub，欢迎贡献。

GitHub: GitHub

🔗 原文：点击查看

PostgreSQL标识符63字节截断陷阱

max_identifier_length 报告的数字是 63，但数字本身不是重点。PostgreSQL 与 MySQL、SQL Server、Oracle 不同：超长标识符不是报错，而是静默截断。

截断发生在词法分析器的 truncate_identifier()，按 63 字节而非字符切割，适用于所有标识符：表、列、索引、约束、schema、角色、数据库、函数、游标、保存点、LISTEN 通道。引号保留大小写，但无助于长度。

失败模式是碰撞。两个前 63 字节相同的名字被视为同一个，生成名称时变化部分在末尾，最容易踩坑。示例：60 字符父表名的每日分区，_p2024_01_01 和 _p2024_01_02 都被截成同一名字，第二个报 already exists。更糟的是 DROP TABLE 解析到同一 63 字节，可能删掉今早刚建的分区，且无报错。

PostgreSQL 自身生成的名称安全：makeObjectName() 缩短表名和列名部分，碰撞时加计数器重试。外部工具处理不一：pg_partman 会修剪父名腾出空间；Django 自 2010 年报告 63 并哈希索引名尾部；Rails 7.1 起改用哈希，Action Cable 适配器今年才修复按字符而非字节计数的 bug。

可以提升：NAMEDATALEN 改为 128 可得 127 字节名称，但需 initdb，pg_upgrade 拒绝迁移，C 扩展需全部重编。邮件列表 2012、2017、2021 年都提过，答案不变：name 是定宽 64 字节，翻倍会让所有目录行和 syscache 翻倍。

建议把 63 当预算，后缀优先：约定追加 _p2024_01_01 或 _pkey 时，基础名超过 45 字符就是隐患。脚本生成名称先检查 octet_length(candidate) 与 max_identifier_length 比较，再用查询找出已有 63 字节的名称，确认是否被截断。SQL 标准允许 128，Oracle 12.2、SQL Server 早已支持，MySQL 允许 64 字符。PostgreSQL 是短的，也会保持短的。参数本身不能设置，能做的只有规划命名。

🔗 原文：postgr.es/p/9uq

Murmur：终端里的 AI 电台

Murmur 是一个用 TypeScript 写成、直接在 Node 24 环境下运行的 CLI 电台。它会自行挑选话题，使用 Claude Agent SDK 作为大脑，并通过一个托管的 HTTP 端点播放人声。你可以在终端里听它说话、播放音乐、说早安晚安，甚至在对话中输入文字，主持人会即时回应。

程序逻辑、键盘输入、音频混音、人格设定和记忆都保存在本地；音乐通过 yt‑dlp 下载，规则文件存放在 ~/.murmur。主持人的人格是一个可编辑的文本文件，记忆则随对话增长，记录日期和引用。

Murmur 通过 npm install -g murmur-radio murmur 安装，启动后会自动引导你安装 ffmpeg、yt-dlp 和配置语音端点。它在 macOS 上已测试，Linux 也可用，Windows 尚未验证。

GitHub: GitHub

🔗 原文：点击查看

oxlint 实测：类型感知模式仍比 ESLint 快 13 倍

有人在 Vue 核心仓库上对比了 ESLint 与 oxlint 的真实耗时。仓库共 445 个 TypeScript 文件、约 15 万行代码，在干净的 Node 20 容器里用两种工具各跑两种模式，取多次运行的墙钟中位数。

纯语法规则下，ESLint 9 搭配 typescript-eslint 耗时 4.4 秒，oxlint 默认模式 0.24 秒，约快 18 倍。oxlint 自报的引擎时间只有 75 毫秒，其余都是 Node 启动开销。开启类型感知规则后差距更明显：ESLint 的 recommendedTypeChecked 需要构建 TypeScript program，耗时 12 秒；oxlint 通过 --type-aware 标志调用配套的 tsgolint，0.9 秒完成，比 ESLint 同类工作快约 13 倍，甚至比 ESLint 纯语法模式还快 5 倍。

作者原本预期 oxlint 只做廉价语法检查、类型感知规则仍需交给 ESLint，实测推翻了这一结论。不过有几处需要说明：两套规则集并不完全一致，oxlint 语法模式报告 96 条规则、类型感知模式 111 条；类型感知模式目前仍标记为实验性，需单独安装 oxlint-tsgolint 包；底层类型检查器是 Go 实现的 tsgolint，并非官方 tsc，属于不同实现，投入 CI 前应在自己代码上验证。

作者建议把 oxlint 放进 pre-commit 钩子和 CI 第一步，亚秒级成本下没有理由不跑；ESLint 保留给 oxlint 尚缺的特定规则或插件，只在 CI 跑一次。核心结论不是二选一，而是快速工具已快到可以随处运行，剩下的问题只是哪些检查仍值得留给慢工具。

GitHub

🔗 原文：点击查看