公司怎么把AI真正用起来

有一种挺常见的 AI 落地方式。

老板在群里转了几篇文章，开会时顺便提一句：“现在 AI 这么快，各部门都研究一下，看看怎么把效率提起来。”

一个月后再问，技术部有人拿 AI 写过代码，市场部用它改过文案，行政同事让它写过两次通知。

然后就没有然后了。

这不一定是谁执行得不好。

“大家把 AI 用起来”这句话，本身就很难执行。它没有说清楚要改哪项工作、用什么工具、谁来确认结果，也没有说做到什么程度才算有效。

如果让我在一家公司里推动这件事，我不会先做全员培训，也不会先买一大批账号。

我会先去找工作。

准确一点说，是找那些每天都在重复、资料已经数字化、结果容易检查，而且确实让人觉得麻烦的工作。

AI 真正能落地，通常就是从这些地方开始的。

先别买工具，把重复工作列出来

第一步很朴素。

让每个部门列出十件重复发生的工作，先不讨论用哪个模型，只记录五个数字：

这张表不用做得很精确。

它只是帮我们分清楚，哪些工作值得先动，哪些暂时不要碰。

适合第一批交给 AI 的任务，通常有几个特点：频率高，输入大部分已经在线上，输出格式相对固定，做错了能被人发现，也能撤回重做。

付款、生产控制、法律承诺、人员录用这类工作，即使很耗时间，也不适合一开始就让 AI 自动完成。

先选那些错了还有机会改的。

公司做 AI 的第一步，不是追求最聪明，而是建立第一条能稳定跑通的流程。

软件技术部最适合先打个样

技术部往往是最容易开始的部门。

代码、需求、测试、日志和发布记录本来就在数字系统里，结果又能通过编译、测试和 Code Review 检查。AI 不需要凭空猜测，它有很多可以验证的东西。

但这里也最容易走偏。

不少开发人员拿到 Claude Code、Codex 或 Cursor，第一句话就是：“帮我把这个功能做完。”

如果代码仓库不大，需求也简单，偶尔真能做出来。项目一复杂，它就会开始补自己不知道的东西：随手换一个库，绕开现有封装，漏掉异常处理，或者写出能运行但不符合团队习惯的代码。

我现在更认可下面这条路径。

先把仓库里的规矩写下来

使用 Codex，可以在仓库里维护 AGENTS.md；使用 Claude Code，可以维护 CLAUDE.md。不用写成长篇制度，先把几件最容易踩坑的事讲清楚：

• 项目怎么构建和运行；
• 单元测试、集成测试分别执行什么命令；
• 哪些目录可以改，哪些生成文件不要动；
• 数据库变更采用什么方式；
• 日志、异常和配置使用现有哪套封装；
• 完成任务后必须给出哪些验证结果。

这些内容本来就在老开发人员脑子里。

把它写下来以后，不只是 AI 少走弯路，新人接手项目也会轻松很多。

再让 Agent 先分析，不要马上改代码

一张可以交给 Agent 的任务单，至少要说清楚：

目标：用户连续登录失败 5 次后锁定账号 30 分钟。

范围：只修改身份认证服务，不调整前端页面。

约束：沿用现有 Redis 缓存和日志组件，不增加新的 NuGet 包。

验收：补充成功、失败、锁定、自动解锁四类测试。

执行方式：先分析影响范围和修改计划，确认后再写代码。

第一轮只让 Claude Code 或 Codex 阅读代码、找调用链、列风险。

开发人员看完计划，再决定哪些地方可以做，哪些理解错了。方向确认以后，让 Agent 创建分支、修改代码、运行 dotnet test、npm test 或项目已有的测试命令。

最后生成 Pull Request，由 GitHub Copilot Code Review、CodeRabbit 或另一个 Agent 做第一轮审查，开发人员负责最终合并。

完整流程可以是：

