TGViewer
Channel Public Channel
开发者工具箱|编程·开发工具·资源

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

@devtoolboxhub

面向开发者的实用工具、库与效率技巧,写代码更快更爽。投稿 @BDHT1
#开发者 #编程工具 #效率 #程序员 · 开源总站 @GitHubTrendingHub
Subscribers
779
Photos
1.4K
Videos
0
Links
766

Showing posts older than #1474 · Back to latest

Older Posts 20 shown
Post #1473 6
TanStack Table V9 Beta 发布:Tree-Shakable、新状态管理与更低内存占用

TanStack Table V9 进入 Beta 阶段,这是一个面向多种 JavaScript 框架的无头 UI 库,用于构建表格和数据网格。此次基础性重写聚焦于状态管理、内存效率、包体积和可扩展性,同时保持开发者已熟悉的核心表格逻辑。

最显著的变化是引入选择加入(opt-in)功能模型。开发者仅需加载实际使用的组件,实现 tree-shaking 优化。状态层迁移至 TanStack Store,进一步降低内存占用。官方提供渐进式迁移路径及向后兼容工具,确保从 V8 平稳过渡。该库继续保持免费、面向开发者的定位。

#开发者 #工具 #TanStackTable #V9Beta #状态管理 #无头UI #JavaScript
@DevToolboxHub
Post #1471 4
10个LLM评估实验,只跑了1个——够了

作者设计了10个实验来回答一个问题:在日常开发中,什么时候需要前沿模型,什么时候只是在浪费钱?最终他只跑了1个CI诊断实验,结果就够用了。

实验对比了Haiku 4.5和Sonnet 5(通过OpenRouter),使用真实GitHub Actions日志,约50次run。结果:Haiku便宜10倍,快67%,准确率相当。对CI诊断这类任务,Haiku是默认选择,Sonnet只在必要时使用。整个实验花费$13.53。

作者还构建了可复用的评估框架model-compass,涵盖9个真实Agent任务(CI诊断、事故事件分类、代码审查、PR撰写、架构分析等),支持多模型适配层和成本自动计算。
同时提到了开源路由器TierForge,它能将评估证据转化为YAML路由规则,如“CI诊断默认用Haiku,满足特定条件升级到Sonnet”。
关键教训:不需要跑完所有实验,一个精心选定的实验就能校准直觉;评估框架比发布论文更有价值;个人预算决定了学习策略;成本问题背后常隐藏着信任、控制等深层担忧。


#开发者 #工具 #LLM #CI #Haiku #Sonnet #ModelCompass #TierForge #DevOps #成本优化
@DevToolboxHub
Post #1470 5
AxonASP 集成 Caddy 实现服务端JS渲染

AxonASP 是一个 Caddy 模块,将服务端 JavaScript 运行时直接嵌入 Caddy 的 HTTP 处理器内,无需配置 FastCGI、反向代理等组件,实现零进程架构。配合 Caddy 自动 HTTPS,几秒内即可启动动态服务。

步骤速览:
1. 获取服务器:下载含 AxonASP 的预编译二进制,或用 xcaddy 从源码构建。
2. 配置 Caddyfile:在 route 块中添加 axonasp 指令,与 file_server 共存。
3. 编写服务端 JS 页面:在 www 目录创建 default.asp,以 <%@Language="JavaScript"%> 开启 JS 引擎,编写服务器端逻辑。
4. 启动:运行 caddy run,访问 即可看到由服务端 JavaScript 渲染的动态页面。


整个过程不到一分钟即可完成搭建,天然支持 Caddy 的自动 HTTPS 和生产级扩展性,适合快速构建动态 Web 服务。

#开发者 #工具 #AxonASP #Caddy #服务端JavaScript #Caddyfile #零进程架构
@DevToolboxHub
Post #1469 5
AI 编码周报:活动账本而非生产力分数

一周的 Claude Code 和 Codex 工作会在本地留下足够的痕迹,能回答几个具体问题:会话何时活跃?哪些供应商产生了活动?哪些模型出现?每日 token 结构如何变化?但它无法证明代码是否正确、这周是否有产出、API 估值是否等于实际花费。正是这个边界让周报有用。

