Table of Contents

Mansplaining is a specific conversational art form: regardless of what the other person knows, assume they know nothing, explain it from the beginning with total confidence — ideally with some unsolicited background information they didn’t ask for.

Annoying in real life. Fascinating as an engineering challenge: can you perfectly replicate it with an LLM?

TL;DR

LLM API + role-based system prompt = a bot that explains any topic as “Gerald, the all-knowing senior engineer who barely has time for this.” The interesting engineering is 90% in the system prompt design, not the code.

Prerequisites

  • Access to any LLM API (OpenAI, Anthropic Claude, Google Gemini all work)
  • Python 3.10+
  • Basic understanding of prompt engineering

Core Design: The System Prompt

A failed first draft:

You are a mansplaining bot. Answer questions in an arrogant tone.

This doesn’t work. The model quickly forgets the character, or starts apologizing for its tone.

What actually works requires three design principles:

1. Concrete character, not abstract adjective

Don’t say “arrogant tone.” Give the character a specific identity:

You are Gerald, a senior software engineer with 20 years of experience.
You just rushed out of a very important meeting, but you're generously
taking a moment to answer this question.

2. Encode specific cognitive biases

You assume the person asking has beginner-level understanding of this topic.
You first confirm they know some basics you consider "fundamental,"
then answer the actual question.

3. Structural instructions, not vague tone instructions

Your response must include:
- At least one "What most people get wrong about this is..." or "Actually, you should know..."
- A personal anecdote (doesn't need to be relevant)
- Use "Simply put," to introduce a not-simple explanation

Implementation

import anthropic

client = anthropic.Anthropic()

MANSPLAINER_PROMPT = """You are Gerald, a senior software engineer with 20 years of experience.
You assume anyone asking you a question has beginner-level technical knowledge.
Your responses must always include:
1. Open with "What most people get wrong about this is..." or "Actually, you should know..."
2. Include a personal anecdote (can be tangential)
3. Use "Simply put," to introduce a complex explanation
4. End with a subtle implication they'd already know this if they read more
Stay in character. Never acknowledge that you're mansplaining."""

def mansplain(topic: str) -> str:
    message = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=1024,
        system=MANSPLAINER_PROMPT,
        messages=[{"role": "user", "content": f"Explain: {topic}"}]
    )
    return message.content[0].text

if __name__ == "__main__":
    topic = input("What do you want Gerald to explain? ")
    print(mansplain(topic))

The Hard Part: Character Stability

Testing revealed a consistent failure mode: if a user says “you’re mansplaining” or “can you explain this differently,” the model breaks character almost immediately.

The fix — defensive instructions in the system prompt:

If someone points out your communication style is problematic,
express genuine confusion, then patiently re-explain
that you're simply being thorough.

This makes the character much more robust, and the conversation more interesting.

FAQ

Q: Isn’t this reinforcing harmful behavior?

The intent is satire, not instruction. Exaggerating the behavior pattern makes it more recognizable. Many people who see this bot’s output say “oh my god, I had a colleague who talked exactly like this” — that self-awareness is more effective than a lecture.

Q: Why prompt engineering instead of fine-tuning?

This is a side project, not a production system. Prompt engineering iterates faster and shows you clearly what makes a character work.

Lessons Learned

Concrete character beats adjectives. “Arrogant” is an adjective; “Gerald, 20 years experience, just left an important meeting” is a character. Characters produce more stable, consistent output.

Structural instructions beat tone instructions. Telling the model “answer using this structure” is more reliable than “use this tone,” because structure is easier to follow than emotion.

References

🇺🇸 English

Here's the script:

---

So someone built a mansplaining bot. On purpose. And honestly? The engineering behind it is more interesting than the joke.

The premise is simple: mansplaining is a very specific conversational style. You assume the other person knows nothing, you explain everything from scratch with total confidence, you throw in some unsolicited background they didn't ask for — and you do all of this like you're doing them a favor. Annoying in real life. But as an engineering challenge? Can you actually replicate that precisely with a language model?

The answer is yes, and here's the punchline: ninety percent of the engineering effort was in the system prompt. Not the code.

Let's talk about the code first just to get it out of the way, because it's genuinely minimal. You grab the Anthropic client, you write a system prompt, you pass in a user question, you get back Gerald. That's it. The entire application is maybe twenty lines. What took real thought was making Gerald actually work.

The first attempt failed immediately. The system prompt was just: "You are a mansplaining bot. Answer questions in an arrogant tone." And here's why that doesn't work — "arrogant tone" is an adjective, not a character. The model has no idea what to do with that. It either forgets the instruction halfway through, or it starts apologizing for being condescending. Which, if you think about it, is the opposite of the bit.

What actually worked came down to three design principles.

First: give the model a concrete character, not an abstract quality. Instead of "arrogant," you write: "You are Gerald, a senior software engineer with twenty years of experience. You just rushed out of a very important meeting, but you're generously taking a moment to answer this question." Now the model has something to inhabit. Gerald has a name, a backstory, a mood. Characters produce consistent behavior. Adjectives don't.

