家庭服务器上的应用越来越多，Jellyfin、qBittorrent、AdGuard Home、Radarr 等散落在各个端口，每次想使用都得翻找地址，实在令人头疼。本期安利一款开源免费的 Homelab 仪表盘 —— Labby，帮你把所有服务集中到一个页面，管理从此变得一目了然。

Labby 的核心功能

项目名称就叫 samuelloranger/labby，GitHub 上直接搜索就能找到。Labby 能把 NAS 上常用的服务聚合到同一个仪表盘里，当前已经集成了不少实用模块：

• Docker 容器状态查看与一键启停
• qBittorrent、Transmission、SABnzbd 下载任务管理
• Jellyfin、Emby、Plex 媒体服务监控
• AdGuard Home、Beszel、Radarr、Sonarr、Rawkoon 状态
• 天气、日历、网速测试、书签组件
• Reddit、Hacker News 等信息卡片

它并不只是简单地展示数据，你还可以直接在页面上启动或停止容器、暂停或继续下载任务，甚至一键开关 AdGuard 防护。服务端会定时向各个后端请求状态，然后通过 SSE 实时推送到前端，不需要浏览器反复轮询。所有的服务地址、API 密钥等配置信息都保存在一个 SQLite 数据库里，修改和迁移都很方便。

快速部署 Labby

这里以威联通 NAS 为例，使用 Docker Compose 一行命令就能拉起。

部署用的 compose 文件如下：

services:  
  labby:  
    image: ghcr.io/samuelloranger/labby:latest  
    container_name: labby  
    user: "0:0"  
    ports:  
      - "8425:8080"  
    volumes:  
      - /share/Container/labby/config:/app/config  
      - /var/run/docker.sock:/var/run/docker.sock  
    restart: unless-stopped

打开威联通的 Container Station，创建新的应用程序，把上面的内容粘贴进去，启动即可。

AEC Magazine 在伦敦 QEII 中心办完十周年大会，把 NXT BLD 2026 的核心信号浓缩成七条。今年最鲜明的转向是：AI 与开源真正渗透进了设计院的日常工作流。下面用直白语言把这七条讲清楚。

图：NXT BLD 2026 现场。大会在伦敦 QEII 中心举办，恰逢办会十周年。

01

工厂化交付，从口号变成可操作的数字化流程

WSP 的 Dale Sinclair 分享了一个实例。

本来需要运到现场拼装的构件多达 3500 个，转为工厂预制装配方案后，最终只有 64 个集成的总成单元。现场的工期、管理复杂度和风险同步下降。

这套方法就是 DfMA——为制造和装配而设计。Sinclair 认为，它需要配备新一代工厂，这些工厂能够带来到更低的整体成本、更短的交付周期。他拿波音作为参照：整机在美国境内运输，因为制造和物流是一套完整的系统，而非散件拼装。

目前 WSP 正在深入研究产品生命周期管理（PLM），这套技术已在汽车和航天领域运用多年。PLM 的头部厂商 Siemens 与 Dassault 都已到场，把建筑业视作下一个重要战场。

图：工厂化预制装配示意。将现场散件组装工作前移至工厂，形成少数总成，是这一条最核心的动作。

02

头部事务所，将技术栈彻底重构

Foster + Partners 的 Martha Tsigkari 明确表示，他们并没有在旧流程上粘贴 AI，而是把整套技术栈推倒重建。在她看来，AI 既是颠覆力量，也可能直接威胁专家的知识型工作。

他们的底气来自六十年的设计知识积淀，以及与之相伴的文档体系。新管线从图像到视频，再延伸到三维模型，中间依靠智能体协作，工具已经变成了与设计师共同建模的伙伴。

HOK 的方向聚焦在数据。Greg Schleusner 抛出一个问题：当数据真正解放后，行业到底需要什么？更困难的是，抽出丰富且可用的内容，因为锁定不仅来自文件格式，API 层面的壁垒同样棘手。

为此，HOK 已经做了验证性实验：把 Revit 模型迁移到 Bentley 的 iModel 环境，再利用 Graebert 自动生成图纸。这说明事务所自主掌控数据管线的构想，已不再是纸上谈兵。

OpenAI决定停运自己的AI浏览器Atlas。根据官方文档，这款产品将在2026年8月9日正式下线。书签、打开的标签页和浏览历史等数据，不会自动迁移，用户需要提前自行导出。

Atlas于2025年10月面世，从出生到终止服务，生命周期不到一年。

