从资源监视器到「收尾助手」——当安全成为产品本体

Pier 2.x 是个菜单栏资源监视器：端口、进程、系统指标、Docker、Homebrew 服务，基本单位是端口和进程，默认用户看得懂这些低层对象、也能自己判断该不该动手。3.0 是一次定位转向——从「开发者资源监视器」变成「AI 编程后的本地开发收尾助手」。这篇讲这个转向的判断，以及它逼出的一条设计铁律：安全不是营销词，是产品本体。

转向的起点：vibe coder 不认识进程

目标用户变了。3.0 面向的是高频用 Cursor、Claude Code、Windsurf、终端 agent 的人——他们让 AI 把项目跑起来，但未必真懂端口、进程树、Docker、LaunchAgent 是什么。

问题出在 AI 跑完之后。AI agent 会拉起一堆后台资源：dev server、文件 watcher、浏览器自动化进程、MCP helper、sandbox、容器——任务结束了，这些东西却常常没被停干净。日积月累，Mac 越用越卡、端口被占、内存爬升。而 vibe coder 打开活动监视器，看到的是一屏 node、python、docker-proxy，根本不知道哪个能关。

于是 3.0 的基本单位从「端口/进程」上移到「项目/开发会话」，它要回答的核心问题只有一句：

我的 AI coding 工具留下了什么？哪些可以安全停掉，让 Mac 恢复正常？

Pier 把底层的进程、端口、连接数据，翻译成有证据支撑的、按项目组织的收尾建议。它不是通用 Mac 清理软件、不是杀毒、不是系统优化套件——边界很硬：只碰本地开发资源。

为什么安全是产品本体，不是卖点

这条转向带出一个残酷的约束：面向非专业开发者的清理工具，只有一次犯错的机会。

想象 Pier 建议用户停掉一个 dev server，而那个 server 正是他此刻在浏览器里盯着的页面；或者误碰了一个数据库、一个有状态的持久服务。对一个看不懂进程的用户来说，这不是「哦一个小 bug」，是「这软件把我正在做的东西弄没了」——信任瞬间归零，再不会打开第二次。

专业开发者能自己兜底：他知道 kill 错了怎么救。vibe coder 不能。所以在 2.x 里「展示信息、由用户判断」的模式，到 3.0 必须换成「Pier 替用户把住安全边界」。安全从一个功能点，变成了整个产品能不能成立的地基。

这条判断固化成六条产品原则：

1. 宁可漏报，不可误杀。可以错过一些能清理的对象，但绝不能把有风险的东西放进默认清理；
2. 先给证据，再给动作。每个建议都要说明 Pier 为什么认为它可清理、需确认、或必须保护；
3. 项目优先，进程次之。默认界面按项目组织，PID / 命令 / 端口收进展开详情；
4. 默认温和停止。优先 SIGTERM 或工具自带的 graceful stop，SIGKILL 只是高级兜底，3.0 甚至不自动升级到它；
5. 不做自动清理。Pier 可以建议，但没有用户明确点击，绝不停任何东西；
6. 本地、私密、可解释。所有判断在本机完成，核心功能不依赖遥测或云端。

三色分级：让用户敢点，但不盲点

安全边界的产品化，是一套三色分级，每张项目卡片内部显示：

• 绿色（可安全收尾）：高置信度，Pier 敢放进一键清理。但绿色卡片必须亮出两三条强证据——「没有发现浏览器/API 正在连接」「父终端已退出」「已识别为 Vite dev server」「位于项目目录」——让用户敢点，但不让他盲点；
• 黄色（需要确认）：可能没用了，但证据不足以替用户决定。默认绝不混入一键清理，得用户看完解释、手动勾选；
• 红色（已保护）：Pier 默认不碰，并把它设计成建立信任的保护区——「有人正在连接这个端口，所以 Pier 不会把它放进安全收尾」。

关键在文案层也贯彻了「面向 vibe coder」：默认界面避免低层术语——不说 Kill / SIGTERM / PID / established connection，改说「停止开发服务」「释放端口」「有人正在连接」「可能是 coding agent 留下的服务」。技术词留给展开详情里的高级用户。

Agent 遗留资源：3.0 的一等公民

3.0 最独特的一块，是主动去找**「AI agent 启动、但会话结束后没释放」的遗留资源**。这类东西 CPU、内存未必高，但会越积越多，而且 vibe coder 几乎不可能自己识别。

难点在归因——怎么判断一个孤零零的 node 进程「可能是 coding agent 留下的」。这里有一条铁律：归因必须是结构化证据，不能是路径子串。项目路径里出现 claude、cursor 这种字符串，绝不能产生归因——那太容易误判。agent 本体只认精确的可执行文件名或 App bundle 证据。

更棘手的是 agent 退出后子进程还在的情况。父终端一关，dev server 就被重新挂到 launchd 下，父子关系断了，来源证据眼看要丢。解法是一个 AgentLineageTracker：以 PID + 稳定启动时间 + 用户 作为进程的稳定身份，在 agent 父进程退出、子进程被 reparent 到 launchd 之后，依然保留住「这个后台服务源自那个 agent 会话」的证据。而一旦 PID 被复用、或启动时间变了、或拿不到稳定启动时间，历史归因立即失效——宁可不归因，绝不张冠李戴。

于是 UI 能用人话讲清楚，又不过度声称：

可能是 coding agent 留下的后台服务
没有发现浏览器/API 正在连接
父终端已经退出

「可能」这个词是有意的——Pier 说明了为什么它值得你注意，但不假装 100% 知道来源。

复盘

• 换用户群会重写基本单位。从「懂进程的开发者」换到「不懂进程的 vibe coder」，产品的原子单位就得从端口/进程上移到项目/会话——否则你还是在让用户面对他看不懂的东西；
• 有些产品里安全是地基，不是特性。当执行者会犯错（AI）、用户兜不了底（非专业）、动作不可逆（停进程），安全就不能是勾选框里的一项，它决定产品成不成立。「宁可漏报不可误杀」要写进第一条原则，而不是留到 bug 列表里；
• 归因宁缺毋滥。「可能是 agent 留下的」这种判断，用结构化证据（精确 basename、稳定进程身份）而不是路径子串；证据一旦不可靠（PID 复用、启动时间变）就立刻失效。宁可说「来源不确定」，不可张冠李戴——错误的归因比没有归因更伤信任；
• 术语也是安全的一部分。给看不懂 PID 的人展示一屏 PID，本身就是把风险转嫁给用户。默认界面说人话，技术细节留给主动下钻的高级用户。

3.0 把 Pier 从「给你看数据、你自己判断」变成「替你把住边界、给你有证据的建议」。后面几篇会拆开这套安全机制的内部：fail-closed 的分级引擎、怎么停一个随时在变的进程、以及怎么在不经 shell 的前提下把停掉的服务再启动回来。