你的概念就该是概念，任务就该是任务

访谈说：你的概念就该是概念，不要混进参考或任务；任务就该是任务，教程就该是教程。你需要让东西既可以被人类用户消费，也可以被机器侧的爬虫与消费者消费。

类型是契约：读者（和助手）知道打开这一页会得到什么。契约破了，复用就破了。一页既讲原理又塞步骤，人要自己剔骨；助手更容易总结串台——原理当步骤、示例当承诺、培训故事当现网规格。全能页往往谁都伺候不好：想学概念的人被步骤打断，想动手的人被长篇原理劝退，想查字段的人在散文里捞针。打开一页却不知道「这一页到底在办哪件事」，是类型混的第一现场症状。

行业里常见的类型纪律（概念 / 任务 / 参考 / 教程一类分法）在此只作语言参考，不写成 Baklib 内置模板品牌名。重要的是纪律本身：先约定这一栏放什么，再往里堆字。名字可以自创，边界必须清楚——这一页到底是在回答「是什么 / 边界在哪」，还是「此刻怎么做完」，还是「字段与约束是什么」，还是「跟我练一遍」。混在一起，检索与总结都会交税。

公开观察里，一半以上团队在用自创的信息架构指南，也有人套用既有框架，仍凭直觉的也不少——类型纪律还没成为行业默认。方向却清楚：指南上升、直觉下降。先约定类型，再谈问答吃哪一类块；否则模型只是更流畅地混煮。对国内团队更实用的说法是：先把「这一页办哪件事」写进栏目约定，再往里堆字——比先争论框架叫什么、再继续写全能页，便宜得多。

搜「如何导出」命中一篇半概念半步骤的长文，人要自己剔骨；助手更容易总结串台。混类型，是可发现性的隐形税：标题像任务，正文却大半是产品哲学；标题像概念，正文却夹着未经验证的操作捷径。国内帮助中心尤甚：产品介绍、操作步骤、错误码表、培训长文塞进同一 URL，标题还起得很「全能」——「导出功能完全指南」听起来勤奋，打开却不知道该从哪一段开始动手。客服收藏夹里往往另存一版「真正能用的步骤」，对外站上仍是那锅粥。

内容模型——白话就是事先约定一类内容该有哪些字段与结构——规定不同类型必填什么：任务页要有适用场景与步骤，概念页要有边界与非目标，参考页要有字段与约束，教程页要有目标与练习路径。没有模型，分类栏只是装修：看起来分了栏，栏里仍是同一锅粥。字段不定，审核也不知道该查什么——查文采，还是查步骤能不能走通？

分类体系管理 则让这些类型在树上可导航、可过滤，而不是靠作者个人感觉临时起文件夹名。栏目按类型与用户任务排，检索才知道该优先命中哪一类；标签与元数据才能说「只要任务型、只要现行版」。分类若只按部门挂目录，类型纪律落不了地——规矩必须落在对外看得见的树上。

微内容 适合承载短任务与 FAQ；它不适合把整本概念手册塞进一条气泡。类型对了，短才有用；类型错了，短只会更快传播错用——三步操作里夹一句未标明边界的「支持全部导出」，断章出去就是事故。混类型还有一种组织成本：发版时不知道该改哪一页。参数默认值变了，到底改概念页、任务页还是参考表？全能页里四处都像相关，四处都可能漏改。类型分开，变更路径才短：改规格回概念与参考，改步骤回任务，改练习回教程。

公开观察里，自创信息架构指南的比例不低，仍凭直觉的也不少——类型纪律还没成为行业默认。方向却清楚：指南上升、直觉下降。先约定「这一栏只放任务型」，再谈问答吃哪一类块。类型先定，检索与总结才有边界；否则模型只是更流畅地混煮。工具选择和结构选择，越来越像同一件事：你选什么发布形态，往往已经暗示了你允许多混的类型。

国内可执行的约定不必厚，写成团队一页就够。帮助中心三栏——任务、FAQ、概念；开发者参考与操作步骤分栏；培训与长教程走视频或课程入口，而不是硬塞进帮助页当「完全指南」。写进周会约定，比每次发版争论「这篇算说明书还是算营销稿」便宜。售前材料可以讲故事，帮助页应讲现行步骤——穿衣风格本来就该不同，就像商场一楼和负一层办的事不一样。乱，通常不是因为门多，而是因为每扇门后面各养了一套货，还把概念、任务、参考搅在同一 URL 里。

验收也可以很土。挑十个真实搜索词，看命中页的类型是否与搜索意图一致：「如何…」应落到任务页，「什么是…」应落到概念页，「字段 / 错误码」应落到参考。命中全能页或类型错位页，就拆，而不是再加一篇更全能的。指南的价值不在厚，在于大家认账：这一栏放什么、不放什么。直觉不是罪过；没有指南的直觉，才会在发版周把类型再次搅乱。指南上升，不是为了显得规范，是为了让人和机器共用同一套预期。

发版周尤其容易破功。功能急着上，文档同学被催「先写一页顶上」，于是概念、步骤、错误码、培训话术又被揉进同一 URL。当时省事，两周后检索开始串台，客服开始另存「真正能用」的飞书稿。类型纪律若只写在年度规划里，发版周一定守不住；纪律要落在栏目与内容模型上——这一栏拒收混类型稿，比事后开整改会便宜。

帮助中心 按任务 / FAQ / 概念分栏；开发文档 里参考与操作分开；视频教程门户 承担教程形态。便于检索和总结，也便于人扫读。建设侧模板点亮不同叶子时，事先划清类型，后面少很多「这篇到底算说明书还是算营销稿」的扯皮。门脸可以不同，类型边界应事先写进约定——Help 讲任务，Docs 讲规格与概念，Developers 讲参考与对接，Videos 讲跟练，而不是四个门口各写一锅全能粥。

问答与搜索放在后面。它们应只读已发布、类型清楚的块——任务块回答怎么做，概念块回答是什么，参考块回答字段与约束。类型先定，到达层才有边界；类型混着，对话框只会更流畅地串台。先点亮 Help、Docs、Developers、Videos 一类叶子时，把类型写进约定，比先上一个很炫的对话框便宜。内容模型与分类体系先立住，微内容才知道该短成什么样——短在任务与 FAQ 上有用，短在把概念手册塞进气泡里只会更快错用。

落地验收不妨对着搜索意图做。十个真实问题里，有几个命中了类型错位页？错位就拆：概念留边界，任务留步骤，参考留字段，教程留练习路径。帮助中心少写全能指南，开发文档少把操作散文塞进错误码表，视频门户少把十分钟跟练硬塞进帮助页当「完全手册」。类型分开，人和机器才知道打开这一页会得到什么；混在一起，写得再勤也像没交付。

软件团队起步时，不妨先点亮这三片叶子：帮助中心接任务与 FAQ，开发文档接参考与对接，视频教程门户接跟练。概念说明可以放在文档站或帮助中心的概念栏，但不要再塞进任务页当开场长文。类型边界写进一页团队约定，发版周就少一次「先写一页顶上」的全能稿。问答可以后接；类型没定，问答只会更快串台。

类型不混，人和机器才用得上。混了，写得再勤，也像把厨房和仓库锁进同一扇门——谁进去都找错抽屉。概念归概念，任务归任务；分开，是为了复用和到达，不是为了显得规范。契约清楚，人和机器才知道这一页该怎么用。