引子

很多人第一次给智能助手加能力，做法像搬家：把聊天记录、项目文档、工具说明书一股脑塞进去，生怕它少知道一点。结果往往相反。真正要用时，它在一堆旧信息里打转，既慢，又容易把昨天的说法当成今天的事实。

Pi 作者 Mario Zechner 与 Armin Ronacher 在一次对谈中，给出了另一种思路：

少预装，多回源；少建万能大脑，多给简单工具。

Pi官方账号在X发布了这段对谈视频。[1] Pi官网也把产品定位写得很直白：核心保持精简，能力按工作流扩展；

Skill按需加载，历史可分支保存，上下文也允许自行管理。[2]

下面五条原则，是我对这套思路的通用化整理。作者观点会明确标出，其余是面向个人与小团队的实践建议。

原则一：“代码是事实”，不等于“不要记忆”

对谈中Mario说：

做编程任务时，代码本身才是事实来源。

这个判断常被误解成“记忆系统毫无用处”。更准确的说法是：

容易变化的事实，不该复制到另一处长期保存。

想象一家小店。

商品今天卖多少钱，应查收银系统；若另抄一本“价格记忆册”，两边迟早对不上。

但 “退款要找谁” “月底如何盘点” 这类稳定规则，写进手册很合适。

对 AI 来说也一样：

• 当前版本、文件内容、任务状态、库存数量等易变事实，应让助手临时读取原始文件或系统；

• 长期记忆只保留稳定偏好、固定约束和难以从现场重新发现的信息。记忆是路标，不是第二套数据库。

原则二：不同信息，要放进不同容器

第一种是目录地图。它只回答“东西在哪里”，例如“合同在documents，照片在media，月报在reports”。地图要短，最好几十行内能扫完；路径变化时立即更新。

第二种是追加式历史，也就是旧记录不改，只在末尾增加新记录。常见格式叫JSONL，可以把它理解为“一行一条小账目”。它适合保存操作日志、聊天摘要、实验结果和决策沿革。需要追溯时再搜索，不必每次把整本账簿塞给助手。

第三种是Skill，即“按需取用的操作手册”。它适合放某类任务的步骤、工具用法、风险和验收方式，比如“怎样整理发票”或“怎样发布网站”。Pi官网称这种方式为渐进式披露：平时不占上下文，任务匹配时才加载。[2]

第四种是README，即目录门口的说明牌。它适合告诉人和助手：这里是什么、怎么开始、哪些文件不能碰。README不宜承担流水账，也不要塞进几百条随时变化的业务事实。

原则三：“Bash够用”说的是通用原语，不是无限授权

Bash是一种通过文字命令操作电脑的外壳。复制文件、搜索文字、调用程序、组合数据，都能用它完成。Mario和Armin所说的“Bash is all you need”，重点在于它是一块很小却能组合出许多工作的积木，而不是说每项能力都要做成专门按钮。[1]

这句话绝不能翻译成“助手想执行什么都可以”。工具的通用性与权限大小是两回事。一个助手能拼出删除、上传或发信命令，不代表它应当拥有这些权限。Pi官网甚至明确说，它不内置权限弹窗；需要的人应按自己的环境加入权限闸门、受保护路径或沙箱。[2]

对普通用户，更稳妥的默认值是：先只读；写文件限制在指定目录；发信、付款、删除和发布必须由人确认；密钥与私人文件不要暴露给通用命令环境。

原则四：遇到反复需求，再造一把小工具

Armin在对谈中举了Sentry的例子。Sentry是收集软件报错的平台。他没有事先加载一整套庞大的工具说明，而是在确实需要固定格式的数据后，让助手做出一个专用Skill和命令行工具。CLI，也就是命令行工具，是通过简短命令接收参数并返回结果的小程序。[1]

这和装修很像。偶尔拧一颗螺丝，用现有工具即可；每天都要拧同一种螺丝，才值得定做夹具。先观察重复痛点，再固化认证方式、查询参数和输出格式，通常比一开始接入几十种“也许会用”的工具更省事。

MCP是一种让模型连接外部工具的标准协议；Schema则是工具参数的结构说明。MCP本身没有错，问题在于某些接法会预先把大量Schema放进上下文，助手还没干活，桌面已经铺满说明书。Pi选择默认不内置MCP，但官网明确允许通过扩展接入。[2]

原则五：大结果落盘，小摘要进上下文

“上下文”可以理解为助手这一次思考时摊在桌面上的材料。桌面有限，把五十二条完整报错全铺开，真正的问题反而容易被淹没。

Sentry例子里的做法很实用：完整结果保存为JSON文件，只把三条样例、总数、字段说明和文件路径交给助手。若样例结构正确，助手再用搜索或筛选命令进入文件查看其余内容。[1] 这类“上下文节省型工具”应返回三层信息：一句结论，少量代表样本，以及完整产物的位置。数据不丢，但也不强迫模型一次吃完。

常见误解：简单不等于排斥专业工具

AST是把代码拆成语法树的结构化表示，适合精确重构和依赖分析；RAG是先检索资料、再让模型回答，适合跨越大量文档查知识；MCP在统一权限、审计调用和结构化写操作时也很有价值。Pi官网同样保留了动态注入、RAG和MCP扩展能力。[2]

小仓库里，直接搜索和读文件往往最省事；几百万行代码、严格权限边界或高风险写操作，则可能需要AST、RAG、MCP以及专门审批。判断标准不该是“哪派更先进”，而是它有没有降低错误率、查询成本和审计难度。没有比较，就不要把个人工作流包装成普遍评测结论。

个人用户与小团队的实践清单：

• 先画一页目录地图，只写路径和一句用途。

• 把价格、状态、版本等易变事实留在原系统，要求助手现查。

• 用追加式文件保存历史，不反复改写旧记录。

• README写入口、边界和禁区；Skill写可重复的具体流程。

• 同类任务重复三次以上，再考虑做专用CLI或Skill。

• 工具默认只读；写入限定目录；外发、删除和付款逐次确认。

• 查询结果超过几十条时，完整内容落盘，只回传样例、统计和路径。

• 每月删除失效说明，抽查Skill能否从空白环境跑通。

• 大仓库或受监管场景，再评估AST、RAG、MCP和集中审计。

结语

好用的智能助手不必“什么都记得”，而要知道去哪里查、何时查、查完怎样留下证据。文件系统负责保存，命令负责组合，Skill负责教方法，上下文只摆当前要用的东西。这样做未必最炫，却能减少一类很日常的麻烦：助手拿着过期笔记，信心满满地回答今天的问题。

Sources

[1] Pi官方账号：Mario Zechner 与 Armin Ronacher 对谈视频（X）— https://x.com/pidotdev/status/2088951405155426757

[2] Pi Coding Agent 官网 — https://pi.dev