给免费模型额度装个本地预算账本

免费模型额度看着充裕，但一个超时重试循环就可能悄悄烧光。这个 Python 脚本在调用前做保守预估、调用后记录实际用量，超预算直接拒绝请求，防止意外浪费。

脚本从 JSON 文件读取预算和已用额度，调用前按提示词字节数除以四、加上最大响应 token 数、再留 15% 余量做预估；调用后从响应中读取 usage 字段并原子化写入账本。若端点返回异常或缺少可用 token 计数，脚本会退出且不更新账本。

典型场景：超时重试包装器在首个响应前把慢请求重试四次，token 消耗成倍增长；长上下文缓冲每轮都发送同样的 6k token 历史。仪表盘只显示总量下降，看不出是哪次调用导致。本地账本在请求发出前就拦截超预算调用。

用法：配置环境变量后运行 python budgeted_call.py '提示词'。测试时可将 BASE_URL 指向不可达地址，验证脚本非零退出且账本不变。

注意：单 JSON 文件不支持并发共享预算，不适合对延迟有硬性 SLO、需要审计或合规审查的场景。免费端点也不适合发送敏感提示词，仅作金丝雀测试目标。

脚本假设端点遵循 OpenAI 风格 chat completions 路径并返回 usage 字段，不依赖特定模型列表。若免费服务返回的 usage 字段结构不同，脚本会停止而非静默少计。文中 30,000,000 token 额度来自参考材料，实际以当前配额页为准，可通过环境变量调整。

#开发者 #工具 #Python #CLI #Token预算 #API调试 #MonkeyCode
@DevToolboxHub

逆向无文档 ERP：自学开发者的实战复盘

巴西餐厅运营经理 Luis Henrique Vasconcelos 分享了他逆向 TronSoft 餐厅 ERP 的经历。这套系统基于 Firebird 数据库，没有 API 参考、没有 schema 图、没有社区讨论，只有一份薄薄的操作手册。他靠观察生产数据库，最终梳理出约 40 个功能模块中的 390 张表和 514 个外键。

逆向过程中踩到的 Firebird 特性坑不少：SQL 方言用 FIRST 1 而非 LIMIT；主键由 GEN_ID 生成器驱动，不同步会产生静默冲突；复合主键在并发下才暴露问题；事务可见性也需摸清 autocommit 的具体行为。最难的并非 SQL 本身，而是复刻人工关闭 comanda 时的精确写入序列，让税务开票服务（NFC-e）认可自动化操作。他通过实时监控 MON$ 内部表、对比操作前后快照，逐步摸清黑盒规则。

第一版自动化用屏幕驱动鼠标键盘操作 UI，脆弱易断。转折点是放弃模拟界面、直接安全写入 COMANDA、ITEM_COMANDA 及税务相关表，复刻厂商软件预期的 NULL 模式和字段约定，自动化才从 hack 变成真正的集成，并已稳定运行在生产环境。

他的建议：无文档不是墙而是数据集，快照对比和查询日志比手册教得更多；在冷门系统里深耕是稀缺资产；生产环境才是真正的考验。他正把同样的方法用于评估 AI 编程代理。

#开发者 #工具 #逆向工程 #Firebird #TronSoft #数据库 #SQL #ERP #巴西
@DevToolboxHub

10天构建多语言银行语音助手Samar

开发者Raghul P在VoiceForBharat挑战赛中，用10天时间构建了Samar——一个面向印度数字银行场景的多语言AI语音助手。项目从简单语音助手起步，逐步演进为具备记忆、实时工具调用、外呼、人工升级、通话分析与专家转接能力的完整语音AI系统。

Samar基于LiveKit实现实时语音通信，使用LLM负责推理对话，语音识别理解用户输入，语音合成由Murf Falcon TTS API驱动。系统流程为：用户语音→语音转文字→LLM/Agent逻辑→记忆或工具调用→文字转语音→用户听到回复。

核心能力：

• 回答银行常见问题
• 提供金融信息
• 经同意后记住回头客
• 实时查询汇率与附近网点
• 主动外呼提醒
• 敏感问题升级人工
• 通话分析看板，以及将专业问题转接给贷款等专项Agent。安全护栏确保不索取PIN
• OTP
• CVV
• 密码等敏感信息

多语言处理是主要挑战：模型能听懂印地语，但语言配置不当会让语音带英语口音。通过配置多语言语音识别、动态语音/区域处理并强制各语言使用原生文字（印地语用天城文、英语用拉丁字母）解决。多语言语音AI需要识别、检测、文字生成与语音合成协同工作。

项目后端使用Python与uv管理依赖，前端基于pnpm构建，运行后访问localhost:3000即可对话。API密钥需存入环境变量，切勿提交至代码仓库。

#开发者 #工具 #Samar #VoiceAI #LiveKit #MurfFalcon #多语言 #语音助手 #银行科技
@DevToolboxHub

Sentinel：10 天构建的实时语音应急调度代理

