37 · 知识管理场景
项目结束，把文件、决策和交付物一起沉淀
最近PIagnet 非常火爆，我把它加入到我WeSight作为核心引擎之一，看看效果如何？
最近PIagnet 非常火爆，我把它加入到我WeSight作为核心引擎之一，看看效果如何？
给 WeSight 接入 PI 引擎：豆包工作把项目资产规划得明明白白
以前我总觉得，让 AI 写代码不难，难的是让 AI 真正「懂」你的项目。这次给 WeSight 接入 PI 引擎，豆包工作直接把项目的知识库和代码放在一起看，把要动的地方规划得清清楚楚。整个过程比我想象中要顺利和丝滑很多。
项目背景：WeSight 想加一个新引擎
WeSight 是我在维护的一个桌面应用，Cowork 功能支持选择不同的 agentEngine 来跑 AI 编程会话。这次想接入 PI 引擎——pi.dev 的极简终端编码代理，命令就是 pi。
我的诉求很朴素：它的价值已经远不止输出可运行的代码片段，提前帮你把整个项目的整体结构、权责边界、潜在风险点全部摸排梳理清楚。于是我对豆包工作进行提问：
在 wesight 这个项目中，准备添加引擎。我想用 PI Agent 引擎。现在请结合知识库的内容和代码的现状，PI 引擎的接入，给我出一个执行计划。
豆包工作不只写代码：知识库 + 代码一起看
读知识库，也读代码
豆包工作先去翻了两样东西：一是飞书里的 WeSight 项目知识库，二是代码仓库里的引擎路由、常量定义、适配器、Provider 注册这些接入点。
这个动作本身就体现了典型的工程协作思维，它会同步对齐知识库中沉淀的项目历史上下文，以及代码仓库里实际运行的架构实现细节，再决定计划怎么写。
一个意外发现：知识库是空的
说实话我一开始没想到，它第一句话就提醒我：知识库是空的。
我打开一看，果然，WeSight 项目知识库只有标题和一个指向已删除子页面的引用，没有任何实际内容。也就是说，引用这个知识库的人，以为里面有答案，其实什么都没有。
更让我放心的是，它没有因为知识库空就瞎编。明确说明「计划里的 PI 信息全部来自对 pi.dev 官方文档和 badlogic/pi-mono 源码的一手调研」，把信息来源交代得清清楚楚。
从代码现状反向摸清接入点
它梳理出给WeSight新增一个引擎，需要逐层打通5个核心环节，依次是常量/类型注册、Provider/环境/安装器、运行时适配器、Router + Main接线、Renderer UI，最后再补上配置同步和全链路测试。
几个关键决策它都给了明确建议：
- 集成通道走 RPC 模式（pi --mode rpc，stdin/stdout JSONL 协议），和现有引擎架构一致；
- 新建独立适配器 PiRuntimeAdapter，不复用 131KB 的 ExternalCliRuntimeAdapter（后者是为解析各 CLI 文本输出定制的，而 PI 是干净的 JSONL 流）；
- 首版 权限直通，二期再通过 PI 扩展把确认弹窗接到 WeSight 现有的权限弹窗。
它的价值已经远不止输出可运行的代码片段，提前帮你把整个项目的整体结构、权责边界、潜在风险点全部摸排梳理清楚。
把项目资产规划得明明白白
交付物：一份可落地的执行计划
计划存到了 docs/pi-engine-integration-plan.md，按 4 个里程碑排了实施顺序和预估工作量：
- M1 骨架：常量/类型/Provider/安装器——能编译，环境面板出现 Pi 并可检测/安装；
- M2 核心跑通：PiRuntimeAdapter + Router + Main 接线——Cowork 用 Pi 引擎跑通一轮对话；
- M3 完整功能：UI + 配置同步 + 图片/续聊/停止；
- M4 权限打磨：权限弹窗 + 测试与回归。
它还提前列了 6 个风险点，包括了models.json 的 schema、流式语义、会话续聊策略、Windows 兼容等等，都是实现时容易踩的坑。
决策不拍脑袋：留给你拍板
它将接入路径走RPC模式、新建独立适配器、首版采用权限直通这三个核心决策点清晰呈现，同步给出了经过验证的默认方案参考，最终将项目决策权完整交还给开发者。这种先完成全链路方案推演、再保留核心决策空间的协作模式，大幅降低了项目推进过程中的沟通内耗。
把调研和交付物沉淀回知识库
放知识库，遇到权限问题
我提出把这份PI引擎接入的调研文档沉淀进项目知识库。它先尝试直接写入WeSight项目知识库，很快识别出当前账号仅拥有只读权限，无法完成新建操作，随即自动切换路径，将完整文档同步导入我的个人知识库，完成全量内容校验，确认导入结果完全准确。
这个过程里它点出了一个很容易被忽略的核心认知：文档的存放位置、可维护权限本身就是项目资产的重要组成部分。如果知识库内的每一份文档都没有明确标注负责人和最后更新时间，用不了多久，整个知识库就会变成没人认领、没人敢随便修改的信息孤岛。
先做表层骨架，不搞真实开发
我的要求是「先简单开发一下，只做一个表层就好，一定不要真实开发。做完后把当前状态同步到飞书文档。」
它立刻精准对齐了需求：常量、类型、空适配器、UI 选项都加上，能编译、界面能看到 PI 选项，但不实现真实的 RPC 通信和会话逻辑。随后它从最底层的常量层开始推进，直接在constants.ts文件里新增了PI引擎的枚举定义。整个执行节奏和我预想的完全一致。。
一点感想
回到开头那句话：豆包工作不仅能写代码，还能结合项目的知识库以及代码协作，把项目的资产规划得非常好。 这次它把「知识库现状 + 代码结构 + 外部调研 + 里程碑 + 风险点」放在一起给到我，这就是把项目资产当回事的样子。
但我也想提醒自己和团队，知识会过期。这次遇到的是空知识库，下次很可能就是内容已经过时的旧文档。缺少来源标注、维护负责人、最后更新时间的内容，存放时间越久隐患越大，过时的旧答案会在无人察觉的情况下长期误导后续使用者。 所以文档要带上来源、负责人和更新时间，让 AI 和人都知道：这句话谁说的、什么时候说的、现在还准不准。
最后 这是知识库结构
WeSight 项目知识库
├── 首页
├── 产品与架构
├── 研发规范
├── 会议与决策
│ ├── 会议纪要
│ └── 决策记录 (ADR)
├── 发布与版本
│ ├── 发布记录
│ └── 发布检查清单
└── 团队与职责
最后：
AI越来越强，centex就越来越重要！
AI 办公产品教程 · 完整版