使用本地日历日:周报应覆盖今天加之前六个本地日历日。标题、每日柱状图、供应商总计和模型行必须使用相同的边界。若图表用日历日而模型行用滚动 168 小时窗口,各部件会不一致,一行可能超出标题,即使每个单独计算都看似合理。时区和午夜行为是核算规则。

token 总量描述活动:输入、输出、缓存创建和缓存读取代表不同工作。建议保留两个总量:wire token 总量(包含本地记录的所有分类)和输入/输出总量(排除缓存流量)。两者都不是生产力分数。缓存密集的重构可能比小改动移动更多 token;一次失败运行可能很昂贵;安静的会话可能是在等人而非空闲。

比较供应商时不制造等价:供应商拆分能显示多少记录活动来自 Claude Code、多少来自 Codex,但无法证明每个供应商的一个 token 代表同等的工作、延迟、质量或配额压力。供应商配额是报告状态,本地 token 活动是重建的账本。显示两者没问题,用一个填补另一个的缺失数据则不行。

每个事件保留模型上下文:一个会话可以切换模型。后面的 token 事件需要当时活动的模型上下文,而非文件顶部显示的模型。未知命名的模型应保持可见且无定价。猜测相近模型家族会让历史报告不可审计。token 排名和 API 估值排名也不同:一个模型可能因大量廉价缓存读取而数量领先,另一个则因估值领先。

五分钟周回顾:用周报做一次操作决策——检查七天是否齐全,寻找缺口、重播峰值或过期供应商数据;比较供应商和模型组合而不将其视为质量;仅在显示的费率日期下阅读预估 API 值;为下一周写一个工作流变更,例如减少无人值守运行、修复重复身份验证失败或更改开始长会话的时间。数字本身不改进工作流,决策才改进。

分享必须是单独操作:本地报告默认应留在本地。Agent Island 从已存储在机器上的记录构建报告,内容不上传到其服务。可分享的卡片是渲染摘要而非自动广播,复制或导出需要显式操作。分享前检查日期、总量、模型名称和项目上下文,排除任何不愿披露的信息。


一份周报通过说明每个数字的含义及其不能证明什么来赢得信任。完整工作流与当前验证范围见规范指南。

#开发者 #工具 #AI编码 #周报 #活动日志 #Claude #Codex #AgentIsland
@DevToolboxHub
Post #1468 5
AI编程成本追踪:需要一份测量合同

AI编程仪表盘中最危险的数字是那些标着“成本”却没有定义的值。一个本地工具可以从 Claude Code 和 Codex 的会话记录中重构 token 活动,并应用一份带日期的模型价格表,生成一个可用于对比周期和理解本地活动形态的估算——但它不是发票。

第一步:统一文件格式边界。Claude Code 和 Codex 的记录格式不同——Claude 在 assistant 消息中暴露 input、output、cache creation、cache read 字段;Codex 则将 model context 与后续 token 事件分开,cached input 可能包含在 total input 内。计算前必须归一化:provider、timestamp、model、input tokens、output tokens、cache creation tokens、cache read tokens。
第二步:正确计算缓存输入。对于 Codex,安全做法是先分离 cached input:non-cached input = max(total input - cached input, 0),然后分别按不同费率计价 non-cached input、output、cache creation、cache reads。如果直接用 total input 计价再加 cache reads,会造成精确的重复计数。
第三步:防止重放。会话文件会被多次读取、应用重启、监视器重连、归档文件重现。如果每次观察到同一事件都计数,周报会膨胀。使用稳定的 provider 事件标识符;若格式无此标识,需记录回退方案及其不确定性。
第四步:价格表必须带日期。新模型 ID 可能在桌面应用得知费率之前出现,API 价格也可能变更。追踪器应附带一份带日期的费率快照,对未知名称的模型保留可见但不计价,历史报告保留费率日期。在 Agent Island 中,计算出的数字被标记为“API value”——这是基于嵌入费率的反事实估算。
第五步:区分四种度量。一个有用的仪表盘不应把这些合并为一个指标:Provider quota(账户距重置边界的距离)、Local token volume(会话记录的内容)、Estimated API value(基于日期化的 token 类别计算)、Actual billing(收据、额度、订阅、provider 端调整)。只有第四项是账单,本地记录不足以重建它。