印度开发者 Subhangi Dutta 在 VoiceForBharat 挑战赛中，用 10 天构建了 Sentinel——一个面向灾害应急场景的实时 Voice AI 调度代理。项目源于季风洪水中的真实困境：受灾家庭手机仅剩 14% 电量、网络退化到 2G，无法加载应急 App 或下载 PDF，唯一可行的求助方式是直接打电话。

Sentinel 针对印度应急响应的三个痛点设计：信息碎片化（指南、降雨警报、避难所容量分散在不同部门）、触屏界面在湿屏和高压下失效、以及传统聊天机器人转接时丢失上下文、迫使受害者重复叙述。系统通过统一 WebRTC 管道实现双向语音流，核心组件包括 Deepgram Nova-3 实时多语种转写、Google Gemini 负责灾情分诊与工具编排、Murf Falcon 提供低延迟印式英语语音合成，并配合 LiveKit 与 Silero VAD 支持自然打断。

架构分层上，LiveKit 负责浏览器与后端间的超低延迟 WebRTC 流，Silero VAD 动态追踪语音边界；Deepgram Nova-3 处理多样口音与快速语码切换；Gemini 作为决策引擎，评估灾情护栏、决定是否拉取外部遥测或执行 SQLite 查询，并在遇到避难所类问题时触发 ShelterInformationSpecialist 子代理；Murf Falcon 2 流式输出音频，无需等待完整句子生成即可开始播放；SQLite 维护呼叫者档案与升级日志，数据仅在用户明确语音同意后保存，并支持「忘记我的数据」指令即时清除。

Sentinel 具备状态记忆与隐私保护、实时天气遥测与故障回退（第三方 API 失败时自动切换缓存应急通告）、以及人工升级工作流——当呼叫者报告被困时，系统验证安全状态、记录紧急程度（Critical/Moderate/Low）、生成可追踪的参考 ID 并触发调度 webhook。

开发中最棘手的障碍是「静默转接」：多代理委派时，Sentinel 宣布转接后通话完全静音，LiveKit 将初始轮次视为结束，新代理只能等待呼叫者再次开口。解决方案是利用 LiveKit Agents 的 on_enter() 生命周期方法，在专家代理接管会话的瞬间立即通过 Murf Falcon 触发 session.say() 音频流，消除空白并即时播报避难所数据。

项目依赖 Python 3.10-3.13、Node.js 18+ 与 pnpm，需配置 LiveKit Cloud、Murf AI、Google Gemini 和 Deepgram 的 API 密钥。作者计划下一步接入 SIP 电话系统，直连 NDRF/SDMA 免费灾害热线，并扩展卡纳达语、阿萨姆语和孟加拉语的语码切换支持。

#开发者 #工具 #VoiceAI #Sentinel #WebRTC #LiveKit #Deepgram #Gemini #Murf #灾害应急
@DevToolboxHub

Basehim：面向 AI 时代的开源 PHP CMS

Basehim 是一个开源的模块化 PHP CMS，主打 API-first 与 AI-ready 架构，面向开发者、AI 辅助开发以及 AI Agent 场景。它试图解决传统 CMS 在 AI 时代暴露出的问题：内容被困在管理后台、扩展需要改动核心、AI 集成缺乏细粒度权限控制。

项目最鲜明的特点是内置 MCP（Model Context Protocol）服务器，AI 客户端可通过 /mcp 端点发现、认证并操作网站资源，例如让 AI 助手直接检索文章、起草内容。同时，AI Agent 的访问通过 OAuth 2.1 与 scoped permissions 管控，可按 posts:read、comments:write 等粒度授权，避免给予管理员级权限。

部署方面，Basehim 刻意降低门槛：只要服务器能跑 PHP 8.1+ 与 MySQL 5.7+ / MariaDB 10.3+，即可上传文件、运行安装向导完成部署，无需 Composer、前端构建流程或常驻守护进程，兼容 cPanel、Plesk、Apache 与共享主机等传统 PHP 托管环境。

扩展机制采用应用（App）与主题（Theme）分离的架构。App 位于 content/apps/ 目录，通过 app.json 清单与 boot() 方法注册钩子、路由、Widget 及后台菜单项；App 可声明所需权限，管理员在激活前可见。主题则负责纯展示层，无需复杂前端构建。

项目以 MIT 许可证开源，代码库结构清晰，包含 Core、Http、Repositories、Services 等组件，并附带 docs、CHANGELOG、CONTRIBUTING 等文档。当前核心安装约占用 30 MB 磁盘空间。

Basehim 的定位并非取代 WordPress，而是为希望以 API、模块化和 AI Agent 为核心构建网站、又不想被复杂基础设施绑定的开发者提供一个更轻量的基础。它适合那些想让 AI 成为网站可操作接口、而非仅仅在页面上挂一个聊天机器人的场景。

GitHub: GitHub

#开发者 #工具 #Basehim #PHP #CMS #MCP #AI #OAuth #开源
@DevToolboxHub

Zenoh 的 put 与 get 存在读写竞态

