从一个售前场景开始：一次组织级 AI 落地项目复盘

过去两个月，我负责了一个公司内部创新业务部门的 AI 落地项目。它表面上是一个“市场扫描助手”：自动采集区域市场数据、生成市场扫描报告、支持业务人员查询报告和关键数据。但如果只把它理解成一个报告生成工具，就低估了这个项目的价值。

它真正解决的是一个售前场景里的核心问题：当前线销售面对大量区域线索时，如何更快判断哪里更值得跟进、以什么切入点跟进、用什么材料支撑客户沟通，以及市场中台如何把分散经验沉淀成可复用的数据资产和决策能力。

项目阶段性交付后，数据库已经覆盖全国 2867 个区县，并形成同量级的市场扫描报告库；前期基于模型与人工判断筛选出的 104 个优先区县，已经支撑业务方做销售团队宣贯和市场协同推进。工具端同时提供飞书机器人和应用入口，一线人员可以直接检索区域报告，也可以查询单个数据字段。业务部门对销售进行了培训，反馈非常积极，认为它切实提高了售前工作效率。后续这个项目也准备被作为公司内部 AI 赋能业务的标杆案例进行宣传。

这篇文章不是项目宣传稿，而是我对这次 AI 落地过程的总结和复盘。它回答几个问题：为什么选择这个组织和场景？我们是如何从 0 到 1 做出来的？过程中遇到了哪些困难？项目真正创造了什么价值？以及下一次做类似项目时，可以沉淀出怎样的方法论。

在传统模式下，区域市场扫描主要依赖市场中台人员人工借助豆包检索、整理、判断和撰写。这个方式在单个项目上可以跑通，但当业务进入全国化拓展阶段，问题就会集中暴露出来。

首先是产能问题。一个区县报告并不只是简单查资料，它需要整合区域经济、学生规模、教育资源、竞品情况、政府公开信息、合作切入点等多类信息。人工可以做深，但很难做广。一旦需要同时评估几十个、几百个甚至上千个区域，人工模式就会变成瓶颈。

其次是标准问题。不同人、不同阶段做市场扫描，关注字段、判断逻辑、报告结构很容易不一致。售前判断一旦过度依赖个人经验，就很难形成统一口径，也难以沉淀为市场中台能力。

第三是质量问题。通用 AI 工具可以辅助写报告，但在这个场景里，单纯让大模型“搜一搜、写一写”并不可靠。它会遇到信息幻觉、数据错配、来源不可追溯、链接失效、字段缺失等问题。尤其当多个维度的数据需要综合评分时，前端一点小偏差，可能会影响后续区域优先级判断。

最后是复用问题。过去每做一次报告，很多信息就停留在一次性材料里。报告写完了，但数据没有系统沉淀；经验形成了，但没有变成规则；判断做出来了，但难以支持后续持续更新和二次分析。

因此，我们真正要解决的不是“能不能自动写一份报告”，而是“能不能形成一套稳定、标准、可复用的售前市场情报生产机制”。

项目早期，我们并没有一上来就决定自研。相反，我们先看了市面上已有的解决方案，也针对火山、阿里等不同产品能力做过尝试和比较。

外部产品的优势很明显：平台成熟、能力完整、上手快，适合通用知识问答、文档生成、数据分析等场景。但当我们把需求放到这个具体业务流程里，就发现很多能力无法完全匹配。

这个场景对 AI 的要求不是写得像不像，而是数据准不准、字段全不全、来源能不能追溯、规则能不能固定、批量能不能稳定、结果能不能被业务人员直接使用。而外部通用方案往往更偏平台能力，难以深度嵌入我们自定义的数据采集规则、校验逻辑、报告模板、批量生成机制和飞书工作流。

更现实的问题是，业务方最终需要的是一个低门槛工具，而不是一个复杂的 AI 运维环境。前期我们尝试让业务方自行使用技能和开发工具生成报告，但在 Windows 电脑、环境配置、命令操作、批量运行等方面都存在门槛。对一线业务人员来说，如果一个 AI 工具需要先学会复杂运维，它就很难真正进入日常工作。

因此，我们逐步调整方向：底层能力由技术侧搭建和运维，业务侧沉淀规则、参与校验、反馈迭代；最终交付给前线的是简单入口，而不是复杂工具。也就是把复杂性留在后台，把确定性和易用性交给业务。

最终，我们选择了自研路径：用脚本和 Skill 定义 AI 的运行逻辑，用标准规则约束数据采集、校验和报告生成，用飞书知识库沉淀数据池和报告库，再通过飞书机器人和应用入口提供查询服务。

这次项目能阶段性跑通，最重要的一点是我们没有把希望寄托在“大模型自己变聪明”上，而是把业务规则拆出来、写清楚、固化到流程里。

