Cursor代码评审提示词：按平台定制不同版本

要确保Cursor生成兼容多平台的代码审查建议，提示词必须明确指定目标平台及其元数据契约。例如GitHub接口要求path/line/body的JSON结构，路径必须绝对；GitLab需要携带base_sha的position对象，且需启用diff-aware模式；Bitbucket则强制使用inline单行评论，表格与resolved状态标记均不被支持。

若提示词未明确声明“目标平台”，Cursor输出的审查意见格式大概率与平台API不兼容——GitHub PR依赖review_comment字段与line锚点，GitLab MR解析position对象中的base_sha，Bitbucket diff仅受理inline模式，多行引用将被直接忽略。

GitHub平台专用评审提示词写法

第一步：在提示词头部嵌入平台声明块
【目标平台】GitHub Pull Request Review → 必须输出JSON数组，每个元素包含path、line、body三个字段，line值须为整数，禁止使用范围写法（例如"42-45"）。

第二步：绑定GitHub API约束
所有评审意见必须遵循GitHub REST API v3 POST /repos/{owner}/{repo}/pulls/{pull_number}/comments 的请求体规范；若检测到if嵌套层级超过3层，须在body内嵌入

第三步：禁用本地路径别名
【禁止使用】“当前文件”“本模块”“上文”等相对引用——必须采用src/main/ja va/com/example/auth/JwtFilter.ja va:87完整路径加行号，GitHub审查界面不处理相对上下文。

GitLab平台专用评审提示词写法

方法一：强制position结构
每条评审意见必须以position:开头，紧随JSON对象：{"base_sha":"a1b2c3d","start_line":22,"end_line":22,"old_path":"utils/validator.py","new_path":"utils/validator.py"}。base_sha不可省略，GitLab MR评论接口校验失败会整批拒收。

方法二：启用diff-aware模式
在提示词中附加指令：“当检测到+ def validate(self):新增行时，自动提取前导空格数量并与- def check(self):删除行缩进比对，仅对缩进匹配的增删行对生成对比意见”。此策略可防止GitLab在合并预览页将意见挂载到错误行。

Bitbucket平台专用评审提示词写法

Bitbucket仅支持inline评论，需满足三条硬性规则：每条评论content字段不超过500字符；禁止使用Markdown表格；所有代码引用须以```python包裹且限定单行。例如检测到for item in data:，评审意见只能写成：

for item in (data or []):

实际操作只需将文件拖拽至指定区域即可完成。

注意：Bitbucket不提供resolved状态标记，所有评论默认状态为open，因此提示词中严禁使用“请确认后关闭此意见”等表述，以免误导评审者。