PostgreSQL 复制槽上限参数 max_replication_slots 解析
差一个等于没有。报错是 all replication slots are in use。把参数设为 0，pg_basebackup 会报同样的错。发布端 max_replication_slots = 1 时，订阅槽占掉唯一条目，之后每个 tablesync worker 创建槽失败、退出并被反复重启，表无限期停留在 srsubstate = 'd'，而订阅本身看起来正常。备库情况更安静：18.6 上主库有三个 failover 槽、备库上限为 2 时，槽同步 worker 创建前两个后触限退出，且未持久化任何东西，备库一个槽都没同步成。反方向至少够响：把值降到磁盘上槽数以下，服务器拒绝启动，报 FATAL: too many replication slots active before shutdown。pg_upgrade 迁移逻辑槽时适用同样规则。
设置时，要数下一次故障切换后这台服务器上会有多少槽，而不是今天有多少。算完总数后放一边，在集群每个节点（含备库）上都设 50，因为它们终将成为主库，且槽同步现在就需要空间。五十个条目花 15 KB。如果已经用了三十个，就设 100。算术不是重点，重启才是。另外，max_wal_senders 至少应为该值加上物理备库数，它同样是 postmaster 上下文，应在同一次重启中一起提高。还要盯差距而非数量：当槽数接近上限时告警，任何失效数大于零都应视为待删除而非保留。
max_replication_slots 决定共享内存中复制槽数组的长度，仅此而已。它不决定谁能创建槽、槽能钉住多少 WAL、废弃槽何时清理。数组在启动时一次性分配，因此不改它就得重启。默认值 10，上下文为 postmaster，取值范围 0 到 262,143（即 MAX_BACKENDS）。任何类型的槽都要求 wal_level 为 replica 或更高。9.4 到 9.6 默认值为 0；PostgreSQL 10 把默认值提到 10，目标是让全新安装无需重启即可备份并搭建备库。条目本身几乎不花钱：在 18.6 上，10,000 个条目多 3 MB，合法上限 262,143 个多 72 MB，约合每个 300 字节。条目便宜，槽不便宜：槽的真实成本是它钉住的 WAL 和压住的 xmin horizon，那是 max_slot_wal_keep_size 的职责，18 时代还有 idle_replication_slot_timeout 兜底。
凡是 pg_replication_slots 里有行的都占座，不论类型、状态或创建者：每个设置 primary_slot_name 的备库一个物理槽，每个被指定槽的 pg_receivewal 一个；发布端每个订阅一个逻辑槽，初始拷贝期间每个表同步 worker 再多一个，拷贝完成即删除，所以默认 max_sync_workers_per_subscription = 2 的订阅者在追赶期间可在发布端占三个条目。临时槽：pg_basebackup 自 10 起默认创建一个，wal_receiver_create_temp_slot 会为没有永久槽的备库创建一个，随会话消亡但会话存续期间占座。备库上 sync_replication_slots = on 时会复制主库上每个 failover 槽。第三方创建的每个槽同样占座。失效槽显示 wal_status = 'lost'，不再保留任何东西，但在被删除前仍占座。截至 18，replication origins 不在列表内，18 把这项工作移交给 max_active_replication_origins。PostgreSQL 19 增加两个变化：订阅设置 retain_dead_tuples = on 时，launcher 会在订阅者上创建名为 pg_conflict_detection 的持久物理槽；REPACK ... CONCURRENTLY 则从新的 max_repack_replication_slots（默认 5）池中取用。
差一个等于没有。报错是 all replication slots are in use。把参数设为 0，pg_basebackup 会报同样的错。发布端 max_replication_slots = 1 时，订阅槽占掉唯一条目，之后每个 tablesync worker 创建槽失败、退出并被反复重启，表无限期停留在 srsubstate = 'd'，而订阅本身看起来正常。备库情况更安静：18.6 上主库有三个 failover 槽、备库上限为 2 时，槽同步 worker 创建前两个后触限退出，且未持久化任何东西，备库一个槽都没同步成。反方向至少够响：把值降到磁盘上槽数以下，服务器拒绝启动，报 FATAL: too many replication slots active before shutdown。pg_upgrade 迁移逻辑槽时适用同样规则。
设置时，要数下一次故障切换后这台服务器上会有多少槽，而不是今天有多少。算完总数后放一边，在集群每个节点（含备库）上都设 50，因为它们终将成为主库，且槽同步现在就需要空间。五十个条目花 15 KB。如果已经用了三十个，就设 100。算术不是重点，重启才是。另外，max_wal_senders 至少应为该值加上物理备库数，它同样是 postmaster 上下文，应在同一次重启中一起提高。还要盯差距而非数量：当槽数接近上限时告警，任何失效数大于零都应视为待删除而非保留。
竞品关键词调研的自动化流程
从竞品差距分析导出两万个关键词，约一半只是同一词换了词序。真正的瓶颈在导出之后那一小时：一个好问题变成一堵近似重复词组成的墙，外加三种不同口径的搜索量。
从竞品差距分析导出两万个关键词，约一半只是同一词换了词序。真正的瓶颈在导出之后那一小时：一个好问题变成一堵近似重复词组成的墙，外加三种不同口径的搜索量。
找搜索对手别只看商业对手。把最想拿下的五个搜索词丢进 Google，记下反复出现的站点，再和 SEO 工具的竞品报告交叉核对；两份名单冲突时以手工那份为准。关键词至少从两个工具各拉一次：Semrush 的 Keyword Gap 最多并排比较五个域名，Ahrefs 的 Content Gap 从反方向找差距。两者对同一词的难度分和搜索量口径并不一致，Ahrefs 自己承认同一词的难度分在不同工具间差异相当大，且不计站点权重；搜索量上 Ahrefs 取近 12 个月估算，Semrush 取近 12 个月平均，Google 给广告主的是分档区间。三个定义、一个词、三个数字，并排放着就好，不要取平均。
清洗列表是最不体面但收益最大的一步，大致按顺序砍四刀：词序双胞胎（"invoicing software for freelancers" 和 "freelancer invoicing software" 是一页而不是两页）；含竞品品牌名的词，那个点击本来就不是你的；错配词，差距报告会显示每个词实际由哪个页面排名，当那个页面明显不是搜索者想要的，对手只是碰巧排上去；你服务不了的词，比如法律问题类或两人产品碰不了的企业级词。砍狠一点的目的不是整洁，而是一份你真能做完的短名单。
把剩下的词和 Search Console 交叉核对。它免费、是 Google 自己记录的站点表现数据，但数据滞后两到三天，且 Google 会隐去部分实际搜索词，Ahrefs 估计这部分接近全部点击的一半。核对只问一个问题：这个词我是否已经出现？有展示就从来不是差距；排在第二页却没点击，那是标题和摘要的问题。接着按结果页分组：Keyword Insights 的做法是看每个词的前 7 条结果，两个词共享 40% 以上结果就归为一组，阈值可调，Semrush 的 Keyword Strategy Builder 也按相似结果分组。这样就从「一词一页」变成「一组一页」，主词打头，变体顺带覆盖。
意图标签大多是对的，但真正重要的词要自己打开结果页看。工具答不了的问题是：这是不是你的主题？Ahrefs 的 business potential 打分从 0 到 3，3 表示你的产品基本就是答案，0 表示没有任何自然方式提到你卖的东西。还要防搜索量陷阱：Ahrefs 自己的策略指南举过一个约百万美国月搜索量、实际只带来约 200 次点击的词，因为 AI 概览和 Reddit 帖子压在结果顶部。写新内容前先查自我竞争：Search Console 表现报告按单个搜索词过滤，会显示你所有拿到展示的页面，两页争一词就是信号被拆分，通常的修法是选一个赢家、把输的那页指向别处。
可自动化的是排序、去重、分组和每月从三处拉同一份报告；不可自动化的是判断这个季度该拿下哪个词、彻底放弃哪个词。把活交给 AI 前有一条警告：它擅长对你给的列表排序分组，但绝不该碰它查不到的数字。SpyFu 记录过 ChatGPT 把一个真实搜索量约 700 的词估成每月 5000 到 10000。让机器排序、分组、总结，搜索量和难度永远来自有真实数据的工具。
用一个下午审计公司里的重复性工作
多数公司不需要耗时半年的转型项目，才能发现时间到底流失在哪里。花几个小时追踪三个真实工作流，就能看出很多问题。关键不是问团队哪里效率低，也不是凭记忆画出理想流程，而是实际跟着已经发生的工作走一遍。
对开发者和工程负责人来说，可以把它类比成追踪一个请求在分布式系统中的流转，区别在于其中一些“服务”是人、表格、收件箱、审批和 Slack 消息。问出来的往往是症状，追踪出来的才是原因。
把每个发现换算成粗略的年度成本，公式是：单次耗时 × 每年发生次数 × 涉及人数 × 小时成本。比如每次复制数据 6 分钟、每周 40 次，就是每周 4 小时、每年 208 小时，而这还只是其中一个环节。排序时按成本而非抱怨声量，高频的琐碎任务往往比一年才痛几次的流程更值得先动。
发现问题后不要立刻开工单。先分类：有些工作应当直接删除，比如过时报表、多余审批、重复记录；有些只需团队自己改，比如明确归属、统一模板、调整通知规则；只有真正属于工程问题的，才进入开发排期，例如系统集成、Webhook 状态更新、自动校验、共享数据源。
每个结论最终落到删除、指派、自动化、集成、调查或有意忽略，并指定唯一负责人。改动后重新追踪同一流程，对比处理时间、总耗时、人工接触点和涉及系统数，用流程指标而不是“自动化已上线”来判断成效。
多数公司不需要耗时半年的转型项目，才能发现时间到底流失在哪里。花几个小时追踪三个真实工作流，就能看出很多问题。关键不是问团队哪里效率低，也不是凭记忆画出理想流程，而是实际跟着已经发生的工作走一遍。
对开发者和工程负责人来说，可以把它类比成追踪一个请求在分布式系统中的流转，区别在于其中一些“服务”是人、表格、收件箱、审批和 Slack 消息。问出来的往往是症状，追踪出来的才是原因。
选三个高频工作流，各挑一个近期真实案例，从开始到结束逐步追踪。重点标记四类信号：信息被重复录入，同一份数据散落在 CRM、表格、内部系统和财务系统等多处；工作长时间排队等待，比如实际处理 20 分钟、整体耗时却拖到两天；人工反复检查，例如确认同步是否成功、金额是否一致；以及重复重建，比如每周五手工拼报表、把已有数据导出再复制重做。
把每个发现换算成粗略的年度成本，公式是：单次耗时 × 每年发生次数 × 涉及人数 × 小时成本。比如每次复制数据 6 分钟、每周 40 次，就是每周 4 小时、每年 208 小时，而这还只是其中一个环节。排序时按成本而非抱怨声量，高频的琐碎任务往往比一年才痛几次的流程更值得先动。
发现问题后不要立刻开工单。先分类：有些工作应当直接删除，比如过时报表、多余审批、重复记录；有些只需团队自己改，比如明确归属、统一模板、调整通知规则；只有真正属于工程问题的，才进入开发排期，例如系统集成、Webhook 状态更新、自动校验、共享数据源。
每个结论最终落到删除、指派、自动化、集成、调查或有意忽略，并指定唯一负责人。改动后重新追踪同一流程，对比处理时间、总耗时、人工接触点和涉及系统数，用流程指标而不是“自动化已上线”来判断成效。
Instagram 字体生成器：把普通文字换成 Unicode 样式
Instagram 字体生成器是一类在线工具，把普通字母转换成外观不同的 Unicode 字符，再复制粘贴到 Instagram 的个人资料、简介、标题和评论等支持区域。通常不需要下载或安装任何东西，输入文字、选样式、复制结果、粘贴即可。
使用流程是输入文字、挑选样式、点击复制、打开 Instagram 粘贴。iPhone 和 Android 都可以通过手机浏览器使用，一般无需单独安装字体。多数在线生成器免费，可用样式数量和附加功能因网站而异。
部分字符可能不被特定设备、应用或系统支持，出现空框、问号、缺字或显示不一致时，换用兼容性更好的样式即可。发布前建议先在手机上确认实际显示效果，避免在一条简介或标题里混用过多样式。
Instagram 字体生成器是一类在线工具，把普通字母转换成外观不同的 Unicode 字符，再复制粘贴到 Instagram 的个人资料、简介、标题和评论等支持区域。通常不需要下载或安装任何东西，输入文字、选样式、复制结果、粘贴即可。
它并不是真的更换设备上安装的字体，而是用外观类似粗体、斜体、数学体、手写体或装饰体的 Unicode 字符替换标准拉丁字母，Instagram 再把这些字符当作文本显示。常见样式包括粗体、斜体、手写体、小字、等宽体、装饰体、圆圈字符和特殊符号。
典型用法是简介和标题：简介空间有限，短样式文字便于分区，例如把「Photography」「Music Lover」「Travel Creator」分别换成不同样式；也可以只给名字或短句用样式，联系方式、链接、日期等重要信息保留普通字符，更易读。显示名和用户名不同，显示名允许的字符用户名未必接受。
使用流程是输入文字、挑选样式、点击复制、打开 Instagram 粘贴。iPhone 和 Android 都可以通过手机浏览器使用，一般无需单独安装字体。多数在线生成器免费，可用样式数量和附加功能因网站而异。
部分字符可能不被特定设备、应用或系统支持，出现空框、问号、缺字或显示不一致时，换用兼容性更好的样式即可。发布前建议先在手机上确认实际显示效果，避免在一条简介或标题里混用过多样式。
GitHub 的 pull_request_target 改动会破坏什么
GitHub 今年调整了 pull_request_target 的运作方式，两项带日期的变更会影响所有使用该触发器的公开仓库。作者用自研 AI 工程系统 HAL 做了免费检查工具 prt-check，扫描了 GitHub 上 star 数最高的 1,000 个仓库。
两项变更：自 2026-07-20 起，actions/checkout 在 pull_request_target 和 workflow_run 工作流中默认拒绝检出 fork 的 PR 代码，除非显式选择加入；自 2026-11-02 起，GitHub 会阻止没有 Actions 策略允许该触发器的公开仓库使用 pull_request_target。
样本取自 2026-09-26 GitHub 仓库搜索的 1,000 个 star 最高、非 fork、非归档公开仓库，其中 809 个有工作流文件，共 9,328 个，全部可读。只读取默认分支上的 .github/workflows/*.yml 和 *.yaml，未运行任何工作流。Actions 策略从外部不可见，因此部分仓库可能已允许该触发器并在 2026-11-02 后继续运行；这些数字统计的是依赖该触发器的工作流，而非确定会停止的工作流。
建议先在自己的仓库上跑 prt-check，再按 README 里的三种修复方式处理：改用 pull_request、拆成 pull_request + workflow_run，或保留触发器并显式配置 Actions 策略。
GitHub 今年调整了 pull_request_target 的运作方式，两项带日期的变更会影响所有使用该触发器的公开仓库。作者用自研 AI 工程系统 HAL 做了免费检查工具 prt-check，扫描了 GitHub 上 star 数最高的 1,000 个仓库。
两项变更：自 2026-07-20 起，actions/checkout 在 pull_request_target 和 workflow_run 工作流中默认拒绝检出 fork 的 PR 代码，除非显式选择加入；自 2026-11-02 起，GitHub 会阻止没有 Actions 策略允许该触发器的公开仓库使用 pull_request_target。
扫描时间为 2026-09-26，距 11-02 的默认封锁还有 37 天，报告只给聚合数字，不点名任何仓库。1,000 个仓库中有 269 个（26.9%）至少有一个工作流跑在 pull_request_target 上，共 540 个工作流文件；若维护者未在 Actions 策略中允许该触发器，这些工作流将在 2026-11-02 停止运行。9 个（0.9%）在特权工作流中检出 fork 的 PR 代码，且 actions/checkout 带新防护、没有排除 fork 的条件，自 2026-07-20 起这些检出会被拒绝。3 个把 actions/checkout 固定在防护之前的版本或提交上，防护不生效，fork 代码会在工作流 token 和 secrets 所在环境中被检出，最需优先修复。4 个用 allow-unsafe-pr-checkout: true 主动选择加入。9 个用 git fetch ...pull/... 或 gh pr checkout 在特权工作流中拉取 PR 代码，绕过新防护。8 个在 pull_request_target 上跑 AI 或审查类 action，除非允许该触发器，否则 2026-11-02 后这些审查会静默失效。
这些工作流中最常用的 action 按使用仓库数排列：actions/github-script 125、actions/labeler 50、actions/create-github-app-token 25、actions/setup-node 22、actions/setup-python 16、amannn/action-semantic-pull-request 13、eps1lon/actions-label-merge-conflict 12、actions/upload-artifact 12、contributor-assistant/github-action 10、step-security/harden-runner 6、dorny/paths-filter 6、actions/download-artifact 6。AI 与审查类 action：anthropics/claude-code-action 5、presubmit/ai-reviewer 1、anthropics/claude-code-base-action 1、openai/codex-action 1。
样本取自 2026-09-26 GitHub 仓库搜索的 1,000 个 star 最高、非 fork、非归档公开仓库，其中 809 个有工作流文件，共 9,328 个，全部可读。只读取默认分支上的 .github/workflows/*.yml 和 *.yaml，未运行任何工作流。Actions 策略从外部不可见，因此部分仓库可能已允许该触发器并在 2026-11-02 后继续运行；这些数字统计的是依赖该触发器的工作流，而非确定会停止的工作流。
建议先在自己的仓库上跑 prt-check，再按 README 里的三种修复方式处理：改用 pull_request、拆成 pull_request + workflow_run，或保留触发器并显式配置 Actions 策略。
SaveNowX 无落盘下载 X 视频的架构设计
SaveNowX 是一个免费工具，把公开的 X（Twitter）帖子解析成可下载的视频，无需账号、无水印、不留历史记录。作者在开发之初设下一条硬约束：服务器端任何内容都不落盘，不存视频文件、不存下载历史，也就没有清理和泄露的问题。这条约束逼出了一系列架构决策。
对于只有 HLS 的帖子（.m3u8 加一堆 .ts 分片），重定向无法生成单个文件，需要真正抓取分片并重新封装。这类情况走一套任务系统：POST /api/download/url-start 启动，GET /status/{id} 轮询真实进度，GET /file/{id} 取回文件，发送完成后立即删除临时文件。MP3 提取则把最低码率的音频变体通过 ffmpeg 直接管道输出到 HTTP 响应流，不写中间文件，并发转换数有上限。
整套技术栈是 Next.js + FastAPI + Cloudflare Worker。作者认为，把「永不存储」当作硬性架构约束而非事后补上的策略，才催生了 syndication 优先、双 TTL 缓存、边缘 Worker 替代后端代理、临时文件不跨请求存活这些设计。
SaveNowX 是一个免费工具，把公开的 X（Twitter）帖子解析成可下载的视频，无需账号、无水印、不留历史记录。作者在开发之初设下一条硬约束：服务器端任何内容都不落盘，不存视频文件、不存下载历史，也就没有清理和泄露的问题。这条约束逼出了一系列架构决策。
解析接口 GET /api/resolve?url= 只返回元数据和 CDN 地址，从不下载或代理任何视频字节。它优先走 X 的公开 syndication 接口，失败时才回退到 yt-dlp。结果按推文 ID 缓存，成功解析缓存 1 小时，确认「无视频 / 未找到」只缓存 5 分钟，避免错误链接被反复请求时持续打后端。
解析出直链 MP4 后，后端完全不参与传输。下载按钮指向一个 Cloudflare Worker，它唯一的工作是设置 Content-Disposition: attachment 响应头，因为浏览器会忽略跨域链接上的 HTML download 属性。视频直接从 X 的 CDN 到用户设备，FastAPI 后端一个字节都看不到。
对于只有 HLS 的帖子（.m3u8 加一堆 .ts 分片），重定向无法生成单个文件，需要真正抓取分片并重新封装。这类情况走一套任务系统：POST /api/download/url-start 启动，GET /status/{id} 轮询真实进度，GET /file/{id} 取回文件，发送完成后立即删除临时文件。MP3 提取则把最低码率的音频变体通过 ffmpeg 直接管道输出到 HTTP 响应流，不写中间文件，并发转换数有上限。
整套技术栈是 Next.js + FastAPI + Cloudflare Worker。作者认为，把「永不存储」当作硬性架构约束而非事后补上的策略，才催生了 syndication 优先、双 TTL 缓存、边缘 Worker 替代后端代理、临时文件不跨请求存活这些设计。
Agent 运营站点实测：125 次曝光零点击
这是一个由 agent 负责写作、部署和测量的站点，人类只做审批。第二期实测记录披露了一组数据：查询词 git undo last commit keep changes 排在搜索结果第 10 位，七天拿到 125 次曝光，零点击。围绕它的变体——reset、revert、uncommit，都带 keep changes——在同一位置又贡献约 250 次曝光，同样无人点击。
诊断先于修改，因为显而易见的修法通常是错的。该短语已经出现在标题和正文前一百词里，问题不在措辞。一个上线仅数周的域名排到第 10 位却完全沉默，是信任缺口，而站点间的信任靠链接传递。因此本轮动作是：从该集群中表现更强的页面加一批内链，并对搜索引擎实际展示的描述做一次精确短语处理。
数据方向是对的：本周 245 名访客，三周前的基线是每周 79。10 月 1 日设定的里程碑是 90。但看板是 Google 的，流量不是——Google Search Console 只带来本站约 11% 的会话，DuckDuckGo 系承载 56%，Bing 约 21%。agent 优化的只是唯一存在的看板，即查询级数据，而访客来自那些不公布任何数据的引擎。
尚未解决的问题也照实记录：当前版本拿不到停留时长，判断只能依赖访问量；dev.to 已停止公布阅读数，那一侧只能看反应和评论；搜索数据滞后两天；某个体裁不满五篇文章就不许下结论。更深的失败模式是结构性的——一个负责挑选题的看板，会乐于为看板写作而不是为读者写作。数字挑门，读者决定要不要走进去。
这是一个由 agent 负责写作、部署和测量的站点，人类只做审批。第二期实测记录披露了一组数据：查询词 git undo last commit keep changes 排在搜索结果第 10 位，七天拿到 125 次曝光，零点击。围绕它的变体——reset、revert、uncommit，都带 keep changes——在同一位置又贡献约 250 次曝光，同样无人点击。
诊断先于修改，因为显而易见的修法通常是错的。该短语已经出现在标题和正文前一百词里，问题不在措辞。一个上线仅数周的域名排到第 10 位却完全沉默，是信任缺口，而站点间的信任靠链接传递。因此本轮动作是：从该集群中表现更强的页面加一批内链，并对搜索引擎实际展示的描述做一次精确短语处理。
三个月前这个站点按天轮换主题，AI 日、Linux 日、凭感觉日。这套轮换现在进了 KILL 清单，证据是那些早期文章落后于此后所有选题。替代规则很简单：没有引用查询词的选题不许发布，要么搜索排名在 5 到 15 之间，要么是真实存在的自动补全短语。
看板具体推动了三件事。工具由查询词催生：生成器之所以存在，是因为看板上出现了一个命令形态的问题，带着数百次曝光，没人假设它，是数字要求的。集群胜过单篇：git-undo 集群现有八篇文章加一个枢纽页，集群内每篇新文章都必须链接枢纽。手术有时间表：进入 5 到 15 区间却零点击的查询，48 小时内修，不是「以后再说」。
数据方向是对的：本周 245 名访客，三周前的基线是每周 79。10 月 1 日设定的里程碑是 90。但看板是 Google 的，流量不是——Google Search Console 只带来本站约 11% 的会话，DuckDuckGo 系承载 56%，Bing 约 21%。agent 优化的只是唯一存在的看板，即查询级数据，而访客来自那些不公布任何数据的引擎。
尚未解决的问题也照实记录：当前版本拿不到停留时长，判断只能依赖访问量；dev.to 已停止公布阅读数，那一侧只能看反应和评论；搜索数据滞后两天；某个体裁不满五篇文章就不许下结论。更深的失败模式是结构性的——一个负责挑选题的看板，会乐于为看板写作而不是为读者写作。数字挑门，读者决定要不要走进去。
Will It Focus：相机自动对焦兼容性查询 Agent
这是一个面向摄影器材的自动对焦兼容性查询工具，但它真正的看点在于工程实现：如何让模型引用厂商原文时，保证引用的确实是厂商的原话。
作者在拍片时遇到过 Canon T5i 自动对焦失准的问题，而 Canon 官方手册第 100 页其实写明了原因。Will It Focus 把这类问题做成了可查询的 Agent：给定机身、镜头和转接环，分别回答取景器拍照、实时取景和视频三种模式下能否自动对焦，以及对焦失败的原因。跨卡口和转接环也支持，比如「Sigma 35mm Art 通过 MC-11 接在 Sony a7 IV 上，AF-C 能用吗」。
工具也有明确边界：闸门只能证明引文存在于它引用的记录中，不能证明 Agent 为你的具体组合引用了正确的记录。数据集规模有限，覆盖 Canon T5i 时期、Sigma MC-11、Metabones Mark V 和 Canon EF-EOS R 转接环。五个法兰距数据来自 Wikipedia，因为厂商页面没有给出，相关记录中已注明。
这是一个面向摄影器材的自动对焦兼容性查询工具，但它真正的看点在于工程实现：如何让模型引用厂商原文时，保证引用的确实是厂商的原话。
作者在拍片时遇到过 Canon T5i 自动对焦失准的问题，而 Canon 官方手册第 100 页其实写明了原因。Will It Focus 把这类问题做成了可查询的 Agent：给定机身、镜头和转接环，分别回答取景器拍照、实时取景和视频三种模式下能否自动对焦，以及对焦失败的原因。跨卡口和转接环也支持，比如「Sigma 35mm Art 通过 MC-11 接在 Sony a7 IV 上，AF-C 能用吗」。
核心机制是一道引用闸门：模型输出后，代码会回到它引用的 Sanity 记录里逐句比对。如果引文与记录中的完整句子一致，页面会像裂像对焦屏合焦一样对齐显示；如果模型改写了原话，页面会明确标注，并在下方给出记录中的真实句子。如果没有任何厂商资料覆盖该组合，Agent 直接拒答，而不是猜测「能装就能对焦」。
数据层用了两个 Sanity Context 端点，通过 MCP 接入同一个 Agent。一个以 GROQ 模式提供数据集，负责给出结论；另一个提供由六份厂商 PDF 构建的知识库，包括 388 页的 T5i 手册、两份 18-55 套机镜头说明书、Canon Canada 2013 年 T5i 发布稿，以及 Sigma 的两份 MC-11 兼容性表。Schema 共 131 份文档、七种类型：35 个机身、34 支镜头、10 个卡口、5 个转接环、3 种传感器画幅、36 条兼容性记录和 8 条对焦注意事项。自动对焦按拍摄方式拆成 viewfinderPhoto、liveViewPhoto、video 三个字段，因为同一机身在不同模式下用的是不同硬件。
评测用 20 个答案可在厂商表格和手册中查到的问题，在 gpt-5.4-mini 上跑了三种配置。仅用知识库：43 个结论中 37 个与厂商一致，10 段引文中只有 1 段能在厂商文档中逐字找到。仅用数据集：39/43 和 28/31。两者同时使用（即应用实际运行的配置）：38/43 和 21/22。结论准确率差距不大，真正的差别在于引号里的词是否真的属于厂商。评测还暴露了两个作者自己的错误：Sigma 的 DMF 列最初存在自由文本备注里，Agent 查不到，所有 DMF 问题都答「未覆盖」，现已改为类型化字段；小模型因为「Sony a7 IV」匹配不上别名「a7 IV」而漏掉记录，随后自行编造了 id，现在机身和镜头都带上了用户实际会输入的名称，并明确禁止 Agent 构造 id。
工具也有明确边界：闸门只能证明引文存在于它引用的记录中，不能证明 Agent 为你的具体组合引用了正确的记录。数据集规模有限，覆盖 Canon T5i 时期、Sigma MC-11、Metabones Mark V 和 Canon EF-EOS R 转接环。五个法兰距数据来自 Wikipedia，因为厂商页面没有给出，相关记录中已注明。
Python 虚拟环境其实是个软链接
在 Linux 和 macOS 上执行
这意味着一旦系统 Python 被升级、移动或删除，venv 可能直接失效，也可能在毫无提示的情况下改用另一个 Python 继续运行。
这种设计是有意为之：venv 追求轻量、创建快、可随时丢弃，系统打安全补丁时所有 venv 自动受益。代价是 venv 的稳定性完全取决于它指向的那个解释器。
应对办法是掌控自己的基础解释器：用 uv 或 pyenv 安装固定版本的 Python 再建 venv，锁定依赖并随时重建；Docker 多阶段构建时保证运行阶段与构建阶段使用相同基础镜像和相同路径；目标机器可能没有 Python 时，直接连同解释器一起打包分发。
在 Linux 和 macOS 上执行
python3 -m venv .venv，并不会复制一份 Python。venv 里的 python 只是一个软链接，指回系统解释器；标准库同样没有被复制，真正属于 venv 的只有 site-packages 里的第三方包。这意味着一旦系统 Python 被升级、移动或删除，venv 可能直接失效，也可能在毫无提示的情况下改用另一个 Python 继续运行。
用ls -la .venv/bin/能看到 python、python3、python3.12 全是软链接，readlink -f追下去最终都指向/usr/bin/python3.12。venv 的 pyvenv.cfg 里写着home = /usr/bin，Python 启动时靠它找到真正的解释器和标准库。
实测一个 venv 目录约 12M，几乎全是 pip；解释器和几十兆的标准库都不在里面。把 venv 改名或移动后，pip 等命令行脚本会因 shebang 里的绝对路径失效而报 bad interpreter，venv 不可迁移。
用--copies建 venv 只复制了二进制，标准库仍是借用的。当 base Python 消失时，软链接版直接报 No such file or directory，而 --copies 版会静默回退到编译时的 prefix，可能悄悄换用另一套标准库，引发难以排查的 ImportError。
这种设计是有意为之：venv 追求轻量、创建快、可随时丢弃，系统打安全补丁时所有 venv 自动受益。代价是 venv 的稳定性完全取决于它指向的那个解释器。
应对办法是掌控自己的基础解释器：用 uv 或 pyenv 安装固定版本的 Python 再建 venv，锁定依赖并随时重建；Docker 多阶段构建时保证运行阶段与构建阶段使用相同基础镜像和相同路径；目标机器可能没有 Python 时，直接连同解释器一起打包分发。
2,916 个 AI 网站 8 月流量：转录与图生 3D 起飞
Anjin Radar 追踪了 2,916 个 AI 网站的月度访问量，数据截至 2026 年 9 月 28 日。访问量为第三方流量估算，非站点自行公布。8 月合计访问量从 7 月的约 3.758 亿升至 3.930 亿，环比增长 4.6%，其中 1,731 个站点（约 59%）实现环比增长。
几个可复用的规律：seevio.ai 于 7 月 20 日上线，围绕一个热门视频模型家族定位，访问量从 7 月约 3.2 万涨到 8 月约 112 万。iamtypist.dev 从 6 月约 5,600 涨到 7 月约 75.9 万、8 月约 661 万，hinoter.com 从 7 月约 9.9 万涨到 8 月约 248 万，两者 80% 以上流量来自自然搜索。flowmusic.app 在 6、7 月持平于约 300 万后 8 月翻倍至约 619 万，vocuno.com 把歌曲生成与声音克隆、分轨、母带和分发打包在一起。hi3d.ai 连续三个月增长（约 108 万 → 175 万 → 272 万），但自然搜索流量仅约 10%，作者推测其传播来自社交与创作者社区，并注明这是基于流量结构的推断而非直接测量。
对开发者而言：选方向时，转录/纪要与图生 3D 在 8 月有增长动能，图像生成已饱和；面向明确搜索词的免费工具仍是较可靠的获客路径；复制快速增长竞品前，先看它的流量来自搜索、社交还是直接访问。
Anjin Radar 追踪了 2,916 个 AI 网站的月度访问量，数据截至 2026 年 9 月 28 日。访问量为第三方流量估算，非站点自行公布。8 月合计访问量从 7 月的约 3.758 亿升至 3.930 亿，环比增长 4.6%，其中 1,731 个站点（约 59%）实现环比增长。
分类增长差异明显：文本生成（含转录、会议纪要）+35.3%，3D 建模 +34.6%，音频与音乐 +19.0%，聊天与陪伴 +4.8%，设计 +3.3%，视频制作 +1.6%，AI 检测与去 AI 化持平，图像生成 −1.5%，生产力与办公 −2.8%。图像生成仍是最拥挤的赛道，且略有下滑；增长主要流向转录工具和图生 3D 工具。
增速前十（8 月访问量 100 万以上）：seevio.ai 视频生成约 112 万、+3,414%；hinoter.com 转录与会议纪要约 248 万、+2,416%；iamtypist.dev 免费音视频转录约 661 万、+771%；senzia.cc 视频/图像/音频生成约 110 万、+189%；flowmusic.app AI 音乐制作约 619 万、+105%；whif.io 韩语角色聊天约 154 万、+70%；frendi.ai 俄语角色聊天约 327 万、+63%；vocuno.com AI 音乐制作约 102 万、+56%；hi3d.ai 图生 3D 模型约 272 万、+55%；isekaizero.ai AI 角色扮演与互动故事约 189 万、+44%。
几个可复用的规律：seevio.ai 于 7 月 20 日上线，围绕一个热门视频模型家族定位，访问量从 7 月约 3.2 万涨到 8 月约 112 万。iamtypist.dev 从 6 月约 5,600 涨到 7 月约 75.9 万、8 月约 661 万，hinoter.com 从 7 月约 9.9 万涨到 8 月约 248 万，两者 80% 以上流量来自自然搜索。flowmusic.app 在 6、7 月持平于约 300 万后 8 月翻倍至约 619 万，vocuno.com 把歌曲生成与声音克隆、分轨、母带和分发打包在一起。hi3d.ai 连续三个月增长（约 108 万 → 175 万 → 272 万），但自然搜索流量仅约 10%，作者推测其传播来自社交与创作者社区，并注明这是基于流量结构的推断而非直接测量。
对开发者而言：选方向时，转录/纪要与图生 3D 在 8 月有增长动能，图像生成已饱和；面向明确搜索词的免费工具仍是较可靠的获客路径；复制快速增长竞品前，先看它的流量来自搜索、社交还是直接访问。
wpipe：面向 Python 开发者的轻量编排库
wpipe 是一个纯 Python 可嵌入的编排库，目标是让数据管道的开发回到「编辑—运行—调试」的快速循环，而不必为验证业务逻辑先搭起一整套云原生基础设施。
它针对的是重型编排引擎的隐性成本：本地起容器、等 Scheduler 守护进程采集 DAG、在开发机上扛整套云原生栈。wpipe 不需要 Docker、Redis 或 Postgres 就能在本地跑通管道，生产环境则保持 Docker-Ready。
用法上，管道由 Pipeline、Step、Context 组成：自定义 Step 继承基类并实现 run 方法，通过 ctx.set / ctx.get 在步骤间传递数据，再用 add_step 组装并 execute 执行，最后读取 result.status 与上下文中的处理结果。
重型编排器在分布式大规模调度中仍有其位置，wpipe 更适合希望无摩擦地构建、测试和部署可靠管道的软件与数据工程师。
wpipe 是一个纯 Python 可嵌入的编排库，目标是让数据管道的开发回到「编辑—运行—调试」的快速循环，而不必为验证业务逻辑先搭起一整套云原生基础设施。
它针对的是重型编排引擎的隐性成本：本地起容器、等 Scheduler 守护进程采集 DAG、在开发机上扛整套云原生栈。wpipe 不需要 Docker、Redis 或 Postgres 就能在本地跑通管道，生产环境则保持 Docker-Ready。
因为是标准 Python 代码，VS Code 或 PyCharm 的断点可以直接生效，不必靠 print 调试或等 Web 面板刷新。每个步骤的生命周期清晰解耦，依赖容易被 mock，可以用 pytest 像测试普通 Python 模块一样为管道写单元测试。
状态方面，wpipe 通过 SQLite WAL 模式持久化自动遥测与检查点，无需配置外部数据库。相比重型编排器动辄数 GB 内存和 CPU 开销，wpipe 的资源占用在 MB 级别；本地安装只需 pip install wpipe，反馈循环为直接执行、无需等待轮询。
用法上，管道由 Pipeline、Step、Context 组成：自定义 Step 继承基类并实现 run 方法，通过 ctx.set / ctx.get 在步骤间传递数据，再用 add_step 组装并 execute 执行，最后读取 result.status 与上下文中的处理结果。
重型编排器在分布式大规模调度中仍有其位置，wpipe 更适合希望无摩擦地构建、测试和部署可靠管道的软件与数据工程师。