但这并不意味着Atlas是一次徒劳的尝试。在这期间，它至少验证了一个关键方向：当AI从单纯的回答者变成任务执行者，浏览器能否成为Agent连接真实互联网的操作空间。

OpenAI最终舍弃了Atlas这个独立入口，却没有扔掉它沉淀下来的能力。

官方表示，随着“将基于浏览器的智能体能力引入ChatGPT和Codex”，公司将弃用Atlas，并基于从Atlas获取的经验，让ChatGPT拥有更强大的浏览器体验。

杀死Atlas的，是ChatGPT自己。OpenAI已经看明白了，AI浏览器注定没有未来。

Atlas之死：ChatGPT是幕后推手

去年10月Atlas刚出现时，AI浏览器存在的理由非常充分。

OpenAI把ChatGPT Atlas定义成“一款以ChatGPT为核心内置的全新网络浏览器”。

那时，ChatGPT已经能帮助用户获取信息，搜索成为最高频的功能之一。

但在OpenAI看来，搜索仅仅是第一步。浏览器才是汇合工作、工具和背景信息的核心之地。

早期的Chatbot固然能提供答案，却始终和真实的互联网隔了一层。如果用户想让AI查找最新信息、同时阅读多个网页、对比不同资料来源，甚至操作网站去完成某个任务，AI就必须拥有一个连接互联网的环境。

恰恰拥有网页内容、标签页、登录状态和用户操作界面的浏览器，是互联网最成熟的操作入口。

于是，一个自然而然的设想浮现了：如果AI将来要替用户完成任务，浏览器也许就是Agent进入互联网的工作空间。

Atlas探索的正是这个方向，因此它把ChatGPT嵌进了浏览器。用户打开网页时，ChatGPT能理解当前页面并给出辅助；面对复杂任务，则直接参与甚至代替用户操作。

这条路在当时看很合理。毕竟，一个真正能替用户办事的Agent，不仅要给出答案，还要能够走进真实世界——而浏览器，正是互联网时代最成熟的人机交互界面。

不只OpenAI这么想，同期它甚至是“后来者”。

2025年初，The Browser Company拿出了AI浏览器Dia。和传统产品相比，Dia将AI能力直接嵌入浏览过程，用户可以让AI理解当前标签页内容、提炼要点、生成文字，并基于浏览上下文完成工作。

2025年上半年进入人们视野的Fellou则更加激进，希望AI不仅能阅读网页，还能规划任务、跨网站操作，把浏览器从信息查看工具变成任务执行环境。

随后，2025年7月，Perplexity推出Comet，同样试图将AI搜索、网页理解和Agent能力融合进浏览器。Comet的核心卖点之一，就是让AI助手伴随用户浏览网页，帮忙总结、管理页面，并代表用户完成部分操作。

包括Atlas在内，这些产品共享一个判断：过去，浏览器是人进入互联网的入口；未来，浏览器可能成为AI进入互联网的入口。

这个判断本身未必有错。但不到一年之后，OpenAI给出了截然不同的答案。

OpenAI最终保留了Atlas探索出的能力，说明浏览器Agent的价值依然存在。

但与此同时，另一股浪潮已经涌起：AI正在改写搜索时代形成的流量分配法则。

Search Engine Land援引Previsible发布的AI Traffic Study称，研究团队分析了677万次由大语言模型驱动的网站访问，发现截至2026年5月，大模型带来的月访问量达到64.4万次，同比增长9.9倍。其中，ChatGPT贡献了92.4%的AI推荐流量。

与此同时，Search Engine Land援引Chartbeat Analytics数据指出，基于数千家全球网站的流量分析，小型出版商过去两年来自搜索引擎的推荐流量下降60%，中型出版商下降47%；同期，Google Search带来的页面浏览量降低34%，而ChatGPT推荐流量增长超过200%。

虽然ChatGPT推荐流量目前还占不到网站总流量的1%，但这些变化已经表明，AI正在变为新的流量入口。

从我个人的经历来看，有一段时间Perplexity的Comet是我的默认浏览器。

那时我经常用它搜索事件的相关报道，尤其用来追查原始信源。对我来说，AI幻觉是一个巨大的风险——AI常常凭空编造数据，引用根本不存在的内容，或者引用链接和回答内容并不完全匹配。我必须找到原始链接去核实，才能安心。

但后来，随着ChatGPT的搜索能力越来越强，我几乎再也没打开过Comet，默认浏览器也换回了Chrome（毕竟我并不总是什么事都要问AI）。

