WSL2 上 Claude 驱动 Chrome 的修复方案

Claude in Chrome 扩展在 WSL2 下无法工作，根源在于扩展通过 Windows 注册表发现原生消息宿主，而 Claude Code 在 WSL 中把清单写入 Linux 文件系统，两边互不可见。官方文档也已标明 WSL 不受支持。规避方案是退回 Chrome DevTools 协议（CDP），配合两个廉价的驱动组合，实现低成本、持续登录的浏览器自动化。

核心思路：一台 Windows Chrome 监听 9222 端口，WSL2 中的 agent-browser 负责日常驱动（通过可访问性快照，仅耗数百 tokens，远低于截图的上千 tokens），chrome-devtools-mcp 负责深入调试（网络请求、控制台、Lighthouse）。两者共享同一浏览器，通过 CDP 同时连接，仅需确保各自使用不同标签页。

启动 Chrome 命令（从 WSL 通过 /mnt/c 执行）：
```
"/mnt/c/Program Files/Google/Chrome/Application/chrome.exe" \
--remote-debugging-port=9222 \
--user-data-dir="C:\Users\youruser\AppData\Local\ChromeDebugProfiles\myapp" \
--no-first-run --no-default-browser-check \
--remote-allow-origins='*' &
```
--user-data-dir 隔离浏览器配置，登录一次后会话持久保留。

agent-browser 安装：npm install -g agent-browser，注意跳过 agent-browser install（它会下载无登录状态的 Chrome for Testing）。首次运行因 $XDG_RUNTIME_DIR 不存在会报权限错误，需设置：
```
export XDG_RUNTIME_DIR=/tmp/abr-runtime
mkdir -p "$XDG_RUNTIME_DIR" && chmod 700 "$XDG_RUNTIME_DIR"
```
将 export 写入 ~/.bashrc 以便跨会话生效。

连接已有 Chrome：agent-browser connect 9222。之后使用 snapshot、fill、click 等命令操作页面，注意 ref 会随 DOM 变化失效，需重新快照。SPA 导航用 pushstate 而非 open。

chrome-devtools-mcp 配置（以 Claude Code 为例，添加至 ~/.claude.json）：
```json
{
"mcpServers": {
"chrome-devtools": {
"type": "stdio",
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest", "-u", ""]
}
}
}
```
推荐用 claude mcp add --scope user chrome-devtools -- npx -y chrome-devtools-mcp@latest -u http://127.0.0.1:9222 添加，避免手动编辑被覆盖。

常见陷阱：
- 端口幽灵：旧的 netsh interface portproxy 规则会占用 9222 且不被重启清除。在管理员 PowerShell 中用 netsh interface portproxy delete v4tov4 listenport=9222 listenaddress=0.0.0.0 等命令删除。
- 空工具列表：检查 ~/.claude.json 中端口是否与实验中的 Chrome 一致。
- MCP 服务器在 Chrome 之前启动：先启动 Chrome，再连接 MCP。

这套方案经过数月日常使用验证，关键是将登录状态持久化并避免高昂的截图 token 消耗。记住保持调试配置隔离，且只绑定到 127.0.0.1。故障时先用健康检查命令定位问题。

#开发者 #工具 #WSL2 #Claude #Chrome #CDP #agentbrowser #MCP #调试
@DevToolboxHub

AWS Continuum 上线代理化代码安全平台

Amazon Web Services 推出 AWS Continuum，这是一个新的集成安全平台，用于自动化代码库、依赖项和应用中安全问题的发现、执行与修复。AWS Continuum 提供四个代理能力，覆盖漏洞整个生命周期：渗透测试、代码审查、威胁建模和代码漏洞。

#开发者 #工具 #AWS #Continuum #安全 #漏洞 #渗透测试 #代码审查 #威胁建模
@DevToolboxHub

用MCP Server封装RAG Agent

将RAG Agent包装成MCP Server，让其他AI系统通过标准协议调用其能力，无需硬编码Python导入。作者使用FastMCP构建自定义MCP服务器，暴露四个工具类别：计算器、搜索公司文档、查询员工假期、查询工单信息。

