项目记录：给一份活动规则做自动问答，最后保留了人工入口
目标
一份活动规则长、条件多，参与者反复问同样的几个问题。想做个自动问答，把高频问题接住，减少重复解释。
第一版：直接把整份规则丢进去
做法最省事：整篇规则作为上下文，用户提问就直接答。测试二十条问题，十四条答得不错，剩下六条出问题——不是答错，是答得太肯定。规则里没写的情况，它也会顺着语气补一个答案。
这类“顺手补全”最难被发现，因为句子很通顺。于是推翻重做。
第二版：加编号、加边界、加人工入口
三个改动：
- 规则切成带编号的条目，回答必须引用条目号；引用不上就明确说“规则里没有写”。
- 把问题分两类：涉及时间与条件的，走条目检索；其余走常规说明。分流用固定规则判断，不交给模型。
- 保留人工入口：凡输出“规则里没有写”、或引用超过两条，界面上直接给一个提问按钮。
第 3 点是这次最重要的决定。原本目标写的是“减少人工”，做完发现保留人工反而让整体更可信——用户知道有地方可问，就不会反复试探机器。
条目化的写法参考了 HTML 入门教程站把内容拆成小单元、并保留结构信息的做法；而“每条答案带来源编号”的思路，跟 BackendWiki 里接口条目按编号引用 是同一个道理。
结果
二十条测试题里，十六条给出带编号的答案，四条正确转人工。没有出现编造答案的情况——因为结构上不允许“不带编号也输出”。
复盘
没写出答案，比写出一个像样的错答案更有价值。 这次真正起作用的不是模型，是三条结构约束：编号、边界、人工入口。做应用时总想尽可能自动化，但有些位置留给人，反而才是功能完整。