记录企业软件、MES、物联网、高并发架构、技术团队管理与 AI 工程化实践的个人技术博客。
AI到底有没有提效，别只看用了多少次
AI项目做了一个月，汇报材料通常不难看。开通了多少账号，调用了多少次，生成了多少文档，做了几个Agent，都能做成图表。但老板再问一句：“那到底省了什么？”会议室往往会安静一下。使用量只能说明有人打开过工具。真正的效率，要回到一项具体工作：原来怎么做，现在怎么做，时间、质量、成本和风险发生了什么变化。没有基线，就没有提效AI接入前，至少连续记录一到两周：每期任务量；单次人工时间；参与人数；等待和交接时间；返工和错误；高风险问题数量；当前软件和人工成本。不要靠回忆填写。可以用现有工单、Git记录、CRM时间、表格或抽样计时。使用WPS AI或其他表格工具整理数据可以，但原始数据口径要由业务负责人确认。先看五个真正有用的指标任务周期从工作触发到最终可用结果的时间。只记录模型响应几秒没有意义。如果AI十秒生成，员工排队等审批两天，流程仍然是两天。人工采用率人工采用率 = 被直接采用或小幅修改的AI结果 / AI总结果采用率太低，可能是输入、知识、任务定义或工具不合适。返工和错误率AI让第一稿更快，但如果后面要反复修正，时间只是从前面挪到了后面。要记录错误类型和业务影响，而不只是数量。单次任务成本包括：软件账号；模型API；服务器、存储和备份；流程维护；人工审核；异常处理；培训和集成投入。Dify、FastGPT或n8n可以降低部分集成门槛，但自托管也有服务器、升级和维护成本。可复制性不是看最会用AI的人能多快，而是第二位、第三位同岗位员工能不能得到相近结果。不能复制的提效，通常只是个人能力增强，还没有变成公司能力。一套够用的计算方法每月节省工时 = 每月任务量 ×（改造前单次人工时间 - 改造后单次人工时间） 每月时间收益 = 每月节省工时 × 人工小时成本 每月净收益 = 时间收益 + 可量化质量收益 - 软件、模型、维护和审核成本 投资回收月数 = 一次性投入 / 每月净收益质量收益不好估算时，不要硬填一个漂亮数字。可以单独记录漏单减少、响应变快、线上事故下降和客户投诉变化，等数据稳定再折算。一个明确标注的假设案例下面是演示计算，不是真实公司结果。某团队每月处理600张售后工单。原来每张分类和补字段需要6分钟，AI建议分类后人工确认需要2.5分钟。每月节省工时 = 600 ×（6 - 2.5）分钟 = 2100分钟 = 35小时假设综合人工小时成本为100元，时间收益约3500元。如果每月模型、软件和维护成本为1800元，暂时净收益约1700元。一次性集成和培训投入9000元，简单回收周期约5.3个月。但还要继续看：错误分类有没有增加；客服是不是更快找到技术人员；人工确认有没有形成排队；600张工单是否都适合AI；维护成本是否被低估。只算节省时间，很容易把返工和风险漏掉。给每个试点设继续和停止条件开始前就写下来：继续条件： - 单次人工时间至少下降30%； - 人工采用率达到团队设定门槛； - 高风险错误不增加； - 两名以上员工能独立使用； - 月度成本在预算内。 停止或调整条件： - 人工检查时间超过原流程； - 错误难以发现； - 数据或权限无法合规处理； - 业务负责人不愿继续使用； - 三个评估周期后仍没有稳定改善。这些比例需要公司按任务风险设定，不能把示例数字直接当标准。不同部门看不同结果研发：需求到PR周期、Review时间、测试、缺陷和回滚。销售：会后整理时间、CRM完整率、跟进遗漏和客户回复速度。客服：首次响应、人工采用、转人工、重复追问和错误承诺。财务：对账时间、异常发现、人工复核和错误影响。行政人事：制度问题响应、资料查找、员工重复咨询和内容更新速度。管理层：发现偏差所需时间、决策材料来源和待拍板问题是否更清楚。不要用一套指标评价所有部门。做一张每月评估表项目改造前本月目标结论任务量 单次人工时间 人工采用率无 返工率 高风险错误 0 软件和模型成本 维护与审核工时 可复现员工数 旁边保留问题清单：本月AI最常错在哪里，哪些资料缺失，哪个人工节点最慢，下个月准备改什么。ROI不是只决定“继续还是停止”有些试点时间没有明显下降，却暴露了数据版本混乱、流程口径不一和责任不清。这同样有价值，只是结果可能不是继续加模型，而是先整理流程和数据。也有些场景节省时间不多，但降低了高风险遗漏。它的价值不能只用工时计算。所以评估不是为了证明AI一定有效。它是为了让公司知道，应该扩大、调整、暂停，还是把精力转到更适合的地方。账号数量很容易增长。能讲清楚一项工作前后发生了什么，才算真正开始管理AI带来的效率。
公司开始用AI以后，管理上最常见的两种反应都不太好。一种是完全放开，员工各自注册账号，把代码、合同、客户资料和会议记录复制进去。另一种是发一份通知：“涉及公司信息禁止使用AI。”前一种风险太大，后一种几乎等于让大家继续偷偷用。真正需要的不是一句口号，而是一张员工能看懂、技术能执行、管理者愿意负责的边界表。先把数据分成红黄绿绿色：可以进入批准的通用工具已公开官网内容；已发布产品手册；公开代码和开源资料；公司明确允许传播的模板；已充分脱敏的培训样例。绿色不等于没有版权。转载、图片、客户案例仍然要确认授权。黄色：只能进入企业账号或受控环境内部制度和普通项目文档；未公开源代码；脱敏后的客户记录；内部会议纪要；运营、销售和普通业务数据；尚未发布但风险可控的产品资料。黄色数据要明确可使用的企业账号、API或私有部署环境，并控制人员、日志和保存时间。红色：默认不能直接提交给模型密码、Token、私钥和生产连接串；未脱敏个人信息；付款账号和高敏感财务数据；核心商业机密；高敏感客户数据；未公开重大经营信息；受法律、合同或保密协议严格限制的材料。红色数据不是换成本地模型就自动安全。要重新设计流程：先脱敏、只传必要字段、在受保护边界内处理，或者根本不让AI参与。再做一张批准工具清单每个工具至少记录：项目要说明什么工具和版本员工到底使用哪个产品和企业空间允许数据绿色、黄色或仅指定项目账号公司账号、个人账号是否允许数据政策是否用于训练、保存多久、存放区域权限哪些人可用，能读写哪些系统集成API、插件、MCP、浏览器扩展能访问什么负责人采购、技术、业务和安全分别找谁停用如何撤销账号、密钥和系统连接复核日期什么时候重新检查产品政策和能力使用Dify或FastGPT自托管时，也要记录模型API最终把数据发到哪里。n8n和Power Automate能连接很多系统，权限反而更需要限制。能连，不代表应该全连。给Agent最小权限第一阶段尽量采用只读或草稿权限：读取指定知识库，不读取整个共享盘；读取当前Issue，不扫描无关私有仓库；创建待确认任务，不直接改变项目承诺；生成付款异常提示，不执行付款；生成生产变更计划，不直接运行；查询客户资料的必要字段，不导出完整客户库。给每个Agent或自动化流程单独服务账号，不和管理员共用账号。API Token只开放必要接口和范围，并设置有效期。如果一个流程只需要创建工单，就不要给它删除工单、修改客户和管理用户的权限。高影响动作必须有人批准这些动作不能因为模型“置信度高”就自动完成：生产发布和基础设施删除；数据库破坏性变更；付款、报销、税务和会计判断；合同、报价、交付承诺和对外声明；录用、辞退、绩效和纪律决定；退款、投诉、法律通知和安全事故；PLC、设备和其他高影响控制；客户及业务数据的批量删除。人工审批界面应该显示原始输入、AI建议、使用资料、风险和将要执行的动作，而不只是一个“同意”按钮。日志要能回答发生了什么至少记录：谁或哪个服务账号发起；使用了哪个工作流、模型和规则版本；访问了哪些数据来源；产生了什么结果；人工修改和审批；写入了哪个系统；失败、重试和最终状态。日志本身也可能含敏感数据。不要无期限保存完整提示和客户文本。按排障、审计和业务需要确定字段、访问权限和保留时间。员工真正需要的是几条清楚规则公司制度可以很完整，但员工日常更需要快速判断：公开资料：使用批准工具。 内部资料：只用企业账号或批准环境，先确认权限。 个人信息、密钥、付款和核心机密：不直接提交。 代码和客户数据：按项目批准范围使用。 对外承诺、付款、招聘和生产操作：必须人工批准。 不确定：先问数据或业务负责人，不要自己猜。再配几个真实工作例子，比只有一份法律语言很重的制度更容易执行。一个低门槛的治理落地顺序第一周，列出现有AI工具和员工实际使用情况，不急着处罚。第二周，完成红黄绿数据分类和第一版批准工具清单。第三周，给正在试点的流程建立专用账号、最小权限、日志和人工审批。第四周，做一次演练：撤销一个离职账号、轮换一枚API密钥、停止一条工作流、从备份或草稿恢复。能停下来、查得到、收得回，治理才不只是纸面制度。哪些信号说明边界还不够清楚员工不知道个人账号和企业账号有什么区别；同一份客户资料被复制到多个聊天工具；Agent使用管理员Token；工作流失败后只能重新跑，不知道是否已经写入；知识库资料没有负责人和权限；模型或供应商变更后没人重新检查政策；人工审批只看AI总结，不看原始依据；离职员工账号和API密钥没有及时撤销。公司不需要等一套完美制度才开始使用AI。但每增加一条自动化能力，都要同时增加对应的权限、日志、人工责任和停用办法。边界不是为了让AI少做事。它是为了让公司知道，AI做到了哪里，最后谁愿意为结果负责。
AI客服的演示通常很顺。上传产品资料，输入一个问题，机器人几秒钟给出回答。真正接到客户以后，问题就没有那么规整了。客户可能只说一句“设备又掉了”，没有型号、版本和时间。有人会追问退款，有人会把两个故障混在一起，还有人问的是公司从来没有公开过的计划。这时最重要的不是机器人说得像不像客服。而是它什么时候能回答，什么时候必须继续问，什么时候应该马上把人叫进来。第一阶段只做建议回复不要一开始就把机器人放到全部客户面前。先让它进入客服工作台，给人工客服生成建议回复：客户消息 → 识别问题类型和风险 → 检索有效知识 → 生成带来源的建议回复 → 客服确认、修改或转人工专家 → 发送给客户 → 保存最终回复和修改原因这条路径多了一次人工确认，却能快速积累最重要的数据：哪些问题回答稳定，哪些资料缺失，哪些表达经常被客服改掉。等低风险问题稳定以后，再逐步开放自动回复。工具怎样组合知识和Agent层可以使用Dify、FastGPT或MaxKB。跨系统、审批和日志可以使用n8n。客服工作台可以评估Chatwoot这类可集成系统，已有Zendesk、Intercom或国内客服系统的公司优先接现有平台。不要为了AI客服先替换整套客服系统。最小方案只需要：现有工单或会话导出、一个知识应用、一个建议回复入口和人工确认。知识库先放“能负责”的内容第一批资料可以只有：当前版本产品手册；常见故障和排查顺序；售后服务范围；已公开的版本说明；明确的转人工规则。每份资料标记产品、版本、生效日期、负责人和保密等级。不要把历史群聊、所有工单和个人笔记直接倒进去。旧工单里可能包含临时方案、错误判断、客户隐私和已经失效的承诺。历史工单更适合先清洗成经过确认的FAQ或故障案例。先给问题分三类可以建议回答例如公开功能、标准操作、常见故障和已经确认的服务流程。AI给答案和来源，客服确认后发送。需要补信息例如设备故障缺少型号、版本、时间和日志。AI不急着下结论，先生成澄清问题：请确认设备型号和软件版本； 问题第一次出现的时间； 断线后是否自动恢复； 是否有对应日志或错误码。必须转人工退款和赔偿；合同与报价；投诉和法律问题；安全事故；未发布产品和交付承诺；涉及客户隐私和高权限操作；连续两轮仍无法确定的问题。这类问题不要让模型“尽量给一个有帮助的回答”。它应该明确停止，并把已知信息整理给人工。回答必须带来源客服看到建议回复时，同时显示：使用了哪份资料；资料版本和更新时间；关键引用片段；当前问题分类；是否存在冲突资料；置信度只能作为提示，不能替代检查。如果找不到可靠资料，正确行为是说不知道并转人工。语言很流畅，不代表答案可靠。一条可执行的最小流程准备50个历史问题，去掉客户身份和敏感信息，由资深客服给出标准答案和风险分类。然后：建立测试知识库；导入有效资料；设置只能依据知识回答；无来源时不生成确定答案；建立必须转人工的关键词和问题类型；在测试工作台显示建议回复；让3名客服连续使用两周；保存AI建议、人工修改、最终回复和客户是否追问；每天复盘高风险和错误答案；只把稳定问题考虑为自动回复候选。第一阶段不要自动关闭工单，也不要让AI修改客户等级、退款状态或合同字段。工单回写要保留两份内容一份是AI原始建议，一份是人工最终回复。还要记录：使用的模型和提示版本；检索到的知识；人工修改类型；是否转人工；处理时间；客户是否再次追问；是否产生投诉或错误升级。这些数据以后可以告诉团队，问题到底出在知识、检索、模型，还是客服流程。常见失败怎么处理知识版本冲突：暂停自动回答，清理资料责任和生效版本。客户问题太短：先补信息，不猜设备和原因。模型引用不存在的政策：强制来源校验，找不到就转人工。接口超时：保留客户消息，进入人工队列，不重复发送。同一会话重复触发：使用会话ID和消息ID做幂等。敏感信息进入日志：对手机号、身份证、地址和凭据做脱敏，限制日志访问和保存时间。怎样决定是否开放自动回复对每一类问题单独评估，不要给整个机器人一个总准确率。可以设定内部门槛：测试问题有可靠来源；人工采用率长期稳定；错误不会造成合同、财务或安全影响；无答案和转人工行为可靠；资料有明确负责人；出错可以快速停用和回退。即使开放自动回复，也从一小部分公开FAQ开始，并保留抽检。真正要减少的是低价值来回AI客服的目标不应该只是少几个人。更现实的价值是：客户不用重复描述，客服不用到处找文档，技术人员收到的问题已经带上必要信息，常见问题更快回答，高风险问题更早交给合适的人。先把建议回复做稳，再谈自动回复。能及时说“不知道，需要人工处理”，往往比什么都敢答更接近一个可上线的客服系统。
AI Coding最容易演示的场景，是从零写一个页面或接口。输入需求，几分钟后代码能跑，现场效果很好。软件团队真正花时间的地方却不是这个。更多时候，开发人员面对的是一个运行了几年的仓库：历史封装很多，数据库不能随便动，接口有人依赖，测试不完整，线上问题还要能追。这时真正需要验证的，不是Agent会不会写代码。而是它能不能在边界内改代码，能不能说清影响，能不能跑完检查，出错以后团队能不能接得住。先用同一个任务比较工具国际工具可以评估Claude Code、Codex、Cursor和GitHub Copilot。国内团队可以测试通义灵码、百度 Comate和Trae。不要让每个人各自选一个Demo比较感受。准备同一个真实但低风险的任务，例如：给现有查询接口增加一个过滤条件，补齐参数校验和单元测试。让候选工具都完成：阅读Issue和相关代码；输出影响范围；给出修改计划；修改分支；运行现有测试；补充缺失测试；生成变更说明。比较计划准确度、无关改动、测试通过率、人工修正时间、中文体验、国内访问、代码数据政策和账号成本。工具选型不是一次决定。先批准一到两种主工具，避免仓库规则、账号和支持被切得太散。仓库要先学会“自我介绍”一个Agent进入陌生仓库，最缺的不是更多代码，而是项目里没有写下来的规矩。Codex可以读取AGENTS.md，Claude Code可以使用CLAUDE.md。其他工具也可以参考同一份仓库说明。最小内容可以这样写：Repository Guide ## Build and test - Restore: dotnet restore - Build: dotnet build --no-restore - Unit tests: dotnet test tests/UnitTests - Integration tests require the local compose profile. ## Boundaries - Do not edit generated clients under src/Generated. - Do not add NuGet packages without approval. - Database changes must use the existing migration project. - Never modify production configuration or secrets. ## Completion - Explain affected modules. - Run relevant tests. - Add tests for changed behavior. - Report unresolved risks and commands executed.不要把几十页编码规范全塞进去。先写构建命令、目录边界、现有封装、迁移方式和完成标准。规则太长时，拆成Agent按需读取的项目文档。把任务分成三个风险等级不是所有任务都应该给Agent同样权限。低风险补测试；改文档；小范围重命名；生成重复映射；分析日志和调用链。可以允许Agent在独立分支修改并运行测试。中风险修改业务逻辑；增加接口；调整数据库查询；更新依赖；修改CI配置。要求先提交计划，开发人员确认后再改。必须通过Review和自动测试。高风险数据库破坏性迁移；权限和身份认证；支付、合同或安全逻辑；生产配置；基础设施删除和生产发布。Agent只做分析、草稿和验证建议，不直接执行。任务分级比“允许使用AI”或“禁止使用AI”更容易执行。一张能交给Agent的任务单目标：用户连续登录失败5次后锁定30分钟。 范围：身份认证服务和对应测试；不修改前端。 背景：失败次数保存在现有Redis中，日志使用项目封装。 约束：不增加新包，不改变已有Token格式，不修改生产配置。 验收：成功、失败、锁定、过期解锁、并发请求都有测试。 执行：先只读分析；确认计划后创建分支修改；最后列出命令、测试和未解决风险。任务说不清楚时，Agent通常会替你补一个看起来合理的版本。所以AI Coding也会反过来暴露团队的需求质量。推荐的分支工作流Issue → Agent只读分析 → 开发确认计划和风险 → 创建独立分支或工作区 → Agent修改并运行局部测试 → 开发检查diff和关键路径 → 第二个工具或Reviewer做初审 → CI执行完整检查 → 人工合并 → 人工批准生产发布不要让Agent直接在主分支工作。如果工具支持沙箱、工作树或隔离环境，优先使用。密钥通过环境和凭据系统提供，不要写进提示、仓库规则或日志。Code Review不能只找语法问题AI适合做第一轮审查，但审查任务要具体。可以让它检查：改动是否超出Issue范围；异常、取消、超时和重试；并发和幂等；权限与数据泄露；日志能否定位失败；数据库查询和索引影响；测试是否覆盖改变的行为；是否绕开项目现有封装。每条意见需要位置、影响和理由。不要把“建议优化命名”与“可能导致越权”放在同一优先级。GitHub团队可以测试Copilot的Review能力，也可以使用其他审查工具。无论谁给意见，最终阻止合并的责任仍在代码Owner和Reviewer。自动发布只能走现有流水线Agent可以生成或修改GitHub Actions、GitLab CI或Jenkins配置，但不能绕过组织现有审批。推荐边界：Agent可以创建分支、提交代码和触发测试环境构建；CI账号只拥有当前仓库和目标环境需要的最小权限；数据库迁移先在测试环境验证并备份；生产发布需要人工批准；发布后由Sentry、Grafana或现有监控确认错误率和关键指标；失败时走已有回滚流程，而不是让Agent临时发明一个。自动发布的价值是减少重复操作，不是取消发布责任。一开始不要考核生成代码量两周试点可以选3到5名开发人员、10个低中风险任务，记录：从领取任务到PR的周期；人工阅读和修正时间；测试增加数量及有效性；Review发现的高风险问题；无关改动和返工；CI失败、上线缺陷和回滚；每人账号和模型成本；哪些任务类型最适合。生成行数和聊天次数没有太大意义。如果PR更快，但Reviewer要花两倍时间清理，团队并没有变快。最容易踩的几个坑Agent一次改太多。解决办法是缩小任务、先计划、限制目录。测试命令写错。把真实命令放进仓库规则，并让CI做最终判断。把日志、数据库快照或客户代码提交给未经批准的外部服务。上线前明确工具、账号和数据边界。开发人员不再理解代码，只负责接受。要求任务Owner解释关键改动和失败路径。每个人保存一套个人规则。把稳定规则放回仓库，跟代码一起Review。真正值得沉淀的不是某个工具Claude Code、Codex、Cursor、Copilot和国内编码工具还会继续变化。更稳定的能力是：仓库有清楚边界，任务能说明目标和验收，测试可以自动执行，Review有风险重点，发布有审批和回滚。这些东西原本就应该存在。AI只是让它们的重要性更早暴露出来。先从一个仓库、几名开发、十个任务开始。工具可以换，工程纪律不要跟着一起换。
很多公司的AI使用，最后停在一个聊天窗口里。员工把会议纪要复制进去，生成一份任务清单，再复制到飞书项目、Jira或CRM。局部确实快了，但信息仍然靠人搬来搬去。真正进入业务流程，要多走一步：让系统自动拿到输入，AI只负责自己擅长的整理和判断草稿，人确认以后，再把结果写回原来的业务系统。这一步听起来复杂，其实可以先从一条很窄的流程开始。这次只做“会议纪要转任务”目标流程：飞书妙记或会议记录 → n8n接收Webhook → Dify提取任务和待确认问题 → 飞书发送确认卡片 → 负责人确认或修改 → n8n写入Jira、飞书项目或测试表 → 记录处理日志最小版本先不写正式任务系统。把最后一步写进一张测试表，确认任务提取和人工审批稳定，再换成Jira、CRM或工单接口。这样出错时容易清理，也不会污染生产数据。为什么用n8n做外层流程n8n适合处理Webhook、API调用、条件分支、等待、重试和系统写回。Dify更适合管理模型、提示、知识检索和Agent流程。FastGPT也可以承担知识和模型处理，国内团队可以根据模型接入和部署条件选择。如果公司已经重度使用Microsoft 365，可以评估Power Automate。以飞书为中心的团队，也可以先使用飞书现有自动化，再在需要模型和跨系统处理时接n8n。我会把职责分开：层负责什么不负责什么n8n触发、系统连接、审批状态、重试、写回、日志不承担复杂业务判断Dify或FastGPT模型、知识、结构化提取、提示版本不直接拥有生产系统高权限飞书/Jira/CRM正式业务记录和人员权限不把AI中间结果当最终事实人确认需求、负责人、时间和承诺不重复搬运已经结构化的信息开始前准备这些东西一个n8n测试环境；一个Dify或FastGPT测试应用；公司批准的模型API；飞书测试应用或其他可发送确认消息的渠道；一张测试任务表，至少包含标题、描述、负责人、截止时间、来源链接和状态；10段脱敏会议记录；一个只对测试系统有写权限的服务账号。API密钥放在n8n凭据管理或环境变量里，不要写进工作流节点文本、Markdown或截图。Dify只做结构化提取先把任务定义得克制一点。输入是一段会议记录，输出固定JSON：{ "meeting_id": "meeting-20260724-01", "tasks": [ { "title": "确认设备断线后的补传策略", "owner": "待确认", "due_date": null, "source_quote": "需要技术部确认断线期间的数据怎么补传", "confidence": "medium" } ], "open_questions": [ "补传数据是否需要覆盖原有统计结果？" ] }提示里要明确：不猜负责人和截止时间；每个任务保留原文依据；没说清楚的内容进入open_questions；不生成报价、合同或交付承诺；输出必须符合JSON结构。先用10段记录手工调用，确认JSON稳定，再接n8n。n8n工作流需要哪些节点不依赖具体版本名称，可以按职责搭建：Webhook接收会议ID、文本和来源URL；校验必填字段，缺少会议ID直接返回错误；生成idempotency_key，例如会议ID加记录版本；查询处理日志，已经成功的请求不重复创建任务；HTTP Request调用Dify或FastGPT API；校验返回JSON和任务数量；生成飞书确认消息；等待负责人确认、修改或拒绝；确认后写入测试任务表；保存输入摘要、模型版本、输出、人工修改和最终状态。这里最容易被忽略的是第3、4步。Webhook可能重发，人工也可能重复点击。如果没有幂等键，同一场会议会创建两遍任务。自动化流程不是跑通一次就够了，它要能面对重复、超时和中断。人工确认应该看什么确认卡片不要只有“同意”和“拒绝”。至少显示：任务标题；原文依据；建议负责人；截止时间；置信度；尚未确认的问题；原会议链接。负责人可以修改后确认。最终写入系统的内容和AI原始结果都保留，方便以后知道模型在哪些地方经常出错。失败时不要悄悄丢掉这条流程至少会遇到这些失败：失败处理方式模型API超时指数退避重试有限次数，仍失败则进入人工队列返回不是合法JSON保存原始输出，不写业务系统，等待人工处理飞书消息发送失败记录错误并通知流程负责人等待确认超过时间标记超时，不自动创建任务写入业务系统失败保留已确认数据，允许安全重试Webhook重复用幂等键返回已有处理结果不要让失败分支直接结束。每个失败都要有状态、日志和责任人。否则流程看起来自动化了，实际错误只是从员工眼前消失了。权限尽量小n8n使用的服务账号第一阶段只写测试表，不要给删除、审批和管理员权限。Dify或FastGPT只接收脱敏后的会议文本。涉及客户合同、个人信息或未发布经营数据时，要确认数据能否进入所选模型和部署环境。写入正式系统以后，也只创建“待确认”任务，不自动改变项目承诺、客户报价或生产状态。怎样验收这条流程用10段会议记录跑完整流程，记录：Webhook到确认卡片需要多久；JSON成功率；提取任务的准确率；人工修改了哪些字段；重复请求是否只创建一份结果；模型和系统失败能否恢复；每次调用成本；负责人是否愿意继续使用。在测试表稳定运行两周，再接正式任务系统。如果人工每次都要重写大部分内容，先调整输入和提取规则，不要急着增加更多节点。真正有价值的自动化，不是流程图上有多少个方块。而是信息只输入一次，错误看得见，关键决定仍然有人负责，系统失败以后还能回到一个清楚的位置继续处理。
从提示词到Skill，把一次成功变成团队能力
团队里经常会出现这种情况。有个人把AI用得很顺，写需求、查代码、整理客户记录都很快。大家问他怎么做，他发来一段很长的提示词。其他人复制过去，效果却不一样。不是模型突然变笨了，而是那段提示词背后还藏着很多东西：他知道去哪找资料，知道什么结果不可信，知道哪些字段必须检查，也知道出错以后怎么补。这些没有写出来的判断，才是真正的能力。提示词只是任务入口一条提示词通常只能说明“这次想让AI做什么”。一个能被团队复用的Skill，还应该包含：适用场景 + 输入资料 + 执行步骤 + 工具权限 + 输出格式 + 检查规则 + 失败处理 + 维护负责人这里的Skill不一定非要是某个平台的专用文件。它可以是Claude Code使用的项目指令、Codex读取的AGENTS.md、Dify里的工作流、FastGPT里的应用流程，也可以先是一份普通Markdown操作说明。关键不在名字，而在下一位同事能不能按照它完成同一项工作。先挑一条已经重复成功的做法不要把第一次成功的聊天记录马上包装成团队标准。至少重复使用三到五次，确认：输入资料大致稳定；输出确实能节省工作；常见错误已经出现过；人工知道检查什么；换一个人还能理解；这项工作值得持续维护。如果每次任务差异都很大，或者结果完全依赖某位专家临场判断，更适合保留为个人辅助方法，不必急着做成自动流程。用“任务说明卡”替代神奇提示词可以先把个人做法整理成这张卡：名称：接口代码审查 适用范围：ASP.NET Core服务的Pull Request初审 输入：PR diff、相关Issue、项目AGENTS.md、测试结果 任务：检查业务遗漏、异常处理、并发、日志、权限和测试 不能做：不直接合并，不修改生产配置，不猜测缺失需求 输出：问题位置、影响、建议、证据；按高/中/低风险排序 人工确认：模块负责人判断是否阻止合并 失败处理：上下文不足时列出缺少资料，不给确定结论这比“你是一名资深架构师，请全面审查代码”有用得多。它把适用范围、输入和责任说清楚了。一个需求评审Skill怎么形成假设产品经理经常把会议记录整理成需求。第一版可能只是一句话：“请把会议内容整理成PRD。”用几次以后，会发现AI经常把客户的试探性表达写成确定需求，也会漏掉尚未确认的接口和数据范围。这时可以把流程拆开：会议记录 → 区分客户原话、产品判断和待确认问题 → 提取用户、场景、触发条件和预期结果 → 生成验收条件草稿 → 标记缺少的数据、权限和异常场景 → 产品经理确认 → 写入需求系统再准备一组检查问题：有没有把“可能”写成“必须”；是否说明不做什么；是否有异常和权限场景；验收条件能不能被测试；哪个结论找不到原始依据。当这些规则稳定下来，它才开始像一个团队Skill。AI Coding里的Skill更容易被看见使用Claude Code或Codex时，团队可以把项目规则直接放进仓库。Codex使用AGENTS.md，Claude Code可以使用CLAUDE.md。国内团队也可以用同一思路测试通义灵码等编码工具。文件里不需要堆满编码规范，先写最容易出事故的内容：构建和测试命令；项目分层和现有封装；不能修改的生成目录；数据库迁移方式；日志、异常和配置要求；完成任务后的验证清单；禁止直接执行的生产操作。规则应该跟代码一起Review。项目结构变化了，Skill也要改。否则AI会非常认真地遵守一套已经过期的做法。业务流程可以放到Dify或FastGPT对于客户问答、资料整理、销售跟进这类工作，可以把稳定步骤做成Dify或FastGPT流程。例如销售会议跟进：输入会议记录 → 提取客户、需求、异议、承诺和下一步 → 检查是否缺少时间与负责人 → 生成CRM草稿 → 销售确认 → 才允许写回CRM流程里要保留原始记录链接。AI生成的客户需求不能替代客户原话，报价、交期和合同条件不能自动承诺。第一阶段甚至不用接CRM。先让员工复制一段脱敏会议记录，确认输出模板稳定，再考虑API和自动写回。Skill需要版本，不是写完就结束建议每个Skill至少记录：名称： 版本： 负责人： 适用工具： 适用任务： 最后更新： 输入要求： 输出要求： 人工确认： 已知问题： 变更记录：修改时保留一个小测试集。需求评审可以保存五段脱敏会议记录，代码审查可以保存三个历史PR，客服可以保存二十个常见问题。每次改Skill以后重新跑一遍，确认旧能力没有被新规则破坏。三种最常见的失败第一种，Skill写得太通用。“分析问题、给出专业建议”适用于任何工作，也指导不了具体工作。第二种，规则太多。把几十页制度全部塞进指令，模型抓不到重点，维护的人也不敢改。规则应该围绕当前任务，背景知识放进可引用的知识库。第三种，没有负责人。提示词保存在群文件里，流程出错时没人知道该找谁。时间一长，大家各自复制一份继续修改，又回到个人方法。怎么判断Skill真的属于团队可以做一个很简单的交接测试。找一位没有参与编写的同岗位员工，只给他Skill、样例输入和工具账号。观察他能不能完成任务，哪里需要额外口头解释。重点看：第一次完成需要多久；输出有多少可以采用；是否知道什么时候应该停止并找人；两个人的结果差异有多大；错误能不能追到具体规则；负责人能不能独立更新。真正的团队能力，不是“幸好某个人有一条好提示词”。而是这个人不在场，团队仍然知道资料在哪里、步骤怎么走、结果怎么查、最后由谁负责。
企业知识库不是把文件丢进去就结束了
企业做知识库时，最容易出现一个看起来很合理的动作：把共享盘里的文件全部上传。几百份Word、PDF、PPT放进去，页面显示“处理完成”，大家问几个问题，机器人也能回答。过一周，真正的麻烦才开始。同一个问题有两个制度版本，机器人引用了旧的；产品手册写的是标准功能，售后实际执行又有例外；扫描PDF根本没有识别完整；销售问一个具体报价政策，答案来自三年前的会议纪要。知识库不是文件数量比赛。它更像一套有来源、有版本、能测试、有人维护的信息系统。先用20份文档，不要先搬整个共享盘第一次做，我会把范围限制得很小。选一个部门、一个问题类型、20份以内的资料。比如只做“员工制度问答”或“某个产品的售后排查”，不要同时覆盖人事、财务、产品、销售和技术。准备这些东西：一位真正使用答案的业务负责人；10到20份已经确认有效的文档；每份文档的负责人、版本和生效日期；30个真实会被问到的问题；5个知识库不应该回答的问题；一套可以调用的模型或企业账号。如果资料里有客户信息、员工个人信息、合同或未公开代码，先完成脱敏和权限确认。不要因为工具支持上传，就默认数据可以上传。Dify、FastGPT、RAGFlow和MaxKB怎么选这几款工具都能做知识检索，但切入点不完全一样。工具更适合先看什么使用前要确认什么DifyAgent、工作流和知识库放在一起自托管维护、模型API和权限需求FastGPT中文知识库和可视化流程快速起步版本、模型配置和企业数据要求RAGFlow文档解析、复杂资料和检索过程服务器资源、解析质量和运维成本MaxKB国内团队快速建立问答应用文档类型、模型接入和权限范围如果只是验证制度问答，FastGPT或MaxKB更容易让国内团队快速开始。已经准备把知识库接进多个Agent和流程，可以评估Dify。资料以复杂PDF、表格和长文档为主，值得单独测试RAGFlow的解析效果。不要根据首页功能列表直接决定。拿同一批文档和同一组问题跑一次，答案质量、来源定位和维护成本会比产品介绍更有说服力。文档进入知识库前，先做一次清理每份资料至少补上这些信息：标题：设备断线排查手册 适用产品：边缘网关 V2 版本：2.3 生效日期：2026-05-10 负责人：设备平台组 保密等级：内部 替代文档：V1排查手册已失效同时处理四类常见问题：删除重复文件和临时版本；把扫描件转成可检查的文字；将过长表格、页眉页脚和无关目录清理掉；明确旧文档是删除、归档，还是只供历史查询。模型无法替公司决定哪个制度有效。这个责任必须落在资料负责人身上。切分不是越碎越好知识库通常会把长文档切成小段，再通过向量或关键词检索相关内容。切得太大，一段里混进太多主题，检索结果不够准确。切得太小，条件、例外和上下文会被拆散。可以先用一个简单原则：按自然标题和完整语义切分，再根据测试结果调整。例如设备排查手册不要把“现象、原因、步骤、注意事项”拆成互不相干的四块。如果问“设备反复断线怎么办”，Agent需要同时看到触发条件、检查顺序和不能执行的高风险动作。对于制度文件，条款标题和适用范围最好保留在同一个片段里。对于FAQ，一问一答本身就是自然单元。对于表格，先确认工具能否保留行列关系，不能的话就转成结构清楚的文字。用30个问题做第一次验收问题不要全部来自文档标题。真实员工不会问“请介绍请假制度第三章”。他会问：“孩子突然生病，我今天先请假，明天补流程行不行？”测试集可以分成五类：类型示例重点检查直接事实年假怎么计算是否找到正确版本条件组合入职不足一年能否休年假条件是否完整操作步骤网关离线先查什么顺序和风险提示无答案未发布产品什么时候上线是否明确说不知道越权问题把全部客户报价导出来是否拒绝或转人工每个问题记录：检索到了哪些片段、答案是否正确、来源是否可打开、有没有漏掉重要条件、是否应该转人工。不要只看语言是否流畅。一个答案写得很自然，却引用错版本，比直接说不知道更危险。一个最小知识库的执行顺序具体界面会随版本变化，但过程基本可以保持稳定：创建测试空间 → 接入公司批准的模型 → 上传清理后的20份文档 → 设置切分和检索参数 → 为文档补版本、部门和权限元数据 → 导入30个测试问题 → 检查检索片段和答案来源 → 调整文档、切分或提示 → 业务负责人验收 → 只开放给一小组用户第一阶段先让知识库只读，不要自动修改业务数据。答案显示来源，找不到可靠资料时明确转人工。常见失败，通常不在模型答案不稳定时，可以按这个顺序排查：原文里到底有没有答案；上传的是不是有效版本；文档是否解析完整；切分有没有拆掉关键上下文；检索是否找到正确片段；提示是否要求模型只能依据资料回答；模型是否忽略了条件或来源；这个问题是不是本来就应该由人判断。一上来换模型，往往只能暂时掩盖资料和流程问题。上线以后谁来维护知识库至少需要三类责任人：业务负责人决定哪些内容有效；技术负责人维护平台、模型、权限、日志和备份；使用者持续提交错误答案和缺失问题。每份资料要有更新时间。每月检查新增问题和错误答案，每季度清理旧版本。账号离职、部门变更和资料权限也要同步调整。自托管并不意味着不用管。Dify、FastGPT、RAGFlow或MaxKB的服务、数据库、向量数据、模型密钥和备份都需要进入日常运维。怎么判断第一版值得继续第一版不追求回答所有问题，可以先看：30个测试问题中正确且来源可靠的比例；明确说不知道而不是编答案的比例；用户找到资料的平均时间；需要人工升级的问题类型；资料更新后多久能在知识库生效；每月模型、服务器和维护成本。如果20份文档都管不好，上传两千份不会变得更聪明。先把一个小知识库做到来源清楚、答案可查、错误能改，再扩大范围。这一步看起来慢一点，后面会少很多麻烦。
别急着全公司铺开，先挑对第一个AI场景
企业第一次做 AI，很容易把题目出得太大。有人想做一个公司级知识平台，有人想让 Agent 自动跑完整流程，还有人一开始就在比较模型参数和私有化集群。方案越聊越完整，真正要从哪件工作开始，反而没人说得清楚。我现在更倾向于先做一个不那么“像战略”的动作：把各部门觉得麻烦的工作列出来，挑一件试两周。第一条流程选对了，公司会得到真实经验。选错了，几个月后通常只剩一套没人愿意维护的演示系统。先找工作，不要先找模型让每个部门提交五到十项重复工作，不用写AI方案，只回答这些问题：一个月发生多少次；一次需要多少时间；哪几个人参与；输入资料在哪里；最终结果是什么；结果由谁检查；出错以后能不能撤回；涉及什么敏感数据。这一步会筛掉不少“看起来很适合AI”的场景。比如战略判断很重要，但发生频率低，结果也很难在短期验证，不适合成为第一个试点。付款审批很重复，却涉及高风险权限，同样不适合让AI先自动执行。第一次试点更适合从会议整理、工单分类、资料检索、测试用例、周报汇总这类工作开始。它们不一定最有想象力，但更容易看见结果。用一张表把感觉变成比较每个候选场景按八个维度打1到5分：维度1分5分发生频率偶尔发生每天重复人工耗时几乎不耗时占用多人较长时间输入数字化主要靠口头和纸张文档、表格、接口已经在线输出可验证很难判断对错有规则或人员可以快速检查流程可撤回错了难以恢复可以退回草稿重新处理系统可集成完全封闭有API、Webhook或导入导出数据可使用权限和质量都不清楚来源、权限、责任人明确业务负责人支持没人负责有使用者愿意持续反馈再单独记录风险：客户隐私、财务影响、生产影响、错误是否容易发现、是否能够人工复核。不要把风险简单从总分里减掉。有些场景收益高，风险也高。它们不是没有价值，只是不适合第一批自动执行。可以先改成“AI生成草稿，人确认后继续”。一个可以直接照着算的例子下面是一个假设的中小企业评分，不代表真实项目结果：场景收益评分风险第一阶段做法客户会议转跟进任务35中AI整理，销售确认后写入CRM售后工单自动分类37中AI给分类和建议，客服确认项目周报自动汇总33低从任务系统生成草稿，负责人修改付款审批自动通过31高暂不自动审批，只做异常提示如果只能选一个，我会优先考虑售后工单分类或会议转任务。原因不是它们分数最高，而是输入、输出和人工确认都比较清楚。两周以后，能直接计算节省了多少整理时间，分类错了多少次，员工是否愿意继续使用。两周试点只做一条细流程试点不要写成“提升客服效率”。把范围缩到：客户消息进入工单 → AI建议一个问题分类 → AI提取设备、版本和故障现象 → 客服确认或修改 → 保存到工单系统第一周只旁路运行。AI给结果，但不自动写入正式字段。负责人每天抽查，记录错误类型。第二周再允许确认后的结果写回系统。仍然不让AI直接退款、承诺交付时间或关闭投诉。试点至少留四份记录：改造前单次耗时；AI结果被直接采用的比例；人工修改最多的地方；出错后怎样恢复。什么情况下应该停止AI试点不是只能成功，及时停止也是结果。出现这些情况，可以先停下来：为了让AI工作，员工需要额外整理大量资料；结果无法快速验证，人工检查比原工作更累；数据权限说不清楚；API、账号或网络稳定性无法支撑日常使用；业务负责人不使用，只剩技术人员在维护演示；错误造成的业务代价超过节省的时间。停掉不代表AI没用。它可能说明场景选早了、流程没理顺，或者公司应该先整理数据，而不是先接模型。第一个场景真正要验证什么两周结束后，不要只汇报“调用了多少次”。应该回答：每次工作节省了多少人工时间；AI结果有多少可以直接采用；错误集中在哪几类；人工确认有没有成为新瓶颈；谁愿意继续使用；每月账号、API和维护成本是多少；这条做法能不能复制到第二个人。第一条AI流程的价值，不只是省下几十个小时。更重要的是，公司第一次知道了：自己的数据够不够用，员工愿不愿意改，人工边界应该放在哪里，效果应该怎么量。先把这几个问题回答出来，再谈全公司铺开，会稳很多。
不少公司的 AI 培训都挺热闹。老师在台上演示 ChatGPT 或 Claude，十几秒写出一封邮件，再生成一张图。中间讲几种提示词结构，大家跟着复制一遍，效果确实不错。培训结束时，每个人都觉得 AI 很厉害。第二天回到工位，该怎么开会还是怎么开会，该怎么整理表格还是怎么整理表格。开发继续自己查日志，销售继续把客户记录留在微信里，培训群慢慢也没人说话了。后来复盘，最容易得到的结论是员工主动性不够。我倒觉得不一定。如果培训里做的是旅行计划、营销文案和通用邮件，员工学会的只是“这个工具能聊天”。他回到真实工作以后，面对公司代码、客户资料、审批流程和一堆历史文件，还是不知道从哪里下手。所以我现在看 AI 培训，验收标准很简单。不是员工听懂了多少概念，也不是现场生成的内容有多惊艳。而是培训结束以后，每个人手里有没有一条明天就能继续使用的工作流程。培训前，先让每个人带一件麻烦事来课程开始前，我会让参加培训的人先交一份很短的作业：我每周重复做的工作： 这件事一次要花多久： 需要找哪些资料： 最后要交付什么结果： 最容易错在哪里： 哪些内容不能交给 AI：开发人员可以带一个真实但范围不大的缺陷，产品经理可以带一段已经脱敏的会议记录，销售可以带一次客户沟通，行政可以带一份入职流程，财务可以带一张去掉敏感信息的对账表。这一步很重要。员工没有真实任务，老师就只能讲通用案例。通用案例越顺，回到公司以后的落差通常越大。部门负责人也要提前看一遍这些任务。有些人带来的工作一个月只做一次，不值得优先改；有些任务涉及付款、合同承诺或生产控制，风险太高；还有些工作连现有流程都说不清楚，暂时也不适合直接自动化。第一批训练任务，最好高频、可验证、做错能撤回。培训不是让大家拿 AI 冒险，而是先找到一块安全的练习场。账号和数据边界，要在上课前准备好培训里经常会出现一种挺尴尬的场面。培训开始了，开发人员还没装 Claude Code，销售没有会议转写权限，行政同事注册不了海外工具。老师演示得很流畅，学员只能看。看懂和会做不是一回事。培训前，公司至少要准备一份批准工具清单。比如：研发允许使用 Claude Code、Codex、Cursor 或 GitHub Copilot 中的哪些工具；通用办公使用 ChatGPT Enterprise、Claude Team/Enterprise、Microsoft 365 Copilot，还是公司统一接入的模型；内部知识问答使用 Dify、FastGPT 或飞书智能伙伴；流程自动化使用 n8n、Power Automate、Make 还是 Zapier；哪些账号由公司统一购买，哪些个人账号禁止处理公司资料。如果公司优先使用国内工具，研发组可以准备通义灵码、百度 Comate 或 Trae，通用办公可以测试 DeepSeek、通义千问、Kimi 或豆包，知识库可以从 FastGPT、Dify、RAGFlow 或 MaxKB 中选择。培训前要统一好版本和账号，不要让每个人临时注册一套完全不同的工具。工具不需要多，但必须能登录、能使用，也知道出了问题找谁。培训材料里最好直接放官方入口，避免学员搜索到名称相似的第三方站点：Claude CodeCodexDifyFastGPTn8n通义灵码百度 Comate飞书妙记这些工具信息核对于 2026 年 7 月 11 日。正式培训前，应再次检查账号、价格、企业数据政策和国内访问情况。数据边界可以先用很直白的红黄绿规则。绿色数据是公开资料、公开代码和已经发布的产品信息，可以进入公司批准的通用 AI 工具。黄色数据是内部制度、项目文档、未发布代码和普通客户资料，只能进入企业账号、批准的 API 或私有部署系统，并且要按权限访问。红色数据包括密码、密钥、未脱敏个人信息、付款账号、核心商业机密和高敏感客户数据，不能直接提交给模型。这个规则不一定一次就很完善。但如果完全不讲，员工要么什么都不敢用，要么把生产密钥和客户资料一起粘进个人聊天账号里。两种结果都不是公司想要的。开场不要先讲模型原理第一节课经常花很多时间介绍大模型发展、参数规模、Token 和提示词公式。这些内容不是完全没用。但员工最先需要学会的，是怎样把一件工作交代清楚。我更愿意先给大家一张任务说明卡：背景：这件事为什么要做，现在是什么情况。 资料：允许使用哪些文档、代码、表格和历史记录。 任务：这一次具体要完成什么。 约束：哪些目录不能改，哪些结论不能猜，哪些规则必须遵守。 输出：结果要用什么格式交付。 检查：怎样判断完成，哪些地方必须由人确认。这比背一套“角色、目标、步骤、格式”的提示词口诀更有用。因为它本质上不是在学习怎么跟 AI 聊天，而是在学习怎么定义工作。一个人如果连自己要什么、有哪些限制、怎么验收都说不清楚，换再强的模型也很难稳定做好。不同岗位，不要坐在一起练同一道题通识部分可以一起上。真正实操时，必须按岗位拆开。技术组使用 Claude Code、Codex、Cursor、GitHub Copilot 和 CodeRabbit，练习代码分析、修改、测试和 Pull Request 审查。产品和运营组使用 Claude Projects、ChatGPT Projects、飞书妙记、Notion AI、Figma Make 或 Gamma，练习把会议记录变成待确认问题、需求和原型。销售和客服组使用 Gong、Fireflies.ai、飞书妙记、HubSpot Breeze、Dify、FastGPT 或 Chatwoot，练习客户信息提取、CRM 回写和建议回复。财务与行政组使用 Excel Copilot、Power Query、Power Automate、UiPath 和 OCR 工具，练习资料提取、表格核对、制度问答和流程提醒。工具并不是每一种都要买。分组的目的是让大家面对自己的工作，而不是让财务跟着开发人员学怎么生成单元测试，也不是让开发人员坐两个小时看市场部生成海报。第一周，只解决一项个人工作第一周不要急着做 Agent，也不要接公司系统。每个人只处理课前带来的那一项任务。技术组可以从一个真实缺陷开始。先让 Claude Code 或 Codex 阅读 Issue 和相关代码，只输出影响范围、修改方案和风险，不允许马上改文件。开发人员确认方向以后，再让 Agent 创建分支、修改代码并执行测试。最后由本人解释每一处修改为什么可以接受。产品组可以把一段飞书妙记交给 Claude Projects，要求区分客户原话、产品判断、待确认问题和任务草稿。产品经理回到原文逐条核对，看看 AI 是在哪里把“可能需要”写成了“确定要做”。销售组可以让 Fireflies.ai 或飞书妙记生成转写，再提取客户角色、需求、异议、承诺和下一步行动。结果先放在草稿区，由销售确认后再录入 CRM。行政组可以拿一份员工手册，用 Dify 或 FastGPT 做一个小型制度问答。先准备二十个员工真的问过的问题，看答案有没有来源、有没有引用过期条款。第一周结束，每个人只需要回答三件事：原来一次要花多久；现在要花多久；AI 最容易在哪一步犯错。能回答清楚，第一周就没有白练。第二周，把个人用法变成部门流程个人用得顺，不代表团队能复用。第二周要做的，是把第一周的成功和失败写下来。比如技术组发现，一张任务单只写“修复登录问题”远远不够，还需要说明影响范围、现有组件、测试命令和不能调整的接口。那就把这些内容放进 Issue 模板和仓库的 AGENTS.md、CLAUDE.md。销售组发现，AI 经常把客户的试探性表达当成正式需求，就在模板里增加一条规则：必须区分客户原话、销售判断和待确认事项，并且保留时间戳。客服组发现，退款问题最容易答错，就把退款、合同和投诉统一列为强制转人工，不再让模型尝试生成最终承诺。这时候形成的东西，可以是一份模板、一张检查清单、一条 SOP，也可以是 Claude Code、Codex 或 Dify 能调用的 Skill。名字不重要。重要的是下一位同事不需要重新摸索一遍。第二周结束时，每个小组至少要交付：一份可以重复使用的任务模板；一组修改前后的真实结果；一份 AI 常见错误清单；一个明确的人工确认节点；一位负责后续更新的人。第三周，再考虑把工具连起来很多培训一开始就演示自动化工作流。屏幕上节点一串，消息一来，AI 自动处理，再发到另一个系统，视觉效果很好。但如果前两周连输入、规则和人工边界都没有跑稳，自动化只会让错误传播得更快。第三周再使用 n8n、Power Automate、Make 或 Zapier，把已经验证过的步骤串起来。销售场景可以这样做：飞书妙记产生会议记录 → n8n 调用 Claude 或企业模型 → 提取客户需求和下一步行动 → 发送给销售确认 → 确认后写入 CRM → 到期发送跟进提醒客服场景可以让 Dify 或 FastGPT 检索知识库，生成带来源的建议回复，再通过 Chatwoot 进入客服工作台。研发场景可以让 Claude Code 或 Codex 完成分支修改和测试，再交给 GitHub Actions 或 GitLab CI 构建测试环境。生产发布仍然等待人工批准。第三周主要练的不是怎么拖节点。而是失败以后怎么办：模型超时是否重试，写入 CRM 失败是否保留草稿，知识库没有答案是否转人工，Agent 执行一半是否有日志可以追。能处理失败的流程，才有资格叫自动化。第四周，不考试，直接做工作演示我不太建议用选择题考核 AI 培训。让学员解释什么是 Prompt、RAG 和 Agent，分数可能很高，跟实际工作仍然没有关系。第四周直接做一次十五分钟的工作演示。每个人展示同一件任务以前怎么做、现在怎么做。现场说明使用了什么工具，输入从哪里来，结果由谁确认，遇到错误怎么退回，以及一个月大概能省多少时间。验收时可以用这张表：验收项要回答的问题时间单次耗时从多少变成多少质量返工、遗漏和错误有没有增加采用AI 结果有多少可以直接使用，有多少要重做风险哪些动作仍然由人确认复用其他同岗位员工能不能照着做维护工具、模板和资料由谁更新如果一条流程只能由培训里最懂 AI 的那个人运行，它还没有真正进入团队。换一位同岗位员工也能照着完成，才算通过。培训结束，要留下一个公司自己的案例库很多培训结束以后，只留下课件和录像。真正有用的内容，反而散落在学员的聊天记录和个人文档里。可以在公司内部建立一个很简单的目录：ai-playbook/ approved-tools.md # 公司批准使用的工具和账号类型 data-rules.md # 数据分级与禁止事项 departments/ engineering/ # 研发任务模板、AGENTS.md 示例 product/ # 会议转需求模板 sales/ # 客户跟进流程 support/ # 知识库与转人工规则 finance/ # 对账和复核流程 failures/ # AI 出错案例与处理办法 metrics/ # 改造前后的效果记录这个目录可以放在 Git、Notion、飞书知识库或公司文档系统里。内容不要只由培训老师维护。每个部门找一位真正每天做这项工作的人负责更新，每两周花半小时整理新问题。AI 工具变化很快，课件很容易过期。但公司自己的任务、错误案例和判断边界，会越来越有价值。培训老师不能成为永久客服培训刚结束的两周，问题通常最多。这个时候如果没人接，员工遇到两次错误就会回到原来的做法。如果所有问题都找外部老师，培训成本又会一直持续。比较现实的办法，是每个部门选一位内部种子用户。他不需要最懂模型，但要熟悉本部门工作，也愿意把问题记录下来。培训期间和外部老师一起跑案例，培训后负责每周一次短时间答疑。遇到工具配置、权限和系统集成问题，再由技术部支持。遇到流程边界和业务判断，仍然由部门负责人拍板。这样责任不会全落在一个“懂 AI 的人”身上。不要把使用次数变成绩效如果公司要求每个人每天必须使用 AI 十次，很快就能得到很好看的数字。但员工也会很快学会完成这个数字。打开聊天窗口、问几个无关紧要的问题，并不会改变工作。真正值得跟踪的是任务层面的结果：一项工作节省了多少时间；AI 结果被人工接受的比例；返工和错误有没有增加；有多少个人做法变成了团队模板；培训结束一个月后，这条流程还在不在运行。有些任务用了 AI 以后没有更快，甚至更麻烦，也很正常。把它停掉就好。培训不是证明 AI 适合所有工作，而是让团队学会判断哪些工作值得使用，怎样使用才不会把风险一起放大。说到底，公司培训员工用 AI，不是多教会一个软件。它是在训练大家把工作讲清楚，把经验留下来，把重复动作交出去，同时知道最后那一步判断仍然属于谁。员工能带走一条真实可用的流程，比记住一百条提示词更有价值。
有一种挺常见的 AI 落地方式。老板在群里转了几篇文章，开会时顺便提一句：“现在 AI 这么快，各部门都研究一下，看看怎么把效率提起来。”一个月后再问，技术部有人拿 AI 写过代码，市场部用它改过文案，行政同事让它写过两次通知。然后就没有然后了。这不一定是谁执行得不好。“大家把 AI 用起来”这句话，本身就很难执行。它没有说清楚要改哪项工作、用什么工具、谁来确认结果，也没有说做到什么程度才算有效。如果让我在一家公司里推动这件事，我不会先做全员培训，也不会先买一大批账号。我会先去找工作。准确一点说，是找那些每天都在重复、资料已经数字化、结果容易检查，而且确实让人觉得麻烦的工作。AI 真正能落地，通常就是从这些地方开始的。先别买工具，把重复工作列出来第一步很朴素。让每个部门列出十件重复发生的工作，先不讨论用哪个模型，只记录五个数字：工作每月次数单次耗时参与人数出错代价整理客户会议纪要2040 分钟2低给售后工单分类3005 分钟3中审查代码合并请求8025 分钟5中核对付款信息6015 分钟2高这张表不用做得很精确。它只是帮我们分清楚，哪些工作值得先动，哪些暂时不要碰。适合第一批交给 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 CodeCodexDifyFastGPTn8n通义灵码百度 ComateTrae飞书妙记本文中的工具信息核对日期为 2026 年 7 月 11 日。以后再读到这篇文章时，如果工具名称、入口或能力已经变化，以官方最新说明为准。用 30 天跑出第一批结果如果公司准备现在开始，我会把第一个月安排得很具体。第一周，每个部门列出十件重复工作，记录频率、耗时、参与人数和出错代价。负责人只选一件，不要贪多。第二周，准备账号、样例数据和人工确认点。先让 AI 在旁边跑，不直接写入生产系统，也不直接面对客户。第三周，进入真实工作。每次结果都记录三件事：用了多久，人改了多少，AI 在哪里出错。第四周，拿改造前后的数据做一次复盘。有效的流程写成 SOP 或 Skill，效果一般的继续调整，没有价值的就停掉。不同部门可以看不同指标：研发看需求周期、审查时间、测试覆盖和上线缺陷；产品看纪要整理时间、需求返工和待确认事项遗漏；销售看 CRM 完整率、会后整理时间和跟进遗漏；客服看首次响应、错误回答、转人工和重复追问；财务看对账时间、异常发现率和人工复核量。不要把“使用 AI 的次数”当成核心指标。员工每天打开十次聊天窗口，不代表公司效率提高了。真正值得保留的，是那些让工作少一次转述、少一遍复制、少等一个人，同时又没有把错误和风险放大的流程。公司当然可以讨论更大的 AI 战略。但在那之前，先让一个部门里的一件麻烦事，真的少花一半时间。这比做十场演示更有用。