需求或缺陷单
  → Claude Code / Codex 分析影响范围
  → 开发人员确认修改计划
  → Agent 创建分支并编码
  → 自动执行单元测试和 Playwright
  → CodeRabbit / Copilot 审查 Pull Request
  → GitHub Actions / GitLab CI 构建测试环境
  → 人工批准生产发布
  → Sentry / Grafana 观察上线结果

AI 可以参与编码、测试、审查、流水线配置和日志分析。

但合并主分支、执行数据库破坏性变更、发布生产环境，最好继续保留人工确认。Agent 可以很勤快，责任不能跟着自动化一起消失。

如果团队更看重国内访问、采购和中文支持，也可以拿同一个真实任务测试通义灵码、腾讯云 CodeBuddy、百度 Comate 和 Trae。

不要只比较谁补全代码更快。让它们读取同一个仓库、分析同一个缺陷、执行同一组测试，再比较计划是否准确、修改范围是否克制、测试能不能跑通，以及代码是否会被发送到团队不能接受的位置。

技术部判断有没有提效，也不要只看生成了多少行代码。

更值得看的是：一个需求从开始到进入 PR 花了多久，代码审查等了多久，测试有没有补上，上线后的缺陷和回滚有没有增加。

写得更快但返工更多，不算提效。

产品部门先把会议里的信息捞出来

产品经理有一类时间消耗很隐蔽。

上午开客户会议，下午整理纪要，晚上再把同一批内容拆成需求、待确认问题和开发任务。真正做判断的时间不一定多，大量时间花在信息搬运上。

这条流程可以直接改。

会议先用飞书妙记、Fireflies.ai 或 Otter.ai 转成带发言人的文字记录。会后把记录交给 Claude Projects、ChatGPT Projects 或 Notion AI，按固定模板输出：

• 客户明确提出的需求；
• 仍然含糊的地方；
• 已经做出的决定；
• 需要谁在什么时间前确认；
• 可以进入 Jira 或飞书项目的任务草稿；
• 对应的验收条件。

产品经理不需要重新听一遍录音，但要回到原始记录确认关键结论。

这里最重要的不是“自动生成 PRD”。

而是把会议、需求、任务和验收条件连起来，减少同一份信息被人重复整理三四次。

遇到还不确定的需求，可以用 Figma Make、v0 或 Lovable 快速做一个可操作原型。先让客户和开发看到流程，再决定要不要进入正式设计。

原型是为了尽早暴露理解偏差，不是拿生成页面直接替代生产代码。

销售部门别让会议纪要停在会议纪要里

销售人员愿意用录音转写，但不少公司的流程到这里就停了。

会议纪要生成得很漂亮，CRM 还是没人填。

真正有用的做法，是把飞书妙记、Gong 或 Fireflies.ai 生成的结果继续往下推：提取客户角色、明确需求、预算线索、反对意见、承诺事项和下次跟进时间，再写入 HubSpot、Salesforce 或公司现有 CRM。

使用 HubSpot 的团队可以评估 Breeze，使用 Salesforce 的团队可以评估 Agentforce。已有国内 CRM、又不想整体更换的公司，可以用 n8n 调用 CRM 接口，再让 Dify 或 FastGPT 负责整理内容。

一条具体流程可以这样跑：

客户会议结束
  → 飞书妙记生成转写
  → AI 提取需求、异议和待办
  → 销售确认内容
  → n8n 写入 CRM
  → 到期自动提醒下一次跟进

人工确认不能省。

客户没有说过的话，不能因为 AI 总结得通顺就写进 CRM；报价、交付周期和合同承诺，也不能让 Agent 自己决定。

这个场景的指标很清楚：销售整理一次会议要多久，CRM 完整率有没有提高，答应客户的事情有没有更少遗漏。

客服部门适合从“建议回复”开始

客服场景看起来特别适合 AI，也特别容易出事故。

产品参数答错、退款规则说错、给客户承诺了不存在的功能，都会直接影响业务。