在使用任何 AI 编程成本追踪工具前,对照以下问题检查:它读取哪些本地记录?是否分离 input、output、cache creation、cache reads?如何防止重放事件被重复计数?当模型不在费率表中时如何处理?价格快照是否带日期?UI 显示的是“估算”还是暗示“实际支出”?数据收集是否本地化,分享是否是独立操作?如果那个数字可能被误认为是已支付的费用,说明文字应当紧挨着数字出现。

#开发者 #工具 #AI编程 #成本追踪 #测量合同 #ClaudeCode #Codex #AgentIsland #本地工具
@DevToolboxHub
Post #1467 5
AI 调试:提速还是添乱?

AI 辅助调试已成为许多开发者的日常。把堆栈粘贴进 ChatGPT,或向 Copilot Chat 描述意外行为,几秒内就能拿到假设甚至修复方案。但真实场景下,这些工具的效果远比表面复杂——它在哪些地方真正省时,又引入了哪些新风险?

AI 调试的核心是模式匹配,而非真正运行代码。对于空列表除零这类常见错误,它能迅速给出正确修复。跨语言场景下,它能帮不熟悉 JS 异步错误的开发者快速理解问题。但当 bug 不匹配已知模式时,AI 往往给出自信但错误的答案。例如,面对 Sequelize 查询的 TypeError,它可能虚构一个不存在的方法,让开发者引入第二个 bug。

上下文质量决定了输出质量。一条“为什么我的 API 返回 500?”的弱提示只能得到泛泛回答;而包含运行时版本、依赖版本、精确错误信息的强提示才能产出真正有用的建议。这意味着 AI 调试放大的是经验,而非取代经验。

某些 bug 对 AI 几乎不可见:竞态条件、内存泄漏、性能回归、分布式系统故障。这些需要运行时观察和分析工具,AI 无法替代。


想要提速而不失控,应把 AI 输出当作初始假设而非最终答案。提供完整错误信息和上下文,明确告诉 AI 你已尝试过什么,对陌生 API 保持怀疑。这样,速度是真实的,混乱可控。

#开发者 #工具 #AIDebugging #AI辅助 #调试 #Copilot #ChatGPT #Cursor #Sequelize #DevOps
@DevToolboxHub
Post #1466 7
调试工作流:告别盲目试错

每个开发者都经历过那种时刻:昨天还能跑的函数今天突然坏了,测试全红,日志毫无帮助,盯着同一段代码看了四十分钟。问题不在于调试本身难,而在于大多数开发者的调试方法都是即兴发挥。一个结构化的调试工作流能把令人沮丧的无限循环变成可重复的决策序列,帮你更快定位根因。

第一步:停止猜测,开始观察。把问题用自然语言描述出来——预期是什么?实际是什么?差异在哪?这能把大脑从应激模式切换到观察模式。橡皮鸭调试法(向一个无生命对象解释你的代码)常常能瞬间暴露逻辑漏洞。
第二步:可靠复现。不能复现就无法修复。目标是构造最小可复现用例(MRE):剥离所有无关依赖,用桩数据替代真实调用,把输入精简到还能触发错误的最简单形式。例如,对比一个有数据库依赖的测试和一个纯数据测试,后者能证明问题独立于外部系统。
第三步:真正读懂错误消息。不要只扫第一行就跳结论。从堆栈底部往上读——Python traceback 的异常点通常在最后一行。比如 TypeError: Cannot read properties of undefined,实际错误是 user.profile 未定义,而非 user 本身为空,问题根源是数据源缺少字段。
第四步:隔离故障层。用二分法逐层缩小范围:如果一个管道有5步,先测中间那步,确认错误在上游还是下游,再继续二分,直到定位到出问题的单一步骤。
第五步:把日志当作一等工具。在问题出现前就部署结构化日志(如 Python logging 模块),记录输入、输出和关键中间值。生产环境中结构化的 JSON 日志能让修复时间从三小时缩短到十五分钟。
第六步:知道何时该撤。连续调试30-45分钟无进展时,离开屏幕。散步或睡觉后的大脑扩散思考往往能带来“洗澡灵感”。回来后重新审视原始假设,很可能发现最初猜错了方向。


