PiDeck 核心原理解析与功能深度指南

本文档面向希望深入了解 PiDeck 底层机制、设计理念与技术细节的用户与开发者。无论你是刚刚上手的小白，还是希望排查疑难问题的进阶玩家，都能在这里找到关于输入框指标、上下文压缩、进程与会话生命周期、消息队列与 btw、检查点回滚、内置插件机制、模型加载体系、代理链路及配置设计的详尽解答。

---

目录

1. 设计理念：PiDeck 与 pi 的边界与配置共用
2. 输入框各种指标与计算原理
3. 上下文压缩与裁剪机制
4. Agent 运行时生命周期与各种状态
5. 消息队列、忙碌投递与 BTW (顺便说一句)
6. 检查点（Checkpoint）与版本回滚（Rewind）
7. 外部会话导入与加载机制
8. 内置扩展（插件）全景深度解析
9. 模型生态：获取、加载、刷新与默认逻辑
10. 代理链路：桌面代理、会话代理与 DSH 代理
11. 子 Agent（Subagent）与委托任务管理
12. 核心配置项详解与小白上手建议

---

一、设计理念：PiDeck 与 pi 的边界与配置共用

1. 核心边界原则

在 PiDeck 的架构中，有一个不可逾越的边界：

• pi 负责什么？ 负责 Agent 核心大脑：工具调用（读写文件、执行 bash 等）、LLM 调用、会话 JSONL 文件读写、模型上下文构建与状态流转。
• PiDeck 负责什么？ 负责桌面工作台体验：窗口管理、进程生命周期守护、多项目管理、会话可视化时间线、Git 状态面板、内置终端、外部编辑器调用、可视化配置交互。
• 两者如何通信？ 严格通过 stdio JSON-RPC 标准输入输出通信，绝不引入第二条通信通道（例如不会在 pi 内部开 HTTP 服务）。

2. 配置与数据的共用机制

很多用户困惑：“我在命令行装了 pi，PiDeck 会不会重复创建一套配置？” 答案是：完全共享，无缝衔接。

• 全局配置目录：~/.pi/agent/
  • models.json：模型供应商与自定义端点定义。
  • auth.json：各模型的 API 密钥（API Keys）。
  • settings.json：pi CLI 的原生设置（如 thinking 等）。
  • skills/ 与 extensions/：用户自行编写或安装的全局技能与扩展。
• 项目级配置目录：每个项目根目录下的 .pi/
  • .pi/skills/ 与 .pi/extensions/：特定项目的私有扩展与技能。
• 会话持久化存储：
  • pi 会话是标准的追加写 .jsonl 文件，保存在系统的 ~/.pi/agent/sessions/ 目录中。
  • 无论你在终端执行 pi 还是在 PiDeck 桌面中对话，写入的都是同一批 .jsonl 文件。在终端开过的会话在 PiDeck 侧栏立即可见，在 PiDeck 里聊过的会话也可以在终端 pi --resume 继续。
• 桌面专用数据目录（userData）：
  • 仅存储桌面端专用的元数据：如 settings.json（桌面窗口尺寸、主题、快捷键、代理配置）、窗口状态、本地缓存、内置扩展热更新目录等，不污染 pi 原生配置。

---

二、输入框各种指标与计算原理

在输入框下方或发送按钮旁，常驻着各种性能数据和上下文圆环。这些指标是 pi 算出来的还是 PiDeck 自己算的？指标具体代表什么？

1. 统计条（ComposerStatsLine）展示的各项指标

指标条展示在输入卡正下方。针对 pi 和 DSH 两种后端，呈现模式与数据来源如下：

