一家功能安全咨询公司卖AI Agent，听起来像什么？像一群天天把“证据”“可追溯”“评审证据链”挂在嘴边的人，突然开始兜售最不稳定的东西。我一开始也觉得这多半是蹭热度：功能安全靠的是对标准条文的抠字眼、对失效场景的穷举、对证据链的死磕，这些东西跟AI Agent能有什么关系？但真的把一个Agent放到客户现场跑了一轮之后，我的看法变了。

这篇文章不聊大模型有多聪明，聊的是我们怎么把功能安全这个“最保守”的咨询行当，拆成可以让Agent干活的具体环节，再把它作为产品卖出去。中间有五个已经落地的Agent场景，有从人天计价转向订阅+结果付费的定价纠偏，也有一个上线前差点让我们翻车的权限问题。适合正在犹豫要不要做AI产品的咨询公司朋友，也适合在功能安全圈子里被文档折磨的工程师。

1. 咨询行业的老底子为什么容得下Agent——三个死结与一个转机

1.1 按人天卖脑力的模式已经摸到天花板

功能安全咨询公司，表面上卖的是文档，实际上卖的是风险判断能力。但风险判断能力的载体，是几千个小时的专家经验，而专家的经验没法像货架上的商品一样复制到下一个项目。这个行当常年处在“项目多了人不够，人多了项目又没那么多”的周期循环里。人天报价的天花板算一算就清楚了：一个资深顾问一年能交付的人天就那么多，出差在路上占掉两成，剩下的时间还要开会、评审、改文档。产能上限不是管理问题，是数学问题。

更要命的是知识封装。我们每个顾问脑子里都装着一堆“当年那个项目”的经验：某个控制器在极端温度下做过什么处理、某个客户在HARA评分上会卡哪个条款、某个评审专家喜欢追问哪类安全目标。这些经验从来没有被结构化成公司资产。人走了，经验就跟着走了。新人培养周期又长，看懂标准容易，看懂客户怎么在标准面前打折扣难。

第三个死结是质量波动。同一个FMEA表格，A顾问填得干净利落，B顾问填得拖泥带水；同一个差距分析，今天用的判断标准和三个月前的版本就有出入。客户可能不会直接抱怨，但评审会上被开不符合项的时候，低质量文档的成本会加倍返还。这三个死结叠加在一起，让我们不得不认真想一件事：能不能把一部分“文档苦力”交给软件，把人腾出来做真正需要判断力的工作？

1.2 功能安全偏偏是文档密集、规则透明的行业

我见过太多咨询团队做AI产品，最后都死在同一个地方：拿不出来一条完整的证据链。功能安全客户不会因为你用了大模型就买账，他只会问一句——你的结论依据的是标准哪一条？

但功能安全这个行业有个特点，跟很多软件咨询不一样：它的流程文档极度结构化。虽然产品千差万别，但HARA、FMEA、安全需求、追溯矩阵，每一类文档都有固定的模板和填写规则。这就像一个两层的游戏：规则是固定的，内容因项目而异。AI Agent最适合的就是这种场景——规则由标准定义好了，剩下的工作就是根据项目上下文把内容填上去、把不一致挑出来、把证据链补全。

举几个具体场景。法规差距分析要求把客户现有流程和标准条款逐条对比，这是典型的“条款检索+文本对照”。FMEA要把历史失效数据、部件失效模式、现场反馈组织成结构化表格，这是典型的“信息检索+模板生成”。安全案例要把安全目标、论据、证据串成没有断点的链条，这是典型的“逻辑编排+证据引用”。这些场景的共性是什么？规则清楚、模板固定、重复度高、上下文因项目而异。正好是Agent比较擅长做的事。

1.3 为什么是现在：三个让我下决定的条件

这项技术三年前也存在，语音识别和搜索引擎也能做一部分，但做不到让我们愿意把它包装成产品去卖。真正让我下定决心的是三个条件同时到位。

第一个是语言模型的语义理解能力，已经到了能处理“条款号变了但描述语义不变”这种问题的程度。以前做文本对照，只能靠关键字匹配，条款一旦换了表述方式就断掉；现在可以按语义去找“项目开发流程中缺失了安全计划定义”和标准条款之间的对应关系。第二个是私有化检索的成本降到了项目预算能接受的范围。功能安全客户普遍要求数据不出域，这意味着不能简单调一个云端接口就完事，必须考虑私有化部署。现在一套检索增强方案跑在普通服务器上就能应付几百页文档，成本不再是拦路虎。第三个是客户自己变了。越来越多客户内部已经在用数字化工具管需求、管测试、管问题追踪，对“AI出草稿、人来复核”的工作模式并不排斥。

