感受：cursor真的能提效，原本一周的的代码量，现在一天就可以搞定。能提速，但是实际会更累。因为看几千行代码要比自己写几百行代码痛苦。

问题

问题1：感觉不智能

通常给出需求，它会上来就写代码。并没有和我们确认实现思路。

实用技巧（这个要求可以放在全局文件中来控制）：在交互的时候，最好声明不要直接写代码，先确定思路。人工确认后再写代码。

问题2: 大量冗余代码

通常给出一个需求，目标是生成一个类，它会生成N个类，代码很冗余，有种画蛇添足的感觉。

实用技巧：对于一次写代码的的任务，我们最好定义好任务边界，都要实现几个类，几个函数，分别是什么功能。而不是一个模糊的需求，否则cursor会一切从繁。避免得到太多的代码需要人工校验。浪费生成的token，浪费人工检查的时间。

如果可以的话，从函数开始，到类的实现，不要奢望一次生成一个功能。如果能定义好输入输出是最好的。

就像盖房子一样，我们对cursor期望太高，我们上来就要一个别墅。其实应该先定义好边界，描述清楚我们想要什么，然后让它先设计图纸，然后我们确认， ，再盖一层，盖二层，这样执行下去。

其实更好的是我们当设计师，让cursor来施工

问题3: 大量不熟悉的代码，感到焦虑

实际感受，使用cursor生成很多代码，看起来很陌生，这点感受上不如自己写的代码。

问题4：不要贪图cursor的智能

在使用时候，最好还是限定到函数，最多到类的级别。

问题5: 有时候工作环境需要指定，不然它需要重新导入包

可以这样使用：请先进入虚拟环境，conda activate xxx

 我建议，单独实现一个类，来去改写吧，输出就是项目名，和指标，输出就是改写后的条件（语义理解：通过LLM理解项目背景，生成合适的查询）。 然后串在pipline中
所有指标都需要改写？

先不用考虑验证，我来验证就可以了。
👍 完美！方案确定了！让我确认一下最终的实现方案：
🎯 确定的方案
1. 实现方式
创建独立的 QueryRewriter 类
使用LLM进行语义理解和查询改写
集成到现有的pipeline中
2. 输入输出设计
输入：
- project_name: str  # 项目名称，如"金刚石材料研究"
- metric_name: str   # 原始指标，如"晶圆尺寸"
输出：
- rewritten_query: str  # 改写后的查询，如"金刚石晶圆最大尺寸记录"
3. 改写策略
使用LLM语义理解项目背景
结合项目名和指标生成精准的搜索查询
所有指标都进行改写（无例外）
4. 集成位置
在pipeline中，指标提取之后、调用搜索Agent之前
作为独立步骤处理
📝 实现计划
创建 QueryRewriter 类 (query_rewriter.py)
初始化LLM配置
实现 rewrite_query(project_name, metric_name) 方法
设计合适的LLM系统提示词
在pipeline中集成
找到指标提取后的位置
添加查询改写步骤
将改写后的查询传递给搜索Agent
LLM提示词设计
理解项目背景和技术领域
生成完整、精准的搜索查询
包含比较性词汇（最大、最高、记录等）
❓ 最后确认
类名: QueryRewriter 这个名字合适吗？
文件位置: 放在 top_search_agnet 目录下可以吗？
LLM模型: 继续使用 deepseek 模型？
集成点: 需要我先看一下现在的pipeline代码，找到合适的集成点吗？
确认这些细节后，我就开始实现这个 QueryRewriter 类！
可以，开始干吧！

问题6：不能完全信任cursor写到内容

我们一定要人工check cursor写的代码的输出结果，例如，这里给我的结果三个字段的内容是完全一样的！

{
        "title": "Applications of diamond films: a review",
        "description": "… These diamonds ranged in size from nanometres to millimetres, but the high … big picture”—an overview of the entire spectrum of diamond applications as they currently stand in mid-2024…",
        "context": "… These diamonds ranged in size from nanometres to millimetres, but the high … big picture”—an overview of the entire spectrum of diamond applications as they currently stand in mid-2024…",
        "content": "… These diamonds ranged in size from nanometres to millimetres, but the high … big picture”—an overview of the entire spectrum of diamond applications as they currently stand in mid-2024…",
        "url": "https://www.tandfonline.com/doi/abs/10.1080/26941112.2024.2410160",
        "publish_time": "",
        "pdf_url": "https://www.tandfonline.com/doi/pdf/10.1080/26941112.2024.2410160",
        "images": [],
        "source_key": "3"
      },

问题7: cursor适合做工程问题，不适合做算法问题

cursor很适合做工程任务，不擅长做算法任务（不擅长但能做，需要明确任务，需要强调如何实现，否则给的是工程方案）

问题8: 一个类的代码超过1000行，压力很大，会崩

出现了一个类的代码量比较大的情况下，把原本可以正常运行的代码改的面目全非，最后改不回来了。一定要好好利用git代码管理工具，可以运行的版本，最好提交一下代码，再在此基础上进行修改！

问题9: 不要相信cursor 写的prompt

实测下来，cursor写的prompt能跑，但是效果挺差的。

如何节省token？

技巧1: 多一些功能高度内聚的类，代码简单的类

在一个很长的代码上实现新的功能或者修改功能，这些代码都要当作上下文传给模型，内容越多，压缩的频率越多，越浪费token。

技巧2: 不要让cursor看你的运行日志

当你的运行日志很长的情况下，让cursor直接运行，它都需要阅读这些可能没有的大量的日志。如下这种状态。

虽然看起来很省事很智能，但是这是非常浪费token的。我们最好是自己在terminal中运行测试，人工check最终的结果。如果有问题，把有问题的一小部分给到cursor。

如何更好的使用cursor

技巧1: 好好描述需求

写什么，怎么写，写到哪里。描述清楚这很重要。（说不清楚，就要返工了）

有时候，它上来给你写好多个文件，明明是相同的功能，拆得七零八落。

有时候，它会把很多代码都写到一个类里，这读起来很麻烦。

技巧2：现学现卖

有的任务却是比较复杂仅凭对话cursor不知道我们想要什么。比如一个难的任务，我已经有综述写的工作流了，但是我需要做另外一个工作流，这个时候我可以先让cursor学习我已有的工作流，然后再写出来一个新的。此时效果会很好。可以一口气生成几千行代码。