无编程基础文科生vibe coding自动化学术思路

2 分钟阅读时长

发布时间:

自然语言输入

首先,使用自然语言告诉客户端模型(我用的是gemini3.1pro)自己的需求。

  1. Vectorize approximately 100 existing categorized academic documents, requiring integration with a local Zotero database to read PDF files and complete information.
  2. Vectorize approximately 100MB of original field notes.
  3. It needs to be compatible with any future integration with external LLM APIs or local architectures such as llama.cpp for inference, to achieve:
  4. Using API interfaces to analyze which academic theoretical analysis frameworks the original field note vector library is suitable for. Or, using API interfaces to analyze the academic relevance between the field note vector library and existing academic document vector libraries. Both steps involve integrating web crawlers for academic resources.
  5. Iterative development of the academic document library, achieved through analyzing the original field notes and subsequent actual academic papers.
  6. Automatically compiling an image and video library primarily focused on natural landscapes. This may include future integration with ports allowing the main API or multiple APIs to call image and video analysis LLM tools.

由于我使用了一个之前用中文进行的对话,所以gemini用中文回答了我,它将我的需求分为了四个板块并分别给出prompts。

  1. Zotero 学术文献库同步与向量化引擎 (The Zotero-RAG Bridge)

    使用 Python 读取本地 zotero.sqlite 提取文献元数据(作者、年份、标签),并根据相对路径找到对应 PDF。使用 LlamaParse 解析 PDF,将元数据作为 metadata 附加到生成的 Vector Chunk 上,存入 Qdrant。

  2. 田野笔记语义处理库 (The Field Note Vault)

    编写一个脚本,使用 SemanticSplitterNodeParser(语义节点分割器)处理 100MB 的 Markdown/TXT 文件,识别笔记中的时间戳和地理位置作为 Metadata,存入 Qdrant 的独立 Collection 中。

  3. 学术分析与检索智能体 (The Academic Matchmaker Agent)

    使用 FastAPI 和 LlamaIndex 构建一个 Router Agent。赋予 Agent 三个 Tool:1. 检索田野笔记库;2. 检索 Zotero 学术库;3. Semantic Scholar API 爬虫工具。当收到分析请求时,Agent 需自主规划步骤:先抽山田野笔记的核心现象,再去学术库检索相关理论,最后调用爬虫验证最新研究,并输出分析报告。

  4. 多模态自然景观视觉库 (The Multimodal Media Engine)

    编写一个多模态管道。遍历文件夹内的图片,使用 OpenAI 的 CLIP 模型或本地多模态模型生成 Image Embeddings 存入 Qdrant。在 FastAPI 中暴露接口:允许用户上传一张照片,在库中搜索相似风景;或调用 GPT-4V/本地 LLaVA 模型对选定图片进行地理和生态描述。

在此之前,我先让它给出一个合理的本地路由方案。gemini给出的方案是混合LiteLLM本地网关。接下来,我让它使用“标准流程格式”输出这些prompts。

<workflow_definition name="Hybrid_Routing_Strategy">
<system_goal>
实现一个安全的 LLM 路由网关。必须确保敏感的原始田野笔记(field_notes)绝对不暴露给外部第三方中转 API,而公开学术文献可以使用云端 API。
</system_goal>

<architecture_rules>
1. 必须使用工厂模式(Factory Pattern)动态实例化 LLM 和 Embedding 客户端。
2. 禁止在业务逻辑中硬编码 API Base URL。
3. 每次发起 LLM 请求前,必须经过 `Security_Router` 的涉密级别检查。
</architecture_rules>

<core_routing_logic>
```python
# 伪代码:强制路由逻辑
def get_llm_client(data_source: str, task_type: str):
    # 涉密等级 1:原始田野笔记,必须走本地
    if data_source == "field_notes":
        return initialize_client(
            base_url="[http://127.0.0.1:8080/v1](http://127.0.0.1:8080/v1)", # 本地 llama.cpp
            api_key="local_dummy_key",
            model="llama-3-8b-local"
        )
    
    # 涉密等级 2:公开学术文献,允许走第三方中转 API
    elif data_source == "zotero_academic_papers":
        return initialize_client(
            base_url=ENV["RELAY_API_BASE"], 
            api_key=ENV["RELAY_API_KEY"],
            model="gpt-4o" # 或 claude-3.5-sonnet
        )
        
    else:
        raise SecurityException("Unknown data source. Request blocked.")
```
</core_routing_logic>

<execution_directive>
请根据 `<core_routing_logic>` 中的伪代码,在 FastAPI 项目中实现一个单例模式的 `RouterManager` 类,并用 LlamaIndex 的 `Settings.llm` 进行动态绑定。
</execution_directive>
</workflow_definition>

-----
<workflow_definition name="Gateway_And_Fault_Tolerance">
<system_goal>
构建高并发的文档向量化(Ingestion)流水线,通过 LiteLLM 统一代理所有外部请求,并实现指数退避重试与断点续传。
</system_goal>

