做 PPT、改 Excel、推进项目:这个开源 AI 工作台还能自己改源码

做技术分享时，我更在意 AI 交出来的文件能不能接着用。PPT 的标题要改，时间安排要压缩，讲稿要补上刚才讨论的例子。这些修改很小，却决定了初稿能不能拿去讲。

看 PiCoddy 的代码时，有一个细节让我停下来多看了一会儿：桌面端的 OfficePreview.tsx 把“编辑”“保存”“结束编辑”放在文件预览里，保存成功后显示“已保存到原文件”。聊天和文件之间，多了一条可以继续工作的路径。

再往下看，项目采用 MIT 许可。菜单怎么组织、项目分几个阶段、文档工具接什么参数，都能在源码里找到入口。对开发者来说，除了让它处理手头的任务，还可以把工作台改成自己习惯的样子。

下面围绕一场后端团队的 Agent 技术分享展开：准备 PPT，修改内容，做时间表和讲稿；再用一个菜单改造案例，走到项目开发和二次开发。

本文依据当前项目源码和现有界面素材整理。配图为按最新菜单重制的操作示意，不是本轮完整实测记录；提示词可以直接作为练习起点。办公部分以桌面端为准。

打开 PiCoddy，先在设置里配置可用的模型，发一条普通消息确认连接正常。然后新建任务，选择用于这次分享的工作目录，让资料和后续文件有明确的存放位置。

当前左侧把“专家”“技能”“连接器”拆成了三个入口。“项目”和“自动化”等原有菜单仍然保留。想找专家就进专家页，查看技能就进技能页，不需要在同一页顶部反复切换。

这次先从普通任务开始。给 AI 的要求尽量包含听众、范围和交付格式：

准备一次面向后端开发者的 Agent 工程实践分享。

请先列出 12 页 PPT 的大纲，等我确认后再生成文件。

听众了解大模型，但缺少 Agent 项目经验。

用“查询工单，再提出处理建议”作为贯穿案例，讲清：

工具调用、权限边界、失败重试、退出条件、日志和评测。

每页只讲一个重点，流程尽量用可编辑的文本框和图形表达。

不要把整页内容做成一张图片，不编造上线数据。

最终交付 Agent工程实践-v1.pptx。

先确认大纲，后生成文件，是为了把修改留在成本更低的时候。比如听众主要关心接口接入，就该多讲工具参数和错误处理；如果他们已经做过 Demo，就可以缩短基础概念，增加失败案例。

拿到 .pptx 后，点击会话中的交付物，在右侧打开文件。桌面端支持的 Office 文件可以进入编辑模式，看到“保存”和“结束编辑”。这时可以检查标题是不是独立文本，图形有没有被压成一张图片，内容有没有超出页面。

图 1：PPT 编辑操作示意。

例如第 4 页要讲工具调用的权限边界，标题可以直接改成“先把工具调用的边界说清楚”。改完点击“保存”，确认出现保存结果，再结束编辑。

这里需要看文件本身的结构。原来就是图片的内容，不会因为进入编辑器就自动变成可以逐字修改的文本框。第一次尝试时，用一份版式简单的 PPT 更容易判断编辑链路是否正常。

如果只是换标题，我会先在编辑器里改；如果要补上一段完整案例，就把范围说清楚，再交给 AI。

继续修改前，先保存并结束当前编辑，避免编辑器还拿着未保存版本。然后在同一个会话中发出新的要求：

请先读取已保存的 Agent工程实践-v1.pptx。

保留第 4 页标题“先把工具调用的边界说清楚”。

在现有内容中补充一次工具调用超时的处理过程：

如何记录失败、什么时候重试、什么时候停止。

只修改与这个主题有关的页面，其余内容尽量保持。

另存为 Agent工程实践-v2.pptx，保留 v1。

交付时列出修改的页码和内容；无法保留的格式请说明。

这里的关键是让它读取保存后的文件，并把新版本另存。模型说“保留了原内容”还不够，打开 v2 后要回到第 4 页，看标题是否还在，再检查新增内容。

这一步可以作为自己的验收动作：文件是否能打开，手动修改是否保留，新增页有没有挤字，图形是否错位。不要只根据聊天里的完成提示判断结果。

有了内容，再看时间。准备了 12 页，并不意味着一定能在半小时内讲完。工具调用的例子可能要展开，现场讨论也需要留时间。

