贡献指南
所有内容通过 Git 分支和 Pull Request 协作。小步提交，一次 PR 聚焦一个主题；重要判断在正文中保留来源和验证条件。
Markdown 规范
- 每页只保留一个一级标题，标题层级依次递进。
- 使用相对站内链接，如
[发布流程](/engineering/delivery)；外部事实链接到原始公告、官方文档或法规原文。 - 命令、字段名和状态使用反引号；步骤使用有序列表；比较信息优先使用表格。
- 截图只用于无法用文本表达的界面状态，必须脱敏并补充文字说明。
- 文件名采用小写英文和连字符，目录按主题组织。
Frontmatter
每篇正文至少包含：
yaml
---
title: 页面标题
description: 一句话描述
status: draft # draft | review | maintained | archived
owner: team-member
last_reviewed: 2026-07-26
---owner 表示维护责任，不代表内容仅由一人编辑。发生政策、价格、接口或产品能力变化时，更新 last_reviewed 并说明变化。
内容结构
成熟实践建议依次写明：适用场景、前置条件、步骤、验证、回滚、风险、来源和变更记录。尚未成熟时使用文章模板，明确“已知”“待验证”“不覆盖”的范围。
责任人与复核
- 法律合规：yiran 负责组织复核。
- 基础设施、云服务、网络、邮件、支付接入与申诉：liuzy。
- 产品工程、telemetry、灰度、监控、Vibe Coding、CI/CD、发包、Cloudflare/GitHub：piglet。
- 财务、采购、账户、发票、税务、企业客户：cherry。
- 未明确主题由
team暂管，在进入maintained前指定负责人。
法律、财务、税务、支付及投资内容不得仅凭单人经验进入 maintained。至少需要领域负责人复核；高影响事项应链接现行一手材料，并建议读者咨询持证专业人士。
交叉链接与来源
- 只在确有上下游关系时交叉链接，避免重复复制正文。
- 对会变化的费用、政策、区域可用性和产品能力写明“验证于 YYYY-MM-DD”。
- 二手文章可以帮助发现问题，但关键结论应回到法规、监管机构、服务商或项目官方资料。
- 引用原文时保持短小并注明出处，不复制受版权保护的大段内容。
敏感信息禁入
禁止提交任何真实凭据、.env、cookie、API token、私钥、助记词、邮件授权码、支付密钥、个人身份材料、未脱敏流水或客户数据。示例一律使用明显的占位符，例如 YOUR_API_TOKEN。
发现泄露时，不要只删除文件：立即停止传播、撤销并轮换凭据，再由仓库管理员按影响范围处理历史记录。
提交前检查
- [ ] 页面可本地构建，站内链接有效。
- [ ] Frontmatter、状态、负责人和复核日期完整。
- [ ] 事实与观点已区分，时效信息有来源。
- [ ] 不含凭据、隐私信息或规避限制的指南。
- [ ] 高风险主题已获得对应负责人复核。