所以第一阶段不要急着做全自动客服。

先让 AI 做建议回复。

已经使用 Intercom 或 Zendesk 的团队，可以分别评估 Intercom Fin 和 Zendesk AI。希望自己控制知识库和模型的团队，可以使用 Dify 或 FastGPT，再连接 Chatwoot 这类客服系统。

知识库里先放少量但可靠的内容：当前产品手册、常见故障、售后政策、版本说明。每篇资料都要有负责人、更新时间和适用版本。

客户提问以后，AI 检索资料并生成回复，同时带上来源。客服人员确认后再发送。连续运行一段时间，把问题分成三类：

• 可以稳定回答的普通问题；
• 资料不足，需要补知识库的问题；
• 涉及退款、合同、投诉和安全，必须转人工的问题。

等第一类问题的准确率稳定，再考虑自动回复。

客服提效不能只看机器人处理了多少条，还要看错误答案、转人工比例、首次响应时间和客户重复追问次数。

市场部门先解决“资料找不完、内容改不完”

市场部门很容易成为 AI 工具最多、流程最乱的地方。

ChatGPT 写一版，Claude 改一版，Canva 做一张图，最后每个人的语气和视觉都不一样。

工具没有少用，返工也没有减少。

比较稳的做法，是先固定一条内容生产链。

行业研究使用 Perplexity Enterprise、ChatGPT 或 Claude，但要求保留来源链接和原始数据。选题确认以后，按照公司的品牌语气、禁用表达、产品事实和目标读者生成内容大纲。

正文可以由 Claude 或 ChatGPT 协助完成，海报和配图使用 Canva Magic Studio、Adobe Firefly、Midjourney 或即梦，演示文稿使用 Gamma，短视频初稿使用剪映。

这里最应该沉淀的，不是几十条零散提示词，而是一份品牌资料：公司怎么称呼自己，产品有哪些确定事实，哪些词不使用，过去哪些内容效果好，发布前要检查什么。

每一篇内容仍然要检查数据来源、产品描述、版权和对外承诺。

AI 可以把第一稿做得很快，但不能替公司决定什么值得说。

人力和行政，先做内部问答与入职资料

人力和行政部门有很多重复问题。

报销怎么申请，年假怎么算，新员工要开哪些账号，电脑坏了找谁，某个制度在哪里。

这些问题很适合用 Dify、FastGPT、Notion AI 或飞书智能伙伴做内部问答。资料来源可以是员工手册、制度文件、入职清单和常用表单。

答案最好同时给出原文链接和更新时间。

制度发生变化时，由明确的负责人更新资料，而不是让机器人继续引用三年前的版本。

招聘环节可以用 Moka 等招聘系统管理流程，也可以让 Claude 或 ChatGPT Enterprise 协助整理职位描述和面试记录。但筛选候选人、评价性格、决定是否录用，不应该只交给模型。

AI 可以整理证据。

涉及人的判断，还是要由人承担。

财务部门不要从“自动付款”开始

财务场景里，AI 最适合先处理资料，不适合先处理权力。

发票和单据可以用百度智能云 OCR、Azure AI Document Intelligence 或现有财务系统的票据识别能力提取字段。表格清理和对账可以使用 Power Query、Excel Copilot，经营报表可以使用 Power BI Copilot。

跨系统搬运数据，可以评估 Power Automate、UiPath 或 n8n。

比如每月对账，可以先让 OCR 提取票据信息，Power Query 合并银行流水和系统数据，AI 标记金额、日期、供应商不一致的项目，最后由财务人员逐项确认异常。

这已经能省掉不少机械工作。

付款账号、审批结果、税务判断和最终凭证，不要让 AI 自动决定。财务数据进入外部模型之前，也必须确认公司购买的是哪种账号、数据是否用于训练、保存在哪里，以及谁能看到。

管理层需要的不是更长的周报

AI 很容易把五页周报扩写成十页。

这对管理者没有帮助。

