为了让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/java/com/example/auth/JwtFilter.java: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，因此提示词中应避免使用“请确认后关闭此意见”这类表述，以免误导评审人。