指标字段	展示示例	计算原理与来源（谁算的？）	业务含义与说明
轮数（Turns）	12 轮 或 12 轮 · 24 步	PiDeck 统计（基于会话消息历史） （DSH 后端则由其官方 sessionStats 投影提供）	表示当前会话中用户发起对话的轮次（以发言周期为口径）。在 DSH 下若包含步数（Steps），则表示该会话完成的思考/工具执行单步总数。
首字时延（TTFT）	首字 850ms	pi 上报（记录在运行时状态 ttftMs）	Time to First Token。从消息发送给模型，到收到模型的第一个字符或第一个 Token 所经历的耗时。反映模型 API 的网络延迟与排队等待时间。
单次回合耗时	回复 4.2s	pi 上报（记录在运行时状态 totalMs）	该轮对话中，模型生成完整内容（包括多次工具调用与思考）的累计墙钟总耗时。
生成速率（TPS）	48 tps	pi 上报 / 计算（outputTokens / (totalMs - ttftMs)）	Tokens Per Second（每秒生成的 Token 数量）。反映当前模型接口的输出吞吐速率。数值越高，出字越流畅。
缓存命中率	缓存 84%	pi 上报 / 统计（cacheHitPercent）	提示词缓存（Prompt Caching）的命中比例：cacheRead / (cacheRead + cacheWrite)。命中率越高，大模型重复处理历史上下文的费用越低、首字延迟越小。
Token 用量	输入 12.4K · 输出 1.8K	pi 上报（模型 API 响应返回的真实 usage 累加）	本轮对话中实际消耗的 Prompt 输入 Token 和 Assistant 输出 Token。数值经过 K / M 紧凑单位自适应换算。

关键规则：pi 没有全局会话的大盘投影统计，因此 PiDeck 在 pi 模式下用最近一条回复的性能组（最近一次 TTFT、回复耗时、TPS）来填充指标，语义精准；而在 DSH 模式下则采用整段会话的大盘统计。

---

2. 上下文占用圆环与详情面板（ContextMeter）

发送按钮左侧有一个精巧的 14px 圆环，展示当前会话上下文的使用率。

（1）占用比例是如何计算的？

• 公式：percent = contextTokens / contextWindow * 100%
• 分子（当前消耗 Tokens）：
  • 会话运行中：优先采用模型 API 返回的实际上下文窗口大小（如模型上报已使用 38,400 tokens）。
  • 若模型刚启动或上报百分比为 0 但 tokens 不为 0 时：PiDeck 触发主动重算，防止出现“已用 408 tokens 却显示 0%”的矛盾展示。
• 分母（上下文上限 Window）：
  • 读取当前选中模型在 models.json 中配置的 contextWindow（例如 Claude 3.7 的 200,000，或 DeepSeek 的 64,000）。

（2）两段/三段占用图例分解

点击圆环会弹出一个 320px 宽的详细诊断浮层，展示上下文的构成占比：

• pi 模式（两段估算）：
  • pi 原生接口不拆分 prompt 构成。PiDeck 在主进程中通过算法：对话消息 = 会话文件内历史消息纯字符 ÷ 4 估算。
  • 系统提示词 + 工具定义 = 总 contextTokens - 对话消息估算值。
  • 用蓝色表示“历史对话”，紫色表示“系统提示与工具指令”。
• DSH 模式（三段精确投影）：
  • 分解为：系统（蓝灰） + 工具（紫） + 对话（蓝）。

（3）圆环颜色预警档位

• < 70%：主题普通灰/强调色，表示上下文充裕。
• ≥ 70%：黄色预警，提醒用户上下文偏多，可能影响推理速度或增加调用成本。
• ≥ 90%：红色告警，提示即将撞击上下文上限，建议手动点击浮层内的压缩上下文按钮。

---

三、上下文压缩与裁剪机制

当长对话持续几十轮后，上下文可能接近 100K 甚至 200K，导致模型记忆过载、响应变慢、接口报错（如 413 Payload Too Large）。PiDeck 提供了完整的压缩策略。

1. 压缩触发方式

