AI 员工接入知识库后，真正影响可信度的并不只是“能否回答”，而是用户能否确认答案来自哪份文档、哪段内容。NocoBase 的近期更新把知识库文档引用带入 AI 员工场景，同时继续维护 main、next 和 develop 三个分支。对准备上线的团队来说，这两件事需要放在一起考虑：引用能力决定答案是否可审计，分支选择则决定系统是否足够稳定。
文档引用解决的不是展示问题，而是信任问题
没有引用的知识库回答，即使语言流畅，也很难进入严肃业务流程。例如，员工询问报销标准时，AI 可能给出一个金额，但使用者还需要知道：
- 答案来自哪份制度文档；
- 引用的是当前版本还是过期版本；
- 原文是否真的支持这条结论；
- 不同文档发生冲突时，AI 采用了哪一份；
- 审计或复盘时，能否重新定位到依据。
因此，引用不应只是答案末尾的一串文档名称。一个可用的引用至少应包含文档标识、标题、定位信息和原文摘录。团队还可以增加文档版本、更新时间、知识库空间和访问权限等字段。
可以把 AI 员工的输出约定为下面这种结构。这里是建议的业务侧数据契约，不代表 NocoBase 固定的原生 API 格式：
{
"answer": "差旅住宿费用需要在返回后 10 个工作日内提交报销。",
"citations": [
{
"document_id": "policy-travel-2025",
"title": "2025 年差旅管理制度",
"locator": "第 4 章 / 第 12 条",
"quote": "员工应在差旅结束后 10 个工作日内提交报销申请。",
"version": "2025-01"
}
]
}
这种结构允许前端显示“查看依据”，也方便后端记录引用命中率、无引用回答比例和过期文档使用情况。
main、next、develop 应该承担不同职责
当前更新分为三个分支。摘要明确给出的定位是：
main：截至目前最稳定的版本，推荐安装；next：包含即将发布的新功能，经过初步测试，但仍可能存在已知或未知问题，适合提前体验和反馈；develop：摘要没有给出同等明确的稳定性承诺，因此不应自行把它视为生产版本。更稳妥的做法是仅在内部研发或验证环境使用，并以项目发布说明为准。
对于希望尽快验证知识库引用的团队，可以建立三段式发布路径：
| 环境 | 建议分支 | 主要任务 |
|---|---|---|
| 生产环境 | main |
承载正式用户和业务数据 |
| 预发布环境 | next |
验证即将发布的能力、收集引用质量反馈 |
| 研发沙箱 | develop |
工程实验、兼容性检查和故障复现 |
不要因为无代码平台部署方便，就让 next 直接覆盖生产实例。AI 场景中的回归问题不一定表现为页面报错，也可能是引用丢失、定位错误、权限越界或答案仍然可读但依据不正确。
如果团队通过源码分支管理部署，可以在现有项目检出目录中加入一个简单的保护脚本。下面的脚本会阻止生产环境选择非 main 分支：
#!/usr/bin/env bash
set -euo pipefail
TRACK="${NOCOBASE_TRACK:-main}"
ENVIRONMENT="${DEPLOY_ENV:-staging}"
case "$TRACK" in
main|next|develop) ;;
*)
echo "Unsupported branch: $TRACK" >&2
exit 1
;;
esac
if [[ "$ENVIRONMENT" == "production" && "$TRACK" != "main" ]]; then
echo "Production deployments must use the main branch." >&2
exit 1
fi
git fetch origin "$TRACK"
git checkout "$TRACK"
git pull --ff-only origin "$TRACK"
printf 'Checked out branch=%s for environment=%s\n' "$TRACK" "$ENVIRONMENT"
将其保存为 select-track.sh，然后在已经配置好远端仓库的项目目录中运行：
chmod +x select-track.sh
NOCOBASE_TRACK=next DEPLOY_ENV=staging ./select-track.sh
# 生产环境只能使用 main
NOCOBASE_TRACK=main DEPLOY_ENV=production ./select-track.sh
这段脚本只负责分支保护，不替代 NocoBase 官方安装、升级和数据库迁移流程。正式升级前仍应备份数据库与附件，并阅读对应版本的发布说明。
用自动化检查拦住“有答案、无依据”
知识库引用上线后，最容易出现的误判是：界面显示了引用按钮，就认为能力已经可用。更可靠的方式是准备一组固定问题，把 AI 输出保存为 JSON，再通过脚本执行最低限度的结构检查。
下面的 Python 程序可以直接运行，不依赖第三方库。它检查每条回答是否包含引用，以及引用是否具备文档 ID、标题、位置和原文摘录：
#!/usr/bin/env python3
from typing import Any
CASES: list[dict[str, Any]] = [
{
"question": "差旅结束后多久需要提交报销？",
"answer": "应在 10 个工作日内提交。",
"citations": [
{
"document_id": "policy-travel-2025",
"title": "2025 年差旅管理制度",
"locator": "第 4 章 / 第 12 条",
"quote": "员工应在差旅结束后 10 个工作日内提交报销申请。",
}
],
},
{
"question": "试用期可以申请远程办公吗？",
"answer": "现有知识库中没有足够依据确认。",
"citations": [],
"abstained": True,
},
]
REQUIRED_FIELDS = {"document_id", "title", "locator", "quote"}
def validate(case: dict[str, Any]) -> list[str]:
errors: list[str] = []
citations = case.get("citations", [])
if not citations and not case.get("abstained", False):
errors.append("回答没有引用，也没有明确拒答")
for index, citation in enumerate(citations, start=1):
missing = REQUIRED_FIELDS - citation.keys()
if missing:
errors.append(f"引用 {index} 缺少字段: {sorted(missing)}")
if not str(citation.get("quote", "")).strip():
errors.append(f"引用 {index} 的原文摘录为空")
return errors
failed = False
for number, case in enumerate(CASES, start=1):
errors = validate(case)
status = "PASS" if not errors else "FAIL"
print(f"[{status}] Case {number}: {case['question']}")
for error in errors:
print(f" - {error}")
failed = failed or bool(errors)
raise SystemExit(1 if failed else 0)
保存为 check_citations.py 后执行：
python3 check_citations.py
结构检查只是第一道门槛。进入预发布环境后，还应由业务人员核对引用原文是否真正支持答案，而不是只验证字段非空。建议至少覆盖以下测试类型：
- 能在单份文档中直接找到答案的问题；
- 需要综合多份文档的问题；
- 新旧制度内容冲突的问题；
- 知识库没有答案、应当拒答的问题；
- 当前用户无权访问相关文档的问题；
- 文档改名、移动或更新后，引用是否仍能定位的问题。
上线时重点看权限、版本和回退
文档引用会暴露更多上下文，因此权限检查比普通问答更重要。AI 不仅不能复述用户无权查看的内容，也不应通过标题、摘要、引用片段或链接泄露受限文档的存在。
一次稳妥的上线可以按下面的清单执行：
- 生产环境优先使用
main； - 在隔离的
next环境验证新能力，不复用生产写权限； - 升级前备份数据库、附件和关键配置；
- 为高频业务问题建立固定回归集；
- 同时检查答案、引用原文、文档版本和用户权限；
- 没有可靠依据时，让 AI 明确拒答，而不是补全一个看似合理的结论；
- 预先记录回退版本、回退步骤和负责人；
- 将错误引用视为答案错误，而不是轻微的界面瑕疵。
NocoBase 的无代码能力可以降低知识库与业务流程的搭建成本，但 AI 员工能否进入生产，最终仍取决于工程治理。选择稳定分支、保留可核验引用、建立自动化回归和权限边界，才能让“会回答”真正升级为“回答有据可查”。