四个工具类别：
- 计算器工具：calculator_add 和 calculator_multiply。
- search_company_documents：通过HTTP请求访问RAG Agent的FastAPI /search端点，需api_key参数。
- get_employee_leave：从内存中查询员工剩余PTO。
- get_ticket_information：返回工单状态、分配团队和优先级。
每个工具使用 @mcp.tool() 装饰器注册，FastMCP体验良好。
挑战方面，RAG搜索工具需跨网络调用（requests.get到127.0.0.1:8000/search），需处理连接拒绝、超时等真实错误。
未来计划包括：统一认证、数据源替换为真实数据库、最终接入多Agent工作流。

MCP协议为AI Agent与外部工具提供标准化接口，使系统能力可发现、可调用。企业AI的未来不仅是生成更好回复，更是让AI Agent安全地与现实工具和业务能力交互。

GitHub: GitHub

#开发者 #工具 #MCP #RAG #FastMCP #AIagents #Python
@DevToolboxHub

safari-mcp 索引钳位 Bug：我猜错了根因

safari-mcp 作者三天前提交了一个严重 issue：用户的两个标签页被 AI 代理误导航，滚动位置、页面状态丢失。他自信地分析了根因——位置句柄导致标签归属丢失——并提议用注入 window.__mcpTabMarker 的稳定标识方案。

实际打开源代码后，他发现：这个哨兵方案早在 v2.8.3（April 14）就已经实现了。真正的 bug 藏在其下方四行：当标签索引超过窗口标签数时，代码不是丢弃索引（fail closed），而是将索引“钳位”（clamp）到 tabCount——即指向窗口最后一个标签，一个从未打开的、属于用户的标签。这个“proactive fix”代码段被日志装饰成“修复”，实质是猜答案。

这条 clamp 分支（Mar 31）比哨兵方案（Apr 14）更早，属于遗留启发式。哨兵方案添加时正确连入了两条 fail closed 分支，但这条“输入校验”样式的 clamp 被遗留了。作者总结：当添加更好机制时，旧启发式不会自动删除。任何将“我不知道”转换成合理值的代码，都是披着修复外衣的 fail open。

最终修复只是删除那几行钳位代码，改为 activeTabIndex = null; return null;——就像它上下两条分支一样。错误提示引导用户重新运行 safari_new_tab 来恢复。代价是那些此前“侥幸”成功的 session 会抛出异常，但作者认为：对于“绝不碰用户标签”的承诺，报错是正确答案，猜不是。

修复只是一行删除。作者把错误的根因分析留在 issue 里当警示，并提醒：如果你把同一个 bug 交给 AI 代理，它可能会执行你提出的早已过时的方案，而真 bug 依然存在。

#开发者 #工具 #safarimcp #MCP #Safari #AI #Bug #Javascript #macOS
@DevToolboxHub

Hugging Face 缓存溢出解决方案

Hugging Face 模型下载默认存入 ~/.cache/huggingface，140GB+权重极易撑爆系统盘。以下是 Linux 下的工程级缓存管理方案，避免存储耗尽与生产崩溃。

避免使用废弃的环境变量 TRANSFORMERS_CACHE 和 HUGGINGFACE_HUB_CACHE，应统一使用 HF_HOME。
禁用符号链接法：存在权限提升风险，不推荐。
步骤1：永久修改缓存路径
在 ~/.bashrc 追加 export HF_HOME="/mnt/massive_drive/ai_model_cache" 并 source。
步骤2：Python 中必须在 import transformers 前设置 os.environ["HF_HOME"]。
步骤3：使用 huggingface-cli scan-cache 和 huggingface-cli delete-cache 安全清理。
步骤4：生产环境只读卷需设置 os.environ["HF_HUB_OFFLINE"]="1" 避免写锁文件崩溃。

通过以上配置可彻底解决存储陷阱，确保生产环境稳定运行。

#开发者 #工具 #HuggingFace #缓存 #模型部署 #Linux #DevOps #AI
@DevToolboxHub

开源QR码生成器QRcodly发布