Comet并没有变差，而是ChatGPT逐渐填补了我最在乎的价值空缺：搜索更精准，引用来源更可靠，链接与回答之间的对应更稳定，复杂资料整理也能直接在对话里完成。

换句话说，那些原本需要借助AI浏览器才能完成的工作，现在已经能直接在Chatbot里解决。

在国内，越来越多的人遇到问题时，也会下意识打开豆包和DeepSeek（并开启智能搜索），而不像过去那样“百度一下”。

Atlas死于ChatGPT，根本原因就在这里。死去的并非浏览器Agent这个方向，而是那个决定AI浏览器是否必要的前提假设：

用户需不需要先打开一款AI浏览器，再让AI帮自己使用互联网。

随着AI逐渐具备独立完成搜索、理解网页和执行任务的能力，OpenAI给出的答案是否定的。

AI浏览器没有未来，但浏览器必将拥抱AI

OpenAI放弃Atlas，与公司的整体路线也不无关系。

Atlas原本希望成为ChatGPT进入互联网的入口，但今天的OpenAI正在把ChatGPT打造成一个更大的统一入口。搜索、文件处理、代码执行、任务管理和浏览器Agent能力，全都在被整合进ChatGPT。在这种情况下，继续维护一个独立的Atlas，不但不会增加新的入口，反而可能分散用户。

直白一点说，OpenAI想要的是一个超级助手，而不是一个超级助手旁边再摆上一个浏览器。

但Atlas的关停，必然会迫使市场重新打量AI浏览器的前途。

在深入讨论之前，需要先分清两个容易被混淆的概念：AI浏览器，和浏览器+AI。

它们看似相像，实则代表完全不同的两条路径。

AI浏览器试图创造一个新入口，把浏览器从“网页查看器”升级为一个能够理解目标、调用网页并执行任务的Agent，因此也就要求用户完成一次迁移，舍弃使用多年的习惯，去适应一个全新的产品。

浏览器+AI则是不改变用户入口，只在已有浏览器里加入AI能力。对用户来说，这种变化更自然，因为浏览器本身就沉淀了大量难以轻易替代的资产：收藏夹、历史记录、密码、插件、登录状态，以及长期形成的使用惯性。

这两个概念常被一起归到“AI浏览器”的名号下，但本质上是两种性质完全不同的产品。

拿国内的几个产品举例，美团的Tabbit更接近Perplexity的Comet（以及OpenAI即将关停的Atlas），算是原生的“AI浏览器”，因而也更容易和通用Agent发生重叠。

而腾讯的QQ浏览器、阿里的夸克浏览器和360浏览器，虽然都自称是“AI浏览器”，但这三款产品本质上更接近“浏览器+AI”——它们原本就是浏览器，只不过在自己原有的浏览器里加上了AI能力，并不是要重新创造一个由AI驱动的新入口。

浏览器+AI这条路线最典型的代表是谷歌，其逻辑非常清晰：Chrome已经是数十亿用户访问互联网的入口，谷歌完全没有必要抛弃自身的历史积累，去另创一个入口。

2025年，谷歌开始逐步将Gemini能力整合进Chrome，包括AI模式（AI Mode）、页面理解、跨标签页辅助、浏览历史问答，以及基于浏览器上下文的任务助力。

这些功能的意图，并不是简单地替代搜索，而是让AI能够无缝进入用户原本就在进行的互联网工作流。也就是说，用户不需要换一个浏览器，Chrome自会变得更聪明。

我们不妨这样看，AI浏览器这个产品形态，很可能只是一个过渡阶段。

因为AI需要浏览器，和用户需要AI浏览器，本质上并不是一回事。

Pigsty v4.4 正式发布。表面上看，这是一个例行维护版本：PostgreSQL 18.4、531 个扩展、PG19 beta，以及十四组通过验收的离线安装制品。真正值得讲的变化，则集中在软件仓库与命令行工具上。

Pig 1.5 完成了 PostgreSQL 日常运维命令行的重构。克隆数据库、分叉实例、执行时间点恢复——这些原来散落在 Ansible、Shell、Patroni 与 pgBackRest 里的动作，现在有了一套统一的命令行接口。

与此同时，官方重新梳理了仓库中的 PG 内核分支：新增 Babelfish PG18，补齐 pgEdge PG15～18、AgensGraph PG17 与 OrioleDB PG16～18，还为 PolarDB、IvorySQL 提供自行构建的软件包。

这一版还将 Supabase 自建模板跟进到上游最新版本，并解决了一批兼容问题；同时新增自托管云相册 Immich、堡垒机 JumpServer 与个人财务管理工具 Maybe 的一键部署模板。

