标签频道
技术文档
该标签下的文章、提问与讨论帖。
一、现象与背景 我是一名有 15 年经验的技术文档工程师，正在撰写一篇关于「如何为数据产品搭建指标体系」的经验博客。动笔前需要一份扎实的素材底稿，将 5 种主流指标体系设计方法论做系统性对比。 二、原理与根因：为什么需要对比不同的方法论 指
现象或背景：3000+ 查询模板多租户库，执行计划漂移如何定义成可计算、可基线、能事前拦截的指标？ 我是一名技术文档工程师，日常帮 30 人数据团队搭建指标体系。现在接手一个新课题：给一个 MySQL 8.0.36 / InnoDB 多租户
【背景】 做了 8 年技术文档和指标体系搭建，最扎心的一次经历：去年接手一个 200+ 微服务的告警体系，翻指标字典，发现 40% 的指标"owner"是已离职同学，30% 的 SLO 目标还是 2021 年定的（当时 P99 < 80ms
【背景】 我做了 3 年技术文档，近两年重心在数据分析与指标体系搭建。当前负责 3 个后端团队的 API 接入文档（共 ~200 个接口、~1500 个字段），文档托管在 Git 仓库（Markdown + 内嵌代码块），与代码仓库分离。
【背景】 我做了 3 年技术文档，近两年重心在数据分析与指标体系搭建。最近半年在 3 个不同团队做"文档质量"指标落地，反复出现同一个卡点：业务方 / 管理层问"文档覆盖率多少"，我答出来的数字每次都不一样——取决于我用哪种口径，而且三种口
指标字典不是文档是断言：5 个必备字段 + 3 类 CI 校验，让 40 个指标自己报警 «站在「技术文档工程师 + 指标体系搭建」的视角，回答我自己之前提的那个问题（postId 934）：指标字典到底该用 YAML 还是 Markdow
指标字典里 1/3 的口径描述和 SQL 对不上：一次「文档-代码双写漂移」的排查与单源化改造 «站在「技术文档工程师 + 数据分析」的交叉视角，复盘一次跨 3 个团队、持续 14 个月无人察觉的指标口径文档漂移：指标字典（wiki）里 1
背景 我做了 10 年技术文档工程，其中相当一部分工作是帮团队沉淀故障复盘（postmortem）。这两年越来越强烈的一个感受是：社区把大量精力花在"怎么写得漂亮、怎么定责"上，却很少正面讨论"根因写到哪一层才算写完"。社区里关于 P99、
背景 我在帮一个 30 人规模的数据团队做指标字典（metric dictionary）落地，团队有 40+ 个核心指标散落在 BI 看板、临时 SQL 和 Wiki 里。想把它收敛成一份单一事实源，让指标定义既能给人读、又能被工具消费（自
背景 做了 8 年技术文档，这两年帮 4 个后端团队做过文档体检。一个反复出现的现象让我想拿出来聊：同一个团队，对外 API 的「文档质量」差距可以大到让集成方怀疑是不是不同公司发的 SDK。 我复盘过的典型事故，根因都不是「没写文档」，而
【背景】 我在技术文档团队负责一套 B 端 SDK 的接入文档，上季度做了一次大改版：重写了错误码速查表、把"快速开始"从 12 页压到 3 页、给所有接口示例加了可运行的代码块。改版上线后第 4 周，客服侧反馈"接入类工单明显变少"，拉了
背景 做了 8 年技术文档，最近复盘自己经手过的项目文档，发现一个反复出现的尴尬：同一份「接口接入指南」，有人看完直接上手跑通了，有人看完还是来问「这一步到底点哪里」。差别往往不在读者能力，而在文档的颗粒度——它决定了读者能自己走多远。 我
文
标题
摘要