作者因给亲友准备生日礼物时发现市面上所有QR码生成器都要注册或付费，决定开发一个真正免费的MIT开源替代方案。QRcodly支持无限静态/动态QR码、自定义样式、Logo上传、扫描分析和内置短链接，免费用户无需信用卡，也不会遇到试用期后重定向到升级页面的陷阱。

动态QR码本质是一个302重定向短链接，许多服务借此将打印物料变成自己的广告位。QRcodly的Pro版面向企业提供自定义域名、REST API和批量导入等商业功能，个人用户则不必为“重定向”支付月费。技术栈采用pnpm monorepo结构：前端Next.js、后端Fastify、共享Zod schema作为类型唯一来源，搭配Drizzle ORM、Redis、Clerk认证和next-intl国际化。后端采用自建事件系统而非Kafka/RabbitMQ，降低自托管门槛。目前已稳定运行一年并迎来首批付费客户。

GitHub: github.com/FloB95/qrcodly

#开发者 #工具 #QRcodly #开源 #Fastify #Nextjs #TypeScript #Monorepo
@DevToolboxHub

在 Bedrock 上用 Codex 运行 GPT-5.6

AWS 已将 OpenAI GPT-5.6 上架 Amazon Bedrock。Codex CLI 可通过 Bedrock API 直接调用这些模型，使用你已有的凭证即可。尝试运行：

```
codex \
-c model_providers.amazon-bedrock.aws.region="us-east-1" \
-c model_provider="amazon-bedrock" \
-c model="openai.gpt-5.6-terra"
```

若成功启动并响应提示，即配置完毕。也可将以下两行加入 ~/.codex/config.toml 永久生效：
```
model_providers.amazon-bedrock.aws.region="us-east-1"
model_provider="amazon-bedrock"
```

详细配置与模型选择

Codex CLI 内置 Bedrock 提供商。使用本地 AWS CLI 凭证时，需安装并配置 AWS CLI，且附加 AmazonBedrockLimitedAccess 策略（覆盖 bedrock-runtime 和 bedrock-mantle 端点）。

也可使用 Bedrock API Key（无需 AWS CLI）：通过 AWS 管理控制台或 aws-bedrock-token-generator（Python/JavaScript）生成短期密钥，存入 AWS_BEARER_TOKEN_BEDROCK 环境变量。密钥区域相关，最长有效期 12 小时。

模型选择：Sol（旗舰级，代码/安全/研究）、Terra（平衡型，日常生产）、Luna（高吞吐低延迟，分类/总结/路由）。三者共享 272K 上下文窗口，输出定价分别为每百万 token $33/$16.50/$6.60。注意 Codex 自身每次请求约消耗 9,400–9,500 token 的开销。

区域限制：Sol 支持 us-east-1 和 us-east-2；Terra 和 Luna 额外支持 us-west-2。可通过 Bedrock Mantle Models API 查询当前可用模型。

建议从 Terra 开始尝试。若需进一步配置，参考 Codex 与 Bedrock 指南。

#开发者 #工具 #AWS #Bedrock #Codex #GPT56 #OpenAI #CLI
@DevToolboxHub

变化太快所以不写测试是最大危险信号

几年前一次技术面试中，一位CTO打断我并说：“我们不写测试，因为业务逻辑变化太快。”初听起来，初创公司需求频繁迭代，似乎有道理。但仔细想想，这个逻辑完全反了——变化恰恰是写测试的理由，而不是不写的借口。

