在和AI长期协作的实践里，我发现一个普遍又扎心的问题：当推理卡住、思路循环、迟迟给不出有效答案时，很多人的第一反应是“施压式对话”——反复强调“你必须解决”“给我正确答案”“不准出错”，本质就是对AI进行PUA式引导。
但实践结果恰恰相反：这种做法不会让AI变得更聪明，只会大幅提升幻觉编造的概率。它会为了满足指令，拼凑看似合理、实则错误的结论，让问题从“没答案”变成“错答案”，反而更难纠正。
真正高效的解法，不是施压，而是用一套标准化流程，帮AI跳出循环、回归理性。这套方法经过多次实测，能快速把“卡死的AI”拉回正轨。
在人工智能领域，尤其是生成式AI（如大语言模型）和应用开发平台中，理解一些核心术语，能帮助我们更好地使用和探索这项技术。
Prompt 是用户输入给 AI 模型（如 ChatGPT、Midjourney 等）的指令、问题或文本，用于引导模型生成特定的输出。它是人与模型交互的接口，其质量直接影响AI输出的质量。这也是“提示工程”（Prompt Engineering）兴起的根本原因——通过精心设计输入，让模型产生更准确、更有价值的结果。
一个结构良好的 Prompt 通常包含以下要素：
某游戏中有一个升级系统，每次尝试升级时，会有一定的概率成功或失败，成功后则等级+1，失败则等级不变。升级时会消耗一定的资源，升级成功的概率和资源的消耗量都仅与当前等级有关。具体规则如下：
| 当前等级 | 成功率 | 升级消耗 |
|---|---|---|
| 0 ~ 2 | 35% | 10 |
| 3 ~ 6 | 20% | 20 |
| 7 | 15% | 30 |
| 8 | 10% | 30 |
| ≥ 9 | 5% | 50 |
一开始等级为0，玩家有且仅有20次升级尝试的机会，无论成功或失败都算作一次尝试。
问题：计算玩家用完20次升级尝试后，总消耗的资源的概率分布。
查询 systemctl 相关的日志，主要使用 journalctl 命令，因为 systemd 的日志是由 journald 来管理的。
sudo journalctl使用git时，我们有时候并不需要整个代码库的所有内容，只需要其中的一部分内容。尤其当目标仓库很大时，这个功能就更为常用了。这时，我们可以使用git的稀疏检出功能（sparse checkout）来实现。
本文主要收录了一些LiveSplit在使用过程中一些常见的进阶问题。有关于计时器怎么用、怎么自动计时等基础问题，请参考空洞骑士计时器生成器FAQ和丝之歌计时器生成器FAQ。
打开LiveSplit → 右键 → Edit Layout，你会看到有很多个组件。找到其中的 Splits ，将其删掉，然后点击左边的加号，新增一个 SubSplits 组件，放在相同位置。这样设置后，你的LiveSplit就支持折叠分段了。
我们知道，在redis-cli中使用如SET、GET等命令可以读写数据。但如果过大（例如一个几百K的字符串），这种方法就有些不方便了。
本篇主要介绍 speedrun.com 上面《丝之歌》游戏的投稿问题和NMG规则。
丝之歌排行榜的投稿于2025年10月1日正式开放。
注意
规则的英文原文见：https://github.com/hk-speedrunning/Silksong-Rules
本文旨在帮助国内速通玩家了解速通投稿规则，以意译为主，附带本人的解释，方便国内速通玩家理解，难免有翻译错误，最终请以英文原文为准。下面的每一段翻译都附带了英文原文，方便比对。
规则随时可能变化，但本文档更新可能滞后，最终请以上方链接的规则原文为准。
空洞骑士和丝之歌的存档文件放在打开之后是一串乱码，显然是加密过的。本文简单讲一下它使用的加密算法。
本文主要从机制层面介绍丝之歌的迷瘴地图。为了更加通俗易懂，因此不含对代码详细实现原理的讲解。