Zenohex 是 Zenoh 的 Elixir 绑定。作者用它做 put/get 存储实验时发现，put 后立刻 get 偶尔会读到旧值。2000 次循环中约 78 次（3.9%）出现 stale 读取，但紧接着再查一次几乎总能拿到正确值，说明写入只是有短暂延迟窗口，并非数据丢失。

根因在 NIF 实现：put 的 .wait() 只等本地会话把消息发出，不等远端 zenohd 路由实际存储；而 get 是 DirtyIo NIF，会真正等待远端回复。用 Elixir 术语类比，put 像 cast，get 像 call。上游 eclipse-zenoh/zenoh#2511 已跟踪此问题，仍未解决。

作者给出修复方案：封装 ZenohAckPut 模块，put 后立即 get 同一 key 确认，按短间隔重试直到超时。返回三种结果：:ok 表示写入并确认成功；{:error, :not_confirmed} 表示 put 成功但超时未确认；{:error, reason} 表示 put 本身失败。用同一 2000 次循环验证，stale 读取和超时均为零。

模块已发布为 zenohackput，含复现脚本和验证脚本，暂未上 Hex，需以 git 依赖引入。若用 Zenoh 的 put/get 做状态交接等需要「写后即读」一致的场景，这个不对称值得留意。

GitHub

#开发者 #工具 #Zenoh #Zenohex #Elixir #存储 #读写竞态
@DevToolboxHub

Android 低功耗地理围栏引擎实践

开发者分享了一篇关于为 Android 后台服务构建低功耗地理围栏引擎的技术文章，核心思路是用系统级 GeofencingClient 替代高频 GPS 轮询，实现按物理位置自动切换手机声音模式。

作者最初想解决的是公共场合手机响铃的尴尬场景：在办公室自动振动、在家恢复响铃、在诊所自动静音。传统方案依赖 GPS 轮询，几小时就能耗尽电量。改用 GeofencingClient 后，系统会综合 Wi-Fi、基站和 GPS 数据，只在跨越围栏边界时才唤醒应用，能耗大幅降低。

实现上通过 PendingIntent 将触发逻辑与应用进程解耦，即使应用被系统回收，围栏注册仍由 Google Play Services 进程持有。BroadcastReceiver 收到事件后唤醒 ForegroundService，再切换 AudioManager 状态。代码中特意使用 FLAG_IMMUTABLE 防止其他应用劫持 Intent 篡改静音模式。

作者踩过的坑包括：部分厂商的激进省电策略会抑制 Doze 模式下的围栏触发，直到用户手动亮屏才生效；排查了三周才发现是 WorkManager 交互导致退出事件不触发，最终强制应用忽略电池优化。另外 Play Services 定位库是个黑盒，系统因低电量降级围栏时无从得知原因。

给同行的建议是别自己写轮询循环，在电源管理上不可能赢过 Google 的工程师。用高层的 GeofencingClient 并把精力花在边界情况上：GPS 信号丢失怎么办、用户在地下室怎么办。始终假设应用会在最不合时宜的时刻被杀掉，用 PendingIntent 加本地数据库（作者用 Room）保证重启后能立即恢复配置。

作者将这套方案落地为应用 Muffle，用户无需手动切换声音配置。核心教训是：做后台定位服务要顺着系统限制走，而不是对抗它。

#开发者 #工具 #Android #Kotlin #Geofencing #后台服务 #低功耗 #GPS #Muffle
@DevToolboxHub

把安全审计从循环变成一次性工件

Kelsey Hightower 在 PlatformCon 2026 的演讲讲了一个贯穿职业生涯的原则：一次解决问题，把解法编码成可复用工件，之后不再重复解决。这个原则同样适用于安全验证。

他讲过一个 Jira 循环的故事：部署靠 Jira 工单驱动，工程师读工单、复制参数、跑命令、贴回输出、关单，每小时重复一次。他写了一个 Puppet manifest 监视工单、提取参数、执行部署、回贴结果并关单，循环跑完一次就结束了。Docker 和 Kubernetes 也是同样模式——不是让手动步骤变快，而是识别出重复中的抽象，让手动步骤变得不必要。

安全审计正陷入同样的陷阱。工程师每周打开每个 AWS 账户，检查 IAM 策略的通配符、过度授权的托管策略、无条件的跨账户信任，记录发现、跟踪修复，下周再来一遍。Reddit 上有人抱怨「做安全审计做到崩溃，每个开发都在角色上贴 s3:* 或 AdministratorAccess」。市场给出的答案是「用 AI 加速审计」——让 Claude 读 IAM 策略、让 agent 审 CloudFormation 模板。但 AI 读策略、推断风险、生成文字、消耗 token，下次扫描换个策略问同样的问题，一千个策略就是一千次 LLM 调用，每次发现同一类问题都花同样的成本，组织没有任何积累。

