Insight Compiler：改问题而非给答案

向 AI 助手提开放型问题，得到的回答往往合理但泛泛——缩小目标、差异化、做 MVP、聊用户。这些都对，但不会真正推动你向前。Insight Compiler 是一个 Agent Skill，把泛泛答案当作起点而非终点：它先明确写出普通回答，再用后续步骤爬出那个答案的局限。

技能每次运行七步：意图发现（分离表面问题与真实目标）→ 普通答案基线（写出正常 AI 会怎么答）→ 领域视角（借助军事、城市设计、游戏等陌生领域审视问题）→ 发现算子（反转、换位、缩放，找无人注意的缺口）→ 提示库（交叉领域与算子产出密集线索）→ 策略候选（2-3 个方向，每个回溯到具体线索）→ 诚实评估 + 验证分支（不制造平局，预先承诺每个测试结果对应什么行动）。第 2 步是关键——未写出的普通答案是模型悄悄躺进去的天花板，写下来就是可以蹬离的地板。

实际演示：作者问“发布的技能仓库无人访问怎么办”，普通助手回答“改善 README、加 GIF、发到 X 和 Reddit”。Insight Compiler 第一步就拒绝了原问题，提炼为“目标用户在哪第一次接触足够价值以触发思维变化”，并指出“低访问=解释不够”这个前提混淆了发现/分发瓶颈与理解瓶颈。它给出的方案之一是先确定为谁做、产出一个完整示例打动一个人、把输出本身当作内容分发，而不是优化仓库页面。三个候选诚实评级后，最终建议是“先做无聊的 README 改进，因为它几乎零成本，但这是必要条件而非充分条件”。完整对话及两种答案对照都在仓库里。

安装方式：Agent Skill 本质是一个含 SKILL.md 的目录。对 Claude Code：
```
git clone GitHub
mkdir -p ~/.claude/skills
cp -r insight-compiler/InsightCompiler ~/.claude/skills/
```
重启后确认加载。还有一个 InsightCompilerPersonal 版本，在本地配置文件中只记录工作习惯，不构建信息茧房，安装二选一。不适合需要快速事实回答、代码或短决策的场景；其市场缺口判断是推理假设，需自行验证。

仓库：https://github.com/snc2work/insight-compiler (MIT)

#开发者 #工具 #InsightCompiler #Claude #AgentSkill #AI #开源
@DevToolboxHub

Standard Ten：用统一标准重构AI代码生成

AI生成代码的速度很快，但缺乏统一标准会导致架构不一致。Adi Cohen 提出 Standard Ten，主张将全部软件重写为一套统一标准，让人类和AI每次都生成相同的最佳实践结构。

Standard Ten 的核心原则：每个操作接收并返回一个规范“Thing”；程序按嵌套结构组装；所有输出从一个规范种子派生；无手写应用代码；无 OOP；无应用控制流（用事件、路由、map/fold代替）；所有目标使用统一事件机 UEM-16；外部效应通过命名边界；失败必须记录工单；相同输入产生相同输出；测试从同一源生成并完全验证。

开发者只需写一种受约束的 Python 语言，系统生成 UEM 字节码、WebAssembly、原生码等。UEM-16 是芯片无关的虚拟机器，指令集包括 LOAD、ROUTE、MAP、FOLD 等。GUI 和浏览器也通过同一接口协议适配。

已演示成果：基于 Python 的内核、完整小应用生成器、两个独立领域（文本统计和发票汇总）的零手动修正实现、UEM-16 字节码在 Python 和 C99 宿主上跨平台等价执行、全面的测试套件（法则、效果、变异、性能等）。

该项目不宣称支持所有芯片，ARM64、RISC-V 等需在物理硬件上运行无误后才声明。AI 应当像确定性数学系统一样生成软件：从一小套规范词汇出发，在明确法则下产生可复现结果和完整验证。

GitHub

#开发者 #工具 #StandardTen #UEM16 #AI代码生成 #确定性
@DevToolboxHub

基于TOFU的无头AI Agent认证方案