当然还有一个被很多人忽略的原因：功能安全标准很稳定。ISO 26262不会每个月变一次，IEC 61508的维护周期更是以年为单位。稳定的标准意味着知识库存量寿命够长，不用像做互联网产品那样天天跟着规则变动重写提示词，这对踩坑容忍度极低的咨询行业来说非常友好。

2. 我们实际在卖的五个Agent，每一个都冲着“文档苦力”去

2.1 法规差距分析助手：结论必须能溯源到条款

做法规差距分析的痛苦，做过咨询的人都懂。客户拿来几十上百页流程文档，说“你帮我们看看离合规还差多少”，背后其实是几百条标准和上百份公司文件的交叉比对。传统做法是顾问手动翻阅，一边看一边记，开着Excel逐条打钩。一个中高复杂度的差距分析，两个人做两周，做完还要酝酿一份动辄几十页的差距报告。

我们的Agent做的事情很直接：用户上传现有开发流程文档，Agent先按标准条款拆解成检查项，再对文档做语义级检索，输出差距清单，每条差距都带上“现行做法摘要”“标准要求原文”“证据缺口”三部分。关键设计是：结论后面必须能回溯到标准条款号和原文段落位置。没有溯源能力的差距分析，客户根本不会认，随便一个评审专家翻出原文就能把结论推翻。

实际跑下来后发现，检索不准的问题多半出在客户文档的命名上。某个客户把安全计划写成“SP_V2.1_Final_2023”，另一个客户在文件夹深处放了一份“HARA_Final_审核版_终稿”，这种命名不规则的文件，切割和索引都容易乱。我们后来在知识库里加了目录结构引导，让用户上传时先选文档类型，再允许Agent解析正文，准确率立刻上来了。

2.2 FMEA初稿生成器：把老师傅脑子里的事故库捞出来

FMEA表是功能安全里最让人头大的输出物之一。跨部门的人填出来的表五花八门，同一个失效模式，设计部门描述角度和质量部门都不一样；更浪费的是，老工程师在过往项目里处理过的大量失效模式，散落在旧Excel、邮件、问题追踪系统里，从来没人整理复用。

我们的做法不是让Agent凭空生成FMEA，而是从脱敏后的历史FMEA库里检索相近部件、相近场景、相近失效模式，给出初稿。工程师要做的不是从零填表，而是对初稿做判断：这条失效模式适用吗？严重度S、发生度O、探测度D的评分符合当前项目吗？需要补充哪些设计措施？

某工控设备项目试运行时的数据很有参考价值：Agent生成的描述性文字部分，工程师采纳率在七成左右；但评分部分几乎没有人直接采纳。原因很简单，严重度、发生度、探测度要结合具体运行场景和客户的历史失效数据来定，不可能靠通用模型猜出来。这个观察让我们明确了产品的边界：Agent负责把“从无到有”变成“从有到改”，工程师负责所有带判断的决策和评分。客户接受度很高，因为没人愿意从空表格开始敲字。

2.3 安全案例草稿助手：先把证据链骨架搭起来

安全案例是所有功能安全交付物里最难组织的一份。它不是写作文，而是要把安全目标、论据、证据组织成一条没有断点的链。很多项目经理写安全案例，写着写着发现中间缺了一环：某个安全需求没有对应的验证记录，某个验证记录没有关联到系统设计。回头补文档的滋味，体验过的人都懂。

我们把安全案例拆成“论据骨架+证据填充”两步。Agent按GSN（目标结构符号）的模式生成论据骨架，从项目文档库里检索可用的设计说明、测试报告、评审记录，一件件挂到对应位置上。工程师的任务是检查骨架逻辑通不通、证据关联得对不对、缺的证据要补做什么。

这里有个非常实用的经验：Agent生成的证据关联，只能作为线索，不能直接进入正式交付物。因为安全案例最终是要被评估机构看的，证据链的完整性、一致性、可验证性都有人为责任。我们的产品里做了一个“暂存区”设计，Agent找到的所有证据都先放到暂存区，工程师逐条确认后才进入正式版。这个设计看着很土，但恰恰是最让客户放心的地方。

