企业 AI 服务，做过的人怎么交付
切换项目
新手先看
换个词试试，或者去掉一些筛选条件。
企业里助理一多，就要配"管理助理的助理"：发现、运维、审核三个岗位
给企业落地 AI，前期大家关注的是"干业务的助理"。可一旦团队里每周都有新助理上线，问题就变了：谁来发现哪些工作值得智能化？授权过期、权限出错、软件升级导致流程变化，谁来修？团队成员各自搭的新助理，权限和风险谁来审？比较成熟的做法是再配三个"管理型"岗位：发现岗从日常沟通和会议里找值得改造的流程，运维岗定时巡检并修复常见故障，审核岗在新助理上线前检查权限、工具和风险。没有这三个岗位，助理数量越多，负责人越累。
交付前用四问检验系统：拿得走、错得起、停得起、忘得起
很多企业买了不少系统，演示时样样都好，用起来处处别扭，最后还是回到表格。交付前可以用四个问题自查：拿得走，数据和资料能不能完整导出，换工具、换人不被锁死；错得起，录错、判断错了能不能发现和撤回；停得起，系统停了一天，业务能不能用替代方式继续；忘得起，员工隔一段时间不用，回来还会不会用。四问都过，系统才真的有利于别人使用。
给企业搭知识库分三步：按业务流转排目录、每格放齐三样、再整体梳理一遍
企业知识库最常见的失败，是建成了一个更整齐的收藏夹：文件很多，新人不知道先看哪个，AI 也分不清哪份算数。完成标准要定得具体：一个新人或一个 AI 能拿着它办完一件真实的工作，才算建成。搭建分三步：先按"一单业务从进来到结束"的顺序搭目录，固定一个收件箱和一个隔离区；再从公开内容、团队资料、员工访谈三个渠道采集，每个目录先放齐现行规则、一个脱敏的真实例子、一份系统记录；最后整体梳理，写入职手册、分清事实和判断、统一命名、去掉重叠。
最小工作台：选一个岗位，连续试跑一周，用三个数决定要不要扩
企业用 AI，常见的误区是一开始就想搭很多助理、接很多系统。更稳的做法是先选一个固定的业务岗位，比如选题、素材拆解、售前方案初稿、交付资料包，搭一个最小工作台：输入、AI 草案、人工验收标准、输出物，四段接起来。连续试跑几天，只记三个数：可用产出有多少、人工纠错花多长时间、产出能不能直接对外报价或交付。跑得通再扩人、扩助理、扩场景；跑不通先别堆模型。检验提效看的是整段流程少返工，不是初稿写得快。
做企业 AI 服务，先想清楚卖的是哪一件事
找不到客户、不会报价、交付越做越累，看起来是三个问题，根源往往是同一个：你卖的是"AI 企业服务"这个大词，而不是一件具体的事。把服务收窄到一个人群加一个场景，获客、报价、交付才都有了抓手。
SOW 是小团队的护身符：交付什么、不做什么、甲方要备好什么
企业 AI 项目做到一半卡住，原因常常不在技术，而在客户没提供资料、权限或负责人。客户却容易认为"你答应交付结果，卡点都该你免费解决"。所以开工前必须有一份工作范围说明（SOW），写清交付内容、明确不做的事、甲方前置依赖、阶段节点、测试与验收标准、变更方式和售后边界。大项目写进合同，小项目至少在文档或聊天记录里确认。
交付的三个标准：放进真实工作能稳定跑、员工不用学、以后有人能改
给企业做 AI 交付，演示时客户觉得惊艳，真正进了公司却用不起来，是这一行最常见的落差。可以用三个标准检查自己的交付：高可用——放进真实工作后大部分情况能稳定完成，遇到异常也知道下一步怎么办；低学习门槛——员工不用记一堆新操作，最好不用专门培训；高适配度——业务变了，企业里有人或有机制能跟着更新。这三条都需要你亲自跟进客户的使用，自己操作顺不代表客户顺。
企业 AI 服务在做什么：让 AI 接住原本只能本人做的工作
很多企业主和专家已经在用 AI，但涉及分析、取舍、给建议的工作，AI 的结果"差点意思"，最后还得本人重做。企业 AI 服务要解决的，是把专家没写进资料、自己也说不清的判断采集出来，再搭一套信息流转机制，让 AI 结合判断标准和每天变化的业务一起工作。
第一版交付之后，真正的交付才开始
AI 编程让范围清楚的需求可以在几天内做出初版，但这只是初版，客户开始用才会暴露大量之前看不到的问题，初版之后的修改几乎必然比初版本身更花时间。交付前要做好预期管理：说明第一版覆盖哪些场景、哪些可以用于正式业务、哪些暂时不要。测试要关注边角情况，用助理模拟用户能发现问题但不能当作验收证据。交付后没有反馈不等于没问题，可能是根本没用上，要请负责人拿当天的真实工作让员工试一遍。
别在旧流程上加 AI：让 AI 重组流程，人负责提问和判断
很多团队用 AI 越用越累，原因是旧流程一点没变，只是在中间某个环节塞进一个 AI 工具。线程一多，人就被大量衔接和判断压垮。更有效的做法是：把目标、意图、判断标准和样本完整交给 AI，让它重新组织流程，人退到两个关键位置——提出好问题、做方向判断。给企业做落地时，先帮客户画出"如果从零设计会怎么做"，而不是只问"哪一步可以用 AI 替代"。
按效果收费之前，先把"原来的样子"锁定下来
按效果付费听起来对双方都公平，但有一个前提：改善前的基准必须事先确认。一个常见的坑是，前期沟通时客户说某项工作原来要两个小时，谈到按效果结算时又说熟练员工十几分钟就能做完——基准一变，你能证明的改善空间就天差地别。所以在约定效果付费之前，要把原来是谁在做、什么样的任务、包含哪些步骤、多少资料、实际耗时多少都记录下来，最好有可核对的记录，双方书面确认。
一个大名词代替不了交付内容：数字孪生、知识库、智能体都要拆到具体
客户提出"想做数字孪生""要一个企业知识库""搭一套智能体"，名称可以说得很大，但开发和验收需要具体内容：展示什么、接哪些数据、解决谁的什么问题、做到什么程度算完成。这些没有确定，项目就无法估算；你投入时间调研，客户又不断冒出新想法，双方很难对齐，最后你觉得花了很多时间，客户觉得没看到想要的东西。遇到大名词，要么拆到具体能验收的内容，要么明确说这不在你当前的服务范围。
AI 改造是一把手工程：只培训员工，往往只能拿到局部优化
企业做 AI 落地，常见做法是给员工安排培训，让各部门自己想办法提效。结果往往是每个人在自己岗位上优化一点，整体变化有限。原因是员工站在自己部门的角度，只能看到局部；老板看到的是全局流程，才可能发现某些流程应该整个去掉、重新设计。给企业做服务时，要争取老板或一把手亲自参与：至少参与一次需求访谈、看一次 Demo、定一次优先级。老板不下场的项目，推进难度会大很多。
和老板聊需求：找痛点、算清账、描述结果
直接问"你有什么 AI 需求"，多数老板答不上来。更有效的聊法是四步：问出最耗人力、最容易出错的环节；把改进换算成老板能理解的时间和成本；点到为止地说说同行在怎么做；帮他把三个月后的变化描述出来，这个描述就是之后的交付标准。尽量和有决策权的人谈。
员工讲不清和不愿讲，要分开处理
梳理流程时，经常遇到两种情况：员工愿意讲但讲不清楚——他每天都在做，已经成了习惯，不会把每个小动作当成值得解释的信息；员工不愿意讲——担心工作被替代，或者觉得你在审计他。前者可以请他用最近一次真实任务演示一遍，在征得同意后录屏辅助整理，观察他在哪停顿、去哪查资料、什么时候问同事。后者先别把他当成障碍，先帮他解决一个烦了很久的小问题，让他感受到合作对自己的好处。
需求变了怎么办：预算、周期、范围，至少要动一个
真实项目一定会有变化：试点没验证到的问题在正式开发时暴露，某个环节被低估，某个需求发现做不了。处理原则是：预算不加、周期不变、范围还扩大，这样一定交付不出来。可以把变更分成三类：客户新增需求，加预算或删减原范围；乙方低估难度，说明原因、重新协商周期和方案；前置条件不成立，由甲方补条件或暂停对应范围。不要用沉默和加班掩盖变化。
客户说数字化做得不错，也要看真实材料
客户说"我们数据都在系统里""流程很成熟"，不能直接当真。系统多不等于数据能直接用：同一个字段在不同表里叫法不同，有些记录只在个人电脑里，有些流程看起来在线上、关键决定却靠口头交代。估工作量之前，要请客户拿出最近的真实记录，带着你走一遍；走到某个节点他说"这次情况特殊，要去问另一个人"，就说明这里有没写明白的逻辑。看过真实材料再报价，能避免很多后期返工。
报价前对照六类成本：别只算写代码那几天
AI 编程让初版开发很快，很多人就按写代码的几天来报价，结果项目做完发现没赚钱。一个项目的真实投入至少包括六类：获客和项目管理、产品与流程梳理、技术实现、测试与调整、培训与维护、外部支出（差旅、工具、模型、服务器、第三方采购）。报价前逐项对照，看有没有漏掉；模型和服务器这类随用量变化的费用，最好让客户自己开账号按账单付；上线需要的域名、备案、认证等手续，尽早确认由谁准备。
用 Demo 代替评审会：先做出能看的雏形，再和客户讨论
一个抽象想法，在每个人脑子里可能是十种样子。开会讨论半天，往往各说各话。AI 让做雏形的成本降到很低，更高效的协作方式是：有想法就先做出一个能看、能点的 Demo，拿着它讨论。Demo 一出来，大家立刻知道"是这样，不是那样"。给企业做服务时，第一次沟通后尽快拿出 Demo，比写长篇方案更容易对齐需求，也更容易让对方决策。注意 Demo 只是对齐工具，要说明它和正式交付的差距。
高风险场景：AI 整理资料、写初稿，专业人员做最终判断
在医疗、法律、人事这类专业场景里，AI 能帮很大的忙：从大量资料里提取信息、按内容分类、生成初稿，把专业人员原本要花几个小时的整理工作，压缩到只需审核修改。但最终判断必须留给专业人员。原因很简单：一次不恰当的结论可能影响客户关系甚至造成风险，损失远超一次模型调用的费用。设计方案时要把人工审核放在发出去之前，同时考虑出错时能否识别、谁来复核、用户有没有机会在发出前发现问题。
第一单从你熟悉的行业开始：先给自己做一个小工具
新人最常问的是"客户在哪里"。一个省时间的答案是：从你工作过、熟悉的行业开始，而且范围要小——不是整个行业，而是某个平台、某个品类、某个岗位。你已经知道这里的人每天在处理什么、被什么事耽误，外行要问很多轮才能知道的东西你已经有答案。先给自己做一个解决具体麻烦的小工具，自己用顺了，拿给同事和同行试，有人愿意继续用，再决定做成软件、定制服务还是培训。
初版被差评、一个月收到上百条反馈：先分类，再决定改什么
第一版交付后被客户直接说"不好用"，一个月内收到一两百条反馈，在专业场景里并不少见。专业人员往往在开发前说不清所有要求，看到结果才会指出问题。关键是别把所有反馈都理解成"再加一个按钮"，要先分类：原来没说清的规则、操作不方便、使用后才发现的异常、真正的新需求。反复出现的同一类问题，说明前面的流程理解有偏差，要回到 SOP 去改；表述误解只需调整交互；新需求进需求池排优先级。
按后续用途拆字段，别只给一段长摘要
处理公告、合同、报告这类长文档时，很多方案的做法是让模型生成一段摘要，看起来已经节省了阅读时间。但如果后面要筛选、比较、排序、提醒，一段摘要就不够用了，还得有人再读一遍。更好的做法是先问清楚用户按什么条件做决定，再把对应的信息提取成明确的字段：日期分清是报名截止还是开标、金额单独一列、资格要求逐条列出。字段定义要和业务方一起确认，同一份材料里出现多个日期时，要知道每个日期对应什么事。
先找出哪些工作值得智能化：从日常沟通、会议和文档流转里挑候选
企业里能交给 AI 的工作很多，但不是每件都值得做。比较实用的方法是先系统地收集候选：从团队日常的沟通、会议纪要、文档流转里，找出重复出现、耗时、规则相对清楚的工作；再按频率、耗时、风险、数据是否可得四项打分排序；最后从得分最高、风险最低的那一件开始。收集候选的工作本身也可以交给助理做，但只能在客户授权的范围内读取信息。
免费试做做到哪就该停：Demo 是敲门砖，不是无限修改
面对还没有案例的行业或较大的客户，先做一个小范围的 Demo 让对方判断可行性，是常见也有效的做法，可以免费，也可以约定签约后计入项目费用。但 Demo 的目的是验证合作意愿，不是把整个系统交出去。如果已经做了好几轮免费修改，客户仍然不愿提供资料、不确认下一步、一谈费用就回避，就该停下来想想：你是在验证合作，还是在替一个没有计划的人反复试验？给 Demo 设好范围和截止点。
熟人客户更要把规则讲清楚：信任能让合作开始，但替代不了约定
熟人、前同事、老客户是很好的第一单来源，对方愿意基于对你这个人的信任给一次机会，哪怕还没完全弄懂你会怎么做。但关系越熟，越容易不好意思谈细节：范围、费用、验收、付款节点都没写清楚就开工了。做着做着双方理解出现偏差，钱的问题和关系的问题搅在一起，反而伤感情。熟人合作要和陌生客户一样，把需求、范围、费用和验收写下来，这不是不信任，而是保护这段关系。
客户说"想做个智能体""要个知识库"时，先回溯到具体工作
很多客户是看过某个 AI 演示后来找你的，开口就是"想做个智能体""要一个知识库""想做短视频"。这可能是一个方向，也可能只是他最近看到的东西。不要直接按这个功能名去做，要继续问：准备让谁用、在哪个工作里用、原来的办法有什么问题、做出来希望发生什么变化。几轮聊下来，常常会发现他真正着急的事跟最开始说的功能差得很远，最后需要的可能主要是自动化，AI 只参与其中一个环节。
AI 结果不可靠，多半是问题没讲清楚：边界、标准、上下文、授权四项自查
企业客户常说"AI 有幻觉，不敢用"。在普通业务场景里，大多数时候不是模型碰到了能力边界，而是使用者没有把问题讲清楚：边界在哪、什么算好、背景资料是否充分、授权是否到位。AI 是人的能力放大器，问题定义越清楚，结果越可靠。交付前用四项自查过一遍，再加一条底线：高风险决策必须由人兜底。
在客户公司里培养一个"内部小 FDE"
交付后，客户公司里如果有人能理解业务问题、整理需要的材料、自己做一些小改进，整个合作会顺很多，系统也能跟着业务持续更新。给客户装好工具后，往往能看出几类人：有的主动研究、很快做出小尝试，有的看过演示才跟着做，有的暂时没行动。对主动探索的人多给支持，让他逐渐承担部门里的小开发任务。判断标准不能只看使用量，还要看他做出了什么、有没有认真吸收。教会客户不会让你失业，反而能让你把精力放在更有价值的事上。
知识库建好后的二次梳理：入职手册、可信度排序和"待确认"文件夹
资料放进知识库以后，还要整体梳理一遍，这一步决定了好不好用。四条原则：给 AI 写一份入职手册放在最外层，写清为谁工作、每个目录做什么、哪些红线不能碰、哪些事必须先问人；分清事实和判断，按后台数据、会议确认的结论、策略文档、复盘、提案的顺序排可信度，提案里的预计数字不能当事实；AI 新得出的结论先放进"待确认"文件夹，人确认后才转正；目录和文件名用业务员听得懂的话，同一件事只留一个说法。
交付太重就做不大：三种让交付变轻的办法
代运营、深度定制这类重交付能赚钱，但会把你的时间锁死：账号杂事、平台规则变化、客户的例会和汇报，每加一个客户都要多一份人力。想让一个人服务更多客户，要做三件事：谈单用分享代替一对一，产品锁定一两个场景让交付可复用，用合作分账代替招人。
不需要培训的产品才是好产品：让工具顺着员工的工作走
企业软件每多一点学习成本，都可能变成推广的阻力。很多公司买了功能强大的系统，员工最后只用其中一两个功能。设计交付时要尽量贴近员工现有习惯：能自动带出的信息不让人反复填，结果送到员工常用的沟通渠道，做完后清楚显示成功了多少、还有哪里要处理。流程内部可以很复杂，用户不需要感知。自己测试时留意：操作时是需要不断回忆上一步，还是顺着就能做下去？
现场调研：还原真实流程，先查资料能不能信
和老板谈，通常只能谈清预算和由谁来做；真正的交付边界，要到现场跟实际干活的人逐一聊。访谈不问"想要什么功能"，而是还原流程：谁在什么时候收到什么、打开哪个系统、根据什么判断、遇到例外找谁、结果写到哪里。还要特别核查原始资料：AI 会非常准确地复述一份错误资料，很多真正的规则只存在于老员工的脑子里。
一人公司不是单干：按项目分工，按贡献分账
一人公司的重点是"公司"而不是"一个人"：有分工、有上下游、有合作伙伴。接到项目先拆开：哪些自己做、哪些交给 AI、哪些交给伙伴。伙伴之间按项目结算，不靠工资维系；合同要签，但真正稳定的合作来自持续筛选和清楚的分账机制。
技术上能做，不等于权限给得了：方案要按客户的真实条件调整
设计方案时，最理想的往往是直接通过系统接口读写数据，快且稳。但现实中，对方系统的管理方可能对开放权限很谨慎，尤其在合作还处于前期验证阶段时，不会因为一方觉得方便就给出很大的访问权限。这时要按真实条件调整方案：比如先把数据导出到本地比对、找出需要修改的部分，再回到线上更新。效果可能不是最理想的，但只要客户有明显的体感，就足以推进下一步合作。
选客户比选技术更重要：优先接什么样的单，哪些单要拒绝
客户选错了，技术越强，损失可能越大。优先考虑：企业仍在增长、决策人真想做、有业务负责人、能接触真实流程和资料、有人能确认结果、第一阶段能在几周内验证。要警惕的是：经营下滑的企业（预算缩减、回款风险）、没人负责资料和验收、只说"全公司 AI 化"却说不清第一批用户的项目。知道什么不做，本身就是交付能力的一部分。
报价看客群、痛点和案例，不看同行
企业 AI 服务没有统一标价，同一个工作流在不同人手里价格可以差出很多倍。真正决定价格的是三件事：客群（他自己能不能搞定、会不会比价）、痛点（解决的问题离收入有多近）、案例和背书（有没有同行业的成功经验）。没有案例时先从低往上报，把第一单做成案例。
三种报价方式：固定范围、按效果、组合，各自要先确认什么
企业 AI 服务没有一张能套所有客户的价格表，常见的报价方式有三种。固定范围报价——先讲清内容、交付物和验收方式再给价，适合需求清楚的项目，前期调研量大时可以把调研和开发分开报。按效果付费——达到约定指标收对应费用，前提是基准、归因和结算口径能确认。组合报价——启动费、阶段费用和效果分成放在一起，前面的钱保障投入，后面的钱和效果挂钩。新手能把第一笔固定费用、第一阶段范围和验收讲清楚，已经是很重要的一步。
程序、自动化、模型、人工：一个流程里各放在哪
流程梳理清楚以后，要决定每一步由谁来做。规则明确、能固定下来的部分（按编号匹配、比较字段、到期提醒）优先写成程序，稳定且成本低；系统没有合适接口、但人能在页面上操作的，再评估界面自动化，并考虑页面变化和登录失效；资料格式不一、需要理解文字、识别图片或生成内容的地方，才用模型；高风险判断和异常处理，要有明确的人工负责人。别硬上 AI，原本几毫秒能完成的确定性处理改成让模型思考，只会多出等待、费用和出错的概率。
老板自己用 AI 编程工具写系统了，还需要我们吗？
需要，但角色会变。AI 编程工具很适合让业务人员把脑子里的流程快速做成演示版本，大幅降低沟通成本；但长期运行的系统仍然需要工程结构、模块认知、测试和维护责任，否则模块一多，改一个问题带出新问题，最后说不清谁对什么负责。可以把老板做的演示当成最好的需求文档，你负责把它变成能长期稳定运行、可验收的系统。
访谈时老板说的流程和一线说的不一样，知识库写哪个？
写一线实际在跑的那一个。老板描述的往往是他希望的流程，一线员工说的才是每天真实发生的流程。知识库和技能要能在真实工作里跑起来，就必须以实际流程为准。但两者的差异本身很有价值：要整理出来交给老板确认，哪些是一线的变通需要正式认可，哪些是偏离了规则需要纠正。确认后的版本写进知识库，没确认的放进"还没定的事"隔离区，不要让 AI 读到两套说法。
学了很多 AI 工具和智能体，还没接到一单，问题出在哪？
常见原因是一直在学工具，没有做过一次真实的生意验证。工具会过时，验证需求的能力不会。建议停下来做一个小实验：选一个具体行业、一个具体岗位，做出一份能看的结果，找几个真实客户聊，看有没有人愿意付钱。有人买单再完善工具和流程；没人买单，换方向再验证，而不是继续买课、继续堆工具。
客户想要一个看起来很高级的工作台界面，要先做吗？
可以有，但建议后做。工作台本质上是一套可视化的操作界面，把流程摆到眼前、点着就能用，它本身不生产内容。真正干活的是知识库和技能，再加上员工手里的 AI 助手。工作台的价值在于让流程看得见、降低不熟悉 AI 的同事和想一眼看结论的老板的上手门槛。但它好不好，取决于底下的知识库：数据没有覆盖到的地方，界面做得再高级，也只是把猜测装修成事实。先把知识库和技能跑顺，再决定要不要做界面。
AI 初稿出得很快，但改起来很费时间，这算提效吗？
不一定。提效要看整段流程：从拿到需求到产出能直接用的结果，总共花了多少时间、返工几次。如果初稿快了但人工修改的时间更长，整体没有提效。常见原因是输入资料不全、指令每次临时写、没有写清楚验收标准。先把这三处补上，再判断。
没有案例，第一单怎么谈？
两条路：一是先找规模小、方向接近的客户，低价甚至免费做一个完整案例；二是用你原有的行业经验做背书，服务你熟悉的行业。做完要把过程、结果和客户反馈整理好，这就是下一单的敲门砖。
企业用 AI，一定要本地部署模型吗？
不一定。见过不少企业花钱买了设备、部署了本地模型，结果因为速度和效果不理想，实际很少用。是否本地部署，要看客户需要什么能力、用量多大、现有硬件和维护能力如何、能接受怎样的效果和费用，以及数据敏感程度、合同约定和权限要求。模型放到本地以后，更新和维护的工作量不小。不要在没了解需求时就先推荐企业买设备；敏感资料也不能不经评估就直接交给外部服务。先问清楚需求，再比较本地和云端。
担心交付的方法和文档被客户学走，以后不需要我了，怎么办？
企业 AI 服务真正的价值，不在一份可复制的文档，而在两种需要长期实践才能获得的能力：AI 技术能力（做过很多助理和产品积累的判断）和行业认知能力（服务过足够多客户形成的经验）。文档可以被拿走，这两种能力拿不走。与其防着客户，不如把交付做扎实，让客户愿意继续合作；同时把每一单的经验沉淀下来，让自己越做越快。
企业老系统没有接口，要不要想办法硬接？
一般不建议。没有开放接口的旧系统，强行绕过去做自动读写，稳定性差、出了问题难修，还可能带来数据和权限风险，最后责任落在交付方身上。更稳的做法是：把这部分写进 SOW 的"明确不做"；评估能否用导出导入、人工录入或半自动的方式先把结果交出来；等客户系统升级、开放接口后再做下一期。企业买的是可靠结果，不是证明所有环节都能自动化。
想做企业 AI 服务，要不要先辞职全职做？
不建议一开始就辞职。第一单从哪来、后面还有没有客户、交付要花多久、一单最后能留下多少，这些都没验证的时候，收入会很不稳定。更稳妥的路径是：利用现有的行业经验，在业余时间从熟悉的场景尝试；拿到第一笔钱后先别急着扩大投入，算清楚这笔钱背后花了多少时间、还有多少售后没做完；等有了稳定的客户来源和可复用的方法，再考虑全职。起步方式按自己的经济条件选，不要为了一个身份把生活压力拉得很高。
客户已经买了好几套系统都没用起来，还要再给他做一个吗？
先别急着做新的。先弄清楚旧系统为什么没用起来：是不贴合实际流程、操作太复杂、数据录入太累，还是没人负责推动。很多时候更好的方案是把已有、还能用的系统配合起来，在缺口处补一个小工具，而不是再上一套大系统。如果原因不解决，新系统大概率会重复同样的结局。
给企业搭助理，工具要不要统一？个人好用的工具适合团队吗？
团队落地建议统一工具栈。每个人用不同工具，助理之间很难协作，经验也没法共享。选工具时优先考虑客户已经在用的协作软件，让原有工作环境长出 AI 能力，而不是额外增加一个系统。个人知识库类工具适合个人沉淀，但团队最重要的是协作，要选分享和共同编辑方便的平台。工具组合尽量收敛到三类：开发和维护助理的主力工作台、让助理持续运行的框架、承载文档和消息的协作平台。
要不要让客户先自己试用？
不建议直接丢给客户自己试。很多老板不熟悉 AI 工具，点几下没搞定，就会得出"不好用"的结论。更好的方式是你来演示：你操作、他看，只展示最核心的几个价值点；确认方向后再做一个小范围试点，带着他用。
老板认可，中层不配合，项目推不动怎么办？
这是企业 AI 项目常见的阻力。部分中层担心 AI 会削弱自己部门的作用，或者增加额外工作。应对方法是：立项时请老板明确负责人和目标；把中层拉进需求和验收环节，让他成为项目的受益者；先从他们最头疼的重复工作切入。
提不同意见要有依据：AI 生成的方案，发出去之前自己先看懂
用 AI 帮忙整理方案、写报价思路很正常，但发给客户之前，你必须自己看懂每一部分。一个自己都解释不了的地方，就不该发出去——客户找的是能负责的人，不是让他替你检查一份你没读过的材料。同样，对客户的想法提不同意见时要有依据：自己没理解业务，只拿 AI 生成的建议去反驳一个做了多年的行业老手，很容易被听出来。不熟悉的问题，可以说"我需要回去看数据、做测试再给您答复"。
做完一单，别让下一单从空白开始：每个项目要沉淀的十样东西
小团队如果每一单都从空白文档、空白代码和空白判断开始，很快会被交付拖垮。每个项目结束后，至少沉淀：客户初筛问题、现场访谈清单、流程还原模板、报价成本项、SOW 模板、常见前置依赖、测试用例结构、上线与交接清单、需求变更记录、经允许后可匿名公开的案例。项目里遇到的问题和形成的方法，会变成下一次交付的底座，也可能变成下一个项目。
岗位技能的三个关键设计：写清不能做什么、定好交接、用真实好例子代替形容词
给企业的岗位做技能，最常见的坑是做一个什么都能问的"万能专家"，它只能给出平均水平的回答。要按业务环节拆，一个环节一个技能。值得做成技能的经验有三个条件：重复三次以上、需要动脑、结果能检查。做的时候三个设计最关键：写清楚不能做什么，比如没有现行价目表就不报金额；定好交接要带的信息，对方确认接了才算交出去；用几条老员工真实做得好的例子定标准，不用"专业亲切"这类形容词。这三条本质上都是管理问题。
首个场景先过五项检查：高频、资料可得、规则清楚、有人配合、结果可判断
和客户聊下来往往有十几个候选场景，第一个做哪个直接影响后面的合作顺不顺。可以用五项检查来筛：高频——反复发生，改善后有持续用途；资料可得——能拿到真实样本，知道数据缺在哪；规则相对清楚——至少能说清第一版要处理的情况；有人配合——负责人愿意提供信息、安排试用和反馈；结果容易判断——双方能用同一种方式看有没有改善。现实中很少五项都完美，关键是知道缺在哪、准备怎么补。
第一个场景去哪找：重复多的、出错贵的、走一个人就断的
见到老板，很容易从培训聊到智能体再聊到全公司改造，聊完大家都很兴奋，下一步却不清楚。更好的做法是先找一个具体场景，可以从三个方向找：高重复的工作——每天都在做、占用不少人时间；高犯错成本的工作——一旦出错会影响客户、付款、重要日期或企业风险；高人员流失成本的工作——一个人离开新人就很难接手。三个方向最后都要落到具体动作上，说不清发生在哪里的问题，后面也很难判断有没有改善。
半标准、半定制：通用技能加客户自己的知识库，让下一单更快
企业 AI 服务做着做着容易变成外包：每一单都从零开始，收入只能跟着单量慢慢涨。产品化要解决的是下一单能不能更快、更便宜。一个可行的结构是半标准、半定制：目录骨架、通用技能和验收方式是标准的，客户自己的资料和按岗位做的调整是定制的。同一个策划技能，接上不同行业的知识库，就懂不同的业务。交付内容可以固定成四样：一个能用的知识库、按岗位定制的技能、两份使用和更新的 SOP、第一个月就能用上的一批成品物料。
第一个客户从哪里来：用一场小分享代替一对一推销
企业客户，尤其是实体企业和品牌，大多在线下建立信任。与其一对一上门推销、一下午聊不出结果，不如组织一场小型分享：一次面对一群潜在客户，你的身份从销售变成老师，客户会主动来问。分享主题就是筛选器，讲什么题目，就来什么样的客户。
SOP 要写到新手拿来就能执行：每一步拿什么、怎么判断、交给谁
AI 编程很快，很多人想尽早开始开发，跳过了流程梳理。但要让程序替人做事，先得把人到底怎样做这件事搞清楚。"收集资料、分析、输出结果"这种描述远远不够，每一步要写清：拿什么资料、从哪拿、按什么条件判断、哪些条件可以一票否决、哪些只是参考、结果交给谁、遇到不正常的情况怎么处理。能量化的明确标准，靠经验判断的就挖例子。一份没经过业务核对的 SOP，再完整也只是看起来完整。
测试集要在交付前设计：别用"我试了几次感觉不错"去验收
企业 AI 项目最后要验收，验收靠的是测试集，不是演示效果。做法和传统软件测试类似：每个需求点设计正向、反向和边界用例；乙方自测集交给客户确认有没有遗漏；客户可以保留一套不公开的验收集。有标准答案的问题自动判对错，开放问题由业务人员评价。更换模型、提示词或知识版本后，都要重新跑一遍。
一个人戴三顶帽子：业务负责人、方案设计者、交付工程师
做企业 AI 服务，一个人往往要同时承担三类工作：业务负责人（相当于项目经理加销售，负责听懂业务、推进合作、收款）、方案设计者（相当于产品经理加 AI 工程师，决定哪里用模型、哪里用程序、哪里必须人确认）、交付工程师（相当于程序员加测试，把方案做出来、测好、改好）。AI 编程让技术工作变轻了，但三类工作始终交织在一起。知道自己哪顶帽子戴得不稳，就找人补上。
客户给的评分权重也要校验：分数两极分化就该回头调
做筛选、排序类的系统时，客户通常会给一版评分规则和权重。按这版规则跑出来，经常出现分数两极分化：一部分很高、一部分很低，中间缺乏区分，员工看着分数也不知道该优先看哪个。这时不能抱着"客户怎么给我就怎么做"的心态，要把运行结果拿给业务方一起讨论：哪些分得不合理、哪项权重要调整、某个硬性条件是否应该先筛掉而不是在总分里扣分。调整由业务方确认，你负责把问题呈现出来。
采集全景图：业务、客户、本人三类信息，本人信息分"底子"和"打法"
要让 AI 接手专家的工作，先明确要给它哪些信息。业务信息和客户信息靠资料加采访基本能拿到；真正要花时间的是本人信息：他的思维与表达习惯（底子），以及每项工作的信号、流程节奏、决策规则、分型、复盘（打法）。
第一次业务采访：先了解人和事，再找缺口
服务开始时做两件事：用一份才干或性格测评对客户建立初步认知，用一次业务采访梳理他的业务版图和最想交给 AI 的工作。采访提纲让 AI 结合行业情况、前期沟通记录和测评结果来准备，既不暴露外行，也不让客户重复讲已经说过的事。
说不清的判断怎么采：比较淘汰、改变条件、评价意见、动手修改
有些判断靠回忆和解释说不清楚，比如"几个目标都重要"但冲突时优先保哪个。可以给客户一个具体任务，从他的选择和修改里采集：让他在几个方案里选和排除、一次改变一个条件看判断变不变、评价另一种合理意见、直接修改一段草稿。
收发室与外脑：给客户搭一个 AI 能调用的外置大脑
采集的内容散在对话、录音和文件里，要整理成 AI 能用的依据。准备两个文件夹：收发室用来随手投放新资料，外脑用来长期保存。外脑里保留原始素材层，再按用途分成系统规则、关于本人、关于客户、关于业务、工具库、持续生长六层。
信息流转：让 AI 跟上每天变化的真实业务
外脑建好后，业务每天在变。信息流转分四个环节：接收（固定入口，客户不用先整理）、处理（给重要信息写上依据、范围、状态、时间、重查条件，区分补充替代冲突，标出受影响的工作）、调用（围绕具体任务找当前适用的信息）、写回（保存产出、更新进展、提炼会影响后续的反馈）。
不懂技术，能做企业 AI 服务吗？
能。这类服务的核心能力是拆解业务、追问和对行业的理解，而不是写代码。做过老师、顾问、销售、管理、内容的人，往往更擅长把客户说不清的判断采出来。但你需要先让 AI 在自己的工作里跑通，才能给别人做。
回放真实工作：从一次具体选择里，采出判断依据
直接问专家"你是怎么判断的"，大多数人只能讲出空泛的原则。更好的方法是挑他最近一两周做过的一次重要判断，让 AI 先还原背景、再聚焦一个关键选择逐个追问、遇到"凭经验""不合适"这类模糊回答继续拆到具体依据。
从一件事开始，带着客户一起搭，边界先写清楚
企业 AI 服务不要一上来就承诺"整体转型"。从客户最烦、最依赖本人判断的一件事开始，在他自己的电脑和账号上，带着他一起搭；哪些事 AI 自己做、哪些必须先问人，开工前写下来；先收定金，按天或按项目报价。
核对采集结果：这条判断怎么来的、在什么条件下成立
一段对话聊得深入，不代表已经准确理解了客户。核对时看三件事：这条判断是客户主动说的还是被 AI 引导出来的；放回真实工作里是否成立、有没有遗漏条件；最后分成已有依据、需要调整、仍待确认三类，保留来源和适用条件。