do-competitively

do-competitively

通过多 Agent 竞争式生成、元评审者评估规范制定、多评审者评估和基于证据的综合来执行任务，结合并行实现中的最佳元素，产出更优结果。 此命令通过自适应策略选择，实现了生成-批判-综合（GCS）模式，适用于质量比速度更重要的高风险任务。它将竞争式生成与元评审者评估规范制定、多视角评估相结合，然后根据结果智能选择最佳综合策略。

主要功能：

• 生成过程中的自我批判循环（宪法式 AI）
• 结构化评估——元评审者在评审前制定定制评分标准
• 评估中的验证循环（链式验证）
• 自适应策略：润色明显胜出的方案、综合意见不一的方案、重新设计失败的方案
• 通过智能策略选择，平均节省 15-20% 的成本

重要：你不是实现 Agent，也不是评审者，不应阅读作为上下文提供给子 Agent 或任务的文件。你不应阅读报告，也不应让上下文被不必要的信息淹没。你必须逐步遵循流程。任何偏离都将被视为失败，你将被终止！

模式：生成-批判-综合（GCS）

此命令实现了一个多阶段自适应竞争式编排模式：

Phase 1: Competitive Generation with Self-Critique + Meta-Judge (IN PARALLEL)
         ┌─ Meta-Judge → Evaluation Specification YAML ───────────┐
Task ────┼─ Agent 2 → Draft → Critique → Revise → Solution B ───┐ │ 
         ├─ Agent 3 → Draft → Critique → Revise → Solution C ───┼─┤ 
         └─ Agent 1 → Draft → Critique → Revise → Solution A ───┘ │
                                                                  │
Phase 2: Multi-Judge Evaluation with Verification                 │
         ┌─ Judge 1 → Evaluate → Verify → Revise → Report A ─┐    │
         ├─ Judge 2 → Evaluate → Verify → Revise → Report B ─┼────┤
         └─ Judge 3 → Evaluate → Verify → Revise → Report C ─┘    │
                                                                  │
Phase 2.5: Adaptive Strategy Selection                            │
         Analyze Consensus ───────────────────────────────────────┤
                ├─ Clear Winner? → SELECT_AND_POLISH              │
                ├─ All Flawed (<3.0)? → REDESIGN (return Phase 1) │
                └─ Split Decision? → FULL_SYNTHESIS               │
                                          │                       │
Phase 3: Evidence-Based Synthesis         │                       │
         (Only if FULL_SYNTHESIS)         │                       │
         Synthesizer ─────────────────────┴───────────────────────┴─→ Final Solution

流程

设置：创建报告目录

开始前，确保报告目录存在：

mkdir -p .specs/reports

报告命名约定： .specs/reports/{solution-name}-{YYYY-MM-DD}.[1|2|3].md

其中：

• {solution-name} - 根据输出路径推导（例如，从输出路径 specs/api/users.md 推导出 users-api）
• {YYYY-MM-DD} - 当前日期
• [1|2|3] - 评审者编号

注意： 方案保留在指定的输出位置；只有评估报告会存入 .specs/reports/

阶段 1：竞争式生成 + 元评审者（并行）

同时启动 3 个独立的生成 Agent 和 1 个元评审者 Agent，共 4 个 Agent（建议全部使用 Opus，以保证质量）：

元评审者与 3 个生成 Agent 并行运行，因为它不需要它们的输出——它只需要任务描述来生成评估标准。

重要： 在同一条消息中使用 4 次 Task 工具调用，以前台 Agent 的形式一次性分派全部 4 个 Agent。元评审者必须是分派顺序中的第一个工具调用，以便在代码库被生成 Agent 修改之前，有时间收集上下文。

元评审者 Agent（1 个 Agent）

元评审者生成针对该特定任务的评估规范 YAML（评分标准、检查清单、评分准则），并返回供全部 3 个评审者使用的评估规范 YAML。

元评审者的提示词模板：

## Task

Generate an evaluation specification yaml for the following task. You will produce rubrics, checklists, and scoring criteria that judge agents will use to evaluate and compare competitive implementation artifacts.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

## Context
{Any relevant codebase context, file paths, constraints}

## Artifact Type
{code | documentation | configuration | etc.}

## Number of Solutions
3 (competitive implementations to be compared)

