ARTICLE · 1039698
用 Codex 做一个简单插件,到底需要多久?
最近忙于我的AI视频短剧，发现每次在视频号发布内容的时候，我都要重复做几件事：选择视频标注(打上AI标注)、关闭位置信息、勾选确认原创声明协议等等。
图中 ① ② ③处
单次操作花不了多少时间，但只要发布频率上来，这些重复点击就会变得很烦。 本着重复的事情交给程序的想法：直接尝试用codex做一个插件出来。
我没有上来像以往去搭建项目、搭建框架。直接把我的需求丢给codex去实现，因为实质上就像做一个脚本。最终实现效果是一个可以实际使用的 Tampermonkey 用户脚本，并把它整理成了开源项目 Wechat-Video-Autofill。
那么这么一个简单的小功能从开始到最终实现效果，花了多少时间呢？
答案是：2小时。
这还包含我中间验证和调整的环节，到最后的完全符合我需求基本上就是2小时左右。
我想解决什么问题
再回到需求本身
这个插件的目标很简单：打开视频号发布页后，自动完成几个固定动作。
选择预设的视频标注，例如“含 AI 生成内容”； 将位置设置为“不显示位置”； 默认勾选“声明原创”； 在原创权益弹窗中勾选协议并确认； 每次进入发布页面都默认替我完成以上操作。
怎样向 Codex 描述需求，成功率更高
经过这次实践，我总结了几个很有用的方法。
第一，先描述结果，不要急着规定技术方案。
例如直接说：“进入发布页面后，默认选择‘含 AI 生成内容’，位置设为‘不显示位置’，并声明原创。”这比一开始要求它使用某个选择器或框架更有效。
第二，一次只验证一条链路。
先确认插件能显示，再确认视频标注能选择，然后处理位置，最后处理原创弹窗。问题混在一起时，很难判断失败发生在哪一步。
第三，出问题时提供现场信息。
截图可以说明控件在哪里，控制台报错可以说明事件为什么失败，HTML 或简化后的诊断结果可以说明页面真实结构。信息越接近失败现场，修复速度越快。
第四，让 Codex 直接维护最终项目。
当脚本可以使用后，可以继续让它清理旧项目、补充 README、检查敏感信息、统一项目名称。这样得到的不只是聊天框里的一段代码，而是一个可以继续维护和分享的仓库。
AI 时代，想法正在变得比工具更重要
这次做插件给我最直接的感受，AI时代真的是会提升效率，快速的实现每一个想法。过去以往需要手敲的一行行代码，都可以交个AI去实现，人只用充当一个指挥官和验收官的角色。
以前想做这种小工具，第一反应通常是：要学 JavaScript、研究浏览器扩展、分析网页 DOM，还要处理存储和页面生命周期。学习成本很容易让一个小想法停留在“以后再做”。
Codex 改变的并不是代码本身，而是把尝试成本降了下来。你可以先用自然语言描述一个具体麻烦，很快获得第一版，再根据真实使用结果继续调整。
在 AI 时代，我们可能不再需要等到“完全准备好”才开始行动。不会写插件，可以先描述想要的效果；不懂网页结构，可以让 AI 协助分析；第一版不好用，就把现场信息交给它继续修改。很多过去需要搁置的想法，现在都可以先花半小时验证一下。
这也是我认为 AI 最有价值的地方：它让更多人拥有了把想法做出来的能力。
AI 把这条路径缩短了。一个人不必先成为专业开发者，才有资格尝试解决自己的问题。只要能把场景、目标和限制讲清楚，就可以让 AI 帮助完成代码、界面、调试和文档，再通过实际使用不断修正。所以我更愿意把 Codex 看成一位执行速度很快的技术搭档。过去，从想法到结果之间隔着学习成本和大量重复劳动；现在，我们可以先把注意力放在问题本身，再让 AI 帮助跨过实现门槛。
当实现成本下降之后，想法的质量、对场景的理解，以及持续把事情做完的能力，反而会变得更加重要。
项目地址：https://github.com/xu20160924/Wechat-Video-Autofill
感兴趣的朋友欢迎体验和赏个star
最后说一句，封面图也是AI出的，这个风格你们感觉是哪个模型呢？