AI Conversation Generator.

Under every good chat screen sits a quiet set of decisions: who may speak, what counts as an event, how a streaming reply appends, and what happens when a user rewrites a question. MeDo generates the whole organizing pattern from those decisions — a typed message model, ordering and grouping rules, streaming semantics, branching, and compaction for threads that outgrow their welcome.

Who Spoke Is a Data Question Before It Is a Design Question

A chat screen is easy; the model underneath is where implementations go wrong. The moment an agent does anything richer than reply with prose, 'a list of messages' stops being enough: a tool call is not a speaker, a system event has no author, a streamed reply is one message that keeps growing, and an edited question silently orphans the answer already on screen. Deciding the taxonomy — user turn, agent message, system event, tool call, tool result — and the rules that order and group them makes every downstream behavior tractable: scroll anchoring during streaming, retry after a failed tool, branching when a user rewrites a turn, compaction when the history outgrows the context window. Get the model right and any rendering looks reasonable; skip it and every new feature — citations, forks, summaries — becomes a special case bolted onto a flat array.

4 个模板

可以生成的 Conversation 模板

每个模板都是真实的提示词，而不是截图。复制到任意 AI 编辑器，或在 MeDo 中运行，直接拿到 React + Tailwind 代码。

Strict orderLinear Thread

One Append-Only Line of Turns

The default organization model: every entry appends to the end, nothing forks, the transcript reads top to bottom. Right when the dialogue itself is the product.

Build a conversation view with a single append-only thread. Render five entry types in insertion order — user turns compact and right-leaning, agent replies as full-width markdown, system events as centered grey captions such as 'Conversation shared at 2:14 PM', tool calls as one-line labeled chips, and tool results indented beneath their call. New tokens stream into the open reply as one growing message, never fragments, pinned to bottom only while the reader is already there. A stop button finalizes the open reply with an interrupted marker. No branching: a rewritten question appends a correction. Entries above the visible window lazy-render from the stored array.

在 MeDo 中尝试

Tool-heavyRun Log

Turns Grouped Into Agent Runs

For agents that act: each request opens a run — a collapsible block holding the calls, results, and narrative it produced, with per-run status.

Build an agent conversation organized as a run sequence. Each user turn opens a run block with a timestamp header and a status line — running, succeeded, failed. Inside a block, render the agent's prose, tool call cards with the tool name and one-line argument summary, and results indented under their calls with exit status and duration. A running card shows animated ellipsis and elapsed seconds; a failed one expands to the error with a Retry-run action that resends the turn. When the next user turn arrives, collapse the finished run to its header line, expandable on click, so a long session reads as an index of requests. The docked composer below indicates which run the next reply joins.

在 MeDo 中尝试

BranchableFork Tree

Edit-and-Resend Branching With Siblings

The exploration model: rewriting any turn forks the thread, siblings persist, and a switcher moves between versions without losing anything.

Build a conversation with true branching. Any user turn offers Edit; committing it creates a sibling branch — the original path stays intact below a fork marker, the revised turn heads the new one. A switcher above the composer reads 'Branch 2 of 3', arrows moving between siblings; only the active path renders, moving to a sibling swaps the tail beneath the fork. Add a New-branch action that forks without editing, for trying a different instruction from that point. Model entries as a tree: each stores a parentId, and the visible thread is the path from root to the selected leaf. Only the open leaf accepts streamed tokens, and sibling counts persist across reload.

在 MeDo 中尝试

Long horizonCompacted Thread

Summary Stubs for Weeks-Long Conversations

The longevity model: settled turns compress into expandable summary stubs, the thread stays scannable at any age, and the verbatim boundary is always visible.

Build a conversation designed to stay readable across weeks. Keep the six most recent turns fully rendered; compact everything older into one summary stub pinned above them — 'Earlier: 14 turns about the Q3 pricing migration' — with Expand lazy-loading the original turns in place and Collapse re-summarizing. Compact system events like model switches and handoffs first. Build stubs from stored summaries, never on-the-fly regeneration, so they cannot drift from what happened. When a compaction boundary would split a tool call from its result, move the boundary to keep the pair together. Draw a subtle divider where the verbatim transcript begins, and append new turns with standard streaming — one growing message, bottom-pinned unless the reader scrolled up.

在 MeDo 中尝试

