技术穿刺怎么做？以企业知识库问答为例，验证风险、方案和投入

需求评审时，一句"做个 AI 知识库问答"很容易达成共识。真正难的是判断：现有文档能不能用、答案靠不靠谱、权限会不会泄露、投入是否值得。本文用一个常见案例，讲清楚如何通过一次技术穿刺回答这些问题。

什么是技术穿刺？

在本文中，技术穿刺指围绕一个高风险问题，在有限时间内打通最小业务链路，用运行结果支持方案选择和投入决策 。它与敏捷开发中的 Spike 接近：先回答关键问题，再估算后续工作，而不是一开始就建设完整产品。

假设业务方提出："把公司的文档接入 AI，让员工直接提问。"完整产品可能涉及文档管理、权限配置、聊天界面、反馈系统和运营后台。首次穿刺只选一条链路：

text 复制代码

上传文档 → 解析和切分 → 检索相关片段 → 生成回答 → 展示引用来源

这条链路跑通后，还要验证它在错误、缺失和越权场景下如何表现。能演示一次正确回答，不等于技术风险已经排除。

建议把目标压缩成四类问题：

实验开始前写下这些问题，结束时逐项回答，可以避免 Demo 很好看，却没有验证真正影响决策的风险。

选取约 20～50 份有代表性的文档，覆盖 PDF、Word、表格，以及少量扫描件。再请业务人员准备一组真实问题，至少包括四种类型：

最小实现只需要文档导入、检索、问答、引用展示，以及记录请求耗时和调用成本。页面可以简单，但引用必须能定位到原文，方便业务人员核对。

如果系统先检索全库，再在页面上隐藏无权限文档的引用，模型仍可能利用这些内容生成答案。因此，权限约束需要进入检索链路：先确定当前用户可访问的文档范围，再检索、生成回答。穿刺时应使用不同权限账号，对同一问题重复测试。

每次失败都应保存输入问题、检索结果、系统回答和预期结果。例如，"回答错了"不足以指导修复；"正确段落没有进入检索结果"与"检索正确但生成时误读"，对应的是两种不同方案。

穿刺时可以手工导入文档、使用固定测试账号；正式使用则需要补齐持续运行能力。建议在结论中分别说明：

这样，穿刺结论才能从"技术上能跑"推进到"具备继续建设的条件"。

以下是示例评估框架，阈值应在实际项目中由业务要求和预算确定；表中的结果栏需要用实测数据填写。

投入也应分开估算：一次性开发 包括文档接入、检索与问答、权限对接和测试；持续投入包括模型调用、存储、文档更新、效果评估与问题处理。文档质量和权限结构越复杂，后两项工作越不能忽略。

穿刺结束后，给出明确建议：

演示时不要只挑一个"答对了"的问题。可以让业务人员连续看到以下过程：

text 复制代码

问题 A：新员工如何申请测试环境？
预期效果：系统给出步骤，并引用操作手册的对应段落。

问题 B：明年的测试环境政策会如何变化？
预期效果：现有文档没有依据，系统明确表示无法确认。

问题 C：其他部门的内部预算是多少？
预期效果：当前账号没有访问权限，系统不返回预算内容。

上面是演示脚本和预期效果，并非已经完成的测试结果。实际演示应保留页面录屏或截图、引用原文和测试记录，让旁观者能够复核。

一次有价值的技术穿刺，交付物可以只是一个简单页面、一份测试记录和一张决策表。关键是通过"文档---检索---回答---引用---权限"这一条最小链路，尽早回答：能否做、风险在哪里、需要哪些支持、是否值得继续投入。

对于企业知识库问答，先获得这些证据，再决定是否建设完整产品，比直接按一张聊天页面估算项目更可靠。