构建AI Agent时，一开始只需一个Personal Access Token（PAT），但随着接入Slack、Notion、Linear等服务，长期凭证散落在.env、CI/CD、K8s Secret和基础设施中，安全隐患和运维负担随之攀升。Passkey提出一种借鉴SSH「Trust On First Use（TOFU）」的授权模型，让Agent无需任何长期凭证即可安全访问外部服务。

传统OAuth依赖人类在浏览器中点击「允许」，但无头Agent没有交互界面。开发者通常退而求其次：PAT扩展快但留下技术债；自定义OAuth需为每项服务处理回调、加密、刷新，认证层比产品本身还庞大；Secret Manager仅解决存储，不解决授权；Service Account让所有Agent共享同一身份，单点泄露影响全局。

Passkey的目标是：Agent永不接触长期凭证；人类仅需批准一次新Agent；每次操作可归因到特定Agent；撤销一个Agent不影响其他部署；现有框架无需改动。方案来自SSH的TOFU模型：首次连接时检验主机指纹，用户确认后记住指纹，之后自动连接。类比到Agent，首次请求时网关暂停请求，Owner收到审批通知，通过后存储指纹，后续请求自动放行。

具体流程：开发者一次性OAuth连接服务，凭证留在网关内。Agent启动时获得一个Passkey URL，请求网关获取GitHub等工具时，网关检查指纹。未知指纹触发人工审批，通过后交换一个短令牌（非刷新令牌、PAT或client secret），Agent直接调用上游API。指纹由运行时特征派生，每个Agent拥有唯一身份，请求可归因、可审计，撤销指纹即可封锁该Agent，无需轮换凭证或重新部署。

集成方式：通过MCP协议，任何兼容MCP的框架（LangChain、CrewAI、Strands、Bedrock AgentCore）无需改动，Agent自动看到工具列表如github_list_issues等。网关使用令牌交换而非代理所有请求，降低延迟、避免瓶颈、兼容现有MCP工具。

其他设计：
• 连接URL使用轮换slug
• 支持动态客户注册（减少限流竞争）
• 原生MCP

该模型尤其适合接入多个SaaS平台、需要审计和归因、安全团队禁止PAT散落的场景。安装本地代理只需执行 npx passkey-mcp，目前内置19个集成（GitHub、Slack、Jira、Confluence、Notion、Stripe、Salesforce、HubSpot、Linear等）。核心问题已验证：无需长期凭证，且不降低开发体验。

#开发者 #工具 #AI #Agent #TOFU #MCP #Passkey #CICD
@DevToolboxHub

威胁建模：健康仪表盘的同意边界测试

健康连接器即使标记为“只读”也可能跨越权限边界。真正的危险并非攻击者利用，而是用户以为访问结束后仍在进行的合法后台刷新。安全不变量应比“令牌有效”更强：每次读取必须获得当前、基于特定目的的同意。OpenAI 2026年7月23日宣布在美国向18岁以上用户推出Health in ChatGPT，支持医疗记录和Apple Health，数据不用于训练模型或定向广告。

资产模型包含四类：连接凭证、导入记录、派生仪表盘视图和审计证据。同意服务需与导入工作器和对话检索分离。关键设计决策：提供商令牌单独不能证明当前同意，工作器必须提交授予标识、请求目的、数据类别和操作时间。策略决策应记录到安全日志而不复制临床内容。

威胁工作表列出典型滥用场景：撤销后刷新竞态、睡眠数据被用于无关目的、支持工具暴露记录、已删除连接静默重连、导出包含隐藏源字段。每个场景对应预防、检测和恢复措施。

回归测试规范包含三个负面用例和一个正面用例：撤销后过期任务、目的扩展、重连；正面用例是授权有效期内刷新和撤销完成后新建授予。验收标准检查控制平面、数据平面和证据平面：控制平面必须拒绝过期或越权权限，数据平面拒绝后不得持久化新获取数据，证据平面记录触发的规则且不含健康内容。

