Mvv（小也）：为了看懂芒格的一个视频，我手搓了一个 Coze 插件，我是不是疯了？

Mvv（小也）：为了看懂芒格的一个视频，我手搓了一个 Coze 插件，我是不是疯了？ Mvv（小也）：为了看懂芒格的一个视频，我手搓了一个 Coze 插件，我是不是疯了？ Modified December 13, 2025 一、 缘起：听不懂芒格，我决定召唤 AI 最近在复盘查理·芒格（Charlie Munger）的智慧，找到了他临终前的一段珍贵访谈。但老人家毕竟年事已高，语速缓慢且口音含糊，直接听纯英原生肉有些吃力。我需要一份精准的中英对照逐字稿。 市面上的工具要么收费昂贵，要么翻译腔太重。作为一名 AI 时代的折腾党，我下意识的反应是：能不能用 Coze（扣子）搭建一个智能体来自动化解决这个问题？ 我想象中的流程很简单：上传视频 提取音频 扔给 LLM 循环翻译 输出。 但我万万没想到，为了这一个视频，我最后竟然被迫开发了一个插件。 但这三个小时的“疯狂”，让我真正看清了 AI Native 开发的未来。 二、 踩坑 Coze 第一阶段：Prompt的优化 我的第一个方案是纯 LLM 路线。我试图通过精心设计的 Prompt，让 bot 在 Coze 的工作流中自动循环处理字幕段落。 在这里，我撞上了第一个反直觉的墙。 在传统的思维里，我们认为给 AI 的prompt越详细、背景越丰富、约束条件越多（比如指定 JSON 格式、指定标点符号、指定语气），效果应该越好。 但实测结果狠狠打了我的脸： • 复杂的结构化 Prompt： 当我试图把任务拆解得非常细致（如下图），模型反而开始“发疯”。它会过度关注规则，导致输出内容缺斤少少，或者在循环中丢失上下文。 • 简单粗暴的一句话 Prompt： 无奈之下，我尝试“摆烂”，只给了一句最直白的大白话。结果？效果出奇的好！ 以下是我实验的结果 第二阶段：效率和tokens 解决了 Prompt，我遇到了第二个更棘手的问题：效率与稳定性。 当我对接长视频时，纯 LLM 的方案开始崩溃： 1. 速度极慢： LLM 是一个字一个字生成的（Token by Token），处理一小时的视频字幕，它恨不得也要跑半小时。 2. 不可控的“加戏”： 哪怕我勒令它“只输出翻译”，它还是时不时会冒出一句：“好的，这是为您翻译的内容...”，或者在结尾加个总结。 3. Token 浪费： 在 Coze 的循环节点中，这些废话不仅拖慢速度，还在疯狂燃烧我的 Token 配额。 三、 破局：Gemini 助我开发插件 翻遍了 Coze 的插件市场，没有找到能完美支持我这种“大段文本清洗+高并发翻译”需求的插件。 摆在我面前的只有一条路：自己写一个插件（Plugin）。 但我不想把时间花在查阅 Python 语法和调试环境上。 于是，我找到了优秀的外援——Gemini。 我是这样操作的： 1. 定义需求： 我告诉 Gemini，“我要在 Coze 里用，写一个 Python 代码，功能是接收一段乱七八糟的字幕文本，根据时间戳切片，并调用翻译 API，最后返回干净的 JSON。” 2. 生成代码： Gemini 思考了不到 1 分钟，直接给出了完整的 Python 代码，甚至帮我处理了边界情况（比如时间戳缺失）。 3. 阅读文档： 我把 Coze Plugin 的官方文档丢给 Gemini，让它检查代码是否符合 Coze 的部署规范。 4. 落地： 复制 粘贴 部署 申请 API Key。 整个过程，丝滑得像是在拼乐高，而不是在写代码。 以下是gemini的python代码 Python Copy async def main(args: Args) Output: 获取参数对象 params = args.params 1. 获取输入内容 这里的 'long text' 对应你在截图【上方】定义的变量名 source text = params['long text'] 2. 设置切分长度 这里设置为 500 字一切分，你可以根据需要修改这个数字 chunk size = 500 3. 执行切分逻辑 如果文本是空的，就返回空数组，防止报错 if source text is None: chunks = [] else: 使用列表推导式进行切分 chunks = [source text[i:i + chunk size] for i in range(0, len(source text), chunk size)] 4. 返回结果 这里的 key "result array" 对应你在截图【下方】定义的变量名 return {"result array": chunks} 四、成果与反思 三个小时后，插件上线。 原本纯 LLM 需要跑 20 分钟的任务，现在通过插件（代码逻辑）+ LLM（仅负责润色），缩短到了 3 分钟。 在这个过程中，我有几点深刻的感悟想分享给社区的朋友： 1. AI 不是万能的，"AI + Code" 才是。 不要迷信 All in LLM。在处理确定性高、计算量大的任务时，传统的代码逻辑依然是王道。Coze 的强大之处，正是它允许我们把 LLM 的灵活性和 Plugin 的刚性结合起来。 2. 门槛的消失。 以前开发一个插件，我需要懂环境配置、懂鉴权、懂部署。现在？我只需要懂 “提问” 。Gemini 充当了我的“技术合伙人”，填平了 Idea 到 Product 之间那道名为“技术细节”的鸿沟。 3. 真实的“降本增效”。 这就是万维钢老师说的“复杂世界的真实”。我们以前觉得搞开发很难，是因为我们要在“语法”和“环境”上磨损 80% 的精力。而现在，我们可以把 100% 的精力花在“定义问题”上。 最后： 为了看一个视频，开发了一个插件，我是疯了吗？ 不，我觉得我赚大了。 我不仅看懂了芒格，我还看懂了这个 AI 时代该有的生存方式： 把手弄脏，去实操，去造轮子。哪怕一开始只是为了解决一个小小的痛点。 现在coze商店已经发布了我的长文本翻译助手（需要长文档切分的代码，就在文中，需要自取） 一、 缘起：听不懂芒格，我决定召唤 AI 最近在复盘查理·芒格（Charlie Munger）的智慧，找到了他临终前的一段珍贵访谈。但老人家毕竟年事已高，语速缓慢且口音含糊，直接听纯英原生肉有些吃力。我需要一份精准的中英对照逐字稿。 市面上的工具要么收费昂贵，要么翻译腔太重。作为一名 AI 时代的折腾党，我下意识的反应是：能不能用 Coze（扣子）搭建一个智能体来自动化解决这个问题？ 我想象中的流程很简单：上传视频 提取音频 扔给 LLM 循环翻译 输出。 但我万万没想到，为了这一个视频，我最后竟然被迫开发了一个插件。 但这三个小时的“疯狂”，让我真正看清了 AI Native 开发的未来。 二、 踩坑 Coze 第一阶段：Prompt的优化 我的第一个方案是纯 LLM 路线。我试图通过精心设计的 Prompt，让 bot 在 Coze 的工作流中自动循环处理字幕段落。 在这里，我撞上了第一个反直觉的墙。 在传统的思维里，我们认为给 AI 的prompt越详细、背景越丰富、约束条件越多（比如指定 JSON 格式、指定标点符号、指定语气），效果应该越好。 但实测结果狠狠打了我的脸： • 复杂的结构化 Prompt： 当我试图把任务拆解得非常细致（如下图），模型反而开始“发疯”。它会过度关注规则，导致输出内容缺斤少少，或者在循环中丢失上下文。 • 简单粗暴的一句话 Prompt： 无奈之下，我尝试“摆烂”，只给了一句最直白的大白话。结果？效果出奇的好！ 以下是我实验的结果 第二阶段：效率和tokens 解决了 Prompt，我遇到了第二个更棘手的问题：效率与稳定性。 当我对接长视频时，纯 LLM 的方案开始崩溃： 1. 速度极慢： LLM 是一个字一个字生成的（Token by Token），处理一小时的视频字幕，它恨不得也要跑半小时。 2. 不可控的“加戏”： 哪怕我勒令它“只输出翻译”，它还是时不时会冒出一句：“好的，这是为您翻译的内容...”，或者在结尾加个总结。 3. Token 浪费： 在 Coze 的循环节点中，这些废话不仅拖慢速度，还在疯狂燃烧我的 Token 配额。 第二阶段：效率和tokens 解决了 Prompt，我遇到了第二个更棘手的问题：效率与稳定性。 当我对接长视频时，纯 LLM 的方案开始崩溃： 1. 速度极慢： LLM 是一个字一个字生成的（Token by Token），处理一小时的视频字幕，它恨不得也要跑半小时。 2. 不可控的“加戏”： 哪怕我勒令它“只输出翻译”，它还是时不时会冒出一句：“好的，这是为您翻译的内容...”，或者在结尾加个总结。 3. Token 浪费： 在 Coze 的循环节点中，这些废话不仅拖慢速度，还在疯狂燃烧我的 Token 配额。 第二阶段：效率和tokens 解决了 Prompt，我遇到了第二个更棘手的问题：效率与稳定性。 当我对接长视频时，纯 LLM 的方案开始崩溃： 1. 速度极慢： LLM 是一个字一个字生成的（Token by Token），处理一小时的视频字幕，它恨不得也要跑半小时。 2. 不可控的“加戏”： 哪怕我勒令它“只输出翻译”，它还是时不时会冒出一句：“好的，这是为您翻译的内容...”，或者在结尾加个总结。 3. Token 浪费： 在 Coze 的循环节点中，这些废话不仅拖慢速度，还在疯狂燃烧我的 Token 配额。 三、 破局：Gemini 助我开发插件 翻遍了 Coze 的插件市场，没有找到能完美支持我这种“大段文本清洗+高并发翻译”需求的插件。 摆在我面前的只有一条路：自己写一个插件（Plugin）。 但我不想把时间花在查阅 Python 语法和调试环境上。 于是，我找到了优秀的外援——Gemini。 我是这样操作的： 1. 定义需求： 我告诉 Gemini，“我要在 Coze 里用，写一个 Python 代码，功能是接收一段乱七八糟的字幕文本，根据时间戳切片，并调用翻译 API，最后返回干净的 JSON。” 2. 生成代码： Gemini 思考了不到 1 分钟，直接给出了完整的 Python 代码，甚至帮我处理了边界情况（比如时间戳缺失）。 3. 阅读文档： 我把 Coze Plugin 的官方文档丢给 Gemini，让它检查代码是否符合 Coze 的部署规范。 4. 落地： 复制 粘贴 部署 申请 API Key。 整个过程，丝滑得像是在拼乐高，而不是在写代码。 四、成果与反思 三个小时后，插件上线。 原本纯 LLM 需要跑 20 分钟的任务，现在通过插件（代码逻辑）+ LLM（仅负责润色），缩短到了 3 分钟。 在这个过程中，我有几点深刻的感悟想分享给社区的朋友： 1. AI 不是万能的，"AI + Code" 才是。 不要迷信 All in LLM。在处理确定性高、计算量大的任务时，传统的代码逻辑依然是王道。Coze 的强大之处，正是它允许我们把 LLM 的灵活性和 Plugin 的刚性结合起来。 2. 门槛的消失。 以前开发一个插件，我需要懂环境配置、懂鉴权、懂部署。现在？我只需要懂 “提问” 。Gemini 充当了我的“技术合伙人”，填平了 Idea 到 Product 之间那道名为“技术细节”的鸿沟。 3. 真实的“降本增效”。 这就是万维钢老师说的“复杂世界的真实”。我们以前觉得搞开发很难，是因为我们要在“语法”和“环境”上磨损 80% 的精力。而现在，我们可以把 100% 的精力花在“定义问题”上。 最后： 为了看一个视频，开发了一个插件，我是疯了吗？ 不，我觉得我赚大了。 我不仅看懂了芒格，我还看懂了这个 AI 时代该有的生存方式： 把手弄脏，去实操，去造轮子。哪怕一开始只是为了解决一个小小的痛点。 现在coze商店已经发布了我的长文本翻译助手（需要长文档切分的代码，就在文中，需要自取）