ai_context 序列化器 #
为大语言模型而非数据库构建的、确定性且理解数据结构的记录视图：已解析、带关联、最新，而不是需要模型自行解读的原始数据行。每个实体都有一个，这样跨模块的回答两次都能以同样的数据为依据。
详细介绍见： 每条记录都能自我说明
术语表
本站用自己的一套词汇来论证，而其中有些词在业内其他地方用得很随意。这里写明我们使用每个词时的确切含义，写法便于引用，包括被机器引用。
A
AI 原生 #
AI 层位于系统每个部分之下，而不是挂在某一部分旁边。检验标准不是产品有没有 AI 功能，而是一个跨越两个业务领域的问题能否用一次查询回答。外挂的 AI 演示效果很好，实际使用时却只能局限于单一孤岛。
详细介绍见： AI 原生平台为何胜出
B
按
回
回滚路径 #
写入操作的回退方式。大多数记录采用软删除，删除后可以从回收站恢复；Ask Cyril 与人工操作走同一套服务代码，而不是另一条更弱的写入通道。但这并不意味着智能体的每个操作都可撤销。
详细介绍见： 让 AI 安全行动，需要同一份审计日志
集
客
连
模
企
软
生
事
事实锚定 #
把模型的回答与它实际获得的具体记录绑定，使回答可以对照这些记录核实。上下文太单薄，换个更好的模型也解决不了：只拿到五分之一数据的模型，仍然只能回答五分之一的问题，只是说得更流畅。
详细介绍见： 每条记录都能自我说明
数
同
同一份审计日志 #
各模块中的登录、设置和记录变更都写入同一份记录，包含执行者、操作、所涉记录和时间戳，支持会话也会被单独标记。Ask Cyril 对每次运行另有记录：执行计划、审批人以及每一步做了什么。
详细介绍见： 让 AI 安全行动，需要同一份审计日志
同一张数据图谱 #
每个模块中的每条记录，都是同一个数据结构中的一个节点，因此一个商机、交付它的项目、针对它提出的工单以及它对应的发票，是真正相互关联的，而不是靠相同的客户名称来匹配。本站的其他所有主张，都依赖这一特性。
详细介绍见： 产品总览
同一套权限模型 #
对“谁能看什么、做什么”的单一定义，同样适用于每个模块和 AI 层。AI 是受其约束的调用方，而不是例外，所以助手不可能调出提问者本人打不开的记录。
详细介绍见： 信任中心