团队知识库标准化写作

团队知识库为什么容易失控

中国中小企业的团队知识库常面临一个共同问题：信息散落在飞书文档、企业微信、本地 Word 文件和个人笔记里，当有人试图把这些内容整理成正式业务文档时，会遇到几个具体的麻烦。首先是写作风格不统一——销售团队偏口语化，技术团队堆满术语，管理层需要的却是结论先行的摘要。其次是事实依据缺失，文档里经常出现"应该"、"大概"、"以前是这样"这类模糊表述，事后无法追溯。第三是协作边界模糊，文档修改后很难判断是基于事实还是个人推测，也不清楚谁该对哪个章节负责。

更隐蔽的问题是，很多团队把知识库当作"收集箱"而不是"决策依据"。文档越写越长，但能支撑会议决策、项目复盘或制度落地的内容，往往被淹没在无关细节里。

核心能力与执行步骤

这个 Skill 是一套围绕中国业务场景设计的文档生成工作流。

信息确认是第一步。 写作前，Skill 会列出缺失的关键信息，如业务目标、负责人、时间约束、已有数据和不可改变条件。涉及价格、案例、资质或经营结果时，Skill 不会自行编造，而是标注为待确认项。

结构化拆解是核心。 Skill 把写作任务拆成可检查模块，每个模块有明确负责人和依赖关系。文档结构遵循目标→事实→可执行性→合规→交付的层次，确保最终页面既有背景信息也有具体行动项。

证据标注是关键。 Skill 将事实、推断、建议和待确认信息分开标注，让读者清楚区分已验证数据、经验推测和需要人工确认的开放问题。

发布前复核是底线。 输出前，Skill 会检查文档是否对应真实业务目标、每项建议是否有负责人和检查标准、名称和输入是否一致。硬门槛不满足时，Skill 直接输出暂不可交付，而不是生成看似完整但无法落地的文档。

适用边界

Skill 不代替管理者、法务、财务或人力负责人做最终决策。它生成的是文档框架和执行建议，不是决策结论。涉及真实发送、发布、付费或生产变更时，会要求用户明确授权。

Skill 不读取、记录或输出密钥、Token 或无关个人信息，也不把本地文档或模板冒充成已执行的平台操作。这些边界不是限制，而是保证输出质量的基础。