提示词定生死给阿里代码评审 agent 定制评审规则与结构化输出【免费下载链接】open-code-reviewSecure, fast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-reviewAI 代码评审在 2026 年几乎成了每个团队的标配实验CI 里接一个 agent让它在 PR 合入前先读一遍 diff。但实验落地到生产绝大多数团队栽在了同一个地方——不是模型不够强而是提示词没有工程化。社区里对这类工具的吐槽高度一致评审覆盖不全、位置漂移、幻觉误报、评论刷屏。阿里开源代码评审工具 open-code-review 之所以在 GitHub 周榜上持续霸榜恰恰是因为它把提示词定生死这个命题拆成了可审计、可调试、可落库的工程问题角色与评审维度用规则文件定制输出用 JSON 协议约束误报用独立过滤 agent 抑制。本文基于其仓库源码逐层拆解这三件事是怎么做的。角色定义与评审维度不是一段提示词而是一条四层解析链多数团队把评审维度写在一段长提示词里改一次要重新调参。open-code-review 的做法相反评审角色和评审维度被拆成提示词模板prompt 文件与规则文件rule两套资产前者固化在模板目录里后者允许用户按层覆盖。角色定义在 main_task_system.md 中它明确写死了三条行为边界只评新增代码Focus on issues in newly added code. Avoid commenting on correct code or unchanged code. Avoid commenting on deleted code; deleted code serves only as reference context.必须逐个过文件Review every file listed inreview_filesindividually且在调用task_done前确认每个文件都过了一遍——这直接回应了社区普遍遇到的大变更集下 agent 挑肥拣瘦、漏文件痛点。跨文件是鼓励项Cross-file observations withinreview_filesare encouraged但上下文工具只用于取证never produce comments targeting files outside it——把幻觉误报的出口提前封死。评审维度则完全交给规则层。仓库内置了一套按语言拆分的规则文档internal/config/rules/rule_docs/下 60 份default.md 定义了正确性、安全、性能、可维护性、测试覆盖五个通用维度go.md 进一步细化到错误包装丢失原始 cause、typed nil interface、锁跨 IO 持有、sync.Once重试、range 循环变量捕获、math/rand用于安全密钥等 Go 专属清单ts_js_tsx_jsx.md 则覆盖 React Hooks 规则、innerHTMLXSS、eval注入、原型链污染等前端红线。每种语言的规则都带着一条总纲Favor precision over recall... A false positive costs reviewer trust——即宁可漏报不可误报。定制入口是rule.json有四层优先级见 resolver.go 的NewResolver--rule标志指定的自定义文件最高项目级repo/.opencodereview/rule.json可提交进仓库全局~/.opencodereview/rule.json内嵌系统默认规则兜底永远存在规则条目是{path, rule}的 glob 匹配声明顺序即优先级、首匹配生效merge_system_rule: true时用户规则会与系统语言规则拼接而不是替换——官方文档给了一个典型用法一条**/*的兜底安全规则加上merge_system_rule后Java 文件仍然拿到 java.md、Python 文件仍然拿到 python.md用户规则叠加其上。调试时ocr rules check file能直接打印命中的层级、匹配的 pattern 和最终生效的规则正文这是提示词可调试的关键基础设施ocr rules check --rule custom.json src/main/resources/mapper/UserMapper.xml # Source: Custom (--rule) # Pattern: **/*mapper*.xml规则解析链还藏在细节里.m后缀同时被 MATLAB 和 Objective-C 使用sniffer.go 会读取文件首行做内容嗅探来决定用哪份规则规则文件本身有扩展名白名单.md/.txt/.markdown和 512KB 大小上限system_rules.go 的readRuleFileSafe。定制评审维度的成本被压到了最低改一份 markdown 规则就等价于改一次 agent 的系统提示词且全程可审计。结构化输出JSON 协议约束模型评论才能落库提示词再精巧模型返回的自由文本都无法直接进 CI。open-code-review 的解法是用工具调用的 JSON Schema 约束输出结构评审结论不是写出来的而是调出来的。模型唯一能提交评审结论的通道是code_comment工具定义见 tools.json。它的入参要求每条评论携带 5 个必填字段——content、existing_code、category、severity、path其中分类是 8 枚举bug/security/performance/maintainability/test/style/documentation/other严重度是 4 枚举critical/high/medium/low。这背后对应的 Go 结构体是 LlmCommenttype LlmComment struct { Path string json:path Content string json:content SuggestionCode string json:suggestion_code,omitempty ExistingCode string json:existing_code,omitempty StartLine int json:start_line EndLine int json:end_line Thinking string json:thinking,omitempty Category string json:category,omitempty Severity string json:severity,omitempty }解析端code_comment.go对枚举做了归一化兜底模型传了非法的 category 会被归为other非法 severity 归为low——结构化协议允许模型出错但不允许结构被破坏。existing_code的作用是让评论能够通过滑动窗口算法在 diff 中锚定精确行号relocation.go 配套的RE_LOCATION_TASK会在锚定失败时让模型重新定位代码片段。这是位置漂移问题的工程解法不靠提示词请求模型尽量给对行号而是靠工具协议 二次定位保证。落库与分发同样结构化。ocr review --format json输出一个包含status、summary文件数/评论数/token 消耗/耗时、tool_calls按工具聚合的调用次数与失败明细、comments的完整 JSON 文档见 output.go 的jsonOutput--format sarif则把 category 映射为 SARIF rule、severity 映射为 result levelcritical/high→errormedium→warninglow→note见 sarif.go可直接接入 GitHub Code Scanning。而每一次评审会话都会以 JSONL 追加写入~/.opencodereview/sessions/encoded-repo-path/session-id.jsonlpersist.go记录从 prompt、LLM 响应到工具调用、评论产出的每一个事件——评审过程本身就是可回放的数据。更有意思的是 manifest.go每条评论所属文件会被记录到 coverage 集合用item_idfingerprint追踪每个文件的评审状态失败原因被归类为 provider/timeout/budget 等固定枚举连哪些文件没审到都有据可查。结构化的尽头是可观测这恰恰是社区文章里反复强调的AI 评审必须可审计的落地形态。分级过滤与误报抑制把降噪也做成一次提示词工程评审 agent 最大的生产事故是评论刷屏——一次 PR 挂 50 条 low 级噪音工程师三天不看 review。open-code-review 把降噪拆成了前置过滤 后置过滤 分级输出三层每一层都有独立的提示词资产。前置过滤是确定性的不花一个 token。文件进入 agent 前要过六道闸internal/agent/selection.go二进制排除 → 内置密钥路径保护.ssh/、id_rsa、.env等见 default_secret_patterns.json不可被 include 绕过→ 用户 exclude → 用户 include可反制内置测试文件排除→ 扩展名白名单 → 内置默认排除测试文件、node_modules/、vendor/、dist/、生成代码等 100 条模式见 default_exclude_patterns.json。ocr review --preview可以零成本预览每个文件被过滤的原因。后置过滤是提示词工程的重头戏。主评审循环结束后agent 会运行独立的REVIEW_FILTER_TASK提示词在 review_filter_task_system.md 与 review_filter_task_user.md。这个事实核查员角色的默认动作是批准一切只允许在两个严格前提下删除评论Ground A评论描述的目标代码根本不在其 subject 文件的 diff 中Ground Bdiff 中有某一行字面直接反驳评论的核心断言。提示词里写得很直白Suspicious, I cannot verify this, low value... all mean approve.无法核实一律放行。更巧妙的是受保护主体机制内存安全、并发、链接/声明一致性、行为或兼容性变更、未使用的参数这五类评论禁止删除——因为删错一条真发现比多留一条噪音贵得多。这是对误报抑制的最精细设计它不是让模型觉得不对就删而是规定了删除所需的最低证据标准并把证据不足时如何抉择的成本偏好显式写进提示词。分级过滤还有确定性一侧评论产出时已带 category/severityocr session comments --severity high --category bug session-id可以在消费端按严重度与分类筛选session_cmd.go 的filterCommentsGitHub Actions 集成post-review-comments.js支持按 severity 阈值路由低于阈值的评论进 issue 而非 PR review 评论从源头避免刷屏。这套重精度轻召回的设计在 benchmark 里得到了量化验证。仓库 README 公布的真实世界基准50 个热门仓库、200 个真实 PR、1505 条人工标注缺陷显示与同模型的通用 agentClaude Code相比open-code-review 的Precision 与 F1 显著更高token 消耗仅约 1/9耗时更短代价是 Recall 更低——这是一个刻意选择的取舍。与其让 agent 扫出 20 条假阳性再靠人来筛不如让它只报 5 条可信的把工程师的注意力留给真问题。而支撑这个取舍的正是上面那套角色边界 规则维度 工具协议 双段过滤的提示词工程体系。结语回到提示词定生死这个命题open-code-review 的启示是提示词工程的价值不在于把一段 system prompt 写得多么华丽而在于让提示词变得可分层、可约束、可验证。评审角色与维度下沉为可覆盖的规则文件输出被工具 JSON Schema 钉死成可落库的结构误报抑制被拆成独立 agent 并写入明确的证据标准——再加上确定性过滤兜底。当提示词不再是黑盒 prompt而是一套有优先级、有 schema、有证据门槛的工程资产时AI 评审能不能信这个问题才第一次有了可以回答的基础。【免费下载链接】open-code-reviewSecure, fast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/11 8:36:30 · 阅读 1.2k 提示词定生死：给阿里代码评审 agent 定制评审规则与结构化输出
提示词定生死给阿里代码评审 agent 定制评审规则与结构化输出【免费下载链接】open-code-reviewSecure, fast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-reviewAI 代码评审在 2026 年几乎成了每个团队的标配实验CI 里接一个 agent让它在 PR 合入前先读一遍 diff。但实验落地到生产绝大多数团队栽在了同一个地方——不是模型不够强而是提示词没有工程化。社区里对这类工具的吐槽高度一致评审覆盖不全、位置漂移、幻觉误报、评论刷屏。阿里开源代码评审工具 open-code-review 之所以在 GitHub 周榜上持续霸榜恰恰是因为它把提示词定生死这个命题拆成了可审计、可调试、可落库的工程问题角色与评审维度用规则文件定制输出用 JSON 协议约束误报用独立过滤 agent 抑制。本文基于其仓库源码逐层拆解这三件事是怎么做的。角色定义与评审维度不是一段提示词而是一条四层解析链多数团队把评审维度写在一段长提示词里改一次要重新调参。open-code-review 的做法相反评审角色和评审维度被拆成提示词模板prompt 文件与规则文件rule两套资产前者固化在模板目录里后者允许用户按层覆盖。角色定义在 main_task_system.md 中它明确写死了三条行为边界只评新增代码Focus on issues in newly added code. Avoid commenting on correct code or unchanged code. Avoid commenting on deleted code; deleted code serves only as reference context.必须逐个过文件Review every file listed inreview_filesindividually且在调用task_done前确认每个文件都过了一遍——这直接回应了社区普遍遇到的大变更集下 agent 挑肥拣瘦、漏文件痛点。跨文件是鼓励项Cross-file observations withinreview_filesare encouraged但上下文工具只用于取证never produce comments targeting files outside it——把幻觉误报的出口提前封死。评审维度则完全交给规则层。仓库内置了一套按语言拆分的规则文档internal/config/rules/rule_docs/下 60 份default.md 定义了正确性、安全、性能、可维护性、测试覆盖五个通用维度go.md 进一步细化到错误包装丢失原始 cause、typed nil interface、锁跨 IO 持有、sync.Once重试、range 循环变量捕获、math/rand用于安全密钥等 Go 专属清单ts_js_tsx_jsx.md 则覆盖 React Hooks 规则、innerHTMLXSS、eval注入、原型链污染等前端红线。每种语言的规则都带着一条总纲Favor precision over recall... A false positive costs reviewer trust——即宁可漏报不可误报。定制入口是rule.json有四层优先级见 resolver.go 的NewResolver--rule标志指定的自定义文件最高项目级repo/.opencodereview/rule.json可提交进仓库全局~/.opencodereview/rule.json内嵌系统默认规则兜底永远存在规则条目是{path, rule}的 glob 匹配声明顺序即优先级、首匹配生效merge_system_rule: true时用户规则会与系统语言规则拼接而不是替换——官方文档给了一个典型用法一条**/*的兜底安全规则加上merge_system_rule后Java 文件仍然拿到 java.md、Python 文件仍然拿到 python.md用户规则叠加其上。调试时ocr rules check file能直接打印命中的层级、匹配的 pattern 和最终生效的规则正文这是提示词可调试的关键基础设施ocr rules check --rule custom.json src/main/resources/mapper/UserMapper.xml # Source: Custom (--rule) # Pattern: **/*mapper*.xml规则解析链还藏在细节里.m后缀同时被 MATLAB 和 Objective-C 使用sniffer.go 会读取文件首行做内容嗅探来决定用哪份规则规则文件本身有扩展名白名单.md/.txt/.markdown和 512KB 大小上限system_rules.go 的readRuleFileSafe。定制评审维度的成本被压到了最低改一份 markdown 规则就等价于改一次 agent 的系统提示词且全程可审计。结构化输出JSON 协议约束模型评论才能落库提示词再精巧模型返回的自由文本都无法直接进 CI。open-code-review 的解法是用工具调用的 JSON Schema 约束输出结构评审结论不是写出来的而是调出来的。模型唯一能提交评审结论的通道是code_comment工具定义见 tools.json。它的入参要求每条评论携带 5 个必填字段——content、existing_code、category、severity、path其中分类是 8 枚举bug/security/performance/maintainability/test/style/documentation/other严重度是 4 枚举critical/high/medium/low。这背后对应的 Go 结构体是 LlmCommenttype LlmComment struct { Path string json:path Content string json:content SuggestionCode string json:suggestion_code,omitempty ExistingCode string json:existing_code,omitempty StartLine int json:start_line EndLine int json:end_line Thinking string json:thinking,omitempty Category string json:category,omitempty Severity string json:severity,omitempty }解析端code_comment.go对枚举做了归一化兜底模型传了非法的 category 会被归为other非法 severity 归为low——结构化协议允许模型出错但不允许结构被破坏。existing_code的作用是让评论能够通过滑动窗口算法在 diff 中锚定精确行号relocation.go 配套的RE_LOCATION_TASK会在锚定失败时让模型重新定位代码片段。这是位置漂移问题的工程解法不靠提示词请求模型尽量给对行号而是靠工具协议 二次定位保证。落库与分发同样结构化。ocr review --format json输出一个包含status、summary文件数/评论数/token 消耗/耗时、tool_calls按工具聚合的调用次数与失败明细、comments的完整 JSON 文档见 output.go 的jsonOutput--format sarif则把 category 映射为 SARIF rule、severity 映射为 result levelcritical/high→errormedium→warninglow→note见 sarif.go可直接接入 GitHub Code Scanning。而每一次评审会话都会以 JSONL 追加写入~/.opencodereview/sessions/encoded-repo-path/session-id.jsonlpersist.go记录从 prompt、LLM 响应到工具调用、评论产出的每一个事件——评审过程本身就是可回放的数据。更有意思的是 manifest.go每条评论所属文件会被记录到 coverage 集合用item_idfingerprint追踪每个文件的评审状态失败原因被归类为 provider/timeout/budget 等固定枚举连哪些文件没审到都有据可查。结构化的尽头是可观测这恰恰是社区文章里反复强调的AI 评审必须可审计的落地形态。分级过滤与误报抑制把降噪也做成一次提示词工程评审 agent 最大的生产事故是评论刷屏——一次 PR 挂 50 条 low 级噪音工程师三天不看 review。open-code-review 把降噪拆成了前置过滤 后置过滤 分级输出三层每一层都有独立的提示词资产。前置过滤是确定性的不花一个 token。文件进入 agent 前要过六道闸internal/agent/selection.go二进制排除 → 内置密钥路径保护.ssh/、id_rsa、.env等见 default_secret_patterns.json不可被 include 绕过→ 用户 exclude → 用户 include可反制内置测试文件排除→ 扩展名白名单 → 内置默认排除测试文件、node_modules/、vendor/、dist/、生成代码等 100 条模式见 default_exclude_patterns.json。ocr review --preview可以零成本预览每个文件被过滤的原因。后置过滤是提示词工程的重头戏。主评审循环结束后agent 会运行独立的REVIEW_FILTER_TASK提示词在 review_filter_task_system.md 与 review_filter_task_user.md。这个事实核查员角色的默认动作是批准一切只允许在两个严格前提下删除评论Ground A评论描述的目标代码根本不在其 subject 文件的 diff 中Ground Bdiff 中有某一行字面直接反驳评论的核心断言。提示词里写得很直白Suspicious, I cannot verify this, low value... all mean approve.无法核实一律放行。更巧妙的是受保护主体机制内存安全、并发、链接/声明一致性、行为或兼容性变更、未使用的参数这五类评论禁止删除——因为删错一条真发现比多留一条噪音贵得多。这是对误报抑制的最精细设计它不是让模型觉得不对就删而是规定了删除所需的最低证据标准并把证据不足时如何抉择的成本偏好显式写进提示词。分级过滤还有确定性一侧评论产出时已带 category/severityocr session comments --severity high --category bug session-id可以在消费端按严重度与分类筛选session_cmd.go 的filterCommentsGitHub Actions 集成post-review-comments.js支持按 severity 阈值路由低于阈值的评论进 issue 而非 PR review 评论从源头避免刷屏。这套重精度轻召回的设计在 benchmark 里得到了量化验证。仓库 README 公布的真实世界基准50 个热门仓库、200 个真实 PR、1505 条人工标注缺陷显示与同模型的通用 agentClaude Code相比open-code-review 的Precision 与 F1 显著更高token 消耗仅约 1/9耗时更短代价是 Recall 更低——这是一个刻意选择的取舍。与其让 agent 扫出 20 条假阳性再靠人来筛不如让它只报 5 条可信的把工程师的注意力留给真问题。而支撑这个取舍的正是上面那套角色边界 规则维度 工具协议 双段过滤的提示词工程体系。结语回到提示词定生死这个命题open-code-review 的启示是提示词工程的价值不在于把一段 system prompt 写得多么华丽而在于让提示词变得可分层、可约束、可验证。评审角色与维度下沉为可覆盖的规则文件输出被工具 JSON Schema 钉死成可落库的结构误报抑制被拆成独立 agent 并写入明确的证据标准——再加上确定性过滤兜底。当提示词不再是黑盒 prompt而是一套有优先级、有 schema、有证据门槛的工程资产时AI 评审能不能信这个问题才第一次有了可以回答的基础。【免费下载链接】open-code-reviewSecure, fast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考