笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
想看看各位使用 Pi 的姿势
先说下背景。我从 Codex 切到 Pi 有一阵子了，整体感受就四个字：迅速、精准、简洁、可控。这四个词基本覆盖了我对 AI 编程助手的全部诉求。Codex 不是不好，但它的输出风格和交互节奏让我总觉得隔了一层，Pi 的响应速度和 token 利用率确实让我有点意外。
不过说实话，从 ChatGPT 客户端这种 GUI 切到 Pi 的 TUI，适应期是真实存在的。最痛苦的是输入——在终端里写长 prompt 或者改代码片段，我基本上一言不合就 Ctrl+G 调出 VS Code 来编辑。这不是 Pi 的问题，是我个人的肌肉记忆还没切换过来。
目前我装的插件不多，就三个：Ponytail、web-access 和 multi-skills。Ponytail 我真心喜欢，无论是开发过程中的代码生成，还是 review 已有仓库时的精简表现，都相当到位。web-access 不用多说，联网搜索是刚需。multi-skills 则是让我能在不同 skill 之间快速切换，省去了手动管理的麻烦。
下面把帖子里各位老哥分享的玩法、插件、工具和思路，按我的理解重新整理一遍，该展开的展开，该补充的补充。
一、插件生态：官方 vs 自研
帖子里有个老哥（paidaxtis）说得很直接：全部功能自己用 Pi 实现插件，哪怕有好的也自己写一遍。这个思路我一开始觉得有点偏执，但仔细想想是有道理的。Pi 的插件机制其实很轻量，自己写一遍的过程就是深度理解其 API 的过程，而且能确保插件完全符合自己的工作流，不会有“别人的鞋硌自己的脚”的问题。
zapan 也提到了类似的观点：不依赖 npm，自己写插件。这里的“不依赖 npm”不是说不让用 npm 生态，而是说插件的核心逻辑不要被第三方依赖绑架，保持轻量和可控。
我自己也尝试过自己写插件，说实话门槛不高。Pi 的插件本质上就是一个定义了输入输出协议的脚本，你可以用任何语言写。关键是要理解它的 skill 机制——skill 是 Pi 执行特定任务的原子单元，插件则是 skill 的集合和调度器。
二、GUI 方案：Orca、pi-web、ThinkRail 的横向对比
帖子里的 bwangll 推荐了 Orca，我试用了一下，确实是目前完成度最高的 Web GUI 方案。它的界面设计得很克制，没有过度图形化，保留了终端的质感，但把上下文管理、文件树、git 状态这些信息都可视化呈现了。
我之前试过 agegr/pi-web，完成度确实偏低。界面是有的，但交互逻辑和响应速度都差点意思，感觉更像是一个 demo 而不是生产工具。不过它的 star 数挺高（4000+），说明需求是真实存在的，只是实现还没跟上。
JetBrains 开源的 ThinkRail 也值得关注。界面精致度很高，毕竟是 JB 家的审美水平。但说实话，它更像是一个“AI IDE”而不是“AI 终端的 GUI 壳”，定位和 Pi 本身的哲学（轻量、可组合）有点冲突。如果你喜欢 JB 系产品，可以试试，但别指望它能完全替代 Pi 的 TUI 体验。
ykone 老哥的观点我特别认同：不要搞重型 GUI、ADE 的路线，就应该 Pi 或者 dsh 等强自定义的做底层核心，单独开 VSCode 或者 Orca 等做 IDE 的工作。这个思路的核心是“职责分离”——AI 交互层和代码编辑层解耦，这样你想怎么迁移都随便，不会被某个 IDE 绑架。
三、上下文管理：Magic-Context 和 20k 初始上下文
yidinghe 推荐的 Magic-Context 插件解决的是一个非常实际的问题：会话切换或压缩导致的信息丢失。
用过 Pi 的人都知道，它的上下文窗口是有限的。当对话变长，Pi 会自动压缩早期内容，但压缩策略往往不够智能，经常把重要信息丢掉。Magic-Context 的做法是：提取关键信息（比如文件路径、用户偏好、项目结构、决策记录）单独存储，在每次会话开始时自动加载，确保“记忆”不丢失。
这其实是一个很深的主题。Pi 的上下文管理机制和 Codex 不太一样，它更强调“显式控制”——你可以通过 tree 命令查看当前上下文的组成，通过 shake 工具手动清理不再需要的上下文块。这种灵活性是双刃剑：用得好，你可以把初始上下文压到 20k 左右（Symbo1ic 提到的数据），用不好，你会陷入上下文管理的泥潭。
关于这个，Symbo1ic 推荐了一个叫 oh my pi 的分支，虽然名字有点搞笑，但学习价值很高。它做了几件事：
- 提供 subagent 和 workflow 机制（其他 harness 的常用功能）
- 更精简的 MCP 系统
- 通过抽象将初始上下文尽量压小（一般可以压到 20k 左右）
- 保留 Pi 的灵活性（比如 tree）
- 提供 harness 级别的 handoff 和 shake 等上下文控制工具
- 可以直接读其他主流 harness 的 skills
- 支持从其他 harness 的聊天记录直接 resume
迁移成本很低，但也有一些小问题，比如 workflow 不支持 resume。不过作为一个集成方案，它确实能帮你快速了解并测试不同的上下文控制方法。
四、权限控制：Pi 的设计哲学与社区补救方案
150530 问了一个很关键的问题：权限是怎么限制的，Pi 好像没有批准功能吧？
确实，Pi 的设计逻辑就是不做权限控制。它的哲学是“信任用户，信任 AI”，默认情况下 AI 可以执行任何命令。我在 Codex 时代也是直接 yolo 模式，所以对我来说无所谓。但如果你在团队中使用，或者 Pi 要处理一些敏感操作，这个问题就绕不开。
社区给出了几个方案：
pi-guardrails（
aliou开发）：给 Pi 增加危险执行命令检查和授权功能。coreJK推荐了这个，但klc反馈说在非交互式的 subagent 任务中容易陷入死循环。这个反馈很有价值——说明权限检查机制在交互式和非交互式场景下的表现差异很大，设计时需要区分对待。pi-permission-system：
foryou2023用的这个。他的做法是：让 AI 改一下配置，把执行rm的命令改为要申请批准的，其他命令全部放行。这个思路很务实——不是一刀切地全部拦截，而是只针对真正危险的操作做拦截。pi-defender：
klc之前用过，但同样在非交互式任务中遇到死循环问题，后来放弃了。他的替代策略是：如果 agent 改错了，就用 pi-rewind 回滚代码。这个思路很有意思——与其在“执行前”做权限控制，不如在“执行后”做变更回滚。
说实话，Pi 的权限控制确实是一个需要社区持续补全的领域。核心难点在于：权限检查本身会消耗上下文，而且会打断 AI 的思维流。理想的状态应该是“默认放行，关键拦截”，但“关键”的定义因人而异。
五、模型接入：cliproxy、antigravity 与多模型切换
leadfast 提到他主要配合 cliproxyapi 使用，切换模型很方便。这个工具本质上是给 Pi 做了一个模型代理层，你可以在不修改 Pi 配置的情况下动态切换后端模型。
ffalex 的用法更进阶：在 paseo 中利用 Pi 调用 antigravity，这样可以在 paseo 中同时运行 Claude Code、GPT 和 Gemini。多模型并行跑的好处是：你可以针对不同任务选择最合适的模型，比如代码生成用 Claude，通用对话用 GPT，特定领域用 Gemini。这种“模型路由”的思路，在复杂工作流中非常有用。
lonccc 问 Pi 和 Claude Code 相比有什么优势，lone6 的回答很直接：Pi 可以直接对接 Claude Code。这意味着你不必在两者之间做选择，而是可以把 Pi 作为统一的入口，把 Claude Code 作为后端模型之一。
六、自研之路：从 Codex 到自建 agent
bronyakaka 分享了一条完整的演进路线：
Claude Code → OpenCode → Codex → 定制 Pi → Kimi Code → 自己写了一套最满意的自己用
他开源了自己最终的作品：https://github.com/Bronya0/ally-agent。
这条路线的价值在于：每一次切换都是一次深度思考。你用 Claude Code，理解了 Anthropic 的交互设计；你用 OpenCode，理解了开源生态的灵活性；你用 Codex，理解了 OpenAI 的模型能力边界；你定制 Pi，理解了插件系统的设计空间；你用 Kimi Code，理解了国产模型的差异化优势。最后你把这些理解融合，写出真正属于自己的工具。
spark 问了一个直击灵魂的问题：定制来定制去，我想知道同样用 GPT-5.6-sol 差距有多大？
我的回答是：模型是引擎，harness 是驾驶舱。同样一台发动机，装在轿车和装在卡车上，驾驶体验完全不同。Pi 比 Codex 快、token 少、命中率高、废话少——这不是模型层面的差异，而是 harness 层面的差异。Pi 的 prompt 设计更紧凑，上下文管理更智能，输出控制更精确，这些都会直接影响最终效果。
七、终端 vs Web：Sixel、OMP 和迁移成本
xironwater 在 Windows 上遇到一个问题：Pi 不支持老协议 Sixel，所以无法在终端中展示图片。这对他来说是硬伤，因为他的工作流中图片展示是刚需，最终他转投了 omp 的怀抱。
这个细节值得注意：协议兼容性往往是 TUI 工具被忽视的短板。Sixel 是终端图片显示的老协议，现代终端大多支持，但 Pi 选择了不支持。如果你依赖终端内图片展示，需要提前确认这一点。
micean 从 omp 迁到了 dsh，他的评价是：不折腾不建议迁。原因是 dsh 的 web UI 开发比较自由，他的 Windows 环境原本是 tty7+omp，现在功能基本迁移过来了。但性能上有 bug？他没有明说，这暗示 dsh 在稳定性上可能还有待提升。
八、其他实用插件和技巧
Meursau1T只装了两个插件：给页面添加边距的插件、折叠工具调用输出的插件。极简主义者，但这两个插件确实解决了实际问题——边距影响阅读体验，折叠工具输出减少视觉噪音。passive在 tmux 下直接用原始版本，只装了 web 搜索插件和全局的 grill skill，然后用 Pi 给自己写了一个识别本地/局域网 self-hosted model 的插件。这个思路很好——把 Pi 当作一个开发平台，而不是一个固定功能的工具。BingoXuan在做一件很有意思的事：基于 Pi 的 Web IDE，让硬件工程团队在本地跑一个 MCP 服务，AI 云端生成固件并烧录控制硬件。这本质上是“硬件版的 Lovable”——AI 直接驱动硬件开发。这个案例展示了 Pi 在垂直领域的潜力。ykone的建议再次强调：Pi 或 dsh 做底层核心，VSCode 或 Orca 做 IDE 工作。这个架构的核心优势是“可迁移性”——底层核心和上层界面完全解耦，任何一层都可以独立替换。ykk的观点比较佛系：如果真的好用，等 Codex+GPT 内置你需要的 skill 能力就行了，从来没搞过什么 skill，每个月几十亿 token 消耗，不学习就不用学。这是一种“无为而治”的策略，适合那些不想深度定制、只想要开箱即用体验的用户。
九、关于 DeepSeek 和思维链的一个插件
最后，Symbo1ic 提了一个针对 DeepSeek 的插件：https://github.com/hundan2015/omp-dsh-minimal。如果你因为 DeepSeek 的“智商问题”而苦恼，想换到 dsh 但又不想失去思维链能力，这个插件能保留 minimal 模式的思维链同时保证功能。
这个插件解决的核心问题是：DeepSeek 在某些任务上的表现不如预期，但它的思维链（Chain of Thought）能力又很有价值。这个插件让你在 dsh 中继续使用 DeepSeek，同时保留思维链的透明性。
十、我的最终建议
综合帖子里所有信息，我给出以下建议：
如果你追求极致的轻量和可控：直接用 Pi 的原始 TUI，装 web-access 和 grill skill，自己写插件。不要装太多东西，保持核心的简洁。
如果你需要一个 GUI 壳：首选 Orca，次选 ThinkRail。pi-web 目前完成度还不够，可以关注但别投入太多。
如果你需要多模型并行：用 cliproxy 做代理层，或者用 paseo 做统一入口，把 Pi 作为核心引擎对接不同模型。
如果你关心权限控制：用 pi-permission-system 做最小化拦截（只拦 rm 等危险命令），配合 pi-rewind 做变更回滚。
如果你在 Windows 上且需要终端内图片显示：提前确认 Pi 的协议兼容性，必要时考虑 omp 或其他方案。
如果你想要深度定制：参考 oh-my-pi 的设计思路，理解它的上下文压缩和 workflow 机制，然后自己写一套。
Pi 的核心优势不是某个单一功能，而是它的可组合性。它不是一个“开箱即用”的工具，而是一个“自己组装”的平台。花时间理解它的插件机制、skill 系统和上下文管理，你会得到一个完全贴合自己工作流的工具——这种体验是任何闭源 GUI 都给不了的。