2.4 文档一致性检查员：专治评审会上的不符合项

在功能安全评审会上，被开不符合项的重灾区之一就是文档不一致。同一个安全需求，在需求规范里写的是“响应时间小于100ms”，到了架构设计文档里变成了“响应时间小于150ms”，到了测试报告里又变成了“平均响应时间100ms”。这种问题人工查很费劲，因为要在几百页文档里来回翻；不查又不行，因为评估机构非常喜欢把这种不一致拎出来。

我们的Agent做的是术语级和参数级比对。它会提取文档中的需求编号、功能名称、关键性能参数、时间约束，跨文档比对同一实体的描述是否一致，输出一张不一致清单。每一条都标出“A文档原文位置”和“B文档原文位置”，工程师再审一遍确认。有个汽车电子试点项目的数据：几百页的文档集，人工抽检需要一周，Agent半天给出初版报告，人再花两天复核。虽然不能完全省掉人，但周期的压缩非常明显。

比较意外的是，这个Agent在售前阶段成了最受欢迎的一个。因为它解决的是“立刻能感知到的检查需求”，客户可以在谈判桌上看到一份自动生成的不一致清单，比演示什么泛泛的智能问答管用得多。

2.5 条款问答与新人陪练：当AI客服不如当“搜索优先”的资料员

最后一个Agent，我们最初是想做成内部培训工具给新人用的，后来发现客户那边也要，就包装成了产品。功能其实不复杂：新人问“ASIL分解到底能不能跨控制器”“HARA里的TTC和FTTI的区别”，Agent回答并附上标准条款上下文；导师在旁边负责纠正，必要的时候补充公司内部的方法论。

设计这个Agent时有个很容易踩的坑：把它做成AI客服。AI客服的交互是“用户提问，系统回答”，大家会本能地问“标准第几部分说了什么”，系统答对了还要追问“原文在哪一页”。所以我们把交互改成“搜索优先、答案其次、出处兜底”：任何回答都以检索结果作为支撑，宁可只返回相关段落，也不硬生成一段看似正确但找不到依据的结论。这块工作不花哨，但对功能安全行业的用户极其受用。

3. 到底卖什么：模型不是产品，证据链才是——技术架构与产品边界

3.1 不微调、不炼丹：用RAG守住私有知识边界

在第一版设计时，有人提过要不要微调一个专用模型，让它“记住”所有功能安全条款。我们算了一笔账就放弃了：标准条文多、细节深，微调需要大量高质量语料，成本不低；而且客户的项目数据是绝对不允许出域的，微调模型要么无法用私有数据，要么就得在客户环境里反复训练，周期和合规风险都不可控。

所以整体技术路线走的是RAG加工作流编排：把标准条款、模板库、历史项目文档（统一脱敏）作为基础知识库，客户上传自己的流程文档后，Agent在检索阶段就只从当前客户的知识库切片里找上下文，然后交给语言模型做归纳和生成。这样做的好处是把“知识记忆”的问题拆成了“检索质量”的问题。检索质量是可以被评估、被验证的，而记忆是不好验证的。

部署模式上，我们也做了区分。汽车电子客户对数据出域非常敏感，普遍要求私有化部署，我们就把整个服务打包成一个镜像放到客户环境里；工控设备客户相对能接受云端隔离实例，但也会明确要求“训练隔离”和“访问控制”。这个差异不是技术问题，而是客户所在行业的监管习惯问题，做方案时要在商务阶段就问清楚。

3.2 知识库分层比调参更花时间

真正花时间的地方不是模型，是知识库怎么组织。我们踩了一个多月才把知识库从“一堆PDF堆在一起”变成“分层的检索体系”。现在的结构大致是这样：

• 第一层：标准条款库，包括ISO 26262、IEC 61508等，按条款编号和章节标题切块，每一条都保留版本号和生效日期。
• 第二层：内部方法库，包括我们公司自己做项目时的HARA模板、FMEA示例、安全计划框架、评审检查单，这些是咨询公司的看家底子。
• 第三层：脱敏历史项目库，去掉客户名、产品名、具体参数后保留的结构化失效信息和文档片段。
• 第四层：客户自有库，每个客户的流程文档、阶段产物、评审意见单独隔离，只对当前项目开放。

