企业官网建设流程全解析

1. 别急着谈“AI 赋能”，先看看这个词被用坏成了什么样

我去年参加过一个内部评审会，某公司业务线的负责人在汇报里写了满满一页“AI 赋能全链路提效”，PPT 做得漂亮，从“赋能”到“闭环”到“抓手”，词都堆齐了。轮到我提问，我只问了一句：这条链路上，AI 具体替代了哪个动作、那个动作原来一天要花多少人工小时、现在还剩多少？会议室安静了大概十秒钟。这十秒钟其实就说明了问题——很多人嘴里的“AI 赋能”，赋的是一种情绪，不是一种能力。

“AI 赋能”这四个字被用滥了，滥到一线做事的人听见就想笑。但你要是因此就否定它，那也不对，因为真正把 AI 嵌进业务里的团队，确实拿到了实打实的收益：原来三个人做一天的资料比对，现在一个人半小时过一遍；原来新人上手要三个月才能回答客户问题，现在两周就能靠内部问答兜住。所以问题不在“赋能”这个词本身，而在于大部分人从没把“赋”这个动词拆开过——赋给谁、赋什么、赋完之后对方多了什么能力、这个能力怎么被验证。

这篇文章我想干的事很简单：把“AI 赋能”这个词按在手术台上，一层一层剥开。它适合三类人看——正在被要求写“AI 落地方案”但不知道怎么落笔的产品和业务岗；手上有一堆重复劳动想找突破口的技术同学；以及被各种供应商 PPT 轰炸、想搞清楚哪些是真能干、哪些是纯忽悠的决策者。看完你至少能自己判断一件事：你手上这个场景，AI 到底能不能赋、能赋多少、赋完值不值。

1.1 我见过的三种“假赋能”

第一种我称之为工具赋形不赋神。买了一套问答系统，接了个大模型接口，界面上加了个对话框，然后对内宣布“我们的 AI 能力已上线”。实际情况是员工问的第一个问题它就答不上来，因为知识库是空的，或者塞进去的是三年前过期的规章制度。这种赋能的实质是“我们有了一个 AI 入口”，跟“我们有了一个电话”没什么区别，能力并没有增长。

第二种是指标赋数不赋实。汇报材料里写“AI 使用率达到 78%”，这个数字是怎么来的？是把所有登录过系统的人都算进去，还是把真正每天用、并且任务被替代掉的算进去？我见过最离谱的一份统计，把“员工点开过一次侧边栏对话框”也算作活跃。数字好看，业务没变，年底一算人力成本，一点没少。

第三种最隐蔽，叫场景赋点不赋线。某个环节做得特别好，比如合同关键信息抽取准确率做到 95%，但上下游没有打通——抽出来的信息没人用，还是靠人工再录一遍到另一个系统里。这个 95% 除了让展示页面好看，对流程的价值接近于零。赋能要看的从来不是单点精度，而是这条链路的端到端时间有没有缩短。

判断真假赋能只有一个土办法：拿一张纸，左边写下这件事原来的人工动作和耗时，右边写下现在的人工动作和耗时。右边如果只是“动作变轻了但没有消失”，那叫优化；如果整段动作消失了，那才叫赋能。

1.2 AI 真正改变的只有三件事

把玄乎的词去掉，AI 在做的事说穿了就三件。第一，把非结构化信息变成结构化信息。一份合同、一段录音、一页手写单据，原来只有人能看懂，现在机器能提取出字段。第二，把散落的信息压缩成答案。原来要在十几个文档里翻半小时，现在一句话问出来。第三，把重复的表达和生成变成批量化产出。写摘要、写回复、写初稿、写测试用例，这类活儿原来按篇算人力，现在按批算。

这三件事背后有一个共同点：它们原本消耗的是人的阅读时间和表达时间。而这两种时间，恰恰是知识型工作里占比最大、又最容易被低估的部分。你回想一下自己上个星期的工作，有多少小时是花在“找东西”和“把找到的东西重新组织成一段话”上的？如果这个比例超过三成，那你这个岗位就有被赋能的巨大空间，而且这个空间是能量化出来的。

2. AI 赋能的五个“赋”，拆开看才不玄乎

我一直觉得“赋能”这个词最大的问题是它太抽象，抽象到无法拆解成任务。所以我习惯把它翻译成五个具体的“赋”，每一样都能对应到可测量的动作上。你在做方案的时候，可以直接拿这五条去对照，看你的场景落在哪一条，或者哪几条的交叉点上。