如果软件几乎不变，弱测试覆盖还能勉强运转；可业务逻辑每周都在变，你不断触碰生产环境运行的代码，风险会不断累积。测试最大的价值不是抓bug，而是让你在修改现有代码时有东西可依赖。想象一下要更新一年前上线的定价规则：新的条件本身很简单，但真正难的是找出这个行为在其他地方还有哪些依赖——另一个结算流程、某个市场两年前添加的覆盖、某个仍在运行的旧活动。没有测试，你只能手动检查几个场景，靠产品和老同事的记忆来验证。随着系统变大，手动测试变成了“希望大家都记得对的事情”。
软件永远不会真正完成：业务规则变、用户行为出乎意料、性能问题、法规演进。有时一个小需求会暴露多年积累的设计问题——同一规则在四个地方重复、三个无关模块依赖同一个工作流、修一个边缘情况却影响到远超出预期的范围。这时缺乏测试的成本就显现了：团队用人工检查来补偿，但总会有被忽略的情况导致上线失败。发布变慢，越来越多的人介入，代码库某些区域变成“危险区”，所有人都知道该清理但没人敢碰。工程师可能很清楚设计的问题，甚至知道如何改进，但他们不相信自己动手后的结果。这就是短期技术债慢慢变成架构的原因——不是因为没人注意到，而是因为改变比维持现状更冒险。
有用的测试套件能改变这一点：它能给团队足够的反馈，让他们逐步改进系统，而不是等待一次可能永远不会发生的大重写。但这不等于测试越多越好——慢速或脆弱的套件会制造同样的不确定性；与实现过度耦合的测试会让无害的重构寸步难行。关键在于，测试应该保护业务依赖的行为，而不是每次内部结构变化时都崩溃。

这正是那句话让我一直记住的原因。不是因为他们不写测试，而是背后的逻辑：他们知道软件在持续变化，却没有给工程师更安全的方式去应对，而是把不确定性当作工作中理所当然的一部分。当这成为常态，人们最终会停止改进系统——避免重构、绕开糟糕设计、每次触碰旧代码都小心翼翼。我后来在两种系统都工作过：一种是小改动验证比实现还慢，因为没人知道会连带什么；另一种是更大的改动也能逐步推进，因为团队有足够的反馈。我们需要测试不是因为软件稳定，而是因为工程师需要信心去改变它。

#开发者 #工具 #软件工程 #测试 #技术债务 #重构 #工程文化
@DevToolboxHub

本期安全：微软补丁与AI编码代理攻击面

微软7月14日Patch Tuesday创历史记录，两个零日漏洞正被积极利用。同时，编码代理（coding agent）成为新的攻击面——Wiz的GhostApproval和AI Now Institute的Friendly Fire同天公布，打破了AI编码工具的信任边界。本推送提供三个可实际运行的安全检查块，以及背后的信任模型思考。

补丁分类：找到那两个真正需要紧急处理的问题
微软14日发布了史上最大规模补丁集——约570个CVE（59个关键），整个7月合计622个。两个在补丁前已被利用的漏洞：
• CVE-2026-56155 — Active Directory Federation Services权限提升，由微软检测与响应团队发现
• CVE-2026-56164 — SharePoint Server无认证关键函数提升，无需认证即可远程利用，CVSS 5.3（低评分但实际严重）
使用CISA已知被利用漏洞（KEV）目录交叉检查，优先于CVSS。运行以下命令拉取实时数据：
curl -s | jq '.vulnerabilities[] | select(.cveID | test("CVE-2026-56155|CVE-2026-56164")) | {cveID, vendorProject, product, dateAdded, dueDate, knownRansomwareCampaignUse}'
若返回结果，则确认已被利用，需立即修补并检查是否已被攻击。另注意：CVE-2026-56164所在版本还修复了CVE-2026-55040（SharePoint另一链第一部分，Rapid7称结合未公开的第二部分可达无认证RCE，微软预计8月修复）。第三个零日CVE-2026-50661是BitLocker绕过，需物理访问，微软评为低利用可能性，暂不急。

编码代理攻击面：GhostApproval和Friendly Fire
7月8日Wiz公布的GhostApproval是符号链接攻击：代理读取文件、识别出是符号链接指向敏感路径，但仍写入。人类审批对话框只显示无害文件名，代理实际写入解析后的目标。亚马逊评级为高严重性预认证写入（CVE-2026-12958），Cursor在v3.0中修复（CVE-2026-50549），Google修复了AntiGravity，Augment和Windsurf仍在开放状态，当前Claude Code构建会解析符号链接。
Friendly Fire由Boyan Milanov和Heidy Khlaaf发布，目标是代理自动审查和修复第三方仓库的工作流。无需钩子、插件、MCP服务器或恶意配置文件，只需代理运行在自动模式（如Claude Code auto-mode或Codex auto-review），然后利用普通仓库内容中的提示注入。作者指出仅靠模型更新无法修复，因为模型无法可靠区分代码与指令。
实用问题不是“我的代理是否已修补”，而是“我的代理被允许做什么，我能看到它做了什么”。首先检查出口（egress）：macOS/Linux上查看编码代理进程的网络连接：
sudo lsof -i -nP | grep -iE 'claude|cursor|copilot|codeium|windsurf|augment|antigravity'
这只是快照，不是持续监控，但已能暴露盲区。