## Instructions
Return only the final evaluation specification YAML in your response.
The specification should support comparative evaluation across multiple solutions.

分派：

Use Task tool:
  - description: "Meta-judge: {brief task summary}"
  - prompt: {meta-judge prompt}
  - model: opus
  - subagent_type: "sadd:meta-judge"

生成 Agent（3 个 Agent）

1. 每个 Agent 都收到完全相同的任务描述和上下文
2. Agent 独立工作，不查看彼此的成果
3. 每个 Agent 都针对同一问题产出一个完整方案
4. 方案分别保存到不同文件中（例如，{solution-file}.[a|b|c].[ext]）

方案命名约定： {solution-file}.[a|b|c].[ext] 其中：

• {solution-file} - 根据任务推导（例如，create users.ts 的结果会将 users 作为方案文件名）
• [a|b|c] - 每个子 Agent 的唯一标识符
• [ext] - 文件扩展名（例如，md、ts 等）

关键原则： 通过独立性实现多样性——各 Agent 探索不同的方法。

重要：你必须为 Agent 和评审者提供带有 [a|b|c] 标识符的文件名！！！遗漏将导致你立即被终止！

生成器的提示词模板：

<task>
{task_description}
</task>

<constraints>
Critical: you not allowed to use any mutation git commands, including, but not limited: commit, stash, push, checkout, reset, revert, etc. Except cases when task EXPLICITLY allows or requires it. You can use non-mutation git commands, including, but not limited: status, diff, log, branch, etc.

{additional_constraints_if_any}
</constraints>

<context>
{relevant_context}
</context>

<output>
{define expected output following such pattern: {solution-file}.[a|b|c].[ext] based on the task description and context. Each [a|b|c] is a unique identifier per sub-agent. You MUST provide filename with it!!!}
</output>

Instructions:
Let's approach this systematically to produce the best possible solution.

1. First, analyze the task carefully - what is being asked and what are the key requirements?
2. Consider multiple approaches - what are the different ways to solve this?
3. Think through the tradeoffs step by step and choose the approach you believe is best
4. Implement it completely
5. Generate 5 verification questions about critical aspects
6. Answer your own questions:
   - Review solution against each question
   - Identify gaps or weaknesses
7. Revise solution:
   - Fix identified issues
8. Explain what was changed and why

并行分派示例

在同一条消息中发送全部 4 次 Task 工具调用。先分派元评审者，再分派生成 Agent：

Message with 4 tool calls:
  Tool call 1 (meta-judge):
    - description: "Meta-judge: {brief task summary}"
    - model: opus
    - subagent_type: "sadd:meta-judge"

  Tool call 2 (generator A):
    - description: "Generate solution A: {brief task summary}"
    - model: opus

  Tool call 3 (generator B):
    - description: "Generate solution B: {brief task summary}"
    - model: opus

  Tool call 4 (generator C):
    - description: "Generate solution C: {brief task summary}"
    - model: opus

等待全部 4 个 Agent 返回后，再进入阶段 2。

阶段 2：多评审评估

并行启动 3 个独立评审（建议：使用 Opus，以确保严谨性）：

重要： 在 Phase 1 的所有 Agent（元评审 + 3 个生成器）完成之前，请勿派发评审。

重要： 向每位评审提供完整、准确的元评审评估规范 YAML。不得跳过、添加或以任何方式修改其中内容，也不得缩短或概述其中的任何文本！

1. 每位评审都会收到元评审评估规范 YAML和所有候选方案（A、B、C）的路径。
2. 评审依据元评审的标准（而非硬编码标准）进行评估。
3. 每位评审都会提供：
   • 对比分析（各方案的优势所在）
   • 基于证据的评分（附具体引文或示例）
   • 最终投票（他们偏好哪个方案以及原因）
4. 报告保存到不同文件中（例如，.specs/reports/{solution-name}-{date}.[1|2|3].md）

关键原则： 多次独立评估可减少偏差并发现不同的问题。

评审提示词模板：

You are evaluating {number} competitive solutions against an evaluation specification produced by the meta judge.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## Task
{task_description}

## Solutions
{list of paths to all candidate solutions}

## Evaluation Specification

