我们让 AI 整理一份行业数据，回答读起来严丝合缝、专业自信，核对时才发现——真数据、过时数据、凭空编的数据，混在同一段话里，外表完全看不出区别。
这件事背后是一个正在恶化的不对称：**AI 把「生成」的成本降到了接近零，却把「信任」的成本推到了历史最高。**核对一段 500 字的回答，常常比写它还费时间。时间久了，大家养成两种坏习惯：要么盲目信任，要么一律不信。这两种态度，对 AI 都没有好处。
我们不想在「读起来流畅但不敢信」和「逐句人工查证累到放弃」之间二选一——所以做了 HallucC。
动手之前我们看了一圈市面上已有的东西，发现一个空档。三个判断，决定了这个产品的形状：
判断一
评测框架解决不了运行时问题
现有 eval 工具面向开发者上线前的批量测试：跑 prompt、跑数据集。但「这条回答里哪一句是真的」是运行时、逐句、还经常要给非技术同事看的问题。没有产品把「逐句核验 + 给出证据 + 给出修正」做成普通人敢直接用的东西。
判断二
误报是核验工具的第一死因
一个整天喊「这句是编的」、结果一查冤枉了 AI 的工具，两周之内就会被用户抛弃。所以 HallucC 从第一天起把「控误报」当作设计底线：证据不足就老实降级为「无法核实」，绝不强行判假。可信的裁判，比锋利的裁判更重要。
判断三
Agent 让错误从「一句」变成「一条链」
Agent 的错误很少凭空出现——往往是某一步工具调用返回了坏数据，随后被逐环放大。传统 tracing 只告诉你「发生了什么」，不告诉你「哪一步开始不真实」。于是我们把验证延伸到全链路：比对工具返回与最终回答，把幻觉的传播路径画出来。
**02：**给谁用：三类人，排序是刻意的
我们假设了三类核心用户，优先级明确：开发者帮我们把产品打磨锋利，内容团队让我们活下来，合规角色让我们进得去门。
1：第一批最懂痛的人 · 决定产品口碑
Agent / AI 应用开发者
用 Coze、Dify 或自建链路搭 Agent 的开发者。把 HallucC 当成工作流里的检测节点和安全网关：请求进模型前先拦 Prompt 注入与越狱，回答出去前先做逐句核验；Agent 轨迹验证帮他们在多步链路里定位「事实从哪一步开始漂移」——六维评估（任务完成、工具选择、参数一致、结果忠实、传播可控、执行效率）给出可解释的体检报告。
2：最愿意为准确付钱的人 · 决定商业价值
高风险领域的内容生产与审核团队
金融研报、法律文书、医疗科普、政务与教育材料的内容团队。他们的真实工作流是「AI 出初稿 → 逐句核验 → 采纳最小修正 → 签字负责」。六大垂直领域（通用 / 医疗 / 法律 / 金融 / 教育 / 政务）的专属验证标准和私有知识库，就是为这条流水线准备的：内部资料也能作为核验基准。
3：决定能不能上的守门人 · 决定企业渗透
企业 AI 治理与合规负责人
他们关心的问题不是「好不好用」，而是「出事了能不能交代」：OWASP LLM Top 10 对齐、40+ 特征实时检测、PII 脱敏、拦截留痕可审计。安全网关毫秒级串接在现有链路之前，恶意请求不消耗模型额度、不触达业务逻辑。
下一步 90 天，想验证什么
上面每一个论断其实都还只是假设。接下来 90 天，我们想用数据验证四件事——它们分别回答「谁在用、敢不敢信、是不是真价值、愿不愿付钱」：
**1：**谁真的留下来了
三类人群假设，哪一类的激活率和留存最高？这个结果直接决定首页第一屏放「安全网关」还是「逐句核验」，也决定销售资源往哪个方向压。
分人群激活率7 日留存人均重复检测次数
**2：**判定敢不敢被信
把误报当一级指标：收集用户对「存疑 / 无法核实」判定的申诉，看误报率能不能压到「敢当裁判」的水平。每一条被推翻的判定都进回归集，而不是被遗忘。
判定申诉率误报样本回收率「无法核实」占比的健康区间
**3：**修正是不是真价值
用户是看完标注就走，还是逐条采纳修正、导出交付？采纳率是「检测报告工具」和「修订工作流工具」之间的分水岭，决定产品往哪边长。
修正采纳率导出 / diff 使用率单文档核验完成率
**4：**有没有人愿意为「深度」付钱
Coze / Dify 插件有没有人装、装了有没有周活调用？私有知识库配置率能否证明垂直场景是真需求？免费额度之后，最先出现的付费理由是按次、按坐席、还是按调用量。
插件安装与周活KB 配置率付费转化与首选付费理由