1. 手动压缩：在发送按钮旁的 ContextMeter 圆环点击展开面板，点击【压缩上下文】按钮。
2. 输入框斜杠命令：在输入框输入 /compact 提交。
3. 被动/自动恢复（Request Size Recovery）：当遇到网关 413 或请求体过大时，内置扩展会弹出确认卡片，协助临时调用大窗口模型完成压缩。

2. 压缩背后的实现原理（pi 内核逻辑）

• 所有权判定（Compaction Ownership）：
  • 会话运行由活跃的 RPC 进程守护，发送压缩请求时，桌面端优先通过 RPC 命令 session/compact 交给原进程处理；如果旧进程中断，则由协调器重新托管。
• 摘要替换与锚点：
  • pi 会截取 firstKeptEntryId 之前的老历史消息，构造一个紧凑的压缩提示词让模型生成一份自包含的结构化任务与状态摘要。
  • 老消息在上下文传输中被折叠，由一条 compaction 摘要消息替代，而磁盘上的原始 .jsonl 依然完整记录。
• 与持久化 Todo 的联动：
  • 压缩会抹除之前的消息，但为了保证任务不丢失，PiDeck 的 pi-deck-todo 扩展会在压缩完成后自动注入一条轻量的持久化任务状态快照（todoBriefNeededAfterCompaction），确保后续推理依然记得当前代办清单。

---

四、Agent 运行时生命周期与各种状态

PiDeck 中每个会话背后可能挂载一个独立的 pi 子进程。进程的启停与状态机设计非常严格，避免孤儿进程或状态撕裂。

1. 运行状态全集

状态标识	含义与表现	允许的操作
unstarted	会话已建好（或从侧栏打开），但尚未向模型发送过任何消息，未拉起子进程。	点击发送即自动激活并启动。
starting	子进程正在 spawn，或正在执行模型连接握手，加载扩展与技能。侧栏显示加载中转圈。	允许强制取消/终止。
idle	进程就绪，等待用户指令。侧栏状态为蓝色圆点。	随时发送新消息、重启、切换分支、切换模型。
running	模型正在流式推理、思考或正在调用外部工具。侧栏状态为黄色呼吸点，输入按钮变为红色中止方块。	允许点击中止（Abort）、发送 btw 插话。
error	进程启动崩溃、退出码非 0、或严重崩溃。侧栏状态为红色圆点。	重新加载会话、重启进程、查看错误日志。
closed	进程已正常退出并清理。	再次发送消息时自动重新拉起。
detached	会话处于后台非激活态，已被空闲释放机制回收资源。	点击会话切回前台时无感重新绑定。

2. 资源管理：空闲释放（Idle Agent Releaser）

很多用户打开几十个项目和会话，如果每个会话都常驻一个 Node.js/Python 进程，内存很容易爆掉。

• PiDeck 内置 IdleAgentReleaser 协调器。
• 当某个会话进入 idle 超过指定时间（且不在当前聚焦屏幕中），主进程会自动向其发送优雅关闭信号，回收内存与 CPU 资源。
• 当用户再次点击该会话 Tab 时，PiDeck 会通过 SessionRuntimeCoordinator 秒级自动复苏该会话，历史消息丝滑还原。

---

五、消息队列、忙碌投递与 BTW (顺便说一句)

当 Agent 正在执行一段耗时很长的任务（比如正在跑构建或遍历修改 20 个文件）时，你突然有了新的想法，该怎么输入？

1. 消息投递的两种策略

可以在 设置 → 会话管理 → 忙碌时发送 中配置默认行为：

1. 插入当前回合（Steer）：
   • 立即把你的话作为“插话指令”打入当前 Agent 正在进行的上下文。
   • 适合发现 Agent 走偏了：“别改那个文件，改另一个！”Agent 会在下一步执行时收到此指令并纠正方向。
2. 排队等待完成（Follow-Up / Queue）：
   • 消息不会打扰当前运行，而是进入 PiDeck 维护的 待发送队列（QueuedPromptQueue）。
   • 等 Agent 本轮彻底结算（agent_end）后，系统自动取出队列首项发给 Agent。