切块策略也有讲究。我们最初学通用做法按固定token数量切，结果把条款切得支离破碎，检索经常断章取义。后来改成按标题层级和条款编号切：一个条款就是一个块，一个章节超过一定长度就按子标题继续切。检索效果立刻好了一大截。版本管理同样不能省，标准如果出新版本，旧版本必须在知识库里保留但标注“已废止”，否则Agent会混乱。

3.3 人必须留在环上：Agent出草稿，工程师签字

功能安全是证据学科，这个行业里没有人会允许AI Agent承担安全责任。如果产品话术里写着“AI自动生成安全案例”，客户评估机构第一个不答应。所以我们从一开始就把人机分工写死在产品逻辑里：Agent产出草稿，工程师在系统里做评审，评审意见和修改记录作为审计轨迹留档。

这套设计在产品界面上的体现就是“草稿态”和“定稿态”两个状态。Agent输出的东西全部在草稿态，带着明显的“AI生成未复核”标签；工程师逐条确认之后才能转成定稿态，此时系统记录确认人、确认时间、修改内容。这里还有个微妙的设计：定稿态的文档里不出现“AI生成”标记，因为功能安全交付物最终不能存在责任的第三方。

这个“人必须留在环上”的原则，我们还写进了销售材料的第一页。它既是卖点也是边界：卖点是帮客户把重复劳动省掉，边界是承担判断责任的一直都是人。同行做类似产品时，建议先把这个边界理清楚再去谈合同，不然后面扯皮的空间很大。

3.4 客户第一次问的永远是数据安全

第一次给客户讲Agent产品时，对方技术负责人听完并没有追问模型效果，而是问了一句：“我们的FMEA里带着真实故障代码和测试数据，传到你们平台会不会被拿去训练？”这个问题基本每一次演示都会被问到。

我们的回答分三层。第一层是合同约定：训练隔离写进条款，客户数据不用于任何模型训练，项目结束后按客户要求删除或交付归档。第二层是技术手段：私有化部署的客户，数据只在客户环境里处理；云端隔离实例的客户，数据库单独开库、单独备份、访问凭据分项目隔离。第三层是证据展示：我们专门准备了一份脱敏演示数据，所有现场Demo都用这份数据跑，不让客户的真实数据进入演示环境。

这里特别提醒一点：在功能安全行业做SaaS服务，不能拿“别人家都用云”来糊弄客户。客户的合规要求是他们所处的行业决定的，不因为你是软件服务商就放宽。

4. 从“人天计价”到“订阅+结果付费”：我们调了三次价格表

4.1 按人天卖Agent是自杀式定价

咨询公司有个根深蒂固的习惯：什么东西都按人天报。顾问一天多少钱，乘以预估天数，加上差旅费，就是报价。这套逻辑放在纯人力交付上没问题，但放在Agent产品上非常别扭。

原因很简单：Agent的边际成本几乎是零。同一个文档一致性检查Agent，跑一个项目是这些算力，跑一百个项目还是这些算力。如果按人天卖，客户会非常困惑：为什么你一个软件收得比两个顾问还贵？反过来，如果按人天折算得很便宜，我们自己又会发现：卖软件居然卖成了卖人头，利润率上不去，还要承担接口不稳定、算力波动这些不属于传统咨询的风险。

更微妙的是客户的心理预期。按人天报价，客户默认你在“出售时间”，会盯着你实际投入了多少人、干了多少天；按软件订阅报价，客户默认你在“出售结果”，会盯着你给我产出了什么价值。功能安全客户对结果的敏感度远高于过程，与其被追问“这个Agent到底算几天人天”，不如直接按结果来定价。

4.2 我们最后用的组合：订阅打底、项目制走量、结果付费做尖刀

调了三次价格表之后，我们定下的结构是三层组合。

第一层是基础订阅，包含文档一致性检查员和条款问答。这类功能使用频次高、价值清晰，按每个项目组或每个账号收年费。客户预算上容易批，我们也能获得稳定的现金流来支撑后续迭代。

第二层是项目制报价，包含法规差距分析和FMEA初稿生成。这类功能跟特定项目绑定，按项目发起、按项目收尾，用户数不限但限制知识库的文档量和项目数。客户认可度高，因为可以拿一个具体项目的预算来试水，风险小。

第三层是按结果计费，主要针对安全案例草稿。这类交付物价值极高，验收标准也相对明确，按生成的“论据骨架+证据关联初版”收费。客户相当于买了一个“加速器”，用自己的工程师时间换回更短的项目周期。