<system_architecture>
```mermaid
graph TD
    A[FastAPI / LlamaIndex Ingestion Script] -->|统一请求 localhost:4000| B(LiteLLM 代理网关)
    B -->|Primary Route| C[廉价第三方中转 API]
    B -->|Fallback on 429/500| D[官方 OpenAI/Anthropic API]
    B -->|Fallback on Network Dead| E[本地 llama.cpp 备用节点]
```
</system_architecture>

<architecture_rules>
1. 本 Python 后端代码不直接连接任何外部 LLM 厂商,只通过 `base_url="http://localhost:4000"` 与外部通信。
2. 对于 500 份 PDF 的向量化过程,必须使用 `tenacity` 库处理 HTTP 请求异常。
3. 必须使用 SQLite 记录已处理的 Chunk ID,实现断点续传。
</architecture_rules>

<core_retry_logic>
```python
# 伪代码:强健容错与状态机管理
from tenacity import retry, stop_after_attempt, wait_exponential

@retry(stop=stop_after_attempt(5), wait=wait_exponential(multiplier=1, min=2, max=10))
def embed_and_store(chunk):
    # 1. 检查断点续传状态
    if sqlite_db.is_processed(chunk.id):
        return "SKIPPED"
        
    try:
        # 2. 统一调用 LiteLLM 网关
        vector = litellm_client.embeddings.create(input=chunk.text)
        
        # 3. 存入 Qdrant 数据库
        qdrant_db.insert(vector)
        
        # 4. 提交状态至关系型数据库
        sqlite_db.mark_as_processed(chunk.id)
        
    except RateLimitError as e:
        log.warning("Rate limit hit, triggering exponential backoff...")
        raise e # 抛出异常以触发 tenacity 重试
    except ServerError as e:
        log.error("Relay API server error, triggering fallback...")
        raise e
```
</core_retry_logic>

<execution_directive>
请参考 `<system_architecture>` 的上下游关系,把 `<core_retry_logic>` 的伪代码转化为真实可运行的 Python 异步代码(asyncio),并提供一份基础的 `litellm_config.yaml` 配置文件,以实现主要 API 失败时自动 Fallback 的逻辑。
</execution_directive>
</workflow_definition>

之后,将这些标准格式prompts喂给VS codes中的Codex插件后,workflow正式转移到VS codes中。

Zotero 学术文献库同步与向量化引擎

使用gemini转义过的prompts效率很好,condex非常准确地完成了基本架构的搭建。我按照它的指示创建了.venv环境运行Fastllm,把qdrant和Litellm部署在Docker中。虽然我不太喜欢docker desktop的虚拟化内存耗损率(倒不如说WSL太反人类了),但我目前手上的超轻薄本装双系统耗损显然会更大,所以我还是按照Codex指示照做了,以确保我硬编码在Litellm网关里的api不会不幸流出(我使用拼车系统)。

现在,第一个问题是Codex给出的本地Zotero数据库抓取架构只会抓取一级分类,而跳过了分类下方的子分类中的条目。所以我让codex增加了在抓取条目前检索zotero.sqlite中递归树的功能,它还主动在本地文件夹中增加了两个每次自动更新(我设置为每24小时)Zotero同步Qdrant后输出最新的递归树表格文件作为简易日志。

第二个问题是codex建议我增加引用Zotero api或是引入zotero原生的key标签以更准确地区分递归树,防止重名条目混淆。但我自己在zotero中从来不使用重复的分类名,所以没有增加这两个功能。

Litellm的Python兼容性问题

Litellm在Python 3.14版本上报错了,所以我按照codex建议用3.12重新创建了一个虚拟环境并重装了所有依赖。

与此同时,由于我不确定未来field notes和学术文件会不会是跨语言的,所以我需要频繁更改本地模型,所以我让codex增加了每次启动自动根据配置文件更新嵌入模型,我使用的都是Qdrant官方支持可直流下载的未微调模型,所以没有另外另外在docker中操作导入模型。

田野笔记语义处理库

codex默认给出的方案是让我把所有田野笔记都以md文件格式放置在子目录field_notes中,让Litellm同样24小时自动更新抓取并向量化进入Qdrant。我认为markdown已经算功能简洁了(并且我的田野笔记没有什么很复杂的架构),所以没有增加一个原本我想实现的功能,即增加一个把Litellm和google docs连接在一起的接口。

田野笔记的向量化速度非常快,我没有使用gemini建议的语义分隔器模型,而使用了一个更主流的专门针对英文的嵌入模型,因为我改变了最早把中英文的田野笔记都输入Qdrant的想法。

学术分析与检索智能体

我还没给项目增加在检索Qdrant中两个collections后线性触发的爬虫功能,因为我搭建项目到一半突然觉得自己写论文也不错。

作为替代方案,我用自然语言告诉codex我准备把Qdrant接入Sillytavern。我让codex帮我写了retrieval-only接口给Sillytavern使用,通过插件形式实现。插件的实现速度让我后悔为什么没有早点在vs codes中安装编程辅助器。不管怎么说,插件运行得很顺利,我目前还在设计专门的预设。

多模态自然景观视觉库

我也还没有开始让codex写给视觉分析模型使用的接口,因为目前我想先用文本材料来完成论文。

发表评论