管理层更适合使用 Microsoft 365 Copilot、Power BI Copilot、ChatGPT Enterprise 或 Claude Team/Enterprise，把项目数据、销售数据和会议记录整理成一页决策简报：

• 本周发生了什么变化；
• 哪几个指标偏离目标；
• 哪些风险需要拍板；
• 每个判断来自哪份数据；
• 下周需要确认什么。

如果数据还在十几张口径不一致的 Excel 里，先别急着做“老板驾驶舱”。

AI 会把混乱的数据讲得很像真的。

管理层使用 AI 的价值，不是让汇报更漂亮，而是更快发现需要判断的地方。

工具不要买成一套展览品

前面提到的工具很多，一家公司不需要全部购买。

工具组合应该顺着现有系统来选。

已经重度使用 Microsoft 365 的公司，可以优先看 Microsoft 365 Copilot、Power Automate 和 Power BI。研发团队围绕 GitHub 工作，就从 GitHub Copilot、CodeRabbit、GitHub Actions，再配合 Claude Code 或 Codex 开始。

以飞书为主要协作工具，可以先用飞书妙记和现有项目管理能力，再用 n8n、Dify 或 FastGPT 补上知识库和跨系统自动化。

对数据出境、客户隐私或源代码有严格要求的公司，要优先选择企业版账号、批准的 API 和私有部署方案。Dify、FastGPT、RAGFlow、n8n 能解决一部分自托管需求，但自托管不等于天然安全，权限、日志、备份和模型接口仍然要有人维护。

如果公司暂时无法稳定采购 ChatGPT 或 Claude，通用办公和资料处理也可以先测试 DeepSeek、通义千问、Kimi、豆包等国内工具。需要接入业务系统时，再评估阿里云百炼、火山方舟、智谱开放平台等企业 API。这里不要只看一次回答效果，还要确认数据政策、调用成本、账号权限和接口稳定性。

先围绕一条工作流选最少的工具。

跑顺以后，再决定是否扩展。

先从这些官方入口核对工具

工具功能和价格会变化。下面只列这篇文章中几项核心工具的官方入口，真正采购前还要按公司的地区、账号和数据要求重新确认：

• Claude Code
• Codex
• Dify
• FastGPT
• n8n
• 通义灵码
• 百度 Comate
• Trae
• 飞书妙记

本文中的工具信息核对日期为 2026 年 7 月 11 日。以后再读到这篇文章时，如果工具名称、入口或能力已经变化，以官方最新说明为准。

用 30 天跑出第一批结果

如果公司准备现在开始，我会把第一个月安排得很具体。

第一周，每个部门列出十件重复工作，记录频率、耗时、参与人数和出错代价。负责人只选一件，不要贪多。

第二周，准备账号、样例数据和人工确认点。先让 AI 在旁边跑，不直接写入生产系统，也不直接面对客户。

第三周，进入真实工作。每次结果都记录三件事：用了多久，人改了多少，AI 在哪里出错。

第四周，拿改造前后的数据做一次复盘。有效的流程写成 SOP 或 Skill，效果一般的继续调整，没有价值的就停掉。

不同部门可以看不同指标：

• 研发看需求周期、审查时间、测试覆盖和上线缺陷；
• 产品看纪要整理时间、需求返工和待确认事项遗漏；
• 销售看 CRM 完整率、会后整理时间和跟进遗漏；
• 客服看首次响应、错误回答、转人工和重复追问；
• 财务看对账时间、异常发现率和人工复核量。

不要把“使用 AI 的次数”当成核心指标。

员工每天打开十次聊天窗口，不代表公司效率提高了。

真正值得保留的，是那些让工作少一次转述、少一遍复制、少等一个人，同时又没有把错误和风险放大的流程。

公司当然可以讨论更大的 AI 战略。

但在那之前，先让一个部门里的一件麻烦事，真的少花一半时间。

这比做十场演示更有用。