知识整理更新：2026-07-07
一句话
“提示词里写禁止编造”不能作为工程防线。我的做法是先由脚本生成白名单事实包，LLM 只能引用事实编号写作；草稿完成后再抽取数字、日期、指标名和来源编号逐项回查，包外或口径不明的内容不进入发布。
四道闸门
- 数据准入：原始数据先由脚本解析和清洗，例如成交 CSV、回测报告、账户记录和研究表格，不让 LLM 直接面对混乱来源后自由总结。
- 白名单事实包：每个数字、日期、指标、样本区间和口径都绑定事实编号、来源层级与采集时间，LLM 只能在包内表达。
- 后校验脚本：从草稿中抽取数字、日期、百分比、指标名和引用编号，逐一回查事实包；包外数字、错配指标和缺失来源直接退回。
- 来源分级与口径纪律：官方源可单源确认，商业源需要独立组互证；同名指标不等于同口径，合并前必须保留双方原始口径。
后校验里的坑
后校验不能只做简单正则。年份、月份、小整数、引用编号、章节序号和结构数字都会误伤或漏放，比如 [F1] 里的 1 不应被当成正文数字，“三段”“6月”也不一定是业务事实。但放行规则越宽，越容易留下盲区，所以百分位、排名、收益、回撤、交易次数这类实质数字，最好要求它们全部来自事实包。
低可信源怎么接
低可信源可以进入线索池，但默认不进入事实包，也不驱动结论。标题数量再多，也不能靠重复转载冒充交叉验证。只有当它与已信任来源属于同一发布主体，或被人工点名提权后，才允许进入后续整理和引用流程。
我怎么用
凡是“抓数据 → LLM 写东西 → 发布”的项目，我都把 LLM 放在最后一层表达位。在交易研究、图书代码复现和站点内容里，回测指标、成交绩效、事实包和发布校验由 Python / JavaScript / SQLite / tsc / lint / build 或自定义脚本负责。
LLM 只负责研究初稿、结构化摘要和表达改写。数据站的信任不是写出来的，是每道闸门拦出来的。