2. 食品添加剂使用标准查询应用的需求分析

在动手设计任何查询工具之前，先把“谁会用它、在什么场景下用、卡在哪里”想清楚，比急着画界面更重要。食品添加剂使用标准（以 GB 2760 为代表）本身是一部结构复杂、条款密集的强制性标准，它按食品分类号组织，按添加剂品种列出使用范围与最大使用量，还附带“按生产需要适量使用”的例外规则和各类备注。不同角色面对同一部标准，查询路径和痛点截然不同。本节围绕食品企业、监管人员、研发人员三类典型用户，梳理其真实查询场景与痛点，并据此划定应用的功能边界。

三类典型用户的查询场景与痛点

食品企业（合规与品控岗）的典型场景是“反向核对”：手里已有配方和产品，需要确认某种添加剂能不能用、最多用多少。例如一家生产酱腌菜的企业，配方中拟加入某防腐剂，品控人员要回答三个问题：本产品在标准中归入哪个食品分类号？该添加剂在该分类下的最大使用量是多少？是否受“残留量”或“以某种物质计”的折算规则约束。痛点集中在分类判定上——食品分类号往往需要逐级下钻，且企业产品常处于两个类别之间，判定错误会直接导致超范围或超量使用。此外，企业还要应对配方调整、供应商变更带来的重复核对，人工翻查效率低、易遗漏。

监管人员的典型场景是“抽检判定与现场核查”：拿到一份检测报告或货架产品，需要快速判断某添加剂的检出值是否合规。他们的痛点在于判定链条长——先确定产品分类，再确认该添加剂是否允许使用，然后比对限量，最后还要处理“不得使用”与“未检出”的区别、复配添加剂带入原则等边界情形。监管场景还要求结论可追溯，即能说明依据的是标准哪一条、哪个表、哪条备注，否则执法文书缺乏支撑。

研发人员的典型场景是“正向探索”：在配方设计阶段，希望知道某类食品中允许使用哪些同类功能的添加剂、各自的限量如何，以便在防腐、着色、增稠等目标下做方案比选。他们的痛点不是查不到单一品种，而是难以横向比较——同一功能类别下多个添加剂的适用范围和限量分散在不同条目中，缺少按功能、按食品类别聚合的视图，导致选型时反复切换、凭经验取舍。

用一张图看清需求结构

下图把三类用户的输入、查询路径、核心痛点与期望输出放在同一张关系图中，便于对照理解功能边界应当覆盖哪些环节。

从痛点推导功能边界

需求分析的价值不仅在于“列出要做什么”，更在于“明确不做什么”。综合三类场景，应用的功能边界可以这样划定。

必须做的核心功能包括四项。第一是食品分类定位：支持按分类号逐级浏览，也支持按产品名称关键词检索，并给出分类判定提示，帮助用户处理跨类产品。第二是添加剂条目命中：支持按添加剂名称、常用别名、CNS 号、INS 号多入口检索，解决“同物异名”问题。第三是限量与备注的完整呈现：不仅显示最大使用量，还要把“以某物质计”“残留量”“按生产需要适量使用”等备注与主条目绑定展示，避免用户只看到数字而忽略规则。第四是依据溯源：每条结果标注标准版本、表号、条目位置，满足监管与企业留痕需求。

应当做但不作为核心的辅助功能包括：按功能类别（防腐剂、着色剂、增稠剂等）聚合的横向比选视图，服务研发选型；以及“允许/不允许”的快速判定提示，服务监管初筛。这些功能提升效率，但判定结论仍需人工复核。

明确不纳入边界的内容：配方设计与优化计算、食品添加剂的检测方法、对标准条款的行政解释与裁决、企业内控标准的制定。把这些排除在外，既能控制应用复杂度，也能避免工具越界给出误导性结论。尤其要强调，任何查询结果都应视为“辅助判定”，最终合规结论需由具备资质的人员结合产品实际工艺复核。

一个可参考的需求核对表

为了让需求分析可落地，可以把上述结论整理成一张按角色划分的核对表，在评审时逐项确认。下表中的“示例判定”为教学假设，用于说明填写方式，并非真实产品结论。

需要提醒的是，需求分析阶段最容易犯的错误是“按界面想象功能”，而不是“按任务反推功能”。建议在评审时让每类用户各带一个真实查询任务现场走查：从输入开始，看能否在合理步骤内得到带出处的结论。若某一步必须靠用户自己“猜分类”或“翻备注”，就说明该环节的功能边界需要补强。把这三类场景的输入、路径、痛点与输出对齐之后，后续的数据结构设计、检索策略和界面组织才有明确依据。