Stave 的做法是把抽象提取为「对配置快照求值的正式规范」。一个 control 就是一个编译成可复用工件的已解决问题，比如 CTL.IAM.ROLE.FULLACCESS.MANAGED.001 检查是否有 IAM 角色附加了完全访问的托管策略。它是 CEL 谓词，每次求值确定性输出，零 token、零 LLM 调用。3000 多个 control 就是 3000 多个只跑过一次就变成可复用工件的循环。成本对比很直观：AI agent 方案按 1000 账户、每账户 100 角色、每周扫描算，一年 520 万次 LLM 调用；Stave 是 3000 多个谓词对观测数据求值，毫秒级 CPU，零 token。

他的收尾是「确保训练你自己的模型」——指心智模型，从业者几十年从事故、审计、错误配置中积累的模式识别能力。control 目录就是这个模型的外化：每个 control 编码了一个从业者从事故或审计中学到的模式，通过 Red-Green 测试验证、HAZOP 校验，永久学习、不会遗忘。Kelsey 的模型存在一个人脑子里，42 岁退休就没了；目录是外化、形式化、可执行、可共享的。

他还用 deploy.sh 的故事说明知识载体的问题：SharePoint 里文档写的是 deploy.sh，实际能跑的是 this_one_works.sh，没人更新文档。Stave 用可执行规范替代文档——control 不是「可能被读、可能被遵守」的文档，而是每次对每个配置求值的谓词，知识即执行，错了由测试套件在依赖它之前拦住。

采用路径遵循 Unix 管道哲学：先学单条命令 iam-explain role.json，再用管道组合 iam-explain role.json --output obs | stave apply，最后为组织特定模式写自定义 control。iam-explain 解析 IAM 策略输出观测，stave apply 对观测求值，obs.v0.1 JSON 是两者之间的文本流，每个阶段都可检查。

Stave 是开源的 AWS 配置验证器，iam-explain 是带 Z3 形式验证的单策略 IAM 分析器。核心思路：把安全知识从文档和人工检查变成可执行、可组合、零边际成本的工件，一次解决，永久复用。

#开发者 #工具 #Stave #AWS #IAM #KelseyHightower #PlatformCon #安全审计 #云安全 #DevOps
@DevToolboxHub

ESP32-S3 自制 CH32V003 烧录器

作者用 ESP32-S3 替代专用 WCH-Link，通过 SWIO 协议为 CH32V003 实现完整烧录流程，并开源了全部代码。

项目链路为 PC → ESP32-S3 → SWIO → CH32V003，由 ESP32-S3 直接处理时序敏感的 SWIO 通信与 DMI 调试接口，实现了目标检测、内存访问、flash 解锁、页擦除、编程、回读校验及复位运行。硬件方面使用 ESP32-S3 N8R2、CH32V003A4M6（SOP-16）、4.7kΩ–10kΩ SWIO 上拉电阻及 CP6208 电机驱动。

早期版本 SWIO 同步失败（DMCFGR = 0xFFFFFFFF），作者排查启动时序、接收行为与物理接线后，成功输出 SWIO sync: OK、DMI communication: OK、CH32 ID = 0x0713BB91。flash 操作中观察到 FLASH_CTLR 解锁前后从 0x00008080 变为 0x00000200，随后用确定性数据测试编程与回读，零失配。

首个实际应用为驱动 PC4 的裸机固件，配合 CP6208 与直流电机。首次上电失败，排查发现固件已正确烧录且 PC4 输出约 3.3V，问题出在 CP6208 第二输入为 HIGH 而非 LOW，接地后电机正常运转。作者总结：烧录链路完全正确时，最终硬件应用仍可能出错。

主机端提供 Python 命令行工具，示例：python tools/flash_tool.py --port COM10 --bin firmware/ch32_blink/blink.bin --addr 0x08000000 --reset。真机最终测试全部通过：目标检测、编程、校验、复位运行均 OK。

代码仓库包含 ESP32-S3 固件、CH32V003 示例、Python 烧录器、硬件与 SWIO/DMI 文档。作者下一步计划探索该方案向其他 WCH RISC-V 器件的扩展性。

GitHub

#开发者 #工具 #ESP32S3 #CH32V003 #SWIO #RISCV #嵌入式 #烧录器
@DevToolboxHub

React Native 八种项目结构拆解

一篇来自团队 lead 的实战梳理，对比 8 种 React Native 项目目录结构各自解决什么问题，以及 "Domain-Driven" 和 "Micro-Frontend" 两个标签常被误用的地方。选错结构，代码库要么能吸收更多功能和工程师，要么在自身重量下崩塌、最后专门招人来重写。