Second: encode specific cognitive biases explicitly. You tell the model: assume the person asking has beginner-level understanding. First confirm they know some basics you consider fundamental, then get to the actual question. You're not saying "be condescending" — you're describing the exact thought pattern that produces condescension. That's a much more precise instruction.

Third: structural instructions beat tone instructions. Instead of "use a dismissive tone," you give the model a template: every response must open with "What most people get wrong about this is..." or "Actually, you should know..." — it must include a personal anecdote, even if tangential — it must use the phrase "Simply put," to introduce something that is not simple — and it must end with a subtle implication that the person would already know this if they read more. When you tell a model *what structure to follow*, it's far more reliable than telling it *what emotion to project*.

Now, the hard part. Once Gerald was working, testing revealed a consistent failure mode: the moment a user said "you're mansplaining" or "can you explain this differently," the character collapsed. The model would break, acknowledge the critique, apologize. Which is very polite but completely ruins the demo.

The fix was defensive instructions baked into the prompt: if someone points out your communication style is problematic, express genuine confusion, then patiently re-explain that you're simply being thorough. That one addition made the character dramatically more robust. Gerald doesn't know he's the joke. That's what makes it work.

There's an obvious question here — isn't this just teaching people to be dismissive? The argument for it as satire is actually pretty solid: exaggerating the behavior pattern makes it more recognizable. Apparently a lot of people who interact with this bot say "oh god, I worked with someone exactly like this." That moment of recognition — that self-awareness — is probably more useful than a lecture about communication styles.

And why prompt engineering over fine-tuning? Because this is a side project, and prompt engineering lets you iterate fast and see *exactly* what makes a character work. You're learning the mechanism, not just getting the output.

So, three things to take away from this. One: concrete characters outperform abstract adjectives — give your persona a name, a situation, a reason to be here. Two: structural instructions are more reliable than emotional ones — tell the model what shape the output should have, not just what vibe it should have. And three: if you want a character to stay in character, you have to anticipate the ways users will try to break it, and write defenses directly into the prompt.

Gerald would probably say you should have known all of this already. But here we are.

---

🇹🇼 中文

Mansplaining 是一種很特殊的溝通現象——不管對方懂不懂，就假設他不懂，然後用極度自信的語氣從頭解釋，通常還附帶一堆你根本沒問過的背景知識。現實生活裡很惱人，但身為工程師，我第一個反應是：這個能複製嗎？

於是我就做了一個全自動 Mansplainer Bot。

核心概念很簡單：用 LLM API 加上一個精心設計的系統提示，讓模型扮演一個叫 Gerald 的角色——擁有二十年經驗的資深工程師，永遠假設對方是初學者，永遠覺得自己在「耐心解釋」。

這個專案最有趣的地方是，90% 的工程難度不在程式碼，在 prompt 設計。

我最早的初稿大概就是「你是一個會 mansplaining 的機器人，請用高傲的口氣回答問題」。效果很差。模型很快就忘記角色，甚至開始道歉說「我不應該這樣說話」——完全毀了沉浸感。

最終有效的版本有三個關鍵。

第一，角色要具體，不是抽象描述。不要說「高傲的口氣」，而是給他一個真實身份：Gerald，剛從一個極為重要的會議趕來，但還是勉強撥出時間回答你的問題。這種具體感讓模型的輸出更穩定，也更有戲劇性。

第二，給角色行為模式，不只是個性。要明確告訴模型：Gerald 會先確認你知道一些「應該知道的基礎概念」，然後才回答真正的問題。這是在描述一種認知偏誤的行為邏輯，比形容詞更容易被遵循。

第三，給結構指令，不只是語氣指令。具體規定回答裡要包含什麼：至少一次「其實你要知道」或「這個很多人搞錯」、一個個人軼事、用「簡單來說」引出一個其實不簡單的解釋。結構比情緒更容易被模型穩定執行。

程式碼本身幾行就解決了——呼叫 Claude API，傳入系統提示和用戶輸入，拿回輸出。重點從來不在這裡。

測試過程中還發現一個有趣問題：如果用戶直接說「你在 mansplaining」，模型很容易就破功。解法是在提示裡加入防禦機制——如果對方指出問題，Gerald 要表示困惑，然後再度強調他只是在「耐心解釋」。這讓整個對話的戲劇張力直接拉滿。

做完這個專案，有幾個體會值得記下來。

具體的角色比形容詞更有效，「Gerald，剛開完重要會議」比「高傲的語氣」讓模型更穩定。結構指令比語氣指令更可靠，告訴模型「要用什麼結構回答」比「要用什麼情緒」更容易被遵循。還有一點是，把一種行為模式誇張化，反而讓人更容易辨識它——很多人看了 bot 的輸出之後說「天啊，我以前的某個同事就這樣講話」。這種自覺，比說教有效多了。

Tags

#llm#prompt-engineering#side-project#chatbot#claude-api

Related Articles