可以继续让 PiCoddy 生成一张时间表：

根据已经确认的 PPT，生成 分享时间表.xlsx。

包含“内容模块”“时长（分钟）”“备注”三列。

先按以下安排填入 6 行：

开场问题 3 分钟，工具调用 6 分钟，权限边界 5 分钟，

失败恢复 7 分钟，日志与评测 6 分钟，现场讨论 3 分钟。

最后一行用 SUM 公式计算总时间，不要写成固定数字。

请说明公式所在的单元格，便于我检查。

这组数字的合计是 30。表头在第 1 行、六个模块在第 2 到第 7 行时，合计单元格 B8 应当使用 =SUM(B2:B7)。

图 2：时间安排示例，数字用于演示检查方法。

打开表格，先检查公式栏。再把“失败恢复”的 7 分钟改成 9 分钟，看看合计是否变为 32。这个小操作能分辨交付的是一张带公式的表，还是只填好了结果的静态表格。

源码里也有对应入口：src/agent/tools/doc.ts 的 edit_xlsx 支持设置单元格，并有单独的 formula 参数。生成表格和补入公式可以由不同工具步骤完成，使用时仍以最终文件为准。

如果时间超了，再回到内容上做取舍。比如删掉重复解释的概念页，而不是单纯让讲者把每一页讲快一点。

PPT 适合现场讲，分享结束后，读者通常还需要一份能检索、能复制代码的文字说明。

在同一个会话里，可以接着提出：

读取确认后的 PPT，整理为 Agent工程实践.md。

按“问题—处理方式—检查方法”组织内容。

加入一张 Mermaid 图，包含工具执行、结果检查、

失败重试和退出分支，并保留 Mermaid 源码。

概念解释与 PPT 保持一致；依据不足的地方明确标出。

PiCoddy 当前的 Markdown 预览支持渲染 Mermaid。先看流程图有没有漏掉失败路径，再读文字有没有把“模型提出操作”和“工具实际执行”混在一起。

图 3：Markdown 预览示意，不是富文本编辑器。

这里和 Office 编辑有一个区别：当前 MdPreview.tsx 实现的是预览，没有文章编辑工具栏。要调整说明，可以在会话中要求修改源文件，也可以用自己的 Markdown 编辑器处理，再重新打开检查。

逐页讲稿则更适合 Word。继续给出明确的输出要求：

以确认后的 PPT 和 Markdown 说明为依据，

生成 Agent分享讲稿.docx。

每一节对应 PPT 页码，写出开场句、需要展开的解释、

一个具体例子，以及过渡到下一页的话。

不要只把幻灯片上的要点改成完整句子。

不添加虚构的个人经历、客户案例或效果数据。

图 4：在桌面工作台检查和修改讲稿。

打开讲稿后，挑两页实际读一遍。长句念起来拗口，就直接拆开；一个概念还需要补例子，再让 AI 修改对应章节。最后核对讲稿页码和 PPT 版本，避免幻灯片已经更新，讲稿还停留在上一版。

到这里，围绕同一场分享有了 PPT、时间表、技术说明和讲稿。下一步可以转向开发者更关心的问题：如果这个工作台本身不符合自己的习惯，怎么改？

左侧的“项目”入口值得单独打开看看。当前桌面端提供“产品研发全流程”“已有代码迭代”“调研与方案”和“空白项目”几种开始方式。

拿这次菜单调整当例子，需求很具体：原来挤在一起的专家、技能、连接器，拆成三个独立菜单；点击后只展示对应内容；去掉顶部切换，同时保留其他入口。

这种已有代码上的小改动，适合选“已有代码迭代”。新建项目后填清目标，并在配置里关联自己本机的 PiCoddy 仓库目录。阶段可以按实际工作调整，开始前检查专家分配是否满足当前阶段要求。

给这个项目的第一条任务，可以这样写：

在当前 PiCoddy 仓库中，定位桌面端和云端的左侧菜单、

专家内容页，以及从其他位置进入连接器管理的代码。

目标：专家、技能、连接器分别作为左侧菜单，

每个入口只显示自身内容，移除顶部三项切换。

保留新任务、桌面端项目、自动化等已有入口和行为。

先说明涉及的文件、当前状态如何传递、可能影响的跳转。

不要覆盖仓库里与本任务无关的未提交改动。