八种结构速览：
• Flat Structure：所有文件平铺在 src/，适合原型、hackathon、单屏 demo；超过 10-15 个文件后难以定位。
• Feature-Based：按产品功能划分，auth、feed 各自拥有 components、screens、services，是生产环境最常见结构；但功能文件夹本身不强制隔离，跨功能 import 一多就退回扁平结构，需用 lint 规则约束。
• Layered：按技术角色分组（components、screens、services），适合小团队；缺点是 components 和 screens 会变成大杂烩，看不出文件归属哪个功能。
• Domain-Based：按业务能力分组，常被误称 DDD——真正的 DDD 是建模纪律，涉及限界上下文、聚合等，这里只是按业务域映射团队边界，适合大规模多团队产品。
• Atomic Design：UI 组件架构而非应用架构，按 atoms、molecules、organisms、templates、pages 分层，适合做跨应用共享的组件库。
• Duck：把 reducer 的 actions、types、逻辑放同一文件夹，Redux Toolkit 的 createSlice 已吸收此思路，多见于老代码库。
• Monorepo：apps/mobile 与 apps/web 共享 packages/ 下的业务逻辑、组件和工具，避免双端逻辑漂移；可用 Yarn Workspaces 或 Lerna 起步，规模大了配 Nx 或 Turborepo。
• Modular：常被叫 "Micro-Frontend"，但 RN 没有 Web 那种运行时组合能力，只有一个 JS bundle；真正接近的是 Re.Pack 或原生 super-app 插件架构，多数团队实际只是更严格的 feature/domain 组织。

选型框架看三点：项目规模与复杂度、团队人数与分工、增长预期。示例路径：小团队从 Feature-Based 起步，到约 100 人引入 Monorepo，再往后按业务域迁移到 Domain-Based。早期不做这些思考不算错，但营收和用户增长出现后，公司通常会招资深工程师来给从未为扩展设计的代码补架构。

#开发者 #工具 #ReactNative #移动开发 #项目架构 #Monorepo #DDD #Redux #前端架构
@DevToolboxHub

浏览器硬件诊断：能读到什么，读不到什么

作者花时间构建了一套基于浏览器的硬件诊断工具，并总结出 Web 平台在硬件检测上的真实边界。核心结论：出于反指纹追踪的考虑，几乎所有硬件相关 API 都被刻意削弱，浏览器能给出的只是相对测量值，而非真实硬件规格。

刷新率：没有 screen.refreshRate 这类 API，唯一办法是用 requestAnimationFrame 回调计时，取帧间隔的中位数推算。注意必须用中位数而非平均值，一次掉帧就会毁掉平均值；且后台标签页会节流 rAF，测量前需检查 document.visibilityState。

屏幕尺寸：screen.width、window.innerWidth、devicePixelRatio、screen.availWidth 测量的是不同东西。通常想要的原生面板分辨率是 screen.width * devicePixelRatio，但这也是基于 CSS 像素推导的，缩放显示下可能与物理面板不一致。浏览器根本不暴露真实硬件分辨率。

键盘：event.key 依赖布局，event.code 是物理位置，硬件测试应使用后者。PrintScreen 常不触发 keydown，Meta 组合键被系统吞掉，Fn 在多数笔记本上不可见。N-key rollover 测试效果不错，跟踪当前按住的 Set 大小即可，廉价键盘在 3-4 键同按时丢输入会很明显。

指针事件：pointerdown/pointerup 统一了鼠标、触摸和笔，pointerId 可正确追踪多点触控。检测磨损开关的双击故障，只需测量同一按钮连续 pointerdown 的间隔，低于约 80ms 且无移动，基本可判定为硬件故障。注意 preventDefault() 会杀掉后续的兼容鼠标事件。

Gamepad：轴移动没有事件，只能在 rAF 循环里轮询 navigator.getGamepads()。控制器在用户按键前不会出现，数组里全是 null。摇杆漂移表现为静止时轴值不为 0，超过约 0.08 即为电位器磨损。

媒体设备：enumerateDevices() 在授权前能列出设备但标签全为空字符串，只有 getUserMedia() 成功后才有可读名称。麦克风电平用 AnalyserNode 的 getByteTimeDomainData 计算 RMS 比频域数据更稳定。

坏点检测：没有 API，唯一可行方案是用 Fullscreen API 填充纯色让肉眼观察。不是所有问题都需要程序化答案，全屏渲染 #ff0000 本身就是工具。

所有十个诊断 demo 均在客户端运行、不上传任何数据。作者认为，诚实的工具应测量行为而非声称读取规格，并欢迎对刷新率测量方案的改进建议。

#开发者 #工具 #JavaScript #硬件诊断 #浏览器API #WebAPI #性能测试
@DevToolboxHub

纯浏览器 SVG 文字特效生成器 GummyType

作者分享了一款完全在浏览器本地运行的文字图形生成器 GummyType，支持气泡、Y2K、镀铬等风格，无需账号、上传或服务端渲染。核心管线为 React 控件 → SVG 字符串 → SVG Blob → HTML Image → Canvas 栅格化 → 裁剪 PNG，SVG 生成逻辑封装为纯 TypeScript 函数，便于无浏览器环境测试。

字体一致性通过打包 TTF 文件并以内嵌 @font-face 方式写入 SVG 解决，避免不同设备回退字体导致的渲染差异。画布尺寸基于 CanvasRenderingContext2D.measureText 实测文本宽度计算，而非字符数，防止长句被裁剪或短句导出为巨大固定画布。预览与导出使用两套 SVG 渲染：预览框按最大字号固定尺寸保持稳定，导出则紧贴当前字号裁剪。PNG 导出通过读取 alpha 通道自动裁剪透明边距，并保留安全边距避免阴影被切，纯色或渐变背景时跳过此步骤。

