Hi, 请登录     我要注册     找回密码

开源照片自动备份工具 P-Pass 更新：新增 Windows 和 iPhone 支持

分类：未分类 阅读() 评论(0)

P-Pass 是一款开源照片备份工具，可将手机相册自动备份到家中已有的电脑上，全程无需注册账号。用户在电脑和手机各安装一个 App，扫码配对一次后，新拍摄的照片和视频即可在后台自动传回家中电脑。最新版本已覆盖四大平台：桌面端支持 Apple 芯片 Mac 和 64 位 Windows，移动端支持 Android 8.0 以上和 iPhone。家中多部手机可连接同一台电脑并共用一个照片库，一人拍摄的内容，其他家庭成员在手机上也能查看。对于不愿开放整个相册的用户，可先通过系统选择器只挑选选中的几张照片传给 App，自动备份可随时开启或关闭，关闭时仅传输手动选中的照片。桌面端还支持将照片库连同文件夹内其他文件迁移到另一块硬盘，且不影响扫码配对。远程场景下优先直连，连不上则走公共中继，全程端到端加密，照片和视频均保存原图，在电脑上以普通文件夹形式存放。项目采用 Rust + iroh（QUIC）开发，桌面端基于 Tauri，安卓端使用 Kotlin，iOS 端使用 Swift。源码托管在 GitHub，官网 FAQ 提供安装说明及 Windows 安全提示等常见问题的解决办法。

事件分析

该项目的技术看点在于用 Rust 与基于 QUIC 的 iroh 实现点对点传输，配合公共中继回退机制，与 Tailscale 打洞加中继的架构思路相近，解决了家庭宽带无公网 IP 下的远程可用性问题。桌面端选用 Tauri 而非 Electron，资源占用更低，契合家庭电脑常年驻留的场景。此次补齐 Windows 与 iOS 两端后，这类去中心化备份方案对个人云盘订阅与厂商云相册服务构成一定替代压力，尤其面向在意照片隐私、不愿将原图交由第三方托管的用户。后续走向需观察 iOS 后台上传的实际稳定性、公共中继的带宽成本与长期维护意愿，以及开源社区能否形成持续的贡献生态。

核心观点：云相册订阅费持续上涨之际，本地直连加端到端加密的开源方案，正帮用户拿回照片数据的主导权。

原文链接：V2EX 分享发现

C code80.ai · AI 编码 API 聚合 Claude / GPT 多模型统一接入,稳定不限速,按量计费,几行配置接入 Claude Code。 了解一下 ›

相关推荐

抢沙发

评论前必须登录！

立即登录   注册

易安
易安作者
长期关注 AI Agent、软件工程、自动化工作流与个人生产力系统。喜欢把复杂技术拆成普通人也能上手的实践教程,也记录自己在工具链、编程、内容创作和知识管理上的真实折腾。
  • 分享 AI 工具、Agent 工作流与提示词工程的实战经验
  • 记录从想法到产品、从代码到上线的完整实践过程
  • 关注普通人如何用 AI 放大能力,而不是被工具牵着走