可靠的工作流不是对小 bug 也执行每一步,而是在卡壳时有一个默认的应对序列:可靠复现、先观察再动手、完整读错误、二分隔离、有意图地日志、转不动就休息。其中最核心的一条是构建最小可复现用例——有了它,一切都会变得清晰。

#开发者 #工具 #调试 #工作流 #Python #JavaScript #工程效率
@DevToolboxHub
Post #1465 7
Amazon EKS 新增 Kubernetes 版本回滚功能

Amazon EKS 近日引入 Kubernetes 版本回滚支持。在集群升级后 7 天内,若出现问题,运维人员可将控制平面回退至之前使用的 Kubernetes 版本。该功能为原地升级提供安全网,降低了集群升级的风险,使团队能快速从有问题的更新中恢复。

#开发者 #工具 #AmazonEKS #Kubernetes #版本回滚 #DevOps #AWS
@DevToolboxHub
Post #1464 9
PixelSmash:FFmpeg 十六年高危漏洞曝光

JFrog 安全研究团队披露了名为“PixelSmash”的漏洞,存在于 FFmpeg 媒体框架的 MagicYUV 解码器中,可导致远程代码执行(RCE)与拒绝服务(DoS)攻击。该漏洞已在代码库中潜伏十六年,影响大量使用该解码器的应用。攻击者仅需提供一个恶意构造的媒体文件即可触发。

建议用户立即检查受影响版本,应用补丁或禁用 MagicYUV 解码器以降低风险。

#开发者 #工具 #FFmpeg #PixelSmash #MagicYUV #RCE #DoS #JFrog #安全漏洞
@DevToolboxHub
Post #1463 6
Solana主网部署完整检查表

作者结合自身真实上线经验,整理了一份 Solana 程序从 devnet 到 mainnet-beta 的部署检查表,覆盖部署前、部署中、部署后权限管理、前端对接等四个阶段,并标注了亲自踩过的坑。作者认为,最危险的不是 deploy 命令本身,而是集群确认、升级权限决策、缓冲区 SOL 回收这些“外围步骤”——每项都不复杂,但一旦忙起来容易忘,而任何遗漏都可能造成不可逆损失。

预计起飞前有检查单,外科医生下刀前也有。不是因为他们忘了怎么飞或做手术——而是因为在压力下跳过一个步骤的代价太高,不能仅靠记忆。把 Solana 程序发到主网也属于同一类:不可逆操作、真实资产在线,以及十几件每件在忘记之前看起来都显而易见的小事。作者最近刚完整走了一遍上线流程,趁记忆还新鲜把步骤写成了过手单。
Phase 1: Pre-flight(在 devnet 上做) 确保测试全部通过,且测试针对最终编译的字节码(不是之前版本)。在 devnet 上完整体验一遍主网流程,不跳过任何计划“这次先跳过”的步骤。用 anchor build --verifiable 生成可验证构建——跳过它的话程序就永远是个黑箱。确认部署钱包有足够 SOL 覆盖 rent-exempt minimum(可用 solana rent 预览),注意:有了可验证构建后不要再跑普通 anchor build 或 cargo build-sbf,否则会生成不同哈希。
Phase 2: 部署(不可逆阶段) 切换 CLI 到 mainnet-beta 并用 solana config get 确认。通过专用 RPC 端点部署(不用公共端点,限流会导致写入超时)。网络忙时加 priority fee(--with-compute-unit-price)。了解恢复路径:部署不是原子操作,若中断可用 solana program show --buffers 查看滞留的 buffer 并恢复或关闭它,避免每次失败都泄漏 SOL。
Phase 3: 部署后权限与验证 用 solana program show <PROGRAM_ID> 确认程序已上线并检查升级权限。主动决定谁持有升级权限(单密钥对、Squads 多签或 --final 不可变),不要默认。发布 IDL 让程序接口随程序本身可检索,并通过 IDL 重新生成类型化 client。注意:跳过 IDL 发布会导致构建验证失败。
Phase 4: 前端与上线 将 React 前端指向主网 program ID。确认 Wallet Standard 连接展示的是主网钱包(不是 devnet 残留)。重新验证所有失败模式(拒绝授权、余额不足、blockhash 过期)现在都能给出清晰提示。公布上线,并提前写好用户反馈渠道。

