夜雨聆风前两天我发了一期视频，做了一个视频剪辑插件。
它直接跑在 Codex 里。你不用打开任何剪辑软件，跟 Codex 对话就能剪视频。
做这个插件，其实我是想探索一种新的产品形式。
过去十年，我们做产品的思路一直都是开发一个 App，或者一个 Web 应用。包括我自己，最近几个月 Vibe Coding 的时候也一直以桌面端应用为主，前几期视频里大家都看得到。
但我越来越发现，像 Claude Code 和 Codex 这样的 Agent 工具正在变成我们使用 AI 的主要入口，甚至可以说是超级入口。
什么意思呢？就是我们现在用 AI 干所有的活，都是打开 Codex 或者 Claude Code 来完成的。
那问题就来了。如果所有工作都在 Codex 里完成，我们真的还有动力再单独打开一个新的 App 吗？
所以我在想，以后会不会有更多的 App 和 Web 应用，直接以插件的形式跑在 Codex 的插件生态里。
这期内容就是我对这个问题的一次尝试。
为了开发它，我还抽象出了一套全新的开发流程，叫插件经理 1.0。下面我会把这套流程完整地拆开，手把手告诉你这个插件是怎么一步一步做出来的。你可以用同样的方式，马上开发一个属于你自己的插件。
我们现在开始。
动手之前得先搞清楚一件事，你要做的到底是哪一种插件。
现在的插件一共有三种形态。它们怎么工作，适合做什么，完全不一样。
第一种叫 MCP App，它的界面直接长在对话里。
比如你在 Codex 里说，帮我看看杭州有哪些在售的房源。Codex 就会直接打开一张能拖动的地图，就在对话里，图钉、价格、筛选器都能点。你再让它帮你出几张海报方案，它就直接在聊天里给你一排设计卡片，可以左右翻着挑。项目时间线也一样，直接在对话里拖着调。
原理很简单。插件的工具里带着一个界面资源，宿主把它渲染成对话里的一张卡片。你在卡片里做的每个操作，模型都知道。你刚在地图上圈了一个小区，下一句它就直接跟你聊这个小区。
这套玩法现在有官方标准，各家宿主用的都是同一套。不过要注意，不是所有的宿主都支持把界面嵌进对话。不支持的环境里界面不会出现，插件就退回纯工具模式，功能照常使用。
所以它适合轻度到中度的交互。查询、筛选、调参、预览、确认，一张卡片装得下的事，都可以做成 MCP App。
第二种叫 Companion Web App，伴生式 Web 应用。
MCP App 是把界面长在对话里，Companion 正好是反过来。对话在旁边，工作台在浏览器里。
Skill 一触发，插件就在你本机唤起一个 Web 服务，浏览器打开就是一个完整的工作台。多面板、画布、时间线，界面做得多复杂都行。宿主有内置的浏览器就直接在里面开，没有就在外部开浏览器。
它跟 Agent 之间不直接说话，靠同一份项目状态文件来同步。你在界面上提一个请求，先写进项目文件，Agent 看到了就来处理，把结果写回文件，界面过一两秒自动刷新，结果就出来了。谁改了什么，改到哪个版本，全都有记录，两边不会互相覆盖。
所以重交互的产品都用它。编辑器、看板、工作台，要拖拽、要预览、要处理大文件的，就用它。
顺带说一句，前面这两种其实不互斥。同一个插件可以在对话里放一张卡片，同时在浏览器里开一个完整工作台，共用一个后端，源码里管这种叫 hybrid。
第三种叫 Skill Plugin。它跟前面两种最大的区别是，它可以完全没有界面。
整个插件就是一组 Skill，可能再带上 Sub-Agent 和 Hook。装进宿主以后，画面上什么都没多，变的是 Agent 本身。它多了一套现成的方法、流程和检查标准。
以前是你说一句它写一段，现在是按一套固定的流程把事情做完。
所以方法论、工作流程这类的东西，最适合做成 Skill Plugin。开发规范、审核流程、写作流程，都是教 Agent 怎么干活的。
我们这次要用的插件经理 1.0，就是一个标准的 Skill Plugin。
它跟我以往的工作流不太一样。以前工作流是一个项目文件夹加一堆规则文件，现在工作流本身就是一个插件。
那插件经理 1.0 到底怎么帮你，把一句「我想开发一个插件」，变成一个能装、能跑、能交付的成品？
它的工作流一共 5 个阶段。
第一个阶段是 Plugin Spec Builder，跟你做需求采访。
它有个很特别的设计，写进需求文档的每一条，都标着来源和置信度。哪句是你亲口说的，哪条是它推断的，哪条是行业默认，清清楚楚。
第二个阶段是 Interaction Runtime Design，做交互和运行时设计。
它把要做的决定分成三类。产品上的取舍来问你，架构方案它自己决定，平台到底支持什么，去查官方文档。技术上的细节不会推给你猜。
第三个阶段是 Plugin Dev Planner，拆开发计划。
它不按前端后端这么拆，而是竖着切，每个 Task 都能单独跑起来、单独验收。做完一个就能验一个。
第四个阶段是 Plugin Builder，真正开工。
先打通一条最小的链路，再写业务功能。每做完一个 Task，先机器自检，再送独立审核。整个开发期间，它不碰真实宿主。
第五个阶段是 Plugin Checker，做最终检查。
真机接触全部都集中在这一步。把插件真的装进宿主，把完整的流程跑一遍。而且一个宿主通过了，不能替代另一个宿主背书。你要求支持谁，就得在谁那单独验证。
主线就是这 5 步，需求、设计、计划、开发、检查。但真正让它稳的是两层循环。
先说小循环，它在开发环节里。每做完一个 Task，先机器自检，再送任务级审核。审核不通过，不是甩回来一句这里有问题，而是给一份完整的 Finding，把违反了什么要求、证据在哪、影响多大、怎么修、修完怎么重验，全都写清楚。阻断级的问题清零，这个 Task 才算通过。
再说大循环，它在最后。所有 Task 做完，先做完整的检查，再把插件装进真实宿主里跑一遍，最后是全量审核。
这一层发现了问题也不会一律打回重写，而是先看问题出在哪一层。代码的问题回开发，计划漏了回计划，设计错了回设计，需求变了就回需求。
这背后其实是两条原则。
第一条，写和审永远分开。
审核的 Reviewer 每次都是新开的上下文，只读文件和证据，连主 Agent 的转述都不完全信。道理很简单，让主 Agent 自己检查自己，等于让出题的人给自己阅卷，题目本身出歪了，他永远发现不了。
第二条，所有通过都要证据。代码存在不等于功能通过，Build 通过不等于能安装，本地能打开不等于宿主里能跑。
最后必选宿主全部真机验证，必过的验收项全部通过，审核的阻断问题清零，三个条件同时满足才算可以交付。
整个流程的进度都记在状态文件里。今天跑一半，明天接着跑，随时中断，随时恢复。
一句话总结核心思路，就是流程打薄，围栏加强。
像 GPT-5.6 这一代模型，推理能力已经足够强了。你把要求讲清楚，把验收标准讲清楚，把想要的结果讲清楚，中间具体怎么执行，它自己能想明白。
所以整套插件经理里面，你看到的规则基本就是三类，要做成什么样，怎么样才算合格，拿什么来证明。
关注我一段时间的朋友，现在应该已经发现了，这次的插件经理 1.0 跟以往的产品经理系列不太一样。这一次，开发流程本身就是一个插件。
我之所以这么做，是因为我自己也在反思。
原来产品经理系列里有 CLAUDE.md 或者是 AGENTS.md，每次开发你都要把这些规则装进当前的项目文件夹里，非常不方便。那你说装到全局行不行，但 CLAUDE.md 和 AGENTS.md 又会跟全局的规则打架。
所以这一次我直接把开发流程变成插件，装到全局。这样一来，规则冲突的问题就解决了，新开项目也不用重新装，装上这个插件你就可以直接使用。
在 skills 目录下，是插件经理 1.0 包含的 8 个 Skill，整套 Harness 就是由这 8 个 Skill 组成的。
这个界面就是废才俱乐部的官网，www.feicaiclub.cn，插件经理 1.0 的 Codex 版和 Claude Code 版都传在上面了。文件可以在线一层一层翻，也可以直接下 Zip 包，五百多 K，很小。
但和以往有点不同，这套用来开发插件的 Coding Harness 本身就是一个插件，所以你会发现里面没有 CLAUDE.md 或者 AGENTS.md。
那总调度放在哪里呢？就在 Interactive Plugin Builder 这个 Skill 里，就是它下面的 SKILL.md。Description 里写得很清楚，当你从零开发、继续开发、检查，或者打包一个可安装的 Claude Code 或者 Codex 交互式插件时，就会用到这套 Harness。
那整体的工作流程，阶段之间怎么串联，又放在哪里呢？在 references 目录下的 orchestration-core.md 里。这份文档里专门有一块叫五阶段流水线，从第一步的需求采访，第二步的交互与运行时设计，一直到最后的交付收尾，整条流水线的步骤、安排和串联全都写在这里。
当然，你自己的 CLAUDE.md 或者 AGENTS.md，依然是整个项目的顶层规则，这个不冲突。但是一旦涉及到开发插件，启动这套 Harness 的时候，你现在看到的这份 SKILL.md 加上 references 下面的所有规则就会一起生效，并且会影响你接下来和主 Agent 的工作流程。
插件经理 1.0 怎么装，我们来看一下。
下面演示我全程用 Codex。用 Claude Code 的朋友不用换台，两个版本互为镜像，除了目录命名，装法和行为都一样，照做就行。
你需要先把刚才那个文件包下下来，保存到桌面，然后在 Codex 里输入这段提示词，就可以安装插件经理 1.0 了。
Codex 会自动找安装文件，读取脚本，执行安装流程。
执行完成后，它会提醒你已经安装完成，并且需要新开一个 session 才能加载使用。
在左边的导航进入到 Plugin 管理页面，插件经理 1.0 会安装到 Personal 下。点进去，这就是插件经理 1.0 的控制页，这个插件下的 Skill 都在这里管理，可以开启，也可以禁用，一共 8 个 Skill。
再往下，插件经理 1.0 还带了一个 Hooks，也可以在这里管理。第一次安装的时候，系统会问你是否信任这个 Hooks，出现提示你就直接选 Trust 就好了。
安装好之后点击右上角的 Try Now，系统会自动开一个新的 session，插件也自动帮你调用好。然后你输入你想要开发插件的需求描述，发给 Codex 就可以了。
接下来我们就进入到实操环节，从头走到尾，走一遍我这个视频剪辑插件的完整流程。
在输入框里输入 /plugin，找到 Interactive Plugin Builder。这就是插件经理 1.0 整个流程的起始 Skill。
我告诉它，我想开发一个用 Codex 做视频剪辑的插件。
它马上按 Interactive Plugin Builder 开始总调度，先读项目状态，判断项目现在走到哪一步了。因为这是一个全新的项目，所以在项目进度检查里可以看到，Plugin Spec 是空的，设计是空的，开发计划是空的，代码也是空的。
它问我的第一个问题，这个插件给谁用，用来剪什么类型的视频。
我告诉它，这是我自己用的，我是自媒体博主，平时主要拿它做视频粗剪，也会剪一些参加开发者大会时录的素材。
第二个问题，它让我确定首版范围。只做口播剪辑，只做大会素材粗剪，还是两个都要。
其实我两个都要。刚才我举的大会的例子只是想让它举一反三，不代表我只剪这一种素材。所以我把这个需求讲清楚，等于给它矫正一下，保证它后面的问题都是基于口播粗剪和其他素材剪辑这两个场景。
这种矫正后面还有好几次，先说到这。
接着它跟我确认最常见的任务长什么样。一次导入多少条视频，每条多长，什么格式和分辨率，最后希望导出什么结果。
我告诉它，口播草稿一般是一条 20 分钟左右的 A-Roll，成片时长不确定，看内容，素材数量也不固定，看这期视频有多少素材，导出希望能渲染成 1080P 或者 4K。
它又问，导出的结果具体指什么。直接导出成片，导出粗剪时间线，还是都要。
我回答我都要。既能导出成片，也有时间线，而且时间线不是导出来就完事，我要能在插件里做一些基础的剪辑，比如拖动素材重新排列。
于是它列了 6 个基础的剪辑操作，素材管理、时间线、裁切、分割、预览、撤销重做，然后问我还有没有要补充的。
我说这 6 个肯定是要的，但是我反过来让它帮我补充一下建议。
它刚才上网搜索过竞品，对这件事其实它比我更了解，让它反向给我提功能建议，比我自己凭空想更靠谱。
它给的建议分三档。像底稿转录、素材标记，还有 Agent 一键流程，它觉得可以做。花字、字幕、转场、音频的基础操作、B-Roll 插入这些可以做，但是不要做得太重。至于多机位自动切换、复杂的调色、花字模板这种锦上添花的，它不建议在第一版里面做。
看完建议，考虑到这是第一版，而且我现在正在录屏操作，所以我只想做一个基础版。我跟它说，复杂的就先别加了，只保留最基础的操作，能让我实时通过对话让 Codex 剪辑，同时给我一个可视化操作界面就够了。
开发范围就这么定下来了。它找我确认首版的范围有没有问题，我看了一下，跟它说好的没问题。
接着它问了一个非常关键的问题，这里我建议你仔细想一想。
它问这个插件是在哪个环境里使用的，给了三个选项。A 是 Codex 桌面端，B 是 Codex 的 CLI，也就是在终端里使用，C 是 ChatGPT 和 Codex 的聊天端。
我告诉它，我们这个插件跑在 Codex 桌面端。它确认了首版在 Codex 桌面端，形态是完整的本地 Web 编辑器。
接着它问素材怎么界定，怎么复制，怎么使用，怎么保存。它还给了一个建议策略，原素材只做引用，工程文件保存在项目文件夹里，导出的时候让用户自己选择位置。
我基本同意，因为这也是常见的做法。但是我补充了一条原则，我所有的素材上传都在项目文件夹内，下载导出也在项目文件夹内，你只需要确保这一点就行了。
紧接着它问要不要做视频和音频的转录。因为这决定了整体的工作流，比如上传一个视频，第一步就是要先提字幕，一般都是用 Whisper 来转。
方向是对的，但是想多了。
我告诉它，这个功能不用在插件里做。插件本来就是跑在 Codex 桌面端的，Codex 自己就有能力去做转录。所以不要做成插件里的按键或者功能，直接用 Agent Skill 让 Codex 去执行，把结果回写到插件上就好。
不做成一个功能，做成一个 Skill 反而更简单。
它继续问，怎么让 Codex 知道我们正在处理时间线上哪一段素材。它的设想是只处理选中的素材，没选中就默认全部处理，问我是不是这个方向。
我回答它这个交互规则是合理的，但我也希望它再上网搜索一下，看看在这个基础上还有没有可以补充的规则。它去搜索了一圈它认为的对标产品，又帮我们总结了 6 条交互规则。这版总结没问题，我确认了让它继续。
接下来是长任务规则。它给的方案是每个任务都带着状态，从排队中、处理中、可预览，到已完成、失败、已取消，一共 6 种。session 关掉或者进程停了，任务自动中断，下次打开从断点接着跑。我同意这个长任务方案没问题。
然后它再次跟我确认哪些功能不做，一共列了 10 个。花字、字幕、转场、复杂特效、多机位自动切换、多人协作、云同步等等，第一版确实都不做。
但第 10 条有歧义，它写的是不承诺复杂的成片审美质量。
因为成片质量不只是审美层的质量，还包括成片本身的基础质量。口播顺不顺畅，内容有没有被强行截断，这些不是不做，而是底座，是必须达到的能力。
更有意思的是，它还写了一句，不承诺电影级节奏，也不用审美好坏作为唯一验收。
这一点我还是不同意。
因为电影级节奏、复杂的情绪曲线、商业广告级包装，这些根本不是功能。这也是大家经常犯的错误，连 AI 这一次问我们，也犯了同样的错误，把它当成了功能。
它们本质上就是自然语言理解和文本处理的事，说白了就是写视频提示词，做成 Agent Skill 就能解决。
经过这轮梳理，它又帮我们补了 9 个 Agent Skill，全部会包含在我们的插件里。我告诉它好的没问题，这个方向完全对了。
到这里它收集的需求已经足够多了，可以开始写 Plugin Spec，也就是这个插件的产品需求文档。这里要给它一点时间，过程可能会久一些。
好，写完了，我们打开看一下。
先看这个插件的一句话定位。通过完整本地视频编辑界面，让 Codex 使用 Agent Skill 生成、审查和修改可视化时间线，最终得到可继续手动调整，并且可导出为 1080P 或者 4K 的视频剪辑草稿或成片。
用户与情景这边，痛点也写得很明确。剪辑过程中，我们看不到素材片段范围和时间线，Agent 生成结果以后，也没有办法继续用基础的剪辑操作去修正。
所以我们要的核心结果就是一个可视化的视频剪辑编辑器。Codex 负责理解、规划和处理，编辑器负责素材浏览、播放、拖拽、剪裁、分割、删除、撤销这些基础操作。
至于最终形态，这里注意看好，是 Companion Web App。
前面我们介绍过插件的三种形态。基于这个插件功能的复杂度，Codex 帮我们选的就是第二种。
再往下就是主要的用户操作流程。这部分你一定要亲自审一遍，它其实就是用户地图，你跟着它逐条检查，你主要的业务流程是不是和它给你规划的一致。
再往下就是它帮我们规划的具体功能需求、交互需求、非功能性需求，还有数据与权限，这里就不展开了。这份文档到这里其实已经比较完整了。
刚刚你看到了我们整个的采访流程，基本上就是一问一答，再加上我反向给它纠正方向。
那在这个过程里，反向纠正方向这个动作非常关键。
如果你是新手，可能你还不具备纠正它的能力。但至少你可以凭经验、凭第一直觉告诉它，这个功能我到底想不想要。因为这决定了后面整体功能的走向，也决定了最后开发出来的这个插件，它的效果表现和功能能不能达到你心里的预期。
另外我在设计追问逻辑的时候，是按照四个象限来设计的。你知道它知道，你知道它不知道，你不知道它不知道，它知道你不知道。所以聊的这个过程当中，尽可能地坦白诚实，尽可能地把你想要的全部想法讲出来。
设计和拆计划这两步，我基本没怎么插手。
我们让 Codex 继续下一步，设计阶段。这个阶段它会调用 Plugin Interaction Runtime Design 这个 Skill，来帮我们设计插件的 UI 和交互。
因为上一个阶段它已经做过竞品调研，了解了这类产品的工作区布局和整体的排版，视频剪辑这个品类也确实非常常见，所以这一步它没有问多少问题需要我们确认，直接给了首版的建议。
左侧是项目素材库，中间是视频浏览区，右侧是 Agent 面板，底部是时间线。
风格上我们有两个主题可以选，一个叫极光，另一个叫纸墨。
先看极光，它分暗亮两个版本。我们现在看到的是暗色，全界面基本只有黑白灰，唯一的彩色是这条极光渐变，专门用来标 Agent 的操作状态。
这种主题适合暗环境里长时间盯屏的场景。监控面板、数据工具，还有视频音频这类创作工具，专业剪辑软件也都是深色的。
亮色版就是用同一套规则换浅色底，适合白天的办公环境，或者你就是不喜欢深色界面。
接下来是纸墨，先看暗色版。
纸墨的规则很简单，主墨干所有的活，正文、按钮、图表都是它。蓝黑墨专门标 AI，AI 写的、AI 在动的，一眼就能认出来。校对红只管删除、错误和驳回。
亮色版是纸墨的默认形态，米白纸面配黑墨，看着像印刷品，适合报表、文档、审核表单、后台这类白天的案头工作，截图放进 PPT、直接打印都可以。
根据它的建议，我们决定用 Neural Pro，也就是极光，同时我告诉它我要 Light Mode。
接着它让我们最后确认一遍风格包的默认主题和首版范围。这应该是它最后一个问题了，因为这个插件布局非常常规，几乎不需要再做进一步的调研。
我跟它说 OK 我确认，它就开始帮我们落实视频剪辑插件的设计文档。
好，设计文档已经生成了，我们打开看一下。先看基础信息，插件命名 Codex Video Editor，设计版本 0.1.0，形式是 Companion Web App。
再往下是设计概要 Design Summary，这里详细列了开发形态，这部分我建议你仔细都审一遍，发现问题及时反馈让它改。
至于剩下的部分，拆解好的设计任务、工作区布局的线框图，还有一些核心资产和组件，这里我就不展开了，我们先跳过。
这里插一句。刚刚看到的极光和纸墨这两个主题，是我提前设计好、预设进插件经理 1.0 的。
之所以这么做，是因为 Codex 自己开发出来的前端界面，我不说你也知道，丑得要命。
我尝试了很多次，最后发现提前把 UI Kit 的代码发给它，让它直接复用，效果会好很多。
这么做当然会牺牲掉很多的灵活性，只能开发一些固定范式的产品。但对我来说，目前完全够用了。而且说实话，我现在也开发不出什么跨时代的交互或者产品，所以固定下来的基础 UI Kit 和设计风格，对我来说足够了。
我们继续让 Codex 进入开发计划阶段。这个阶段它会用 Plugin Dev Planner 这个 Skill，来设计和拆解整个开发计划。
因为需求文档、设计文档，还有前面的调研都已经齐了，所以这一步完全不需要我们参与，它自己就能把开发计划拆出来。
好，现在拆完了，我们打开看一下。它一共帮我们拆了 90 多个 Task，每个 Task 关联的要求和验收标准也都列出来了，还有 Component Map，每个 Phase 要开发哪些 Task 也都完整地列在里面。
开发的时候方便追踪状态，新开一个 session 的时候，Codex 也知道它应该从哪个断点继续。
到目前为止，我们已经拿到了产品需求文档、设计文档，还有开发计划这三份文档。那接下来就是让它进入到正式写代码的环节。
那这一步我们有两种做法。
第一种做法就是直接让它开始开发。它会按照我们的既定流程和 Harness，顺着开发计划里的任务一个一个地去做，该做任务级的审核就做任务级的审核，该做 Phase 级的审核就做 Phase 级的审核。但这种方式中间可能需要你在旁边 stand by，比如遇到卡壳的地方，它会回来问你该怎么办。
那第二种方法就是用 Goal。我们写一套循环，让它从第一个任务一直干到最后交付，中间遇到的所有问题都由它自己想办法去解决。
为此我在插件经理 1.0 里写了一个 Goal Creator Skill，专门帮你写这条 Goal 的循环提示词。
使用 Goal Creator 这个 Skill，它会自动读取我们当前的项目状态和所有的项目文件，包括产品需求文档、设计文档、开发计划文档，同时它也会理解我们当前 session 里聊过的内容，综合下来按照我给的模板，帮我们写出一条完整的 Goal 提示词。
这条提示词能保证你从第一个 Task 一直开发到最后，实现插件开发完成、打包发布的完整循环。
接下来你只需要复制它，在输入框里粘贴发给 Codex，它就开始干活了。
整个开发过程其实就是按照我们已经设计好的流程，从任务级的小循环到 Phase 级的大循环，一路走下去，直到开发完成。
这个过程短则几个小时，长则几十个小时。我就不录屏了，也确实做不到，相信你也不想看，我们这里就先跳过。
OK，终于开发完成了。
这一次我们总共花了 15 个小时 20 分，累计消耗了 1098 万 Token。
比我想象中要快一些，我曾经遇到过连续跑 100 个小时以上的情况。
顺便说说 Token 这件事，因为这个数字看着确实有点吓人。
它消耗大是有原因的。审核员每次都是新开的会话，从零把文件重读一遍，第五步还要真装进宿主里真跑一遍。这两件事是整套流程最烧钱的地方，也正好是它最靠谱的地方。
模型这块我的建议很直接，上你手里最强的那一档。这套流程把规则删到只剩目标、标准和验收，中间全部留给模型现场发挥，模型弱一档，发挥就变成放飞。
还有一条，你的第一个项目别拿大需求练手。第一次的目标不是出成品，是摸清这套流程的脾气。挑一个小到不心疼的需求，比如一个只有单个面板的小工作台，五个阶段走完，你对每一步的预期都对上了，大项目才轮得到登场。
那现在 Codex 已经帮我们把插件装进了 Codex 的插件商店。点开 Personal，就能看到我们刚刚开发好的 Codex Video Editor。
MCP Server 也已经装好了。
再往下是这个插件带的 Skill，从口播剪辑、B-Roll 的自动选取，到情绪节奏、商业片，前面规划好的那些场景也全都写好 Skill 了。
看到了吗，这就是我为什么一直在说，你最好在沟通阶段就把需求聊清楚，仔细检查。不然下一次你有机会挑三拣四的时候，或者是改错的时候，那可就是 15 个小时以后了。
而且这次还算是快的。万一它开发个一两天，或者是你发现这个不满意、那个不如预期的时候，你就会非常难受。
好，接下来就到收菜的阶段了。
不过我提前说一下，开发完成之后，我其实还做了一些小的调整和改动。这个毛刺修正阶段其实是不可避免的，我们几乎不可能一次就开发出一个没有 bug、直接就能用的插件，所以这部分会比较细碎。
但话又说回来，现在 Codex 或者是 Claude Code，加上 GPT-5.6 或者 Opus 5，它们的能力已经非常强了，成品完成度极高，所以打磨这个阶段的工作量，其实可能也没有想象中那么大。
好，我们来测试一下开发出来的这个视频剪辑插件。
输入 open video editor，这就是视频插件的启动 Skill。当然，如果你在沟通的过程中，它识别到你要剪视频的意图，它也会用这个 Skill 自动帮你把插件打开。
插件启动后，它拉起了一个本地服务，这就是它帮我们开发好的插件，整个视觉就是我们当时选的极光主题。
整个工作区，左边是素材管理区，视频素材从这里上传。中间是播放区，用来预览和播放时间线上的素材。右边是日志和视频渲染导出区。下面是时间线，素材可以拖进来，等它剪完，我们也能在上面做一些基础的剪辑操作。
接下来我提前准备了硅谷 101 的一期播客节目，大概 75 分钟，把它上传，然后我们把它拖到时间线上。
然后我在对话这边告诉它，帮我给这期播客剪一个 60 秒左右的视频切片，方便我在短视频平台传播。
收到要求，它马上启动了 Commercial Structure Pass 这个 Skill。这也是它帮我们开发的、包含在插件里的剪辑 Skill 之一。
紧接着它就按这个 Skill 开始分析，怎么挑选金句，怎么做切片。
过程中我发现它要先用转录工具把视频转成字幕，那我马上告诉它，项目文件夹里我已经把字幕准备好了，你不要重复造轮子。
接下来它就通过字幕和里面的时间戳来判断该切哪个片段，该选哪个高光和金句。
好，现在已经完成了。
这边的日志记录了它做过的所有事情，那我们播放看一下效果。
到这里我们的开发环节就全部走完了，接下来是我的踩坑经验时间，一共三条。
先说需求这一块。
你必须在第一阶段，也就是需求收集和访谈这个阶段，把你所有的想法完整地表达出来，说清楚。
听好了，是你必须。
不管你说的是结构化的还是碎碎念，是有逻辑还是没逻辑，都没有关系。插件经理 1.0 会通过追问，逐条地帮你理清思路，最后形成一份结构化的产品需求文档。重点是你要先把想法说清楚。
大家也看到了，这次开发我们等了 15 个小时。而且这 15 个小时，还是在我没有加任何复杂效果和功能的前提下。如果一上来我们就要做一个大而全的项目，可能开发个 100 个小时都是挡不住的。
难道你要等 100 个小时之后，再去说这里不对、那里不对、这里有问题吗？
所以在沟通这个阶段把想法完整地表达出来，绝对不是一个可选项，而是必选项。先说全，再在这个基础上剪枝和调整。
然后是前端的审美问题。
前面我提过一句，Codex 从零开始写出来的前端，我可以向你保证，非常的丑。但如果你预设好主题，把主题的代码完整地交给它，让它在你框好的设计范围内，复用你的组件代码和动态效果，那它开发出来的前端其实还是不错的。
那主题这块我的做法是，用 Claude Design 帮我把主题设计好，代码以 UI Kit 包的形式下载下来，然后再内置到插件经理 1.0 里。
所以你不是只能用今天的极光和纸墨，你完全可以自己去做主题。
最后我们来说一下插件里面我们要用到的 Skill。
如果你开发的插件是 Skill Plugin，你不能指望 Codex 根据你的需求，直接把 Skill 给你写好。
就拿我们的这个视频剪辑工具来说，比如第一个 B-Roll Coverage，就是让它自动帮我们去选 B-Roll 的画面，和 A-Roll 进行穿插。
看起来它写的这个 Skill 还是挺像模像样的，但是你真正用起来，它给你写的就只能当一个架子，肯定不会完全贴合你现有的剪辑流程，或者是你的剪辑偏好。
所以最好的做法是，在开发需求的时候，涉及到 Skill 的，你直接就把你写好的 Skill 发给它，让它帮你放进开发的插件里。
这样一来，Skill 是你自己写的，你肯定是满意的，效果比它给你写的要好。而且这些 Skill 能反哺给 Codex，让它更加理解你要开发的功能和业务流程。
这其实就形成了一个双向的互补，你的开发会事半功倍。
说完这三个坑，还有一件事我想单独提一下，不是所有东西都该做成插件。
普通的网站、SaaS、移动 App、纯展示页，这些本来就不在这套流程的范围里，硬要套进来只会别扭。还有一条更实际的，如果你做的东西是要给不用 Codex 的人用的，那它就不该是插件。插件的前提是对方也在这个入口里干活。
插件真正合适的场景其实很窄，就是你自己天天在 Codex 里干的那些活，中间有一段非要切出去、开另一个软件才能做完。把那一段搬进来，收益立刻就有。剩下的情况，你多半还是应该老老实实做个 App。
回到开头那个问题。
如果所有的活都在 Codex 里干，我们还有没有动力再单独打开一个 App？
我做完这个插件之后的感觉是，至少对我自己来说，是真的没有了。
剪一条切片，我不用再切到另一个软件，也不用把素材导来导去。同一个对话里说一句话，编辑器就在旁边开着，它剪完我再手动调一下。这件事本身没多复杂，但省掉的那几次切换，是真的省掉了。
当然我也不想把话说得太满。这个插件还很粗糙，能迭代的地方非常多，跟专业剪辑软件更是没得比。我也不确定这条路最后会不会成为主流。
但做产品这件事的默认形态，我觉得可能真的要变了。以前你有一个想法，第一反应是做个 App 或者做个网站。现在你可以先问自己一句，这个东西是不是本来就该长在我天天用的那个 Agent 里面？
如果是，那你今天就可以开始动手。整套流程我已经拆完了，插件也放在 www.feicaiclub.cn 上，你照着走一遍就行。
🌟 以上，如果你觉得内容还不错的话，辛苦随手点赞、推荐以及转发吧。也欢迎加入废才俱乐部，这对我们是特别大的肯定和支持！