2. 待发送队列管理面板

• 当消息排队时，输入框上方会升起独立的 排队消息卡片（queuePanel）。
• 单会话队列上限为 10 条，卡片默认展开显示前 3 条，超出折叠。
• 每条待发送消息支持：
  • 撤回输入框（Retract）：把排队消息取回输入框重新编辑。
  • 模式切换（Change Behavior）：就地从“排队等待”切换为“立即插入当前回合”。
  • 丢弃（Discard）：直接删除此条排队。

3. BTW（顺便说一句 / Side Question）的实现

在复杂任务执行期间，用户如果只是想问一个临时问题（例如：“顺便查一下刚刚那个函数的引用在哪里？”），系统支持基于独立上下文分支或以 Steer 机制派发轻量临时提示，不破坏当前主线执行。

---

六、检查点（Checkpoint）与版本回滚（Rewind）

AI 帮我们改代码最怕的是什么？“改了 10 个文件，改崩了改不回去，Git 工作区全乱了！” PiDeck 内置了类似 Git 快照的零依赖安全检查点机制（移植自 pi-rewind）。

1. 什么时候会自动打快照？

• 回合开始前（turn）：用户发送新提示词，模型即将开始动手前。
• 破坏性工具调用前（tool）：当模型准备调用 write、edit、bash（带修改命令）等工具前。
• 恢复前保护（before-restore）：在用户点击执行“回滚到某节点”的前一秒，系统会自动给当前现状备份一份，保证回滚操作本身也是可以后悔的！

2. 快照到底存了什么？

每次快照不污染用户可见的 Git 分支，而是直接存入 Git 专有的低层引用：refs/pi-checkpoints/<checkpoint-id>。 一次快照由三棵 Git 树组成：

• HEAD 树：当前提交状态。
• Index 树：当前 Git 暂存区状态。
• Worktree 树：使用隔离的临时索引，将包括未跟踪的新建文件（Untracked Files）一起打包入快照树。

3. 安全回滚（Safe Clean）

当在右侧抽屉的【检查点】列表中选择某一条记录点击【恢复（Rewind）】时：

• 系统校验分支守卫：必须处于快照创建时的同一 Git 分支，防止跨分支误回滚。
• 执行差异对比与原子复原。
• 安全清理守卫：只清理快照创建后新生成的未跟踪垃圾文件；原本就存在的文件、被 .gitignore 忽略的文件、大于 10MB 的大文件受绝对保护，绝不会误删。

---

七、外部会话导入与加载机制

如果你之前使用过 Claude Code、Cursor、OpenCode、Codex 或 WorkBuddy，PiDeck 允许你直接把历史记录带过来！

1. 导入入口

在左侧栏的项目名上右键点击 ⋯ 菜单 → 选择 【导入会话】。

2. 跨工具格式归一化转换

各个 AI 编程工具保存会话的格式五花八门：

• Cursor：保存在 SQLite 数据库（state.vscdb）中，数据是富文本树状结构。
• Claude Code：保存在 ~/.claude/sessions/ 下的 JSON/JSONL 文件。
• Codex：特定目录下的 thread JSON。
• OpenCode：项目专有结构。

PiDeck 的 Importer 会对消息格式进行双向降阶与结构清洗：

1. 提取角色（user / assistant / tool）。
2. 将各家私有的工具调用参数归一化为标准的 read、edit、bash 等通用表达。
3. 清理不可打印字符与超大 base64 噪音。
4. 写入 PiDeck 兼容的标准 .jsonl 头信息与消息行，并放入当前项目的会话归档池中。

3. 会话加载与扫描优化（SessionScanner）

