blog-writing-specialist

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Blog Writing Specialist

博客写作专家

Comprehensive blog writing combining technical depth, personal voice transformation, and AEO optimization.

集技术深度、个人风格转化与AEO优化于一体的全面博客写作指南。

Quick Decision Tree

快速决策树

Input Type	Use Section
Technical tutorial, deep dive, benchmark	Technical Blog Writing
Brain dump → polished post	Nick Nisi Voice
Personal voice (Jarad style)	Jarad's Voice
Company/product/technology category post	Lightfast Category System
Not sure	Start here, adapt as needed

输入类型	适用模块
技术教程、深度解析、基准测试	技术博客写作
零散想法 → 精炼文章	Nick Nisi风格写作
个人风格（Jarad风格）	Jarad风格写作
公司/产品/技术分类文章	Lightfast分类体系
不确定	从此处开始，按需调整

Part 1: Technical Blog Writing

第一部分：技术博客写作

Write developer-focused technical blog posts.

撰写面向开发者的技术博客文章。

Post Types

文章类型

1. Tutorial / How-To

1. 教程/操作指南

Step-by-step instruction. Reader should build something.

Structure:
1. What we're building (with screenshot/demo)
2. Prerequisites
3. Step 1: Setup
4. Step 2: Core implementation
5. Step 3: ...
6. Complete code (GitHub link)
7. Next steps / extensions

Rule	Why
Show the end result first	Reader knows if worth continuing
List prerequisites explicitly	Don't waste wrong audience time
Every code block should be runnable	Copy-paste-run is the test
Explain the "why" not just the "how"	Tutorials that explain reasoning get shared
Include error handling	Real code has errors
Link to complete code repo	Reference after tutorial

分步式指导，读者应能跟着完成一个项目。

结构:
1. 我们要构建的内容（附截图/演示）
2. 前置条件
3. 步骤1：环境搭建
4. 步骤2：核心实现
5. 步骤3：……
6. 完整代码（GitHub链接）
7. 后续步骤/扩展方向

规则	原因
先展示最终效果	让读者明确是否值得继续阅读
明确列出前置条件	避免浪费非目标读者的时间
所有代码块必须可运行	复制-粘贴-运行是检验标准
不仅解释“怎么做”，还要解释“为什么”	包含推理过程的教程更易被分享
加入错误处理内容	真实代码会遇到错误
链接到完整代码仓库	方便读者在教程结束后参考

2. Deep Dive / Explainer

2. 深度解析/原理说明

Explains a concept, technology, or architecture decision in depth.

Structure:
1. What is [concept] and why should you care?
2. How it works (simplified mental model)
3. How it works (detailed mechanics)
4. Real-world example
5. Trade-offs and when NOT to use it
6. Further reading

深入解释某个概念、技术或架构决策。

结构:
1. 什么是[概念]，为什么你需要关注？
2. 工作原理（简化心智模型）
3. 工作原理（详细机制）
4. 实际案例
5. 取舍与不适用场景
6. 延伸阅读

3. Postmortem / Incident Report

3. 事后复盘/事件报告

Describes what went wrong, why, and what was fixed.

Structure:
1. Summary (what happened, impact, duration)
2. Timeline of events
3. Root cause analysis
4. Fix implemented
5. What we're doing to prevent recurrence
6. Lessons learned

描述问题发生的过程、原因及修复措施。

结构:
1. 摘要（事件内容、影响、持续时间）
2. 事件时间线
3. 根本原因分析
4. 实施的修复方案
5. 预防复发的措施
6. 经验教训

4. Benchmark / Comparison

4. 基准测试/对比分析

Data-driven comparison of tools, approaches, or architectures.

Structure:
1. What we compared and why
2. Methodology (so results are reproducible)
3. Results with charts/tables
4. Analysis (what the numbers mean)
5. Recommendation (with caveats)
6. Raw data / reproducibility instructions

基于数据的工具、方法或架构对比。