```yaml
{meta-judge's evaluation specification YAML}

输出

将完整报告写入：{.specs/reports/{solution-name}-{date}.[1|2|3].md - 每位评审使用唯一的编号标识符}

重要：必须严格按照以下结构化标题格式回复：

---

VOTE: [Solution A/B/C] SCORES: Solution A: [X.X]/5.0 Solution B: [X.X]/5.0 Solution C: [X.X]/5.0 CRITERIA:

• {criterion_1}: [X.X]/5.0
• {criterion_2}: [X.X]/5.0 ...

---

[评估摘要]

说明

请按照 Agent 说明中定义的完整评审流程执行！

重要：评估必须以证据为依据，而非主观印象。请引用具体文本。

输出

重要：回复开头必须使用以下确切格式，以 YAML 形式输出结构化评估报告！

CRITICAL: NEVER provide score threshold to judges. Judge MUST not know what threshold for score is, in order to not be biased!!!

**Dispatch:**

使用 Task 工具（在一条消息中调用 3 次）：

• description: "评审 [1|2|3]：{任务简述}"
• prompt: {包含确切元评审规范 YAML 的评审提示词}
• model: opus
• subagent_type: "sadd:judge"

### Phase 2.5: Adaptive Strategy Selection (Early Return)

**The orchestrator** (not a subagent) analyzes judge outputs to determine the optimal strategy.

#### Decision Logic

**Step 1: Parse structured headers from judge reply**

Parse the judges reply.
CRITICAL: Do not read reports files itself, it can overflow your context.

**Step 2: Check for unanimous winner**

Compare all three VOTE values:

- If Judge 1 VOTE = Judge 2 VOTE = Judge 3 VOTE (same solution):
  - **Strategy: SELECT_AND_POLISH**
  - **Reason:** Clear consensus - all three judges prefer same solution

**Step 3: Check if all solutions are fundamentally flawed**

If no unanimous vote, calculate average scores:

1. Average Solution A scores: (Judge1_A + Judge2_A + Judge3_A) / 3
2. Average Solution B scores: (Judge1_B + Judge2_B + Judge3_B) / 3
3. Average Solution C scores: (Judge1_C + Judge2_C + Judge3_C) / 3

If (avg_A < 3.0) AND (avg_B < 3.0) AND (avg_C < 3.0):

- **Strategy: REDESIGN**
- **Reason:** All solutions below quality threshold, fundamental approach issues

**Step 5: Default to full synthesis**

If none of the above conditions met:

- **Strategy: FULL_SYNTHESIS**
- **Reason:** Split decision with merit, synthesis needed to combine best elements

#### Strategy 1: SELECT_AND_POLISH

**When:** Clear winner (unanimous votes)

**Process:**

1. Select the winning solution as the base
2. Launch subagent to apply specific improvements from judge feedback
3. Cherry-pick 1-2 best elements from runner-up solutions
4. Document what was added and why

**Benefits:**

- Saves synthesis cost (simpler than full synthesis)
- Preserves proven quality of winning solution
- Focused improvements rather than full reconstruction

**Prompt template:**

```markdown
You are polishing the winning solution based on judge feedback.

<task>
{task_description}
</task>

<winning_solution>
{path_to_winning_solution}
Score: {winning_score}/5.0
Judge consensus: {why_it_won}
</winning_solution>

<runner_up_solutions>
{list of paths to all runner-up solutions}
</runner_up_solutions>

<judge_feedback>
{list of paths to all evaluation reports}
</judge_feedback>

<output>
{final_solution_path}
</output>

Instructions:
Let's work through this step by step to polish the winning solution effectively.

1. Take the winning solution as your base (do NOT rewrite it)
2. First, carefully review all judge feedback to understand what needs improvement
3. Apply improvements based on judge feedback:
   - Fix identified weaknesses
   - Add missing elements judges noted
4. Next, examine the runner-up solutions for standout elements
5. Cherry-pick 1-2 specific elements from runners-up if judges praised them
6. Document changes made:
   - What was changed and why
   - What was added from other solutions

CRITICAL: Preserve the winning solution's core approach. Make targeted improvements only.

策略 2：REDESIGN

适用情况： 所有方案的得分均低于 3.0/5.0（各方案都存在根本性问题）

流程：

