面向 100 名员工、其中大多数没有技术背景的公司做 AI 落地，真正决定成败的往往不是模型参数，而是你如何定义场景、控制权限和处理反馈。这类问题在 HN 上经常出现，能落地的回答大多有一个共同特征：先小范围试点，再逐步扩大，而不是一上来就全员开通。很多人把精力放在“选最强模型”上，结果两周后只有少数几个固定场景还在被使用，剩下的人早就退回原来的工作方式。
我更愿意把它看作一次内部产品上线，而不是一次技术升级。你需要先回答三个问题：给谁用、解决什么任务、怎么判断有效。下面按一家 100 人左右、非技术员工占多数的公司来拆解整个落地过程，从场景筛选、技术选型、权限控制，到试点、培训、运维和推广节奏，全部按可执行顺序展开。
1. 先定义“有效”：100 人公司的 AI 落地到底在解决什么问题
1.1 大多数真实场景绕不开这三类
非技术员工不会因为“AI 很强大”而主动使用，他们只会因为“这个活确实被省下来了”而持续打开。在 100 人规模的公司里，真正高频、可复制的场景通常只有三类：
第一类是写作与沟通：邮件草稿、周报、公告、报价说明、客服话术、群通知。这类任务不需要精确数据，也不会因为一次表述不准确造成不可逆损失，非常适合先上。
第二类是信息整理：会议纪要、资料摘要、表格清洗、竞品信息汇总、长文提炼。员工最烦的不是写不出来，而是要把一堆聊天记录、会议录音、市场材料手动整理成结构化内容，AI 在这里的价值非常直观。
第三类是重复任务自动化：从模板生成合同初稿、从聊天记录提取待办、定时汇总销售数据、自动打标签。这类场景更接近 AI Agent 的范畴，但要注意，100 人公司通常没有足够工程师去维护复杂流程，所以第一批不要碰太重的自动化，先把单点任务做稳。
1.2 用一张用例清单代替“大家要多用 AI”
在部署之前，别急着买账号，也别急着开会。先让每个部门负责人填一张用例清单。这个方法看起来土，但比任何宣传都有用。
用例清单不需要太复杂，包含五列就能开始：
| 部门 | 具体任务 | 当前每周耗时 | 输入是什么 | 期望输出 |
|---|---|---|---|---|
| 客服 | 把聊天记录按问题类型分类并打标签 | 6 小时 | 在线聊天原始记录 | 分类汇总表，附原文证据 |
| 销售 | 根据会议记录生成跟进邮件初稿 | 4 小时 | 会议录音转写文本 | 三封不同语气的邮件草稿 |
| 行政 | 把公司通知改写成简短公告 | 2 小时 | 原始通知文本 | 不同平台版本，如群聊、邮件 |
| 市场 | 汇总本周竞品动态 | 5 小时 | 竞品公众号文章、新闻链接 | 按时间排序的摘要列表 |
这张表的价值有两个。第一，它逼着员工把“任务”说清楚，而不是说“AI 帮我做文档”。第二，只有输入输出都足够具体的任务，才有可能做成稳定模板。如果某个部门只能写下“提高效率”“辅助思考”这样的描述，这个场景就先不要立项。
表里的数据是示例，不是真实统计。你落地时应该用自己公司数字，这会影响后面判断“值不值得做”。
1.3 先砍掉三类高风险用例
不是所有任务都适合第一批上线。我在复盘时发现，最容易让项目失败的反而是那些看起来很有价值、但实际上会消耗信任的场景。
第一类是涉及敏感隐私的：HR 的薪资讨论、法务的未公开合同、员工的个人身份信息。这些数据一旦进入外部模型服务，就是不可控的合规风险。
第二类是需要绝对准确的：财务对账、合同金额审核、药品剂量建议、法律意见、内部制度解释。AI 在这些场景的错误率哪怕只有 5%，带来的损失也远远大于节省的时间。第一批完全不应该碰。
第三类是强风格创意输出：对外品牌广告语、核心产品文案、需要反复打磨的设计稿。这些任务一旦让 AI 生成，后续修改成本可能比从零开始还高，而且员工会因为“AI 写得太套路”而失去信心。
先砍掉这三类，剩下的场景哪怕少一点，也比上线后被一票否决强。
2. 技术选型别按“最强模型”选，要按“谁能维护、数据去哪、能否断网”选
2.1 三条路线，对应不同公司条件
很多人一听到 AI 落地，第一反应就是要私有化部署，其实这是误解。100 人公司最稀缺的不是算力，而是能长期维护 AI 系统的工程师。
路线一：直接使用云 API 或商业产品。常见做法是用编程接口或现成智能助手，按量付费，最快当天开通。优点是上线速度快，员工没有任何额外学习成本；缺点是数据会离开内网，而且长期费用需要监控。
路线二：私有化部署开源模型。这类方案适合数据敏感、有 GPU、也有维护能力的团队。优点是可以控制数据边界，缺点是模型维护、版本更新、并发调度都需要专人跟进。如果公司里只有一两个兼职运维，要非常谨慎。
路线三：使用现有办公工具里的 AI 功能。很多公司已经在用在线文档、多人协作工具、项目管理软件，这些产品自带摘要、续写、智能问答功能。对非技术员工来说，学习成本最低，也最不容易出权限事故。
这三条路线不是互斥的。更常见的做法是：先用办公工具内置 AI 做第一批体验，再把高频固定场景通过 API 做成统一入口，最后根据数据要求决定是否私有化部分模型。
| 对比维度 | 云 API / 商业产品 | 私有化部署 | 办公工具内置 AI |
|---|---|---|---|
| 上线速度 | 快，小时级 | 慢，需要开发和运维 | 最快，配置即可 |
| 数据边界 | 数据出内网，需评估 | 数据留在内部 | 取决于厂商协议 |
| 维护成本 | 低 | 高，涉及模型和 GPU | 最低 |
| 定制能力 | 中高 | 高 | 低 |
| 适合阶段 | 第一版快速验证 | 对数据有硬性要求 | 全员基础体验 |
2.2 100 人规模怎么判断该走哪条路
判断标准其实很朴素：如果你的团队里没有人能说清楚“GPU 是什么”，就不要考虑私有化部署；如果客户合同或行业规范没有明确要求数据不出境，也不要用私有化增加负担。
更稳妥的第一版方案，是做一个统一入口。这个入口可以是一个内部网页，也可以是办公协作软件里的机器人。员工只需要知道“有一个地方可以问 AI”，不需要记住哪些场景用哪个工具。
从技术上来说，统一入口的核心是加一层 API 网关：所有请求都走同一个代理，网关负责转发、记录日志、统计使用量、控制配额。这样做的价值有三个：账号统一、日志可查、换模型不影响前端。后端模型可以从默认模型开始，后面发现效果不够再换，不会影响员工使用习惯。
2.3 别急着接内部系统
很多团队在规划阶段就想着让 AI 读取内部 Wiki、CRM、工单系统，这个目标本身没问题，但不适合放在第一周。原因很简单：接内部系统意味着权限打通、数据行为变更、接口稳定性都要负责，如果中间出问题，员工只会觉得“AI 是个摆设”。
我建议先把入口做成“无内部权限”的版本，只接收员工粘贴的文本，输出处理结果。等员工真的依赖这个入口之后，再逐步读取指定的内部知识库。先让人用起来，再让系统连起来，顺序反过来就会变成大工程。
3. 权限和数据边界：部署前先处理三件事
3.1 账号、角色、配额分开管
100 人公司听起来人不多，但如果全员开放同一个入口，没有账号管理，后面排查问题会非常痛苦。管理员不知道是谁调用了什么、为什么某些人用了 10 倍额度、出了问题也找不到责任人。
第一批应该至少建立三个角色：管理员、部门负责人、普通员工。管理员能看到全公司的调用记录、错误日志和费用；部门负责人只能看到自己部门的统计；普通员工只能看到自己的历史会话。这样既保护隐私，也为后面的成本分析打基础。
另外，不要一次性给 100 个人开权限。建议先开 10 到 20 个试点名额，等模板和反馈流程稳定后再放给更多人。这个动作不是限制员工，而是保护项目早期口碑。
3.2 数据边界：明确哪些内容不能进入外部 API
商业 API 调用时，数据会发送到模型服务商。员工不一定有这个意识，可能随手把客户列表、内部薪资、未公开合同粘贴进去。所以部署前必须做两件事：第一是发布一份“禁止输入清单”，用员工看得懂的话写清楚，比如“不要上传真实身份证号、手机号、银行卡号、未公开财务数据、源代码”；第二是在系统层面做简单规则过滤，比如检测到敏感号码就拦截或警告。
强烈建议部署前就加一个输入过滤层，而不是等出问题再补。
数据过滤可以很简单，先写一批关键词和格式规则，比如身份证正则、电话号码正则、薪资相关词、合同编号格式。命中后直接不允许发送，或者提示用户删除后再发送。这个功能不需要很复杂，但能有效避免多数低级事故。
日志也要做最小化。不要把全部提示词永久保存，只保留调用时间、员工 ID、模型、Token 数、状态码这些统计信息。除非在排查严重问题，否则不要翻看员工的原始输入，这对内部信任很重要。
3.3 成本管控：别让第一个月账单失控
很多商业 API 按 Token 计费，Token 可以理解为模型处理文本的最小单位。员工每输入一次内容，系统按字符数换算成 Token，最终决定费用。热词里常见的 “credits” 在 AI 产品里通常就是这个概念：预付费余额或免费额度，按用量消耗。
如果你不做控制，一个 100 人公司第一个月就可能产生非常高的账单。原因很简单：大多数员工会尝试很多随机任务，而且输出质量不满意时会反复重新生成。所以配额是必须的。
常规做法是给每位普通员工设置每日请求次数上限，比如 50 次；单次输入长度上限，比如 4000 字；每月团队总额度，超出后自动冻结并进入审批。管理员按部门看一个简单的费用看板，把调用量、Token 消耗、费用排名展示出来，不需要做得像专业观测平台，一张表格就够。
注意：不要一上来就开最大并发，先用一条样例确认输入、输出和日志都正常。
4. 试点团队怎么选：先让 10 个人把场景跑通
4.1 种子用户不是最懂技术的人，而是最愿意描述工作的人
试点团队选人非常关键。如果你只找程序员，他们确实能很快上手，但无法代表大部分非技术员工。如果你找高管，他们时间太少，很难每周稳定反馈。我更建议选三类人：客服骨干、销售助理、行政专员。这些人日常处理大量文本，愿意为了节省重复劳动而投入时间，而且他们能具体描述“这个任务每周要花多久”。
种子用户的标准很简单：愿意每周花 2 小时做测试，能清楚说出任务输入和输出，遇到报错时愿意截图记录。只要满足这三点，哪怕完全不熟悉 AI 也没关系。
4.2 两周试点节奏，产出比热情更重要
试点不要拖久，两周就够了。第一周让每个试点用户提交 5 个真实任务，用 AI 跑一遍，记录输出质量。第二周把其中 2 到 3 个稳定任务固化成模板，放在统一入口里。两周后做一次复盘，重点不是“AI 好不好用”，而是“哪些任务稳定可用、哪些不行、卡点在哪里”。
一个容易被忽略的细节是：试点期间，AI 的每一条输出都要有人工复核。不要让员工觉得“AI 说的一定对”，更不要让下游流程直接使用未复核的输出。非技术员工需要在这个阶段建立检查习惯，这个过程比模型本身的准确率更重要。
4.3 试点产出物是“模板库”，不是“使用心得”
很多人试点结束后写一篇总结，说 AI 很好用、大家很兴奋，但这个对后续推广几乎没有帮助。真正有价值的是沉淀出一批可直接复用的模板。
模板库的结构可以这样设计：
| 模板名称 | 适用岗位 | 输入格式 | 示例输入 | 输出要求 | 人工检查项 |
|---|---|---|---|---|---|
| 客服反馈分类 | 客服 | 原始聊天记录，粘贴完整 | 多段聊天文本 | 表格输出，分价格/物流/质量，附原文摘要 | 分类是否准确；是否漏掉关键反馈 |
| 会议待办提取 | 销售、管理 | 会议录音转写文本 | 转写文本 | 输出待办清单：负责人、截止时间、事项 | 负责人和截止时间是否与原文一致 |
| 周报润色 | 全员 | 员工自己写的工作要点 | 3 到 5 条零散要点 | 输出一段通顺周报，分条列出 | 是否夸大了原意；是否添加了不存在的成果 |
模板库最大的作用，是让后来者不用从零开始写提示词。他们只需要填输入，然后让 AI 按固定格式输出。这比任何培训都更有效。
5. 给非技术员工培训时，别教提示词，教任务拆解
5.1 非技术员工真正缺的不是“提示词技巧”
很多团队做培训，一上来就教“万能提示词公式”，结果员工听完还是不会用。原因在于，提示词技巧是给已经知道任务边界的人用的，而非技术员工的问题是：他们根本没说清楚任务。
“帮我整理一下”“写得好看一点”“总结一下”这类需求，模型不是不能做，而是输出结果很难满足预期，因为“整理”和“好看”太模糊。所以培训的重点应该是让员工学会把任务拆成四个要素：角色、任务、输入、输出要求。
5.2 任务拆解四要素，配一个可直接套用的模板
我建议培训课上只讲一个结构，然后让员工用真实任务练三遍。结构如下：
- 角色：谁来处理这个任务。比如“你是一名客服主管”“你是一名销售助理”。
- 任务：动词加对象。比如“把下面反馈分类”“从会议记录中提取待办”“把这段通知改写成群聊公告”。
- 输入：给出足够上下文。可以是原文粘贴、要点列表、背景信息。
- 输出要求：格式、长度、语气、是否分点、是否需要证据。
一个示例提示词可以是这样：
你是一名客服主管。请把下面的用户反馈按“价格问题、物流问题、质量问题、其他”四类进行整理。输出格式为表格，每个分类包含：问题摘要、出现次数、原始证据一句。不要额外补充建议，先只做分类。用户反馈如下： （在这里粘贴聊天记录）这个模板本身并不神奇，但它强迫员工先想清楚自己要什么。只要员工愿意填这四个空，大多数任务不会跑得太偏。培训课不用讲多，讲透这个模板，再让员工用自己手里的活跑三次，基本就能建立感觉。
5.3 允许从“粘贴整段”开始，再慢慢拆细
第一次使用 AI，很多员工不敢下手。这时候不用逼他们写结构化提示词，直接告诉他们：把整封邮件、整场会议记录、整段通知完整粘贴进去，先问“你能不能帮我总结”。这没有任何问题。
等 AI 给出一版结果后，再引导他们做“细化”：如果输出太泛，就让模型“只提取待办事项”；如果语气不对，就加一句“用普通话正式一点的语气”；如果结果太长，就让模型“不超过三句话”。员工很快会发现，他们不需要记住技巧，只需要描述差异。这种做法比一开始就讲公式更容易让非技术人员建立信心。
注意：AI 输出仅供参考，必须有人工复核。这一点要印在培训材料里，而不是只靠口头提醒。
6. 日常运维：日志、反馈、幻觉兜底和升级通道
6.1 建立反馈渠道，但不要收集“感觉不好用”
试点和全员推广最怕的是什么？是员工用一次发现不对，然后默默不用了，不再告诉你。所以必须有一个极简反馈渠道。一个表单、一个专用群都行，字段不要多：任务名称、输入简述、AI 输出有什么问题、期望是什么、截图。
管理员每周汇总一次，把反馈归类。别急着改模型，先看是不是模板写得太宽、输入格式不对、或者员工对输出预期有误解。每周挑出 2 到 3 个反复出现的问题，修模板、换模型、或者调整提示词。持续两周后，反馈量会明显下降。
6.2 幻觉高风险区，要单独处理
AI 模型可能会一本正经地输出错误内容，这就是常说的“AI 幻觉”。在写作润色、信息分类这类场景里，幻觉的影响有限；但在政策解释、法律意见、财务数字、内部制度解答这类场景，一次错误就可能摧毁信任。
最稳妥的做法是：第一波不开放这些高风险场景。如果确实需要做，就在模板里明确要求“只根据提供的资料回答，超出资料范围要明确说不知道”，并在输出前端加提示条：“本内容由 AI 生成，仅供参考”。更重要的是，高风险场景必须设置人工复核节点。不要指望模型可靠，要指望流程兜底。
6.3 效果不好时，按链路排查而不是直接换“更贵模型”
当员工反馈“AI 不聪明”时，很多人的第一反应是换一个更强的大模型。但实际排查时你会发现，问题经常出在输入、权限或展示层。
可以用下面这个顺序排查：
| 现象 | 第一步做什么 | 常见原因 | 处理方式 |
|---|---|---|---|
| 输出很泛、没有信息量 | 看员工输入了什么 | 任务描述模糊，缺少背景 | 用任务拆解四要素优化输入 |
| 输出乱码或格式错乱 | 检查原文格式 | 粘贴时带了表格、特殊字符 | 要求粘贴纯文本 |
| 完全没反应 | 看日志 | API 超时、配额耗尽、网关报错 | 检查错误码、配额、网络 |
| 答非所问 | 看模型上下文 | 接了内部系统但权限没有取到资料 | 检查权限链路 |
| 费用突然变高 | 看用量排行 | 有人批量跑长文本 | 设置每日配额和单次长度上限 |
每一条都要有日志支撑，否则就会变成靠猜。所以“日志记录”不是可选项，而是整个 AI 落地项目的地基。
6.4 接入内部系统时，先从“读”开始
如果后续要把 AI 接到内部 Wiki 或 CRM，建议从读取知识库开始，不要一开始就让 AI 直接修改客户记录、写入工单、更新状态。原因很简单：读操作出错，最多是答得不准确；写操作出错，可能污染基础数据，很难回滚。先让 AI 生成建议内容，由员工确认后再提交，这是一个稳定的过渡方案。真正能承担完整 Agent 写操作的时候，说明你的数据权限、日志追踪、人工审核环节已经成熟了。
7. 从试点到全员推广：节奏比功能重要
7.1 分批开放，而不是“全员大群通知”
试点跑通后，真正到了全员推广阶段，最容易犯的错误就是“所有功能一次性放给所有人”。看起来很大方，实际上会导致：一半人不会用，少数人滥用，管理员收到大量重复问题。
建议分三批：第二批放给 30 人左右，观察一周；第三批再放给全部员工。每一批开始前，把模板库和培训材料重新发一遍，并安排一个 15 分钟在线答疑。这样节奏虽慢，但每一步都在可控范围内。
7.2 每两周公布一个真实案例，用数字说话
推广阶段最有效的不是发功能公告，而是发布真实案例。案例必须来自自己的团队，最好有量化信息。比如“客服组用反馈分类模板，每周分类耗时从 6 小时降到 2 小时，但需要 30 分钟人工复核”；“销售助理把会议记录转成待办清单，原来需要 20 分钟，现在 5 分钟完成初稿”。这些数字如果你没有，就用真实记录去算，不要编造。
写作时要写清楚：任务原貌、输入什么、AI 输出什么、人做了哪些复核、节省在哪里。这比任何“AI 能力说明”都更有说服力。一旦员工看到身边同事的真实工作方式，使用率自然会上来。
7.3 建立撤出机制，别让所有功能都永久保留
并不是所有 AI 功能都值得长期存在。有些场景试用两周后发现不稳定，有些场景员工新鲜感过了就不再用，这些都应该及时下线或调整。建议每隔一个月做一次功能盘点，看每个模板的使用次数和反馈情况。如果一个场景连续三个月使用率低于 20%，并且没有可预期的增长，就果断下线。
这看起来有点无情，但对整个项目很重要。保留单一、稳定、高频的功能，比保留一堆“偶尔能用”的功能更能建立员工信任。最后留下来的模板，才是真正的基座。
回到最初的问题：面向 100 名员工、大多数非技术背景的 AI 部署，什么方法有效？我能给出的判断是：先不要陷入模型测评，把场景、权限、反馈循环做好，比选哪个模型更重要。先用 10 人把少数模板跑通，再逐渐扩大，比一步到位更稳。如果能重新来一次，我会把权限、日志和反馈渠道放在第一天就建好，然后才开始谈提示词和模型效果。
