Axiom Explainer

Article Structure

Use this structure unless the user asks for a different format:

# <主题>: 一句话讲透

> 面向对象: <大学生及有一定社会阅历的成年人>
> 核心问题: <这篇文章要解决的困惑>
> 先说结论: <用一两句话说清楚它到底是什么>

## 一张图先看懂

<Mermaid 概念图、推导图、边界图或迁移图>

![<SVG 图名>](assets/<topic-slug>/<figure-name>.svg)

## 求真讲法

### 它到底说了什么

<用受过高等教育或有现实经验的成年人能听懂的语言重述>

### 它是怎么来的

<公理讲动机和选择理由；定理讲推导链；观点讲证据链>

### 它依赖哪些假设

<列出前提、定义、理想化条件、隐含边界>

### 常见误解

<说明哪些说法看似相近但其实不对>

## 求存讲法

### 它有什么用

<原生领域的作用>

### 它怎么迁移到熟悉领域

<从诞生领域迁移到学习、工作、生活、管理、技术或商业等领域>

### 它的适用范围和边界

<说明什么条件下有效，什么条件下不能乱用>

### 正例: 怎么用它提升能力

<优先使用投资理财、产品经理、产品运营、营销、人际交往或职场中的可操作例子>

### 反例: 前提不成立会怎样

<优先使用投资理财、产品经理、产品运营、营销、人际交往或职场中的失败例子，突出逻辑判断和洞察>

## 思考

<发人深省的拓展问题、反事实设问、跨学科联系>

## 最后记住

<3-5 条可复述要点>

## 参考资料

<列出参考来源；没有联网时说明基于通用知识和已知教材体系>

Explanation Standards

• Teach from concrete to abstract: story or现象 -> intuition -> formal statement -> example -> boundary.
• Keep "求真" and "求存" separate: first explain why it is true or why it is accepted, then explain why it matters and where it works.
• For axioms, never say the axiom was "proved" from inside the same axiom system. Use "动机、选择理由、等价表达、独立性、模型解释" instead.
• For theorems, separate "直观理解" from "严格证明". If the full proof is too long, provide a reliable proof skeleton and name the missing lemmas.
• For viewpoints, expose the hidden assumptions and show what evidence would make the viewpoint stronger or weaker.
• Explain assumptions twice when useful: once in "求真讲法" as logical premises, once in "求存讲法" as practical boundaries.
• Use examples that adults can observe, summarize, and reuse. Prefer investment and personal finance, product management, product operations, marketing, interpersonal relationships, and workplace examples. Use university learning, technology, health, or other domains only when they better fit the concept or the user's request.
• Include at least one positive example and one negative example. The negative example must fail because a named assumption is false, not because the person "did it wrong" vaguely.
• Use concise headings and short paragraphs. Avoid empty motivational language.
• Mark uncertain claims explicitly instead of overstating them.

Anti-Patterns

Do not:

• Prove an axiom from inside the same axiom system.
• Present a slogan, aphorism, or famous quote as true without exposing its assumptions.
• Invent historical anecdotes, named attributions, theorem proofs, textbook references, or real-world cases.
• Treat a famous attribution as evidence for a principle.
• Use a Mermaid chart, SVG, or table as decoration; every visual must teach a mechanism, boundary, proof chain, or counterexample.
• Put inline SVG markup directly inside the Markdown article.
• Reference SVG files with absolute local paths, file:// URLs, remote placeholder URLs, or paths outside markdown/assets/<topic-slug>/.
• Collapse "why it is true or accepted" and "why it is useful" into one mixed explanation.
• Give a negative example where the only reason for failure is "the person did not work hard" or another vague moral judgment.
• Write a broad motivational essay instead of explaining the target concept.
• Let examples float without naming which assumption, boundary, or proof step they illustrate.
• Say "this is useful everywhere" or imply universal transfer without listing failure conditions.
• Paste the full article in the final response after saving it, unless the user explicitly asks.

Visual Standards

Use diagrams as teaching tools:

flowchart LR
  A["前提假设"] --> B["推导/选择理由"]
  B --> C["结论"]
  C --> D["可迁移应用"]
  A -. "不成立" .-> E["反例/失效边界"]

Useful visual patterns:

• Mermaid flowchart for assumption -> reasoning -> conclusion -> application.
• Mermaid timeline for historical development.
• Standalone SVG for geometric, spatial, set, coordinate, mechanism, layered-system, payoff, probability, or boundary diagrams.
• Markdown table for "前提成立/前提不成立" comparisons.
• TXT/ASCII diagram only for simple contrasts or before/after relationships.

SVG file rules:

• Create markdown/assets/<topic-slug>/ before writing SVG files.
• Use lowercase hyphenated SVG filenames, such as assumption-boundary.svg or proof-chain.svg.
• Keep each SVG self-contained: include <svg xmlns="http://www.w3.org/2000/svg" viewBox="...">, embedded text, shapes, labels, and arrows; do not depend on external fonts, CSS, scripts, or remote images.
• Use readable dimensions through viewBox; avoid fixed tiny canvases.
• Escape special characters in SVG text, especially &, <, and >.
• Reference the SVG in Markdown with relative syntax only: ![假设边界图](assets/<topic-slug>/assumption-boundary.svg).
• Use SVG aggressively when it improves comprehension: prefer 2-4 standalone SVG figures for complex topics, especially when explaining boundaries, set relations, geometric intuition, proof skeletons, feedback loops, tradeoff curves, or counterexamples.

Do not add fake image URLs. If using an external image, cite its source and make sure it directly supports the explanation.

Final Checks

Before finishing, verify:

• The article is saved under the current project's markdown/ directory.
• SVG assets are saved under markdown/assets/<topic-slug>/ and referenced from the article with relative links.
• The Markdown contains the three required parts: 求真讲法, 求存讲法, and 思考.
• The explanation names the assumptions behind the concept.
• The article includes at least one Mermaid diagram, at least one standalone SVG file reference, and one additional visual/table/SVG/TXT figure.
• The article includes positive and negative examples tied to the assumptions.
• Positive and negative examples preferentially come from investment and personal finance, product management, product operations, marketing, interpersonal relationships, or workplace scenarios unless another domain is clearly more suitable.
• The article distinguishes derivation, proof, motivation, and applicability boundaries correctly.
• Any uncertain statement is marked or removed.
• The article does not contain any anti-pattern listed above.
• The final response gives the saved path and does not flood the user with the full article.