真正让作者惊讶的是:部署命令本身并不吓人——跟 devnet 上跑的一样。真正需要谨慎的是围绕部署的那些环节:确认集群、把升级权限当作决策而非默认、记住停止的部署不是从头再来而是 SOL 在 buffer 里等着回收。最好的工程团队不把上线当作记忆或英雄主义表演,而是当作程序来执行。

#开发者 #工具 #Solana #Web3 #Checklist #Deployment #Anchor #React
@DevToolboxHub
Post #1462 6
打造免费开源图像编辑器替代昂贵方案

开发者 @rageshpikalmunde 在集成图像编辑功能时发现,现有库要么功能不全,要么需支付昂贵的商业许可。于是他决定自己构建一个免费开源且易于集成的图像编辑器——RP Image Editor。

该库轻量、TypeScript 优先、框架无关且高度可定制。当前提供裁剪、旋转、缩放、绘图、标注、形状、移动端友好、HEIC 支持、自动 EXIF 旋转、高分辨率导出等能力。架构支持集成到 Angular、React、Vue、Ionic、Capacitor 等前端项目。

项目正在积极开发中,计划加入模糊工具、更多标注工具、移动端体验优化、性能优化及更多主题选项。社区反馈对项目发展非常重要,开发者欢迎提交 feature request 或 bug report。


npm

#开发者 #工具 #RPImageEditor #开源 #图像编辑库
@DevToolboxHub
Post #1461 5
文件同步工具的四种数据丢失陷阱

一个文件同步工具一旦在网络两端读写用户文件,就会面临比崩溃更严重的隐患——静默地销毁用户无法恢复的成果。以下是开发过程中遇到的四种数据丢失陷阱,以及对应的修复方案。这些 bug 都不算罕见,且都能通过简单的测试,但实际却是错误的。

1. os.WriteFile 先截断后写入。若进程在两步之间被杀死,文件会变成半截内容。修复:先写入临时文件,再 rename 进行原子替换。注意临时文件需与目标同目录,且 rename 会交换 inode,硬链接和扩展属性会丢失。更隐蔽的二次伤害:若写入发生在本地区块记录之前,被杀死的写入会产生一个工具不认识的内容片段,下次运行会误报“本地文件已更改”,然后提供 --force 破坏性标志作为解决方案。

2. 基于 etag 或 mtime 的冲突检测会遗漏双方都修改的情况。本地和远端都改动时,etag 比对只会看到“服务端不同”并直接覆盖本地编辑。冲突判定必须基于字节哈希,而非元数据。元数据只适合作为跳过任务的快速路径,不能作为授权覆盖的依据。

3. --prune/mirror 标志造成的破坏最大,因为删除不可撤销。幼稚的规则是“本地有但远端没有就删除”,这会误删用户从未同步过的文件、本地修改的文件以及仅存本地的文件。正确规则:只删除能证明是你写入且用户没有触碰的文件。证明来自你的本地区块记录。若操作中途中断,必须将自身记录为失败,否则 prune 逻辑会将崩溃解读为一批用户删除。

4. 当服务端返回的文件列表为 null 时,Go 的 json.Unmarshal("null", &slice) 会成功并产生一个 nil 切片。不加保护地处理此输入,工具会认为项目没有文件,下次 push --prune 就会删除所有本地文件。防御措施:不可信输入必须进行形状验证,任何意外情况都需停止操作,而非放行。需要明确拒绝 null 列表、达到分页上限的列表,以及内容长度与服务端声明不符的列表。一次错误的信任可能损失用户文件。


这四种 bug 都能通过 happy-path 测试,只有通过问“如果此刻崩溃或出错,用户会损失什么”才能暴露出来。工具是开源的,上述每个决策都有测试用例锁定。

GitHub

#开发者 #工具 #Go #数据安全 #Git #sync #编程教程
@DevToolboxHub
Post #1460 4
中间链治理:不只在入口验证AI代理输出

现代AI代理通常执行多步工作流——检索文档、调用API、查询数据库、生成中间计划、调用外部工具、产生最终响应。但现有安全机制大多只验证初始提示或最终输出,忽略了中间步骤的风险。例如一个无害请求可能让代理在第三步生成引用敏感表的SQL,这种中途输出问题靠入口检查永远无法发现。