如何自定义你的 Conversation

Name every speaker and event your product can produce

Write the taxonomy before the screen: user, agent, system event, tool call, tool result — plus whatever your domain adds, like a handoff-to-human entry. Anything not modeled will render as the wrong default later, usually as prose where a status belonged. When a new entry type appears mid-project, extend the model first and the renderer second; the reverse order is how flat message arrays acquire their fifteenth boolean flag.

Decide what streaming means for the scroll

Streaming appends into one open message — the entry is created once and grows — and the view pins to the bottom only while the reader is already there. If the user scrolled up to re-read, new tokens must not yank the viewport down. Ask for that anchor rule explicitly, plus a stop control that finalizes the open message with an interrupted marker instead of discarding what arrived.

Make branching a decision, not an accident

Edit-and-resend either forks — the original path survives and the edit starts a sibling — or it truncates everything after the edited turn. Both are legitimate; silently picking one is not, because truncation destroys work users thought was saved. If your product is about exploring options, model the thread as a tree with a parent pointer per entry and a visible switcher; if it is about answers, append corrections and skip branching entirely.

Compact old history on a budget and show the seams

Threads that live for weeks need compaction: recent turns stay verbatim, older ranges collapse into a summary stub the reader can expand. Build the stub from stored summaries rather than on-the-fly regeneration so it cannot drift from what actually happened, keep tool call-result pairs on the same side of a compaction boundary, and draw a divider where the verbatim transcript begins — readers should always know which parts are quote-accurate.

谁在使用 Conversation 组件

Consumer AI chat product

The conversation is the product: a thread list in a sidebar, streaming replies anchored to the bottom, model-switch captions, and threads that persist across sessions.

Knowledge-base answer engine

Every agent reply carries citations to source documents, and the model distinguishes a retrieval tool call from the prose answer it produced — the difference between an auditable answer and a confident guess.

Writing and tutoring copilot

Multi-turn coaching where students rewrite their own prompts to explore alternatives — branching with sibling switchers is the core interaction, not an advanced feature.

Operations run console

Tool-heavy sessions rendered as runs: each request opens a block of calls, results, and narrative that collapses to a status line once the next request arrives.

不同网站的 Conversation 方案

同一个 conversation 组件，针对它所在网站的类型做调整。

01 / 04

AI-First Products

When the conversation is the product, the pattern carries the full model: thread list, model-switch captions, streaming appends, and session persistence. The taxonomy tends to stay small and the prose quality carries everything.

Conversation 的风格与变体

挑选与页面其余部分匹配的变体，然后生成它。

01 / 04

Alternating Turns

Speaker identity encoded as alignment and fill — user turns right and tinted, agent turns left and plain. The most familiar reading contract, and the cheapest to parse at a glance.

在 React、Next.js、Vue 与 Svelte 中使用 Conversation

React、Next.js、Vue 3、SvelteKit、Astro 或纯 HTML —— 同一个 conversation，六种接入方式。

01 / 03

React Conversation

The pattern's core loop as a rendering switch: one row component that branches on the entry type, so the taxonomy lives in one place and a new type is one new case.

src/components/Conversation.tsx

function Row({ msg }: { msg: Msg }) {
  switch (msg.type) {
    case 'user':
      return <UserTurn text={msg.content} />
    case 'agent':
      return <AgentReply text={msg.content} streaming={msg.open} />
    case 'system':
      return <p className='text-center text-xs text-zinc-500'>{msg.content}</p>
    case 'tool_call':
      return <ToolCard name={msg.name} args={msg.args} running={msg.pending} />
    case 'tool_result':
      return <ToolOutput callId={msg.callId} status={msg.status} />
  }
}

// Ordering lives in the model: visiblePath is the root-to-leaf traversal.
<ol role='log' className='space-y-3'>
  {visiblePath.map((msg) => <Row key={msg.id} msg={msg} />)}
</ol>

如何把 Conversation 加入项目

四个步骤，从挑选 conversation 模板到上线生产环境。

01~15min

Inventory Your Entry Types

List everything that can appear in a thread: user turns, agent prose, tool calls, results, system events, plus whatever your product adds like a human handoff. Anything not named now will render as the wrong default later.

02~10min

Set the Ordering Rules