Claude Code出口争议：中国国家漏洞数据库将Claude Code 2.1.91至2.1.196标记为未经同意传输位置和身份的“后门”，要求开发者卸载。Anthropic否认间谍后门，称争议功能是反滥用实验；一名Claude Code工程师称反蒸馏隐写机制已在7月1日的2.1.198中移除。核心教训：运行上述命令后，诚实地问自己能否解释每一个连接。大多数团队做不到。一个拥有这么大权限的代理，如果出口不可观察、遥测不可枚举，就是在盲目扩展信任边界。修复方法不是选边，而是像对待任何特权进程一样对待它：可观察的出口、文档化的遥测、最小权限约束其行为。

已知漏洞与配置错误：NSA等多国机构7月13日联合警告，俄罗斯国家行为者攻击关键基础设施并非靠零日，而是已知已修补的CVE及基础配置错误（默认SNMP社区字符串、弱密码、暴露的管理接口、Cisco Smart Install未关闭）。可针对自身边缘设备运行检查：
# 检查弱/默认SNMP社区字符串
nmap -sU -p161 --script snmp-info <your-device-ip>
# 检查Cisco Smart Install（端口4786，通常不应暴露）
nmap -p4786 <your-device-ip>
配合CISA和FBI自春季持续追踪的活动：与俄罗斯情报相关的钓鱼者窃取Signal和WhatsApp账户，并非破解加密，而是诱使目标交出验证码或链接攻击设备。
这些攻击模式不需要任何AI：未修补已知漏洞、错误配置、以及一次有说服力的谎言。

补丁只能让你存活，不能修复信任模型。今天的行动：运行上述三个检查块。如果KEV查询返回记录，今晚就要修补。如果lsof输出中有无法解释的连接，那就是Claude Code争议真正暴露的问题。如果nmap检查在你自己的边缘亮起红灯，那么俄罗斯攻击者不需要零日也能找到你。

#开发者 #工具 #微软 #安全 #零日 #编码代理 #ClaudeCode #CISA #GhostApproval #FriendlyFire
@DevToolboxHub

usernoted 啃掉一个CPU核心？一条命令揪出元凶

一台 Mac 发烫，usernoted 守护进程持续 99% CPU。删除 Timelines app 后问题解决。以下是完整调试过程。

开机 CPU 持续 99%，按内存排查无果，按 CPU 排序发现 usernoted 占用一个整核。killall 后两秒重启。使用 sample 获取堆栈，发现卡在 UNCalendarNotificationTrigger 的 week-of-year 日期计算无限循环。

怀疑是日历数据问题：移除 Google 日历、关闭日历通知、删除可疑日历、导出 .ics 检查 BYWEEKNO，全无效。原因为 zsh 内置 log 命令遮蔽了 /usr/bin/log，且命令后加了 2>/dev/null 吞掉报错，导致日志一直被误认为空。改用完整路径后立刻发现反复出现的 bundle ID com.glimsoft.Timelines，该 app 曾调度两条“重新互动”通知，但通知权限已被拒绝，形成死循环：计算触发时间 → 送达被拒 → 重新调度 → 再计算。

删除 /Applications/Timelines.app 后，CPU 从 8.0s/8s 降至 0.38s/8s。问题根源：Apple 的 Calendar.nextDate(matching:) 在无法满足组件时无限循环，已被向 Feedback Assistant 报告。

关键教训：不要过早忽略错误输出，警惕 shell 内置命令遮蔽，测量用累计时间而非快照。遇到 usernoted 飙 CPU，用 /usr/bin/log show 直接查看重复 bundle ID。

#开发者 #工具 #macOS #usernoted #调试 #Timelines #CPU
@DevToolboxHub