细节处理：

• 用户输入空格替换为不换行空格防止 SVG 栅格化时被折叠；异步渲染通过 effect cleanup 标记失效结果防止旧渲染覆盖新预览；每次生成的 object URL 在替换或组件卸载时及时 revoke；输入长度设限避免极端画布尺寸。作者计划后续增加更多字体形状
• SVG 导出
• 预设样式
• 键盘控制与更多导出背景

#开发者 #工具 #GummyType #SVG #Canvas #Nextjs #TypeScript #前端
@DevToolboxHub

功能开关实战：五种安全上线姿势

功能开关不只是简单的开关，它把部署和发布解耦，让团队在代码上线后仍能控制功能暴露范围。工程团队常用它做金丝雀发布、A/B 测试、熔断开关、内测和暗发布，核心都是降低生产事故风险。

金丝雀发布：先让 1% 用户尝鲜，出问题立刻关掉开关排查，没问题再逐步放量。对高流量系统尤其有用，小 bug 也可能影响成千上万用户，慢速放量能拿到真实生产信号。

A/B 测试：用开关把流量分到不同版本，让数据决定哪个方案胜出。实验结束删掉失败分支即可。理论简单，但实验跑几个月后容易忘了当初在测什么。

熔断开关：第三方 API 返回垃圾数据、数据库查询锁死、新功能内存泄漏时，值班工程师几秒就能关掉问题功能，不用回滚部署或半夜叫醒发布经理。

内测与抢先体验：给核心用户、内部测试者、Beta 客户提前开放新功能，收集真实反馈。反馈差就只对测试组关闭，反馈好就全量发布。用 Web UI 管理测试组比改配置文件方便得多。

暗发布：新代码在生产环境运行但不展示给用户，结果写入日志或监控系统。适合验证新数据库查询、算法替换、基础设施迁移等高风险后端变更，在提交全量前拿到生产级验证。

功能开关的价值在于把发布风险拆小，让团队在真实流量下逐步验证。想省去自建管理后台的功夫，可以试试 FeatureFlags.app 这类现成工具。
@DevToolboxHub

Spring AI 实战：用 OpenAI 构建首个应用

本教程带你从零搭建一个基于 Spring Boot 与 OpenAI 的 AI 应用，通过一个简单的 REST 接口，完整走通从项目初始化、配置 API Key、创建 Controller 到发送 Prompt 的全流程。

教程核心步骤：

• 通过 Spring Initializr 创建 Maven 项目并引入 Spring AI OpenAI starter；使用环境变量配置 API Key，避免硬编码进源码；通过 ChatClient.Builder 注入并构建 ChatClient；创建 ChatController 暴露 GET /api/chat 接口；引入 Service 层分离 HTTP 与 AI 交互逻辑；使用 system 消息约束模型行为。教程还梳理了 ChatClient 的 prompt()
• call()
• content() 三个核心操作，并对比了 System Message 与 User Message 的职责差异

常见错误提醒：不要把 API Key 提交到 Git；避免在每个 Controller 中直接调用 AI 模型，应统一经过 Service 层；ChatClient 是面向应用的抽象，底层模型集成由 ChatModel 处理；生产环境应通过 system 指令控制模型行为；初期不要直接引入 RAG、向量数据库、Agent 等复杂架构，按需演进。

教程最后展示了完整的 ChatService、ChatController 与配置示例，并预告下一部分将使用 Ollama 在本地运行 LLM，同一套 ChatClient 代码可无缝切换 OpenAI、Ollama 等不同模型提供商。

#开发者 #工具 #SpringAI #SpringBoot #OpenAI #Java #AI #LLM
@DevToolboxHub

生成式 SQL 提速可能悄悄丢行

生成式 AI 改写的 SQL 跑得更快，不代表结果正确。提速可能来自 join 类型变化——比如 inner join 悄悄丢掉了 left join 保留的行。因为显示出来的每行都有客户名，快速冒烟测试很难发现缺失。在差分检查对比新旧结果集之前，应把生成式查询改动当作补丁，而非证明。

join 变化里藏着的失败

用一个小数据夹具演示：orders 表里有一条订单，对应 customers 表中不存在的客户。这种悬空引用在遗留系统里很常见，正是 join 转换改变查询语义的地方。原查询用 LEFT JOIN 保留全部 5 行订单，其中一行 name 为 NULL；生成式改写只把 join 类型换成 INNER JOIN，因为它在 schema 保证 customer_id 都存在时读起来更好、通常也更快——但本例中该保证不成立，结果只剩 4 行。性能提升同时改变结果集，就不是优化。

合并前先做黄金结果校验