2.1 赋效率：把检索、汇总、初稿压到分钟级

这是目前落地最广、见效最快的一条。它的本质是压缩“从信息存在”到“人拿到手”之间的路径长度。传统做法是：资料存在共享盘或者知识库里，人要知道路径、要会搜关键词、要打开好几份对照、最后自己归纳。AI 把后面三步压成了一步。

举个我实际跟过的场景。某公司做投标文件，一份标书要响应招标方的几十条要求，原来两个商务同事对着招标文件逐条比对自家产品参数，一份下来四到六个小时，赶上大项目要一整天。改造之后的做法是：把招标文件里的要求条款抽取成结构化清单，把自家产品库做成可检索的知识块，让模型逐条匹配并标出“满足/部分满足/不满足/需确认”。人工从“逐条找”变成“复核机器给的结论”，一份标书的初筛时间压到一个小时上下。

注意这里的关键不是“节省了几小时”，而是动作性质变了。原来是生产动作，现在是审核动作。审核动作可以标准化、可以抽检、可以追责，而生产动作很难。这一点决定了后续的质量管理体系能不能建起来。

另外要提醒一句，效率类场景最容易踩的坑是“以快为荣”。速度快了，人就容易跳过复核，最后错的还是错的，只是错得更快了。所以凡是效率类赋能，必须同时设计一个“抽样复核比例”和“错误回流的渠道”，否则你只是把错误的生产效率也提高了。

2.2 赋判断：从“给数据”到“给参照系”

这条比上一条难，因为涉及到决策辅助。很多团队做到“把数据查出来给到人”就停了，觉得任务完成。但一线的真实痛点是：数据我拿到了，可我不知道这个数算好还是算差。

判断类赋能的核心是给参照系。比如客服质检，原来主管听录音打分，凭经验判断这通电话“态度不好”。现在 AI 不只是转写文本、标出情绪词，而是给出“这通电话在同类问题里的话术偏离度”“有没有触发必须道歉的规则”“和上月优秀样本的相似度”。主管看到的不是一个分数，而是“为什么是这个分数”。

这里的技术要点是:模型给出的结论必须可溯源。我一般会要求把判断拆成“证据片段 + 规则条款 + 结论”三段式输出。证据片段是从原始材料里摘出来的原话，规则条款是内部制度里的具体条目，结论是这两者比对的结果。少了任何一段，判断就变成了玄学，业务方不会信，也不会用。

还有一点很现实：判断类场景千万不要一上来就做“全自动决策”。先做“建议 + 人工确认”，跑三个月，把人工修改记录全存下来，这份修改记录就是你未来做效果评估和模型微调最值钱的资产。跳过这个积累期直接上全自动，出了事没人兜得住。

2.3 赋表达：把专业语言翻译成对方能听懂的话

这条被严重低估。很多技术团队觉得“生成文本”是最没技术含量的事，但实际上企业内部大量的沟通成本，都耗在“同一个意思用不同语言重复表达”上。技术人员写的故障说明，业务方看不懂；业务方提的需求，技术方理解偏了；给客户的方案，术语堆得客户不敢签。

AI 在这件事上的价值是做语言层的适配器。同一份技术故障报告，给研发看要保留堆栈和参数，给业务看要翻译成“影响了哪些功能、多久恢复、要不要通知客户”，给管理层看要浓缩成“原因、影响、已采取措施、后续改进”四句话。原来这活儿要么让写报告的人写三版，要么让中间人转述，现在可以让模型基于同一份源材料生成不同颗粒度的版本，人只做审校。

我踩过的坑是：别让模型自由发挥。生成对外话术的时候，必须给它一份“禁用词清单”和“必须出现的关键信息清单”。比如涉及赔付的表述不能自己加码，涉及时间承诺的不能自己缩短。这类约束写进提示词里，比事后人工删改要省事得多。我一般的做法是把约束分成硬约束（不能出现某些表述）和软约束（语气、长度、结构），硬约束用规则校验再过一遍，软约束靠提示词引导。

2.4 赋流程：把散点动作串成闭环

前三条都是单点，这一条才是真正决定成败的。前面说过，单点做得再好，如果上下游没打通，价值会被流程吃掉。流程类赋能的核心是把“人手动搬运”这个环节干掉。