结构:
1. 对比内容及原因
2. 测试方法（确保结果可复现）
3. 结果（含图表/表格）
4. 分析（数据背后的意义）
5. 建议（附注意事项）
6. 原始数据/复现说明

5. Architecture / System Design

5. 架构/系统设计

Explains how a system is built and why decisions were made.

Structure:
1. Problem we needed to solve
2. Constraints and requirements
3. Options considered
4. Architecture chosen (with diagram)
5. Trade-offs we accepted
6. Results and lessons

解释系统的构建方式及决策依据。

结构:
1. 我们需要解决的问题
2. 约束条件与需求
3. 考虑过的方案
4. 选定的架构（附示意图）
5. 我们接受的取舍
6. 结果与经验

Writing Rules for Developers

面向开发者的写作规则

Voice and Tone

语气与语调

Do	Don't
Be direct: "Use connection pooling"	"You might want to consider using..."
Admit trade-offs: "This adds complexity"	Pretend your solution is perfect
Use "we" for team decisions	"I single-handedly architected..."
Specific numbers: "reduced p99 from 800ms to 90ms"	"significantly improved performance"
Cite sources and benchmarks	Make unsourced claims
Acknowledge alternatives	Pretend yours is the only way

要做	不要做
直接表述：“使用连接池”	“你可能需要考虑使用……”
承认取舍：“这会增加复杂度”	假装你的解决方案完美无缺
团队决策用“我们”	“我独自设计了整个架构……”
使用具体数据：“将p99延迟从800ms降至90ms”	“显著提升了性能”
引用来源与基准测试	提出无来源的主张
认可替代方案	假装你的方案是唯一选择

What Developers Hate

开发者反感的内容