第一步是明确字段和采集规则。我们和业务方一起梳理市场扫描需要哪些字段，哪些字段影响优先级评分，哪些字段只是辅助参考，同时，我们对字段采集规则做了详细的梳理。

第二步是建立校验机制。AI 不是采集完数据就直接输出，而是要按照预设规则做字段校验、来源标注和质量判断。我们明确了完整率、准确率等指标的计算方式，把感觉还可以变成可以讨论、可以验收、可以迭代的数据质量标准。

第三步是统一报告框架。市场扫描报告不是散文，也不是 AI 随机发挥的分析文。它需要服务售前动作，所以必须围绕区域基本情况、市场机会、合作切入点、风险提示和建议动作展开。只有报告结构稳定，前线人员才容易横向比较不同区域，管理层也才能基于统一口径判断市场优先级。

第四步是产品化交付。最初的能力更多像一个后台生产工具，后来我们把它进一步封装成报告库和查询助手。业务人员不需要知道后台如何采集、校验、生成，只需要在飞书里搜索区县名称，就能查看对应报告；也可以通过机器人查询某个地区的具体数据。

这一点很关键。AI 落地不是把能力做出来就结束，而是要让业务人员在自己熟悉的工作界面里用起来。

从结果看，这个项目的成效可以分成四层。

第一层是效率提升。以 2867 个区县报告为例，原先如果依赖人工校验和生成，按每份约 2 小时计算，总耗时约 5734 小时（约239天）；引入智能体后，市场中台人员无需再进行报告撰写和校验，可直接供销售团队参考，仅部分高层领导重点关注的市场（约100个），需由人工再进一步复核与深度梳理，按每份约 0.5 小时计算，总耗时约 50 小时，整体效率提升约 99%。

第二层是流程自动化。原流程包括需求受理、数据采集、数据校验、平台验证、报告撰写、报告存档 6 个节点，现所有节点均可以由智能体自动完成，流程自动化率约 100%。这意味着 AI 不只是提升某个动作，而是开始进入业务流程本身。

第三层是决策支持。市场优先级筛选已经用于支撑公司高层和事业部管理层对销售团队的宣贯材料。对售前团队来说，这个工具帮助他们在海量区县中优先识别更具市场价值、付费能力和合作可能性的区域，把有限时间投入到更高概率的线索上。而这套工具，不仅能支持到单个产业公司的售前团队，更可以面向全集团售前团队开放，体现出很强的复用性。对市场中台来说，它沉淀的是一个可持续更新的区域数据库和报告库，而不是一次性材料。

第四层是组织示范。这个项目跑通了业务方共创产品设计与规则梳理、AI 团队搭建能力、流程团队评估价值、前线销售实际使用的协作模式。业务方反馈积极，销售培训后也认为工具切实提高效率。这种反馈比技术指标更重要，因为它说明 AI 不再停留在演示环境，而是进入了真实业务动作。

复盘下来，这个项目能推进到阶段性交付，有几个有利条件非常关键。

第一，业务方是真的想落地。很多 AI 项目失败，并不是因为模型不够强，而是业务方没有真实投入，只是把 AI 团队当成“帮我做个工具”的资源。这次不一样，业务方愿意花时间一起梳理规则、抽查数据、反馈问题、组织培训，也愿意接受在不完美中迭代。

第二，各方目标一致。业务方要提升售前效率，AI 团队要跑通组织级应用，流程团队要验证流程改造价值，管理层希望看到可宣传、可复制的标杆案例。目标一致会显著降低协同成本，因为大家不是在争论“这是谁的事”，而是在共同推动“这件事怎么成”。

第三，场景选得足够具体。市场扫描不是一个泛泛的“AI 赋能销售”，而是售前流程中一个明确、重复、有规则、有数据、有交付物的环节。AI 落地最怕场景太大，边界太虚；这次项目之所以能推进，是因为我们把它切到了一个足够小但价值足够高的切口。

第四，有阶段性成果牵引。前期先做 900 多个区县数据，再筛出 104 个优先区县，再形成报告库，最后扩展到 2867 个区县。每个阶段都有可见成果，也给业务方持续增强信心。

当然，这个项目并不轻松。

第一类挑战是技术路径不确定。早期我们试过不同工具、不同模型、不同产品方案，也和外部供应商方案做过比较。每条路径都有优点，但真正放进业务场景里，就会暴露稳定性、准确性、批量能力、交付门槛等问题。最后选择自研，并不是因为自研天然更好，而是因为这个场景需要更强的规则控制、流程嵌入和交付可控性。

第二类挑战是数据质量。市场扫描涉及公开信息、多源数据和复杂判断，大模型天然存在幻觉和误判风险。我们一开始也遇到业务反馈“数据准确性和完整性一般、存疑”的情况。解决方式不是争论 AI 到底准不准，而是把质量标准明确出来：哪些字段关键、怎么校验、准确率怎么算、什么情况下必须人工兜底。AI 项目越进入业务核心，越不能只讲体验，必须讲验收标准。