举个典型的流程：客户投诉进来，原来是这样走的——客服记录、转给对应部门、部门排查、回复客服、客服回复客户。中间每一步都靠人用聊天工具传话，信息在传的过程中衰减。改造之后：投诉内容自动分类、自动关联历史同类工单和解决方案、自动生成给责任部门的工单（含上下文）、处理完成后自动生成回复草稿。人做的只剩“确认分类对不对”和“确认回复能不能发”。

这里最关键的技术点不是模型，是接口和状态机。模型只是流程里的一个节点，它前面要能拿到结构化的上下文，后面要能把结果写回系统。我见过太多项目卡在这里：模型能力做完了，结果发现业务系统的接口不开放，只能人工把结果复制粘贴回去，等于什么也没省。所以做流程类赋能，一定要在动手写第一行代码之前，先把“数据从哪来、结果往哪去”这两件事确认清楚。

2.5 赋沉淀：让个人经验变成组织资产

这条是最长期、也最容易被忽略的。任何一个组织里，真正的能力都长在老员工脑子里。他们知道哪些客户不能催、哪些单子要先走哪个流程、哪些问题看着像 A 其实是 B。这些人一走，能力就没了。

AI 在这里的作用是提供一个沉淀的容器和提取的抓手。具体怎么做？不是让老员工坐下来写文档，那没人愿意写。而是把他们的真实工作过程录下来——处理的工单、改过的方案、回复过的话术、在群里解释过的原因——用模型做归纳提炼，生成结构化的经验条目，再让人确认修订。这个过程叫“从行为反推知识”，比“让人主动写知识”的转化率高得多。

我个人的判断是，这一条在未来两三年会变成企业 AI 投入的重心。因为前四条赋的是当下的效率，这一条赋的是组织未来的能力上限。而且它有个附带好处：沉淀下来的知识条目，反过来又能喂给前四条做支撑，形成正循环。

3. 核心逻辑：赋能不是“上一套模型”，是“搬一次隐性知识”

如果把前面五条再往上抽一层，我认为 AI 赋能的本质只有一句话：把原本只存在于人脑里的隐性判断，搬到系统里变成可调用、可校验、可迭代的显性规则，同时把调用这件事的边际成本压到接近于零。

这句话里有三个关键词，每一个都对应一个常见的失败原因。

3.1 一条公式：赋能价值 = 频次 × 单次节省时间 × 采纳率

我习惯用这个公式做初筛，比任何评估模型都直接。频次是这件事一天/一周发生多少次，单次节省时间是每次能省多少分钟，采纳率是模型输出被人真正接受的比例。三者相乘，就是这个场景一年的可量化收益量级。

举个例子。某场景一天发生 50 次，每次原来花 8 分钟，AI 之后花 2 分钟，采纳率 70%。那一天的净收益就是 50 × 6 × 0.7 = 210 分钟，约 3.5 个工时。一年按 250 个工作日算，接近 875 个工时。这个数字拿去和投入成本对比，值不值一目了然。

这个公式最大的价值是帮你排除掉那些看起来很酷但没价值的场景。有些场景单次节省时间很可观，比如一份研报从 4 小时压到 1 小时，但一年只做两次，那收益就是 6 小时，再高的技术含量也不值得单独投入。反过来，有些场景单次只省 30 秒，但一天发生两千次，那才是金矿。

采纳率这个因子最容易被忽略，但它往往是决定性的。采纳率低于 50% 的场景，基本可以判定为“AI 在给人添活”——人还得看一遍、改一遍、有时候改得比自己写还费劲。这时候要么优化输出质量，要么就承认这个场景还没到能上的时候。

3.2 为什么大多数项目死在“知识没被搬出来”

我复盘过几个失败的项目，共同点惊人地一致：模型没问题，接口没问题，界面也没问题，但效果就是不行。往深了查，全都是同一件事——该搬出来的知识，根本没被搬出来。

具体表现是：知识库里只有公开的制度文档，而员工真正需要问的问题，答案在某个微信群里、在某个人电脑的表格里、在老员工的口头习惯里。你让模型去回答这些，它只能编。编出来的东西看着像模像样，实际一用就错，用两次之后就没人再用了。

所以做任何 AI 落地，第一步应该是一次“知识考古”：把这个场景下所有需要的信息源列出来，标清楚哪些是显性的（文档、系统数据）、哪些是隐性的（人的经验、口头约定、例外规则）。显性的直接接，隐性的必须设计提取机制——要么访谈整理，要么从历史行为里挖，要么就承认这部分暂时覆盖不了，在提示词里明确告诉模型“遇到这类问题请回答不知道并转人工”。

