用 Codex Chrome 插件重构工作流:从 OA 工时填报到可复用 Skill 的自动化实践

用 Codex Chrome 插件重构工作流:从 OA 工时填报到可复用 Skill 的自动化实践

上个月底,我又遇到了那个熟悉的场景:打开 Excel,核对任务,登录 OA,创建任务,登记工时,再一条条检查有没有漏填。

这件事不难,但很烦。

真正烦的不是复制粘贴,而是每次都要在脑子里过一遍规则:哪些任务只是计划,不能填;哪些日期已经填过,要跳过;系统弹出提示时,是继续还是停下来;如果月底发现少了几天,要不要找相近任务补上。

这些判断都不复杂,但它们很耗注意力。

刚好,OpenAI 在 2026 年 5 月 7 日发布了 Codex Chrome 插件,让 Codex 可以直接在 Chrome 里工作,使用真实浏览器页面和已登录会话。对我来说,这个能力的意义不是"AI 终于能点网页了",而是它让很多原来只能手工处理的企业后台流程,有了被重新设计的可能。

于是我开始想:能不能不只是让 AI 帮我填一次,而是把这套流程重构掉?

最后,我用 Codex Chrome 插件接管真实浏览器,用 Skill 记录规则,把这个原本靠人工记忆和反复纠错维持的 OA 工时填报流程,整理成了一套可以复用、可以修正、可以继续进化的自动化工作流。

不过这里也有一个前提:任何 Agent 操作都会消耗 token。它不是免费的后台脚本,也不是可以无限试错的廉价劳动力。所以,真正值得做的不是让 Agent 反复替你执行零散动作,而是把高频、重复、规则清晰的工作流沉淀下来,让每一次 token 消耗都在积累流程资产。

这篇文章不想讲"AI 怎么帮我点按钮",而是想聊一件更有意思的事:

当我们把重复工作交给 AI 时,真正值得重构的,可能不是动作,而是工作流本身。

为什么是现在?

以前想自动化企业后台流程,通常有两个难点。

一个是入口问题。很多内部系统没有开放 API,或者 API 不适合个人工作流改造;另一个是状态问题,系统依赖真实浏览器登录态、SSO、权限和页面交互。

Codex Chrome 插件出现后,这个入口问题被打开了一部分。它让 Agent 可以进入真实浏览器场景,而不是停留在隔离环境里。

但这并不意味着所有事情都应该交给 Agent 做。因为 Agent 的每一步观察、判断和操作,本质上都在消耗 token。越是没有结构的流程,越容易变成"用 token 换手工劳动"。

所以我的目标不是让 AI 多帮我点几次按钮,而是把流程重新组织一遍:

  • 哪些动作值得自动化?
  • 哪些判断应该写成规则?
  • 哪些异常必须停下来问人?
  • 哪些纠错应该沉淀到下一次?

这才是我理解的工作流重构。

一、重复工作真正消耗人的,不是动作,而是判断

很多重复工作表面上看是机械劳动。

复制、粘贴、填写、提交。

但如果你真的把流程拆开,会发现里面并不只是动作,还有大量判断。

以 OA 工时填报为例,表面流程很简单:从工作计划里整理任务,然后到 OA 系统里创建任务、登记工时。

但真实流程里会遇到很多问题:

  • 有些任务只是计划,不能提前处理。
  • 有些任务已经在后续文件中更新,要以后续版本为准。
  • 有些日期系统已经填过,不能重复填。
  • 有些周末日期,如果来源数据里明确写了,也应该保留。
  • 有些缺失记录,不能让 AI 直接编内容,必须先提示用户确认。

这些规则没有写在一个按钮上,也不会由系统主动告诉你。

它们来自经验。

这就是很多工作流真正消耗人的地方:不是手在忙,而是脑子一直在维护一堆隐性规则。

如果这些规则不被显性化,自动化只能停留在很浅的层面。

AI 可以帮你点按钮,但它不知道什么时候不该点。

二、Codex Chrome 插件解决的是入口问题,不是全部问题

这次我用到 Codex Chrome 插件,是因为 OA 系统属于典型的企业内部系统。