该模型不验证具体实现或监管状态，仅使授权声明可证伪。关键提问：同意变更后，哪些排队、缓存、导出和派生对象仍可移动，以及每个对象已停止的证据是什么？

#开发者 #工具 #安全 #威胁模型 #健康仪表盘 #同意边界 #OpenAI #ChatGPT #AppleHealth
@DevToolboxHub

本地健康导出字段校验 CLI

这个小工具的目标很简单：在本地检查 JSON 健康导出文件，如果包含接收者未请求的字段，就拒绝通过（fail closed）。它不解析医疗数据，不上传任何内容，是一个介于「导出完成」和「文件共享」之间的窄范围预检。触发背景是 OpenAI 于 2026 年 7 月 23 日宣布的 Health in ChatGPT 产品推送，面向美国 18 岁以上已登录用户（网页与 iOS），支持连接病历和 Apple Health，可查看化验、药物、活动、睡眠等信息。OpenAI 称连接数据与相关对话不会用于基础模型训练或广告定向。

该验证器使用白名单（allowlist）而非黑名单（denylist）来规避意外泄露——黑名单只检查已知敏感键，而白名单要求每披露字段都经过审批，能捕获源设备、原始记录 ID、时区等隐藏元数据。下面是一个示例实现（Python 3 脚本，作为 validate_export.py 保存）：

```python
#!/usr/bin/env python3
import argparse, json, sys
from pathlib import Path

ALLOWED = {"subject", "type", "day", "value"}
FORBIDDEN = {"name", "email", "address", "phone", "notes"}

def check(path: Path):
errors = []
for number, raw in enumerate(path.read_text().splitlines(), 1):
try:
row = json.loads(raw)
except json.JSONDecodeError as exc:
errors.append(f"line {number}: invalid JSON ({exc.msg})")
continue
keys = set(row) if isinstance(row, dict) else set()
extra = keys - ALLOWED
found = keys & FORBIDDEN
if not isinstance(row, dict):
errors.append(f"line {number}: object required")
if extra:
errors.append(f"line {number}: unexpected={sorted(extra)}")
if found:
errors.append(f"line {number}: forbidden={sorted(found)}")
return errors

p = argparse.ArgumentParser()
p.add_argument("file", type=Path)
args = p.parse_args()
problems = check(args.file)
print("REJECT" if problems else "ACCEPT")
for problem in problems:
print(problem, file=sys.stderr)
raise SystemExit(bool(problems))
```

使用方法：python3 validate_export.py export.ndjson。如果文件中出现 "notes":"call after lunch" 这样的字段，会同时报出 unexpected 和 forbidden 两种错误并退出。

分享前建议增加三个低成本检查：随机浏览十行并统计总行数；通过带外方式确认目的地和删除日期；从允许字段生成新文件，而非原地修改原文件。该工具仅校验顶级键名，无法检测允许字符串内隐藏的标识值、链接攻击、畸形日期、重复行或重识别风险。OpenAI 描述的健康体验为「支持」，不替代医疗诊断或治疗；本地 schema 校验的作用更小：只能减少意外泄露，不能判断数据的准确性、必要性或临床意义。

#开发者 #工具 #CLI #Python #隐私 #OpenAI #ChatGPT #Health #数据校验
@DevToolboxHub

用Python实现健康记录数据最小化过滤器

OpenAI 在 2026 年 7 月 23 日宣布 ChatGPT Health 功能，覆盖符合条件的美国用户（18 岁以上，登录后使用网页或 iOS），可连接病历和 Apple Health，仪表盘展示化验、用药、活动、睡眠等信息。OpenAI 称已连接数据和相关对话不用于训练基础模型或定向广告。

这篇教程用一个迷你 Python 程序演示“数据最小化”——如何让程序证明一个目的只接收原记录中的部分字段。例如，输入包含 date、steps、sleep_minutes、medication、note，但 activity_summary 目的只应得到 date 和 steps。

