周四晚的线上 AI 沙龙，最有价值的部分，不是展示了某个多厉害的平台。
真正有价值的，是大家一起看见了一件事：普通业务人、流程人、职能同学，已经可以用 AI Coding，把一个浏览器插件改成自己的智能体。
有人想把流程文件生成流程图。
有人想做个人知识库。
有人点开插件配置页，发现按钮打不开，页面报错。于是当场把问题丢回给 AI，让它分析原因、扫描文件、继续修。
这比单纯讲概念更重要。
企业 AI 的分水岭，不是会不会问 AI，而是能不能把一个想法做成可交付的工具。
一、这场沙龙先打破一个误区：会用 AI 不等于会交付 AI
会用 AI，只是入口；能交付工具，才开始接近生产力。
很多企业做 AI 推广，第一反应还是培训员工怎么提问。
怎么写提示词，怎么让 AI 做 PPT，怎么让 AI 改邮件，怎么让 AI 总结会议。
这些当然有用。
但它们多数还停留在“聊天框效率”。你问一句，它答一句。你复制一段，它润色一段。任务结束以后，能力并没有沉淀下来。
这场沙龙真正要讨论的，是另一层问题：
如果 AI 已经能写代码，为什么流程管理人不能做自己的智能体？
这里说的智能体，不一定是一套昂贵平台。
它可以先是一枚插件。
能读取当前页面，能调用模型，能运行一段固定技能，能生成 Word、Excel、PPT、PDF，能把一类高频判断封装起来。
对流程管理人来说，这个门槛刚刚好。
它比纯聊天更接近业务现场，也比从零搭企业级平台更容易起步。
二、插件，是普通人进入智能体开发的第一块砖
插件的价值，不是小，而是离业务现场足够近。
为什么这次从插件开始讲？
因为插件有几个天然优势。
第一，它就在浏览器里。
企业里的审批、流程、知识库、OA、CRM、项目系统，大量工作都发生在网页上。插件可以直接靠近这些页面。
第二，它是一个代码包。
名字、图标、按钮、提示词、技能、模型配置、页面读取能力，都可以被修改。你不需要一开始就理解所有技术细节，只要能把需求讲清楚，就可以让 AI Coding 工具帮你改。
第三，它容易分享。
一个流程审批助手，一个流程文件质检助手，一个流程图生成助手，一个制度问答助手，都可以先从插件形态跑起来。
Chrome 官方文档也明确，扩展可以用 HTML、CSS、JavaScript 这些 Web 技术构建。换句话说，它不是神秘系统，而是一套可被 AI Coding 工具理解和改造的工程结构。
这就是插件适合流程人的原因。
它够轻，够近，够快。
三、AI Coding 的第一课，不是写代码，而是把需求说清楚
AI 写不好，很多时候不是它不会写，而是你只给了它两个字。
沙龙里有一个很真实的细节。
当同学想改造插件时，如果只说“生成流程图”，AI 很难知道你真正要什么。
你得把自己说清楚。
我是谁？我要做一个什么助理？它要服务什么业务场景？输入是什么？输出是什么？结果要给谁看？哪些动作要自动做？哪些动作只能给建议？
这才是 AI Coding 的第一课。
不是学语法。
是学会把脑子里的想法，变成一份可执行的需求。
所以我一直建议，不要对 AI 说两个字。对一个真实同事，你也不能只说两个字。
你要讲背景，讲目标，讲约束，讲验收标准。
更关键的是，当 AI 做错时，不要立刻到处问人。
先让它自己反推。
告诉它：为什么错，请分析原因。然后再告诉它：全面扫描相关文件，给出修复方案，修完后自己验证。
这套动作，比“帮我改一下”有效得多。
四、流程管理人最该先做的，不是大平台，而是 Skill 和插件
流程 AI 化，不应该从“买平台”开始，而应该从“封装一段可复用能力”开始。
流程管理人天然适合做这件事。
因为流程工作本来就要回答四个问题：
1 谁在什么时候触发这件事？
2 系统要读取哪些信息？
3 规则如何判断，异常如何处理？
4 最后交付什么结果，谁来验收？
这些问题，正好就是 Skill 的骨架。
比如流程文件发布。
业务部门提交的版本格式不统一，审批过程中有很多会签意见，最终发布版到底有没有吸收这些意见，也经常要人工反复核对。
这时就可以先做一个流程文件质检助手。
它读取流程文件，按公司模板检查格式，提取会签意见，再比对发布版是否落实。最后给出问题清单和修改建议。
这不是空泛的 AI 赋能。
这是把流程专家的经验，封装成一个能跑的工具。
五、Agent 可以操作系统，但必须先把边界讲清楚
Agent 的强大，必须和权限、日志、人工确认一起出现。
沙龙里有同学问：这种助手能不能操作公司系统？
答案是，技术上越来越可行。
它可以通过浏览器自动化，像人一样打开页面、点击按钮、读取内容、填写表单。也可以通过 MCP、API 或本地工具连接系统。
OpenAI 对 Codex 的介绍里，已经把它定位成能处理软件工程任务的智能体。Anthropic 的 Claude Code 文档也把它描述为能在终端里帮助处理代码任务的工具。Cursor 的 Agent 模式，同样支持搜索、编辑和运行代码。
这些工具共同指向一个趋势：
AI 正在从“回答问题”，走向“调用工具并完成任务”。
但越是这样，越不能兴奋过头。
如果 Agent 带着你的账号进入系统，它就不是普通机器人。它是在你的权限上下文里行动。
审批、付款、合同、客户数据、员工信息，都不能一上来就交给它自动处理。
更稳妥的方式，是先让它做三件低风险工作。
先读取页面，生成判断建议。
再后台并行校验，记录它和人工判断的差异。
最后只在低风险、规则清晰、可追溯的场景里，逐步放开自动执行。
这不是保守。
这是企业级 AI 必须有的刹车系统。
六、从 User 到 Builder，企业 AI 推广要换一套路线
真正的 AI 推广，不是让所有人都多问几句，而是让一批人先做出工具。
企业里第一批应该被重点培养的人，不一定是传统 IT。
流程管理、质量管理、运营管理、财务、人力、法务、采购，都有机会。
原因很简单。
这些岗位长期和规则、模板、审批、异常、跨部门协同打交道。他们知道业务里最烦、最重复、最容易出错的地方在哪里。
过去，他们只能提需求，等系统排期。
现在，他们可以先做一个可运行的原型。
不一定完美，但能验证想法。
能不能读页面？能不能跑规则？能不能生成交付物？能不能减少一次人工核对？能不能让审批人少看十分钟？
这些问题，只靠开会很难讨论清楚。
做出来，才会清楚。
七、明天就能开始：选一个流程，把它做成自己的 AI 工具
从明天开始，不要先问“我要学多少技术”，先问“我能把哪段流程做成工具”。
如果你是流程管理人，可以从一个很小的场景开始。
不要一上来做企业级智能体平台。
也不要一上来做跨系统自动审批。
先选一个高频、低风险、规则清楚的流程节点。
比如流程文件格式检查。
比如审批意见一致性核对。
比如采购需求材料完整性检查。
比如制度条款和模板之间的差异比对。
然后写清楚五件事。
1 输入是什么：网页、文档、表格，还是一段文字。
2 规则是什么：模板、制度、经验判断，还是历史案例。
3 动作是什么：提取、检查、比对、生成，还是提醒。
4 输出是什么：清单、报告、流程图、审批意见，还是标准文档。
5 验收是什么：谁看结果，什么叫通过，什么必须人工复核。
这五件事写清楚以后，再把它交给 AI Coding 工具。
让它先评估能不能做。
让它给出轻量方案。
让它改插件。
让它自己测试。
让它复盘哪里还能优化。
这个过程刚开始会折磨人。
但你一旦跨过去，就会发现一个新世界：代码不是程序员的专属语言，代码是把业务想法变成工具的中间层。
流程管理人真正要补的，不是写代码本身。
是把流程说清楚，把规则说清楚，把边界说清楚，把验收说清楚。
一旦这四件事做到了，AI Coding 就不再只是开发工具。
它会变成流程管理人新的放大器。
八、最后：别只做 AI 的使用者
这场周四 AI 沙龙，表面上是在教大家改一个插件。
但更深一层，是在提醒每个流程管理人：
你过去的优势，是懂流程、懂规则、懂组织协同。
未来的优势，是把这些经验封装成别人可以调用的能力。
会用 AI，当然重要。
但如果你只停留在会用，你的经验仍然只存在自己脑子里。你一忙，能力就停了。你一离开，组织就断了。
如果你能把经验变成 Skill，变成插件，变成流程工具，变成一个低风险可验证的小智能体，事情就不一样了。
你的能力开始可以复制。
你的判断开始可以复用。
你的方法开始可以进入组织。
这就是从超级个体到超级组织的第一步。
不是先喊一个宏大的口号。
而是从一个真实痛点开始，把它做成一个能跑的工具。
别再只把 AI 当聊天框了。流程管理人真正要学会的，是用 AI 把自己的专业能力做出来。
九、资料参考
1. OpenAI, Introducing Codex
2. Anthropic, Claude Code overview
3. Chrome for Developers, Extensions / Get started
4. Cursor, Cursor Agent modes
5. Model Context Protocol, Connect to remote MCP servers