Pig 1.5：统一运维入口

pig 最早只是 PostgreSQL 扩展包管理器，后来逐步承担 Pigsty 安装、软件仓库与 PostgreSQL 管理工作。到了 1.5，它已经不只是“能执行很多命令”，而是开始形成一套清晰的 PostgreSQL 操作界面。

这一轮最重要的变化不是命令数量，而是职责边界。过去，这些操作主要靠 DBA 记住 SOP 与命令别名：什么时候调用什么工具，下一步做什么，会有什么副作用。现在，这些经验被直接写进命令，高风险操作统一沿着同一条链路推进：

各阶段的结果与帮助信息既可以输出为人类可读的文本，也可以输出成便于机器和 Agent 处理的 JSON/YAML。通过这套 Agent-Native 接口，DBA、脚本与 Agent 可以共用同一个入口，获得所需上下文、风险判断与下一步提示。

抽象的话说多了没意思，下面来看几个具体例子。

克隆：给单个数据库开一个分支

新增命令 pig pg clone 可以快速克隆单个数据库。

大约一个月前，笔者分享过一款名为PMBrain的本地知识库。当时的版本已经具备资料导入、知识搜索，并且能够接入Codex、Claude Code和Cursor等AI工具。功能虽然可用，安装仍需通过命令行完成，对非技术用户并不友好。

后续有不少读者留言，希望可以推出一个Windows桌面版。这个需求不难理解——知识库能力再强，如果安装时需要配置环境、敲命令、处理端口和依赖，大部分人可能还没开始就已经放弃。

于是，PMBrain桌面端的开发正式启动。这一做，差不多花了一个月。

动手之前看架构，仿佛只是给现有服务套上一个Electron桌面壳。真正实践后才发现，桌面软件的复杂度远不止加个界面那么简单。数据库要能启动，后台服务需随软件运行，端口变化后MCP配置要同步更新，PDF解析依赖额外的本地组件，软件更新还不能误删用户数据。安装包在开发机器上编译成功，并不能保证换一台电脑就能正常使用。

有一次，安装包顺利生成，但在真实环境中导入PDF文件时却报出DOMMatrix is not defined的错误。排查再三，才意识到打包过程遗漏了一个Windows本地依赖。界面能打开，服务也能启动，到了真正导入资料这一步依然会失败。类似的问题踩过不少。

因此，如今要判断一个桌面端产品是否真正可用，不能只看安装包能不能生成。它必须装到一台全新的电脑上，能够顺利启动、配置模型、导入Word和PDF、搜索资料，并能接入AI工具，这才算是真正交到了用户手中。

现在，这个目标终于达成。PMBrain已经推出了Windows安装包。下载后只需点击“下一步”，不必安装Bun，也无需打开终端输入命令，就能把本地知识库部署到自己的电脑上。

下载地址：

https://github.com/zhengyunhui123-dev/PMBrain/releases

目前支持Windows10/11的64位系统，32位Windows暂不支持。项目尚未进行代码签名，安装时可能看到“未知发布者”的提示，请认准上述GitHub发布页面获取安装包。

PMBrain的核心定位：什么样的知识库？

PMBrain基于Garry Tan开源的Gbrain改造而成，背后融合了RAG与LLM Wiki的知识管理思路。目前，PMBrain完全开源、免费，代码和安装包均托管于GitHub。个人模式下，所有数据运行在用户自己的电脑里，无需购买服务器服务，模型API由用户自行选择，对应成本也由用户自己承担。

普通的RAG擅长将资料向量化，然后根据问题找出相关内容。PMBrain在此基础上更进一步：资料不仅可被搜索，其内置的Dream模块还会持续整理资料、提取知识点并建立关联，外部AI工具也能通过MCP调用这些积累下来的知识。

开发PMBrain的初衷，源于解决笔者自身的实际需求。作为产品经理，日常接触需求文档、会议记录、项目方案、待办事项以及大量的AI会话。资料散落在文件夹和聊天窗口里，真正需要查证“当时为什么如此决策”时，往往要耗费大量时间回忆。

大模型的确掌握着广泛的世界知识，但它们并不了解用户的专属项目。PMBrain要保存的正是这部分内容：做过什么、讨论过什么、哪些方案已被放弃、下一步准备做什么。它更像是安置在本地电脑中的外置大脑。

特性一：资料完全保存在本地电脑

