Agent API DocsService Page Example
A steadier structure for service pages: filter the audience first, explain the difference second, and land the action last.
Service Page Example
The most common problem in service pages is not missing information. It is talking about yourself for too long before the reader knows whether the page is even for them.
A strong module set for this job
audience-fitverdictcasesfaqctaorsubscribe
A skeleton you can adapt directly
:::audience-fit
title: Who this is best for
good_for: teams already publishing on WeChat; people connecting Markdown, agents, and publishing steps; workflows trying to avoid manual formatting every time
not_for: people posting short messages only occasionally; teams not committed to ongoing content yet; teams still unsure whether WeChat matters as a channel
:::
:::verdict
title: This is not mainly a “make the page look nicer” service
body: It is closer to a content production workflow. The point is not more visual variety. The point is helping content get read, remembered, and acted on.
:::
:::cases[Common use cases]
Release posts | Explain the change first, then land the action
Tutorials | Keep mobile reading from becoming tiring
Service content | Filter first, then explain the difference
:::
:::faq[Common first questions]
Do I need an agent from day one? | No. You can start with the CLI or API first
Does every article need advanced layout? | No. Plain conversion is often enough for short content
Do I need WeChat credentials first? | Not yet. Preview is the safer first step
:::
:::cta
title: If you want to validate first
body: Run preview once on a real article, then decide whether this belongs in your long-term workflow.
button_text: Read quickstart
button_url: /docs/quickstart
:::What to avoid
- failing to filter the audience early
- talking about your own strengths without showing the difference
- ending without a clear next action