Dolt 2.0 发布：自动存储清理与压缩

DoltHub 近日发布 Dolt 2.0，这是开源版本控制 SQL 数据库的重大更新。新版本新增自动存储优化，包括垃圾回收和压缩，同时改进了对大数据类型和向量数据类型的支持。Dolt 兼容 MySQL，将 Git 风格的版本控制引入数据库，支持分支、合并与回滚等操作。

#开发者 #工具 #Dolt #DoltHub #版本控制 #数据库 #存储优化
@DevToolboxHub

超越MCP：企业AI平台需要七层边界

MCP（Model Context Protocol）正迅速成为企业智能体架构的默认答案——访问数据用MCP，调用API用MCP，智能体之间通信也用MCP。但MCP只标准化了一个边界：AI应用与能力之间的连接。它不决定哪个数据源是权威的，不保留业务事务，不处理审批流程，也不验证智能体是否正确执行。一个企业级的智能体平台必须处理至少七个独立的边界，代理到工具只是其中之一。

过去18个月内，四个主流厂商推出了四个开放协议，针对不同问题：

• MCP（Anthropic，2024年11月开源）— 基于JSON-RPC，定义AI客户端如何发现和调用工具。已被Claude、Cursor、VS Code及数十个智能体框架采用。适合多个AI客户端共享同一能力接口。

• A2A（Google，2025年4月发布，2026年1月v1.0）— 标准化相互独立运行的智能体之间的工作委托。现由Linux基金会治理。适合“去调查这个供应商并生成报告”这类跨组织协作。

• AG-UI（CopilotKit，2025年开源）— 标准化智能体后端与前端的流式连接。适合实时状态、交互式UI、超出聊天范围的人机协同。

• AgentCore（AWS，2025年）— 为智能体提供托管基础设施，涵盖身份、能力网关和运行时。适用于AWS环境中的凭据管理、工作负载身份和网关路由。

全都开源，但各自解决不同问题，单独任何一个都不足以构成生产级企业平台。

七个边界：

边界 | 技术 | 解决的问题

智能体 → 工具 | MCP、function calling | 发现并调用有界能力

智能体 → 业务服务 | REST、gRPC、GraphQL | 利用现有保证进行确定性领域操作

智能体 → 智能体 | A2A | 将目标委托给独立运行的智能体

智能体 → 用户 | AG-UI、A2UI、MCP Apps | 流式状态、渲染交互体验

服务 → 服务 | API、事件、队列 | 可靠的系统集成（已解决）

智能体 → 持久化流程 | 工作流引擎 | 持久性、重试、审批、补偿

身份 → 资源 | OAuth、OIDC、IAM | 建立并强制授权

将这些边界放在一起，组成六个平面：体验层（聊天/IDE/门户）、智能体运行时（模型/状态/规划）、能力层（注册表/网关/MCP）、企业上下文（数据产品/搜索/记忆）、执行层（工作流/队列/沙箱/审批）、记录系统（ERP/CRM/数据库）。横切关注点包括身份、授权、策略、密钥、审计、可观测性、评估、成本和生命周期。

随着模型能力提升，硬编码的路由将减少，模型会动态组装执行路径。但这不会消除对身份、授权、事务、持久状态、审计和评估的需求——更强的智能体能尝试更多操作，控制层反而更重要。趋势是：更少的自定义编排，更强的能力和信任基础设施。

下周一可以做的事：映射你平台中的七个边界；找出哪些地方在用MCP替代工作流引擎；识别模型中本应由确定性系统做决策的环节；端到端构建一个可追踪的例子，从体验层到记录系统走通，发现信任假设的缺口。模型越强，受治理的企业层就越厚，这正是平台投入的方向。
@DevToolboxHub

Pinecone 发布 Nexus 知识引擎

Pinecone 宣布 Nexus 知识引擎正式上线，这是一款为 AI 代理设计的“知识引擎”，能将企业数据转换为结构化的可查询层。团队可以一次性注入并管理业务上下文，让多个代理复用，从而降低 token 开销并提升回答准确性。

#开发者 #工具 #Pinecone #知识引擎 #AI代理 #Nexus #结构化数据
@DevToolboxHub

