# How to Beat GRPO Without Touching Model Weights
**作者**: Akshay
**日期**: 2026-04-30T18:17:40.000Z
**来源**: [https://x.com/akshay_pachaar/status/2049916107923034300](https://x.com/akshay_pachaar/status/2049916107923034300)
---
A team at Berkeley beat GRPO by 10 points with 35× fewer rollouts and no GPU training, and why most teams are still doing prompt optimization the wrong way.
You spent two weeks fine-tuning an 8B model with GRPO. Burned $40,000 in compute. Got a 7-point bump on your benchmark.
A team at Berkeley ran a different optimizer on the same setup. Spent under $1,000. Beat your score by 10 points.
No weight updates. No GPUs. Just prompts.
That's GEPA. The paper dropped in July 2025. Nine months later, it was accepted as an ICLR 2026. DSPy made it a first-class optimizer. Hugging Face and OpenAI shipped cookbooks. Shopify's CEO publicly said it's underhyped.
If you skipped GEPA when it came out, this is your second chance.
Let's break down why it works and how to use it in DSPy.
# The dirty secret of RL on LLMs
Here's the thing nobody tells you about reinforcement learning on language models.
Every rollout your agent produces is a 5,000-token document, containing:
- Reasoning steps
- Tool calls
- Self-corrections
- Compiler errors
- Judge rationales
Rich, structured, full of useful information.
GRPO takes all of that and reduces it to a single number.
Was this trajectory better or worse than the group average? +1 or -1. That's your learning signal.
You just threw away thousands of bits of structured information so you could backprop on one bit per trajectory. Then you wonder why RL needs tens of thousands of rollouts to converge.
The signal isn't sparse. You made it sparse.
# What if the signal could read itself?
Here's the GEPA bet in one sentence: the rollout is already a natural language artifact, so let an LLM read it.
Don't reduce the trace to a number. Hand it to a reflection model along with the failure mode, and ask: "What went wrong here, and how should the prompt change?"
The reflection model writes a new prompt. You test it. If it improves, keep it.
That's the entire core idea.
The rest is engineering details that make it work at scale.
# What GEPA actually optimizes
GEPA targets compound AI systems. Think DSPy programs.
A pipeline of LLM modules with their own prompts, glued together by Python control flow. A multi-hop QA agent might have:
- A first-hop query writer
- A retriever
- A summarizer
- A second-hop query writer
- A final answerer
Each module has a prompt. GEPA evolves all of them.
The optimization target is simple: maximize expected metric on your task, subject to a rollout budget B. The novelty is in how you spend that budget.
# The feedback function: where the magic lives
GEPA replaces your scalar metric with a feedback function μ_f. Same score, plus a natural language description of what happened.
- For HotpotQA, μ_f returns which gold docs you retrieved and which you still need.
- For instruction-following, it returns per-constraint pass/fail descriptions.
- For code generation, it returns the actual compiler errors and profiler traces.
- For privacy-preserving rewriting, it splits the score into quality and PII-leakage with breakdowns.
# The algorithm in six steps
Each iteration of the main loop does this:
1. Pick a candidate prompt set from the population (Pareto sampling, more on this below)
2. Pick a module to mutate (round-robin across modules)
3. Sample 3 examples from the training set
4. Run rollouts and collect full traces plus feedback from μ_f
5. Reflect: feed traces and feedback to a reflection LLM, get a new prompt
6. Accept or reject: rerun on the same 3 examples. If better, keep it. If not, discard.
Repeat until budget runs out. Return the best candidate.
That's it. No gradients. No PPO. No KL penalties.
# GEPA vs GRPO, head to head
A quick look at GRPO first:
Both take feedback and improve a system. That's where the similarity ends.
GRPO updates model weights with policy gradients on scalar rewards. GEPA updates prompts with natural language reflection on full traces.
Two completely different approaches.
Here's the side-by-side:
One important caveat. GRPO can change what your model knows. GEPA can only change how you ask it.
If your base model can't do the task at all, no prompt evolution will save you. Fine-tune when you need new capabilities. Use GEPA when you need to extract more from what's already there.
# A real example
Let's make this concrete with a real example from the paper.
The task: HotpotQA is a multi-hop question answering benchmark. You get a question that needs information from two different Wikipedia articles to answer. You can't find the answer in just one place.
Example question: "What is the population of the region containing the parish of São Vicente?"
To answer this, your agent has to:
1. First hop: Search for "São Vicente parish", retrieve a doc, learn it's in Madeira
2. Second hop: Search for "Madeira population", retrieve that doc, get the number
3. Answer: Combine both
The agent has separate modules for each hop. We're going to look at the prompt for the second-hop query writer, the module that decides what to search for after the first retrieval.
Inputs the module receives:
- question: the original user question
- summary_1: a summary of what the first hop retrieved
Output it produces:
- query: the search query for the second hop
Here's the seed prompt that DSPy gives you by default:
> "Given the fields question, summary_1, produce the fields query."
Generic. Just describes the schema. Scores around 38% on validation.
GEPA runs this on a few examples and watches what happens. The query writer keeps doing the same thing wrong: it paraphrases the original question and retrieves the same documents it already had.
For our São Vicente example, given a summary about the parish, it would search "São Vicente parish population" again. Retrieves nothing new. Fails.
The reflection LLM sees this failure pattern across multiple examples in the trace. It writes a new prompt:
> "Generate a search query optimized for the second hop of multi-hop retrieval. The first-hop query was the original question, so first-hop docs already cover the entities mentioned directly. Your goal: retrieve documents NOT found in the first hop but necessary to answer completely. Avoid paraphrasing the original question. Target connected or higher-level entities mentioned in summary_1 but not explicitly in the question. Example: if summary_1 describes a parish but the question asks about the wider region's total population, your query should target the region, not the parish. So for a question about São Vicente's region, query 'Madeira archipelago population' rather than 'São Vicente population'."
New score: 69%.
Same model. Same task. The only thing that changed was the prompt for one module out of several.
Notice what happened. The reflection LLM didn't just rephrase the seed. It absorbed an actual strategy from observed failures:
- Don't paraphrase the question
- The first hop already covered the directly-mentioned entities
- Target the broader entity that connects them
- Here's a worked example of the pattern
That's the kind of information you cannot encode in a policy gradient. RL would just tell you "this trajectory was 0.3 below the group mean" and let backprop figure it out across thousands of tokens. GEPA writes the lesson down in plain English and ships it as the new prompt.
# Pareto selection: the move that makes it work
Here's where most evolutionary prompt optimizers die.
The naive approach: always mutate from the best candidate so far. Sounds reasonable. Collapses to local optima fast.
GEPA uses something smarter, borrowed from quality-diversity optimization.
Imagine three candidate prompts and four tasks:
Greedy picks C every time. C has the best average.
But A is the only one that handles Task 1 well. B is the only one that nails Task 2. If you only ever mutate from C, you lose those strategies forever.
Pareto selection keeps anyone who's best at at least one task. Then it samples parents weighted by how many tasks they win. So C is most likely to be picked, but A and B stay in the pool. Their distinctive strengths can later be combined with C's.
This single design choice is what separates GEPA from earlier evolutionary prompt methods.
# Where GEPA fits in the landscape
Quick map of who does what:
- APE, OPRO: LLM-as-optimizer, single prompt, scalar feedback. Older generation.
- EvoPrompt, Promptbreeder: Evolutionary, single prompt, scalar fitness. Genetic structure but no reflection.
- Reflexion: Verbal feedback, but per-task memory rather than population evolution.
- TextGrad: Textual gradients that propagate through computation graphs. No population.
- MIPROv2: Bayesian search over instructions plus bootstrapped few-shot demos. DSPy's prior flagship.
- GRPO: Actual RL with weight updates. Different beast entirely.
GEPA is the synthesis. Reflection from Reflexion. Population evolution from EvoPrompt. Compound system focus from MIPROv2. Pareto selection that's genuinely new.
# Using it in DSPy
The API is one line different from MIPROv2:
```
optimizer = dspy.GEPA(
metric=metric_with_feedback,
auto="medium",
reflection_minibatch_size=3,
candidate_selection_strategy="pareto",
reflection_lm=dspy.LM("gpt-5", temperature=1.0, max_tokens=32000),
use_merge=True,
track_stats=True,
)
optimized = optimizer.compile(program, trainset=train, valset=val)
```
The catch: your metric function needs the right signature.
```
def metric(gold, pred, trace=None, pred_name=None, pred_trace=None):
# return dspy.Prediction(score=float, feedback=str)
```
Return a prediction with both a score and a feedback string. The feedback is what gets fed to the reflection LLM. Make it diagnostic. Make it specific.
If your feedback string is just "wrong answer", you're back to scalar territory and GEPA degrades to a slower MIPROv2.
If your feedback says "missed entity X, retrieved doc Y when gold was Z, format violation in step 3", GEPA flies.
# A 2026 reality check
The "beats RL" headline is real, but worth being precise about.
GEPA beats GRPO specifically. Not every RL method. The field has stopped framing this as GEPA vs RL and started framing it as GEPA and RL. The paper itself points to hybrid recipes like BetterTogether and mmGRPO as the natural next step.
The honest summary: reflection is far more sample-efficient than RL on compound systems. The two are increasingly combined, not pitted against each other.
One more nuance worth knowing. Decagon's March 2026 production ablations found that more data isn't always better with GEPA. 20 to 100 examples often beats 500. The reflection loop overfits when you feed it too much.
Hermes agent uses GEPA for evolving skills, which helps it learn with you and getting better with time.
Counter-intuitive, but it tracks. GEPA learns from patterns in failures. With 50 well-chosen examples, the reflector sees clean signal. With 500, it starts chasing noise.
Use small, high-quality training sets. Don't assume scale helps.
# When to reach for what
If you're building a compound AI system today, here's the decision tree.
- Use GEPA when: You have a small training set, expensive rollouts, no access to weights, and a metric you can describe in words.
- Use GRPO when: You have abundant cheap rollouts, open weights, and a verifiable terminal reward.
- Use MIPROv2 when: You specifically need bootstrapped few-shot exemplars in your prompts.
- Use TextGrad when: Your computation graph is deep and you want explicit per-variable critique propagation.
For most practical compound-system work in 2026, GEPA is the default to try first.
RL isn't dead. It's just no longer the obvious answer when reading a rollout costs less than running ten thousand more.
References:
- https://arxiv.org/abs/2507.19457
- https://dspy.ai/api/optimizers/GEPA/overview/
Thanks for reading!
If you found it insightful, reshare with your network.
Find me →@akshay_pachaar ✔️
For more insights and tutorials on LLMs, AI Agents, and Machine Learning!
## 相关链接
- [Akshay](https://x.com/akshay_pachaar)
- [@akshay_pachaar](https://x.com/akshay_pachaar)
- [12K](https://x.com/akshay_pachaar/status/2049916107923034300/analytics)
- [DSPy](https://dspy.ai/)
- [https://arxiv.org/abs/2507.19457](https://arxiv.org/abs/2507.19457)
- [https://dspy.ai/api/optimizers/GEPA/overview/](https://dspy.ai/api/optimizers/GEPA/overview/)
- [@akshay_pachaar](https://x.com/@akshay_pachaar)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:17 AM · May 1, 2026](https://x.com/akshay_pachaar/status/2049916107923034300)
- [12.6K Views](https://x.com/akshay_pachaar/status/2049916107923034300/analytics)
---
*导出时间: 2026/5/1 12:38:33*
---
## 中文翻译
# 如何在不接触模型权重的情况下击败 GRPO
**作者**: Akshay
**日期**: 2026-04-30T18:17:40.000Z
**来源**: [https://x.com/akshay_pachaar/status/2049916107923034300](https://x.com/akshay_pachaar/status/2049916107923034300)
---
伯克利的一个团队以 35 倍少的 rollouts（推演）数量且无需 GPU 训练，击败了 GRPO 整整 10 分，而这也是大多数团队仍在错误地进行提示词优化的原因。
你花了两周时间用 GRPO 微调了一个 8B 模型。烧掉了 4 万美元的计算成本。在你的基准测试上提升了 7 分。
伯克利的一个团队在同一设置上运行了一个不同的优化器。花费不到 1000 美元。击败了你的分数 10 分。
没有权重更新。没有 GPU。只有提示词。
这就是 GEPA。该论文于 2025 年 7 月发布。九个月后，它被 ICLR 2026 接收。DSPy 将其作为一等优化器。Hugging Face 和 OpenAI 发布了官方手册。Shopify 的 CEO 公开表示它被低估了。
如果你在 GEPA 发布时错过了它，这是你的第二次机会。
让我们来分解一下它为什么有效，以及如何在 DSPy 中使用它。
# 大语言模型强化学习不可告人的秘密
这是关于语言模型强化学习没人告诉你的事情。
你的 Agent 产生的每一次 rollout 都是一个包含 5000 个 token 的文档，其中包含：
- 推理步骤
- 工具调用
- 自我修正
- 编译器错误
- 判决器理由
丰富、结构化，充满有用的信息。
GRPO 获取所有这些并将其简化为一个单一的数字。
这条轨迹是优于还是劣于组内平均水平？+1 或 -1。这就是你的学习信号。
你刚刚丢弃了数千比特的结构化信息，以便你可以在每条轨迹的一个比特上进行反向传播。然后你怀疑为什么 RL 需要数万次 rollouts 才能收敛。
信号并不稀疏。是你让它变得稀疏了。
# 如果信号能读懂自己会怎样？
用一句话概括 GEPA 的赌注：rollout 本身就是一个自然语言产物，所以让 LLM 来阅读它。
不要将轨迹简化为一个数字。将其连同失败模式一起交给一个反思模型，并问：“这里哪里出了问题，提示词应该如何改变？”
反思模型编写一个新的提示词。你测试它。如果它有改进，就保留它。
这就是整个核心思想。
其余的都是使其能够大规模工作的工程细节。
# GEPA 实际上优化了什么
GEPA 针对复合 AI 系统。比如 DSPy 程序。
一个由 LLM 模块组成的流水线，每个模块都有自己的提示词，通过 Python 控制流粘合在一起。一个多跳问答 Agent 可能包含：
- 第一跳查询编写器
- 检索器
- 总结器
- 第二跳查询编写器
- 最终答案生成器
每个模块都有一个提示词。GEPA 对它们全部进行进化。
优化目标很简单：在 rollout 预算 B 的约束下，最大化任务上的预期指标。新颖之处在于你如何花费该预算。
# 反馈函数：魔法所在的地方
GEPA 用一个反馈函数 μ_f 替换了你的标量指标。分数相同，外加对发生情况的自然语言描述。
- 对于 HotpotQA，μ_f 返回你检索到了哪些黄金文档以及你仍然需要哪些。
- 对于指令遵循，它返回每个约束的通过/失败描述。
- 对于代码生成，它返回实际的编译器错误和分析器跟踪。
- 对于隐私保护重写，它将分数拆分为质量和 PII 泄露，并提供细分。
# 算法分六步
主循环的每次迭代都会执行以下操作：
1. 从种群中选择一个候选提示词集（帕累托采样，下文详述）
2. 选择一个模块进行变异（在模块间轮询）
3. 从训练集中采样 3 个样本
4. 运行 rollouts 并收集完整轨迹以及来自 μ_f 的反馈
5. 反思：将轨迹和反馈提供给反思 LLM，获得一个新的提示词
6. 接受或拒绝：在相同的 3 个样本上重新运行。如果更好，保留它。如果不行，丢弃。
重复直到预算耗尽。返回最佳候选。
就是这样。没有梯度。没有 PPO。没有 KL 惩罚。
# GEPA 对决 GRPO，正面交锋
先快速看一下 GRPO：
两者都接收反馈并改进系统。相似之处仅此而已。
GRPO 使用基于标量奖励的策略梯度来更新模型权重。GEPA 使用基于完整轨迹的自然语言反思来更新提示词。
两种完全不同的方法。
以下是并列对比：
一个重要的注意事项。GRPO 可以改变你的模型所知道的知识。GEPA 只能改变你提问的方式。
如果你的基础模型根本无法完成该任务，没有任何提示词进化能拯救你。当你需要新能力时，进行微调。当你需要从现有模型中挖掘更多潜力时，使用 GEPA。
# 一个真实的例子
让我们用论文中的一个真实例子来具体说明。
任务：HotpotQA 是一个多跳问答基准。你会得到一个问题，需要来自两个不同维基百科文章的信息来回答。你不能仅在一个地方找到答案。
示例问题：“包含 São Vicente 教区的地区人口是多少？”
为了回答这个问题，你的 Agent 必须：
1. 第一跳：搜索“São Vicente parish”，检索一个文档，得知它在马德拉
2. 第二跳：搜索“Madeira population”，检索该文档，获取数字
3. 回答：结合两者
Agent 为每一跳都有单独的模块。我们要看看第二跳查询编写器的提示词，即决定在第一次检索后搜索什么的模块。
模块接收的输入：
- question：原始用户问题
- summary_1：第一跳检索内容的摘要
它产生的输出：
- query：第二跳的搜索查询
这是 DSPy 默认给你的种子提示词：
> "Given the fields question, summary_1, produce the fields query."
（“给定字段 question, summary_1，生成字段 query。”）
很通用。只是描述了模式。在验证集上得分约 38%。
GEPA 在几个样本上运行并观察发生了什么。查询编写器反复犯同样的错误：它改写了原始问题并检索了它已有的相同文档。
对于我们的 São Vicente 示例，鉴于关于教区的摘要，它会再次搜索“São Vicente parish population”。没有检索到任何新内容。失败。
反思 LLM 在轨迹中的多个样本中看到了这种失败模式。它编写了一个新的提示词：
> "Generate a search query optimized for the second hop of multi-hop retrieval. The first-hop query was the original question, so first-hop docs already cover the entities mentioned directly. Your goal: retrieve documents NOT found in the first hop but necessary to answer completely. Avoid paraphrasing the original question. Target connected or higher-level entities mentioned in summary_1 but not explicitly in the question. Example: if summary_1 describes a parish but the question asks about the wider region's total population, your query should target the region, not the parish. So for a question about São Vicente's region, query 'Madeira archipelago population' rather than 'São Vicente population'."
（“生成一个针对多跳检索第二跳优化的搜索查询。第一跳查询是原始问题，因此第一跳文档已经涵盖了直接提到的实体。你的目标：检索第一跳中未找到但完全回答所必需的文档。避免改写原始问题。针对 summary_1 中提到但未在问题中明确指出的相关或更高级别的实体。例如：如果 summary_1 描述了一个教区，但问题询问更广泛地区的总人口，你的查询应针对该地区，而不是教区。因此，对于关于 São Vicente 地区的问题，查询‘马德拉群岛人口’而不是‘São Vicente 人口’。”）
新分数：69%。
同样的模型。同样的任务。唯一改变的是几个模块中其中一个的提示词。
注意发生了什么。反思 LLM 不仅仅是改写了种子提示词。它从观察到的失败中吸收了一个实际的策略：
- 不要改写问题
- 第一跳已经涵盖了直接提到的实体
- 针对连接它们的更广泛的实体
- 这里有一个该模式的具体示例
这是你无法在策略梯度中编码的信息类型。RL 只会告诉你“这条轨迹比组内均值低 0.3”，然后让反向传播在数千个 token 中弄清楚。GEPA 将教训用清晰的英语写下来，并将其作为新提示词发布。
# 帕累托选择：使其奏效的关键举措
这就是大多数进化提示词优化器消亡的地方。
幼稚的方法：总是从迄今为止最好的候选进行变异。听起来很合理。很快就会塌陷到局部最优。
GEPA 使用了更聪明的方法，借鉴了质量-多样性优化。
想象三个候选提示词和四个任务：
贪婪算法总是选择 C。C 具有最好的平均水平。
但 A 是唯一能很好处理任务 1 的。B 是唯一能搞定任务 2 的。如果你只从 C 变异，你就永远失去了那些策略。
帕累托选择保留在任何至少一项任务上表现最好的人。然后根据他们获胜的任务数量加权采样父母。所以 C 最有可能被选中，但 A 和 B 保留在池中。它们独特的优势稍后可以与 C 的结合。
这单一的设计选择就是 GEPA 与早期进化提示词方法的区别所在。
# GEPA 在领域中的定位
快速映射一下谁做什么：
- APE, OPRO：LLM 即优化器，单提示词，标量反馈。老一代。
- EvoPrompt, Promptbreeder：进化式，单提示词，标量适应度。遗传结构但没有反思。
- Reflexion：语言反馈，但是基于任务的记忆而不是种群进化。
- TextGrad：通过计算图传播的文本梯度。没有种群。
- MIPROv2：基于指令的贝叶斯搜索加上引导的少样本演示。DSPy 先前的旗舰产品。
- GRPO：带有权重更新的实际 RL。完全不同的野兽。
GEPA 是集大成者。来自 Reflexion 的反思。来自 EvoPrompt 的种群进化。来自 MIPROv2 的复合系统关注。真正新颖的帕累托选择。
# 在 DSPy 中使用它
API 与 MIPROv2 仅有一行之差：
```
optimizer = dspy.GEPA(
metric=metric_with_feedback,
auto="medium",
reflection_minibatch_size=3,
candidate_selection_strategy="pareto",
reflection_lm=dspy.LM("gpt-5", temperature=1.0, max_tokens=32000),
use_merge=True,
track_stats=True,
)
optimized = optimizer.compile(program, trainset=train, valset=val)
```
关键在于：你的指标函数需要正确的签名。
```
def metric(gold, pred, trace=None, pred_name=None, pred_trace=None):
# return dspy.Prediction(score=float, feedback=str)
```
返回一个包含分数和反馈字符串的预测。反馈是输入给反思 LLM 的内容。使其具有诊断性。使其具体。
如果你的反馈字符串只是“答案错误”，你就回到了标量领域，GEPA 会降级为一个更慢的 MIPROv2。
如果你的反馈说“遗漏了实体 X，当黄金标准是 Z 时检索了文档 Y，步骤 3 格式违规”，GEPA 就会起飞。
# 2026 年的现实检验
“击败 RL”的标题是真实的，但值得精确对待。
GEPA 具体击败的是 GRPO。不是所有的 RL 方法。该领域已经停止将其框架化为 GEPA 对决 RL，并开始将其框架化为 GEPA 和 RL。该论文本身指向 BetterTogether 和 mmGRPO 等混合方法作为自然的下一步。
诚实的总结：在复合系统上，反思比 RL 具有高得多的样本效率。两者越来越多地结合在一起，而不是相互对立。
还有一个值得知道的细微差别。Decagon 2026 年 3 月的生产消融实验发现，对于 GEPA 来说，更多数据并不总是更好的。20 到 100 个样本通常胜过 500 个。当你喂给它太多时，反思循环会过拟合。
Hermes agent 使用 GEPA 来进化技能，这有助于它与你一起学习并随着时间的推移变得更好。
反直觉，但这是有道理的。GEPA 从失败模式中学习。对于 50 个精心挑选的样本，反思器看到的是清晰的信号。对于 500 个，它开始追逐噪声。
使用小型、高质量的训练集。不要假设规模会有帮助。
# 什么时候该用什么
如果你今天正在构建一个复合 AI 系统，这里是决策树。
- 使用 GEPA 当：你有一个小的训练集、昂贵的 rollouts、无法访问权重，以及一个可以用语言描述的指标。
- 使用 GRPO 当：你有大量便宜的 rollouts、开放的权重，以及一个可验证的终端奖励。
- 使用 MIPROv2 当：你特别需要在提示词中使用引导的少样本示例。
- 使用 TextGrad 当：你的计算图很深，并且你想要显式的逐变量批评传播。
对于 2026 年大多数实际的复合系统工作，GEPA 是首选的默认尝试选项。
RL 并没有死。它只是不再是显而易见的答案了，因为阅读一次 rollout 的成本低于运行一万次。
参考资料：
- https://arxiv.org/abs/2507.19457
- https://dspy.ai/api/optimizers/GEPA/overview/
感谢阅读！
如果你觉得有见地，请在你的网络中转发分享。
Find me →@akshay_pachaar ✔️
获取更多关于 LLM、AI Agent 和机器学习的见解和教程！
## 相关链接
- [Akshay](https://x.com/akshay_pachaar)
- [@akshay_pachaar](https://x.com/akshay_pachaar)
- [12K](https://x.com/akshay_pachaar/status/2049916107923034300/analytics)
- [DSPy](https://dspy.ai/)
- [https://arxiv.org/abs/2507.19457](https://arxiv.org/abs/2507.19457)
- [https://dspy.ai/api/optimizers/GEPA/overview/](https://dspy.ai/api/optimizers/GEPA/overview/)
- [@akshay_pachaar](https://x.com/@akshay_pachaar)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:17 AM · May 1, 2026](https://x.com/akshay_pachaar/status/2049916107923034300)
- [12.6K Views](https://x.com/akshay_pachaar/status/2049916107923034300/analytics)
---
*导出时间: 2026/5/1 12:38:33*