Mid-Chain Governance(中间链治理)在执行过程中按间隔重新检查每一步的输出文本,而非仅依赖入口验证。它不是拦截动作本身,而是在文本传递到下一步或交付用户之前进行检查。通过选择性重新验证——按间隔检查且保证最终交付总被检查——在模拟中实现了接近全步骤检查的捕获率,而延迟成本大约减半。

该项目是一个开源的实验性库 midchain-governance,用于多步AI管道的选择性输出重新验证。它不声称发明了跨步约束检查这一概念,而是一个具体的、经过测试的实现——包括间隔逻辑、无论链长多少都保证检查最终输出的机制,以及探索捕获率/延迟权衡的模拟代码。当前没有生产记录,模拟数据如实标注为模拟。目标是补充而非取代现有护栏。

适用场景:企业AI助手、客服代理、自主软件工程代理、多代理编排平台——任何代理在多个步骤产生有意义输出的系统。作者欢迎反馈和贡献。


GitHub: GitHub

#开发者 #工具 #AI #安全 #LLM #代理 #MidChainGovernance #开源 #多步工作流
@DevToolboxHub
Post #1459 5
phi-leak-guard:检测LLM输出PHI并阻断构建

作者在开发基于LLM的临床文本功能时发现,现有评估库要么完全不检测受保护健康信息(PHI),要么依赖远程API评分——这对患者数据而言本身就是风险。于是他写了 phi-leak-guard,一个零依赖 TypeScript 库,在 Vitest/Jest 中本地运行,不联网、不调用模型,只要发现 PHI/PII 就让测试失败。

库的关键在于用校验和减少误报:NHS号走 Modulus-11 校验,VIN 验证 ISO-3779 校验位,IPv4 做八位段范围验证,SSN/NINO 检查结构+前缀规则。命中结果会标注是 validated(校验通过)还是 pattern(正则/上下文匹配),方便评估可信度。覆盖率方面,它完整覆盖 HIPAA Safe Harbor 列出的 18 类标识符,对于生物识别、照片、“其他任何标识符”等文本无法检测的类别则明确报告为不可检测,而非假装覆盖。作者明确表示这不是合规认证,而是降低风险的回归门。同时预留了可插入 NER 模型的接口。

安装:npm install --save-dev phi-leak-guard。MIT 许可,提供 ESM + CJS + TypeScript 类型。合成基准测试精度 1.00、召回 0.97。


GitHub

#开发者 #工具 #PHI #TypeScript #Vitest #Jest #npm #LLM #HIPAA #隐私检测
@DevToolboxHub
Post #1458 4
mAPI-ng:让 Go API 自我诊断问题

厌倦了盯着 Grafana 面板来回比对?mAPI-ng 是一个为 Go 服务设计的诊断工具,不只看图表,而是关联 RED 指标(速率、错误、时长)与 Go 运行时信号、实例健康及下游 IO,直接给出可能根因和置信度,例如“内存/GC压力(高置信度)”“下游IO瓶颈(中等置信度)”“goroutine泄漏”,并附带“排除此原因”说明,避免黑盒幻觉。

接入极简:两个 import、一个中间件、一个环境变量,无需 YAML 配置或管理 Prometheus;数据存储使用 ClickHouse。整个方案 MIT 许可,可通过 make up 自托管,也提供托管版(含永久免费层),无锁定风险。

GitHub

#开发者 #工具 #Go #API #诊断 #开源 #监控 #ClickHouse #自托管
@DevToolboxHub
Post #1456 5
2026年S3替代方案速览:自托管与兼容云

2026年Amazon S3替代方案分为两大阵营:免出站费的S3兼容云(Wasabi、Backblaze B2)和完全去锁定的自托管引擎(MinIO、RustFS、Ceph、SeaweedFS)。选择取决于你希望由谁托管——云服务商还是自己的机架。

关键对比
• MinIO(AGPLv3):单个静态二进制,纠删码,对象锁定,单租户高IOPS场景标杆,商用嵌入需另购许可。
• RustFS(Apache 2.0):Rust编写,许可宽松,目标高吞吐自托管,但社区规模和第三方工具仍弱于MinIO。
• Wasabi:专有许可,无出站费,热存储约$6.99/TB/月,API兼容但缺乏Athena/Lambda等生态。
• Backblaze B2:专有许可,出站免至存储量3倍,约$0.005/GB/月,适合备份和归档。
• Ceph(LGPLv2.1):统一对象+块+文件,运营复杂度高,适合大规模存储。
• SeaweedFS:轻量级,大文件数和小对象优化,适用于内容农场。