Decide how entries sort, what groups together, and whether a tool result may ever sit apart from its call. Write the rules down; they become the backbone of the prompt you will generate from.

03~3min

Generate From the Taxonomy

Hand MeDo the typed message model — entry types, ordering, append behavior, fork rules — rather than a screenshot of a chat app. A view generated from its model absorbs new features; one generated from pixels grows special cases.

04~5min

Replay a Messy Session

Feed the generated view a real, ugly transcript: an interrupted stream, a failed tool, a question rewritten mid-thread, a week of history. The organization model is correct when the worst session still reads top to bottom.

关于 Conversation 的常见问题

How is a conversation different from a chat panel?

The conversation is the organizing pattern; the chat panel is a widget that hosts it. The pattern defines the message taxonomy, ordering, streaming append semantics, branching, and history rules — the things that stay true whether the dialogue renders full-screen, in a rail, or in a drawer. The panel adds the embedding concerns: width, host-page context, focus, collapse behavior. When you generate a conversation with MeDo you are specifying the model; the same model can later be dropped into a panel, a full page, or a workspace column without redesign.

Isn't a conversation just a feed of messages?

They are near-opposites wearing similar markup. A feed is reverse-chronological content consumption: newest first, entries authored by others, no obligation to reply, read order is top to bottom starting from now. A conversation is turn-taking: strictly oldest-to-newest, the reader is a participant, the view anchors to the bottom while new content arrives, and a composer is the contract that the other side will answer. Reverse the order of a conversation and it stops working; a feed that anchored to its oldest post would be unreadable. Same rows, inverted time, different product.

What message types does a conversation model need?

Start with five: user turn, agent message, system event (model switches, shares, handoffs — things that happened with no participant speaking), tool call (a named action with arguments), and tool result (bound to its call, carrying status and duration). The binding rule matters as much as the list: a result must stay attached to its call even across compaction and virtualization. Add product-specific types deliberately — a human-agent takeover, a payment confirmation — rather than overloading prose, because each type earns its own rendering and its own rules.

How does streaming work without breaking the layout?

Create the reply entry once, then append tokens into that same entry — the list length never changes during a stream, so layout cannot jump. Anchor the viewport to the bottom only while the reader is already there, with a small threshold rather than exact equality. Resist rendering each chunk as its own element or re-rendering the whole list per token: long threads need windowed rendering with stable entry heights, and a stream that mutates one entry plays nicely with that. A stop control finalizes the open entry with an interrupted marker instead of deleting the partial text.

When should a conversation support branching?

When revising a question is part of the product — writing tools, tutoring, research exploration — branching turns 'I asked the wrong thing' into a feature: the edit forks a sibling, both survive, and a switcher moves between them. When the product is about dependable answers — support, ops — branching adds state you must explain for little gain; append a correction instead. The middle ground many products ship is edit-and-resend with visible fork count, so the cost of rewriting a turn is honest and the original answer is never silently discarded.

What is history compaction and when do I need it?

Compaction summarizes settled parts of a thread into a stub — 'Earlier: 14 turns about the pricing migration' — while keeping recent turns verbatim and expandable. You need it when either limit bites: the model's context window makes old turns expensive or impossible to send, or human readers face a scroll they will never finish. Compact by range, keep tool call-result pairs together across the boundary, build stubs from stored summaries so they cannot drift, and mark where the verbatim transcript begins. A thread a user can re-enter after three weeks is a retained user.

立即用 MeDo 生成你的 conversation。

尝试任何提示词 — 免费，无需注册。

免费开始构建查看定价

Task Input

The front door of every agent product: one card that carries the whole job — instruction, attachments, model and mode, context the user can actually see — and a submit that turns into a stop button the moment work begins. Tell MeDo what your agents get asked to do and the entry unit comes back with its state machine built.

Chat Panel

Your product already has the page where the answer is needed. MeDo generates the panel that lives there: a docked surface with a streaming message log, an attachment-aware composer, citations that trace back to sources, tool chips that tell the truth, and a recovery path for every failed request — all scoped to whatever the host page has open.

Agent Workspace

Not a chat window with extra panes: an arrangement where the conversation steers, the files testify, the preview verifies, and the task list keeps the plan honest — all of it wired to one run state so a failure lands everywhere at once. Give MeDo the regions and the states and the environment comes back assembled.