ClickHouse 26.3 EXPLAIN 新增两种格式化选项

ClickHouse 26.3 为 EXPLAIN 语句引入 pretty=1 和 compact=1 两个格式化选项，不改变执行计划本身，仅改变呈现方式。pretty 输出带缩进和标签的详细树形结构，适合深度调试与学习；compact 去除包装节点，仅保留核心操作，适合终端快速检查与 CI 日志。两者可以组合使用：EXPLAIN pretty=1, compact=1 SELECT ...，在保留缩进的同时折叠不必要的 Expression 节点。

测试使用官方 Stack Overflow 数据集（约 3700 万帖子、1300 万用户），涵盖五种场景：
- 简单 WHERE 过滤：compact 仅保留 ReadFromMergeTree，pretty 显式展示包装节点。
- GROUP BY 聚合：pretty 提供 Before GROUP BY 等注解，compact 仅标出 Aggregating 阶段。
- JOIN 操作：pretty 标注 Left/Right Pre Join Actions，明确区分两表分支。
- ORDER BY + LIMIT：两种格式都揭示 ClickHouse 的懒加载优化——先扫排序列，再取 TOP 行的剩余列。
- 复杂分析查询（JOIN + WHERE + GROUP BY + HAVING + ORDER BY + LIMIT）：pretty 的缩进树让约 15 个执行节点的关系一目了然，compact 则更难追踪父子节点。

使用建议：pretty=1 适用于学习执行计划、调试复杂性能问题、撰写文档；compact=1 适用于快速检查查询结构、终端工作、CI 日志。最佳实践是在优化前始终检查执行计划，对比 schema 变更前后的计划，结合 system.query_log 关联实际运行统计，并用 EXPLAIN PIPELINE 分析处理器级别的并行性。

新选项本身不提升查询性能，但显著降低理解执行计划的门槛，帮助开发者更高效地定位优化点。

#开发者 #工具 #ClickHouse #EXPLAIN #查询优化 #数据库 #SQL #DevOps
@DevToolboxHub

kalbee：从 pip 到多目标追踪的卡尔曼滤波指南

kalbee 是一个 Python 状态估计库，专为从噪声传感器数据中恢复干净信号（位置、速度、温度等）而设计。只需 pip install kalbee，依赖只有 NumPy 和 SciPy，也可选装 YOLO 检测和绘图支持。其核心理念是 predict（用运动模型预测）和 update（用实际测量校正）交替循环，适用于内置的十种滤波器。

入门示例：使用 constant_velocity 模型追踪匀速直线运动的一维物体，通过对比原始测量误差与滤波后 RMSE，直观感受卡尔曼滤波的降噪效果。

拓展能力：n_dims 参数可扩展至二维（位置/速度 x、y）甚至加速度模型；非线性系统可替换为 EKF 或 UKF，只需传递状态转移函数和测量函数。

多目标追踪：通过 MultiObjectTracker 配合匈牙利匹配算法，管理轨迹的创建、确认与消亡（参数 n_init、max_age、gate），可直接接入 YOLO 等检测器。

调参辅助：内置 EM 算法从历史数据自动学习过程噪声 Q 和测量噪声 R；内置实验运行器可对比不同滤波器在给定信号上的 RMSE 和 NEES 指标。

所有代码片段均可直接复制运行，文档和 examples/ 目录提供了完整的多目标追踪和 YOLO 集成示例。无论一维还是高维、线性还是非线性，kalbee 用一致的接口帮你快速上手状态估计。

#开发者 #工具 #kalbee #卡尔曼滤波 #状态估计 #Python #多目标追踪 #EKF #UKF
@DevToolboxHub

AI Demo 到可交付 MVP 的 5 道验证门

AI 编码代理大幅缩短了从想法到可用软件的距离，但并未消除判断力。一个好看的界面不能证明数据能在重载后存活，通过的单元测试不能证明键盘用户能完成核心任务，成功部署不能证明预期提交已到达生产环境。因此需要“证明门”——必须满足的可观测条件，才可使产品声明更可靠。以下是区分有说服力的 AI demo 与小规模可交付 MVP 的五道门。