代码使用 Python 3.11+ 和标准库，定义 POLICY 字典映射目的到允许字段。minimize 函数对未知目的抛出 ValueError（fail-closed），而非返回全部字段。测试用例验证精确输出、输入不被修改、未知目的失败闭合。建议先测试异常输入（如拼写错误的目的名），确保断言能检测多余字段。

本练习只处理扁平字典，不处理值清洗、嵌套临床格式、匿名化、文件安全或集成任何已发布服务。示例数值纯属虚构，无医学意义。切勿未经完整的隐私与安全审查就用于生产健康数据控制。

#开发者 #工具 #Python #数据最小化 #隐私 #OpenAIHealth #ChatGPTHealth #单元测试
@DevToolboxHub

DeepDoc：离线解析文档为Markdown的单二进制工具

在构建RAG管道或搜索功能时，从docx、pdf等文件中提取文本总是一道绕不开的槛。现有方案要么依赖JVM（Apache Tika），要么需要Python环境及模型下载（unstructured、Docling），要么得上传云端（LlamaParse）。DeepDoc提供另一种选择：一个静态Rust二进制，无JVM、无Python、无模型下载、不连网，单文件即可运行。

> DeepDoc将每种格式解析为统一的文档模型（标题、段落、列表、表格、元数据、页码），再序列化为Markdown或JSON。v0.1支持13种原生数字格式：docx、pptx、xlsx、odt、ods、odp、epub、html、rtf、csv、md、txt及纯文本PDF。递归处理文件夹，输出保持目录结构。
>
> 对于RAG场景，DeepDoc按块边界切分，同时保留标题层级路径和字节范围作为元数据，确保检索时上下文不丢失。非OCR工具，扫描PDF会被检测并报错退出（返回码4），避免污染索引。也可作为Rust库使用，直接嵌入服务。
>
> 示例：deepdoc report.docx 直接输出带表格的Markdown；deepdoc ./docs --recursive -o out/ 批量处理并镜像目录。

DeepDoc是本地优先、轻依赖的工具链（DeepLab系列）之一，开源（MIT / Apache 2.0），v0.1已发布。

GitHub

#开发者 #工具 #DeepDoc #Rust #RAG #文档解析 #离线 #开源
@DevToolboxHub

APRF: AI生产就绪的硬门控框架

大多数团队把LLM功能当落地页来发布——合并PR、看演示、庆祝，然后现实打脸：提示注入泄露客户CRM、编码Agent提交密钥、支持机器人虚构退款导致诉讼、遗忘的API密钥一夜烧掉$82k。这些失败并非模型不够聪明，而是生产系统缺少生产门控。APRF是一个门控的、机器可读的生产就绪框架，提供代码、YAML门控和CI，本周就能接上。

APRF不是认证、不是合作伙伴网络、不是给董事会的0–100“就绪分数”。它是必过式方法论：强制检查要么通过，要么阻止发布。推荐控制从不平均进入门控。核心原则：门控结果 = ALL(强制检查通过) — 一项失败即阻断；能力 = 各支柱最小值 — 不允许平均分掩盖弱点。当前版本v0.10包含8个域（安全、安全、数据、模型生命周期、Agent、可靠性、成本、治理）、27个支柱、核心配置41个门控（Tier‑2）、受控配置61个门控（Tier‑3/合规系统），以及RAG、Agent、语音、编码Agent等附加透镜。机读规范与自证声明JSON均可获取。附完整实现示例：TypeScript工具白名单+模式验证、Python不可绕过的审批、YAML策略包（与app版本绑定）、GitHub Actions门控CI（检查证据文件存在性）、以及自证声明JSON模板。一个门控失败即阻止发布，没有“87%就绪”。

适合正在交付Agent、RAG、语音、编码助手的工程师，平台/MLOps团队厌倦了“我们很小心”的模糊说法，安全人员需要能映射到测试和配置的AI控制。APRF不会给你“对所有都合规”的徽章——这正是它的价值所在。贡献与讨论通过公开RFC进行。

#开发者 #工具 #APRF #StackRail #LLM #AI安全 #生产就绪
@DevToolboxHub

三款Chrome扩展提升开发工作流