一句大实话：知识库里没有的东西，模型不会凭空变出来。它只会用流畅的语言把不知道包装成知道，这比直接报错危险十倍。

3.3 从“人找信息”到“信息找人”的翻转

传统信息系统的逻辑是人找信息：你得知道去哪找、用什么词搜、找到之后自己判断哪份是最新的。AI 带来的真正翻转是信息找人：你把当前正在做的事告诉它，它把需要的东西推到你面前。

这个翻转听起来简单，但对流程设计的影响是根本性的。因为“人找信息”的系统可以把所有内容堆在一个库里，让用户自己筛；而“信息找人”的系统必须在正确的时机、用正确的颗粒度、把正确的内容推出来。早了是打扰，晚了没用，颗粒度粗了要人再筛一遍，细了可能断章取义。

做这件事的技术手段，常见的是把业务上下文一起带进检索。不要只拿用户的那句问话去做检索，要把用户当前所在的页面、正在处理的单据类型、最近的操作记录一起作为检索的输入。我实测下来，加了上下文之后，检索命中率能往上走一截，因为很多问题单看那句话是歧义的，加上场景就清楚了。

4. 四个可抄的实践方向，附场景拆解

理论说完了，落到地上。下面这四个方向是我认为现阶段性价比最高、复用性最强的，不管你所在的是哪个行业，大概率能对上其中一个。每个方向我都会说清楚：解决什么问题、关键动作是什么、难点在哪。

4.1 方向一：文档密集型业务的“问答 + 比对”

这是最经典的一类。凡是靠文档吃饭的岗位——合同、标书、申报材料、合规审查、研究报告——都属此类。核心痛点不是“看不到文档”，而是“文档太多、要求太散、比对太累”。

落地路径分三层。第一层是问答：把文档切块、向量化、建检索，用户提问时先检索再生成，答案带出处。这一层的价值是让人不用通读全文就能定位到关键段落。第二层是比对：给定一份“要求清单”和一份“响应材料”，逐条判断是否满足，输出差异表。这一层的价值是把“逐条人工核对”变成“复核机器结论”。第三层是留痕：所有问答和比对的过程、依据、修改记录全部存档，形成可追溯的审查链。

难点在第二层。逐条比对看起来简单，实际上要求模型理解“同义不同表述”。比如要求写“响应时间不超过 2 小时”，材料里写“接到通知后 120 分钟内到场”，这是满足的，但字面完全不同。我一般的处理是让模型先做语义归一，把两边的表述都翻译成统一的结构化字段（指标名、数值、单位、条件），再比对数值，比直接让模型判断要稳得多。

4.2 方向二：客服与售前的“知识兜底”

这个方向的场景特点是：问题重复度高、答案有标准、但新人不熟。核心痛点不是“没有答案”，而是“答案散在十几个地方，新人找不到或者找错”。

落地时我建议先做“辅助”不做“替代”。具体说，客服在和客户对话时，系统在旁边实时给出建议回复、相关知识条目、以及“这个问题过去是怎么解决的”的历史案例。客服看一眼，觉得对就用，不对就自己写。这个过程里，所有的“采用/不采用”都是宝贵数据。

真正难的是知识的新鲜度维护。产品一改版，几十条知识就过期了，如果没人维护，模型就会自信地给出过时答案。我的做法是给每条知识打上“生效时间”和“关联产品版本”，检索时带上版本过滤，同时设一个“超过 N 个月未复核”的标记，定期推给人确认。这件事没有捷径，必须有个人对知识的新鲜度负责。

4.3 方向三：研发与运维的“日志与代码辅助”

技术团队自己用的场景，反而最容易量化。典型的有三个：故障日志的归因分析、历史工单的相似检索、以及代码变更的影响面提示。

归因分析这块，模型的作用不是“诊断”，而是“收敛”。一次线上故障可能产生几万行日志，人看不过来。做法是先把日志按错误类型聚类、按时间窗口排序、把首次出现的异常和它的上下游调用链摘出来，形成一个“嫌疑清单”，人再顺着清单排查。这个动作能把定位时间从小时级压到分钟级。

代码辅助这块，我的经验是别指望它写业务逻辑，指望它写样板和解释。写单元测试、写数据转换脚本、给一段看不懂的老代码写注释和调用关系说明，这些活它做得比人快得多，而且错了也容易发现。反过来，涉及核心业务规则的代码，让它写你必须逐行审，那还不如自己写。