第三类挑战是项目管理。刚开始业务要求时间很紧，整体资源也有限，该场景在公司内未有先例，同时多数成员还是第一次跨团队合作 AI 落地项目。大家一开始都不知道最佳协作方式是什么，进度管理、预期管理、沟通节奏、分工边界等都需要边做边磨。这个过程中，阶段性交付非常重要。先交付 MVP，再根据反馈优化，比一开始追求完美方案更现实。

第四类挑战是使用门槛。前期我们希望业务方可以借助开发工具自行生成数据和报告，但实践后发现，对非技术人员来说，工具链太复杂，尤其在公司 Windows 电脑上配置和使用并不友好。这个反馈让我们意识到，组织级 AI 应用必须产品化。真正好的 AI 落地，不是让业务学会技术工具，而是让 AI 能进入业务原有工作流。

我认为这个项目做得比较好的地方有三点。

第一，我们没有陷入为 AI 而 AI。从一开始，项目就绑定了售前拓展、市场优先级、线索判断等业务目标，所以后续每一次技术选择都能回到业务价值上。

第二，我们坚持业务共创。好的 AI 产品不是 AI 团队闭门造出来的，而是和业务方一起定义、验证、修正。业务方越参与，最终工具越贴近真实使用场景，也越容易被接受。

第三，我们把能力做成了资产。2867 份报告、区县数据库、报告库、Skill、查询助手、规则集、更新机制等等，这些都不是一次性交付物，而是可以继续运营的市场中台资产。

做得不够好的地方也很明显。

首先，早期对工具使用门槛估计不足。我们一度高估了业务人员直接使用开发工具和 Skill 的可行性，后来才转向由技术侧统一生成、业务侧通过低门槛入口查询的方式。如果一开始就从最终用户体验倒推，可能会少走一些弯路。

其次，前期数据规则梳理不够系统。很多规则是在问题暴露后逐步补齐的。虽然这符合从 0 到 1 的真实过程，但也说明以后做类似项目，规则集、质量标准和验收口径应当更早前置。

第三，价值评估还需要进入正式运营阶段。目前我们已经能证明效率提升、自动化率、数据质量和使用反馈，但真正的业务价值，比如线索转化率、成单效率、资源投放回报，还需要在后续真实运营中持续追踪。

这次项目之后，我对组织级 AI 落地有了更清晰的判断：AI 项目不是先找模型，而是先找组织、找流程、找价值。

第一步，选组织。判断业务部门是否有真实目标、真实痛点、负责人投入度，以及是否愿意和 AI 团队共创。没有组织准备度，再好的模型也很难落地。

第二步，选场景。一个好场景要同时满足三个条件：业务价值足够大，流程规则足够清晰，后续运营能力可以承接。只满足技术可行但业务价值弱，不值得做；业务价值大但流程完全不可控，也很难短期跑通。

第三步，拆流程。不要直接问 AI 能做什么，而要先拆原流程：谁在什么系统里做什么动作，哪里耗时，哪里出错，哪里重复，哪里断点。只有把流程拆到足够细，才知道 AI 是替代人、辅助人，还是连接断点。

第四步，定技术路径。外部产品、内部平台、自研脚本、智能体、人工运营都只是手段。选择路径时要看成本、质量、稳定性、交付周期、使用门槛和后续运维，而不是迷信某一种技术形态。

第五步，做产品化交付。AI 能力如果只停留在后台脚本，价值会打折。它必须以业务人员能理解、能访问、能反馈的方式交付，最好嵌入他们原有的办公系统和协作流程。

第六步，做运营闭环。AI 上线不是结束，而是数字员工进入试用期。它要有 owner、有更新机制、有反馈入口、有质量标准、有价值评估，也要有后续迭代和退出机制。否则，智能体很容易变成无人管理的工具孤岛。

这次项目给我最大的感受是，AI 落地不是一场技术表演，而是一场组织协作。

模型能力当然重要，但它只是其中一部分。真正决定项目成败的，是业务方有没有强需求，流程有没有被拆清楚，规则有没有被工程化，工具有没有被产品化，价值有没有被衡量，运营有没有人负责。

从一个售前市场扫描场景开始，我们跑通了从组织选择、场景选择、规则共创、技术实现、产品交付到业务使用的完整链路。它还远不是终点，后续还需要继续优化数据更新机制、追踪线索转化效果、扩展到更多销售和市场场景。

但至少这次经历让我更确定一件事：企业 AI 转型最有价值的方向，不是让每个人都拥有一个炫酷工具，而是让组织真正多一种可复制、可管理、可衡量的工作能力。