迁移清单(以12TB为例)
部署目标(MinIO/RustFS/B2),用rclone sync --checksum拷贝,切换应用端点并保留S3作为回退一个计费周期,最后用rclone check验证。在1Gbps链路上迁移12TB约需一个周末,瓶颈通常是源端出站上限。

选择四问:谁运行(云/自托管)、出站模型(读多需免出站)、许可证(AGPLv3/Apache 2.0影响分发)、工作负载(单租户/混合/统一)。答案映射:云+免出站→Wasabi/B2;自托管+宽松许可+高吞吐→RustFS;自托管+成熟生态→MinIO;统一存储→Ceph。


选择建议:按上述四问定位,200GB的PoC比电子表格更有效。最流行的S3替代是MinIO(自托管标杆)和RustFS(Apache 2.0高吞吐),云上免出站则推荐Wasabi和Backblaze B2。

#开发者 #工具 #S3 #对象存储 #MinIO #RustFS #Ceph #Wasabi #BackblazeB2
@DevToolboxHub
Post #1455 9
SonicJS 认证问题排查指南

SonicJS 部署到 Cloudflare Workers 后,可能会遇到用户无法登录、权限不足或随意注册等问题。以下是在生产环境中必须处理的认证配置。

关闭公开注册:在 app config 中设置 disableSignUp: true,管理员通过 /admin/users/new 创建用户,确保同时写入 auth_user 和 auth_account。
密码存储不一致:Better Auth 读取 auth_account,部分流程只更新 auth_user.password_hash。使用 npm run set-password:prod 脚本同步两个存储,并通过环境变量 ADMIN_EMAIL 和 ADMIN_PASSWORD 种子初始管理员。
RBAC 权限问题:登录后有权限提示,通常是因为 auth_user.role 字段未映射到 RBAC 角色。使用 npm run promote-user:prod 提升用户权限,默认 editor 带 portal:access,admin 则全权限。
症状排查表:任何人可注册→关闭 signup;凭证未找到→运行 set-password;登录后无权限→运行 promote-user;种子失败→检查 wrangler.toml 和 D1 绑定;部署后认证异常→重新设置 BETTER_AUTH_SECRET 和 JWT_SECRET。
使用 patch-package 修复框架 bug,但应优先升级上游版本。

最后,确保私有 CMS 的强化清单:禁用公开注册、种子 admin、创建用户写入双表、RBAC 含 portal:access、密码重设脚本同步双存储、生产密钥通过 wrangler secret put 设置、公开集合显式指定 access.public。

#开发者 #工具 #SonicJS #Cloudflare #BetterAuth #RBAC #Workers #CICD
@DevToolboxHub
Post #1454 9
Empire LLM for Codex:外部模型只贡献证据,不掌权

面对多个AI模型涌入代码审查场景,混乱与成本同步飙升:模型擅自编辑文件、执行命令、甚至自行审批补丁。Empire LLM for Codex 为 Codex 设计的插件,用一条原则解决这一痛点——外部模型贡献证据,而非权威。

Codex 保持领导地位。插件通过 OpenRouter 路由有限请求,应用能力/隐私/可用性/成本策略,返回带来源和成本的响应。外部模型无法编辑项目、执行代码、批准自己的提案或静默合并结果。Codex 评估后决定是否采纳。

具体实现中,请求被严格界定,响应附带着 provider、model、tokens、cost 和引用证据。开发者只需安装插件、定义最小上下文任务、并在行动前阅读“收据”——使用它如同对待外部顾问的建议:有用但绝不自动生效。同样,模型生成的图表、原型等媒体也按此流程处理:生产、标记、返回,由 Codex 决定是否放入资源文件夹。


这种架构强制了职责分离:更多模型并不自动产出更多智能,反而带来更多成本与模糊性。插件设立了三个关键边界:有限请求范围、每份响应的溯源、以及明确拒绝授予仓库权限。目前尚缺审查质量、假阳性率和成本方差等公开基准,但“Codex 主导、外部模型提供证据”的决策本身不依赖单一数字。