不要靠肉眼对比前几行。正确做法是建立已知正确的基线、规范化结果集，任何不匹配的候选都直接判失败。用 SQLite 脚本即可实现：构造含悬空引用的 fixture，分别执行基线与候选查询，打印候选缺失的行，结果集不一致就抛出异常。脚本直接输出消失的行，而不是让开发者盯着两张表找差异——这个差异才是调试信号。

让 fixture 贴近生产数据

只含 happy path 的测试通过意义有限。夹具应包含多种边界情况：父记录缺失的子行、无子行的父记录、重复子行、与空字符串不同的 NULL、零值/负数/最大长度等边界值、与索引顺序不同的插入顺序。即便基线与候选在这种"丑陋"夹具上返回相同结果，也只证明消除了一类静默结果集变化，并未证明正确性。

生成多个候选，统一过校验

模型返回更快查询时，最糟的下一步是因其解释听起来自信就合并。更安全的循环是要求多个改写版本，让每个候选都过同一套黄金结果检查。MonkeyCode 的免费模型访问降低了生成第二、第三个候选的成本，不必在第一个看似合理的版本就停下。这不是更信任模型，而是让模型输出足够便宜，可以当作必须通过自动化检查的假设。

替换慢查询的工作流

保存当前 fixture 的结果集，记录基线行的规范化签名；让模型生成三个候选改写而非一个；每个候选跑同一 fixture 和签名；只保留匹配基线的候选；用 EXPLAIN 或 EXPLAIN QUERY PLAN 检查匹配候选是否真的改进了执行计划。若没有候选既匹配又更快，正确输出不是合并补丁，而是列出模型下次应遵守的约束清单。

免费服务端方案的适用场景

笔记本能跑小 fixture，但某些查询 bug 只在大快照下出现，而大快照无法复制到每台开发机。此时可把黄金结果集放到小型对比端点后，让每个候选提交输出换取通过/失败响应。端点做两件事：报告候选行集是否等于基线，返回缺失或多余行的 diff——这个 diff 比模型的解释更有用，因为它来自数据。不要把真实客户数据发给模型或公共服务器，应生成保留相同 join、null、基数陷阱的 fixture，在可控环境里跑完整隐私敏感对比。

方法的局限

差分测试能捕获语义回归，但不能证明查询正确，只证明候选匹配所选基线。SQLite 适合本地 fixture，但 SQL 语义和优化器行为与 PostgreSQL、MySQL、SQL Server、Oracle 不同。黄金基线本身可能错误或过期；查询可能匹配 fixture 却在未包含的数据形态上失败；更快的计划仍可能内存占用过高、锁时间过长或忽略生产环境有用索引。该方法增加步骤，对无静默丢失风险的只读仪表盘属于过度设计。若没有已知正确的结果集、无法安全构造代表性 fixture，就不要把本地通过当作数据库保证。对任何生成代码都应如此：在信任解释之前，先验证真正重要的行为。

#开发者 #工具 #SQL #SQLite #差分测试 #生成式AI #MonkeyCode #查询优化
@DevToolboxHub

用 30 条安全通告实测模型判级准确率

一位开发者因模型把 critical 误判为 low，决定搭建一套可复现的准确率测试。他基于 30 条人工核对过的通告记录，让模型提取包名、严重级别和处置动作，并分别统计误报与漏报。测试脚本很短，读取 JSONL 文件，调用仅返回 JSON 的接口，再与期望值比对。

一次本地运行示例显示：critical 召回率 0.90，moderate 召回率 0.62。模型能抓住多数高危通告，但常把 moderate 降级为 low。作者指出，漏报比误报更危险——跳过关键升级的代价远高于一次多余审查。

测试暴露三类反复出现的失败模式：厂商用词不一致（"important" 被映射为 moderate）、包名冲突（libxml2 被识别为 libxml）、长通告截断导致修复版本信息丢失。

作者明确不建议让该输出自动开合并请求，只用于人工复核前的分诊。需要审计级报告、升级工具无人复核或涉及合规系统时，不应采用此方案。建议从十条记录起步，人工标注期望值，先观察错误模式是否稳定再扩大规模。

这套方法的价值在于可复现：用固定测试集而非实时通告，避免厂商页面和模型行为变化影响结果。先度量，再信任。

#开发者 #工具 #安全通告 #AI评测 #Python #DevOps #依赖管理
@DevToolboxHub

AI Security Studio：全离线自动化安全扫描

AI Security Studio 推出一套完全本地化的安全扫描方案，核心卖点是代码不出机器。多数 AI 安全工具依赖云端推理，代码需上传至外部服务器，这在 NDA 客户项目、受监管代码库或不愿源码进入他人日志的场景下难以接受。该工具所有流程本地运行，支持 Ollama、llama.cpp、LM Studio 等本地 LLM，无外部 API 调用，无遥测。

扫描流程采用「确定性优先、LLM 其次」的设计：静态解析（Roslyn / Tree-sitter）与规则引擎先行，完成密钥检测、头部分析、JWT 校验、SQLi/XSS 模式匹配等实际发现工作。LLM 只接触规则引擎产出的结构化摘要，不读取原始源码，负责解释漏洞成因、关联发现、撰写报告。证据不足时系统明确标注「需人工验证」，而非强行下结论。

