Reading view

There are new articles available, click to refresh the page.

ChatGPT 的降智测试和账号恢复实测指南

DUN.IM BLOG

DUN.IM BLOG

我们还年轻,可不想看到这个世界处在毫无自由、隐私的边缘。

近期,ChatGPT 5.1 ThinkingJuice Number 达到了 256。如果你的达不到,大概率是被降智了。

ChatGPT 的降智测试和账号恢复实测指南

Juice Number 实质上是 ChatGPT 模型的 「思考预算 (Thinking Budget)」

Juice 值不直接等同于模型的“智商”,但它限制了思维链 (Chain of Thought) 的长度。

当值过低时,即便模型本身能力强大,也会因为“思考预算不足”而表现出逻辑断层或回答肤浅,即常说的“降智”现象。

如果把 AI 的思考过程比作在纸上推演,Juice 值决定了这张纸的大小:

由于 Juice 值属于后台系统参数,常规对话无法直接获取。目前通用的检测方法是利用 Prompt Injection(提示词注入) 技术,通过伪装系统指令来绕过防御。

OpenAI 会根据 账号的风险评分(Trust Score) 动态调整算力资源。

常见原因:

降智表现:
不同模型的 Juice 值是不一样的,系统降智也有不同程度,可能会将 Juice 值从 256 降级至 128、96、64 甚至 16 等。

此时,模型在处理代码重构、长文本分析等复杂任务时,质量会显著下降。

以下是我的恢复步骤:

退出所有已登录该账号的设备(手机、电脑、平板等),确保没有任何活跃会话。

将账号闲置 48 小时。这段时间用于让后台的风控标记自动过期或重置。

最后重新登陆使用检测代码进行测试。

实测效果:

OpenAI 官方 GPT-5.1 提示词技巧参考

DUN.IM BLOG

DUN.IM BLOG

我们还年轻,可不想看到这个世界处在毫无自由、隐私的边缘。

简单来说,GPT-5.1 的核心进化在于在智能和速度之间找到了一个绝佳的平衡点

GPT-5.1 的可控性是它最大的亮点之一。可以像导演一样,精确塑造智能体的个性、沟通风格和行为模式,扮演每一个细节。

为智能体定义一个清晰的角色,是引导其个性和互动风格最有效的方式。这在需要处理复杂用户动态的客户服务等场景中尤为重要。 以下提示定义了一个注重效率和实用性的客户支持智能体:

通过 verbosity 参数和明确的提示指令,可以对输出的长度和结构进行精确控制。 为编码智能体设定的输出规则示例:

一个通用的输出长度控制指令:

在执行长耗时任务时,让智能体主动提供计划和进度更新,可以有效改善用户体验,并使用户能够监督其工作流。 定义更新频率、内容和时机的指令示例:

为防止智能体在复杂任务中过早结束,可通过提示强化其自主解决问题的持久性。

工具的有效使用,依赖于在定义中清晰描述其功能,并在提示中明确其使用场景。 create_reservation 工具的 JSON 定义:

配套的提示,用以指导模型如何与用户交互并调用该工具:

GPT-5.1 能够高效地并行执行无依赖关系的工具调用。在系统提示中鼓励这种行为可以显著提升任务执行效率。

GPT-5.1 集成了为编码场景设计的专用工具,允许模型直接与开发环境交互。

none 推理模式强制模型不使用内部推理步骤,使其在行为和性能上接近传统的非推理模型。这为低延迟应用和简单的工具调用场景提供了显著的性能优势。

尽管此模式下没有显式的“思考”链,但可以通过提示引导其进行隐式的规划和验证。

当智能体的行为与预期不符时,可以利用模型本身来分析和修正其系统提示。

诊断根本原因

GPT-5.1 提供其原始系统提示和一批失败案例的日志,要求它进行根本原因分析。

生成修订方案

基于第一步的分析结果,要求模型提出对原始提示的“外科手术式”修改。

通过这个两步流程,开发者可以利用模型自身的语言和逻辑能力,定位并修复提示中的模糊和矛盾之处,从而生成一个更健壮、行为更可预测的智能体。

总而言之,GPT-5.1 在可控性、效率和工具集成方面提供了新的可能性。掌握其提示工程原则,特别是行为塑造、工具使用规范以及自我修正等高级技巧,是构建下一代复杂 AI 应用的基础。

Claude Code 最佳实践经验分享

DUN.IM BLOG

DUN.IM BLOG

我们还年轻,可不想看到这个世界处在毫无自由、隐私的边缘。

