云数据库专属集群 部署架构图
现在的专属集群里具备了所有的云数据库的安全能力，同时在这些能力基础上集成了物理隔离能力，面对行业的合规性问题。
整个过程当中，我们在平台建设、业务支持、平台运营、AI创新以及AI整体运营等各个方面做了很多尝试，有了不少的收获和感悟。
最近，我花了一些时间，将其初步梳理出来，写成了这篇文章。
因为具体的标注工作，都是外包公司的数百个标注人员做的，他们才是标注页面的真正用户。
不是真正的用户、没有处在那个场景，就很难了解真实的情况。于是，大家就只能根据自己的经验和专业能力，进行判断和推演。
正确的方式是，先把具体的产品抛下，多了解客户的背景、业务、状态等整体的、背景的、来龙去脉的信息，要表现出对客户“感兴趣”，要想成为客户的朋友。
满足需求，不断“由浅入深”，修炼“无我境界”。
接着，让我们的思考再深入一些。
现在，假设你已经明确了用户是谁、摸到了需求的大概脉络，那也要考量“对需求理解是否深入”的问题，即浅层需求和深层需求的问题。
只有这样，才算是满足了深层需求。
道理是相通的，类似问题在C端产品中也会碰到。
如果你留意的话，你会发现很多电商网站、汽车导购产品的产品经理已经摸到了深层需求。
对于深入满足用户需求，除了做浅层、深层的分析之外，还可以采用“分而治之”的思路，将产品从模块和功能上分层，即分出“N级火箭”，每一级“火箭”用来满足不同类型的用户需求，或者同一用户在不同阶段的需求。
第一级，功能嵌入：通过iframe等实现成本最低的手段，将平台的某个功能模块嵌入到自己的系统当中。
第二级，API调用：直接调用平台提供的成熟API，比如调用sf证、驾驶证之类的OCR识别的API。
这一点看起来没什么深奥的，但常见的问题是，产品经理在产品设计前期，对框架的思考不够充分。经常是到了PRD、视觉评审阶段，才发现模块设计不合理、流程不清晰等等。这时，再返工、改动，成本就大了。
这里说的“帮助体系”，指的是产品化的帮助体系，即 “文档产品化”。具体来说，就是把帮助文档中的要点尽量嵌入到产品页面当中，让产品实现“自解释”，而不是放到产品体外、仅仅存到帮助文档中。
