最近折腾 Codex Skills 和 AGENTS.md，我觉得三者边界可以这么分： 

AGENTS.md：项目长期规则
Skill：可复用任务流程
普通 prompt：本次具体需求

官方文档： 

Codex Skills: Agent Skills – Codex | OpenAI Developers
OpenAI skills repo: GitHub - openai/skills: Skills Catalog for Codex · GitHub

1. AGENTS.md 放项目事实
比如： 
- Use pnpm, not npm.
- UI components live in src/components.
- Run pnpm lint before finishing.
- Do not edit generated files.

这些规则长期稳定，而且只...

在咸鱼找的拼车, 5h和1w额度都没用完突然遇到这个问题, 其实只用了50%不到, 是网上拼车遇到的坑么?需要找主号解决? 
Your workspace is out of credits. Ask your workspace owner to refill in order to continue

可能是类似知识库的形态？但可以方便导入很多形式的个人资料，包括各个平台的资料，自己的聊天记录等等，然后调用大模型和ai对话或者是agent执行任务

安全检查很适合做成 Skill，因为它有稳定 checklist，而且容易被普通开发任务忽略。 
OpenAI 官方 skills 里也有 security 相关技能可以参考： 

我会检查这些点

是否误提交密钥、token、cookie。
是否把 .env、日志、私钥放进仓库。
新增接口有没有鉴权。
用户输入有没有校验。
文件上传有没有类型和大小限制。
SQL/命令/路径拼接有没有注入风险。
依赖有没有明显高危包。

SKILL.md 草稿
---
name: security-check
description: Check code changes for secrets, authentication, authorization, input validation, injection risk, and unsafe file handling. Use before mer...

ccswitch路由模式请求很慢，我看中转站后天时间也就几十s但是两天请求之间隔的时间总是好几分钟，这个有佬有解决办法吗

写 Skill 时，很多人只写 SKILL.md。这能用，但如果任务里有稳定的机械步骤，我更建议放到 scripts/。 
适合写进 scripts 的事

扫描文件。
生成固定模板。
解析 JSON / CSV / BibTeX。
批量重命名。
调 Playwright 截图。
检查 Markdown 链接。
统计测试覆盖率。

这些事让模型手写很容易出错，脚本更稳。 
一个简单结构
my-skill/
  SKILL.md
  scripts/
    collect_changes.py
    render_preview.py
  templates/
    report.md
  references/
    style-guide.md

SKILL.md 里怎么写
When generating the report, run:

```bash
python scri...

[image] 
如图，GPT系列已经稳定一天，成功率甚至超过了国产模型 
为了庆祝这短暂的‘盛世’也是再发个API好吧 
API接口：https://chybenzun.top/v1 
API key：sk-4M67IQp1AJvj6TUHJXEz4QcK4rpWzVRiXW8aNFvUcSHSX0Ul 
[image]

发版前写 release notes 很容易临时翻 git log，然后漏掉 breaking change 或迁移说明。这个场景适合做成 Skill。 
目标
让 agent 根据 git diff、commit、PR 标题，整理出稳定格式的发布说明。 
SKILL.md 草稿
---
name: release-notes
description: Generate release notes from git history, merged PRs, and changed files. Use before tagging a release or publishing a changelog.
---

# Release Notes

Collect:

1. User-facing changes
2. Bug fixes
3. Breaking changes
4. Mig...

用 Codex 做复杂开发时，我现在更喜欢把任务拆成三段：实现、验证、审查。 
不要一上来就说“帮我做完整功能并优化好”。这类任务太大，模型容易同时改架构、写 UI、改测试，最后不好收口。 
我常用的三段式
1. 实现
先实现最小可用版本，不做无关重构。保持现有接口兼容。完成后列出改动文件。

这一段只追求功能跑起来。 
2. 验证
运行项目已有 lint/test/typecheck。失败时只修和本次改动相关的问题。

这一段让 Codex 面对真实命令输出，而不是靠猜。 
3. 审查
Review the diff for correctness bugs, regression risk, and missing tests. Prioritize runtime behavior over style.

这一段专门抓 bug，不继续扩写功能。 
为什么这样有效
因为每一轮只有一个...

Claude Code Skills 里我觉得最容易被低估的是 description。很多人会认真写正文，但 description 随手写一句，结果技能很难被正确触发。 
不好的 description
description: A powerful skill for frontend development.

问题是太泛。模型不知道什么时候该加载，也不知道什么时候不该加载。 
更好的 description
description: Implement or modify React frontend UI, then verify the result with browser screenshots across desktop and mobile viewports. Use when the user asks for visible UI changes.

这里包含...

首先，我个人非常认同L站的准则和文化：以真诚待人为荣，以虚伪欺人为耻；以友善热心为荣，以傲慢冷漠为耻；以团结协作为荣，以鼓励对抗为耻；以专业敬业为荣，以敷衍了事为耻，此处不得不佩服佩服始皇的文采，这也是我一直想说的又不知道应该如何表达。 
正如始皇所说，请不要把互联网上的戾气带到这里。在当下戾气横行的网络环境中，我们太需要这样一方净土了。同时也感谢始皇为我们提供了这么一个地方。作为领导者为我们搭建了舞台，怎么把它建设好并持久地维护下去，就需要各位佬齐心协力，共同为它添砖加瓦。 
在这里，绝不允许任何人傲慢阴阳，这一点我真的是深有感触。在当下社会中，很多人不知道哪来的莫名优越感，自诩所谓的“高知精英”，动不动就抛出那句经典的“这人认知太低，没办法沟通”。这些话也不止在网络中，比如我身边的一些硕博，什么C9，留学生朋友，经常把别人认知低挂在嘴边。他们在学习能力或者自己领域方便确实有过人之处，但...

之前看见很多 codex 的学习教程，里面给的配置都有 disable_response_storage = true 这一项，我也一直都是这么配的。今天突发奇想准备去看看 codex 源码，发现这个配置项早在去年9月份就已经移除了，配了等于没配，有强迫症的佬友们可以去掉这一项。 
具体的 Pull Request: Never store requests · Pull Request #3212 · openai/codex

最近很多人同时用 Claude Code 和 Codex。我觉得没必要争谁替代谁，更实用的方式是分工。 
我的一个简单流程： 
Claude Code：快速实现和探索
Codex：跑测试、审查 diff、修边界问题

为什么这样分
Claude Code 很适合连续改代码、跟着项目上下文推进。 
Codex 很适合在工作区里跑命令、读失败、做 review、处理 GitHub/浏览器/本地环境。 
当然这不是绝对，只是一个好用的默认分工。 
一个实际流程

先让 Claude Code 实现 MVP。
提交前让 Codex review diff。
Codex 按测试失败修一轮。
再让 Claude Code 做小范围优化。
最后 Codex 跑验收命令。

prompt 示例
给 Claude Code： 
实现这个功能，优先保持现有架构，不要大规模重构。完成后列出改动文件。

给 Co...

[pasted-image-2026-05-31T02-11-32.png] 
[pasted-image-2026-05-31T02-12-18.png] 
[pasted-image-2026-05-31T02-12-00.png] 
[pasted-image-2026-05-31T02-12-03.png] 
[pasted-image-2026-05-31T02-14-48.png] 
[pasted-image-2026-05-31T02-14-45.png] 
[pasted-image-2026-05-31T02-14-42.png] 
[pasted-image-2026-05-31T02-15-55.png] 
[pasted-image-2026-05-31T02-15-44.png] 
[pasted-image-2026-05-31T02-15-38.png] 
...

用 Codex 做开发时，我觉得最容易被忽略的一点是：不要只写“我要什么”，还要写“怎样算完成”。 
Codex 文档入口： 

一个低质量任务
帮我优化登录页。

这个任务太空了。优化 UI？优化性能？修 bug？加动画？模型只能猜。 
一个更好的写法
目标：
修复登录页刷新后短暂显示未登录的问题。

上下文：
前端是 React，登录状态在 src/store/auth.ts。
后端接口是 GET /api/me。

约束：
不要改后端接口。
不要重写鉴权系统。
保留现有 localStorage key。

验收：
pnpm test 通过。
刷新页面后不再跳回登录页。
未登录用户仍然正常跳转登录页。

输出：
直接修改代码，并说明改了哪些文件。

我常用模板
目标：

上下文：

约束：

验收：

输出：

最重要的是 约束 和 验收。 
为什么验收条件很关键
因为 Codex ...

Claude Code Skills 有个人级和项目级的区别。这个分工如果一开始没想清楚，后面很容易变成一堆重复技能。 
官方文档： 

我的分工原则
个人级 Skills
适合放所有项目都通用的工作习惯： 
~/.claude/skills/

比如： 

代码审查
写 commit message
整理 release notes
读 PDF / 读论文
通用安全检查

这些技能跟某个仓库无关，换项目也能用。 
项目级 Skills
适合放当前仓库独有的规则： 
.claude/skills/

比如： 

本项目的发布流程
数据库迁移规范
UI 组件使用约定
特定测试命令
内部 API 约定

这些东西离开项目就没有意义。 
一个例子
个人级 code-review 只写通用审查原则。 
项目级 frontend-review 再补： 
- Use existing Button, ...

我发现代码审查特别适合做成 Skill，因为 review 的评价标准应该稳定，而不是每次靠一句“帮我看看代码”。 
为什么要做成 Skill
临时 prompt 容易出现两个问题： 

模型开始评价命名、格式、风格，但漏掉真正的 bug。
输出很散，不方便你逐条处理。

Skill 可以把优先级固定下来：先 correctness，再 regression，再 tests，最后才是 style。 
一个可直接改的 SKILL.md
---
name: bug-focused-review
description: Review code changes for correctness bugs, regressions, risky behavior, and missing tests. Use when reviewing a PR, diff, or uncommitted cha...

很多人用 Codex 时只改 prompt，但其实项目里的 AGENTS.md 更关键。它相当于给 coding agent 的项目说明书，适合写稳定规则，不适合写一次性需求。 
官方入口： 

Codex 文档：Codex | OpenAI Developers
AGENTS.md 文档：https://developers.openai.com/codex/config/agents-md

我建议 AGENTS.md 写这些
# Project Guide

## Commands
- Install: `pnpm install`
- Dev: `pnpm dev`
- Test: `pnpm test`
- Lint: `pnpm lint`

## Architecture
- Frontend: `src/app`
- Shared UI: `src/components`
...

最近看 Claude Code Skills 文档，最大的感受是：Skill 不应该写成“万能提示词”，而应该写成一个边界很清楚的小工具包。 
官方文档： 

Extend Claude with skills - Claude Code Docs
Agent Skills in the SDK - Claude Code Docs

我理解的 Skill
Skill = 一段可自动发现的说明 + 必要的脚本/模板/参考资料。 
它适合沉淀那些你经常重复做、而且流程比较稳定的任务，例如： 

PR review
生成 changelog
检查论文格式
按项目规范写测试
根据设计稿实现页面

不适合把所有偏好一股脑塞进去。那样模型每次都要读一大坨，反而容易失焦。 
最小结构
my-skill/
  SKILL.md
  scripts/
  templates/
  references/

...

本人搞Agent开发，现在上面一堆乱七八糟的需求，自己都没有想清楚要什么，就已经排下来了，话术都是一样的，有Ai了，明天就上、后天就上，试一试。自己都说不清楚意义和价值，明知道这东西就是一坨狗屎还硬要上，真是让人十分无语。 
天天倒排上这些乱七八糟的需求，Ai Coding率飙到90+甚至100，代码几万行几万行的拉，拉了之后也只能AI review，质量明显下滑，下滑之后又会被上面diao怎么这么多bug，又让ai修，修了又出来新bug，子子孙孙无穷尽也。虽然觉得后面ai的能力发展了，肯定会解决很多问题，但是目前这种其实没有达到足够交付质量，但是上面又非要你n倍交付速度，只能交付一坨狗屎的感觉，着实令人痛苦。 
跟老板聊天，老板也会说，不能做干活的人，要有自己的思考，多和业务沟通交流，执行层早晚要被干掉，道理是对的。但是业务老板沟通的结果永远都是，嗯，你说的有道理，那你先把我这个需求做上...