私の碎碎念, 鞭笞下の逃窜

序

初秋的凉风总能让人舒适而清醒。这几天，蒙古的沙尘随着西伯利亚的寒潮，不可思议地到了广东，让春天又往后捎了捎。期间的零星小雨，又让我进入了极度愉悦的状态, 探索欲从未有过的高涨。

晚饭后翻看笔记本，发现上个月做完的 “ Unsloth 微调 deepseek ”的笔记还未进行总结，而实施过程中的思考和要点似乎已经开始以往。便想着写一篇博客进行记录和总结。但在实际写的时候，总有将笔记本插入文章里的冲动，不然总觉得说不清楚；这点可能是源于我喜欢“数形结合” 、 “图文结合”，想让听我讲述的人化身为我，完全理解我的想法的病态完美主义 (而这种完美主义，也不时给自己造成一些困扰)。可是，在查看插件市场和 google之后，发现并没有简便的方法，比较好的方案看起来也是问题多多：要么需要用到 github，要么需要用到 ftp工具，还要每次自己在插入时，写大量的代码并维护什么 id 。

比如：

先写完微调笔记总结再说，完成就是完美完成。

但当我在 Obsidian 中写到一个函数的解释时，习惯性按下 " command + option + , " (自己配置的 gpt 插件唤醒快捷键) 的瞬间，我看到了 “ help ”

Anything I could help you with, my master ?

思维的诞生

显式地用 LLM 达成自己需求的契机就此到来。与生成 ppt、报表、以及绘图不同，这些内容都是在已经很熟练的基础上，去“更快速”解决问题，而这一次，则是真正的从“〇”开始，探索陌生的领域；让 LLM 做探索图中的 Copilot。

收益和代价的评估

这几乎就是完全为了满足自己好奇心的探索而发起的需求。就目前目前看来，真正能用到的次数其实是有明确上限的，而且也有替代的方案。而完成之后，获得的收益就更加有限：一个随时可以被复制的插件、一段使用 AI 编程项目的经历、一个记录过程的视频、一篇狗屁文章以及好奇心被满足后的淡淡慵懒。

明显，一篇狗屁文章已然出现，就意味着已经做、并且已经做完了这件事情。

那么，代价是什么呢？与当初悲观的估计截然相反，仅仅是不到 1 小时的时间，和一瓶 500ml可乐的花费就达成这个“成就” 。

可行性的依据

正如上文和标题所说的，这是个从 “〇” 开始的项目。我们将〇和完全加上引号有两层意思：

这其实非真正的完全从〇开始，因为我们是有比较强的编码基础的，也略懂程序运作的原理，但不懂 wordpress 插件的开发；
之前也写到，即使没有这个插件，我们也有解决办法，只是非常麻烦。也就是说，这个插件只是代替我们完成了重复的作业；这是典型的 RPA(robotic process automation) 擅长的业务场景；
当然最重要的是：我是产品经理，且极具动力；

基于这几点的考量，让这个项目对于自己而言有了近乎 100% 的可行性。自然，下一步确定解决方案，以及这个插件的形态。

理想的解决方案

这个插件理想中应当具备以下几个特征：

能够 100% 保持 jupyter notebook 生成的 html 笔记的样式；
能够兼容不同 wordpress 主题，方便阅读；
能够像其他插件一样在文章编辑器中以插入 shortcode 的形式使用 (编码过程中了解到的名称, 详见下图)；
能够有个管理后台，方便笔记的增、删、改、查；


在编辑器中使用short code	在实际页面中有特定的样式

设想中，这里最理想状态的是：直接上传原始的 ipynb 文件，然后再由插件进行解析展示，但是看了上文的jupyter-notebooks-in-wordpress，发现需要修改 wordpress 的主程序文件，而且 blog 作者也无后续的进展，想必是遇到了什么问题，或者鸽了。

诚然，据我对 jupyter 的了解, 我们也可以设想通过插件去安装 python 环境 + jupyter ，然后再通过 nbconvert 去实现设想中的“最理想状态”，但那不免有“过度设计”的嫌疑。

实现与解析