4.4 方向四：内部流程的“表单到动作”

这个方向听起来不酷，但 ROI 往往最高。典型场景是各种审批、报销、采购、入职、变更申请。痛点在于：表单填完之后，要有人判断该走哪个流程、该通知谁、该准备什么材料。

做法是把“表单字段”到“后续动作”的映射关系显性化。用户提交表单，系统自动判断流程分支、自动生成待办、自动附上需要参考的历史案例。人只需要确认“分支判断对不对”。

这里的技术含量其实不在模型，在规则引擎和模型的配合。硬性规则（比如金额超过某个阈值必须走某级审批）用规则引擎，确定性高、可审计；模糊判断（比如这个申请的理由描述是否充分）用模型。两者分工清楚，系统才稳。我见过把所有判断都丢给模型的方案，结果是同样的输入偶尔给出不同的分支，业务方直接崩溃。

5. 落地七步：从选场景到验收的完整路径

说完方向，说方法。这套流程是我在几个项目里磨出来的，不敢说通用，但至少能让你少走弯路。整个过程我一般压在六到十周，超过这个时间还没看到可用版本，多半是场景选错了或者范围铺太大了。

5.1 选场景的三个筛子

第一个筛子是高频。翻过去三个月的工单系统或者任务记录，找出发生次数最多的前二十类事情。第二个筛子是有标准答案。这件事做得对不对，能不能被明确判断？如果连老师傅都要说“看情况”，那不适合先做。第三个筛子是错了代价可控。先做那些错了能兜住、不会造成对外损失或者合规风险的场景。

三个筛子同时过的场景，通常不超过三个。就从这里面挑一个，不要贪多。我见过同时铺五个场景的团队，最后五个都是半成品。

5.2 数据准备与切分实操

数据这块，第一步是盘点。把候选信息源列出来，标上：多少份、什么格式、多大规模、更新频率、有没有权限限制。这一步经常能劝退一批场景——比如核心资料全在个人手里，或者格式是扫描件且质量很差，那这个场景的前置成本会很高。

第二步是清洗和切分。文档切分不是随便按字数切，要按语义边界切。标题、段落、表格行是天然的边界。切得太碎，模型拿到的上下文不完整；切得太大，检索精度会下降。我常用的做法是层级切分：先按章节切大块，再在大块内按段落切小块，检索时先命中大块再定位小块，兼顾精度和上下文完整性。

# 层级切分的最小示例（伪代码，仅示意逻辑） def split_doc(doc): chapters = split_by_heading(doc) # 先按标题切大块 result = [] for ch in chapters: blocks = split_by_paragraph(ch) # 大块内按段落切 for i, b in enumerate(blocks): result.append({ "chapter": ch.title, "block_id": i, "text": b, "neighbors": [blocks[i-1] if i > 0 else None, blocks[i+1] if i < len(blocks)-1 else None] }) return result

注意neighbors这个字段，很多人不做。但实际用起来很关键：检索命中一个段落时，把它的前后段一起带进上下文，模型的回答质量会明显提升，因为很多信息是跨段落的。

5.3 提示词与评估集怎么搭

提示词不要一版一版凭感觉改。先写一份“基准版”，把角色、任务、输出格式、约束条件写清楚，然后建一个小评估集：从真实历史数据里抽 50 到 100 条，人工标注好“期望输出”，每次改提示词都拿这个集合跑一遍，看通过率有没有提升。

评估集要覆盖三类样本：典型样本（最常见的那类问题，占七成）、边界样本（模糊的、有多种理解的，占两成）、对抗样本（故意问知识库里没有的、或者问法奇怪的，占一成）。第三类最重要，它检验的是模型会不会瞎编。

# 评估脚本骨架（伪代码） cases = load_eval_cases("eval_set.jsonl") # 每条含 input 和 expected def check(pred, expected): # 结构化输出直接比字段；自由文本用关键信息命中率 if expected["type"] == "structured": return pred["fields"] == expected["fields"] else: hits = sum(1 for k in expected["must_have"] if k in pred["text"]) return hits / len(expected["must_have"]) >= 0.8 passed = 0 for c in cases: pred = run_model(c["input"]) if check(pred, c["expected"]): passed += 1 print(f"通过率: {passed}/{len(cases)}")

这套东西看着土，但它是你后续所有迭代的地基。没有评估集，你改提示词就是在赌博，改好改坏全凭当天手感。

