2025-08-09 21:30:37
简单总结Vibe Coding：人利用AI生成代码完成大部分的软件开发任务。
我个人理解Vibe Coding的本质就是开发工作中的一种新的协作关系 —— 人专注于差异性工作，把能交给大模型做的工作尽量交给它去完成，充分发挥AI的可塑性、高效性等。
随着大模型底层基础能力的飞速迭代（例如Qwen3-Coder），AI的能力范畴正在变得越来越大，Vibe Coding的发展趋势就是自底向上蚕食程序员的工作范畴。
以Cursor和Claude Code为代表Vibe Coding工具正在快速迭代，Vibe Coding的架构是时刻在演进和变化，我根据自己的理解比较理想化给出Vibe Coding的分层架构，与上面发展趋势图相对应，Vibe Coding发展到最后就是这张图只剩下蓝色框框没有其他颜色🥳。
关于Vibe coding的八卦，一图胜千文，其实目的还是想让好奇AI Assistant Coding的人知道它的优缺点，以及需要注意的事项。
我总结了主流的几个AI Code Agent的架构：
综合来看，当下AI Code Agent的技术架构基本上都是类似的，主要的差异就是工具、策略等方面选择的差异。
以Cline架构为例对AI Code Agent架构进行管中窥豹
除了基础模型造成的差异之外，Cline建立的AI Coding的差异化竞争力主要在：
我们更进一步来拆解这些优势：
| 竞争力项目 | Cline | Cursor | RooCode |
|---|---|---|---|
| Human in the loop | ✅ | ✅ | ✅ |
| MCP生态支持 | ✅ | ✅ | ✅ |
| 工具生态 | AST | RAG | AST + RAG |
| 混合上下文管理 | Context Management | Automated Context Management + Context Priority Management | Intelligent Context Condensing |
| Agentic AI Model | ✅ | ✅ | ✅ |
| Model | ❌ | apply edit 小模型 | ❌ |
AI Code在卷哪些技术一目了然。
Vibe Coding 大致上有两种使用方法：
实践中，我发现方法1可以极大释放人力，有的时候AI给出的结果超出预期，唯一存在的问题就是人对于代码的信任度。方法2效率提升不如方法1，但是基本的代码实现以及项目进展情况人能够掌控，能够有效的避免AI Coding的几个问题：
基于上述经验，我对Vibe coding的采取的是不信任的态度，原子化任务保证我能够review检查代码（神仙也很难在2万行代码的PR里面准确挑出2-3个bug）。同时，如果是比较明确的任务并且已经有参考（例如已经有sqlite实现了，让AI完成mysql的实现）我就会采用方法1来提升效率。
另外，还有一种方式（我使用相对较少）—— 结对编程的方式，即向AI描述问题或者需求，然后AI规划方案，人来修改或者补充形成 todo list（plan），然后由AI实现。
最后，总结一下Vibe Coding的个人思考：想写一个demo直接扔给AI自动完成，当下的AI已经能够保证试错成本和效率了。想写一个生产使用的软件，自己把控方案设计和技术架构让Vibe coding作为帮助生成代码的工具，同时对Vibe coding始终抱着不信任的态度，时时review、处处检查。
由于每个人使用AI Code工具以及编程习惯都不一样，所以有一些关键原则是需要注意的，其他可以自由发挥。
<|im_start|>assistant<tool_call>{"name": "xxx"来控制工具调用的模式（自动、必需、指定等）；能够跨多个文件读取和修改代码的 AI。用自然语言描述更改，Agent 会执行这些更改。
定义 AI 行为的自定义指令。设置编码标准、框架偏好和项目特定约定。
持久存储项目上下文和过往对话中的决策。在未来的交互中自动引用。
对代码库进行语义分析。支持代码搜索、引用查找和上下文感知建议。
在代码生成过程中提供给 AI 模型的信息。包括文件、符号和对话历史。
Rule的设置是为了让Cursor了解项目结构以及开发约定，包括：
Rule编写时应该注意：
rules 结构示例如下图所示
另外一种Rule设置方法（来自Cline），Task Manager + Todo List的方式管理active context：
Task Manager的方式使用AI Code工具是比较进阶的使用方式，项目开发周期的缘故我还没生产实际中使用过，后续再研究和分享。目前这块有一些比较不错的实践经验可以参考：
我会在项目的docs目录中放置所有的项目相关的问题，包括技术选型、架构设计、模块说明、部署架构、使用手册等等，这样可以让人和AI都能够及时了解项目详细情况，一般修复问题或者新增feature的时候，我会将对应的文档添加到上下文中（@docs/xxx.md），帮着Agent能够更好的完成任务。
随着项目迭代和演进文档需要及时更新，不然会对AI形成误导导致无法正确地完成任务，所以我会形成固定的文档更新工作流。
2025-08-02 21:48:45
趁着暑假，跟家人一起去大阪和京都，有一些见闻和感受想记录一下
有这样一句话「你不买东西，去大阪干吗？」，大阪的心斋桥是一个购物的天堂，这里有性价比极高的药妆店，数码店，让我这种物欲很低的人都忍不住买买买。
不得不说心斋桥是一个可以放大人物欲的地方。
还有一个关于物的感受，除了经常听说的精致、匠心之外，我在大阪生活方方面面碰到的物品，无论是菜单、点餐机器、硬币机器、地铁JR闸机等等，都有很重的使用痕迹，大多磨损很厉害，但是无一不是设计精巧、指示明晰、使用顺畅。这些物品极大释放了人力，这一切物品和工具让我看到了一些视人为人的意境，在这里物最重要的工具属性得到了充分发挥，人在物的帮助下能够悠闲且毫无顾忌的席地而坐，饮一杯自动贩卖机啤酒。
留心查找这些物品的信息，其中不乏美的、格力等产自中国的东西。很可惜，在国内难得看到这样视物为物、视人为人的松弛和安逸。
在来日本之前，对日本的「跪式服务」早有耳闻，冷漠、社畜甚至变态也国内也多有提及，但是他们又能说出「山川异域，风月同天」这种令人神往之语，所以我对他们的人都很好奇，这次旅游用心观察了一下。
日本人干活总是有种不急不慢的感觉，刚到大阪的第一天我们就奔着一家很有名神户和牛店去了，因为没有预约防止没有位置，我们5点不到就到店里了，整个店很小巧，最多能容纳6个人，我们在翻看菜单的时候一个刚刚来上班的店员，推门而入的时候拖着长长尾音跟店里忙碌的师傅打招呼“はい～～”，左右摇晃的双肩包，踮着脚从我身后欢快走过。在帮我们摆放和牛的时候，专注、细腻，wasabi的形状都特意调整好……
地铁上，偶尔看到男生打扮得很日系动漫，不多但挺精致，我做公共交通期间之间到过一次，打扮很像进击的巨人里面的艾伦，上衣的装饰以及裤子镂空的细节都能看出非常精致用心（P.S. 日本人对在公共空间拍照时很敏感的，所以只能用苍白的语言形容这种精致了）。
大部分日本女生的装束都是可爱风精致感觉，年轻女生一般是前面刘海微微卷一下，打扮很精致，脸部会抹点儿腮红，除了这个印象其他跟国内其实差不多。
还有一件关于人的事情值得分享，在大阪我发现了一家我超级喜欢的咖啡屋，早上10点的时候可以见到各式各样悠闲本地人，有随手放下电脑包工作的中年大叔、有点了杯冰水悠闲看报的老人、有热烈聊天的年轻女性等等。Cash Only的买单要求能够让你深刻的体会到日式服务的精神，买单的是一位头发全白的老奶奶，精神头非常好，每位进门的顾客都会热情的打招呼，熟识的老顾客还会闲聊上几句。你坐下用餐的时候，她会站在门口发发呆，时不时往店里眺望几下，防止有顾客需要帮忙的地方。
店里的美式咖啡非常不错，喝惯了星巴克之类的深烘的焦苦味，突然喝到带有回甘和花草味道的手磨咖啡会觉得非常新奇，思来想去估计是因为国内的咖啡于我而言是牛马续命的药水，这家咖啡屋的美式才是生活的享受。然后再配上一个抹了薄薄一层果酱的吐司，这个吐司被放进烤箱烘烤过，表层微微泛黄香脆，里面这是吐司面包软软的质地，咖啡的回味再加上吐司酥软、果酱的甜美，确实是难得的口腹之欢。店员会热情看着你吃东西，嘴里一直重复着「どぞ， どぞ......」，看到你享受美味的时候会很开心的默默走开。
我低头吃东西的时候，余光无意间偏见站在门口老奶奶，看我吃得很香的样子，她嘴角上扬比我还开心。老奶奶不会英文，最后我们去付钱的时候她看我要掏卡，最近轻轻念叨着「cash only, cash only」，然后在指示牌子上比划着，神情略带歉意，我恍然赶忙拿出现金递给她，她笑逐颜开接过去，嘴里念叨着什么，指了指账单，然后拿走了1000的纸币剩下的返回给了我。我当时没注意，还是家人提醒，200多的零头老奶奶没收。再后来，我们又去了两次，都是这个老奶奶收的钱，每次都只收我1000块，零头都去掉了，或许是表达cash only歉意，或许是看着小伙子顺眼，或许她就是喜欢顾客喜欢吃他们的东西，或许她就是喜欢看到世界各地的人。
本来想总结思考一下，日本的精致、安静、悠闲带来的感触和对比的。
后来，有点意兴阑珊，去思考这些的意义是什么呢？对两个完全不同的文化、制度的国家评头论足又有什么意思呢？它们仅剩相同的地方大概就是相似的面孔和历史文化渊源了吧！
于我而言，我唯一记住的就是，它是一个难得让我悠闲和松弛的地方。它的漂亮和友善或许可能是他们天生如此，又或许是因为我是一个匆匆游客，又或许是因为我个人的自我感动。
总之，人总会对喜欢的东西才会格外用心
2025-07-06 16:14:18
延续上一篇关于AI的思考，作为程序员最关心的编程范式的变化，我打算看一下业界有哪些思考和趋势。
这篇文章主要是围绕Tesla前AI总监Andrej Karpathy关于软件3.0的观点展开的。
Andrej Karpathy提出软件开发的演进过程可以被划分为三个主要阶段，即Software 1.0、Software 2.0和Software 3.0，它们代表了编程思想和实现方式的根本性转变。
| 特性 | Software 1.0 (传统软件) | Software 2.0 (AI 软件) | Software 3.0 (LLM 驱动的软件) |
|---|---|---|---|
| 核心思想 | 明确的指令 (Explicit Instructions) | 从数据中学习 (Learning from Data) | 与通用模型对话 (Interacting with a General Model) |
| “代码”是什么? | 人类编写的源代码 (C++, Python) | 神经网络的权重 (Weights) | 自然语言提示 (Prompts) |
| 如何“编程”? | 程序员在开发环境中编写代码 | 工程师用海量数据训练模型 | 用户通过对话、提问、下指令来引导模型 |
| 开发者角色 | 软件工程师、程序员 | 机器学习工程师、数据科学家 | 所有人、提示工程师、AI 应用开发者 |
| 典型例子 | 计算器、操作系统、数据库 | 图像识别、语音识别、推荐系统 | ChatGPT、Copilot (代码助手)、Midjourney (AI绘画) |
| 优点 | 精确、可靠、行为可预测 | 擅长处理模糊、复杂的模式识别问题 | 开发速度极快、门槛极低、知识广博 |
| 缺点 | 僵化、无法处理模糊问题 | “黑箱”，需要海量数据，可能产生偏见 | 可能会“幻觉”(一本正经胡说八道)、依赖大公司、有安全风险 |
这是我们最熟悉的软件开发模式。程序员使用Python、C++等形式化的编程语言，一行一行地编写明确的指令来告诉计算机如何执行任务。例如，特斯拉自动驾驶系统中就包含大量的C++代码。这种模式的特点是逻辑精确、行为可预测。
Software 2.0的“代码”不再是人类编写的指令，而是神经网络的权重。开发者通过收集和标注海量数据，使用梯度下降等优化算法来“训练”一个神经网络模型。模型从数据中自动学习规律和特征，例如用于图像识别的AlexNet。在特斯拉自动驾驶系统中，神经网络就逐渐取代了传统的C++代码。
这是最新的范式，其核心是大型语言模型（LLMs）。开发者不再编写传统代码或训练专门的模型，而是通过自然语言（如英语）编写提示词（Prompts）来与一个强大的、预先训练好的通用LLM进行交互，引导它生成所需的功能或代码。例如，要完成一个情感分类任务，开发者可能只需向LLM提供几句话的描述和几个示例即可。
Software的三个阶段是演进关系而非完全取代。Software 1.0是基础，提供精确控制；Software 2.0解决了1.0难以处理的模糊和感知问题；而Software 3.0则建立在2.0的成果（LLMs）之上，将编程的接口从形式化语言转变为自然语言，极大地降低了门槛。它们之间的核心区别在于“代码”的形态和“编程”的方式：从人类编写指令，到用数据优化权重，再到用语言引导模型。
这个变化最酷的地方在于，开发工作的核心，从“告诉电脑怎么做”变成了“告诉AI我想要什么”。在AI的加持下，开发者不用再苦哈哈地抠每一行代码逻辑了，只需要写出清晰、全面的目标说明（Specifications）和提示（Prompts），告诉AI我们期望软件能实现什么功能。然后，AI代理就会像个得力助手，把这些想法转化成我们能读懂、能运行的代码。
所以你看，开发者的角色也变了！程序员不再是单纯的“码农”，而更像是“AI协调员”或者“模型训练师”。最重要的技能也变成了如何拆解复杂问题、做好系统设计，以及一门新学科提示工程（Prompt Engineering）。这不只是简单地提问，而是要学会如何像一个精准的指挥家一样，用最恰当的指令、上下文和约束，引导AI产出我们想要的结果。
当下的AI Coding Assistant的身影现在几乎无处不在，贯穿了整个软件开发的生命周期：
不过目前AI Coding也不是完美的，存在很多问题：
所以目前为止Software 3.0目前更适合作为工具箱中的辅助工具，而非完全取代传统的代码编程。
Andrej Karpathy关于软件3.0的讨论中提到它不仅仅是一个技术更新，更是一场深刻的范式革命。
社区普遍认为，Software 3.0最大的意义在于“编程民主化”。由于编程语言变成了自然语言，非程序员也能参与到软件创建中，极大地拓宽了创新的来源。X平台（原Twitter）上的讨论热烈，用户强调“English is coding”（英语即编程）的理念。对于程序员而言，工作重心从手写代码转向了设计高效的提示（Prompt Engineering）、验证和审计AI生成的代码以及管理整个AI系统。
Andrej Karpathy将LLMs比作1960年代的早期计算机或是一种新型的操作系统。这一观点在社区中获得了广泛认同。LLMs成为了一个可编程、可组合的基础平台，开发者可以围绕它来构建各种应用，而不是一切从零开始。
目前大家普遍的共识是，Software 3.0强调的是人机协作，即“部分自动化”（Partial Autonomy）。Karpathy提出的“Autonomy Slider”（自主性滑块）概念被反复提及，即用户可以根据任务需求调整AI的介入程度。AI负责生成，人类负责验证，形成高效的“生成-验证”循环。
总而言之，软件3.0不仅仅是工具上的更新换代，它更像是一场关于思维、流程和团队协作方式的革命。公司需要赶紧建立起新的管理规则，培养团队和AI打交道的能力，还得花钱投资一些能管好AI风险的技术。说到底，未来的赢家，不是那些拥有最强AI的人，而是那些最懂得如何与AI共舞、能建立起高效、安全、负责任的人机协作体系的团队和个人。这，才是这场变革中最激动人心的部分！
2025-06-29 21:13:33
经过了将近一年时间与AI的密切接触，论文研究、AI应用使用、AI应用开发，对AI逐渐有了一些自己的思考：我笃信一个原则「抛开时间来看，人能学会的，AI一定可以学会」。
这句话背后的一个核心哲学和科学思想是计算主义。计算主义认为，认知过程，包括人类的学习，可以被看作是一种信息处理过程，类似于计算机的运算。
如果我们将学习看作是一种通过处理信息、识别模式、建立联系并调整行为以适应环境的过程，那么从计算主义的角度来看，只要这些过程能够被精确地描述和编码，AI就可能实现它们。
以下关于AI的思考都是基于这个原则。
作为程序员群体的一员，距离AI是比较近的也是感受最强烈的 —— AI真的很厉害，无论是coding、设计偶尔甚至有接近阿里系P5水准的表现（单指 Claude和OpenAI）。这无疑增加了程序员的一种焦虑：我们可能会被AI替代了，近期针对外包员工一些管理动作可见一斑。
那么，程序员真的会被AI替代吗？
如果计算机技术还是在当前的体系下发展的话，虽然会剧烈的影响程序员的工作，但是我认为AI无法替代程序员。道理很简单，因为在当前的计算机技术体系下AI无法学习和预测一件事：多样性（包括人的多样性、需求的多样性、现实的多样性）。举个职场人都会心一笑的例子：
AI真的仅此而已吗？
刚刚我论证AI无法学习「多样性」的前提是在当下计算机软件应用开发体系下的，如果以后没有计算机软件应用了呢？如果新的软件形态的产生了以后没有软件应用只有数据了，程序员肯定会被直接替代掉了。用比较正式的表达：AI带来的是一种范式的变化，而不是眼前coding权的让渡和变更。
所谓范式（paradigm）就是一种基本的思维方式或行为模式，通常指在一个特定领域内，被公认的、约定俗成的、用来指导研究和实践的标准模式。计算机软件应用的范式是需求、PRD、架构设计、详细设计、研发、测试、部署、运维等。
而AI带来的范式则是 —— 「言出法随」。
举个例子，现在我们只要说一句「把数据中IPv6的数据剔除掉」，剩下交给AI即可。再也不需要去查一下RFC中IPv6格式定义，根据当前项目或者环境进行技术选型，然后设计和考虑各种corner case完成测试再发布使用。这种意义上来讲程序员必定会被AI替代掉。
20世纪出上海街头骑自行车送信的邮差，不是因为发明了有轨电车丢掉工作而是因为email等新的沟通方式被替代掉的，对程序员而言AI就只那个新的方式。
那程序员应该怎么办呢？
短期来看。就像前面分析的，如果计算机技术还是在当前的体系下发展的话程序员还不会被替代只是会让渡出去一些coding权，所以对程序员而言还是有时间。Ilya Sutskever在母校多伦多大学演讲的时候说过：「你可以不关心政治，但政治每时每刻都在关心你。同样的道理，在AI身上要应验许多许多倍。」，所以程序员要做的是尽可能的靠近AI：不要吝啬在AI上的花费（时间、金钱都算）；不要放弃思考和创造（AI目前还弱于人类的地方）；不要忘记自己的Plan B（个人的影响力）。
长期来看。真到了AGI言出法随的那一天，程序员能做的估计只有一件事情：做一个坚定的人类相信者，相信在人与机器的竞争中，人类一定是最后的胜利者。
面对AI的迅猛发展，我自己时常会有一种无力感：「这可咋办，AI什么都会以后还要学习吗？」
最近我看到了一段话：「物理教的不是公式，是建模思维；化学教的不是方程式，是变化思维；语文教的不是词汇，是表达思维」。
我想对于AI时代而言，学习的意义是帮助建立思维框架，它决定了能提出什么质量的问题，而问题的质量决定了AI能给出什么质量的答案。有思维框架的人用AI如虎添翼，他们知道如何精确描述需求，如何拆解复杂问题，如何验证AI的输出。没有思维框架的人用AI如盲人骑瞎马，他们只能提出模糊的需求，然后在AI的试错中消耗时间，最终沦为“提示工程师”。
就像这篇文章里提到的「如果不学习CSS有时候你都没办法描述清楚一个Bug，更不用说让AI帮你解决了」，AI时代的学习不是记住更多知识而是：
尽管AI记住和掌握知识看似远超人类，但概念化、战略思维、引人入胜的沟通和有影响力的执行等更高阶的技能仍然是独特且有价值的，面对AI我想应该超越纯粹的技术能力，认识到真正能区分个体的更深层次的能力：
「哪怕coding变得和说话一样简单，也只有少数人会演讲」。
2025-06-08 11:38:02
我最近更新了自己开发的 Obsidian 插件 Personal Assistant，关于这次更新的主要特性，简单来说，它能让 Obsidian 笔记库变成一个“本地私有版 ChatGPT”，帮助使用者阅读、总结、基于笔记内容问答等，这让 Obsidian 变成了个人专属的知识助理，这篇文章就分享这个插件的新功能以及我自己的使用体验。
P.S. 这个插件适合对 Obsidian 有一定了解，正在探索 AI+效率工具并且注重自己笔记安全的小伙伴～
Personal Assistant 插件的原理是利用了 RAG（检索增强生成） 技术，把你自己的 Obsidian vault 构建成一个可以“召回+生成”的智能知识库，配合大型语言模型（LLM），你就拥有了一个真正理解你笔记的 AI 助手。
🌟 核心功能有三个：
ChatGPT 一样问笔记库的问题总之，它真的让“写完的笔记能活起来”✨。
下面我用几个视频介绍一下插件基本用法：
P.S. 向量知识库初始化的性能问题：
如果你对技术原理感兴趣，简单解释一下：
RAG（Retrieval-Augmented Generation）是一种结合“信息检索 + 文本生成”的 AI 模式。
Personal Assistant 会实时的将 Obsidian 笔记进行 text embedding 向量化，LLM 在做知识问答的时候，它会先从你的笔记中根据语义相关性、MMR等算法检索相关知识库片段，把这些片段交给大语言模型去理解并生成回答或内容。
所以，它比“纯生成”更可信、更贴近你自己写过的内容，也更像是你“第二大脑”的延伸！
插件还融合了 Obsidian 原生的「知识图谱」结构，会在检索时自动考虑笔记间的链接、上下文和引用关系，真正做到“用结构化知识召回内容”。
也就是说，你不仅可以问“这是什么”，还可以问“它和哪些笔记有关”，特别适合信息密集型的笔记用户。
Personal Assistant 插件在每次生成的最后会附上引用的 Obsidian Vault 中笔记记录，方便用户在回顾 Obsidian 中记录的知识。
GitHub 项目地址（持续更新中，欢迎提交 issue 或 PR）：
👉 https://github.com/edonyzpc/personal-assistant
Obsidian 插件安装（官网地址）：
👉 https://obsidian.md/plugins?id=personal-assistant
✨ 如果你已经在用 Obsidian，但总觉得笔记写了就沉底了，不太会“复用”；
✨ 或者你想要一个属于自己的、不上传自己内容也能用的 AI 助手；
✨ 又或者你对 AI + Obsidian 知识管理特别感兴趣；
✨ 如果你已经用上了，欢迎来松烟阁一起交流使用体验和玩法 💬；
✨ 如果你想尝试但不太懂配置，我也可以写一篇新手配置指南，欢迎在 GitHub 留下 issue；
持续更新中，欢迎关注我，一起探索 Obsidian x AI 的更多可能！
2025-05-18 22:07:25
一个月前随着OpenAI o3的发布，社交媒体上兴起了「根据图片找位置」的潮流，举个简单的例子（来源：NanYi）：
一开始我不以为意，我觉得只要能解析图片中Exif信息足够了，不是什么黑科技，直到我看了一下o3的分析过程：
这个分析方法代表着没有metadata的图片也能精确分析得到结果，除了惊讶模型分析推理能力之外，我觉得更加让我惊艳的地方是图片和文字的信息对齐和协同能力 —— 大模型的多模态能力已经不仅仅局限于输入上的多模态支持了。
于是我萌生了一个大胆的想法：作为没有AI算法背景的人打算借助AI工具弄清楚这里的黑科技。
Multi-Modal 多模态已经不陌生了，但是o3这种多种模态输入信息的联动（对齐）到底是归属哪个范畴，需要先识别出来。经过简单的搜索引擎的检索，发现「弥合不同模态之间的语义差距并确保其表示的有效对齐是Multi-Modal Token需要解决的范畴」。
有了关键信息就比较方便了，分别用「Multi-Modal Token」、「多模态token」、「多模态令牌」等关键词进行检索，发现有大量的论文是做相关研究的。
这么复杂且并非自己熟悉的学术领域，自己一篇论文一篇论文的研究肯定是不可能了，直接上手段 Gemini Deep Research。
目前各家大模型基本陆续都推出了 Deep Research 的功能，我个人还是觉得Gemini的更好用，应该归功于Google多年的搜索引擎技术上的积累。
对于不太熟悉的领域，我需要快速的建立对快内容的认知，于是关于Multi-Modal Token结构化的介绍就是第一步了：
这是Gemini最后给出的分析报告：多模态token研究结构化介绍 - Google Docs
简单对比一下国内几个大模型的 Research 结果方便直观比较：
Gemini Deep Research给出的报告比较专业，对于非AI算法专业的我来说比较艰深难懂的，为了初步建立该领域的认识，我不需要完全能够读懂专业报告，所以我的做法就是将该报告作为大模型的多模态输入，让大模型帮我整理出适合我的理解的内容，主要的步骤：
在研究过程中，还可以充分借助AI编程工具（Cursor、Cline等）进行小工具和小任务的快速实现。我
在将Gemini Research报告作为附件，进行个性化研究的时候，为了节约token消耗，同时可以让大模型准确的识别报告中引用的资料来源方便查询和校准，我需要对markdown做一下footnote的格式处理，具体来说包括：
面对这个需求，首先我知道用awk等字符串处理工具肯定可以完成上面的需求，另外我自己并不能熟练地写正则表达式，所以我直接用IDE中的编程Agent帮助解决：