阅读作者的全部文章 ›
文章目录

    置顶推荐

    Code80 · AI 编程巴士

    前沿哨所

    • 合并 MR 前预知 CI 风险：Mac 工具 Pipeline Lens 本地模拟 GitLab pipeline

      开发者在 V2EX 发布了一款名为 Pipeline Lens 的 macOS 小工具，可在本地模拟 GitLab CI pipeline，帮助开发者在合并 Merge Request 之前预判 CI 配置是否会产生问题。随着项目规模扩大，.gitlab-ci.yml 往往被拆分为大量 include，叠加 rules、needs、extends、!reference 等机制，修改 CI 配置时难以预估影响。而 MR 自身的 pipeline 只能验证当前分支，合并后 main、release 分支或 tag 上的 pipeline 会发生什么变化，此前无法提前得知。典型场景如：为 build-api 任务添加 changes 条件以节省 CI 时间，MR 流水线全部通过，但合并后 release 分支上的 deploy-production 因依赖该任务，导致 GitLab 拒绝创建 pipeline，问题直到发版当天才暴露。Pipeline Lens 的处理方式是：将本地、跨项目及通配符形式的 include 全部拉取并合并，然后模拟任意分支、tag 或 MR 的 pipeline，展示哪些 job 会运行、每个 job 由哪条规则触发、未运行 job 的具体原因（含变量取值），以及 GitLab 会因何种错误拒绝创建 pipeline。用户可用 MR 分支的配置去模拟 release 分支，在合并前发现潜在风险。该工具免费，支持 macOS 14 及以上版本，已上架 App Store，官方项目 gitlab-org/gitlab 这类大规模配置也可正常模拟。

      事件分析

      该工具的技术门槛在于对 GitLab CI 配置体系的完整复刻：include 展开、rules 表达式求值、needs 依赖解析、变量插值等环节均需与服务端行为精确对齐，否则模拟结果失真，这也是同类尝试少有成功的原因。作者主动征集模拟结果与实际不一致的案例，说明配置模拟类工具的可靠性需要真实场景持续校准。从行业视角看，随着 monorepo 与多分支发布策略普及，CI 配置复杂度持续攀升，『配置即代码』的可验证性正成为 DevOps 工具链的新切入点；GitLab 官方目前未提供本地 pipeline 干跑能力，社区工具恰好填补了这一空缺。后续若能与 GitLab CLI 集成、扩展至 GitHub Actions 等其他 CI 平台，使用场景将进一步打开。

      核心观点：CI 配置复杂度已超出人工推理边界，合并前本地验证正从最佳实践演变为 DevOps 基础设施刚需。

      原文链接：V2EX 分享发现

    • Claude Pro真实额度实测：5小时窗口20美元、周额度约200美元

      近日，Linux.do论坛用户发布帖子，分享了对Claude Pro订阅实际使用额度的测量数据，引发社区对Anthropic额度分配机制的讨论。该用户表示，其通过反向代理方式接入Claude服务，日常主要调用Opus和Sonnet两款模型。根据长期观察，每个5小时滚动窗口内的额度消耗从未超过20美元，即便在高强度使用Opus模型时也是如此；按周计算的总消耗约为200美元。发帖者据此推测，这一水平与Team计划等更高档位订阅相当，并质疑是否因接入环境不佳、账号权重较低而遭遇额度缩水。Anthropic对订阅用户采取双重限制机制：一是5小时滚动窗口的会话额度，二是每周使用上限，额度以美元折算，不同模型消耗速率不同，Opus单价最高，同等额度下可用量远少于Sonnet。由于官方从未公布具体数值，用户只能通过实际使用和第三方工具估算。社区此前普遍反馈，Pro订阅的5小时额度约在十几至数十美元区间浮动，且不同账号之间存在明显差异。此次帖子的数据为社区提供了参考样本，帖子下已有其他用户分享各自额度体验，但尚无官方回应确认额度差异是否与账号权重或接入方式相关。需要注意的是，通过反向代理调用Claude的行为可能涉及服务条款合规问题，相关使用方式存在账号风险。

      事件分析

      从技术角度看，Claude的额度机制本质上是Anthropic应对算力资源紧张的动态调控手段。额度以美元折算而非消息条数，使不同价位的模型在统一框架下计量，但也带来不透明性，用户无法预知剩余额度，只能依赖社区逆向估算。所谓账号权重虽无官方证实，但风控系统根据接入方式、IP环境、使用模式调整配额在业界并不罕见，反向代理这类非常规路径存在被降权的可能性。对产业而言，此次讨论折射出AI订阅服务的普遍矛盾：厂商为控制成本设置隐性上限，用户则为不可预期的额度体验付出信任代价。随着AI编程工具对推理算力需求持续攀升，周限额预计将成为主流订阅服务标配。后续Anthropic可能面临提升额度透明度的压力，第三方额度监测工具或在社区进一步流行。

      核心观点：Claude额度黑箱暴露AI订阅制核心矛盾：算力稀缺下的隐形配额与区别对待，正在透支用户对定价体系的信任。

      原文链接：Linux.do

    • 开源 Berth 扩展：在 VS Code 侧栏统一管理 tmux 中的 AI Agent 会话

      一位开发者在 V2EX 发布了开源项目 Berth，这是一款 VS Code 扩展，用于解决 AI 编程 Agent 会话分散难管理的问题。作者日常在 Claude Code 与 Codex 之间频繁切换，项目约定统一写在 AGENTS.md 中供各 Agent 读取，但会话散落在不同项目和终端标签里，难以掌握哪个还在运行、哪个已结束。Berth 在 VS Code 侧栏按项目列出 tmux 中的 Agent 会话，显示各会话的运行状态与工作内容，支持按名称、对话标题或目录搜索，点击即可在编辑器区域打开对应终端，并与源码、diff 并排显示。除 Claude Code 和 Codex 外，该扩展还能识别 Gemini CLI、OpenCode、Copilot CLI、Cursor CLI、Kimi CLI 等多种 Agent。设计上，Berth 不另建 tmux 体系，只发现已有会话，Agent 仍用用户原有命令启动；会话运行在 tmux 中，关闭或重载 VS Code 窗口均不受影响，macOS 上 iTerm2 也可连接同一批会话；工作状态来自各 Agent 的 hooks，首次启动时会提示安装。安装方式为 code –install-extension berthdev.berth，支持 macOS 和 Linux，Windows 需通过 WSL，要求 tmux 3.0 以上版本。项目采用 MIT 协议，代码托管于 GitHub，目前处于早期版本，重启电脑后已确认对话 ID 的会话可以恢复。

      事件分析

      Berth 的出现折射出 AI 编程工作流的新变化：多 Agent 并行、频繁切换已成为部分开发者的常态，会话编排正在成为开发者工具链的新一层。技术上，该项目选择在 tmux 之上做薄封装而非另造独立应用，复用 VS Code 的编辑、diff 与插件生态，这种贴合既有基础设施的思路降低了维护成本，也让 Agent 的生命周期与编辑器进程解耦，编辑器崩溃或重启均不中断后台任务。通过 hooks 获取 Agent 状态目前仍是轻量方案，若各家 CLI 的状态上报格式趋于统一，类似能力可能被吸收进 VS Code 或主流 Agent 产品的原生功能中。此外，AGENTS.md 作为跨 Agent 共享约定的实践，暗示 Agent 工具生态正向协议化、标准化方向演进，围绕多 Agent 管理的周边工具有望成为一个新的细分赛道。

      核心观点：当 AI Agent 成为开发主力，会话管理正从终端技巧演变为独立工具层，编辑器正在变成 Agent 舰队的指挥舱。

      原文链接：V2EX 分享发现

    • 开源终端AI编程工具Snow CLI更新：子代理互通组队与5大系统Agent详解

      Snow CLI（v0.6.33）是一款在终端中运行的Agentic编程开源工具，作者近日发布功能更新汇总。新版VSCode扩展支持拆分窗口和侧边栏两种显示方案，用户可在扩展设置中配置默认启动命令与显示方式。子代理系统迎来重要升级：各子代理支持互相通讯和互相唤醒，同时遵循唯一责任人原则；用户可通过>>指令向任意子代理发送消息进行人工干预，用自然语言提示词即可快速组建Agent Team。子代理还支持上下文显示与自动压缩，notebook可随会话一起回滚，避免AI记录错误记忆。Snow CLI自带5个系统子代理：探索者负责查找项目中与需求相关的文件和代码区域；规划者是Plan模式的抽象层，可在任意时机进入规划；需求分析者以业务需求为导向；调试者不改动现有代码逻辑，自行实现日志功能并统一写入.snow/log目录；通用代理拥有主代理的全部工具和能力。作者还澄清了若干易误解的功能：应优先使用/role生成的ROLE.md而非系统提示词，前者支持全局与项目两个作用域、可自由编辑且权重更高；引用代码时@@内容搜索比@路径定位更精准；系统自带工具本质上是MCP服务，可通过/mcp面板用Tab键禁用，且自定义MCP服务名不得与自带服务重复。此外，Snow Console开放新注册，每日签到配额从15提升至50，用户可支付LDC进行多次签到，签到为重置而非叠加。

      事件分析

      Snow CLI的子代理互唤醒机制体现了终端AI编程工具从单Agent向多Agent协作架构演进的趋势，其唯一责任人原则试图在协作灵活性与执行可控性之间取得平衡。5个系统子代理的分工设计借鉴了软件工程的角色划分思路，其中调试代理只加日志不改逻辑、日志统一写入专属目录的约束设计颇具巧思，降低了AI干预存量代码的风险。细节层面，ROLE.md权重高于系统提示词、@@内容级引用减少上下文浪费等设计，反映出工具对Token成本与上下文效率的深度考量。将系统工具统一纳入MCP体系并支持禁用，与MCP协议生态化的行业方向一致。不过，多Agent架构带来的执行风险与Token消耗仍是普遍难题，作者本人不建议频繁组队的提示也印证了当前多Agent落地的谨慎态度。

      核心观点：多Agent协作正从概念走向工程落地，但风险与Token成本决定了唯一责任人式的强约束是现阶段必要设计。

      原文链接：Linux.do

    • 老项目交给AI维护成噩梦：新项目爽烧Token，遗留代码让AI变负担

      近日，一位开发者在Linux.do论坛发帖，分享了在不同类型项目中使用AI编程工具截然相反的体验。该开发者目前同时负责新项目开发与老项目维护。在新项目中，由于是一次性交付、没有历史包袱，AI工具表现出色，开发者大量消耗token调用AI进行开发，过程高效顺畅。然而在老项目维护中情况完全相反：该项目由开发者本人从零手写完成，此前仅在小范围内使用AI工具并保持在自己可控范围内。当开发者尝试让AI模型（帖子中提及gpt-6.1-sol）全盘接管老项目开发时，发现AI的逻辑与原有需求产生大量冲突，AI引入了许多不必要的保护措施和冗余修改。开发者试图强行矫正AI的行为，反而让自己身心疲惫，因此发帖向社区征求应对思路。该话题已获得社区成员参与讨论。这一现象折射出当前AI编程工具的典型局限：在无历史包袱的新项目中，AI优势明显、产出质量高；而在承载既有架构设计与隐性业务逻辑的遗留代码库中，AI难以准确理解原始设计意图，容易生成与预期不符的改动，导致维护成本不降反升。如何在存量项目中有效引入AI，正成为开发者群体面临的普遍课题。

      事件分析

      这一讨论触及AI编程的核心瓶颈之一：上下文与意图理解的缺失。遗留代码库中蕴含大量隐性设计决策——为何如此分层、为何保留看似冗余的逻辑，这些信息往往只存在于开发者脑中而非代码注释里。大模型仅凭静态代码难以还原完整语境，因而倾向于套用通用最佳实践，生成过度防御性代码和冗余重构。从产业角度看，这解释了为何AI编程工具的市场叙事多聚焦于从零构建场景，而对存量软件维护这一占据行业主要工时的领域渗透缓慢。可能的改进方向包括：将架构决策文档化后注入模型上下文、采用增量式小步重构而非全盘托管、利用代码库语义索引增强检索精度等。短期内，AI负责绿地项目、人类工程师把控存量系统的分工格局仍将持续。

      核心观点：AI能读懂代码语法，却读不懂代码背后的历史与意图，遗留系统的维护仍是人类工程师难以替代的护城河。

      原文链接：Linux.do

    • ChatGPT与Codex 12月起共用额度，Plus档位性价比面临重估

      据Linux.do社区消息，OpenAI自12月起将ChatGPT与Codex的用量额度合并，两者共享同一份额度池，Instant模式不在此范围内。这一调整对不同用户群体的影响存在明显差异。对于主要使用Codex编写代码、几乎不使用聊天功能的用户来说，额度集中供给Codex反而省去了分配顾虑。但对于同时重度使用聊天与编程两类场景的用户而言，额度此消彼长：聊天消耗过多可能挤占Codex的可用量，影响编程任务的连续性。社区讨论普遍认为，Plus档位用户受冲击最大，该档位原本额度就较为紧张，合并后需在两个产品间进一步分摊；Pro档位由于额度池规模较大，合并后的使用体感变化预计不明显。帖子发起者询问合并后各档位性价比是否需要重新排序，以及是否有用户因此计划降档或调整使用方式。该话题已有2位参与者发表观点，反映出订阅用户对OpenAI产品策略调整的广泛关注。额度合并意味着通用对话与编程Agent的算力消耗被置于同一计量体系下，用户的使用习惯与订阅决策或将随之改变。

      事件分析

      从产品策略看，此次合并表明OpenAI正将ChatGPT与Codex纳入统一的资源调配体系，通用对话与编程Agent在算力成本上被拉齐。Codex执行编码任务时的单次消耗通常高于普通对话，同池计价后用户需在两类场景间自行权衡分配。对行业而言，一体化订阅模式可能成为AI服务商的普遍做法，但独立额度策略仍是Claude Code、Cursor等竞品的差异化卖点，重度开发者或因此重新评估平台选择。后续可关注的变量包括：OpenAI是否为Plus档位补充总额度、Codex任务的计量规则是否透明化，以及合并后各档位实际可用量的公开数据。若Plus档位不作补偿调整，中端订阅的吸引力可能下滑，进而影响OpenAI的付费用户结构。

      核心观点：额度统一是OpenAI算力成本优化的信号，聊天与编程同池计价，将倒逼重度开发者重新选择订阅档位或迁移平台。

      原文链接：Linux.do

    最新文章

    热门专题

    热门标签

    AI编程claude大模型AIAI Agent人工智能开源项目Gemini开发者工具开源Claude CodeGitHub开源工具AI工具开发工具谷歌openaideepseek提示词工程cursoranthropic网络安全AI应用ChatgptAI开发agentAI安全自动化智能体AI智能体

    网站统计

    • 日志总数：29859
    • 评论总数：8
    • 标签总数：17952
    • 用户总数：3675
    • 最后更新：2026-11-12