PMBrain的数据库、知识文件和配置均可保存在本地。对于项目资料、内部文档以及不方便上传到公共知识库的内容，本地存储会让人安心许多。但这里需要明确边界：本地知识库并不等于所有数据永远不会经过外部服务。如果配置的是DeepSeek、MiMo或其他云端模型，整理与生成过程中，相关内容仍会按照所选接口发送给模型服务商。如果资料敏感，可接入Ollama等本地模型。PMBrain现已支持自定义OpenAI兼容接口，普通模型和向量模型也能分别设置Base URL与API key。数据放在哪里、使用何种模型，完全由用户自己选择。

特性二：Word、Excel与PDF可以直接导入

许多LLM Wiki方案更适用于Markdown用户，但普通人的资料格式往往并不规整。项目里混杂着Word需求文档、Excel排期表、PDF报告、CSV数据以及大量会议记录。如果导入前必须把所有文件转成Markdown，这种知识库大概率坚持不了几天。PMBrain支持md、txt、doc、docx、csv、xlsx和PDF等常见格式。用户可以在知识工作台粘贴一个文件路径，也可以指定一个文件夹，让系统将其中所有资料导入知识库。建议首次导入时，不要一口气导入整个硬盘，而是先拿一个正在进行的项目进行测试。导入完成后，前往“知识库”页面核对文件，再搜索一个只有这些文档里才有的项目名称。如果能找到对应的内容，就说明导入和向量化已成功运行。

特性三：让不同AI工具共享项目记忆

如今很多人会同时使用多款AI工具：Codex负责开发，ChatGPT帮忙分析问题，豆包或千问用来查阅资料。每个工具都很聪明，但它们并不知道你在其他工具里聊过什么。结果就是用户在中间充当信息搬运工的角色。PMBrain可通过MCP接入Codex、Cursor、Claude Code、ChatGPT、WorkBuddy、CodeBuddy和QwenPaw等工具。一段重要工作结束后，可以让当前AI将上下文存入：“把这个上下文完整导入PMBrain，保留已经确定的结论、放弃的方案和未完成事项。”切换到另一个窗口或另一款AI工具时，再让它读取：“先搜索PMBrain里【项目名称】最近的记录，告诉我上次做到哪里，然后继续处理今天的任务。”这样一来，即使AI工具更换，项目背景依然保持连续。对于长期项目而言，这种连贯性比单次回答的聪明程度更加重要。模型会不断升级，工具也会更替，但自己的项目积累不能随着某个聊天窗口一起消失。

特性四：Dream会持续整理你的知识

资料导入知识库仅仅只是开始。用久了之后，同一个项目会出现大量会议记录、会话和版本。旧观点、新结论和已废弃的方案搅在一起，虽然可以搜索出来，实际使用时仍容易选错。PMBrain的Dream模块会继续处理新增资料，提取人物、项目、观点以及它们之间的关系。整理结果可以写入数据库，也可以同步生成本地Markdown文件。如果习惯使用Obsidian，可以把整理后的内容放到指定目录；如果只想使用PMBrain，也可以关闭本地Markdown写入。Dream在使用大模型处理内容时会产生token消耗，效果也会受到模型能力与原始资料质量的影响。这部分仍在持续测试和优化中，尚不能保证每次都能把知识整理得尽善尽美。但知识库真正的难点就在于长期维护：仅会导入和搜索，资料一多，就更容易重新变得零乱。Dream要解决的，正是这个长期难题，让知识库能够随着工作继续生长。

特性五：一个人可用，小团队也能共享

个人使用时，PMBrain默认运行在本机，外部电脑不能访问。如果是10到50人的小团队，可以在一台保持开机的电脑上开启共享模式，再给成员分配凭证和资料源。产品、研发和公共资料可以分开放置，成员根据自己的权限搜索内容。共享模式目前更适用于可信局域网。远程访问只开放了搜索、列出页面、读取页面和确认身份等能力，尚未开放写入。PMBrain现阶段也没有SSO、LDAP、AD及文档级权限，因此大型企业或权限要求复杂的团队，还需要等待后续完善。提前把限制说清楚，而不是把一个适合小团队的功能包装成成熟的企业系统，才是更负责任的做法。

哪些场景适合使用PMBrain？

1. 项目资料管理
   将需求文档、会议记录、项目排期和复盘内容放进去。下次开会前，直接询问上次确定了什么、哪些问题尚未解决。

2. AI会话沉淀
   Codex或Claude Code的上下文快要满载时，把整个会话保存到PMBrain。打开新窗口后先读取之前的记录，项目介绍不必从头再来。