自动化引擎 ASS Script 采用 iMacro 风格的录制/回放/编辑机制，基于应用内节点图设计器构建。脚本为纯 YAML 格式，可读可 diff，每个节点对应真实 GUI 操作或真实扫描调用，无模拟步骤。录制一次工作流后，可从 GUI 或 CLI 重复执行。

配套的离线演示视频生成管线同样贯彻本地优先：以 Markdown 表格编写分镜脚本，Python 脚本解析时间轴，调用 macOS 内置 say 合成旁白，ffprobe 测量片段时长，ffmpeg 拼接音轨，并生成与真实音频同步的 SRT 字幕。全程无需 API 密钥或云端依赖。

该模式可推广至更广场景：将 LLM 视为可选可替换组件，确定性、本地优先的部分前置。安全管线如此，周边工具链亦然——当架构中「AI」实际意味着「网络调用」时，值得重新审视。

#开发者 #工具 #AI安全 #安全扫描 #本地LLM #Ollama #自动化 #离线TTS
@DevToolboxHub

用 Notion 记录 30 天焦虑数据

一位开发者用认知行为疗法（CBT）的思维记录表，在 Notion 里持续 30 天追踪自己的焦虑情绪，共记录 47 条。结果显示 81% 的焦虑念头只落在三类重复模式上，且焦虑高峰集中在周一和周三。记录本身就能让情绪强度平均下降 39.4%。

实验方法：每次感到焦虑、 overwhelmed 或卡住时，打开 Notion 页面填写 CBT 思维记录表，包含情境、自动思维、情绪强度（0-100）、支持证据、反对证据、平衡思维和记录后情绪七个字段。

关键发现一：47 条记录中 38 条（81%）只属于三种重复念头——「我不够格做这个任务」（32%）、「他们会发现我不懂装懂」（28%）、「今天做不完就全完了」（21%）。识别出这三类后，可以提前准备应对方案，不必每次从零推理。

关键发现二：焦虑分布有明确规律，周一 9 条、周三 10 条为高峰，周日晚间有次级高峰。作者在周一早上增加 10 分钟「过渡仪式」，后两周周一焦虑记录从 9 条降到 4 条。

关键发现三：89% 的记录中，反对焦虑念头的证据强度（平均 7.8/10）高于支持证据（平均 4.2/10），但当下每个念头都感觉 100% 真实。关键发现四：情绪强度在记录后从平均 71/100 降至 43/100，降幅 39.4%，且与念头类型和时间无关——结构化自我审视的过程本身就是有效成分。

作者使用的 Notion 模板包含 7 个 CBT 字段的表单、自动时间戳、按日期/情绪类型/强度排序的仪表盘、相似念头分组视图和每周回顾模板，单次填写约 2 分钟，30 天总耗时约 4 小时。模板在 Gumroad 上售价 7 美元。

作者复盘建议：先做 7 天而非 30 天；手机端也要记录，桌面端会漏掉睡前和通勤时的高峰；不要跳过「平衡思维」字段，跳过两次时情绪强度都保持在 80 以上；每周回顾是最有价值的 15 分钟。作者强调这不是专业医疗替代品，但思维记录表本质上就是大脑的日志文件。

#开发者 #工具 #Notion #CBT #心理健康 #效率 #自我调试
@DevToolboxHub

RAG 异步管线与 MCP 协议解析

RAG 检索中，混合搜索通常按顺序执行向量检索、文本检索和语义缓存查询。若三者分别耗时 10 秒、5 秒、2 秒，串行需等待 17 秒才能拿到上下文。改用异步管线后，三个线程同时启动，最坏也只需等最慢的 10 秒，显著降低延迟。多线程模式下每个任务分配独立线程，受限于可用 CPU 核心数；上下文切换则让单线程在多个任务间轮转，即并行处理。

MCP（Model Context Protocol）解决的是工具调用标准化问题。LLM 本身无法回答"今天发生了什么"，但通过工具调用，把外部功能结果喂给模型即可作答。传统做法是每个开发者各自编写获取天气等功能的代码，结果大同小异却重复造轮子。MCP 由数据提供方定义通用工具与协议，消费方直接调用，无需自研代码。工具可通过 StdIO（同机进程内）或 HTTP（引入额外延迟）两种方式调用。

MCP 与 RAG 的结合方式：将已构建的 RAG 系统封装为 MCP 工具，RAG 负责从文档检索信息，MCP 对外暴露统一接口，LLM 或应用按需调用。这样其他开发者无需直接访问底层数据库或编写检索代码，即可复用 RAG 能力。MCP 成为 RAG 系统与各应用之间的标准中间层，职责分离清晰。

#开发者 #工具 #RAG #MCP #异步管线 #多线程 #混合搜索 #LLM #模型上下文协议
@DevToolboxHub