一位开发者注意到日常工作中的三个小痛点——在随机网站上粘贴JSON格式化、复制JWT到jwt.io调试、切换到字符计数网站检查字数——于是花几个周末构建了三个Chrome扩展来解决它们。

PayloadPeek
JSON格式化工具，支持折叠语法高亮树、一键生成TypeScript接口、从JSON结构推断SQL schema（CREATE TABLE）、Ctrl+F搜索、点击复制任意值。最实用的功能是TypeScript Generator，处理陌生API时无需手写接口。

BearerPeek
JWT解码器，附带安全分析面板：标记缺失exp声明（永不过期）、缺失aud声明（任何服务可接受）、算法设为"none"、过期的token及精确过期时长。自动扫描当前页面中JWT格式的字符串，在DevTools查看请求时可预填token。

TextPeek
字符和字数计数器，支持平台感知的限制：Twitter 280、LinkedIn 3000、Meta描述160、YouTube标题100等。选中任意网页文本右键即可看到即时计数，无需打开任何窗口。

构建经验
Manifest V3对权限非常严格：因请求未使用的tabs、scripting权限被拒两次，因从CDN加载highlight.js被拒一次。MV3下所有JS必须本地打包，不能加载外部脚本。首次提交通常被拒，但拒绝邮件具体可操作，仔细阅读并修复即可。构建三个小东西比一个大东西好：每个扩展专注一件事，Chrome商店列表更清晰、权限理由更简单、用户信任更高。本地处理是真正的差异点——“数据不离开浏览器”是开发者关心的，尤其对JWT token和API响应。所有扩展均使用Claude Code作为pair programmer，在周末全职工作之余开发。

作者将这些扩展放在ShipNano品牌下，计划持续推出小型专注工具。

#开发者 #工具 #PayloadPeek #BearerPeek #TextPeek #Chrome扩展 #ShipNano #JSON #JWT #字符计数
@DevToolboxHub

Vault：浏览器端的投资组合风险追踪器

大多数散户用电子表格或免费App管理投资，只能看到总价值和每日变动，看不到年化波动率、夏普比率、市场贝塔、最大回撤、持仓相关性等核心风险指标。机构投资者用了几十年的东西，散户只能看饼图。

Vault 是一个开源的投资组合追踪器，基于 React 19 和 Vite 构建，通过 EODHD API 获取实时市场数据，在浏览器本地计算六项指标：收益（对比标普500）、分散度（HHI指数）、风险（年化波动率、夏普比率、95% VaR）、回撤（最大回撤曲线）、相关性（皮尔逊矩阵）和行业敞口（GICS细分）。不设后端，不存账户，持仓数据仅保存在 localStorage，不上传任何第三方服务器。

所有数学计算集中在单个文件 src/utils/finance.js，不依赖外部统计库，从零实现时间加权收益、波动率、夏普比率、贝塔、回撤、相关性矩阵和集中度指数。这些公式并不神秘，大多数付费工具只是把它们锁在付费墙后。

六项指标核心算法
时间加权收益：每日以前一日收盘价加权，避免月中新增持仓扭曲日收益。
波动率与夏普比率：日收益率标准差×√252，再对可配置无风险利率计算夏普比率。
贝塔：投资组合与标普500（GSPC.INDX）的协方差除以基准方差。
回撤：增长指数曲线（基数100）从滚动峰值的百分比跌幅。
相关性矩阵：按日期对齐的资产间皮尔逊相关系数。
集中度（HHI）：赫尔芬达-赫希曼指数应用于仓位权重。

添加持仓时，EODHD 的 Search + EOD 端点自动补全代码和买入日收盘价，随后渲染收益曲线、相关性热图和行业敞口，无需手动构建公式或重复输入价格。

代码地址：GitHub

#开发者 #工具 #Vault #EODHD #投资组合 #风险指标 #React #开源
@DevToolboxHub

说谎的数字：重建真正的Claude Code用量仪表盘