3. 个人知识与写作素材整理
   平时看到的文章、零散想法、学习记录乃至已经写过的内容都可以存入。需要写新内容时，让AI先搜索过去的资料，减少重复思考和无序翻找。

4. 会议结论与待办追踪
   把转成文字的会议记录导入，提取结论、责任人和未完成事项。即便过了几天再查问，也能找到当时的原始记录。

5. 小团队资料共享
   在局域网内放置一台PMBrain主机，成员通过自己的凭证读取指定资料源。大家共用同一批项目知识，同时也能保留个人与部门之间的边界。

从安装到第一次使用，只需这几步

第一步：下载安装包
访问GitHub发布页面，下载最新的Windows 64位安装包。安装完成后打开PMBrain，如果能顺利进入首次配置页面，说明桌面端已正常启动。

第二步：选择数据库和知识库路径
个人初次体验，选择PGlite即可，无需额外安装Docker。数据库路径和知识库路径均可自由设置，重要资料建议放到平时会备份的位置。

第三步：配置普通模型和向量模型
普通模型负责理解、整理和生成内容，向量模型负责资料检索。使用云端模型需填写对应的API key，使用本地模型则按自己的服务地址配置。一键安装解决的是软件环境，模型与API key仍需用户自行准备。

第四步：导入一个真实文件夹
打开知识工作台，粘贴文件夹路径并选择导入。任务结束后前往知识库页面核对文件数量，再搜索一个明确的项目关键词。仅看到“执行完成”还不够，必须能查找到刚刚导入的内容，才证明文件解析、向量模型和搜索均已正常工作。

第五步：接入一款常用的AI工具
进入MCP接入页面，选择Codex、Cursor、Claude Code或自己正在使用的工具。若有“一键配置”选项可直接使用，其他工具可以复制通用JSON。配置完成后重启AI工具，若能看见PMBrain的搜索和读取能力，即表示接入成功。

至此，一套能够存储资料、搜索内容并被AI调用的本地知识库已经就绪。

PMBrain是笔者作为独立开发者分享的第一个产品。从命令行版本到Windows桌面端，一个月的时间里，大部分精力都投入在用户看不见的地方：启动流程、依赖处理、数据库适配、配置逻辑、更新机制以及安装后的真实验证。这些东西写进宣传页并不显眼，却决定了普通人下载之后能否真正用起来。花时间做一键安装，就是想把部署的麻烦全部留在软件内部。用户不需要为了建立知识库而先去学习Bun、终端命令和一连串运行环境，只需把自己的资料放进去，再让AI使用这些资料即可。

知识库也不会装完就自动变成第二大脑。它需要真实的资料，需要持续的日常使用，也需要用户对重要观点做出判断。PMBrain能做的，是减少整理和搬运的负担，让这些积累不会因为换电脑、换AI工具或者换聊天窗口而重新归零。

提交 Pull Request 后，最耗费精力的往往是最初的审视阶段。审查者需要先了解这次改动涉及哪些文件、测试覆盖是否充足、是否存在安全风险、需求实现是否偏离。只有完成这些前置检查，才能进入深度的设计讨论。当团队任务密集时，这个环节很容易拖延半天。本文介绍的 PR-Agent 正是为此而生：它自动阅读 diff、生成描述、提供建议、回答问题，将第一轮的机械性审查工作承担起来。它无法取代人工审查，但作为首轮筛查工具十分称职。

分清开源PR-Agent与Qodo产品，避免混用

本文专注于开源仓库 The-PR-Agent/pr-agent。PR-Agent 是一款开源的 AI 代码审查代理，同时也是 Qodo 公司由社区维护的旧有项目；Qodo 还单独提供了免费版和商业代码审查产品，切勿混淆。该仓库目前在 GitHub 上已收获约 12k+ Star。

需留意 Docker 镜像的命名空间变更：自 0.34.2 版本起，新镜像发布至 pragent/pr-agent；旧版的 codiumai/pr-agent 仅维护到 v0.31，后续不再推送新镜像。

PR-Agent能帮你分担哪些重复审查工作？

PR-Agent 应放置在人工正式审查之前。例如，当一个 PR 改动涉及十多个文件时，审查者最迫切想了解的是：

• • 这次改动做了什么？
• • 哪些文件需要优先审查？
• • 是否存在明显风险？
• • 代码建议能否直接贴到 diff 旁边？
• • 能否在 PR 中直接针对某段改动提问？