成品的视频展示

这里是最终的成品，并且已经实际运行在这个博客当中。当然，还有很多可以优化的点，如实际展示的样式，展开缩放的交互，以及一些安全性的问题，文件的存储等等等等。但是，就上文提到的必要功能而言，似乎可以说已经完美达成。而在此之前，我对 wordpress 插件的最深入的了解就是：它存放在 wordpress 的 plugins 文件夹中。

Trae编写插件过程

ipynb 源文件下载:
Download

相比结果，“过程更重要”

工作结果导向，但探索时的过程复盘更显珍贵。

工具的选择

AI 代码 IDE的选择国际版 Trae 主要原因是目前它对我而言是最友好的。此前，几乎在 Cursor、Windsur 或者 Vs code + Cline/RooCline/Continue 的组合方案出来的第一时间就进行了尝试，而当时它各有各的问题，例如 Cursor 付费困难， Cline则是奇怪地在我的 PC 和 Mac上都会莫名卡死 (现在来看应该是当时选择了用过于火爆的 deepseek)，而且对 ollama 的支持非常非常差，基本断绝了本地化部署的可能性。此时，稳定而且免费 Trae 国际版就显得鹤立鸡群了。

注意一定选择国际版，从目前使用各个 AI IDE的情况来看，模型支持的上下文长度能够极大地影响编码体验；而 Trae 国际版支持 Claude 3,5 sonnet, 过内版本由于合规问题不支持。

这里需要强调的是，这里的 “免费”及其重要。如果你之前有使用过 Cursor 、 Cline等等，或者看过视频博主的演示，就会发现实现一个不算大的功能，IDE对 tokens的消耗量都是非常惊人的，这意味着巨大的成本。

过程的解析