• 流式增量扫描：对于成百上千条历史会话，PiDeck 不会同时把所有文件全部读进内存，而是按行扫描头尾窗口，提炼出 session_info 标题、首轮问题、最后更新时间、Token 消耗等元数据，写入快速缓存（sessionSummaryCache）。
• 超大文件防护：当检测到会话文件超过安全上限时，自动启用有界读取，防止几百兆的巨大历史直接压垮 Electron 渲染进程。

---

八、内置扩展（插件）全景深度解析

PiDeck 在随安装包发布的 resources/extensions/ 中内置了一批强大的官方扩展。这些扩展在拉起 pi 进程时通过 -e <路径> 注入，无需用户手动编写。

扩展文件名	核心功能	为什么需要它？（解决什么痛点）
pi-deck-ask-question.ts	向用户主动发起结构化交互提问（单选/多选/输入/代码编辑）	模型如果对需求有疑问，不用在正文里发冷冰冰的文字询问，而是直接在桌面端弹出一个选项卡面板，用户点选后直接把结构化答案回传模型。绑定飞书时会自动降级为纯文本，防卡死。
pi-deck-todo.ts / pi-deck-todo-state.ts	会话持久化工作代办列表（Todo Widget）	拥有独立的状态机和持久化条目。任务在输入框上方以可视卡片展示完成进度。零前缀缓存破坏设计，模型只在变更工具结果里感知计划，极大降低 API 费用。
pi-deck-goal-mode.ts	目标模式（Goal Mode）自动续轮执行	开启目标模式后，用户指定一个终极目标，Agent 在执行完一轮工具后不会停下等待，而是自动触发续轮，直到完成、报错或触发中断，实现全自动编程。
pi-deck-plan-mode.ts	规划模式（Plan Mode）与安全工具管控	开启规划模式后，限制模型使用写操作工具（禁止 edit / write，管控危险 bash），强制模型先输出分步规划；用户在界面审阅批准后才放行写工具并分步执行。
pi-deck-security-gate.ts	运行时安全防护网（高/中/低三级安全策略）	拦截危险 shell 命令（如 rm -rf、chmod 777、git push 等），限制写目录边界，保护 .env、密钥和 .git 内部文件免受恶意篡改。
pi-deck-trash-guard.ts	回收站守卫（防误删安全气囊）	很多模型写脚本动不动就执行 rm -rf。本扩展拦截一切删除类命令，在真实删除前先将文件移入操作系统的回收站/废纸篓中备份一份，彻底解决“代码被 AI 删光找不回”的恐惧。
pi-deck-vision.ts	视觉桥（给 DeepSeek 等纯文本模型装眼睛）	DeepSeek 等强大的代码模型本身不支持图片输入。当用户拖入截图时，视觉桥会在后台静默调用一个低成本的视觉模型把图片转化为详细的文字技术描述再喂给代码模型，完全无感。
pi-deck-retry-no-body.ts	瞬态网络故障与中文报错自动重试	第三方中转 API 经常报 400 (no body)、502 Bad Gateway 或中文 模型服务暂时不可用。pi 原生错误匹配通常放弃并停机。本扩展拦截这些瞬态错误，转交 pi 执行指数退避重试，避免任务半途而废。
pi-deck-request-size-recovery.ts	超大请求体熔断恢复（413 Recovery）	当上下文太长导致中转站报 413 Payload Too Large 时，自动弹出救援弹窗，引导用户临时切换到大窗口模型执行单次会话压缩，解开死锁。
pi-deck-nul-redirect-fix.ts	Windows 环境 > nul 设备名修复	Windows 上执行 > nul 会生成一个既打不开又删不掉的奇怪文件 nul。本扩展自动在底层把重定向改写为标准的 > /dev/null。
pi-deck-session-title.ts	首轮对话智能自动命名	首轮任务完成后，在后台异步启动轻量模型，根据用户首轮真实意图提取简洁的中文标题（如“实现登录鉴权中间件”），替换默认的时间戳会话名。
pi-deck-subagents.ts	多子 Agent 运行桥接与面板展示	监听子 Agent 的创建、运行、消耗 token、耗时与产出，将其推送到输入框上方的实时进度条（SessionSubagentsStrip）中。

