关于业务上下文的引用姿势（使用-b）

[duringnone]

目前我想基于业务上下文提供code-review参考，想确认下使用官方的使用姿势、或者针对我的使用姿势官方有无更好的建议？

我的使用姿势，生成业务上下文markdown格式文件，然后通过ocr的--background参数引用该业务上下文内容

1. 案例：
   ocr review -c 80db2cf1 -b "$(cat biz_context.md)"

2. biz_context.md内容参考

# OCR 审查业务上下文

## 审查指令（必须执行）
审查 `<current_file_diff>` 中**新增/修改**的代码时，**必须**对照下文业务上下文逐项验证：
1. **验收符合性**：每一行评论都以"～ocr的建议～"

请教几个具体的问题：

1. 做了几个案例测试效果是ok，求证下使用姿势，以及后续官方在这块场景的规划是怎样的？

2. 对--background的使用上，有什么最佳实践的经验参考吗？

例如：有测试过程中，考虑到-b输入的上下文过长的风险（可能导致ocr注意力分散，从而影响ocr-code-review效果）；具体参数和--background的输入长度limit有什么好的建议吗？（目前设置了8K的阈值，防止上下文膨胀，拍脑袋定的）

[lizhengfeng101]

我提供一下我们内部的最佳实践，以 Claude Code 为例，我们的目前工作流程是：澄清需求 -> 自动编码 -> 自动评审（这个环节会让 CC 自动总结当前的需求背景、关键边界等，类似 commit msg 的一条消息传入 Background）-> 自动修复，然后循环上述流程后两个环节。

我们认为核心点应该是简要的总结 + 关键的边界，其他非动态的背景上下文应该使用规则文件来管理，例如 xxx 组件是你们公司内部的独有用法。

举个例子，在一个电商应用的订单模块中，增加“新用户专享”优惠券功能。

反例：
-b
新增“新用户专享”优惠券类型

正例：
-b
新增“新用户专享”优惠券类型
CR 描述:

• 增加“新用户专享”的优惠券类型。
• 该优惠券有效期为 30 天。
• 退款时退回优惠券，过期时间在原基础上增加 7 天。

[duringnone]

感谢分享，我们是基于openspec开发规范，和你上面的思路类似，但是担心spec.md的内容过于冗长；

1. 现状：目前是粗暴地引入某个需求中的spen.md（业务澄清后的文档），作为ocr 的--background内容
2. 结合你的建议，我会尝试在spec.md再抽象做一层总结，压缩让--background的内容更短

其他问题
3. 目前--background 内容对最终code-review的正向影响效果你们是怎么量化的？（这需要大量的测试数据，目前我们还在使用初期，效果我心里其实没什么底）

[lizhengfeng101]

spec.md 过于冗长会带来副作用，这个我们已经基于数据证明了。关于正向影响如何量化，我们内部上线对效果会造成显著影响的 feature 时都会进行大量的数据回归和轨迹分析。这也是我认为这个项目开源的意义，可以让大量开发者用到接近阿里内部生产级的专业评审工具，不过坦白说，关于 --background 这个特性，我们的数据回归的规模相对有限，没有太深度的去评测，毕竟无法预测用户会植入什么内容。不过可以确认的是，按照我们推荐的规范来使用该能力，效果是正向的。

[duringnone]

1. 大佬，引申问一个问题；关于这个issue（https://github.com/alibaba/open-code-review/issues/40）；目前有排期计划吗，有预计上线时间吗（很期待ing）？
2. 业务背景：我们希望基于open-code-review进一步搭建ai-code-review，能覆盖review全量代码的场景

[lizhengfeng101]

感谢期待，我们预计这个月会上线，AI 时代其实写功能比较快，但是验证会比较花时间。

[DaiKiQi]

@lizhengfeng101 请教下，这种方式是否在cr的过程中能够基于spec文档，确认所有功能点已经实现了吗？看架构是基于单文件多agent的方式，这类spec是否可以校验呢？是每个agent都会注入spec prompt吗

[lizhengfeng101]

是的，我们最近会上线文件分组能力，每个分组都会注入 Background ，所以其实不建议注入 spec