这个组合比单一订阅或单一项目制都好推进。原因在于它尊重了功能安全客户的采购习惯：不是从零接受一个全新工具，而是在已有的项目预算里挑一条最轻的路径先试。我们也遇到过客户要求“你干脆全包了，给我把这个项目的安全案例做到评审通过”，这种需求我们暂时不接，因为责任边界太模糊，一旦评审出现问题，说不清是产品的问题还是咨询交付的问题。

4.3 合同谈判中最容易扯皮的三个点

第一个是质量定义。客户会要求Agent保证“不出错”，这是一个无法承诺的东西。我们改成定量的口径：FMEA初稿的描述性文本采纳率不低于百分之多少、文档一致性检查报告的检出项必须逐条可溯源、法规差距分析的每个结论都必须带条款编号。客户能接受这种口径，因为功能安全本来就是一个讲究证据和量的领域。

第二个是责任边界。合同里必须写清楚：Agent输出为辅助材料，正式交付物的最终责任由客户指定工程师承担。我们不是想甩锅，而是功能安全的行业规矩本来就是“谁签字谁负责”。写进合同反而让客户的合规部门踏实，因为这意味着我们没有试图用AI替代责任主体。

第三个是数据条款。包括项目结束后多久删除数据、是否可以保留脱敏数据用于质量改进、私有化部署的客户是否有权在项目结束后继续使用系统。我们目前的规则是：客户数据默认项目结束后三个月内删除，脱敏数据可以用于内部检索质量测试，但不得用于任何第三方展示。

5. 踩坑实录：上线前三天，被一个“最简单”的权限问题困住

5.1 客户一句话，把我们拉回现实

整套Agent产品做出来后，我们安排了一家客户做上线试点。某资深安全负责人把我们拉进会议室，打开系统，点了几下，问了一句至今让我印象很深的话：“为什么我A项目组的账号，能在搜索结果里看到B项目组的文件列表？”

当时我第一反应是权限模块的配置出了问题。因为在功能安全场景里，项目间数据隔离是底线中的底线。客户那边两个产品线正好处于竞争关系，A项目组和B项目组的FMEA数据互相可见，哪怕只是文件名，都足以让客户当场终止合作。

我们找了一圈权限配置，没发现明显错误。菜单显示正常，角色设置正常，敏感文件在界面列表里看不到，但搜索接口确实把不该出现的结果返回出来了。这个现象很像是在某个环节把项目维度弄丢了。

5.2 缩小范围：界面没问题，接口有问题

按照排查惯例，我们先在测试环境复现，再用不同角色的账号做对比。结果发现：系统菜单和文档列表权限是正确的，A项目组的用户确实访问不了B项目组的文件夹；但一旦在全局搜索框里搜一个关键词，返回结果就混进了其他项目的文档。

问题被锁定在搜索接口。我们换了另一个账号反复测试，发现只要搜索关键词包含某些通用词，比如“安全”“失效”“电机”，返回结果里就会出现跨项目文档。更奇怪的是，通过文档列表页访问这些文档，接口会拒绝；但通过搜索结果的跳转链接访问，居然能打开。

到这里，局面已经很清楚：不是权限模块整体失效，而是搜索接口在检索时没有带项目隔离条件。

5.3 根因：项目ID在序列化环节悄悄丢了

查代码，最终定位到根因。搜索接口的请求体里设计了一个metadata_filter字段，用来传递当前用户的项目ID，服务端在向量检索时应该把这个字段作为强制过滤条件。前端日志里确实解析到了项目ID，但在组装请求体的过程中，某个内部工具类在序列化时把没赋值的extra字段覆盖了请求体，项目ID在这个环节被悄悄丢掉。服务端拿到的请求里过滤条件为空，默认执行全库检索，于是跨项目结果就出现了。

这是一个典型的“看起来简单但藏得很深”的问题。界面层完全没有报错，权限模块的单元测试也通过了，因为那些测试用例走的是另一个入口，没有覆盖这个搜索入口的参数链路。真正定位时，靠的是对比接口日志：发送方日志里还有项目ID，接收方日志里过滤条件为空，中间肯定有一个序列化或者参数装配的环节出了问题。

5.4 修复、验证、写进测试用例

