试运营示例：参与成员与历史互动为演示数据，欢迎留下你的真实想法。
我的笔记分散在 Markdown、网页摘录和项目说明里。这个小工具的目标很简单：输入一个自己以前遇到过的问题，找到相关段落，回答时保留文件名和所在位置。
第一版最容易让人误判的是流畅的回答。它有时说得很像正确答案，但引用段落并不支持结论。于是我把“找不到依据时明确说不知道”作为最先测试的行为。
现在界面左边是回答，右边可以直接打开原文。模型只是帮忙缩小查找范围，最后确认还是由自己完成。下面整理了一些失败样本，也想听听大家会怎样评价这种工具有没有真正节省时间。
只把自己有权使用的文档放入索引。
回答必须能回到原始段落。
记录检索不到、引用错误和过期文档三类失败。
保留普通关键词搜索，方便对照结果。
先用少量自己有权使用的材料验证路径很合适。界面里保留来源和删除入口，后面再扩大数据范围也比较容易管理。
结构校验通过之后，还需要检查业务含义是否正确。我会让无依据的字段保持空值，而不是为了填满结构悄悄补一个猜测。
普通关键词搜索可以先保留，作为对照也作为退路。有些精确的报错和技术名词，直接搜索反而更容易找到原文。
注意重试上限和取消行为。用户点击停止之后，界面、后台请求和后续写入是否都符合预期，最好有一个明确约定。
我会先在自己的小环境里验证一轮，把步骤、结果和没解决的地方都记下来。后续有新发现，再回来补充。
这类工具的成功标准可以更具体一点：找到正确材料用了多久，最后有没有回到原文确认，比单纯比较回答长短更有帮助。
赞同把不适用的情况一起写出来。技术笔记里记录模型会在哪些问题上失败，往往比再展示几个顺畅回答更值得收藏。
建议先保留一小组固定问题，包含答得出来和应该承认不知道的情况。每次改动都跑同一组，比较才不会被一次漂亮结果影响。
引用存在还不够，最好能直接打开原始段落，检查它是否支持回答里的关键结论。这个步骤也能帮助区分检索问题和生成问题。
