大部分的系统，或多或少都存在重复性的工作。

以易览采集工作为例，当新增一个数据源的采集，开发人员需要根据数据源的特征，从现有的采集任务中找到类似的数据源，然后复制一些文件进行代码重写，尽管大部分的代码已经通过模块化封装可复用，但还是少不了需要创建不少新的文件、修改配置等操作。

这时候，Cursor的项目规则就呈现出了它的适用性，下文我将通过引入规则让AI帮我生成代码的实践，验证其对整体开发工作效率的提升到底有多少。

在Cursor IDE中，进入 Cursor Setting >> General >> Project Rules >> 点击"+Add new rule"创建新规则。

在易览采集项目中，我创建了名为 code-rule 的规则，创建成功之后，在项目文件中，会出现这样的规则文件：

接下来，我们就开始对规则进行编写。

由于我们需要通过与AI的交互，让AI匹配到规则中的内容，然后遵循我们制定的规则去编码，那易览采集就确定了规则使用“场景”的方式去匹配。

说到这里，最近算是跟Cursor走了几百个来回，对于规则的编写，有几点我们需要注意：

然而，不管我规则写的多详细、composer与规则的变量联动多首尾呼应，都没用，@CodeBase 执行代码编写时还是我行我素，要么画蛇添足，要么缺斤少两。

因此，才有了以上几个在这个过程中总结出来的特点，最终，我会利用这些特点，完成接近100%的自动代码实现。

第一种：不依赖规则

我花了好几天在验证规则编写，并没有得到满意的结果。在某一天的午后，突然一激灵，觉得可以先抛开规则，直接在composer中把所有步骤罗列出来，看看能做到什么程度。

说干就干，于是就有了这个长长的对话内容：

这种方式也能实现接近于100%的代码实现，缺点是需要在composer中编入过多的参考引用。

第二种：规则结合composer

有了第一种不依赖规则的验证，说明只要能让AI得到相关性的提示词，就能按照我们预期的轨迹去发展。

首先，创建规则 code-rule.mdc ：

然后，打开 composer，输入当前采集数据源相关的信息：

规则文件基本上就是固定的不需要再修改了，但是composer看起来每次新加数据源还需要改动挺多的样子。其实不然，只需要修改这一点点就可以了：

第5点注意事项，经过验证，在composer中进行罗列效果绝佳（因为composer的优先级最高，我试过把注意事项放在规则中被弱化了相关性，不起作用，后续再研究一下）。

最终，生成的代码可用率，初步验证已接近100%（代码实际调试运行，在解析HTML DOM时，存在极少量的匹配位置不准，简单校正即可）。

以下是直接AI一遍生成即可投入生产的代码，按照步骤一步一步生成：

结论：将原来单个数据源接入按天的开发时间，直接推进到小时级别。

当然，目前对于Cursor的使用，我觉得还是不够充分的，特别是关于规则、对话之间的作用域，怎样总结出更加通用的规则，会是接下来让人跃跃欲试的事情。

这次的实践我的感受，整个过程下来像是在教一个徒弟怎么做易览的开发，现在，ta可以出师了。