-
先砍场景，不要一上来接全库。一个仓库几千张表，全向一句话提问敞开，等于把歧义的数量放大到不可控。挑一个部门的二十个高频问题起手，拿区域销售日报的同比口径练，拿库存周转的周环比练。这二十个问题跑顺了，再放开第二个部门。试点最常犯的错不是技术选错，是目标泛化，谁都说不清这次到底要替谁省多少事。 -
指标定义只留一处。口径散落在三份 PPT 和两个人的脑子里，等于没有口径。它得有一个所有人知道在哪、改了会通知到谁的地方。这件事麻烦，麻烦的地方不在写，在要求财务和运营坐下来吵完那一个下午。 -
给模型一条明确的拒答线。跑到定义之外的问题，让它说不知道，并提示用户补充时间范围和口径。这条线是产品功能的一部分，不是兜底逻辑。一个从不说不知道的系统，等于把猜测包装成答案，用户在前三次信任被消耗完之后就不再来了。 -
溯源是默认配置。每条回答底下挂着它用了哪个指标、取了哪段时间、走的哪条计算路径，最好能把生成的代码直接摊开给用户看。这不是给技术人员的高级选项，这是让业务敢用这个东西的前提。人不会信一个不告诉他怎么算出来的数字，这一点从来没变过。 -
反馈要落到定义，不要落到提示词。用户点了反对，说这数不对，正确的处理不是给这句提问补一段说明，是回去改那条指标的定义，让所有问到这个指标的场景一起受益。把修正写进提示词，等于把口径又藏回一个人的聊天记录里。