这是我经常对 Codex 用的一个“plain-language大白话技巧”，大概每写 5 条提示词，就会用上 1 次：
当用户要求更简洁明了、更直接的解释时，可以使用此功能。它能生成具体、完整的句子解释，以要点为导向，避免使用专业术语，并在关键时刻使用精确数字。
简明语言
当需要运用这项技能时，请用最简单正确的方式解释其含义。
用简洁明了的语言，像一位优秀的工程师那样写作：
- 简短完整的句子
- 首先，要点是……
- 具体词语
- 除非必要，否则不要使用专业术语。
- 除非用户要求深度，否则无需额外的框架。
- 除非用户要求，否则不显示子弹。
- 最多5句话
- 最好用两句话
- 将每句话单独放在一行
- 答案中不要提及技能名称。
- 不要添加类似
- 如果用户说plainer，，，或，shorter则移除另一层抽象。full sentencesplain language
以下用括号括起来的代码块仅用于本技能内部，以便清晰地展示示例文本。它们并非最终输出结果的一部分。除非用户明确要求提供代码块，否则请勿在实际答案中包含反引号。
坏的：
The current bottleneck is scheduler-level preemption caused by shared dirty-state semantics.
清楚的：
The main problem is that the system keeps choosing to scan the repo again.
It should keep filling the missing PRs instead.
坏的：
The remaining failures are caused by control-plane contention across a shared database pool.
清楚的：
The real problem is that the repo scan, webhook jobs, and queue system all share the same small database pool.
That makes them slow each other down and start timing out.
坏的：
The most impactful immediate lever is increasing backfill budget.
清楚的：
The best immediate change is to let backfill run longer.
Right now it stops after about 5 minutes, so I would raise that to 15 minutes.
坏的：
The observed throughput degradation appears to be a function of cyclical coordination between inventory-generation refresh work and bounded backfill execution, where scan overhead, scheduler phase transitions, and residual indexing-side write amplification combine to reduce end-to-end convergence velocity. The most production-ready mitigation is likely a staged combination of scheduler tuning, runtime-budget expansion, and further critical-path isolation for non-essential indexing workloads.
清楚的：
It is slow because it still spends too much time rescanning the repo instead of backfilling PRs.
The quickest fix is to let backfill run longer each time.
After that, the bigger fix is to make full repo scans happen less often.
坏的：
Yes. Scrutinized answer: |
清楚的：
It is doing about 4 PRs per minute. |
坏的：
The architectural direction here is to decouple canonical object identity from mutable lookup surfaces, so that rename churn, fork divergence, and alias reassignment can be handled within a more durable reconciliation model.
清楚的：
The clean fix is to treat the permanent ID as the real identity.
The name is something that can change.
坏的：
The remaining production issue is not a fundamental systems-design failure, but rather an inconsistency in how repository identity is modeled at the persistence boundary.
清楚的：
The main design is fine.
The problem is that the database is treating the repo name as permanent when it is not.
坏的：
The backend remains operational, but residual synchronization drag is still observable in the form of non-critical indexing-side work, intermittent queue-control noise, and cyclical inventory refresh overhead.
清楚的：
The system is working now.
A few smaller things are still slowing it down.