它依赖浏览器登录态、公司 SSO、页面权限和复杂前端组件。

在这种情况下,直接写脚本或者调用接口都不一定现实。

Codex Chrome 插件的价值在于:它可以接管真实 Chrome 页面,复用已有登录状态,在真实业务页面里完成操作。

这解决了一个很关键的问题:

AI 不再只能在一个隔离环境里"模拟操作",而是可以进入我的真实工作现场。

但这里也有一个误区。

很多人会以为,有了浏览器插件,自动化就完成了。

其实不是。

浏览器插件只是让 AI 能进入现场。真正决定自动化质量的,是它能不能理解这个现场里的业务规则。

也就是说,Codex Chrome 插件解决的是"怎么进去"和"怎么操作"的问题。

但"什么该做、什么不该做、什么时候要停下来问人",这些还需要工作流设计。

三、工作流重构的第一步:把脑子里的规则说出来

这次实践里,最重要的过程其实不是自动填报成功,而是不断纠错。

一开始,AI 会按照它理解的方式去做。

但真实业务流程里有很多细节,只有实际使用者才知道。

于是我不断纠正它:

  • 这个地方不能用普通浏览器,要用 Codex Chrome 插件。
  • 这个日期不能随便点日历,要以来源数据为准。
  • 周末不是绝对不能填,要看来源数据有没有写。
  • 计划任务不能提前处理,要等下一份实际计划。
  • 某天已经填过工时,就跳过当前任务。
  • 如果发现缺少几天,不要直接补,先把缺失日期列出来问我。

这些话看起来像是在"教 AI 做事"。

但换个角度看,其实是在梳理自己的工作流。

很多规则在说出来之前,只是一种习惯。说出来之后,它们才变成了流程。

这就是我理解的工作流重构第一步:

不要急着自动化,先把你平时靠经验完成的判断显性化。

四、Skill 的意义:让纠错变成下一次的默认能力

如果这些纠正只停留在一次对话里,价值其实有限。

今天纠正了,明天又忘了。

这个月纠正了,下个月又要重新说一遍。

所以我把这些规则沉淀进了 Skill。

Skill 可以理解成一套专门针对某类任务的工作流说明。

但我更愿意把它看成一种"流程记忆"。

它记录的不是某一次操作,而是下一次遇到类似任务时应该默认遵守的规则。

比如:

  • 以后处理 OA 工时填报,要使用 Codex Chrome 插件。
  • 任务来源以工作计划文件为准。
  • 预测任务不提前处理。
  • 工时日期不能随意扩展。
  • 同人同日已填报就跳过。
  • 发现缺失日期时,先提示用户确认,再自动补齐。

这很像软件工程里的重构。

原来逻辑散落在人的脑子里。现在它被抽取出来,变成了一个可以复用、可以修改、可以演进的模块。

所以 Skill 的价值不是"写一份说明书"。

它的价值是:

把一次次人工纠偏,沉淀成下一次自动执行时的默认能力。

五、好的自动化不是全自动,而是有边界感

这次实践让我更明确了一点:真正可靠的 AI 工作流,不应该追求无脑全自动。

因为很多工作并不是只有动作风险,还有责任风险。

比如补缺失工时这件事。

如果系统发现某个月少了几天记录,AI 能不能自动找内容填上?

技术上当然可以。但流程上不能直接这么做。

更合理的方式是:

先告诉用户缺了哪些日期。再询问是否需要自动找内容补齐。用户确认之后,再根据相邻或相关任务生成填报内容。

这个过程看起来多了一步,但它非常重要。

因为它保留了人的确认权。

自动化不是越激进越好。真正好的自动化,应该知道哪些事情可以直接做,哪些事情可以判断后做,哪些事情必须停下来问人。

我把它分成三类:

类型 自动化策略
规则明确、低风险、重复性高 直接自动执行
有明确规则,但可能出现冲突 自动判断,异常跳过
涉及业务责任或内容生成 先提示用户确认

这张表,可能比具体怎么点按钮更重要。

因为它决定了一个 AI 工作流是否可靠。

六、工作流重构的核心:从"代操作"到"可进化系统"

