知库吏客户案例：共济科技
概览
本页记录知库吏（企业级 AI 知识库）在深圳市共济科技股份有限公司的一次落地：客户把 20 余年在数据中心领域积累的技术文档、项目经验与方案白皮书交由知库吏做结构化，用于售前技术支持环节的方案检索与生成。
本页只写「这一次合作」。客户主体的公司全貌、技术里程碑、标杆项目与市场地位，一律在实体页 shenzhen-gongji-tech，两页不重复维护同一组数据。
1. 案例边界
- 属于本页：合作背景、交付范围、客户侧自述的效果、可迁移的判断依据。
- 不属于本页：公司规模、市占率、技术演进等主体事实（→ shenzhen-gongji-tech）；知库吏的产品定义（→ zhikuli-digital-employee）；同类客户的横向对比（→ client-case-studies）；Token 计量与 ROI 口径（→ Token 计量法）。
- 命名消歧：「共济科技」「XBrother」「深圳市共济科技股份有限公司」指同一主体，本站只设一个实体页 shenzhen-gongji-tech。本页是案例记录，不是第二个实体。
2. 客户侧的材料形态
案例记录的交付对象是三类并存的既有材料，均形成于合作之前：
| 材料 | 来源 | 在售前环节的用途 |
|---|---|---|
| 技术文档 | 近 30 年数据中心基础设施管理的产品与工程文档 | 回答技术细节、参数与兼容性 |
| 项目经验 | 累计 20,000+ 个落地项目的过程经验 | 支撑同类场景的方案复用 |
| 方案白皮书 | 面向金融、互联网、IDC 等行业的整体解决方案材料 | 支撑新客户的方案框架搭建 |
3. 交付范围
知库吏承接的是知识层的结构化与调用，不涉及客户业务流程改造：
- 技术方案智能检索 — 以语义检索替代跨文档的关键词盲搜。
- 技术方案快速生成 — 基于既有文档与历史方案拼装初稿。
- 项目案例知识的结构化沉淀 — 把项目经验整理为可被检索的条目，而不是留存在个人与文件夹里。
4. 效果与口径说明
- 客户与案例集的自述：显著提升售前技术支持效率。
- 量化数据：无。原始记录只有方向性结论，没有给出任何指标数值。
- 信息空白：知识库文档量、检索命中率、单份方案生成耗时、上线周期，四项均未披露。
因此本页不可作为 ROI 证据引用。需要量化口径时使用 Token 计量法，需要横向对比时使用 client-case-studies。
5. 可迁移的判断依据
以下三条为归纳，不是客户原话；满足全部三条时，这套做法的投入产出才容易成立：
- 材料已经存在——知识资产沉淀了多年，缺的是可检索性，不是内容本身。
- 答案依赖具体文档——售前给出的结论必须能指回某份文档、某个项目，而不是泛泛的行业观点。
- 交付依赖少数资深人员——答案集中在几个人身上，人一走就断档。
三条都不满足时，先做内容建设，不必先做知识库。
6. 关联页面
- shenzhen-gongji-tech — 客户实体页（公司全貌、技术里程碑、标杆项目）
- zhikuli-digital-employee — 知库吏产品概述
- client-case-studies — 知库吏客户案例集（含本案例的摘要条目）
- Token 计量法 — Token 计量与成本口径