夜雨聆风继续记录一下近期玩AI的经验和感想。
这段时间为了方便看油管视频，我用claude code搓了个chrome插件，主要功能是用ds一键总结视频概述、核心要点、启发。截止到今天，这个插件一共历经了18次迭代。
前期定需求阶段，我是用GPT和gemini同时去聊需求，敲定下来的MVP版本里，只做了一两个核心功能。不敢做多，因为vibe coding有时候真的不太稳定，特别是你用的不是顶级模型或者你的context不够多的时候，单次迭代的功能一做多，它就容易乱做。
等GPT把核心框架的内容定下来之后，我丢给了cc去做执行。第一版从定义需求到初版插件跑通，大概不到一个小时就做完了，非常快。
接着我开始迭代一些小细节：重构UI、提示词优化、输出内容排版优化等等，我自己当天用下来没什么大问题。
但是，当我后面实际用了两天，疯狂总结各种视频，我发现了其实还是有不少的问题：
1、部分视频字幕提取失败，尽管页面显示了字幕。
2、我的插件总结长视频有内容缺失。
我在解决第1个问题的时候花了蛮多时间，起初我预判这是一个小bug，没想到迭代了4个版本，还没有解决这个问题，反而影响到了我其他功能的正常使用。最后我不得不回退版本。
这个问题的核心原因是ISOLATED世界能访问DOM但读不到页面JS变量。考虑到它目前出现的概率不是很大，我决定暂缓这个问题的修复，并让cc把这些失败经验先总结到了memory里。
后面我在看一些长视频的时候，发现了第二个问题，我的插件只能提取到视频的前半段字幕，导致插件输出的总结内容是有缺失的，仔细看你才发现，它只总结了前半段内容。
这个插件是通过提取字幕内容丢给ds总结。所以这个问题最主要的原因是，我的插件只提取了视频前14000个字符，而一小时以上的视频字幕通常有几万字符——14000 可能只覆盖了前 10-15 分钟的内容，后半段的视频就被硬生生截断了。
我当天下午跑了一个中等版本去解决这个问题，然而效果很差，它不仅没解决，还把我的插件给跑崩溃了，我也快崩溃了。做饭的时候还满脑子在想怎么处理这个问题。
晚上的时候，我决定重开会话再试试，我认为是我的plan mode没用好导致的。新开窗口之后第一件事，就是禁止它再自由发挥，一定要先找到问题，并给出几种合理的解决方案，经过综合审查之后，等我确定了它再做执行，并且一定要尽量遵循最小改动原则。
这次就顺利多了，只用了一两个版本就解决了长视频的这个问题。这给了我很大的信心，接着我开始去做速度优化、流式合并输出等小优化。当然，在我关电脑前，还是让cc自己继续总结了下本次执行顺利的原因和经验。
到此为止，我的小插件又还能继续运行一段时间了。在问题得到解决的那天，我短暂地松了口气，同时我也更清楚，这不会是这个插件的最后一个问题，我vibe coding的难题，才刚刚开始。而vibe coding最大的难题是，我怎么让我vibe出来的东西，能够稳定的运行半年、甚至一年呢？这可能不是我通过持续去vibe获得经验就能解决的，还需要更多对技术的理解，以及时间，等待大模型变得更好也更具性价比的时间。
最后，浅浅分享一下从这段时间里提炼到的8点原则吧，其中最后一点我认为价值很大。
1. 从MVP起步，小步快跑
起初试图一步到位：长视频分块、分批并发、深度模式、流式输出全部一次写完。结果连跑都跑不起来。
晚上反其道而行。第一版只做一件事——让分块能跑通，不卡死。第二版再提速。第三版再加流式。第四版再调prompt。每版只解决一个问题，每版都是可用的。走了 4 个版本，每个版本之间的间隔不超过 10 分钟，但每版都经过了独立验证——改一行，测一下，确认通过，再改下一行。Vibe coding最大的诱惑是"反正AI写得快，一口气全写了吧"。但写代码的成本不只是写——调试、定位、回退的成本才是大头。每次只做一个功能，意味着每次只引入一个变量。出问题时排查范围从"6 个函数"缩小到"1 行改动"。vibe coding的快是用极短的验证循环替代猜测。
2. 改了五六版还不行，直接放弃当前会话
之前在一个死循环上反复修补：改退出条件、调overlap参数、换循环写法。越改越乱，因为每次改动都在一个已经不可靠的基础上叠加。
晚上的经验是：如果一个会话里改了超过 5 个版本还没搞定，说明当前会话的上下文已经被错误的假设污染了。AI会基于之前的错误分析继续给出错误的建议。这时候新开一个会话，重新描述问题，往往能跳出思维惯性。
3. 先让AI分析问题，再动手写代码
下午的prompt是："帮我加一个长视频总结功能"。AI直接开始写代码。
晚上的prompt是："分析一下为什么卡住了，给几个修复方案，不要着急执行"。AI先审查了全部代码，用具体数字推演了循环终止条件，发现了死循环，给出了方案A（最小修复）、方案B（稳健修复）、方案C（彻底重构），标注了推荐和风险。用户选了方案A，一行修好。
4. 修复做最小改动，避免上来就大改
核心原则：找到最小可复现条件，做最小改动。任何超出bug范围的改动都是在引入新变量。如果最小改动修不好，说明没找到根因，需要重新分析，而不是扩大改动范围。
5. 调参优先于改架构
晚上的速度优化：chunk 2500→4000，并发 4→6，tokens 600→350，merge tokens 2500→1800。4 个数字，零风险，时间从 85 秒压缩到 31 秒。
如果当时选择改架构来实现同样的提速——比如让Map和Merge重叠执行（pipeline）——需要改 `batchParallel` 引擎、加分批回调、改merge启动时机。代码量 10 倍，风险 10 倍，收益差不多。
任何优化先从参数开始。参数调到极限再考虑改结构。参数是数字，改不错。结构是逻辑，改错就是bug。
6. 做好版本管理，随时能回退
版本管理不只是"保存代码"——它是允许你大胆改的前提。知道能回退，才敢放手试。
7. 改了一个地方，记得检查相关代码
v1.4.1优化了prompt，让模型"保留视频中的具体例子、故事和比喻"。模型的输出确实更丰富了——但merge的max_tokens还是v1.3.1速度优化时压到的1800。内容装不下，写到一半被截断。
有时候只改了A，但B的行为依赖于A的输出。A变了，B的预设就可能失效。改完一个地方，花10秒想想有没有其他代码跟它有关联。prompt让模型多输出，就要检查token预算够不够。改了数据结构，就要检查所有读它的地方。
8. 不怕犯错，让AI帮你总结经验
下午改的版本其实基本全废了。但如果没有下午的失败，晚上不会总结出这些原则。
每次踩坑之后，让AI帮你回顾：这次哪里做对了、哪里做错了、下次怎么避免。然后把结论存到AI的memory里——下次新开会话，AI会自动带着这些经验上场。今天这篇文章里的工作流原则，就是下午踩坑、晚上总结、写进memory的结果。
用AI把每次踩坑变成可复用的经验，这才是vibe coding的长期复利。