热更新机制：内置扩展出现 bug 时不需要等待重新发版客户端。在【设置】→【扩展】的“内置扩展”面板中，可以通过 AtomGit / GitHub 在线拉取最新扩展代码并写入覆盖层，重启即生效。

---

九、模型生态：获取、加载、刷新与默认逻辑

1. 模型从哪里来？（获取链路）

PiDeck 显示的模型列表，核心数据源有三层：

1. pi 命令行探测：主进程后台调用 pi --list-models。由于包含了所有已启用的扩展，一些通过扩展注册的模型（如 Antigravity 插件）也会被一并采集。
2. 配置文件解析：读取 ~/.pi/agent/models.json 和 auth.json。
3. 内置备用目录：如果当前网络离线或 pi 暂时未响应，PiDeck 内置了主流供应商的常用模型映射字典（piAiBuiltinCatalog）。

2. 刷新策略与缓存机制

为了保证界面流畅，模型不会在每次点开下拉框时都卡住去跑命令行：

• 启动预加载：应用启动就绪后，在后台静默发起一次模型解析并缓存到内存。
• 编辑即失效：在 PiDeck 设置页一旦修改并保存了 models.json 或 auth.json，缓存瞬间标记失效（configInvalidated = true），并立即在后台重新触发探测。
• 会话启动强校验：每次启动一个新会话时，强制确保模型列表是最新的。
• 主动目录网络更新：冷启动时，PiDeck 会检测 models-store.json 的更新时间，若超时会自动调用 pi update --models 拉取官方最新模型目录。

3. 默认模型的优先级与决议机制

新打开一个会话时，PiDeck 是如何决定默认选哪个模型的？

1. 历史记忆优先：如果在当前项目最近使用过某个模型，优先沿用上次的选择。
2. 欢迎引导页偏好（Welcome Preference）：新用户在引导界面选中的偏好模型。
3. 设置项默认模型（defaultModel）：在【设置】→【会话/模型】中用户明确指定的默认模型。
4. 有效性回退兜底：如果配置的默认模型因 API Key 被删或配置修改而失效，系统会从已配置有效 Key 的模型列表中选择排序最靠前的可用模型（如 Claude 3.7 Sonnet 或 DeepSeek V3），绝不让输入框处于无可用模型的坏死状态。

---

十、代理链路：桌面代理、会话代理与 DSH 代理

很多网络环境下需要通过代理才能访问大模型 API 或外网镜像。PiDeck 提供了细致的代理分层。

1. 桌面端代理（Desktop Proxy）

• 影响范围：Electron 渲染进程、内置浏览器网络请求、在线拉取模型列表、检测应用更新。
• 核心逻辑：
  • 支持配置 HTTP/HTTPS/SOCKS5 代理地址与 Bypass 忽略名单。
  • 关键原则：当“启用桌面代理”关闭时，PiDeck 绝不强制写死 direct，而是设置为 system（交还操作系统代理）。避免一关开关反而把系统原有的正常网络切断。

2. pi Agent 子进程代理（Pi Proxy）

• 影响范围：每个会话实际执行的 pi 子进程发起的 LLM 调用和工具网络请求。
• 会话级覆盖：
  • 在左侧栏会话右键菜单中选择【会话代理】，你可以为单个特定会话开启或关闭代理。
  • 为什么需要这个？例如你的主力模型走国外代理，但某个项目使用的本地 Ollama 或国内内网大模型必须直连，就可以将该会话单独设为直连。