一位开发者在使用 Claude Code 月订阅时，因夜间自动化脚本消耗了两周额度，账户被锁定 4 天，不得不以原价购买额外 Token。这促使他构建一个用量仪表盘，过程历经四次失败迭代，每个版本都揭示一个关键教训。

第一次：自行估算每周 $4,690 限额，显示已用 13%——这个数字完全虚构，却看起来像真实测量。
第二次：从 claude.ai 抓取真实百分比 12%，但没有时间参考点——12% 在第一天意味着太快，最后一天意味着浪费。
第三次：改为计算剩余可用时间和重置时间，发现 Anthropic 的每周限额是固定时钟（每周一 13:00 重置），未用余额不结转，慢速使用等于浪费。
第四次：用贝叶斯统计处理早期波动大的问题，边界测试发现两个 bug——统计容忍度不应翻转判断结论；周期前 24 小时数据不足时不发出预警。此外，数据缺失时仪表盘应诚实显示“数据不可用”，而非用虚假数字保持沉默。

最终仪表盘在第二天就能用一句话告诉你：“按当前速度，额度不够撑到周五。”作者强调：没有来源的可信数字比明显缺口更危险，输入缺失时保持沉默的数字比错误数字更糟。

#开发者 #工具 #ClaudeCode #Anthropic #用量监控 #自动化
@DevToolboxHub

Apache Airflow与.NET 10集成指南

通过HTTP集成Apache Airflow 3与.NET 10，无需用C#重写DAG。服务端保持Airflow负责调度与执行，.NET仅通过REST API/v2触发DAG Run、认证JWT并轮询状态。指南覆盖端到端流程：生成可追踪的dag_run_id、正确序列化config、复用令牌、处理401后自动续期、设置超时与取消传播。

预备环境需.NET 10 SDK、Docker Compose 2.14+、至少4GB内存。仓库提供Airflow 3.3.0、PostgreSQL 16及示例DAG。使用LocalExecutor以简化测试。
认证：POST /auth/token获取JWT，之后通过Authorization: Bearer发送。客户端读取exp避免频繁刷新，并用SemaphoreSlim防止并发续期。
触发：POST /api/v2/dags/{dag_id}/dagRuns，必需字段dag_run_id、conf、logical_date（可null）。响应返回DAG Run对象，state初始为queued。
监控：GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}，轮询间隔5-10秒，直到state为success、failed或canceled。使用CancellationTokenSource设置总超时（如10分钟）。
关键实践：dag_run_id应包含业务键以确保幂等性；conf只传小引用（ID、URI），不传密文或大负载；失败时区分401（续期）、403（权限不足）等，仅GET允许指数退避重试。

完整代码示例（含Docker compose、客户端实现、Minimal API）见仓库BlogSamples/Orchestration/Airflow。

#开发者 #工具 #ApacheAirflow #dotnet10 #CSharp #DAG #JWT #DevOps #API
@DevToolboxHub

约80行脚本为营销文档做CI校验

作者的个人项目 lans.cloud 提供 100 多个免费浏览器工具。发文章、目录列表、推销邮件里提到的工具数量却不断出错——37、50、51、又变成50。代码有测试，文档会漂移，营销文案漂移最严重，因为没人执行校验。于是作者用大约80行脚本把营销文档放进CI：从代码注册表中提取真实工具数量，在git push前检查所有仍可编辑的文档里提到的数字是否一致，不一致则阻止提交。

关键设计：只检查当前活文档（后续会复制的），已发送邮件、归档旧文保留原数字。第一次运行就揪出一条过时的“41”，第二天又批量发现16处错误。作者感叹，营销文案是在别人头脑中执行的代码，应该像测试代码一样测试它。

#开发者 #工具 #CI #自动化 #营销文档 #事实检查 #lanscloud #sideproject
@DevToolboxHub

用 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

组织 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

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

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

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

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

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

中间链治理：不只在入口验证AI代理输出

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

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

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

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

GitHub: GitHub

#开发者 #工具 #AI #安全 #LLM #代理 #MidChainGovernance #开源 #多步工作流
@DevToolboxHub