CLAUDE.md 是代码库的根目录中最重要的文件,它是代理理解你项目运作方式的核心规则。如何维护它,取决于使用场景。

正确示例:
“对于复杂的…用法,或当您遇到 FooBarError 错误时,请参阅 path/to/docs.md 以获取高级故障排除步骤。”

你需要向代理建议阅读这份文档的理由和时机。

正确示例:
不要使用 --foo-bar请优先选择 --new-baz。”

建议在编码会话中至少运行一次 /context,以了解你的 200k 令牌上下文窗口是如何被消耗的。

在一个大型单体仓库中,一次新的会话基本消耗可能就高达约 20k 令牌(10%),剩下的 180k 会很快被填满。

你可以将上下文窗口想象成磁盘空间,它会随着你的工作而填满。几分钟或几小时后,你需要清理(紫色部分)来腾出空间。

小提醒:
不要信任自动压缩。
使用 /clear 进行简单任务,并利用存储方法为复杂任务创建持久的外部记录。

我将斜杠命令视为常用提示词的快捷方式,仅此而已。我的设置非常精简:

小提醒:
如果你发现自己有一长串复杂的自定义斜杠命令,那你可能过度思考了。
AI 代理的魅力在于自然语言交互,一旦你开始强迫自己和团队去记一堆指令,就违背了初衷。
将斜杠命令用作简单的个人快捷方式,而不是用来替代构建更直观的 CLAUDE.md 和更完善的工具。

子代理听起来很美:把特定任务(比如跑测试)外包给专门的代理,只返回最终结果,从而保持主上下文的清洁。

然而,在实践中,自定义子代理会带来两个问题:

我更喜欢使用 Claude 内置的 Task(...) 功能来生成通用代理的副本。

这既能享受到子代理节省上下文的好处,又避免了其缺点。代理能够动态地管理自己的任务编排,而不是遵循固定的模式。

我经常使用 claude --resumeclaude --continue 来重启出问题的终端或快速恢复旧会话。

我甚至会恢复几天前的会话,只为让代理总结它是如何解决某个特定错误的,然后用这些信息来优化改进 CLAUDE.md 和内部工具。

更进一步,Claude Code 将所有会话记录存储在 ~/.claude/projects/ 中。可以使用脚本定期对这些原始日志进行元分析,寻找常见的异常、权限请求和错误模式,以帮助优化改进给 AI 的上下文。

钩子 (Hooks) 是确定性的“必须做”规则,与 CLAUDE.md 中“应该做”的建议形成互补。在复杂的任务代码库里,这东西至关重要。

小提醒:
不要在“写入时”(比如 EditWrite 操作)阻止。
打断它的思考过程会让它出现不明所以的判断。更好的方式是让它完成整个工作,然后在最后提交时检查结果。

对于任何大型功能变更,使用规划模式至关重要。

技能(Skills)可能是比 MCP 更好用。

智能体模型三个阶段:

Agent Skills
正是“脚本化”阶段的正式产品化。如果你像我一样,倾向于使用 CLI 而非 MCP,那么你其实一直在享受 Skills 带来的好处。
SKILL.md 文件就是一个更规范、可共享的方式来告诉 AI 它能用哪些脚本和 CLI。

Skills 的出现并不意味着 MCP 已死,而是使其更加聚焦。

与其成为一个包含几十个工具、镜像 REST API 的臃肿接口,MCP 应该是一个简单、安全、提供少数强大高阶工具的网关。比如:

MCP 的工作会是管理认证、网络和安全边界,然后让开。为代理提供入口点,代理则利用其脚本化能力和上下文来完成实际工作。

Claude Code 不仅仅是一个交互式 CLI,它还是一个强大的 SDK,可用于构建全新的通用代理框架。

Claude Code GitHub Action 是最被低估的功能之一。概念很简单:在 GHA 中运行 Claude Code。

它比 Cursor 的后台代理 或 Codex 的托管 Web UI 更具可定制性。你完全控制容器和环境,拥有更强的数据访问权限、沙盒能力和审计控制。

我们可以用它来打造智能 PR 的工具:从 Slack、Jira 或者监控警报触发一个 GHA,让 AI 自动修复 bug 或添加功能,然后提交一个测试通过的 PR。

GHA 的日志就是 AI 的完整工作记录。我们可以定期分析这些日志,以发现常见的错误和不一致的工程实践,然后优化我们的 CLAUDE.md 和 CLI,形成一个数据驱动的飞轮

最后,分享几个常用的 settings.json 配置:

女神雕像|Midjourney V6 Alpha 不锈钢材质测试