如果你已经在 Codex 中拉入多个模型,这是在不授予它们“钥匙”的前提下,最干净的做法。

#开发者 #工具 #EmpireLLM #Codex #AICodeReview #OpenRouter
@DevToolboxHub
Post #1452 10
组织 CLAUDE.md、Skills 与 Agents 的最佳实践

为 Claude Code 等编码代理配置指令文件时,常见误区是同一套知识被复制到 CLAUDE.md、skills、agent 定义和参考文档四类文件中,导致各份独立漂移。经审计发现,这种“自信的错误”成本极高——样式文档推荐了与构建配置不匹配的 CSS-Modules 模式,测试模板在 beforeAll 中设置 mock 却被 test setup 文件在每个测试后重置,渲染组件缺少必要 Provider。每个错误文档都会让代理多花数千 token 的调试循环。

正确做法是按“何时加载、谁需要”决定内容归属:
- 每次会话都加载的规则放 CLAUDE.md / AGENTS.md,保持简短(3 行内 + 链接到 skill)
- 只有特定任务需要的深度知识放 skill(如样式机制、数据获取模式、测试配方),描述加载后才触发
- 角色或流程而非知识放 agent(定义工作流完成标准,调用哪些 skill),保持薄层
- 绝不可跳过的检查用 hook(格式化、lint)——代码规则比文字要求可靠

核心原则:每个事实只存在于一个文件,其他文件均引用它。模式超过几行就放入 skill,CLAUDE.md 仅放链接。

验证文档像验证代码一样:先用 grep 检查文档示例是否真实存在于代码库(如“prefetchQuery”零使用,“recommendedHelper”仅 1/50 测试文件使用);再用子代理仅凭文档回答实现问题,对比实际代码评分。若代理按文档生成的代码会失败,则文档未通过,修复后再合并。

这一重组成果显著:典型功能任务上下文缩小约 11%,约定变更现在只需改 1 个文件而非 3 个,且文档不再生成损坏的样式和失败测试——每次代理踩坑省去数千 token 调试。

#开发者 #工具 #Claude #ClaudeCode #Agent #工程效率 #文档管理 #CodingAgent
@DevToolboxHub
Post #1451 8
用 Claude Code CLI 当 Prism provider

一位 Laravel 开发者把已有 Claude Code 订阅利用起来,将 Claude Code CLI 封装成 Prism provider,从而在不额外支付 API 费用的情况下继续使用 Prism 的 LLM 调用接口。整套实现只有约 200 行代码,通过 stdin/stdout 与 CLI 交互,并保留了按环境变量切换 provider 的能力。

核心思路:Prism 的 provider 是扩展自 Prism\Prism\Providers\Provider 的类。这里只需实现 text() 和 structured() 两个方法,不支持 embedding、图片和流式。

CLI 调用输出包含 is_error、result、usage、model,可直接映射到 Prism 的 TextResponse / StructuredResponse。

安全要点:命令参数用数组传给 Laravel Process(避免 shell 注入);用户 prompt 走 stdin 而非 argv;工作目录设为 sys_get_temp_dir() 避免项目指令泄漏;额外检查 envelope 中的 is_error 字段。

结构化输出模拟:CLI 不支持原生 JSON schema,因此在 prompt 末尾拼接 schema 要求,并在解析时先尝试直接 json_decode,再剥离 markdown 代码块,最后截取首尾大括号。

注册方式:在 ServiceProvider 的 boot 中通过 PrismManager::extend() 注册闭包,确保 Octane 下每次解析都重新读取配置。

切换 provider 只需修改环境变量,例如 PRISM_TEXT_PROVIDER=claude-cli PRISM_TEXT_MODEL=claude-haiku-4-5。resolveModel 方法会捕获旧模型名并回退到默认值。

注意:CLI 调用慢(大 prompt 30-90 秒),需注意超时链设置;容器内需安装 Node.js;高并发下进程创建开销大,不适合生产规模流量。对于 solo 开发或小产品,可大幅节省 API 成本。


#开发者 #工具 #Prism #ClaudeCode #CLI #Laravel #LLM
@DevToolboxHub
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →