今日 Codex 工作总结：工具站 review、发布和开发日志起步

今天做了什么

我先让 Codex 以审查者身份看一组浏览器工具站。审查维度包括 SEO、内容可信度、功能正确性、 性能风险、部署配置和用户体验。第一轮输出之后，我没有停在报告，而是要求直接采纳建议并发布。 这一步很关键，因为很多 AI 协作如果只停留在建议层，真正的价值会丢在“没人动手”的缝里。

Codex 接着进入执行模式：逐个项目改配置、修功能、补元信息、跑构建、做本地 smoke test、 提交代码、推送仓库，并在 Vercel 上确认生产部署状态。整个流程里，Codex 不是只改一个文件， 而是在多个独立小项目之间保持上下文和检查清单。

后半段我又让 Codex 新建一个轻量博客，用来沉淀每天的使用总结。这个博客暂时不绑定自定义域名， 也显式设置为不索引。这样它既能在线访问，又不会过早变成公开内容资产。第一篇文章就是这篇： 记录今天如何把 AI 协作从 review 推进到修复、验证和发布。

值得保留的方法

最有用的做法是先让 Codex 明确风险分层。比如工具站最怕“界面看起来正确，但计算或转换结果不可信”。 因此修复优先级不是先调样式，而是先处理表达式解析、URL 生成、随机分组、JSON 查询、大输入保护这类会影响信任的问题。

第二个方法是让 Codex 同时负责验证路径。今天不只是跑了构建，还用浏览器工具检查了几个关键交互： 计算器的运算优先级、二维码生成、地址栏隐私处理、首页搜索过滤。这个环节让“改完了”更接近“真的能用”。

第三个方法是把发布也纳入任务完成定义。推送代码之后，Codex 继续检查部署状态和线上 HTTP 响应。 这避免了一个常见假完成：本地构建通过，但生产环境没有更新。

第四个方法是让 Codex 先判断用户给出的方向是否合理。今天“新建 dev blog”这个方向是合理的， 但更适合先做成无构建依赖的静态站，而不是一上来引入博客框架、数据库或 CMS。对于短期自己看的记录， 简单文件结构、明确的脱敏规则和可部署 URL 比复杂系统更重要。

今天的一个细节

有两个站点的自定义子域名还没有接好。Codex 没有假设它们已经可用，而是用 DNS 和 Vercel alias 结果核对， 然后把 canonical 和 sitemap 临时指向已经上线的 Vercel 地址。这个判断很务实：SEO 指向一个可访问地址， 比指向一个未来才会接好的域名更安全。

对 Codex 协作方式的新观察

今天比较明显的一点是：Codex 适合处理“跨多个相似项目的一致性改进”。人来做这类事很容易疲劳， 比如每个站点都要看配置、改元信息、跑构建、查部署。Codex 的优势不是单点灵感，而是能把同一套工程判断 稳定地应用到一组项目里。

但这种能力需要清楚的边界。比如我希望它发布，但不希望它假设域名已经配置；希望它写总结，但不希望它把私有细节写进去。 所以更好的提示不是“帮我写/帮我发”，而是说清楚完成定义：要脱敏、要测试、要部署、要确认线上结果。

今天有价值的工具

今天真正有帮助的不是某一个“神奇提示词”，而是一组工具配合起来形成闭环。首先是 Codex Skills。 项目里启用了一套规格化的技能文件之后，Codex 能更稳定地遵守项目约定，例如先检查现有指令、再动手、 review 时按风险排序、涉及真实项目时补齐必要的工作流。

这里尤其值得点名的是 gotalab/cc-sdd。 它把 spec-driven development 的工作方式接到 Codex Skills 里，让 Codex 可以围绕 discovery、requirements、 design、tasks 这类结构推进，而不是只靠临场对话。对复杂需求来说，这种 spec 方式能减少“想到哪改到哪”， 更适合做需要持续维护的真实项目。

第二个有价值的是 Codex SEO 插件里的 SEO audit 思路。它不只是检查 title 和 description， 而是把技术 SEO、内容质量、结构化数据、sitemap、AI 搜索可引用性、性能和图片这些维度放在一起看。 对工具站来说，这种框架能避免只做“页面好看”，却忽略 canonical、robots、schema、长尾页面和内容可信度。 这个插件可以从 BestLemoon/codex-seo 了解源码和能力边界。

这次也发现了一个值得继续关注的插件目录： hashgraph-online/awesome-codex-plugins。 它整理了 OpenAI Codex plugins、skills 和相关资源，还能作为 Codex 的 marketplace source 使用。 对我来说，它的价值不是“装越多插件越好”，而是可以先查有没有成熟的社区方案，再决定是否自己造轮子。

第三个是 Vercel 插件和 Vercel CLI。今天发布不是停在本地 build，而是用 Vercel 确认生产部署状态， 再用线上 URL 做 HTTP 检查。这个组合很实用：Vercel 负责部署状态，命令行负责快速验证响应码和响应头， 两者合起来能减少“以为上线了，其实没有”的情况。

第四个是 Chrome DevTools 插件。它适合做轻量 smoke test：打开本地页面，填表单，检查页面文本、 meta、交互结果和关键状态。今天用它验证了计算器表达式、二维码生成、首页搜索和隐私相关的地址栏行为。 这种验证虽然不是完整自动化测试，但比只看构建结果靠谱很多。

最后是一些基础命令行工具：git、curl、dig、npm build、本地 HTTP server。它们不新鲜，但在 AI 协作里很重要。 Codex 可以用这些工具把判断落到证据上：代码有没有提交，域名有没有解析，线上有没有 200，响应头有没有 noindex， 构建产物里还有没有 sourcemap。

