付同学的技术客栈 - AI 实践
type: channel
link: https://www.fuanyi.com/category/ai-%E5%AE%9E%E8%B7%B5/
items: AI到底有没有提效，别只看用了多少次
items: 公司用AI，数据和权限的边界怎么定
items: 从零搭一个能上线的AI客服
items: 软件技术部AI Coding落地手册
items: 用n8n和Dify，把AI接进公司的业务流程
items: 从提示词到Skill，把一次成功变成团队能力
items: 企业知识库不是把文件丢进去就结束了
items: 别急着全公司铺开，先挑对第一个AI场景
items: 公司怎么培训员工用上AI
items: 公司怎么把AI真正用起来

AI到底有没有提效，别只看用了多少次
type: item
date: 2026-08-01T12:30:00+00:00
description: 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，数据和权限的边界怎么定
type: item
date: 2026-07-25T12:30:00+00:00
description: 公司开始用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客服
type: item
date: 2026-07-22T12:30:00+00:00
description: AI客服的演示通常很顺。上传产品资料，输入一个问题，机器人几秒钟给出回答。真正接到客户以后，问题就没有那么规整了。客户可能只说一句“设备又掉了”，没有型号、版本和时间。有人会追问退款，有人会把两个故障混在一起，还有人问的是公司从来没有公开过的计划。这时最重要的不是机器人说得像不像客服。而是它什么时候能回答，什么时候必须继续问，什么时候应该马上把人叫进来。第一阶段只做建议回复不要一开始就把机器人放到全部客户面前。先让它进入客服工作台，给人工客服生成建议回复：客户消息 → 识别问题类型和风险 → 检索有效知识 → 生成带来源的建议回复 → 客服确认、修改或转人工专家 → 发送给客户 → 保存最终回复和修改原因这条路径多了一次人工确认，却能快速积累最重要的数据：哪些问题回答稳定，哪些资料缺失，哪些表达经常被客服改掉。等低风险问题稳定以后，再逐步开放自动回复。工具怎样组合知识和Agent层可以使用Dify、FastGPT或MaxKB。跨系统、审批和日志可以使用n8n。客服工作台可以评估Chatwoot这类可集成系统，已有Zendesk、Intercom或国内客服系统的公司优先接现有平台。不要为了AI客服先替换整套客服系统。最小方案只需要：现有工单或会话导出、一个知识应用、一个建议回复入口和人工确认。知识库先放“能负责”的内容第一批资料可以只有：当前版本产品手册；常见故障和排查顺序；售后服务范围；已公开的版本说明；明确的转人工规则。每份资料标记产品、版本、生效日期、负责人和保密等级。不要把历史群聊、所有工单和个人笔记直接倒进去。旧工单里可能包含临时方案、错误判断、客户隐私和已经失效的承诺。历史工单更适合先清洗成经过确认的FAQ或故障案例。先给问题分三类可以建议回答例如公开功能、标准操作、常见故障和已经确认的服务流程。AI给答案和来源，客服确认后发送。需要补信息例如设备故障缺少型号、版本、时间和日志。AI不急着下结论，先生成澄清问题：请确认设备型号和软件版本； 问题第一次出现的时间； 断线后是否自动恢复； 是否有对应日志或错误码。必须转人工退款和赔偿；合同与报价；投诉和法律问题；安全事故；未发布产品和交付承诺；涉及客户隐私和高权限操作；连续两轮仍无法确定的问题。这类问题不要让模型“尽量给一个有帮助的回答”。它应该明确停止，并把已知信息整理给人工。回答必须带来源客服看到建议回复时，同时显示：使用了哪份资料；资料版本和更新时间；关键引用片段；当前问题分类；是否存在冲突资料；置信度只能作为提示，不能替代检查。如果找不到可靠资料，正确行为是说不知道并转人工。语言很流畅，不代表答案可靠。一条可执行的最小流程准备50个历史问题，去掉客户身份和敏感信息，由资深客服给出标准答案和风险分类。然后：建立测试知识库；导入有效资料；设置只能依据知识回答；无来源时不生成确定答案；建立必须转人工的关键词和问题类型；在测试工作台显示建议回复；让3名客服连续使用两周；保存AI建议、人工修改、最终回复和客户是否追问；每天复盘高风险和错误答案；只把稳定问题考虑为自动回复候选。第一阶段不要自动关闭工单，也不要让AI修改客户等级、退款状态或合同字段。工单回写要保留两份内容一份是AI原始建议，一份是人工最终回复。还要记录：使用的模型和提示版本；检索到的知识；人工修改类型；是否转人工；处理时间；客户是否再次追问；是否产生投诉或错误升级。这些数据以后可以告诉团队，问题到底出在知识、检索、模型，还是客服流程。常见失败怎么处理知识版本冲突：暂停自动回答，清理资料责任和生效版本。客户问题太短：先补信息，不猜设备和原因。模型引用不存在的政策：强制来源校验，找不到就转人工。接口超时：保留客户消息，进入人工队列，不重复发送。同一会话重复触发：使用会话ID和消息ID做幂等。敏感信息进入日志：对手机号、身份证、地址和凭据做脱敏，限制日志访问和保存时间。怎样决定是否开放自动回复对每一类问题单独评估，不要给整个机器人一个总准确率。可以设定内部门槛：测试问题有可靠来源；人工采用率长期稳定；错误不会造成合同、财务或安全影响；无答案和转人工行为可靠；资料有明确负责人；出错可以快速停用和回退。即使开放自动回复，也从一小部分公开FAQ开始，并保留抽检。真正要减少的是低价值来回AI客服的目标不应该只是少几个人。更现实的价值是：客户不用重复描述，客服不用到处找文档，技术人员收到的问题已经带上必要信息，常见问题更快回答，高风险问题更早交给合适的人。先把建议回复做稳，再谈自动回复。能及时说“不知道，需要人工处理”，往往比什么都敢答更接近一个可上线的客服系统。