5.4 上线后的监控与迭代

上线不是结束，是开始。我一般会盯四个指标：调用量（有没有人用）、采纳率（用了之后有没有被改）、转人工率（模型答不上的比例）、错误反馈量（用户主动报错的次数）。

其中采纳率是最灵敏的。它一旦开始下滑，说明要么知识过期了，要么业务变了，要么用户找到了绕过系统的办法。这时候别急着调模型，先去看那批“被修改的输出”，看看人是怎么改的，改的地方往往就是模型没考虑到的业务规则。

迭代节奏我建议按周。每周抽一批失败案例，归类成“知识缺失”“提示词问题”“检索问题”“模型能力问题”四类。前两类自己就能修，第三类调检索策略，第四类才考虑换模型或者微调。顺序不能反，我见过太多团队一上来就想着换更强的模型，结果换了三版效果还是那样，因为问题根本不在模型。

6. 踩坑实录：那些让人白干三个月的细节

这一节全是我自己或者身边人真实踩过的坑，写出来不是为了吓人，是因为这些坑在方案文档里从来不会出现。

6.1 效果不好，八成不是模型的问题

这句话我逢人就说。遇到效果不达预期，先按这个顺序排查：数据在不在（知识库里到底有没有这条信息）、检索到没到（检索环节有没有把它捞出来）、上下文够不够（捞出来的片段是否完整）、提示词说清没（任务和格式有没有明确）、模型能力够不够。前四个都属于工程问题，占了失败的绝大多数；真正需要换模型的，我遇到的不到两成。

一个具体的例子：有个问答系统，用户问“这个流程要几天”，模型老是答错。查了半天发现，知识库里有三份文档写了不同的天数，分别是旧版、新版和特批情况。模型没错，是知识本身冲突了。解决办法不是调模型，是把知识做版本管理，检索时按生效时间过滤。这种问题，换再强的模型也没用。

6.2 成本与延迟：两座被低估的山

做方案的时候大家算的都是“单次调用多少钱”，很少有人算“一天总调用量乘以输入长度”。实际上输入长度才是成本大头。一份十万字的中文材料，粗算下来是十几万 token 的量级，如果你每次都把全文塞进去，那成本会高得离谱，延迟也扛不住。

所以检索这一步不是可选项，是必需项。把十万字压缩成两千字的上下文，成本能差两个数量级。这个账要提前算清楚：日调用量 × 平均输入 token × 单价，再乘 30 天，看看这个数字你能不能承受。如果承受不了，那就必须在检索精度和上下文长度之间做权衡，而不是硬上。

延迟这件事更容易被忽略。用户能忍受的等待大概是三秒以内，超过五秒就开始烦躁，超过十秒基本就放弃了。而一次带检索的生成，如果检索慢、上下文长、模型大，很容易超过十秒。优化手段无非是：缩小上下文、用小模型做初筛、把能预计算的提前算好、流式输出让用户先看到字。这些工程手段比换模型有效得多。

6.3 常见问题速查表

再说两个不成体系的技巧。第一，把“不知道”设计成一个正式的输出选项。很多团队怕模型说不知道显得不智能，实际上用户更怕它瞎编。明确告诉模型“信息不足时请说明缺少什么并建议转人工”，反而会提升信任度。第二，给输出加置信标记。检索到的证据充分时标高置信，证据薄弱时标低置信并提示复核。这个小设计能大幅降低误用率。

7. 我个人对这件事的一点体会

做了这几个项目之后，我最大的感受是：AI 赋能这件事，技术只占三成，剩下七成全是“把事想清楚”的功夫。想清楚哪个动作最耗人、想清楚知识藏在谁脑子里、想清楚错了之后谁来兜、想清楚这套东西上线三个月后谁来维护。这些问题的答案，比选哪个模型重要得多。

还有一个很实在的经验：从小处切，切到能在一个月内看到效果。别一上来就规划“全公司知识大脑”，那种项目大概率做两年还在内测。找一个具体的、高频的、错了也没大事的场景，做完，让用的人真觉得省事了，然后再往下一个场景推。口碑是靠一个个小胜利攒出来的，不是靠一份架构图。

最后分享一个我判断项目健康度的土办法：去看用户有没有在系统之外偷偷用别的办法解决问题。如果他们还留着一份自己的表格、自己的笔记、自己的土办法，那说明系统没真正嵌进工作流。等到某天你发现有人抱怨“系统挂了今天没法干活了”，那才说明这事成了。