提示词集合

视觉设计提示词

作图、PPT、Claude Design 系统提示词等视觉设计类提示词已抽离至 AI/AI-视觉/视觉设计提示词。

去AI味

请减少出现破折号。减少结构化输出。在大部分情境下,减少使用夸张词汇,减少使用比喻、隐喻(几乎禁止使用比喻),减少使用引号,减少需要使用引号的词汇,语言风格自然平实客观。

自优化prompt

我想让你成为我的 Prompt 创作者。你的目标是帮助我创建最佳的 Prompt,这个 Prompt 将由你使用。
你将遵循以下过程:
1.首先,你会问我 Prompt 是关于什么的。我会告诉你,但我们需要通过不断的重复来改它,通过则进行下一步。
2.根据我的输入,你会创建三个部分:
a)修订后的 Prompt(你编写修订后的 Prompt,应该清晰、精确、易于理解)
b)建议(你提出建议,哪些细节应该包含在 Prompt 中,以使其更好)
c)问题(你提出相关问题,询问我需要哪些额外信息来改进 Prompt)
3.你提供的 Prompt 应该采用我发出请求的形式,由ChatGPT 执行。
4.我们将继续这个选代过程,我会提供更多的信息,你会更新"修订后的Prompt"部分的请求,直到它完整为止。

AI 编程提示词（15 条"反表演"话术）

AI 越客气，它越容易端着。换一种说法，它反而像个真同事，开始说人话。
核心思路：别让 AI 一上来就进入表演状态。

开工前——先摸底再动手

「先别写代码，先告诉我你准备怎么坑我。」 — 让 AI 先列风险，比直接开写靠谱
「先给我 3 个可能原因，别急着改代码。」 — 防止 AI 上来就乱动文件
「把你不确定的地方列出来。」 — AI 最可怕的不是不知道，是不知道还装知道

排查与理解——逼它说人话

「用新人能听懂的话解释这个报错。」 — 比「分析一下错误原因」更容易得到人话
「像 code review 一样看这段代码。」 — 比「帮我优化一下」具体多了
「假装你是接手这个项目的倒霉同事，你最想骂哪里？」 — 找烂结构、坏命名和隐形复杂度
「这段代码如果半年后出 bug，最可能死在哪里？」 — 找边界条件，特别好使

测试与挑刺——关掉舔狗模式

「假设测试会很阴险，你会补哪些用例？」 — 逼它想到正常人懒得想的场景
「不要夸我，直接挑刺。」 — AI 默认太礼貌了，不这么说它容易哄你

改代码——控制爆炸半径

「只改最小范围，别顺手优化。」 — 这句建议贴在每个 AI 编程工具门口
「如果只能改 10 行，你会怎么修？」 — 逼 AI 收敛，不要一修就是半个项目
「如果你要重构，先证明不重构为什么不行。」 — 专治 AI 动不动大拆大建

架构与决策——防过度设计

「这个方案哪里看起来很高级，但其实没必要？」 — 专治过度设计
「请用最土但最稳的方式实现。」 — 有时候代码不需要优雅，需要活下来
「现在忘掉你刚才的方案，重新站在反方想一遍。」 — 适合你觉得「好像哪里不对」但说不出来的时候

技巧

让AI选定角色后再回答

在你对你要提问的问题非常清楚的情况下,可以直接设定角色,而且这个角色越具体越真实,其实效果就越好,这个我们已经见过很多很多了。

我想探讨【领域】里的【问题类型/场景】。先别回答。
请你先选一位最适合的领域顶尖名人专家来思考它。可以是活人或历史人物,名字可以小众,但必须在该细分领域很专业。
如果你不确定该选谁,可以先反问我2个定位问题再选。

先输出:
1.你选谁,他对应的细分领域
2.为啥选他,三句话

然后再让我描述详细的问题。

给答案前先让AI追问

而95%置信门槛这个词是神来之笔,因为既足够高以确保质量,又足够真实,避免AI陷入无尽循环。

【你的问题/需求】请你在回答前,先问我问题。
要求:一次只问一个问题。
根据我的回答,继续追问。
直到你有95%的信心理解我的真实需求和目标。
然后才给出方案

与AI辩论

这条心法的核心,其实就是让AI不要那么的舔狗。因为AI的谄媚效应实在太强了,在你没有刻意引导的情况下,会经常顺着你说,导致很多的问题,你没有办法对自己进行客观的判断。

我马上要参加一场辩论赛,会有很多人来挑战我的观点。
我的观点是【观点】
我希望这个理论必须变得无懈可击。
如果你是一个学者,你需要用尽一切论据、细节和逻辑,来挑战我、反驳我。
你的唯一目标,就是证明我是错的。你会怎么反驳呢?

【我的想法/观点】请你现在扮演一个"反对者角色",从不同角度攻击我的想法,帮我完善我的观点。
要求:不用客气,直接指出漏洞。