软件技术部AI Coding落地手册
type: item
date: 2026-07-16T12:30:00+00:00
description: 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适合做第一轮审查，但审查任务要具体。可以让它检查：改动是否超出Is…

用n8n和Dify，把AI接进公司的业务流程
type: item
date: 2026-07-11T12:30:00+00:00
description: 很多公司的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只接收脱敏后的会议文本。涉及客户合同、个人信息或未发…

从提示词到Skill，把一次成功变成团队能力
type: item
date: 2026-07-07T12:30:00+00:00
description: 团队里经常会出现这种情况。有个人把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写得太通用。“分析问题、给出专业建议”适用于任何工作，也指导不了具体工作。第二种，规则太多。把几十页制度全部塞进指令，模型抓不到重点，维护的人也不敢改。规则应该围绕当前任务，背景知识放进可引用的知识库。第三种，没有负责人。提示词保存在群文件里，流程出错时没人知道该找谁。时间一长，…

企业知识库不是把文件丢进去就结束了
type: item
date: 2026-06-30T12:30:00+00:00
description: 企业做知识库时，最容易出现一个看起来很合理的动作：把共享盘里的文件全部上传。几百份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个测试问题 → 检查检索片段和答案来源 → 调整文档、切分或提示 → 业务负责人验收 → 只开放给一小组用户第一阶段先让知识库只读，不要自动修改业务数据。答案显示来源，找不到可靠资料时明确转人工。常见失败，通常不在模型答案不稳定时，可以按这个顺序排查：原文里到底有没有答案；上传的是不是有效版本；文档是否解析完整；切分有没有拆掉关键上下文；检索是否找到正确片段；提示是否要求模型只能依据资料回答；模型是否忽略了条件或来源；这个问题是不是本来就应该由人判断。一上来换模型，往往只能暂时掩盖资料和流程问题。上线以后谁来维护知识库至少需要三类责任人…

别急着全公司铺开，先挑对第一个AI场景
type: item
date: 2026-06-27T12:30:00+00:00
description: 企业第一次做 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
type: item
date: 2026-06-22T12:30:00+00:00
description: 不少公司的 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 聊天，而是在学习怎么定义工作。一个人如果连自己要什么、有哪些限制、怎么验收都说不清楚，换再强的模型也很难稳定做…

公司怎么把AI真正用起来
type: item
date: 2026-06-16T12:30:00+00:00
description: 有一种挺常见的 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。不要只比较谁补全代码更快。让它们读取同一个仓库、分析同一个缺陷、执行同一组测试，再比较计划是否准确、修改范围是否克制、测试能不能跑通，以及代码是否会被发送到团队不能接受的位置。技术…