阅读指南 这是一篇讲理念的分享，不是使用手册。它回答四个问题：
- Pi 是什么——它和市面上的 AI 编码工具到底哪里不一样；
- 我们为什么选它——结合这个仓库过去几个月的真实使用；
- 怎么用它的"可扩展"长出自己的工作流——把工具"改造成贴合我们习惯的样子"；
- Pi Agent Desktop 工作站——我们把这套能力打包成一个"拷到空电脑双击即用"的桌面应用，让每个同事都能上手。
全篇尽量少讲技术，多讲"为什么这么设计、对我们意味着什么"。技术细节都放在文末的 Related Documents 里，需要时再钻。
过去一年，我们试过不少 AI 助手：网页版对话、各家的编码 CLI、各种插件。它们都能用，但都有一个共同的天花板——你只能用它给你的样子，改不动。想加个"每次帮我把飞书日程读出来"的能力？等官方支持。想让它"回答里带上我们内部知识库的口径"？做不到。工具是别人的，工作流是别人预设的，我们只能去适应它。
Pi 反过来。它的作者有一句话是整个产品的灵魂：
"Adapt pi to your workflows, not the other way around."（让 pi 适应你的工作流，而不是你去适应它。）
这句话不是口号。它带来一个结果：这个仓库里几乎每一个"看起来像是官方功能"的东西——自动记录代码问答、提交日报周报、把 PRD 一键建到 TAPD、发飞书消息、编译知识库——都不是官方给的，而是我们自己"长"出来的。 Pi 只提供最基础的三件事（对话、调模型、调工具），剩下的全部留给我们组装。
对团队的意义一句话概括：我们第一次真正拥有了一件"可以被我们自己改造的" AI 工具，而不是租用一个别人定义好的产品。
市面上的 AI Agent 工具大致分两派：
| "全家桶"派（如多数商业 CLI） | Pi（最小内核派） | |
|---|---|---|
| 设计思路 | 把子代理、计划模式、待办、权限弹窗……全部内置 | 这些一律不内置，留给你自己装或自己写 |
| 你拿到的东西 | 一套别人预设好的工作流 | 一套最基础的原语 + 一个开放的改造接口 |
| 想加新能力 | 等官方 | 自己写个扩展就行 |
| 比喻 | 精装样板房，家具齐全但改不动 | 毛坯房 + 无限装修自由 |
Pi 主动选择做"毛坯房"。它的核心只保留三件事：管理对话、路由到不同大模型、调用工具。凡是别的工具争相内置的花哨功能，Pi 都故意不做——因为一旦内置，就等于替用户预设了工作流，而这正是它要避免的。
① 会话是一棵"树"，不是一条"线"。 一般的 AI 对话，聊偏了就只能重开或往回退，之前的探索白费。Pi 把会话存成可分叉的树：任何一个历史节点都能跳回去、另起一支继续。这特别贴合我们做方案的真实过程——同一个需求，改日期、改舱位、改航线是三条平行的探索路径，而不该是"覆盖掉上一个想法"。
② 打断和排队是两个动作。 Agent 正在干活时，你可以选择立刻打断、纠正方向，也可以把新指令排到它做完之后。这个区分很细腻，但正是真实协作里我们需要的——有时是"停，方向错了"，有时是"这个先记着，做完再说"。
③ 四种用法一视同仁。 Pi 既能当终端里的对话工具，也能被脚本批量调用、被其他系统通过接口驱动、被嵌进别的应用。这意味着同一套能力，既服务人手动对话，也能接进自动化流程——我们后面很多"自动记录""自动汇报"就是靠这一点。
④ 能力靠"扩展"和"技能包"叠加，且能打包分发。 新能力以小模块（扩展）的形式挂上去，成熟的还能打包成"包"，通过 npm 或 git 分享给别人一键安装。工具本身是一个可以持续生长、可以在团队间流通的生态，而不是一个封闭的成品。
一句话记住 Pi 别的工具是"给你一套工作流"，Pi 是"给你一套造工作流的零件"。 它赌的是：模型会越来越强，真正稀缺的不是功能，而是"把工具捏合成贴合自己业务的样子"的自由。
理念再好，也要落到"我们到底用它干了什么"。看这个知识库仓库过去几个月的真实状态——几乎每一项日常都由 Pi 承接，且大多是我们自己接上去的能力：
| 我们日常在做的事 | Pi 承接的方式 | 这是不是官方功能 |
|---|---|---|
| 查后台订单 / SQL / 公布运价 / 最新线上代码逻辑 | 直接让 Pi 调 vfticket 命令行工具 | 我们自己接的 |
| 把每次"代码问答"完整存档，供 PRD/报告溯源 | 一个扩展自动监听、自动写入 sessions/ | 我们自己写的扩展 |
| 写 PRD、编译业务知识库（已积累 191 篇概念） | 一套知识库技能（编译/查询/检查/可视化） | 我们自己装的技能 |
| 提交 OA 日报、生成产品周报 | 打包成技能，一句话触发 | 我们自己写的技能 |
| 把 PRD 一键建成 TAPD 需求 | 打包成技能，自动区分单端/多端 | 我们自己写的技能 |
| 发飞书消息、查日程、读写多维表格 | 飞书操作统一入口技能 | 我们自己写的技能 |
| 回复时默认中文、子目录规则自动生效、Python 走干净环境 | 几个"守卫"类扩展在后台默默兜底 | 我们自己写的扩展 |
这张表就是"为什么选 Pi"最诚实的答案。换成一个封闭的商业工具，上面标"我们自己写的"那些行，一行都实现不了。 我们要么等官方，要么放弃。而在 Pi 上，它们是几周之内陆续长出来的。
再举两个具体的、能体现"只有可扩展工具才做得到"的例子：
例一：代码问答自动存档。 我们经常让 Pi 去分析最新线上代码（codescope），这种回答很贵——一次要跑几十秒的实时代码分析，而且经常要写进 PRD 做依据。如果只存在聊天记录里，关掉窗口就没了。于是我们写了一个扩展：每当 Pi 跑完一次代码问答，就自动把"问题 + 完整答案"追加到对应的任务文档里，并更新索引。这件事官方永远不会替我们做——因为它只对"我们这套用 codescope + Obsidian 记录"的工作流有意义。可扩展性让我们能把这种高度个性化的需求变成现实。
例二：语言与环境的"隐形护栏"。 模型偶尔会飘成英文回复，或者想用系统全局的 Python 乱装依赖。我们挂了两个后台守卫：一个检测到回复语言漂移就自动打断、重来并强制中文；一个强制所有 Python 都走项目内干净的虚拟环境。用户完全无感，但工具的行为已经被我们调教成"符合团队规矩"的样子。这就是"让工具适应我们"最日常的形态。
一个容易被忽略的判断 我们内部的研究报告曾评估：Pi 作为面向 C 端用户的产品底座并不合适（它太"毛坯"，缺内置的安全护栏和长期记忆）。但作为产品经理和团队自己用的生产力工具，它的"可改造"恰恰是最大价值。选型的关键从来不是"哪个功能多"，而是"哪个能被我们捏成自己想要的样子"。
这一章讲方法论——不讲怎么写代码，讲怎么思考"把哪些事交给工具、以什么形态交"。Pi 提供了三个"改造层次"，由浅入深：
适用场景：一件事你每次都要按同样的步骤做（写周报、建 TAPD、对比运价……）。 做法：把这套步骤写成一份说明书（技能），需要时 Pi 自动按它执行。 关键理念：技能是按需加载的——平时不占地方，一旦话题匹配才被读进来。所以我们可以攒很多技能（这个仓库有 50+），而不用担心把工具变臃肿。
举例：日报技能做的事是"汇总今天仓库的 git 变更 → 生成 300 字工作总结 → 提交到 OA"。以前这是三步手工活，现在一句"日报搞一下"全自动。它把我们脑子里的隐性流程，变成了工具能复述、能执行的显性流程。
适用场景：你要的不是"一套流程"，而是"改变工具本身的行为"——比如自动记录、自动兜底、接入一个新服务。 做法：写一个小模块，挂到 Pi 的生命周期上（比如"每次工具调用完成后……"）。 关键理念：扩展能触及技能碰不到的地方——它能监听事件、拦截行为、注册新工具。前面的"代码问答自动存档""语言守卫""Python 环境守卫"全是扩展。
这一层是 Pi 区别于所有封闭工具的分水岭：封闭工具你只能用它的行为，Pi 让你改写它的行为。
适用场景：一个技能/扩展好用到值得让全团队、甚至外部伙伴都用上。 做法：打包成一个"包"，通过 npm 或 git 分发，别人一条命令就装上。 关键理念：个人的改造能沉淀成组织的能力。你调好的工作流不再锁在你自己电脑里，而是可以流通、可以复用、可以迭代。
不是所有事都值得固化。我们的经验是问三个问题：
| 问题 | 是 → 值得做成技能/扩展 |
|---|---|
| 这件事重复吗？ | 一次性的事手动做就好 |
| 步骤确定吗？ | 步骤稳定的才值得固化；每次都要临场判断的不适合 |
| 固化后省的时间 > 维护成本吗？ | 这是那条黄金线——省不回本的自动化是负担 |
核心心法 不要问"这个工具能干什么"，要问"我想让它变成什么样子"。前者是消费者思维，后者是主人思维。Pi 的全部价值，就是把你从前者变成后者。
前面讲的一切都很好，但有一个现实门槛：上面说的技能、扩展、运行环境，普通同事自己配一遍非常麻烦——要装 Node、装 Python、配一堆依赖、放好扩展和技能。这一步劝退了绝大多数非技术同事。
于是我们做了 Pi Agent Desktop——一个把整套能力"电池全含"打包好的桌面应用。它的定位一句话：
拷到一台全新的空电脑，双击就能用。没有浏览器、没有命令行窗口、目标机器什么都不用预装。
| 痛点（自己配 Pi） | Pi Agent Desktop 的解法 |
|---|---|
| 要装 Node / Python / 一堆依赖 | 运行时全内置——空电脑也不用装任何东西 |
| 技能、扩展要手动放对位置 | 开机自动同步——默认技能和扩展随应用带上，启动即到位 |
| Python 技能装依赖各种报错 | 内置 Python 预装好依赖——像做 PPT 的 ppt-master 技能离线零配置直接跑 |
| 更新要重新折腾一遍 | 应用内一键"检查更新"——自动拉最新版，不用重装 |
| 一堆窗口和终端 | 原生窗口——像用一个普通桌面软件，关窗即停，不留后台进程 |
一句话：它把"一个资深工程师才配得起来的 AI 工作环境"，压缩成了"任何同事双击就能拥有"。
装好之后，每个人拿到的不是一个空壳，而是一套已经调教好的团队工作站：
这一点体现了很成熟的产品判断，值得团队理解：Pi Agent Desktop 只负责"外壳"——窗口、内置运行时、自动更新、默认扩展和技能。Pi 本身（网页端和核心）始终从上游官方获取，我们不去改它、不去 fork 它。
为什么这么做？因为一旦去改上游内核，就要背上"永远和官方同步"的沉重维护包袱。我们把自己的创新全部放在"外壳"和"扩展/技能"这一层——这一层完全属于我们、随便改；而内核跟着官方升级，自动吃到最新能力。
分层的智慧 内核租来的（跟官方走），外壳和能力是自己的（随便造）。 官方每次升级，我们零成本吃到；我们每次创新，不用担心被官方升级冲掉。这是"既要站在巨人肩上、又要保留自己个性"的最优解。
把四章收拢成一句对团队的话：
Pi 不是又一个 AI 工具，它是一个"能被我们持续改造、并且把改造成果沉淀下来"的 AI 工作底座；Pi Agent Desktop 则让这份底座变得人人可用。
具体的价值：
回到开头那句灵魂："让工具适应你，而不是你去适应工具。"
过去我们习惯了做 AI 工具的"用户"——用别人定义好的功能，忍受别人预设的工作流。Pi 提供了另一种可能：做工具的"主人"——它只给最小的零件，把"造成什么样子"的权力还给我们。这个仓库过去几个月的样子，就是这种可能变成现实的证据：从代码问答存档到日报周报，从知识库编译到飞书协同，几乎每一件称手的事，都是我们自己接上去的。
而 Pi Agent Desktop 完成了最后一步——把这份"资深玩家才配得起来"的能力，装进一个双击即用的盒子，让它可以在团队里流通。
行业的大趋势是清楚的：模型会越来越强，通用能力会越来越便宜。当所有人都能调用几乎一样的智能时，差异不再来自模型本身，而来自你有没有能力把这份智能，捏合成贴合自己业务的、独一无二的工作流。
模型是租来的，功能会趋同，唯有"我们亲手长出来的那套工作流"，是留在自己手里、并且越用越顺的那部分。 这就是我们选择 Pi、并把它做成一台工作站的全部理由。