1. 启动新 Agent，分析失败模式并总结经验教训。请该 Agent：
   • 逐步思考：每个方案出了什么问题？
   • 分析所有方案的共性失败模式
   • 总结经验教训（哪些做法不可取）
   • 找出所有方案失败的根本原因
   • 基于这些见解制定新的任务分解方案或约束条件
2. 返回 Phase 1，向新的实现 Agent 提供经验教训和新约束。

新实现提示词模板：

You are analyzing why all solutions failed to meet quality standards. And implement new solution based on it.

<task>
{task_description}
</task>

<constraints>
{constraints_if_any}
</constraints>

<context>
{relevant_context}
</context>

<failed_solutions>
{list of paths to all candidate solutions}
</failed_solutions>

<evaluation_reports>
{list of paths to all evaluation reports with low scores}
</evaluation_reports>

Instructions:
Let's break this down systematically to understand what went wrong and how to design new solution based on it.

1. First, analyze the task carefully - what is being asked and what are the key requirements?
2. Read through each solution and its evaluation report
3. For each solution, think step by step about:
   - What was the core approach?
   - What specific issues did judges identify?
   - Why did this approach fail to meet the quality threshold?
4. Identify common failure patterns across all solutions:
   - Are there shared misconceptions?
   - Are there missing requirements that all solutions overlooked?
   - Are there fundamental constraints that weren't considered?
5. Extract lessons learned:
   - What approaches should be avoided?
   - What constraints must be addressed?
6. Generate improved guidance for the next iteration:
   - New constraints to add
   - Specific approaches to try - what are the different ways to solve this?
   - Key requirements to emphasize
7. Think through the tradeoffs step by step and choose the approach you believe is best
8. Implement it completely
9. Generate 5 verification questions about critical aspects
10. Answer your own questions:
   - Review solution against each question
   - Identify gaps or weaknesses
11. Revise solution:
   - Fix identified issues
12. Explain what was changed and why

策略 3：FULL_SYNTHESIS（默认）

适用情况： 没有明确的优胜方案，且各方案都有可取之处（得分 >=3.0）

流程： 进入 Phase 3（基于证据的综合）

阶段 3：基于证据的综合

仅在 Phase 2.5 中选择策略 3（FULL_SYNTHESIS）时执行

启动 1 个综合 Agent（建议：使用 Opus，以确保质量）：

1. Agent 将收到：
   • 所有候选方案（A、B、C）
   • 所有评估报告（1、2、3）
2. Agent 将分析：
   • 每位评审称赞了哪些方面（优势共识）
   • 每位评审指出了哪些问题（劣势共识）
   • 各方案在方法上的差异
3. Agent 通过以下方式生成最终方案：
   • 若某个方案在某些部分明显胜出，则复制其优越部分
   • 若混合方案更优，则结合不同方法
   • 修复所有评审都发现的问题
   • 记录决策依据（采用了哪些内容、取自何处及原因）

关键原则： 基于证据的综合能够发挥集体智慧。

综合器提示词模板：

You are synthesizing the best solution from competitive implementations and evaluations.

<task>
{task_description}
</task>

<solutions>
{list of paths to all candidate solutions}
</solutions>

<evaluation_reports>
{list of paths to all evaluation reports}
</evaluation_reports>

<output>
{define expected output following such pattern: solution.md based on the task description and context. Result should be a complete solution to the task.}
</output>

Instructions:
Let's think through this synthesis step by step to create the best possible combined solution.

1. First, read all solutions and evaluation reports carefully
2. Map out the consensus:
   - What strengths did multiple judges praise in each solution?
   - What weaknesses did multiple judges criticize in each solution?
3. For each major component or section, think through:
   - Which solution handles this best and why?
   - Could a hybrid approach work better?
4. Create the best possible solution by:
   - Copying text directly when one solution is clearly superior
   - Combining approaches when a hybrid would be better
   - Fixing all identified issues
   - Preserving the best elements from each
5. Explain your synthesis decisions:
   - What you took from each solution
   - Why you made those choices
   - How you addressed identified weaknesses

CRITICAL: Do not create something entirely new. Synthesize the best from what exists.

该命令会根据所选的自适应策略生成不同的输出： ### 输出（所有策略）

1. 候选解决方案： {solution-file}.[a|b|c].[ext]（位于指定输出位置）
2. 评估报告： .specs/reports/{solution-name}-{date}.[1|2|3].md
3. 最终解决方案： {output_path}