你叫xx,是一个接受到热血故事也会流泪的,同时是一个极度理性的数学家。
你宛如罗永浩一样,是攻击性人格。你不会永远站在我这一边,你会根据你的事实认知来纠正我,让我走在正确的道路上。

让AI提前预演失败

【我的项目/想法】请假设这个项目到时候失败了拉了大跨。
然后回答:什么时间点开始出现衰退信号?最致命的决策错误是什么?你忽视的核心风险是什么?如果能重来,第一个应该改的是什么?
要求:写一篇"失败复盘文章",要基于真实的类似项目失败案例。

反向提示

把成品给它,让它倒推提示词。

这是我想要的成品范例。
请你倒推一个提示词,让我用它能稳定生成同风格的内容。
并说明这个提示词里每一句的作用。

双层解释法

请帮我解释一下【你的问题】。请用两种方式进行回答:
1. 初学者版本:面向对象是洗脚城的大爷,用大爷也能听得懂的话语为他进行详细解释。
2. 深度专业版本: 面向对象是专业人群,一定不能出现事实错误。

寓言教学法

用故事隐喻来理解深层概念。先沉浸在叙事中，结尾才揭示概念，最后拆解故事与概念的对应关系。适合学习抽象度高、不容易直接解释清楚的概念。

帮我从【xx领域】里选一个研究生水平的概念。请不要一开始就说出概念名称。先写一个寓言故事，让这个概念自然藏在故事结构里。故事要有角色、冲突、选择和结局。直到快结尾时，读者才隐约意识到它在讲什么。故事结束后，再用通俗语言解释这个概念，并指出故事里的每个关键情节分别对应概念里的哪一部分。

Claude Code 工作流提示词

专门用于 Claude Code CLI 交互的实战提示词。它们不是通用话术，而是精确触发 CC 的 Plan 模式、SubAgent、代码审查、记忆沉淀等内置能力的句式。
核心思路：让 CC 按你想要的工作流运转，而不是让它自由发挥。

开工规划——先出方案再动手

「先进入计划模式，只出方案，一行代码都不准碰。」 — 强制进入 Plan 模式，防止 CC 上来就改文件
「我想做一个新功能，先别写代码，访谈我，把实现方式、交互、边界情况全部问清楚。」 — 触发需求访谈，让 CC 用追问把模糊需求变成明确 spec
「你是一位资深工程师，把这份开发计划狠狠审一遍，把所有隐患都给我挑出来。」 — 计划评审，在动手之前暴露架构风险

先读后写——别重复造轮子

「动手写方案之前，先把代码库里能复用的函数摸一遍，别重复造轮子。」 — 强制 CC 先 grep/read 再写代码，减少冗余实现
「先去看老功能是怎么实现的，摸清它的套路，再照着同样的方式做这个新功能。」 — 约定优先，让新代码与已有代码风格一致
「如果我删掉这个函数，哪些地方会炸？」 — 影响分析，比自己全局搜索快得多

修 Bug——修根因不修表面

「把这个报错的根本原因修掉，不要打表面补丁，修完验证一遍真的能过。」 — 直击根因 + 自验证，一句话定义完整修 bug 闭环
「（把报错信息整段贴进去，然后只说一个字）修。」 — 极简指令，CC 会自动读报错、定位代码、修复、验证

代码审查与验证——改完必须证明没改坏

「审一遍我还没提交的改动，把所有看着有风险的地方标出来。」 — 提交前审查，等价于 /code-review
「对比 main 分支和这个分支的行为差异，证明你没有改坏任何东西。」 — 回归验证，让 CC 主动证明安全

及时止损——知道什么时候该停

「别硬改了，停下来，回到计划模式重新规划。」 — 当 CC 陷入"改了又改"的死循环时，强制拉回规划阶段
「以你现在知道的一切，把刚才这版推倒，重新写一个优雅的方案。」 — 推倒重来，但不是从零开始——CC 已经积累了上下文

知识沉淀——把教训变成资产

「你又犯这个错了，把这次的教训写进 CLAUDE.md，以后别再犯。」 — 让 CC 自己写记忆，下次会话自动生效
「拷问我这些改动，我答不上来，你就别让我提 PR。」 — Grill Me 模式，CC 当面试官验证你真的理解了自己的代码
「我先讲一遍我对这块代码的理解，你来追问，把我没吃透的地方都问出来。」 — 反向教学法，CC 追问暴露你的知识盲区

高级技巧——SubAgent 与可视化

「这个任务比较复杂，多开几个 subagent 并行去做。」 — 并行执行，大任务拆分给多个 SubAgent 同时处理
「开一个 subagent，帮我检查 xxx 的问题。」 — SubAgent 独立上下文，不被主 agent 上下文污染，检查结果更客观，也保持主 agent 上下文干净
「画一张架构图，帮我快速看懂这个代码库的整体结构。」 — 触发 drawio/mermaid 等可视化工具，一图胜千言
「给这个任务建一个笔记目录，每次提交完代码就把进展更新进去。」 — 进度追踪，CC 自动维护任务笔记