PR-Agent 提供的命令围绕这些需求设计：/describe 用于生成 PR 标题、类型、摘要以及文件级 walkthrough；/review 输出审查反馈、潜在问题、安全关注点和审查工作量估算；/improve 给出具体的代码改进建议；/ask 可对 PR 进行追问；/update_changelog、/add_docs、/generate_labels 则属于辅助功能。它更适合作为第一轮筛查工具，帮助团队省去机械阅读的时间，将人的精力留给业务语义理解、架构取舍和最终决策。如果团队原本拥有 Code Review Checklist，也可以将这些规则沉淀到 PR-Agent 的配置中，例如检查功能是否符合需求、边界条件是否处理、异常与权限是否兜底、是否存在明显重复代码等。这样，它的输出就不再是泛泛的“代码质量建议”，而是贴近团队审查习惯的定制化第一轮检查。

深入解析PR-Agent的工作流程

PR-Agent 的工作流程为：在接收到 PR 评论或 CLI 命令后，首先读取 PR 状态和 diff，对改动进行压缩并优先处理关键部分；然后根据 /describe、/review、/improve、/ask 等指令，调用相应工具，并将结果写回 PR 的描述、评论、标签或行内建议。

Skill 不是 Prompt 的升级版，也不是 Prompt 的替代品。

最近，当你在探索 AI Agent 或 AI 编程工具时，可能经常遇到一个关键词——Skill。例如：Claude 引入了 Skill，Kiro 也支持 Skill，很多 Agent 框架也开始强调 Skill。这自然会让很多人产生困惑：Prompt 和 Skill 到底有什么区别？

网上大部分文章都会告诉你：Prompt 是一句话，Skill 是很多 Prompt。或者：Skill = Prompt + Workflow + Tool。这些说法不能算错，但都没有说到本质。真正的问题其实是：Prompt 和 Skill，本来就不是同一个层级的概念。

我们先不要谈 Prompt。

假设我要开发一个功能：上传一个 PDF，AI 自动生成摘要。从用户眼里，它是这样的：

上传 PDF → AI 总结 → 得到结果

但真正的执行过程可能更像这样：

读取 PDF → 提取文本 → 构造 Prompt → 发送给大语言模型（LLM）→ 整理输出 → 生成 Markdown

请注意。真正发送给大语言模型的，其实只有中间那一步：构造 Prompt。而整个“PDF 自动总结”这项能力，很多平台会把它封装成一个：PDF Summary Skill。这里其实已经能看出两者的区别：Prompt 负责和模型交流，Skill 负责完成一项任务。它们关注的问题完全不同。

Prompt 的本质是什么？

Prompt 常被译作“提示词”，但我一直觉得这个翻译并不准确，因为 Prompt 并不仅仅是一句提示。从模型的角度看，Prompt 就是最终发送给大语言模型的输入。

SnapOtter 是一款开源且高度重视隐私的文件处理平台，它为用户提供了一整套运行在本地环境的多功能工具集，确保所有文件都牢牢掌握在自己手中，彻底摆脱对第三方云服务的依赖。

核心特性

• • 全面的工具覆盖：内置超过 200 种处理工具，横跨图片、视频、音频、PDF 与通用文件五大领域，几乎满足日常所有文件处理需求。
• • 隐私优先设计：秉持“你的文件属于你”的理念，所有运算均在本地完成，杜绝数据外泄风险。
• • AI 能力集成：部分工具融入人工智能，可在图像识别、内容增强等场景中提升智能化处理体验（需硬件支持）。
• • 自托管与隔离环境：专为 NAS、服务器或个人电脑部署设计，轻松实现数据安全与独立运维。
• • 完全开源：项目代码托管在 GitHub，鼓励开发者参与共建与二次定制。

安装部署

快速体验版（推荐）

一个容器即可拉起全部服务，适合快速评估与个人使用：

services:  
  snapotter:  
    image: snapotter/snapotter:latest  
    container_name: snapotter  
    ports:  
      - 1349:1349  
    volumes:  
      - ./data:/data  
    restart: always

生产环境版（需额外依赖）

适用于数据持久化与高并发场景，要求提前准备好 PostgreSQL 与 Redis：

services:  
snapotter:  
    image: snapotter/snapotter:latest  
    container_name: snapotter  
    ports:  
      - 1349:1349  
    environment:  
      - DATABASE_URL=postgres://snapotter:snapotter@postgres:5432/snapotter  
      - REDIS_URL=redis://redis:6379  
    volumes:  
      - ./data:/data  
    depends_on: [postgres, redis]  
    restart: unless-stopped  
  