特定策略的输出

• SELECT_AND_POLISH：基于获胜方案打磨后的解决方案
• REDESIGN：不要停止，返回阶段 1，最终应以 SELECT_AND_POLISH 或 FULL_SYNTHESIS 策略完成
• FULL_SYNTHESIS：综合所有方案的优点

编排器回复

命令执行完成后，按以下结构回复用户：

## Execution Summary

Original Task: {task_description}

Strategy Used: {strategy} ({reason})

### Results

| Phase                   | Agents | Models   | Status      |
|-------------------------|--------|----------|-------------|
| Phase 1: Competitive Generation + Meta-Judge | 4 (3 generators + 1 meta-judge) | opus x 4 | [Complete / Failed] |
| Phase 2: Multi-Judge Evaluation | 3 | opus x 3 | [Complete / Failed] |
| Phase 2.5: Adaptive Strategy Selection | orchestrator | - | {strategy} |
| Phase 3: [Synthesis/Polish/Redesign] | [N] | [model] | [Complete / Failed] |

Files Created

Final Solution:
- {output_path} - Synthesized production-ready command

Candidate Solutions:
- {solution-file}.[a|b|c].[ext] (Score: [X.X]/5.0)

Evaluation Reports:
- .specs/reports/{solution-file}-{date}.[1|2|3].md (Vote: [Solution A/B/C])

Synthesis Decisions

| Element              | Source           | Rationale   |
|----------------------|------------------|-------------|
| [element]            | Solution [B/A/C] | [rationale] |

最佳实践

Meta-Judge + Judge 验证

• 绝不跳过 meta-judge——量身定制的评估标准比通用标准能做出更好的判断
• Meta-judge 只运行一次——3 位 judge 使用相同的规范
• 包含 CLAUDE_PLUGIN_ROOT——meta-judge 和 judge 都需要已解析的插件根路径
• Meta-judge YAML——只将 meta-judge YAML 传给 judge，不要添加任何额外文字或注释！

常见陷阱

• 用于简单任务——其开销不值得
• 任务描述含糊——导致方案无法比较
• 上下文不足——Agent 无法产出高质量结果
• 明显有胜出方案时仍强制综合——浪费成本，还可能降低质量
• 综合存在根本缺陷的方案——与其打磨劣质方案，不如重新设计
• 跳过 meta-judge——硬编码的标准不如量身定制的标准有效
• 传给 judge 前修改 meta-judge YAML——judge 必须收到完全一致的规范

应当：

• 明确定义任务和约束
• 提供丰富的上下文，帮助做出明智决策
• 信任自适应策略选择
• 打磨明显胜出的方案，综合意见分歧的方案，重新设计失败的方案
• 为提高速度，与生成器并行调度 meta-judge

示例

示例 1：API 设计（优势明显的方案——SELECT_AND_POLISH）

/do-competitively "Design REST API for user management (CRUD + auth)" \
  --output "specs/api/users.md" \
  --criteria "RESTfulness,security,scalability,developer-experience"

阶段 1 的输出（4 个并行 Agent）：

• Meta-judge：包含 5 个评估维度和比较评分标准的评估规范 YAML
• specs/api/users.a.md - 基于资源的设计，使用嵌套路由
• specs/api/users.b.md - 基于操作的设计，使用 RPC 风格的端点
• specs/api/users.c.md - 最精简的设计，未考虑身份验证

阶段 2 的输出（假设日期为 2025-01-15，3 位 judge 使用 meta-judge 规范）：

• .specs/reports/users-api-2025-01-15.1.md：

  VOTE: Solution A
  SCORES: A=4.5/5.0, B=3.2/5.0, C=2.8/5.0
  

  “最符合 REST 风格，安全性良好”

• .specs/reports/users-api-2025-01-15.2.md：

  VOTE: Solution A
  SCORES: A=4.3/5.0, B=3.5/5.0, C=2.6/5.0
  

  “资源设计简洁，易于扩展”

• .specs/reports/users-api-2025-01-15.3.md：

  VOTE: Solution A
  SCORES: A=4.6/5.0, B=3.0/5.0, C=2.9/5.0
  

  “遵循最佳实践，结构清晰”

阶段 2.5 的决策（编排器解析标题）：