这次 OA 工时填报只是一个具体例子。

真正让我感兴趣的是它背后的变化:

一开始,我只是想让 AI 帮我完成一个重复工作。后来我发现,更有价值的是借这个过程重新设计工作流。

原来的流程是这样的:

  • 我记得规则。
  • 我判断异常。
  • 我处理系统提示。
  • 我修正错误。
  • 我下次继续靠记忆重复一遍。

重构之后,流程变成了:

  • 规则被写下来。
  • 异常被分类。
  • 用户确认点被设计出来。
  • 错误被转化成 Skill 更新。
  • 下一次执行会继承这一次的经验。

这就是从"代操作"到"系统化"的变化。

AI 不再只是临时帮手,而是参与到了工作流的演进里。

七、我对 AI 工作流的一个判断

现在我判断一个 AI 工具有没有价值,不只看它能不能完成某个任务。

我更关心三个问题:

第一,它能不能进入真实工作现场?

比如浏览器、文档、表格、代码仓库、内部系统。

第二,它能不能承接我的业务规则?

不是只会执行命令,而是能遵守流程边界。

第三,它能不能把这次经验沉淀到下一次?

也就是能不能让一次纠错变成长期能力。

Codex Chrome 插件解决了第一个问题。

Skill 机制解决了第三个问题。

中间最重要的第二个问题,则需要人和 AI 一起完成。

这也是为什么我说,这不是一次简单的 OA 自动填报,而是一次工作流重构。

八、结语:你真正要重构的,是自己的重复劳动方式

很多人问 AI 能帮自己做什么。

我现在更愿意反过来问:

你每天、每周、每月,有哪些工作其实一直在重复消耗你?

如果只是让 AI 帮你完成其中一次,收益是有限的。

更值得做的是:

  • 把这个流程拆开。
  • 把隐性判断说出来。
  • 把异常处理规则写下来。
  • 把确认点设计清楚。
  • 把纠错沉淀成 Skill。
  • 让下一次执行比这一次更成熟。

这才是我理解的 AI 时代个人工作流重构。

它不是让 AI 替你多点几次按钮。

而是借助 AI,把原本依赖记忆、经验和手工操作的流程,重构成一套可以执行、可以纠错、可以沉淀、可以继续进化的系统。

这次我从 OA 工时填报开始。

但真正被改变的,不只是一个填报流程。

而是我看待重复工作的方式。

Codex 对话截图

创建 skill

填报工时

参考资料

相关推荐
小白跃升坊21 小时前
Codex 增强部署:基于 Codex++ 接入 DeepSeek
ai·ai编程·codex·deepseek·ai coding·codex++
AlfredZhao21 小时前
GPT 省钱,不是别用最新模型,而是别浪费缓存
gpt·ai
doiito1 天前
【Agent Harness】Gliding Horse 本体论系统设计:给 AI Agent 装上“语义大脑”
ai·rust·架构设计·系统设计·ai agent
小七-七牛开发者1 天前
周一上线 | SpaceX 收购 Cursor、支付宝进入 AI 时代、DeepSeek 完成 500 亿元融资
ai·agent·token·glm·智谱·claudecode·ai coding·周一上线
doiito2 天前
【Agent Harness】为什么我把 JSON‑LD “编译成 DAG” 后,整个 Agent 平台立刻聪明了
ai·rust·架构设计·系统设计·ai agent
xiezhr2 天前
折腾半小时,终于让AI 能直接帮我写飞书文档了
ai·飞书·ai agent·飞书cli·飞书文档
岳小哥AI2 天前
Claude Fable和Claude Mythos 5同时发布:注意力机制下愈加强大的AI大模型
ai·ai基础
Artech2 天前
[MAF预定义的AIContextProvider-04]Mem0Provider——长期记忆基于的云端解决方案
ai·agent·maf·aicontextprovider·chathistorymemoryprovider·mem0provider
哥不是小萝莉3 天前
一文读懂 OpenAI Codex 源码的原理、架构与未来
ai
大强同学3 天前
Codex App接上微信,我开始在厕所里改 Bug 了
codex