当前安装的 Codex 插件

今天顺手盘点了一下当前 Codex 环境里启用的插件：Browser、Chrome、Chrome DevTools、Cloudflare、 Codex SEO、Computer Use、Context Pack、Documents、Education Agent Skills、GitHub、Neon Postgres、 Nullcost、OpenAI Developers、Presentations、Semrush、Spreadsheets、stark、Tool Advisor、Vercel 和 Writer's Loop。不是每个插件每天都会用到，但知道它们分别适合什么场景，会让 Codex 更像一个可调度的工作台。

今天实际证明有用的主要有四类。Codex SEO 用在工具站 review：检查 canonical、robots、sitemap、schema、 内容可信度、AI 可引用性和性能风险。Vercel 用在发布闭环：从生产部署到线上 URL 验证，确认不是只在本地通过。 Chrome DevTools 和 Browser 用在前端 smoke test：打开页面、检查交互、看 meta 与响应状态。GitHub 和 git 流程则负责把 每个项目的改动提交、推送、保留可追踪的历史。 Chrome 更适合需要登录态、现有浏览器资料或远程页面检查的场景，Computer Use 则适合必须操作桌面应用时再启用。

还有一些插件虽然今天没有重度使用，但很值得保留在工具箱里。Context Pack 适合快速生成仓库上下文，接手陌生项目时很有用； Tool Advisor 适合在任务开始前盘点“该用哪些工具组合”；stark 适合做 UI/UX 评审和设计约束；Writer's Loop 适合长文、总结和发布文案的多轮打磨。Nullcost 可以在选云服务、数据库、托管、邮件和 API 时先查免费层或低成本方案。

更偏平台和专业场景的插件也有明确位置：OpenAI Developers 用在接入 OpenAI API 或 Agents SDK；Cloudflare 用在 Workers、Pages、Durable Objects 这类边缘部署；Neon Postgres 用在 serverless Postgres；Semrush 适合需要量化关键词、流量和竞争页面时再上；Documents、Presentations、Spreadsheets 则适合把工程结果沉淀成文档、 slide deck 或表格。Education Agent Skills 更适合 AI 学习、课程设计和学习活动设计，不一定是工具站开发主线， 但对系统化学习 AI 很有帮助。

一次 Cloudflare 插件使用复盘

今天后面有一个值得记下来的小事故：在给几个站点补自定义域名时，Cloudflare 插件明明已经安装并授权， 但我一开始没有把“使用 Cloudflare 插件”当成最高优先级，而是被底层配置、命令行和凭据细节带偏了。 这个判断是不够干净的，也会让后续操作变得更难复盘。

更稳的做法是先确认当前 Codex 环境里已经安装并授权了 Cloudflare 插件，然后优先使用插件暴露出来的 Codex 能力。Cloudflare 插件本身包含官方 API MCP 能力，但正确入口是 Codex 的插件/工具界面， 不是手工翻缓存配置、抽凭据、再自己拼一条底层调用链。

这次踩坑的关键原因，是把插件实现细节外推成了工作流结论。以后遇到类似场景，记住顺序： 先用已安装插件，再考虑官方 CLI 或文档路径；不要把手工绕过插件的底层调用当作可复用的操作知识。

另一个连带经验是：域名绑定不只看 DNS。Cloudflare 记录、Vercel alias、证书、项目保护设置和最终 HTTPS 响应都要逐项验证。今天有站点在 DNS 和 alias 都正确后仍返回 401，最后原因是 Vercel deployment protection。 这类问题如果只盯着 DNS，会很容易误判。

今天关于学习 AI 的收获

今天的 AI 学习不是看一篇新论文或收藏一个新工具，而是通过真实任务理解 AI 协作的边界。 对我来说，更有效的学习方式是让 Codex 进入完整工程流程：读项目、做 review、提出风险、改代码、 跑验证、发布、再复盘。这样能看清它在哪些地方可靠，哪些地方必须由人来定义边界。

一个很明显的结论是：插件和工具环境决定了 Codex 能从“回答问题”走到多远。没有浏览器、Vercel、 SEO audit、命令行和 git，它可能只能给建议；有了这些能力，它就能参与实际交付。但这也意味着人需要提出更清楚的完成标准， 比如“不要泄露敏感信息”“要确认生产部署”“要用可访问 URL”“要保留 noindex”。

以后这个日志怎么写

这个日志不只记录当前工具站，也可以记录其他项目里的 Codex 使用经验。范围可以包括架构判断、重构过程、 发布流程、工具链选择、调试过程和项目管理方式。关键不是项目本身，而是当天学到的协作方法。

默认写法会保持“项目可泛化、经验可复用”。如果没有必要，就不写真实项目名；如果真实项目名会带来额外上下文风险， 就用“某个内容项目”“一个前端工具”“一组静态站点”这样的描述替代。

明天可以继续改进的点

第一，可以把每日文章的创建流程做成一个小脚本或模板，减少重复 HTML。第二，可以给日志加一个更清晰的文章索引， 按项目类型或协作主题分类。第三，可以逐步把“哪些信息必须脱敏”写成固定检查清单，让每篇文章发布前都过一遍。

脱敏说明

这篇记录去掉了个人邮箱、私有仓库完整地址、部署内部 ID、账号标识和具体提交日志链接。 保留的是工程方法：如何 review、如何分优先级、如何修复、如何验证、如何确认发布，以及如何把一次协作沉淀成后续可读的日志。