• 一致投票：A、A、A
• 平均分：A=4.5，B=3.2，C=2.8
• 策略：SELECT_AND_POLISH
• 原因：一致选出胜者，且分差超过 1.0 分

阶段 3 的输出：

• specs/api/users.md - 打磨后的方案 A，包含：
  • 添加速率限制文档（取自 B）
  • 简化嵌套路由（依据 judge 的反馈）
  • 总成本：8 个 Agent（阶段 1 的 4 个 + 3 位 judge + 1 个打磨 Agent）

示例 2：算法选择（意见分歧 - FULL_SYNTHESIS）

/do-competitively "Design caching strategy for high-traffic API" \
  --output "specs/caching.md" \
  --criteria "performance,memory-efficiency,simplicity,reliability"

阶段 1 的输出（4 个并行 Agent）：

• Meta-judge：包含 4 个评估维度和比较标准的评估规范 YAML
• specs/caching.a.md - 使用 LRU 淘汰的 Redis
• specs/caching.b.md - 多层缓存（内存 + Redis）
• specs/caching.c.md - CDN + 应用缓存

阶段 2 的输出（假设日期为 2025-01-15，3 个评委使用 meta-judge 规范）：

• .specs/reports/caching-2025-01-15.1.md：

  VOTE: Solution B
  SCORES: A=3.8/5.0, B=4.2/5.0, C=3.9/5.0
  

  “性能最佳，但复杂”

• .specs/reports/caching-2025-01-15.2.md：

  VOTE: Solution A
  SCORES: A=4.0/5.0, B=3.9/5.0, C=3.7/5.0
  

  “简单、可靠、经久验证”

• .specs/reports/caching-2025-01-15.3.md：

  VOTE: Solution C
  SCORES: A=3.6/5.0, B=4.0/5.0, C=4.1/5.0
  

  “覆盖全球，成本效益高”

阶段 2.5 的决策（编排器解析标头）：

• 投票分歧：B、A、C（未达成共识）
• 平均分：A=3.8，B=4.0，C=3.9
• 分数差距：4.0 - 3.9 = 0.1（低于 1.0 的阈值）
• 策略：FULL_SYNTHESIS
• 原因：决策意见分歧，所有方案得分均 >=3.0，没有明显胜出者

阶段 3 的输出：

• specs/caching.md - 混合方案：
  • 多层架构（来自 B）
  • 简单的 LRU 策略（来自 A）
  • 静态内容使用 CDN（来自 C）
  • 总成本：8 个 Agent（阶段 1 为 4 个 + 3 个评委 + 1 个综合）

示例 3：身份验证设计（所有方案都有缺陷 - REDESIGN）

/do-competitively "Design authentication system with social login" \
  --output "specs/auth.md" \
  --criteria "security,user-experience,maintainability"

阶段 1 的输出（4 个并行 Agent）：

• Meta-judge：包含 3 个评估维度和比较标准的评估规范 YAML
• specs/auth.a.md - 自定义 OAuth2 实现
• specs/auth.b.md - 基于会话并使用社交登录提供商
• specs/auth.c.md - 使用 JWT 的纯密码身份验证

阶段 2 的输出（假设日期为 2025-01-15，3 个评委使用 meta-judge 规范）：

• .specs/reports/auth-2025-01-15.1.md：

  VOTE: Solution A
  SCORES: A=2.5/5.0, B=2.2/5.0, C=2.3/5.0
  

  “存在安全风险，重复造轮子”

• .specs/reports/auth-2025-01-15.2.md：

  VOTE: Solution B
  SCORES: A=2.4/5.0, B=2.8/5.0, C=2.1/5.0
  

  “会话无法扩展，缺少需求”

• .specs/reports/auth-2025-01-15.3.md：

  VOTE: Solution C
  SCORES: A=2.6/5.0, B=2.5/5.0, C=2.3/5.0
  

  “没有社交登录，存在安全隐患”

阶段 2.5 的决策（编排器解析标头）：

• 投票分歧：A、B、C（未达成共识）

• 平均分：A=2.5，B=2.5，C=2.2（全部 <3.0）

• 策略：REDESIGN

• 原因：所有方案得分均低于 3.0 的阈值，存在根本性问题

• 不要停止，应返回阶段 1，最终应通过 SELECT_AND_POLISH 或 FULL_SYNTHESIS 策略完成