上一篇写完，我们算是有了一张 AI Native 转型的地图。
方向与结果、组织怎样工作、市场与生产之间的价值链、支撑任务流动的协同底座。这几层放在一起，可以解释一家企业为什么不能靠几个零散的 AI 工具完成转型。
不能说画完地图就算完成了行军，我们需要迈出坚实的第一步。
这篇文章我们不再增加新的概念，而是选用一条真实的业务链，把之前文章中谈过的知识、权限、责任、验收、反馈在真实场景里落地一遍。
那篇文章提到过，企业 AI Native 的第一步，一定要找一条高频、边界可控、结果可验收的真实业务链，让 AI 接住其中一部分工作，再把人工责任、验收证据和错误回写一起放进去。
本文选择的场景——售前数字员工，就非常符合这个要求，下面我们展开说说。
一、我们为什么先选售前技术应答
做企业软件的公司，经常会收到客户发来的技术需求。
一份需求里可能同时出现文件归档、在线预览、人员权限、密级控制、企业微信入口、项目管理系统对接、版本管理、自动归档和流程审批。销售拿到以后，需要逐条判断：标准产品能不能支持，哪些需要定制开发，需要配置还是需要集成，哪些地方资料不够，还要找谁确认。
以前这件事通常要交给资深售前工程师，或者售前总监来做。
普通工程师也能读文档，但很难同时掌握多个版本的产品能力、不同模块之间的关系、历史项目做过什么、哪些能力可以直接承诺、哪些话必须留有边界。资深人员要从多份材料里重新查一遍，再形成一版技术答复，大概需要半个小时到一个小时。
我们现在做了一个售前数字员工。
销售把客户需求交给它，它先拆解需求，再从产品介绍、版本说明、操作手册、接口文档和历史材料里寻找依据，最后生成一份逐项应答。现在生成第一版大概需要一到两分钟，专家再花十分钟左右看一遍。
这组数字来自十几组真实对话。目前还在内部试用和影子运行阶段。数字员工已经处理真实需求，但正式口径仍然由原来的专家负责。它可以参与工作，还不能独立对外。
预期再做半个月左右的集中调试，将会把专家审核时间进一步压到三到五分钟。这个还是目标，不是已经得到的结果。是否能够稳定上线，最终要看真实样本的验收，不看日历走了多少天。
第一条链选择售前技术应答，原因也比较朴素。
它反复发生，消耗的又是企业里比较稀缺的人。输入是一份客户需求，输出是一份技术应答，中间范围可以控制，结果也能由产品和售前专家逐条检查。即使 AI 暂时答错，只要不直接发给客户，风险还接得住。
第一条链不一定要从最容易的工作开始。而是找到那些反复消耗稀缺人员精力、又能把风险关在一个小范围里的工作。
二、先把“回答问题”压成一条可验收的链
我们最早的目标很直接：做一个懂公司产品的售前数字员工。
这个目标太大，也没法验收。
后来，我们将其细化成一个更明确的任务：一份技术需求进来，系统生成一份逐项应答草稿，由售前专家确认以后，变成正式材料输出。
这里最关键的一步，是把客户的长文档拆成原子需求。原子需求就是已经拆到可以单独判断的一条需求。
比如“支持远程访问，通过企业微信入口，并能够本地化部署加 VPN”，看起来是一句话，里面至少有远程访问、企业微信集成、本地化部署和 VPN 四个能力点。只给一个笼统的“支持”，后面一定会出问题。
每条原子需求还不能只回答“可以”或者“不可以”。企业软件里的支持方式差别很大：有些是标准产品直接支持，有些需要配置，有些依赖接口集成，有些要定制开发，还有一些本来就是管理制度和人工执行的问题。资料不足时，也必须明确停在“待确认”。
所以一条应答至少要带上判断、依据、产品版本、适用条件和待确认负责人。
做到这里，数字员工才从一个会聊天的工具，变成了一条可以验收的工作链。
它的结束点也要说清楚。当前这条链只到技术应答，不进入报价、合同承诺和交付周期。范围缩小了，结果仍然是完整的：一份经过责任人确认、可以进入正式售前材料的答复。
三、一个真实的问题，文档ready ≠ 知识ready
做了十几组对话以后，我们碰到一个很典型的问题。
产品 1.0 的文档会把当时的全部功能写清楚。到了 1.1，文档通常只写这次增加和修改了什么。后面的 2.0、3.0 也是同样的写法。
人看这些资料时，会把历次变化叠起来。一个做了很多年的产品经理，知道 3.0 不只是 3.0 更新说明里的那几项功能，它还继承了前面版本继续有效的能力。
AI 直接检索时不一定会这样处理。
当我们问“3.0 有哪些功能”，它可能命中了 3.0 的更新文档，然后把“这一次改了什么”当成“3.0 现在完整有什么”。AI没有编造内容，但答案不完整。
当前我们的处理方式，还是让 AI 在每次问答时临时汇总 1.0 到 3.0 的变化。这能解决一部分问题，但每次都重新拼装，结果会受检索材料和上下文影响。
下一步要把这件事前移。
AI 先把 1.0 的全量功能和后续每个版本的新增、修改、废弃合并起来，生成一份当前版本的全量功能清单。产品经理逐项确认以后，再把它固化成正式的产品能力基线。售前数字员工回答问题时，优先查询这份已经验收过的当前事实。
这个过程让我意识到，AI在企业中落地，会有大量在实验室推演中想象不到的问题。
这些问题都不复杂，但这是AI落地的最关键的一环，如果不解决这类适配性问题，我们很容易得出AI还不靠谱的结论，从而使AI转型停滞甚至倒退。
四、AI 的上限很高，企业更要守住下限
售前数字员工的上限已经摆在眼前。
过去资深人员要花半个小时到一个小时完成的第一版，它用一两分钟就能生成。它可以同时读很多材料，迅速拆解需求，还能把答案整理成一张很完整的表。
企业真正把它接进业务以后，关注点会慢慢发生变化。
在Demo阶段，偶尔生成一份非常好的答案，已经足够让人兴奋，并感叹与AI的美好。但在长期使用中，更要看它的最差表现会是什么样？
会不会漏掉一条需求？
会不会引用旧版本？
会不会把“可以集成”写成“已经支持”？
会不会在没有证据时仍然给出肯定答案？
我把它概括成一句话：AI 的上限决定企业愿不愿意尝试，AI 的下限决定企业敢不敢真正把业务交给它。
守住下限，不是要求 AI 永远不犯错。
错误要能被发现，影响要能被限制，过程可以回看，AI 处理不了时有人接管，人工纠正以后下一次要发生变化。
所以影子运行阶段非常重要，绝不能看到令人兴奋的Demo后就把全量工作交给 AI 。
在售前数字员工的场景中：
- 先用历史需求回放，检查需求有没有漏拆、引用是不是当前版本、条件支持有没有被写成直接支持。
- 再让真实需求同时进入数字员工和原来的售前流程，两边并行，逐条比较。
- 等主要需求类型都被覆盖，风险项能够稳定停住，专家审核的工作量也降下来，才考虑继续放开。
实际环境中，下一步，每个问题要分清楚到底出在哪里：资料缺失、版本过期、检索没有命中、能力分类错误，还是表达形成了过度承诺。
一次纠正至少应该带来一项变化：补一份知识，改一条规则，增加一个待确认条件，或者留下一个下次必须重新测试的样本。
人的纠偏进入下一轮以后，AI 的能力下限才会一点点抬起来。
五、一条链跑到边界，新的问题会自己出现
标准产品能力可以沿着这条链继续走。但遇到需要集成和定制需求，我们就会看到另一个场景：
研发关心技术上能不能做，会改动什么，影响哪些架构。
销售更关心技术能不能搞定，交付是否可控，客户预算是否能够覆盖。
管理层需要尽可能了解全面的信息，最后决定值不值得投入。
以前开这种会，经常要先花很长时间补背景。研发在解释技术代价，销售在解释客户需求，管理层还在确认大家说的是不是同一件事。讨论还没有进入取舍，会议已经开了很久。
现在公司管理层和研发都开始使用 AI，你会发现，之前的认知差会被快速拉齐。
AI 可以先把客户需求、现有能力、产品缺口、实现路径、技术代价、架构影响和市场价值整理到同一份材料里。每个岗位都可以驱动AI了解自己不擅长的部分：
虽然最终决策仍然由管理层承担，但 AI 在这里提供的是一个共同的决策起点，而且降低了大量人与人的摩擦。笔者之前有一个“暴论”：企业 AI Native 后，人类之间的沟通会降低95%，大量的沟通会发生在数字员工之间。
这也让我看到，第一条业务链不是一个孤立的小工具。它一头连着市场问题，一头连着产品、研发和管理决策。跑到标准能力边界时，系统要知道停下来，把完整现场交给下一组责任人。
六、地图画完以后，先把一条路走通
回头看这一组文章，最早的问题是 AI 应该怎么分工。后来我写了注意力分工，写了任务怎样在 AI 团队里流转，也写了 AI 从 Demo 进入企业以后会遇到的组织权责和工程问题。
上一篇把这些东西放到了一张企业地图上。
这一次，我们终于把其中一条链放进了真实业务。它还在影子运行，还没有完成正式验收，也没有证明一家企业已经完成 AI Native 转型。
但它已经让前面的很多问题变得具体。
知识从哪里来，版本由谁确认；AI 能做到哪一步，哪里必须停；谁负责产品事实，谁负责售前口径；结果怎样验收，错误以后怎样进入下一轮。这些东西放进同一条任务链，AI 才开始进入企业的运行方式。
第一条链跑完，企业最终留下来的也不只是一个数字员工。
它会留下当前有效的产品能力基线，留下可以反复使用的真实测试样本，留下人工审核和异常升级的边界，也留下知识、任务和责任怎样流动的一段真实记录。
这组文章可以先写到这里。
接下来我会沿着实际项目继续往下走。产品资料怎样变成可维护的知识，AI怎么将专家判断的软逻辑沉淀成硬规则，AI 的权限怎样逐步放开，一条链怎样连接到第二条、第三条链。这些问题，需要一个一个思考、实践和沉淀。
桃李春风一杯酒，江湖夜雨十年灯。
让我们一起在不确定的时代中持续摸索，下个系列再见！
粤ICP备14082021号
免费POC，
零成本试错