此次我们使用用 Trae 的 Chat 模式，该模式可以一步一步执行、修改，会更有掌控感 (如果选择使用 build 模式，则可实现和 Cline 一样的全自动模式）。

整体的思路是：⒈构建一个合法的插件整体结构 → ⒉尝试添加一个功能 F(i)同时保持之前的功能不被改动 → ⒊测试到功能F(i)直至满足要求 → ⒋重复 (⒉) 、(⒊) 直至所有功能添加完毕 → ⒌完成

这里将对几处比较关键的 prompt 阐述当时的思路

Prompts起手式：

我不懂php和wordpress插件开发；但我希望能够开发一个插件，让我能够都将jupyter notebook生成的html文件保持原有样式插入到wordpress文章中。我该怎么做？

这里思路是明确自己对插件开发的陌生，并且提出基本的要求(插入html文件)，经过后续的测试。所有的主流模型，都能够给出一个合法的插件主文件以及目录

这提到两个很重要的概念【主文件以及目录】，后续查阅资料结合已有经验：其实主目录就是当前的目录，主文件就是当前新建的，头部带有这些字段的 php 文件，这里的字段最终将作为插件的介绍在插件列表页展示。后续开发完成之后，只需要将整个项目文件

1
2
3
4
5
6

/*
Plugin Name: Jupyter Notebook Embedder
Description: 在 WordPress 文章中嵌入 Jupyter Notebook HTML 文件
Version: 1.0
Author: Your Name
*/

我们可以注意到(~~真的可以注意到~~)，在它给出主文件中有个 preg_match 函数它似乎在做正则匹配，这意为着它的做法和我们上文提到的思路是不同的。因此，我们在应用了他的代码后，后续立即要求修改开发方向。

如果不修改，我们后续将陷入无穷无尽的样式兼容的修改中，而且不能保证所有的 html 笔记都能被正确展示（甚至不能展示）。后续作死的测试证明了我们要坚守一个原则：不要去尝试解析任何形式的文本，包括 plain/rich text、 html、json等等。

调整技术路线：

你似乎尝试读取html的内容。我希望使用iframe的方式实现，以避免样式错乱和文本解析的问题。首先保留你上文提到的shortcode用法：[Jupyter path="http://your-site.com/path/to/notebook.html"]，但html格式的笔记，需要上传到单独的文件夹 /wp-content/uploads/jupyter-notebooks/ 。至于iframe实现方案，目前我是这么做的：在文章中插入<iframe id="finetune_deepseek" style="border: 1px lightgrey solid;" src="https://10ccc.cc/wp-content/uploads/jupyter-........

虽然包含 Claude Sonnet 在内的大模型的上下文已经足够长，而且语义理解在我们表述清晰的时候也已经很准确，但这里仍旧建议显式要求需要保留的功能。Prompt 中的代码原理来自这个 blog 。

修改部分功能

修改功能时，需要明确修改功能的位置，以及简单的示例，这样能保证模型达到及格线后，能准确修改对应位置的功能。

增加新模块

【Workspace】好的，现在我们一起为这个插件添加后台管理功能。我希望后台管理功能有以下特性：

在我们启用这个插件后，在 wp-admin 页面的左侧主菜单栏的尾部会有一个名为 “Jupyter Notebooks” 的菜单，点击之后可以进入本插件的管理页面；
这个插件的管理页面类似文章管理页面，包含一个“上传笔记”按钮，点击之后可以像上传媒体一样，上传 html 格式的笔记文件到 /wp-content/uploads/jupyter-notebooks/ 中，需要有上传进度，上传成功之后在按钮下方的笔记文件列表展示；
笔记列表用于展示上传的 html 笔记，列表字段包含序号、名称 (即Jupyter Notebook ID)，上传时间、操作。其中操作字段包含删除、和下载两个功能。如果点删除，则将 /wp-content/uploads/jupyter-notebooks/ 中对应的笔记文件删除，点击下载则将对应的文件进行下载；
列表需要有分页功能，每页展示 20 条的笔记记录

好，现在保持当前已有功能不变动。我们开始为iframe增加“高度调整”功能。我希望文章中通过short code插入的html笔记初始展示高度是300px，在iframe右上角内侧，有个大小适当、位置相对iframe固定的按钮，点击之后能够将笔记完整展示，这个按钮的文字在iframe未展开时是“展开”，当iframe已经展开时，是“收回”。

这里将整个 Workspace 添加到上下文的功能是为了保持功能的一致性。注意 prompt 在描述模块时包含了以下元素：模块的入口、模块的布局、模块的功能、以及想要的元素的UI交互。这其实就是在写功能产品文档。而且，可以预见地，如果想要通过 AI 代替程序员完成一个稍具规模的产品，假设原本所需的文档规模为 1 ，那此时需要的规模可能达到 2 或 3 甚至更多。

后记

事实上，上文中提及的一切，都仅仅是本次尝试“成功的一面”。在文章背后，那次我自己充当小白，放任Trae自由发挥的实验结局则是以失败告终。因为它陷入公认的的禁忌之中：

不要去尝试解析任何形式的文本

其实，这实际也不是 Trae/Cursor 自己的问题，根源在模型。似乎无论各个编辑器所配置的模型上下文有多少，他们在解决代码的问题时，似乎都倾向于“破坏性的创造”：用临时的方案代替全局的思考，然后在缺乏正确引导的情况下，在死胡同里面一次次撞南墙。

在我看来，这似乎已经不是增加模型支持的上下文长度可以解决的了，即便是像 Trae 已经配置了Claude sonnet，仍然如此。后续如果配置 opus 呢? 我仍然抱悲观的态度。

整体而言，近期对 AI编辑器的使用时，感觉：

小模块 get √：目前各类的 AI 编辑器能够在小功能、小模块上的表现优秀，比如编写一些基本的函数上已经非常厉害；但是，有过如果要修改，无论是让 AI 修改还是亲手修改，都会非常头疼；
大项目：我并未尝试，但根据各个是视频网站的 up 的测试来看，也能较为准确够修改一些功能，但似乎比人更容易写出屎山代码；而这，意味着修改和订阅费用资金的消耗；
使用这类工具时，如果我们本身是专家，那么能够很好地完成任务；反之，如果真的是小白，那你和你的 copilot ... 啧啧，它就变成了 tokens 收割机（~~我似乎闻到了金钱燃烧的味道~~）；
。。。。。。哎