文章指南

Lab article 是长期有效的手册页面。它把一个有价值的 signal、问题或研究线索，转化成未来学习者可以直接使用的结构化解释，而不需要他们回到最初的聊天或讨论现场。 当输出应该成为关于概念、模式、系统、生态方向或案例研究的长期页面时，使用这个贡献类型。Lab article 不是聊天记录、快速笔记，也不是松散的 source roundup。它应该帮助读者理解主题、为什么重要、如何思考，以及下一步读什么。

​

文章应放置在哪里

根据主题选择分类，而不是根据启发草稿的源章节来选。

​

Issue 和 review 流程

在起草文章之前，先创建 GitHub issue。使用 Content Proposal 表单，并选择 Lab article 或 Major revision to an existing lab page。 核心团队会先 review issue。他们可能批准 scope、请求修改，或拒绝 proposal。issue 被批准或确认之后，贡献者可以 fork 仓库并开始修改。 核心团队会再单独 review pull request。他们可能批准、请求修改，或拒绝 PR。如果 issue 或 PR 被拒绝，贡献者仍然可以保留自己的 fork，并在仓库外继续使用这些改动。

​

必需结构

每篇文章都应遵循：

• metadata-schema.mdx 中的元数据契约
• Article Template 中的结构

必需部分：

• Summary
• Why It Matters
• Mental Model
• Architecture Diagram
• Tool Landscape
• Tradeoffs
• Citations
• Reading Extensions
• Update Log

​

工作规则

• 使用仓库原生英文撰写。
• 概念和引用使用来源输入，而不是直接保留其行文。
• 保持图示简洁，并由仓库自有内容维护。
• 链接到相关的实验室页面，使文章成为更大地图的一部分。
• 保持页面具有长期适用性。如果某个说法很可能很快过时，要么验证它，要么 用不依赖时间的语言来写。

​

完成标准

当一篇文章满足以下条件时，即可进入审阅：

• 与该分类清晰匹配
• 遵循元数据和章节模板
• 引用了主要来源
• 避免照搬上游教学流程
• 至少包含一个有用的内部阅读链接