❌ "In today's fast-paced world of technology..." (filler)
❌ "As we all know..." (if we all know, why writing it?)
❌ "Simply do X" (nothing is simple if reading a tutorial)
❌ "It's easy to..." (dismissive of reader's experience)
❌ "Obviously..." (if obvious, don't write it)
❌ Marketing language in technical content
❌ Burying the lede under 3 paragraphs of context

❌ “在当今快节奏的技术世界中……”（冗余套话）
❌ “众所周知……”（如果真的众所周知，何必写出来？）
❌ “只需执行X”（读者看教程时，没有什么是“只需”的）
❌ “很容易就能……”（轻视读者的体验）
❌ “显然……”（如果真的显然，就不用写了）
❌ 技术内容中加入营销话术
❌ 把核心内容埋在三段背景介绍之后

Code Examples

代码示例规则

Rule	Why
Every code block must be runnable	Broken examples destroy trust
Show complete, working examples	Snippets without context are useless
Include language identifier in fenced blocks	Syntax highlighting
Show output/result after code	Reader verifies understanding
Use realistic variable names	`calculateTotalRevenue` not `foo`
Include error handling in examples	Real code handles errors
Pin dependency versions	"Works with React 18.2" not "React"

规则	原因
所有代码块必须可运行	错误的示例会彻底失去读者信任
展示完整、可运行的示例	脱离上下文的代码片段毫无用处
在代码块中指定语言标识	实现语法高亮
代码后展示输出/结果	帮助读者验证理解
使用真实的变量名	用 `calculateTotalRevenue` 而非 `foo`
示例中加入错误处理	真实代码需要处理错误
固定依赖版本	写“兼容React 18.2”而非“兼容React”

Explanation Depth

讲解深度

Audience Signal	Depth
"Getting started with X"	Explain everything, assume no prior knowledge
"Advanced X patterns"	Skip basics, go deep on nuances
"X vs Y"	Assume familiarity with both, focus on differences
"How we built X"	Technical audience, can skip fundamentals

State your assumed audience level explicitly at the start.

读者信号	讲解深度
“入门X”	讲解所有内容，假设读者无前置知识
“X进阶模式”	跳过基础，深入讲解细节
“X vs Y”	假设读者熟悉两者，重点讲解差异
“我们如何构建X”	面向技术读者，可跳过基础知识

请在文章开头明确说明目标读者的知识水平。

Blog Post Structure

博客文章结构

The Ideal Structure

理想结构

markdown

undefined

markdown

undefined

Title (contains primary keyword, states outcome)

标题（包含核心关键词，明确成果）

[Hero image or diagram]

TL;DR: [2-3 sentence summary with key takeaway]

[首图或示意图]

TL;DR: [2-3句话的摘要，包含核心要点]

The Problem / Why This Matters

问题/为什么重要

[Set up why the reader should care — specific, not generic]

[说明读者为何需要关注——具体而非泛泛而谈]

The Solution / How We Did It

解决方案/我们的实现方式

[Core content — code, architecture, explanation]

[核心内容——代码、架构、讲解]

Step 1: [First thing]

步骤1：[第一步内容]

[Explanation + code + output]

[讲解 + 代码 + 输出]

Step 2: [Second thing]

步骤2：[第二步内容]

[Explanation + code + output]

[讲解 + 代码 + 输出]

Results

结果

[Numbers, benchmarks, outcomes — be specific]

[数据、基准测试、成果——务必具体]

Trade-offs and Limitations

取舍与局限性

[Honest about downsides — builds trust]

[坦诚说明缺点——建立信任]

Conclusion

结论

[Key takeaway + what to do next]

[核心要点 + 下一步行动建议]

延伸阅读

[3-5 relevant links]

undefined

[3-5个相关链接]

undefined

Word Count by Type

按文章类型划分的字数参考

Type	Word Count	Why
Quick tip	500-800	One concept, one example
Tutorial	1,500-3,000	Step-by-step needs detail
Deep dive	2,000-4,000	Thorough exploration
Architecture post	2,000-3,500	Diagrams carry some load
Benchmark	1,500-2,500	Data and charts do heavy lifting

类型	字数范围	原因
快速技巧	500-800字	单个概念，单个示例
教程	1500-3000字	分步指导需要足够细节
深度解析	2000-4000字	需要全面探索主题
架构文章	2000-3500字	示意图可承担部分内容传递工作
基准测试	1500-2500字	数据与图表可传递大量信息

Part 2: Brain Dump → Polished Post (Nick Nisi Voice)

第二部分：零散想法→精炼文章（Nick Nisi风格）

Transform unstructured brain dumps into polished blog posts.

将无结构的零散想法转化为精炼的博客文章。

Process

流程

1. Receive the Brain Dump

1. 接收零散想法

Accept whatever provided:

Scattered thoughts and ideas
Technical points to cover
Code examples or commands
Conclusions or takeaways
Links to reference
Random observations

Don't require organization. The mess is the input.

接受任何形式的输入：

零散的思路与想法
需要覆盖的技术点
代码示例或命令
结论或要点
参考链接
随机观察

无需提前整理，混乱的内容就是输入素材。

2. Read Voice and Tone

2. 研读风格指南

Load

references/voice-tone.md

to understand Nick's writing style.

Key characteristics:

Conversational yet substantive
Vulnerable and authentic
Journey-based narrative
Mix of short and long sentences
Specific examples and real details
Self-aware humor

阅读

references/voice-tone.md

以理解Nick的写作风格。

核心特点：

口语化但有实质内容
真实且带有脆弱感
以旅程为叙事主线
长短句结合
具体示例与真实细节
带有自我认知的幽默感

3. Check for Story Potential

3. 挖掘故事潜力

Read

references/story-circle.md

to understand the narrative framework.

Determine if content fits a story structure:

Is there a journey from one understanding to another?
Can you identify a problem and resolution?
Does it follow: comfort → disruption → return changed?

阅读

references/story-circle.md

以理解叙事框架。

判断内容是否适合故事结构：

是否有从一种认知到另一种认知的转变过程？
是否能识别出问题与解决方案？
是否符合：舒适→打破→蜕变的模式？

4. Organize Content

4. 组织内容

Structure material into sections:

Common structures:

Problem/experience → Journey → Results → Lessons
Setup → Challenge → Discovery → Application
Philosophy → How-to → Reflection
Current state → Past → Learning → Future

将素材整理为以下常见结构：

常见结构：

问题/经历 → 过程 → 结果 → 经验
背景 → 挑战 → 发现 → 应用
理念 → 操作指南 → 反思
当前状态 → 过往经历 → 学习 → 未来

5. Write in Nick's Voice

5. 以Nick的风格写作

Opening:

Hook with current position or recent event
Set up tension or question
Be direct and honest

Body:

Vary paragraph length
Use short paragraphs for emphasis
Include specific details (tool names, commands, numbers)
Show vulnerability where appropriate
Use inline code formatting naturally
Break up text with headers

Technical content:

Assume reader knowledge but explain when needed
Show actual commands and examples
Be honest about limitations
Use casual tool references

Ending:

Tie back to opening
Forward-looking perspective
Actionable advice
Optimistic or thought-provoking

开头：

以当前状态或近期事件引入
设置悬念或提出问题
直接且坦诚

正文：

变化段落长度
用短段落强调重点
加入具体细节（工具名称、命令、数据）
适当展现脆弱感
自然使用行内代码格式
用标题分隔内容

技术内容：

假设读者有一定知识，但必要时仍需解释
展示真实命令与示例
坦诚说明局限性
随意提及工具

结尾：

呼应开头
带有前瞻性视角
给出可行动的建议
以乐观或引人深思的内容收尾

Part 3: Jarad's Voice

第三部分：Jarad风格

Personal blog writing with distinctive voice.

具有鲜明个人特色的博客写作风格。

Core Voice Patterns

核心语言模式

Sentence Structure:

Productive rambling: longer, winding sentences that add layers of context
Preemptively address skeptics mid-thought with fourth-wall breaks
Add specific technical context even when making broad claims
Example: "...ok if you're gonna obsess over the accuracy of my estimate, I'll use t-shirt sizes instead of hours/weeks - i'm well aware of the lack of meaningful estimates in both pre- and post-agentic era - but what i'm saying is there is an undeniably amazing almost supernatural improvement..."

Concrete Over Abstract:

Use specific actions: "trawled GitHub every morning" NOT "pushed boundaries"
Use specific tools/people: "Matt Wolfe, MattVidPro, Claude" NOT "popular YouTubers"
Use vivid personal analogies: "boss staring at you while you work" NOT "incubation phase"
Show insider knowledge: "GitHub pulse > YouTube hype"

Tone Elements:

Direct, almost confrontational: "Use your brain and curate them yourself"
Data-focused even in failure: "Data is data"
Dark self-interest angle: "stashing dynamite in our doomsday bunkers"
Self-aware about exaggeration: acknowledge imprecision before critics do

NEVER Use:

"This isn't X, it's Y" profound-sounding structures
Cliché transitions: "here's the kicker", "here's where it gets interesting"
Abstract action verbs without details: "experimented relentlessly", "pushed boundaries"
Overly polished blog-speak
Clean, explanatory metaphors like "incubation phase"

Header Style:

Minimalistic: 2-4 words maximum
When read in sequence, headers tell their own story
No explanatory subtitles
Example progression: "Flat Charts" → "The Lab" → "Spring 2024" → "The Numbers" → "The Window"

句子结构：

富有信息量的“碎碎念”：较长、连贯的句子，添加多层上下文
在思考中提前回应质疑，打破第四面墙
即使提出宽泛观点，也加入具体技术背景
示例：“……好吧，如果你纠结我的估算准确性，那我用T恤尺码代替小时/周数——我很清楚在Agent时代前后，估算都没什么实际意义——但我想说的是，确实有那种近乎超自然的惊人提升……”

具体而非抽象：

使用具体动作：“每天早上逛GitHub”而非“突破边界”
提及具体工具/人物：“Matt Wolfe、MattVidPro、Claude”而非“知名YouTuber”
使用生动的个人类比：“老板盯着你干活”而非“孵化阶段”
展示内部视角：“GitHub动态 > YouTube热度”

语气特点：

直接，甚至略带对抗性：“动动脑筋，自己筛选”
即使失败也以数据为导向：“数据就是数据”
带有暗黑自利视角：“在末日掩体里囤炸药”
提前承认表述不精确，避免被批评

绝对不要使用：

“这不是X，而是Y”这类故作高深的表达
陈词滥调的过渡语：“重点来了”、“有趣的地方在这里”
无细节的抽象动词：“不懈实验”、“突破边界”
过于精致的博客腔
清晰的解释性比喻，比如“孵化阶段”

标题风格：

极简：最多2-4个词
连起来读能自成故事
无解释性副标题
示例递进：“扁平图表” → “实验室” → “2024春季” → “数据” → “窗口”

Content Strategy

内容策略

Opening:

Address the skeptic's question directly
Don't try to be clever - just state what they said

Body:

Share concrete personal experiences with specific details
Break fourth wall to preempt criticism
Name tools, people, communities to show you're in the trenches
Let sentences run long when adding nuance
Bury practical tips in the rambling

Addressing Critics:

Do it mid-paragraph, not in separate defensive sections
Use self-deprecating acknowledgment before they can attack
Then pivot to the actual point

Closing:

Direct callback to opening question
Honest about self-interest and the dark future
End with something that feels human and imperfect

开头：

直接回应质疑者的问题
不要试图耍聪明，直接陈述他们的观点

正文：

分享具体的个人经历与细节
打破第四面墙，提前回应批评
提及工具、人物、社区，展示你身处一线
需要增加细节时，允许句子变长
把实用技巧融入“碎碎念”中

回应批评：

在段落中间回应，而非单独写防御性章节
先自嘲式承认，再转回核心观点

结尾：

直接呼应开头的问题
坦诚自利视角与暗黑未来
以人性化、不完美的内容收尾

Examples

示例

Bad: "The shovelware isn't missing. It's incubating." Good: "I would say this is more accurately 'an incubation phase'. Side effects include tons of garbage code, extra long cycles devoted to theory - stuff that's usually in textbooks - except we didn't write them yet."

Bad: "I was hitting these incredible 'a-ha' moments weekly." Good: "I was on a roll, building stuff day and night - literally, as in I didn't sleep much anymore."

Bad: "Experimented relentlessly. Pushed boundaries. Tried to break things." Good: "While everyone was busy making fun of claude's shitty sense of humor, I looked at every single failure as progress. Data is data. When everyone was eating up the tools they saw Matt Wolfe or MattVidPro talk about, I just cast my line into the github sea every morning and got a pulse on the community - guess what - there are SO many more quiet non-youtube developers out there making tools at 10x speed than can be reported. Use your brain and curate them yourself."

错误： “这些内容不是缺失了，而是在孵化。” 正确： “我更愿意称之为‘孵化阶段’。副作用包括大量垃圾代码、花费在理论上的额外时间——通常是教科书里的内容——只是我们还没把它们写出来而已。”

错误： “我每周都有惊人的‘顿悟’时刻。” 正确： “我状态正佳，日夜不停地做东西——真的，我几乎都不睡觉了。”

错误： “不懈实验，突破边界，尝试破坏。” 正确： “当所有人都在嘲笑Claude糟糕的幽默感时，我把每一次失败都视为进步。数据就是数据。当所有人都在追捧Matt Wolfe或MattVidPro推荐的工具时，我每天早上都在GitHub的海洋里捞鱼，掌握社区动态——你猜怎么着——有太多不在YouTube上发声的开发者，以10倍的速度制作工具，这是媒体报道不了的。动动脑筋，自己筛选。”

Part 4: Category-Aware AEO System (Lightfast)

第四部分：基于分类的AEO体系（Lightfast）

Create category-aware, AEO-optimized blog posts.

创作基于分类、经过AEO优化的博客文章。

Critical: Accuracy Over Marketing

关键原则：准确性优先于营销

Before writing anything:

Verify every claim:
- If you cite a number, confirm the source
- If you mention a feature, confirm it exists in production
- When uncertain, ask for clarification
Never oversell:
- Disclose limitations: "Currently supports X; Y coming in vZ"
- Be honest about beta status and rollout timelines
Match category voice:
- Technology: Technical authority, data-driven
- Company: Visionary, category-defining
- Product: Problem-solver, benefit-oriented

开始写作前：

验证所有主张：
- 若引用数据，确认来源
- 若提及功能，确认已在生产环境中存在
- 不确定时，请求澄清
绝不夸大：
- 披露局限性：“目前支持X；Y将在vZ版本中推出”
- 坦诚说明Beta状态与发布时间表
匹配分类语气：
- 技术类：专业权威，数据驱动
- 公司类：富有远见，定义品类
- 产品类：解决问题，注重价值

Category Selection

分类选择

Category	Use When	Audience
Technology	Technical deep-dives, architecture, research	Developers, engineers
Company	Funding, partnerships, events, hiring	Executives, investors
Product	Feature launches, updates, tutorials	Customers, prospects

分类	适用场景	受众
技术类	技术深度解析、架构、研究	开发者、工程师
公司类	融资、合作、活动、招聘	高管、投资者
产品类	功能发布、更新、教程	客户、潜在用户

Writing Guidelines

写作指南

Concise & scannable: Match category word counts
Lead with value: Start with what readers gain
Be transparent: Mention beta status, limitations
Active voice: "You can now..." not "Users are able to..."
No emoji: Professional tone
Include TL;DR: 80-100 words for AI citation
FAQ section: 3-5 questions matching search queries
Code examples: Required for Technology posts

简洁易读： 匹配分类对应的字数要求
价值前置： 开头就说明读者能获得什么
保持透明： 提及Beta状态、局限性
主动语态： 用“你现在可以……”而非“用户能够……”
不使用表情符号： 保持专业语气
包含TL;DR： 80-100字，方便AI引用
FAQ部分： 3-5个匹配搜索查询的问题
代码示例： 技术类文章必须包含

Required Frontmatter

必备前置元数据

Every draft MUST include:

```
title
```
,
```
slug
```
,
```
publishedAt
```
,
```
category
```
(core)
```
excerpt
```
,
```
tldr
```
(AEO)
```
seo.metaDescription
```
,
```
seo.focusKeyword
```
(SEO)
```
_internal.status
```
,
```
_internal.generated
```
(traceability)

每篇草稿必须包含：

```
title
```
、
```
slug
```
、
```
publishedAt
```
、
```
category
```
（核心元数据）
```
excerpt
```
、
```
tldr
```
（AEO优化）
```
seo.metaDescription
```
、
```
seo.focusKeyword
```
（SEO优化）
```
_internal.status
```
、
```
_internal.generated
```
（可追溯性）

Part 5: Diagram Generation

第五部分：图表生成

When to Use Diagrams

何时使用图表

Scenario	Diagram Type
Request flow	Sequence diagram
System architecture	Box-and-arrow diagram
Decision logic	Flowchart
Data model	ER diagram
Performance comparison	Bar/line chart
Before/after	Side-by-side

For architecture diagrams and benchmark visualizations:

Use diagramming tools (Mermaid, Excalidraw, draw.io) for architecture diagrams and charting libraries (matplotlib, Chart.js) for benchmark visualizations. These tools provide better control, are self-hosted, and avoid third-party execution risks.

场景	图表类型
请求流程	时序图
系统架构	框线图
决策逻辑	流程图
数据模型	ER图
性能对比	柱状图/折线图
前后对比	并列对比图

架构图与基准测试可视化要求：

使用绘图工具（Mermaid、Excalidraw、draw.io）制作架构图，使用图表库（matplotlib、Chart.js）制作基准测试可视化。这些工具可控性更强，支持自托管，避免第三方执行风险。

Part 6: Distribution

第六部分：分发

Where Developers Read

开发者阅读平台

Platform	Format	How to Post
Your blog	Full article	Primary — own your content
Dev.to	Cross-post (canonical URL back to yours)	Markdown import
Hashnode	Cross-post (canonical URL)	Markdown import
Hacker News	Link submission	Show HN for projects, tell HN for stories
Reddit (r/programming, r/webdev, etc.)	Link or discussion	Follow subreddit rules
Twitter/X	Thread summary + link	See twitter-thread-creation skill
LinkedIn	Adapted version + link	See linkedin-content skill

平台	格式	发布方式
个人博客	完整文章	首选——掌握内容所有权
Dev.to	交叉发布（添加指向个人博客的规范URL）	Markdown导入
Hashnode	交叉发布（添加规范URL）	Markdown导入
Hacker News	链接提交	项目用Show HN，故事用tell HN
Reddit（r/programming、r/webdev等）	链接或讨论	遵守子版块规则
Twitter/X	线程摘要+链接	参考twitter-thread-creation技能
LinkedIn	改编版本+链接	参考linkedin-content技能

Common Mistakes

常见错误

Mistake	Problem	Fix
No TL;DR	Busy devs leave before getting the point	2-3 sentence summary at the top
Broken code examples	Destroys all credibility	Test every code block before publishing
No version pinning	Code breaks in 6 months	"Works with Node 20, React 18.2"
"Simply do X"	Dismissive, condescending	Remove "simply", "just", "easily"
No diagrams for architecture	Walls of text describing systems	One diagram > 500 words
Marketing tone	Developers instantly disengage	Direct, technical, honest
No trade-offs section	Reads as biased marketing	Always discuss downsides
Giant introduction before content	Readers bounce	Get to the point in 2-3 paragraphs
Unpinned dependencies	Tutorial breaks for future readers	Pin versions, note date written
No "Further Reading"	Dead end, no context	3-5 links to deepen understanding

错误	问题	修复方案
无TL;DR	忙碌的开发者还没看到核心内容就离开了	在顶部添加2-3句话的摘要
代码示例无法运行	彻底失去读者信任	发布前测试所有代码块
未固定依赖版本	6个月后代码就无法运行	标注“兼容Node 20、React 18.2”
使用“只需执行X”	傲慢、轻视读者	删除“只需”、“仅仅”、“轻松”这类词
架构类文章无图表	大段文字描述系统，可读性差	一张图表胜过500字描述
营销语气过重	开发者会立刻失去兴趣	直接、技术化、坦诚的语气
无取舍说明	读起来像有偏见的营销内容	始终讨论缺点
核心内容前有大段引言	读者会直接退出	用2-3段内容快速切入主题
依赖版本未固定	教程对未来读者失效	固定版本，标注写作日期
无“延伸阅读”	内容戛然而止，缺乏上下文	添加3-5个相关链接帮助读者深入了解

Bundled Resources

配套资源

References

参考资料

```
references/voice-tone.md
```
- Complete Nick Nisi voice and tone guide
```
references/story-circle.md
```
- Story Circle narrative framework

```
references/voice-tone.md
```
- 完整的Nick Nisi风格指南
```
references/story-circle.md
```
- 故事循环叙事框架

Usage

使用方式

Load reference files when writing in specific voices:

Nick Nisi voice → read

references/voice-tone.md

references/story-circle.md

Jarad voice → use Part 3 guidelines
Technical writing → use Part 1 & 2
Category-aware → use Part 4

写作特定风格时加载对应参考文件：

Nick Nisi风格 → 阅读

references/voice-tone.md

references/story-circle.md

Jarad风格 → 使用第三部分指南
技术写作 → 使用第一、二部分内容
分类写作 → 使用第四部分内容