D1。客户给了一台只读库账号，密码写在便利贴上。我们第一版直接连库，dump 出四十三张表：字段名是拼音首字母，kcb_sl、ddh、wlbh，有两张表连注释都没有。WSDL 地址在十年前的合同附件里，早就失效，最后是从 PDA 的抓包里逆出来的方法名。
那天下午我就知道这活儿的难点不在模型。库存有三个概念——在库、可用、锁定，分别在三张表里，差值最大的时候能到三成。
D2 一整天在确认口径。三个数分别在哪张表、什么时候更新、盘点期间会不会变，业务说「可用」、仓库说「在库」、财务说「账面」。三个词指的是三件事，平时却混着用。我们把它们写成一页纸，让客户签字——这页纸后来救过一次事故。
D3。第一版能答「690 还有多少」了。演示很顺，客户当场说下周就上。
D5。客户业务主管来提了个问题：3 号库的 690 到底能发多少？助手答「在库 165」，主管说不对，能发的只有 128，剩下 37 件是被两张订单锁住的。会议室安静了几秒。我们把「可用」加进去，又在回答里注明口径，才把这一页翻过去。
D7，回滚。
D6 做了一次安全评审。IT 主管问了三个问题：账号能不能只读、查询会不会锁表、日志留多久。第一个答得很快，第二个答不上来——联表查询确实会加共享锁。最后改成读从库，延迟两分钟，业务能接受。
上午 9 点 40，仓库在盘点，二十多个人用 PDA 过账。我们的助手每次查询要做一次跨库联表，单次 8.4 秒，把连接池占满了，PDA 开始转圈。十分钟后客户打电话过来，语气不太好。我们把服务停了。那天下午复盘，问题不在模型，在我们把「能查」当成了「可以随便查」。
改的第一处是权限。单独建只读账号，只授到视图层，接口侧再加一层字段白名单——成本价、客户手机号这些字段从视图里就不出现。原来那版是 SELECT *，等于把整个库交出去，只是没人想到而已。
第二处是超时。硬性 3 秒，超过就先回「稍等，我去查」，结果出来补一条消息。看着是体验问题，其实是稳定性问题：老系统的慢是常态，让请求堆在那里，出事是早晚的。
第三处是溯源。每条回答带单号、数据时间、来源表，比如「690 在 3 号库 128 件（可用），10:32 的快照」。没有这一行，答对了没人信，答错了没人查。
第四处是灰度。
D10 出了个小插曲：为了扛住并发，我们给查询加了两分钟缓存，结果盘点期间有人查到的还是旧数。客户没发火，只问了一句「你们怎么保证我知道这是旧数」。缓存本身没错，错在没把时间戳露出来。
另外，客户 IT 提了个要求：所有查询要留审计日志，谁在什么时候查了什么。这在很多项目里是上线后才补的，实际上应该第一天就设计好——出问题时，日志是唯一能说清事实的东西。
D12 重新上线时只开两个场景：查库存、查单据；只给五个库管用；写操作全部生成待办，由人点确认。OWASP 的LLM 应用风险清单把这类问题叫「过度代理」——给模型太大权限，出了事没人说得清是谁的决定。D15 验收。抽 50 条真实问题人工核对，错 2 条，都是同一个原因：同一物料有多个批次，助手只答了总量。补上批次维度，错答归零。查询替代率 41%，意思是原来每天打给仓库的电话少了四成；P95 响应 1.2 秒。
D13 有位库管反馈：助手答得对，但他还是习惯自己查。「它说得太确定了，我反而要再核一遍。」这句话点醒了我们——确定性要用在确定的地方。后来回答里加了一句「数据来自 10:32 的快照，如刚过账请刷新」，追问率降了一半。
D16 上线满一个月。日均查询 63 次，其中 41% 替代了原来的电话；有 12 次答「查不到」，全是新建物料还没同步。我们把「查不到」也当成指标——它说明数据链路有洞，比答错更值得查。
三个数字里，我认为最重要的是错答率。替代率可以靠营销推上去，响应时间可以靠加机器，只有错答率会真的毁掉信任——用户第一次被误导，后面就不再问了，而你不会知道。
回头看，四处改动没有一处跟模型有关。权限、超时、溯源、灰度，都是老系统集成里的老问题，只是换了个名字。模型的能力决定上限，这四件事决定下限，而下限才决定它能不能活过三个月。
如果现在让我重做一遍
回头看这段，最贵的成本不是开发，是那次回滚带来的信任损耗——客户后来每次提新需求，都会先问「会不会又影响盘点」。
D17，客户问能不能再开「查客户欠款」这个场景。我们没答应，先让他们把口径和权限写清楚——欠款涉及账期、折扣和退货，比库存复杂得多。宁可慢一个场景，也不要第二个 D7。
，第一周我不会碰模型，只做一件事：把「可用的库存」这个口径和业务确认下来，写进字段说明。这一步省不得，省下来的时间后面都要还。