修复本身不复杂：在检索API的服务端强制注入项目级隔离条件，不允许调用方决定是否携带过滤参数。也就是说，过滤条件不再信任前端传来的值，而是由鉴权中间件从当前登录态中解析，直接拼进检索语句。这样即使前端某次漏传，服务端也会自动补上。

改动完成以后，我们做了一轮账号矩阵验证：A项目组账号、B项目组账号、管理员账号、跨项目临时授权账号，分别搜索热门关键词，确认互相不可见。同时把这类用例写进了自动化回归测试，每周跑一遍。这次之后，我们规定所有涉及检索、列表、导出的核心接口，必须在请求级别做数据隔离断言，任何服务端接口都不能依赖前端的过滤参数。

5.5 为什么这个坑在功能安全行业尤其致命

在普通软件产品里，跨项目搜到别的项目文档，算是一个中等严重度的安全漏洞。但在功能安全行业，这是可以直接让客户终止合作的信任危机。客户评估机构的审核员对数据隔离极其敏感，一份跨项目泄露的FMEA，会被解读为“这家供应商连基本的数据边界都管不好，怎么能交付安全合规的系统？”

所以我的建议是：做面向功能安全客户的Agent产品，第一优先级不是模型效果，而是数据边界。演示之前先在真实环境里做权限和隔离的专项测试，账号矩阵要覆盖不同角色、不同项目、不同知识库之间的交叉访问。

6. 踩过这些坑之后，给同行的六条建议

6.1 先卖检查类，别把生成类当主力

检查类Agent的验收标准好定：不一致清单准不准、差异报告能不能溯源、检出项有没有漏报。客户可以在半小时内看到效果，购买决策也快。生成类Agent的使用效果依赖很多上下文，一旦生成结果不够好，客户容易觉得“花了钱买了个半成品”。我们的经验是：第一单下去，用检查类建立信任，再推生成类做增值。

6.2 每个Agent必须配一个“人肉负责人”

功能安全圈子认人不认系统。客户用你的Agent，一定会在群里艾特某个人问“这个结果为什么这么出”“能不能调整一下检索口径”。我们必须为每个Agent指定一个外部可见的负责人，这个人既懂功能安全业务流程，又熟悉产品的工作原理。说到底，客户买的不是一个黑盒，而是一个“知根知底的服务单元”。

6.3 标准条款库要用正版数据源

自己转录OCR标准条文，看起来省了钱，实际上风险很大：一是准确率没保证，条款号一旦错了一位，Agent给出的所有结论都不可信；二是标准文本本身涉及著作权和授权问题，功能安全客户对这类问题的敏感度不亚于代码合规。我们最后是通过正规授权渠道获得的条款数据源，并且逐条校验过版本号。

6.4 演示Demo永远用脱敏数据

演示时用真实客户数据，哪怕只是截图，都可能构成泄密。我们的规矩是：所有演示环境跑一套固定的虚构数据集，数据脱敏到看不出任何真实产品信息。宣传材料里的案例也都改成行业说法，例如“某汽车电子客户”“某工控设备客户”，不出现可识别的项目特征。

6.5 销售话术里禁止出现“替代顾问”

这个行业里，客户信任的是顾问的专业判断，而不是一套软件系统。销售材料里要是写了“AI替代安全顾问”，会同时得罪客户内部的安全团队和我们自己的交付团队。我们的话术是“把顾问从文档苦力里解放出来，去做更有技术含量的评审和决策”。这不是包装，而是Agent产品真实的价值定位。

6.6 从单项目试点进，不要一上来就推全公司订阅

功能安全部门对工具的接受是渐进式的。客户安全负责人不可能在没有充分验证的情况下，给全公司买一个Agent订阅。我们现在的推进路径是：选一个正在做的项目，限定在项目范围内试用，跑完一个里程碑，拿出量化收益，再谈扩大范围。一旦试点项目里出了差池，影响的是后面所有商务谈判。

最后再分享一个个人体会：如果让我重来一次，会更早地把“AI负责初稿、人负责判断”这条分工线定在合同里，而不是等客户追问的时候再去解释。这个行当不缺技术能力强的人，缺的是把知识封装成产品、并让客户放心买走的能力。另外一个小技巧：客户上线前，先拿一份公开的脱敏文档跑通全流程，让客户亲手点一遍“从结论溯源到原文”的按钮，这比你讲十页PPT都管用。