第一道门：证明一个有价值的用户循环
AI 让功能生成变得廉价，但无控制的范围扩张尤其危险。在请求代码前，先定义一个特定情境下的主要用户，描述其可观测的初始状态、能执行的最小有用操作、直接结果以及他们可能返回的原因。这就是产品的核心循环。例如“构建一个生产力平台”过于宽泛，更可测试的循环可以是：自由职业者记住一个有用的客户成果 → 记录成果和支持证据 → 记录出现在可搜索库中 → 能稍后用于提案或回顾。此门通过的条件不是存在表单，而是新用户无需指导即可完成整个循环并说明变化。

第二道门：证明数据与恢复契约
许多 demo 将持久化视为实现细节，但对真实用户而言，持久化是产品承诺的一部分。在允许生成代码散布存储假设之前，先定义数据契约：对每个持久化字段明确名称、类型、是否必填、长度/计数限制、规范化规则和面向用户的含义。持久化数据应携带足够的版本信息以便安全解释。要区分通常被错误归为“空”的各种状态：无数据、当前数据有效、旧数据已迁移成功、数据损坏/不支持、存储不可用、写入因配额或访问限制失败。一个危险模式是捕获解析错误并返回空数组，然后用空状态覆盖用户的最后有效数据。恢复行为必须预先设计。最强实际测试是真实往返：创建代表记录 → 导出备份 → 通过正常控制删除应用数据 → 导入备份 → 重新加载应用 → 验证预期记录和字段存在。

第三道门：用有边界的提示证明 AI 变更
“构建剩余应用”给了代理过多自由度，也给审查者过少证据。有边界的实现提示应包含五部分：目标、边界、验收标准、验证、报告。目标指明一个用户可见结果；边界说明哪些不可更改；验收标准描述可观察的通过/失败行为；验证列出必须运行的测试和命令；报告要求确切结果、已更改文件、剩余风险和未验证行为。对于 Bug，应将诊断与编辑分离：提供预期行为、实际行为、重现步骤和首个相关错误，要求代理追踪代码路径并识别确认怀疑原因的最小实验，然后再请求有针对性的修复和回归测试。

第四道门：证明行为、失败状态和可访问性
如果测试只断言实现细节而非用户可见行为，那么绿色测试套件也可能与故障产品共存。测试领域规则，也要测试用户依赖的完整操作：必填字段拒绝无效输入，有效记录重载后存活，编辑保留身份和创建元数据，取消操作不改变任何内容，删除需确认，搜索和组合过滤器返回确定结果，失败的导入不改变当前数据，选择的导出仅包含预期记录。然后检查超越愉快路径的界面：键盘顺序应遵循任务，焦点应保持可见且在对话框后合理返回，错误应与相关控件关联，基本操作在 320px 宽度和 200% 缩放时应保持可用。自动化可访问性工具有价值，但无法证明完整交互。结果按三组报告：通过、失败、未验证。“未发现自动违规”不等于“工作流可访问”。

第五道门：证明用户实际收到的发布
本地构建成功证明的是构建本身，而非部署。发布前，核对文档与实现行为，运行完整相关测试套件、类型检查、配置的 lint 检查和生产构建，检查凭据、调试输出、失效占位符和无法解释的控制台错误。记录发布提交和已知回滚目标。部署后，在干净会话中验证线上产品：HTTPS 加载正确，主机服务预期发布，静态资源和元数据加载，核心循环工作，持久化数据重载后存活，错误和恢复状态可用，键盘和窄屏行为正常，浏览器控制台和网络面板无未解释的故障。如果高影响线上检查失败，诚实的结果是诊断出发布问题，而非成功启动公告。

保持小证据记录
对每道门记录：正在评估的声明、重现步骤、运行的测试或命令、手动观察、通过/失败/未验证项、回滚点。这份记录无需详尽，其目的是阻止信心脱离证据。AI 能帮助我们更快构建，相应的专业技能是学会何时可用证据证明“这已就绪”。

#开发者 #工具 #MVP #ProofGate #AIAgent #测试 #可访问性 #WebDev #工程效率
@DevToolboxHub