确认范围后再实现，并报告实际执行的检查及未验证项。

这比一句“把菜单改一下”更容易落地。因为菜单变了以后，还要看会话里的“管理连接器”能不能跳到正确页面、左侧选中态是否一致、从一个页面切到另一个页面时是否留下旧筛选。

项目模式也没有把“模型回复完成”直接等同于阶段结束。在 LocalProjectWorkspace.tsx 中，可以看到“提交候选交付”“风险与未决问题”“确认并进入下一阶段”等处理。阶段交付要经过人的检查和确认。

对代码任务，可以把改动说明、实际检查结果和待验证问题一起交付。类型检查能发现一部分问题，浏览器或桌面端的点击验证则负责检查实际交互，二者各有用途。

PiCoddy 当前项目文件采用 MIT 许可，第三方组件的许可仍需分别遵守。这里说的二次开发，有几个能直接落到文件上的入口。

第一类是改交互。这次菜单调整涉及桌面端 frontend/src/components/Sidebar.tsx、ExpertPanel.tsx 和 App.tsx；云端对应代码在 cloud/web/desktop/src/。菜单决定入口，内容面板决定显示什么，应用层负责挂载对应页面。

两端目前有各自的前端代码，修改其中一份不会自然覆盖另一份。给团队维护定制版时，这一点比“支持自定义”四个字更有用：要么同步修改，要么进一步整理共享模块，不能只改完桌面端就认为云端也生效了。

第二类是改项目流程。src/domains/project/shared/workflow.ts 定义了模板和阶段。“产品研发全流程”包含需求澄清、产品方案、技术设计、开发实现、测试验收、交付归档；“已有代码迭代”则省去了产品方案阶段。

如果团队每次交付都要补一份运维交接清单，可以从模板开始调整。界面允许的阶段调整先在界面完成，需要变成所有人的默认模板，再改源码并验证阶段切换和交付记录。这是二次开发的例子，不代表当前版本已经内置了那份交接清单。

第三类是接自己的工具。文档读写工具在 src/agent/tools/doc.ts，连接器实现集中在 src/domains/connector/node/。有现成 MCP 服务时，先检查是否能通过连接器接入；确实需要改底层，再沿着这些入口看参数、授权和调用过程。

例如接一个内部工单系统，先把查询能力跑通，再讨论写入。返回字段是什么、哪些操作要确认、失败时如何报告，都应成为接口设计的一部分。连接成功只是第一步，业务结果还需要验证。

项目源码已公开在 GitHub（https://github.com/yxz1025/picoddy）。可以用 Node.js 24+ 和 npm 准备开发环境。先获取仓库：

然后安装依赖：在项目根目录安装依赖：

macOS 开发环境中开两个终端。第一个启动前端：

npm --prefix frontend run dev

确认前端运行在 http://localhost:5173，第二个启动 Electron：

只打开前端网页，不等于启动了完整桌面应用；本地工具和 Office 编辑还依赖桌面主进程与运行环境。当前内嵌 Office 编辑器的平台支持也有限，源码明确列出了 Windows x64 和 Mac ARM64，具体文件的字体、版式与格式兼容性仍需检查。

桌面端与云端的数据、配置独立，不会自动同步。云端有自己的服务、数据库和沙箱执行环境，不能根据上面的桌面截图推断它具备完全相同的编辑能力。

项目仓库：github.com/yxz1025/picoddy（https://github.com/yxz1025/picoddy）。如果这套工作方式对你有用，欢迎到仓库看看源码、按需二次开发，也欢迎点个 Star。

一场分享做完，可以留下可继续编辑的文件；一次小功能改完，可以留下能检查、能维护的代码。对想把 Agent 放进日常工作的开发者来说，先拿一个明确任务试用，再挑一个具体需求改动，比一次接满所有工具更容易看清它是否适合自己。

资料与图片说明：本文依据 PiCoddy 当前工作副本的 README、LICENSE、Office 预览组件、文档工具及项目工作流代码整理。实操组织方式参考读者提供的公众号文章（https://mp.weixin.qq.com/s/_5NGvKehpxxuuUrWJPXv5g），文字、提示词及项目开发案例重新编写。五张配图由 PiCoddy 现有界面素材重制，均为示意图；未沿用参考文章的实测耗时、增长数据和未核实功能。详细核对记录见同目录《03-来源与发布说明》。