postgres:  
    image: postgres:17-alpine  
    container_name: postgres  
    environment:  
      - POSTGRES_USER=snapotter  
      - POSTGRES_PASSWORD=snapotter  
      - POSTGRES_DB=snapotter  
    volumes:  
      - ./pgdata:/var/lib/postgresql/data  
    restart: unless-stopped  
  
redis:  
    image: redis:8-alpine  
    container_name: redis  
    volumes:  
      - ./redisdata:/data  
    restart: unless-stopped

环境变量说明

更多高级配置请查阅官方文档，以下列出常用变量：

相信大家或多或少都接触过 Superpowers、GSD 和 Gstack 这三个框架。今天分享一种将三者有机整合、让开发效率再上一个台阶的方法——这也是我从几篇文章中获得的灵感。经过这段时间的实践，最突出的体感是：Gstack 在方向决策上的表现非常出色，个人觉得比单纯的 brainstorming 强太多。下面就来详细拆解如何让这三个框架优势互补。

决策、上下文、执行：三大框架的职责分工

整合之前，先厘清三个框架各自最擅长的角色：

• Gstack 主导决策
• GSD 稳固上下文
• Superpowers 负责执行

三大框架核心能力与适用场景解析

1. Superpowers——执行层

• 定位

  ：专注代码落地、闭环交付

• 亮点

  ：覆盖需求澄清→规划→TDD→验收的完整闭环，流程严谨，执行稳定

• 最适合

  ：需求已明确、偏向实现的任务

• 短板

  ：面对小任务时流程略显冗余，前期环节投入较重

2. Gstack——决策层

• 定位

  ：模拟虚拟团队（CEO/设计师/架构师/QA 等角色）进行多角度评审

• 亮点

  ：擅长需求梳理、多视角审查，产品思维、架构与安全校验能力强

• 最适合

  ：需求模糊、需要边探索边开发的场景

• 短板

  ：全角色开启时体积臃肿，单一技能 token 消耗轻松超过 10K，而在代码执行环节相对乏力

3. GSD——上下文层

• 定位

  ：更接近上下文工程工具，而非编码框架

• 定位

  ：固化项目规范、状态与边界，解决长期项目中上下文漂移或失效的顽疾

• 亮点

  ：跨会话保持项目信息高度一致

• 短板

  ：不具备独立的代码交付能力，必须配合执行或决策框架使用

从决策到执行：四步整合实践

以下是我近期真实在用的完整流程：

1. 先用 Gstack 明确方向、完成决策

• /plan-ceo-review

  ：验证产品方向的可行性

• /plan-eng-review

  ：评审架构与技术方案

2. 再用 GSD 锁定上下文，避免漂移

• /gsd-new-project

  ：将 Gstack 敲定的方案“钉”在上下文中

• /gsd-plan-phase 1

  ：设计具体的落地方法

如果想要让某个程序在 Windows 启动时自动运行，最简单直接的方式就是把它放进启动文件夹。在运行对话框或命令提示符中输入 shell:startup 并回车，系统就会打开当前的启动菜单目录。

打开后，直接将程序或其快捷方式粘贴进去即可。如果需要通过命令行自动完成，可以使用如下 copy 命令：

copy "源文件路径" "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\"

这种方法操作门槛最低，适用于大多数简单的自启需求。

第二种方法是利用“任务计划程序”来创建计划任务。通过一条 schtasks 命令就能添加开机自启的任务，并可以指定以 SYSTEM 账户最高权限运行：

schtasks /create /tn task_name /tr C:\run.bat /sc onstart /ru SYSTEM /rl HIGHEST /f

任务创建成功后，如果不想等待下一次重启，还可以立刻触发执行：

schtasks /run /tn task_name

计划任务的方式比启动文件夹更灵活，支持设置触发条件和高权限运行，很适合需要静默运行的脚本或后台程序。

最后一种方法是把程序注册为系统服务。这里推荐使用第三方工具 nssm（Non-Sucking Service Manager），可以从官网 https://nssm.cc/ 下载。通过一行命令就能将任意批处理或可执行文件安装为 Windows 服务：

nssm install YourServiceName "C:\job.bat"

安装完成后，若需要调整服务的额外选项（如启动参数、依赖关系等），可以用图形界面进行编辑：

nssm edit YourServiceName

通过服务方式运行的程序可以在用户登录前就启动，并且拥有较高的稳定性和后台管理能力，适合需要长期驻留的服务型应用。

全文完。