• 模型/供应商白名单过滤：设置中支持配置仅对指定的模型（如 openai/*、anthropic/*）走代理，其余模型自动直连。

3. DSH 代理的特殊环境（NODE_USE_ENV_PROXY）

DSH 采用 Node 22/24 内置的 globalThis.fetch（基于 undici 引擎）。Node 默认不读取环境变量里的 HTTP_PROXY。 为此，PiDeck 在拉起宿主环境时显式注入了环境变量 NODE_USE_ENV_PROXY=1，确保 DSH 会话的代理配置真正穿透并生效。

---

十一、子 Agent（Subagent）与委托任务管理

在处理复杂任务时，pi 经常会派发子任务（例如调用 Agent 工具生成一个探索者、研究员或审查员子进程）。

1. 什么是子 Agent？

主会话的上下文容量是有限的。如果让主模型去漫无目的地 grep 搜索几百个文件，上下文很快就会被无用日志填满。 因此主 Agent 会调用子 Agent：“你帮我深入阅读 src/auth/ 目录并总结认证机制，给你 5 轮机会，把结论带回来”。

2. PiDeck 如何感知与展示子 Agent？

• 内置的 pi-deck-subagents.ts 扩展会实时捕获子进程的派发、运行与终态事件。
• 时间线剥离与折叠：子 Agent 在自己独立的进程沙箱中运行，其繁琐的中间工具调用不会污染当前主时间线。
• 输入框上方状态条（SessionSubagentsStrip）：
  • 当有子 Agent 运行时，输入框顶部会浮现子 Agent 任务条，显示其任务目标、状态（running / completed / error）、耗费 Token 数及工具调用次数。
  • 点击可展开查看完整的任务回报。

---

十二、核心配置项详解与小白上手建议

在 PiDeck 左下角齿轮打开【设置】，很多选项可能让你眼花缭乱。这里挑选最核心的配置做通俗解读：

1. 常用核心设置速查

设置项名称	推荐设置值	通俗解释与为何这样选
发送快捷键 (sendShortcut)	Enter 发送 / Shift+Enter 换行	习惯聊天软件选默认；如果是写长 Prompt 的用户，建议改为 Ctrl+Enter 发送，防止回车换行时不小心误触发出。
会话 Tab 打开模式 (sessionTabOpenMode)	单击预览 (preview)	像 VSCode 一样，点一下左侧只是临时预览，不会在顶部堆积几十个 Tab；只有当你对预览会话发消息或双击时，才会固定为常驻 Tab。
忙碌时发送 (busySendDelivery)	插入当前回合 (steer)	当 Agent 还在输出时你再打字，选 steer 会像跟真人说话一样在中间“插话修正”；选 queue 则老老实实排队等它把话说完再提交。
自动生成会话标题 (autoSessionTitle)	按需开启	开启后，首轮对话结束后会自动调用当前模型总结出 10 个字以内的中文标题，侧栏看起来非常整齐。注意：会产生微量 Token 消耗。
安全管理等级 (Security Level)	标准 (Standard)	严格拦截格式化、强制删除等毁灭性命令，其余常用编辑放行。小白用户切勿随意切为“全放行”。
内置浏览器隔离	默认开启	PiDeck 右侧可以开一个真实的浏览器抽屉看前端效果。它运行在独立沙箱里，禁用危险外部参数，非常安全。

2. 小白最佳上手建议清单

1. 检查环境：首次使用第一件事，在设置确认 pi --version 检测通过。
2. 配一把顺手的 Key：在【设置】→【Auth】配好你的主力模型 Key（推荐 Claude 3.7 Sonnet 或 DeepSeek V3 / R1）。
3. 巧用 @ 和 &：
   • 在输入框输 @：快速模糊搜索并把代码文件路径贴给 AI。
   • 在输入框输 &：快速引用历史会话的某条结论。
4. 不怕改崩：右侧抽屉随时查看【检查点】，随时可以一键点恢复回滚代码。
5. 任务大时善用规划模式：在输入框左下角点击模式图标切换为 Plan（规划模式），让 AI 先出方案确认后再动手写代码。