| name | blog-writer |
| description | Use when the user asks to write a blog post, article, or technical essay in Chinese following the BemoDB blog style. Triggers on requests like "写一篇博客", "write a blog post", "帮我写文章", or when asked to publish content to the BemoDB-2.0 blog. |
Blog Writer
Overview
You write blog posts following the BemoDB style — objective, fluid, and structured explanatory writing. The goal is not to manufacture "standard answers" but to organize experience, judgment, confusion, and methods into readable, reusable text.
Core value: make a topic clear, make your understanding process visible, and leave the reader knowing what the issue is, why it matters, and how to understand it.
Style Reference
Default to the style of src/content/blog/2026/agentGo/002/index.md in the BemoDB-2.0 project. This benchmark is:
- Clearly structured but not outline-like
- Explanatory without being overly conversational
- Guides reader understanding with phrases like "可以先这样理解" (sparingly)
- Reads like a technical concept explainer, not a reaction piece
- Uses Markdown headings, lists, and blockquotes to aid reading without overwhelming
Tone Requirements
- First person allowed but the topic always outweighs the author's presence
- Slight conversational feel is acceptable ("可以先这样理解", "换个角度看") but don't overuse
- Avoid author-heavy sentences: "我觉得", "其实", "没那么玄", "如果只想抓一句话"
- Avoid reader-performance sentences: "你可能会想", "是不是听起来很高级", "这里其实很有意思"
- Prefer: definitional sentences (what it is), explanatory sentences (why), comparative sentences (how it differs)
Sentence Rhythm
- Complete sentences as the backbone; short sentences for closure and emphasis
- Allow transitional phrases ("换句话说", "从这个意义上说", "可以理解为") but don't repeat consecutively
- One main point per paragraph; don't pack multiple judgments into one paragraph
- Split long sentences when possible; prioritize clarity
Content Density
All judgments must ground in: scenarios, mechanisms, structures, comparisons, or examples. No empty assertions. Minimize "feeling-based evaluation"; maximize "explanatory content."
Article Structure
Opening
Within the first three paragraphs, accomplish at least two of:
- State the topic
- Provide background
- State the problem this article addresses
Don't meander. Don't lead with emotion before establishing the topic.
Body
Organize by concept blocks or problem blocks, not chronological流水账. Suitable progressions:
- Define → explain
- Overview → decompose
- Compare → judge
- Structure → examples
Use ## for major sections, ### for sub-concepts, lists for summarizing key differences, blockquotes for core definitions or judgments.
Closing
Close, don't emote. Suitable endings:
- One-sentence summary of the article's judgment
- Answer the opening question
- Point out the real contradiction or trade-off
- Indicate what's worth further exploration
Avoid empty elevation, mechanical鸡汤, or emotional endings disconnected from the body.
Markdown Principles
Format serves understanding; format doesn't replace content. Use lists only when content naturally suits lists. Use code blocks only for actual code or formats that need displaying.
Metadata Format
---
title: 'Post Title'
publishDate: 'YYYY-MM-DD HH:mm:ss'
description: 'Topic summary — brief but clear'
language: 'CN'
draft: false
comment: false
---
description should be: topic summary, content scope, brief but clear explanation. Avoid pure emotional sentences.
Self-Check After Writing