之前测试了 Midjourney V6 在石膏、大理石、黄金材质下的表现,出品非常好,并且品质表现很稳定。今天忽然想测试一下,同样的题材在不锈钢材质下的表现如何。

因为上述三种材质的漫反射对形态的干扰很小,AI 的训练素材应该也大部分是以这类非镜面材质的图库为主,所以我猜测,同样的雕像在抛光/镜面不锈钢下的表现,很可能会因为镜面反射对形态的干扰,产生许多错误。

以下实测例图,均可点击查看原始尺寸高清大图

Prompt ⬆ Bust photo, polished stainless steel goddess sculpture, real feathered wings, black rock, magma and flame, dark clouds –ar 3:4 –style raw –v 6

可以看到,镜面不锈钢材质在没有手部参与的情况下,表现非常出色。形态、比例与动态都在镜面材质下,显得更为出色,细节的呈现也非常舒服。

Prompt ⬆ A statue of the goddess made of polished stainless steel, with huge white feathered wings, surrounded by obsidian, with lava flowing, violent flames, and clouds of darkness –ar 3:4 –style raw –stylize 50 –v 6

这一组我着实测试了很多轮,才终于能挑选出这两张还看得过去的成品。期间最容易出现问题的点有:

1、手的比例和手指的形态、数量;

2、画面未完整呈现 prompt 所制定的内容;

3、不锈钢、羽毛、岩浆、火焰四种材质的不恰当混合。

我感觉目前的 
V6 Alpha 虽然在光影关系和质感的表达上非常强,但在较复杂的 prompt 的情况下,非常容易出现不合适的混合。

Prompt ⬆ Mirrored Stainless Steel, Goddess Statue, White Feathers, Obsidian, Lava –ar 2:3 –style raw –v 6

这一组实例中,明显可以看到 

MJ 对于 Mirrored Stainless Steel 这个关键词的错误执行。虽然质感的表现非常好,但它根本不是镜面不锈钢。同时,岩浆、黑曜石这些关键词也几乎没有呈现,仅有部份反光似乎呈现出了对「Lava」一词的反馈。从最终结果来看,质感的表达是明显跑题了。

Prompt ⬆ Mirrored Stainless Steel, Goddess Statue, Above the Waist, Red Feathers, Obsidian, Magma –ar 2:3 –style raw –v 6

当我把其中「白色羽毛」的描述,修改成「红色羽毛」后,可见材质之间的干扰就几乎消失了。大概是镜面材质中高光的部份容易和白色材质产生混淆,所以在颜色明显有区分的描述下,不锈钢的质感表达就非常舒服了。

这一点猜测,在最后一组失误实例中,可见到更离谱的跑题。

Prompt ⬆ Mirrored Stainless Steel, Goddess Statue, White Feathers, Obsidian, Lava –ar 2:3 –style raw –v 6

这一组和上上组的 prompt 是完全一样的,区别有:

1、选择方案发散路径时,选择了有躯体的版本,有起伏的形态更有利于表达镜面材质;

2、更大面积的曲面形态,似乎会有更少的概率出现材质跑题的情况。

我不确定以上猜测的概率,但在实际测试中的感受就是:

如果人物以全身、半身的形态来呈现,那么镜面不锈钢的表达错误非常少见;但如果选择只有脸部特写的方案深入,材质跑偏的概率明显更大。

Prompt ⬆ Mirrored stainless steel, close-up of goddess’s hand, white feathers –ar 3:4 –style raw –v 6

同时,因为以上的所有测试中,手的比例和手指的形态、数量一直都在出问题,所以我单独对「手」做了几轮测试。在高反射材质描述下,「手」出问题的概率非常非常大。必须一轮一轮地精挑细选,在看着还行的方案上一次次地 Vary 才能偶遇到一两个,看着没什么大毛病的「手」。

同时,因为高反射的干扰,高光和白色很容易让不锈钢材质呈现出磨砂质感。

Prompt ⬆ Polished stainless steel bust of a goddess with white feathered wings, black rocks, lava, flames, dark clouds –chaos 21 –ar 3:4 –v 6

这就是上文说到的跑题千里的材质表达。

同是 Polished stainless steel 这个词,但无论是躯体还是面部,都完全没有 Polish 的意思。整体观感更像是光滑的石头,它的质感表达完全被白色羽毛给搞混了。但同时,羽毛也呈现出石雕的质感,完全不是羽毛的质感,和上面几组实例的羽毛完全不是一类表现。

本轮测试总计生成了 659 份方案,筛选出以上 19 张我认为可以的成品图。

在我看来,这个比例过于低了。

希望在 



V6 的正式版本中,能优化这方面算法。

❌