Conversation
Contributor
There was a problem hiding this comment.
Hey - 我已经审查了你的修改,看起来很棒!
帮我变得更有用!请在每条评论上点 👍 或 👎,我会根据你的反馈改进代码审查。
Original comment in English
Hey - I've reviewed your changes and they look great!
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Contributor
There was a problem hiding this comment.
Pull request overview
该 PR 旨在让“信用点商店(CreditShopping)”流程更好地适配 ADB 资源,并补充“折扣筛选”中的“包含无折扣”选项,从而提升在不同环境下的识别与购买逻辑一致性。
Changes:
- 在任务配置中为折扣筛选新增
Ignore案例(包含“无折扣”),并补齐多语言文案。 - 调整 CreditShopping 主 pipeline 中“保留信用点”相关 OCR:扩大 ROI,并新增/接入颜色过滤节点以提升 OCR 稳定性。
- 更新 ADB pipeline 覆写的 ROI(但目前对 color_filter 对应节点的 ROI 覆写路径存在问题)。
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| assets/tasks/CreditShopping.json | 为折扣筛选新增 Ignore 选项,并通过 pipeline_override 覆写 IsDiscount 识别参数。 |
| assets/resource_adb/pipeline/CreditShopping/Shopping.json | ADB 环境下对“保留信用点”相关 ROI 做覆写,并启用 ADBSpecial 流程。 |
| assets/resource/pipeline/CreditShopping/Shopping.json | 调整保留信用点 OCR ROI、引入颜色过滤节点;修改“购买黑名单”节点的识别条件与描述。 |
| assets/misc/locales/zh_tw.json | 新增 Ignore 文案并调整 Any 文案表达。 |
| assets/misc/locales/zh_cn.json | 新增 Ignore 文案并调整 Any 文案表达。 |
| assets/misc/locales/ko_kr.json | 新增 Ignore 文案并调整 Any 文案表达。 |
| assets/misc/locales/ja_jp.json | 新增 Ignore 文案并调整 Any 文案表达。 |
| assets/misc/locales/en_us.json | 新增 Ignore 文案并调整 Any 文案表达。 |
Closed
Contributor
There was a problem hiding this comment.
Hey - 我发现了 1 个问题,并给出了一些整体性的反馈:
- 在
evaluateBinaryExpression中,逻辑运算符(&&、||)总是会计算两边的表达式,因为在检查运算符之前就对X和Y调用了evaluateASTExpression;如果在表达式中嵌入了 OCR 调用,建议增加显式的短路求值,以避免不必要的识别开销以及潜在的副作用。 - 在
resolveExpressionValues中,expressionNodePattern.ReplaceAllStringFunc对每个匹配都调用了一次FindStringSubmatch,即使完整匹配字符串已经可用;你可以直接从match字符串中截取占位符内容(例如去掉外围的大括号),从而简化逻辑并避免多余的正则开销。
面向 AI Agent 的提示词
Please address the comments from this code review:
## Overall Comments
- In `evaluateBinaryExpression`, logical operators (`&&`, `||`) always evaluate both sides because `evaluateASTExpression` is called on `X` and `Y` before checking the operator; if OCR calls are embedded in expressions, consider adding explicit short-circuit evaluation to avoid unnecessary recognitions and potential side effects.
- In `resolveExpressionValues`, `expressionNodePattern.ReplaceAllStringFunc` calls `FindStringSubmatch` for each match even though the full match is already provided; you can simplify and avoid the extra regex work by capturing the placeholder content directly from the `match` string (e.g., by trimming the surrounding braces).
## Individual Comments
### Comment 1
<location path="agent/go-service/creditshopping/reserve_recognition.go" line_range="109-118" />
<code_context>
+ return reserveRecognitionConfig{}, err
+ }
+
+ if expressionRaw, ok := params["expression"]; ok {
+ expression, ok := expressionRaw.(string)
+ if !ok {
+ return reserveRecognitionConfig{}, fmt.Errorf("expression: unsupported type %T", expressionRaw)
+ }
+ expression = strings.TrimSpace(expression)
+ if expression == "" {
+ return reserveRecognitionConfig{}, fmt.Errorf("expression: must not be empty")
+ }
+ return reserveRecognitionConfig{
+ Expression: expression,
+ }, nil
</code_context>
<issue_to_address>
**suggestion:** Threshold is silently ignored when an expression is provided
When `expression` is present, the function returns a config with only `Expression`, silently discarding any `threshold` value. To avoid confusing mixed configs, either validate and reject cases where both are provided, or clearly log/document that `threshold` is ignored when `expression` is set.
Suggested implementation:
```golang
if expressionRaw, ok := params["expression"]; ok {
if _, hasThreshold := params["threshold"]; hasThreshold {
return reserveRecognitionConfig{}, fmt.Errorf("expression: must not be provided together with threshold")
}
expression, ok := expressionRaw.(string)
if !ok {
return reserveRecognitionConfig{}, fmt.Errorf("expression: unsupported type %T", expressionRaw)
}
expression = strings.TrimSpace(expression)
if expression == "" {
return reserveRecognitionConfig{}, fmt.Errorf("expression: must not be empty")
}
return reserveRecognitionConfig{
Expression: expression,
}, nil
}
```
None required based on the provided snippet. This change ensures that when both `expression` and `threshold` are present, the function fails fast with a clear validation error instead of silently ignoring `threshold`.
</issue_to_address>帮我变得更有用!请在每条评论上点 👍 或 👎,我会根据你的反馈改进后续的 Review。
Original comment in English
Hey - I've found 1 issue, and left some high level feedback:
- In
evaluateBinaryExpression, logical operators (&&,||) always evaluate both sides becauseevaluateASTExpressionis called onXandYbefore checking the operator; if OCR calls are embedded in expressions, consider adding explicit short-circuit evaluation to avoid unnecessary recognitions and potential side effects. - In
resolveExpressionValues,expressionNodePattern.ReplaceAllStringFunccallsFindStringSubmatchfor each match even though the full match is already provided; you can simplify and avoid the extra regex work by capturing the placeholder content directly from thematchstring (e.g., by trimming the surrounding braces).
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `evaluateBinaryExpression`, logical operators (`&&`, `||`) always evaluate both sides because `evaluateASTExpression` is called on `X` and `Y` before checking the operator; if OCR calls are embedded in expressions, consider adding explicit short-circuit evaluation to avoid unnecessary recognitions and potential side effects.
- In `resolveExpressionValues`, `expressionNodePattern.ReplaceAllStringFunc` calls `FindStringSubmatch` for each match even though the full match is already provided; you can simplify and avoid the extra regex work by capturing the placeholder content directly from the `match` string (e.g., by trimming the surrounding braces).
## Individual Comments
### Comment 1
<location path="agent/go-service/creditshopping/reserve_recognition.go" line_range="109-118" />
<code_context>
+ return reserveRecognitionConfig{}, err
+ }
+
+ if expressionRaw, ok := params["expression"]; ok {
+ expression, ok := expressionRaw.(string)
+ if !ok {
+ return reserveRecognitionConfig{}, fmt.Errorf("expression: unsupported type %T", expressionRaw)
+ }
+ expression = strings.TrimSpace(expression)
+ if expression == "" {
+ return reserveRecognitionConfig{}, fmt.Errorf("expression: must not be empty")
+ }
+ return reserveRecognitionConfig{
+ Expression: expression,
+ }, nil
</code_context>
<issue_to_address>
**suggestion:** Threshold is silently ignored when an expression is provided
When `expression` is present, the function returns a config with only `Expression`, silently discarding any `threshold` value. To avoid confusing mixed configs, either validate and reject cases where both are provided, or clearly log/document that `threshold` is ignored when `expression` is set.
Suggested implementation:
```golang
if expressionRaw, ok := params["expression"]; ok {
if _, hasThreshold := params["threshold"]; hasThreshold {
return reserveRecognitionConfig{}, fmt.Errorf("expression: must not be provided together with threshold")
}
expression, ok := expressionRaw.(string)
if !ok {
return reserveRecognitionConfig{}, fmt.Errorf("expression: unsupported type %T", expressionRaw)
}
expression = strings.TrimSpace(expression)
if expression == "" {
return reserveRecognitionConfig{}, fmt.Errorf("expression: must not be empty")
}
return reserveRecognitionConfig{
Expression: expression,
}, nil
}
```
None required based on the provided snippet. This change ensures that when both `expression` and `threshold` are present, the function fails fast with a clear validation error instead of silently ignoring `threshold`.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Member
Author
|
ExpressionRecognition 是一个通用的 Custom Recognition,用于对由识别节点结果组成的表达式进行求值。它支持通过 {节点名} 引用其他 OCR 数字识别节点,执行后将识别结果代入表达式,并以布尔结果决定是否命中 {节点A}<400 节点A必须识别数字,且不能有任何其他字符串(^d+$) |
Contributor
|
locales 换位置了,冲突了 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by Sourcery
支持基于阈值和基于表达式的预留额度识别,并为 ADB 和智能刷新模式适配信用商城相关工作流。
New Features:
Enhancements:
Original summary in English
Summary by Sourcery
Support both threshold-based and expression-based reserve credit recognition and adapt credit shop workflows for ADB and smart refresh modes.
New Features:
Enhancements:
Original summary in English
Summary by Sourcery
支持基于阈值和基于表达式的预留额度识别,并为 ADB 和智能刷新模式适配信用商城相关工作流。
New Features:
Enhancements:
Original summary in English
Summary by Sourcery
Support both threshold-based and expression-based reserve credit recognition and adapt credit shop workflows for ADB and smart refresh modes.
New Features:
Enhancements: