记录说明：沿用本课同一客户的匿名演练材料。第一部分为8月12日需求访谈，第二部分为后续电话确认。对话由课程案例扩写，用于需求提取与方案制作，不是客户真实录音逐字稿。
一、客户到底想解决什么
先不急着看产品。我想请您说说，为什么最近开始考虑一个问答助手？最好讲一件具体的事：谁要找什么，平时怎么找，找不到以后又怎么办？我们先把使用场景说清楚，再讨论需要哪些功能。
我们大概三千名员工，三个办公点。资料并不少，有制度、产品手册、故障处理说明，还有过去积累的常见问题。麻烦是人不知道该去哪儿找。新人碰到一个问题，先搜共享盘，再问群里谁知道。最后还是找到了几个老同事，工作又回到他们身上。
也就是说，您要的不是再建一个存文件的地方，而是让员工能把问题直接问出来，从现有资料里找到能用的答案。那我们应该先选哪类员工、哪类问题？如果一下子面对所有岗位，不同人的资料和权限可能差很多。
对，别上来就做全公司。先拿售后支持团队试，大概一百二十人。他们的工作比较集中，经常问产品怎么配置、遇到异常先查什么、一个常见问题按什么顺序处理。先把这个团队服务好，再看有没有必要扩到其他部门。
这次做的交付可以先说成“售后支持业务问答助手”：员工用日常语言提问，助手给出有资料依据的回答，并能继续追问。它主要帮人查资料和理解处理方法，暂时不替人操作客户的业务系统。这样描述接近您的想法吗？
接近。我们不想把项目说得特别大，也不想先讨论一堆智能体的名字。就看员工碰到问题时，能不能少翻几个地方、少去群里问一遍。不要拿一个什么都能聊的聊天窗口来交差，我希望它懂我们允许它使用的那些业务资料。
二、一次找资料的过程
请您按平常的过程再说细一点。比如售后同事接到一个配置咨询，他最先看到的是什么信息？他是直接把问题发到群里，还是先自己找？我们需要知道助手应该在哪个环节出现，不能只凭一个“智能问答”的名字来设计。
通常先有客户的问题，可能是电话里说的，也可能是同事转过来的一段描述。售后人员先看自己手里的产品手册，找不到就搜旧知识库。搜索词不一样，有时候结果也不一样。实在没把握就到群里问，老同事还要反过来问他用的是哪个版本、发生在什么条件下。
那么“找不到”可能有几种情况：资料确实没有，关键词不对，资料已经过期，或者提问时漏了必要条件。如果助手一看到一句话就给一个很确定的答案，可能只是把问题藏起来。它有必要先问产品版本或适用场景，再回答，对吗？
是。但别一下子给员工发一张十几项的表。他只想把手头事情往下做。关键条件不清楚时，先追问最影响判断的那一两项。如果资料里已经能看出来，就不要重复问。我们希望减少沟通次数，不是把原来的沟通换成填表。
回答之后，员工还要做什么？我们是让他看完建议自己处理，还是还需要找一个人确认？这会影响我们怎样写回答中的依据、适用范围和下一步，也影响以后拿什么标准判断助手有没有帮上忙。
现在先让员工自己判断怎么使用。比如给他一段操作说明，告诉他依据是哪份文件、适用哪个版本。涉及不常见的故障、客户特定环境或者有风险的操作，还是要找专业人员确认。不能因为答案是AI给的，就让新人觉得什么情况都照着做。
三、从“搜文件”到“问问题”
您现在已经有知识库和共享盘，为什么不只把搜索做得好一点？这个问题我会放到方案里解释。如果我们说不清问答入口比搜索多解决了哪一步，内部评审的人很可能认为这只是换了一个页面。
搜索经常给我一堆文件名，接下来还是要自己打开、找段落、比较哪个版本对。我们想要的是先看到与当前问题相关的说明，再决定要不要看原文。如果回答能把几个相关点整理在一起，又能让我回到原文核实，那才比单纯搜文件有帮助。
我理解回答需要两层：前面是针对当前问题的直接说明，后面是依据和适用条件。员工可以继续问“第二步在哪里操作”或者“这个版本也适用吗”。如果追加的问题改变了原来的条件，就重新查依据，不能机械沿用前一个答案。
是这个意思。有时候问的人自己也说不完整。助手可以帮助他把问题说清楚，但不能帮他编一个没有说过的环境。尤其不要看到前面提过某个产品，就认定后面的所有问题都关于这个产品。该确认的时候还是要确认。
那页面是不是不需要把所有模型参数、复杂设置都露出来？员工进来先知道这里能问什么、能查什么资料、哪些问题需要转给人。回答后能打开原文、指出有问题的地方，管理员再从后台看资料与反馈的处理情况。
对，员工界面越直接越好。业务同事不关心背后用了几个模型，首先关心自己的问题有没有被听懂。也不要在页面上写得像已经覆盖全部公司知识。当前只覆盖哪些资料，就让使用者知道，免得问不到的时候觉得系统坏了。
四、首批资料从哪里来
如果先做售后团队，哪些资料可以作为首批内容？这里说的资料是未来问答助手回答时要查询的业务文档，不是这次制作方案PPT的输入文件。我们先把这两个层次分开，以免后面把范围说混。
常用资料先从两百到三百份里面挑，包括产品手册、已发布的操作说明和常见问题。这个数字目前是一个范围，我们还要和资料管理同事确认。不是把所有共享盘文件直接倒进去，有些旧文件和临时文件我们自己也不建议继续用。
这两百到三百份，是您希望从现有资料里筛选的候选范围。具体放哪些，要先确认有效版本、允许谁使用、是否有维护人。这些文档由贵司提供并确认有效范围，我们先核清单，不会为了凑数量把缺失内容补写成业务资料。
对，数量不是目的。我们宁可先把常用资料挑对，也不想为了凑数量放一堆没人维护的东西。资料管理同事会梳理清单，但他还需要售后负责人帮忙判断哪份真的常用。IT能告诉我们文件在哪儿，未必能判断业务内容是否已经过时。
这些资料现在主要放在哪些地方？有没有统一编号和发布日期？我想把来源、版本和负责人的要求写进准备清单。后续员工看到一个答案，至少能知道它引用的是哪份资料，遇到问题应该找谁处理。
一个旧知识库、一部分共享盘，还有一些PDF。命名不完全一样，同一份手册可能有人另存了一份。至于旧知识库有没有现成接口，我现在不能确认，要找IT。我们可以先查能不能导出，但不能现在就答应你们可以直接接上。
五、这些文档是不是用来训练模型
刚才提到把业务资料给助手使用，我想再确认一个容易误解的词。有的人把这件事叫“喂给AI学习”。您这次是希望它能检索并引用指定资料来回答，还是已经有明确的模型训练需求？这两件事的准备和投入不一样。
我们没有提出要自己训练一个模型。我们不熟悉技术细节，只是希望它知道这些文件里的内容。比如员工问一个流程，能从我们允许使用的资料里找到对应做法，而不是用互联网上的一段通用说明来回答我们公司的问题。
那当前方案按知识库问答来写：先把获准文档整理成可查询的知识内容，收到问题时检索相关段落，再生成带来源的回答。本轮不把定制训练模型作为必做工作。资料更新后，也要能换成有效版本，不是一次放进去以后就不管了。
可以。你们汇报时用这个说法就清楚了。尤其要说明文件是什么用途，不要只在一页里放个“两百份”，大家还以为是你们给我们准备的训练样本。我们关心的是它回答时能用什么资料、用了哪一版、有没有看错内容。
我们会把三种材料分开写：一类是客户访谈和我司产品设计资料，供我们制作这次方案；一类是未来知识库里的业务文档，供助手查询；还有一类是用来验证效果的真实问题。它们用途不同，不能混成同一个“训练材料包”。
这样讲我就听得懂。第一类让我看你们是不是理解需求，第二类决定助手能查什么，第三类检查它到底回答得怎样。你们可以在方案里用一个简单流程把它画出来，但不要为了讲技术把我们最初的业务问题淹没了。
六、回答为什么必须带来源
您反复提到来源。我想知道，回答里附一个文件名够不够，还是要能看到相关章节甚至原文？这会影响员工怎样核对，也会影响我们准备资料时需要保留哪些信息。
只写文件名还不够。同一份手册可能很长，我不想每次再从头搜。最好能看到相关段落或者明确位置，能打开原文就更好。员工要确认的不是“AI找过文件”，而是“这个结论确实来自这个位置，放到我这个问题里也适用”。
如果资料里有原文，但原文没写当前问题的全部条件，我们应该怎样回答？比如手册写了一种环境的做法，用户没有说明自己是不是这个环境。是先给通用步骤，还是把适用条件说出来，请他确认后再继续？
要把条件说出来。可以先解释资料能支持到哪里，然后问缺的条件。不要把局部依据扩成一个什么场景都适用的答案。我们现有的专业同事也会这样判断，助手至少应该把不确定的地方摆在明面上。
那我们验收时会把“回答看起来很流畅”和“回答有依据”分开检查。回答可以很顺，但引用错文件、引用过期段落，仍然不合格。来源不是装饰，必要时业务同事要能沿着它把问题查回去。
同意。还有一种情况是答案本身没错，但引用只是相关，并不支持那个结论。这也要记成问题。我们不希望员工为了核对AI的回答，反而要花更多时间找它引用错在哪里。引用方式要让人省事，不是增加一层工作。
七、找不到、答不全和说不准的时候
如果资料没有覆盖一个问题，您希望助手怎么处理？我们可以做得很明确：没有找到可用依据就说明未找到，提示可以补充什么信息，或者转给指定岗位。不能用一段听起来像正确答案的话填上空白。
是。它可以说当前知识库没有找到这个问题的依据，但别说我们公司一定没有这个规定。可能只是这批资料还没收进去。对使用者来说，知道目前查不到，以及接下来找谁，已经比得到一个编出来的回答要好。
如果用户的问题缺了版本、对象或场景，助手先追问；如果关键资料没有，就说明缺口；如果涉及专业判断，就转人。这些情况在界面上最好说清楚，不要全部归成一个“系统无法回答”的错误提示。
可以，不过转人也要实际有接收方式。不能放一个“联系管理员”，最后谁都不管。我们可以先由团队确定问题接收人，试点阶段先跑清楚，再决定是不是需要工单系统。现在不要把自动派单已经实现写到方案里。
我们会把“记录未解决问题”和“自动建立业务工单”分开。第一阶段可以先保存问题、原因和建议处理人，让业务负责人接收；要接工单系统，需要另行确认接口、权限和处理流程。先不在本轮里承诺完整持续跟进。
对。先做到出现问题的时候有人能看到、知道怎么处理。以后如果使用量上来，确实需要自动分派，再谈接口和规则。很多项目一开始什么都想做，最后最基本的问答反而没有做好，我们不想走那条路。
八、权限和不该进入的资料
您刚才说有项目资料只有项目组能看。我们需要区分两件事：哪些资料可以进入首期知识库，以及已经进入的资料谁能访问。不能因为都在企业内部，就默认每个人可以查看所有内容。
没错。项目资料里可能有客户信息和特定项目的约定，不适合给所有售后同事看。通用产品资料和已发布制度相对简单，但也要由资料管理人确认。项目资料要不要做，我们宁可等后面再讨论，别为了演示方便把权限跳过去。
对员工来说，他问一句话时不一定知道涉及哪份文件。所以权限应该在检索资料时就起作用，只从他被允许查看的范围里找内容。不能先搜到不该看的资料，生成答案后再只把文件名隐藏掉。
这个顺序是对的。也不要在回答里暗示“有一份你没权限看的文件写了什么”。我们希望使用者看到的是他可以使用的内容。具体身份怎么识别、权限怎么从现有系统带过来，要由IT和信息安全同事一起评估。
我们会把权限控制写成必须验证的要求，而不是已经接通的能力。方案图上可以画身份检查、资料筛选和回答路径，同时标出需要客户提供的规则。如果当前拿不到规则，试点范围就要收紧，不能靠一句“内部测试”绕过去。
可以。这个项目一旦让员工开始用，大家就会按真实工作对待它。我们不想先让人形成一个“什么都能问”的印象，再回头补限制。你们方案里也别把尚未决定的权限方式画得像已经落地，要能看出哪里还等我们确认。
九、文档版本与更新
我们再看文档更新。假如一份手册今天换版，助手明天还引用旧版，问题会很难发现。首期是不是可以先约定一个资料负责人，告诉我们哪些文件有效、什么时候需要替换，而不是完全依赖技术自动判断？
需要。我们的问题不只是文件分散，还有版本管理不一致。有时群里转的是个人保存的旧版。资料管理人可以先维护一个清单，标明当前有效版本和负责部门。至于后面更新能不能自动同步，要看来源系统支持什么。
如果两份文件互相冲突，比如一个说可以这样处理，另一个写了不同条件，我们不应该让助手自己挑一个比较顺口的答案。先把冲突列出来，让业务人员确认有效依据，更新资料后再重新验证相关问题。
对，最好还能追到这次回答用的版本。出了问题以后，我们要区分是资料本来就写错了、版本没更新，还是助手理解错了。如果所有答案都只标一句“来自知识库”，后面根本没办法复盘。
那么资料准备清单会包括名称、来源位置、版本或日期、适用范围、可访问对象和维护人。这个清单不是为了增加流程，而是保证以后答案出问题时能找得到依据和负责人。字段过多的部分我们可以再一起简化。
这些字段都有用，但先别要求业务同事重复填系统里已经有的信息。能从有效清单或文件属性里带出来就直接用。真正需要人工判断的是资料是否还能用、给谁看、谁负责确认，这几项不能靠系统猜。
十、旧系统能不能接，不能靠现场猜
我们想把接口这件事单独记下来。现在能确定的是资料散在旧知识库、共享盘和PDF里；还不能确定旧知识库能否直接连接。下次是否可以请IT说明接口、导出格式和访问限制？没有这些信息，方案只能写条件，不能写已经完成集成。
可以约IT，但我今天不能替他承诺。旧系统使用时间比较长，有的能力可能要找供应商核实。你们先列需要了解什么，不要一上来要求我们开放全部系统。我们内部也要判断本轮试点究竟需不需要做那么深的连接。
如果暂时没有接口，我们可以讨论先使用获准导出的文件做小范围验证。这样先检查问答是否解决业务问题，同时把以后正式接入所需条件列出来。导出文件的方式是否可用，仍要由你们确认，而不是我们默认可以拿走所有文档。
这个思路可以讨论。先把一部分允许使用的资料整理清楚，比为了追求全自动接入拖很久更实际。但导出到什么地方、谁能访问、试完以后怎么处理，这些也要写在准备清单里，信息安全同事会看。
也就是说，技术路径可以有先后，但权限和资料范围不能省。我们会区分“先用文件验证”“后续评估系统连接”，方案中不把两条路径混在一起。如果连一个文件试点也需要额外审批，就把这个时间和负责人提前列出来。
是。你们把待确认事项写得具体一点：是谁要给什么信息、影响哪一步、没拿到会怎样。不要只是写“需要客户配合”。那种写法看起来都对，实际推进的时候没有人知道今天到底该做什么。
十一、部署方式还没有决定
部署方面，现场有没有已经确定的要求？例如一定要放在哪个环境，还是信息安全团队还在评估？我们需要把已确认条件和待评估条件分开，避免客户需求经过几次转述以后变成一个明确的交付承诺。
还没定。我们当然会关心资料安全和访问控制，但不能因为有人说“数据不能乱跑”，你们就直接写成已经确认私有化部署。信息安全同事要看资料类型、处理过程、人员权限和拟用环境，再给意见。
明白。方案可以说明需要评估哪些条件，也可以画出业务上希望怎样使用，但具体部署方案、资源和成本要等评估。我们不会把“建议方式”写成“客户已经选定”，也不会把未确认的部署周期塞进六周目标里。
对。还有日志里面会不会保存员工提问、里面会不会带客户信息，也要问清楚。这个问题不是今天您我聊天就能定的。我们需要相关人员一起看，你们先提出问题和设计考虑，不要替我们把所有选择做掉。
我们会在方案里列一张落地条件表，把部署、身份权限、接口和资料维护分别写清楚。每项注明当前状态、需要谁确认、影响什么。如果本轮只讨论方向，就不要给这张表填一个看上去完整但没有依据的答案。
这样更好。内部领导不怕看到几个待确认问题，怕的是前面都说没问题，真正投入以后才发现一堆条件没有准备。你们把路径和分工讲清楚，比把所有格子都写成“支持”更有价值。
十二、六周希望看到什么
您前面提到六周左右能看到内部试点。这个时间具体是希望到什么状态：看到一个可讨论的演示、让售后团队做小范围试用，还是全公司正式上线？我想确认这句话的边界，后面排计划不能把它越写越大。
我们说的是希望六周左右看到试点效果，不是全公司上线。大概能用我们挑的资料、拿实际问题试一试，知道这条路值不值得继续。至于能不能按这个目标推进，还要看资料、环境和双方人员准备得怎样。
那我在汇报中会写“客户希望六周左右看到内部试点效果”，再把准备条件和需要确认的计划列出来。不会写成“供应方承诺六周全量上线”。具体里程碑需要双方确认以后才成为项目安排。
对。下周我们内部先看方向，你们不用现在就做正式报价，也不用为了显得有把握，把日期填得特别死。我们希望看到目标、范围、为什么这样做、怎么试以及谁需要参与，然后再决定下一步投入。
我们可以给出推进建议，比如先确认业务范围和资料，再准备环境，随后用真实问题验证，最后评审是否扩大。但这是一份待讨论的安排，不是已经立项的排期。各阶段能不能开始，要看前面的条件有没有真正到位。
可以。计划还要留出业务人员检查结果的时间，不是你们把页面做完就算结束。我们售后同事平时也有工作，什么时候提供问题、什么时候试、谁来判断回答够不够用，要提前约好，不然最后只剩技术人员自己看效果。
十三、不要先写一个漂亮的准确率
效果方面，您有没有已经确定的指标？有些介绍材料习惯直接写百分之九十几的准确率，但如果不知道问题范围和判定方法，这个数字很难说明什么。我们希望先明确要测哪些问题、由谁判断，再讨论是否达标。
先别写那种数字。我们会准备二十个真实问题，来自售后平时要处理的事。先看看它怎么回答、引用对不对、需要补什么资料。有些问题本来就没有现成答案，不能因为助手老实说没有依据，就简单算成它做错了。
我们会把测试问题和知识库文档分开。约两百份业务文档是供助手查询的内容；二十个真实问题是用来检验它的表现。测试问题不是让它提前背好的答案清单，也不应该全部复制文档标题，让结果看起来很漂亮。
是。可以有常见问题，也要有问得不完整的、条件不匹配的、资料里根本没有的。权限问题也要看。我们关心的是实际使用时会发生什么，不是做一个只会回答演示者提前准备好的问题的页面。
对于每道题，双方可以先写出怎样才算可接受：答案要包含什么、不能越过什么条件、引用是否支持结论、找不到时应该怎样说明。试完以后再逐题记录实际结果、问题原因和改法，不先承诺一个总体通过率。
这个方法可以。还要看看员工能不能顺着回答继续做事。如果一段话很长、术语很多，虽然摘自文件，却还是让人看不懂，我们也会提意见。我们希望它解释得清楚，但不能为了简单把必要条件删掉。
十四、试点结果怎么判断有用
除了逐题检查回答，我们还想观察员工使用过程。比如他有没有反复换词搜索，是否仍然必须去群里问，能否自己找到原文核实。不过这些都要在试用中记录，不能现在就把节省时间当成已发生的结果。
同意。现在没有一份能直接拿来当基线的完整统计，你们不要替我们编。先找几类经常遇到的问题，记录以前怎么处理、用了哪些材料，再看助手帮助以后怎样变化。如果还是要来回问很多次，也要如实记下来。
发现错误以后，需要区分问题出在资料还是产品：资料缺失、旧版未下架、问题理解不清、检索没找对，还是回答把依据扩大了。不同原因对应不同改法，不能全部说“再优化一下模型”，也不能把责任全推给业务资料。
对。业务同事能负责资料是否正确，技术同事能检查为什么没有找到；有争议就一起看。我们希望每次修正能落到具体问题，改完再测原来的题，同时换一道类似问题看看，别只把那二十道题修成特例。
那试点复盘可以按“问题、实际回答、来源、原因、修改人、复测结果”记录。这里提出的是验证办法，哪些字段真有必要可以在试用时调整。我们会优先让业务人员看得懂，方便他们给出有效意见。
可以。最后我们判断值不值得继续，也会看维护是否跟得上。如果一份资料更新一次，后面需要很多人手工补很多地方，那日常负担可能转移到了管理员身上。这个成本要看，不是只看员工提问时多快得到一句话。
十五、演示页面和正式产品不是一回事
下周内部讨论，如果只有一份文字方案，大家可能对使用过程理解不一样。您是否愿意同时看一个能点的网页Demo？它可以展示提问、追问、回答、引用原文和反馈，让大家对产品要长什么样有共同认识。
可以，这种东西比较好讨论。但页面上必须明确是模拟数据。不要让领导点一下就以为已经接了我们的旧系统，也不要用一段演示回答来证明资料检索已经过关。它可以帮助我们决定怎么做，不能替代试点验证。
我们会把展示范围说清楚：Demo说明交互与业务路径，真实文档处理、身份权限、接口和回答质量仍需在试点环境验证。如果有现成演示，先判断是否适合当前问题；需要新能力的部分由方案和产品人员评估。
对，不必每一个想法都马上做成复杂系统。能把关键使用过程说明白就有帮助。比如我会关心员工点来源后看到什么、回答不确定时页面怎么说、提了一个没有资料的问题以后到哪里去。这些比首页放几个漂亮统计数字更重要。
那么这次汇报会把方案PPT和可选Demo分开：PPT讲客户问题、方案思路、条件、验证与下一步；Demo帮助理解交互。客户经理可以组织材料和制作汇报，专业内容由方案专家核对，产品经理按需要准备或确认演示。
这样分工可以。你们内部谁做PPT我不介意，重点是最后给我的内容不能几个人说法不一样。方案里写的能力、演示里表现出来的功能和下一步要投入的工作，应该对应起来，做不到的地方要讲清楚。
十六、这份汇报要让谁看懂
下周看方案的人主要是谁？同样一个问答助手，业务负责人会看能不能解决问题，IT会看怎么接，管理者会看投入和推进。我们需要控制内容层次，让他们在一份材料里找到自己需要判断的东西。
主要是数字化负责人、售后支持负责人和IT代表。我们希望先达成一个共同方向，再把信息安全等相关人员拉进后面的确认。不要给大家讲一堆算法，也不要只展示几个对话截图，看到最后仍不知道我们为什么要做、先做什么。
我计划用一条简单的叙述：先讲售后团队当前找资料和问人的问题，再讲问答助手怎样帮助；然后说明首期人群、知识范围、使用流程和落地条件；最后用真实问题验证，给出人员分工和待确认的下一步。这样能支撑内部讨论吗？
能。也请明确这一期不做什么，特别是不要把三千人都写成首期用户，不要把项目资料默默放进去。范围小不代表价值小，如果能把售后团队的日常问题解决好，我们就有依据讨论后面的扩展。
我们会根据你们给的业务事实组织方案，产品实现方式则依据我司的产品设计概要来写。没有依据的能力和效果，不会因为PPT需要显得完整就加上去。需要你们判断的选项和缺口，会集中放到讨论页。
对。你们交的应该是一份能讨论、能推进的方案，不是把我们的聊天按顺序摘成几页纪要。我要看到你们理解了什么、建议怎么解决、理由是什么、还缺哪些条件、双方接下来分别做什么。
十七、后续电话：首批范围进一步明确
上次聊完以后，我们整理了范围和资料清单。今天想核对几个会影响方案的点。上次首批文档说的是两百到三百份，项目资料也提到了权限限制。现在售后和资料管理同事讨论后，有没有更明确的范围？
第一阶段还是售后支持团队，大概一百二十人。资料先控制在两百份左右，不要按上限三百份去写。项目文档暂时不进入。先挑通用、有效、已经允许这个团队使用的业务资料，把这一轮试点做清楚。
好的。本轮方案会写约两百份售后业务文档，作为问答助手可以检索和引用的知识来源。早期访谈的两百到三百份会留在原始记录里，方便解释范围怎么变化；最终汇报采用您今天确认的范围，不让两个数字并列造成误解。
是。也不要把“两百份”写成已经全部整理并交付给你们了。资料清单和具体文件还需要准备。当前确认的是首期拟使用的范围，资料是否有效、能否读取、权限怎样安排，都要在准备阶段逐项核实。
再确认三个点：部署方式继续等信息安全评估；旧知识库接口要找IT确认；二十个真实问题由客户准备。六周仍然是希望看到内部试点效果，不是全量上线时间。这些理解是否有变化？
没有变化。下周先看方向，不需要正式报价。我们认可用可点击的Demo来帮助讨论，但要标模拟数据。至于采购、预算和具体部署安排，现在没有给你们一个已经确认的结论，不要在材料里替我们写定。
十八、收束：方案、责任和下一步
我把这次应交的东西再说一遍：一份业务方案汇报，讲清为什么做、给谁用、问答助手如何工作、用什么知识、需要哪些条件、怎样验证以及下一步分工。专业方案由我司对应同事核对，对外版本由我们统一确认。还有需要特别强调的吗？
请让范围和条件在页面上看得见，不要全部藏在最后一页很小的备注里。比如流程图画到检索资料时，就说明按权限查获准资料；讲到回答时，就说明有来源、没依据不猜；讲计划时，就说明哪些条件还在等确认。
我们会用能看懂的业务流程图来画：员工提问，必要时补充条件，按身份和权限找资料，给出带来源的回答，员工查看原文并反馈。涉及找不到、冲突或专业判断的问题，另外说明怎么交给人处理，不把它们画成自动解决。
这样就具体了。不要给我一个只有“数据层、能力层、应用层”的大图，让大家自己去想员工到底怎么用。可以有技术说明，但先让业务人员看明白一件事怎样发生、在哪一步得到帮助、什么时候还需要人。
后续我们分别跟进资料负责人、IT、信息安全和试用人员。尚未确定的事项放在同一张清单上，写明负责人和需要补充的信息。有了新的确认，就更新同一版本方案，避免每次开会大家拿着不同文件重新解释。
可以。我们希望下一轮讨论是在这个基础上继续往前走，而不是又从“你们到底想做什么”开始。先把这个问答助手的方向和试点条件讲清楚，再看实际验证结果，决定是否投入更多资源和扩大范围。