大家好，我是小陈，这是我第 5 篇原创。
今天捣鼓了 OpenAI 刚出的 Codex app，我用 5 分钟在 Codex app 里做出了一个“定时新闻雷达”：
- 输出「AI 领域 5 条新闻 + 每条 1 句话点评」
图 1 - codex app 生成的 automations第一次跑其实翻车了：格式不规范，读起来像一坨草稿。
我干了一件特别“产品经理式”的事：把问题当成一个待调试的需求，直接丢回去让 AI 自己改——
“你输出不稳定。请先问我 5 个确认问题，再按固定模板输出；缺数据就标注，不要编。”
第二次就顺了。
这件小事让我更确定：2026 年，AI 真正的竞争点不再是“谁更会聊天”，而是——
谁能把你的工作流程固化下来，稳定交付。
所以这篇教程不讲“又一个提示词技巧”，我想教你做一件更值钱的事：
把你日常的 SOP（标准流程）打包成 Skill，让 AI 像一个可复用的“交付模块”。
你不需要安装复杂的 Claude Code，也不用会写代码，只要安装 app，就可以用。
文末我放了 3 个可直接套用的 Skill 模板（行业监控简报 / PRD&需求评审包 / 工单归因与优先级），以及我的领取方式：回复「CODEX」自动获取。
0. 先确认你是不是适合（别硬上）
Codex app 目前是一个桌面“AI 工作台”，我觉得它主要有三件事特别适合职场交付：
- 你可以设定 Automations 定时跑任务，把结果放到 Triage（收件箱）等你审核
补充一个和“新闻雷达”强相关的点：Codex 默认使用 cached web search（缓存搜索），用来降低被不可信网页提示注入的风险。
如果要让它直接访问网络、或者跑需要联网的命令，通常会触发权限请求。你可以把它理解成：默认先“安全模式”，需要的时候再逐步放开。
如果你满足任意一条，这篇就很适合你：
- 你经常写同一种交付物：周报/简报/PRD/复盘/会议纪要/工单归因
- 你有固定节奏的交付（周会、周报、竞品监控），并且不想每次都从 0 开始
- 你带团队/做创业：需要“可交接、可复用”的流程，而不是靠某个人的手感
1. Codex app vs Claude Code：我为什么说它们是互补？
我自己是 Claude Code 重度用户：写内容、写代码（Chrome 插件、前端网页、小程序）都在用。
但 Codex app 还是让我觉得“非常产品化”，原因是它解决的是另一类问题：把 SOP 变成资产。
先更正一个容易误解的点：Claude Code 也有官方的 Skills（beta），同样可以把流程封装成可复用能力；另外它还支持 slash commands（自定义命令）和 /agents 等能力，把常用流程做成“快捷入口”。所以这里的对比不是“有 skills vs 没 skills”，而是“终端工兵型 vs 桌面工作台型”的产品取舍。
我用一张“场景地图”说清楚它们的互补关系（给产品经理/小团队负责人看的）：
| | |
|---|
| | |
| | |
| 可用 Skills/自定义命令固化口径（偏终端工作流） | 同样支持 Skills（偏“工作台+交付物”视角） |
| | 原生支持 Automations + Triage（收件箱） |
| 更像“多开会话 + 你手动协调”，也可用 /agents 分工 | 更像“指挥中心”：多线程按项目组织，可直接用 diff 审校 |
| | |
一句话总结：
- Claude Code 更像“终端里的超级工兵”：适合和代码/命令行贴身肉搏
- Codex app 更像“AI 工作台”：适合把 SOP 固化、按时交付、你只做审核和决策
如果你只记住 Codex app 相对更“工作台化”的 3 个优势点，我建议是这三个（注意：不是“Codex 才有 skills”，而是它把“工作流”做成了默认体验）：
- Automations + Triage（按时交付 + 待审校）：把“固定节奏交付”做成默认能力，并且天然是“先产出、后审核”
- 交付物落盘 + 可审校（diff 思维）：更鼓励把结果写成文件（报告/PRD/清单），方便审校、追溯与复用（尤其是放进 Git 后）
- 默认沙箱 + cached web search + 逐步授权（可控）：当 AI 真能动文件、动命令、动工具时，边界感比聪明更重要
这也是我这篇教程要讲的主线：SOP → Skill → Automation。
图 2 - Claude Code VS codex app
2. 为什么我强烈建议你从“提示词”升级到“交付系统”？
我之前在 WPS 做商业化产品，最深的体会是：
真正能放大的，从来不是一次灵感，而是可复制流程。
我当时负责的业务做到了 年收入亿级、**同比增长 53%**，这类增长不是靠“某一次写得很妙”，而是靠把有效打法沉淀成可复制的 SOP，让团队每次都能稳定交付。
同样一件事：
- 你每次“写 prompt”= 你在重复沟通（人力线性增长）
- 你把 SOP 写清楚 + 固化成 Skill = 你在做“产品化”（边际成本趋近 0）
你会感受到一个非常现实的变化：
AI 不是替你工作，而是把你的“交付口径”变成标准件，然后替你跑重复部分。
你只保留最值钱的那 20%：判断、取舍、责任。
3. 5 分钟复刻：把“定时新闻雷达”做成可交付的 Automation
这一段我写得尽量“照着做就能成”（你也可以把它当成一个示范套路）。但我会把重点放在：怎么让它“体现 Codex app 的能力”，而不是只写一个“能跑的提示词”。
3.1 先写清楚输出验收标准（别一上来就让 AI 跑）
我对新闻雷达的验收标准长这样：
- 每条必须包含：标题 / 来源 / 发布时间 / 一句话摘要 / 为什么重要
- 必须给：3 个内容创作角度（标题备选 + 适合栏目）
- 先提问确认：覆盖范围、时间区间、偏好（交易 or 内容）、风险偏好
你会发现：这其实就是一个 SOP。
3.2 把 SOP 写成 Skill：关键在“先问后写”
Skill 里我会强制加一段：
在输出之前，先问我 5-8 个确认问题；我回答后再输出最终版。
这样可以解决你遇到的第一个痛点：格式不稳定。
你还可以再加一个“产品经理常用小技巧”：把输出模板写得更像“结构化协议”，比如固定字段 + 固定顺序 + 明确缺失处理（【待补充】/【需核验】）。这样 Codex 的输出会稳定很多。
3.3 再把 Skill 接到 Automation：让它“按时交付，进收件箱等我审”
Automations 的正确姿势不是“全自动发出去”，而是：
定时产出草稿 → 进 Inbox/Triage → 你审核/微调 → 再发布/再决策。
对产品经理/小团队来说，这个模式非常健康：效率提升，但责任不外包。
3.4 让它“像 Codex”，而不是“像聊天机器人”：一个小改动
很多人做 Automation 的误区是：只让它在对话里吐一段文本。
这当然也能用，但它无法体现 Codex app 最关键的能力之一：可审校的变更（diff）。
我建议你给每个 Automation 加一个强制规则：
输出必须写入一个明确的文件路径（例如 reports/market-radar/2026-02-03.md），并给出变更摘要。
这么做的好处是：
- Codex 会把“交付物”变成可追踪的资产（文件）
- 你可以用 diff 视角审校：哪些句子变了、哪些字段漏了、有没有偷偷“润色成事实”
- 如果你把项目放进 Git：Automations 会用 独立 worktree 来跑（避免污染你的主目录），而且你可以选择“只 review，不 commit”
从“对话里生成一段文本”，升级为“写入可审校的交付物”，这就是 Codex app 的产品味。
图 3 - Codex app 的 diff/review 视角
4. 3 个更“硬核”的职场 Skill 模板（可直接套用）
先说清楚：模板（prompt）不是 Codex 的核心。真正能体现 Codex app 能力的是“工作流闭环”：
所以我下面给的不是“3 段提示词”，而是 3 套可交付的 Codex 工作流。
下面 3 套分别对应你最容易高频复用、也最容易在团队里“产品化”的交付物：
- 行业/竞品监控简报（适合创业者、PM、投融资关注）
- 用户反馈/工单归因与优先级（适合增长/产品/客服协同）
你可以把它们放在：
- 项目级：
<你的项目>/.codex/skills/<skill-name>/SKILL.md（推荐，方便团队共享/交接） - 用户级：
$CODEX_HOME/skills/<skill-name>/SKILL.md（更像你个人的“技能库”，CODEX_HOME 默认通常是 ~/.codex）
（两者区别：项目级更容易随项目交接；用户级更像你个人的“技能库”。）
创建完 Skill 后，记得 重启 Codex 让它加载新技能（官方文档要求）。
4.1 这 3 套“为什么能体现 Codex app”的能力，而不是另一个 Claude Code？（三条强制设计规则）
你照着下面 3 条写 Skill，Codex 的“工作台能力”会直接显现出来：
- 产物必须落盘：每次运行都写到明确路径（比如
reports/、prd/、triage/） - 在 Automation 场景下默认“只产出 + 待审校”：输出进 inbox/triage，不自动对外发布/不自动合并
- 把“确认问题”写成交互协议：先问关键问题，等你回答再生成最终版（避免臆测与跑偏）
如果你愿意更进一步（团队化/可审计），再加一条：
- 项目放进 Git：你就能用 diff 审校每次变更；Automations 还会用独立 worktree 跑，减少“自动化把仓库搞乱”的风险
模板 1：行业/竞品监控简报（Research Brief 2.0）
适用：创业者/产品经理每周必做的“信息雷达”，但要求证据可追溯、观点能落地。
把下面保存为：.codex/skills/market-radar/SKILL.md
同时我建议你在项目里准备一个产物目录（让交付物可追踪）：
reports/market-radar/（每天一份简报）reports/market-radar/INDEX.md（自动更新索引，方便回看）
---name: market-radardescription: 生成“行业/竞品监控简报”：结论先行、证据可追溯、含反例与行动建议。先提问确认后再输出。---你是我的行业研究助理。你的目标是输出一份可直接转发给团队的简报（800-1200字）。## 0) 先提问（必须先问完再输出）在开始写之前，请按顺序问我这些问题，并等待我回答：1. 这期监控的范围：行业/公司/产品/关键词？2. 时间区间：过去24h / 7天 / 30天？3. 受众是谁：团队内部 / 老板 / 投资人朋友？4. 更偏“交易辅助”还是“内容创作”？5. 我允许你用哪些信源：我提供的链接/RSS/订阅摘要？是否允许使用 Codex 的 cached web search？6. 输出要不要包含：我的个人观点（是/否）？7. 输出要写入哪个目录？（默认：reports/market-radar/）如果你运行在 Automation 里、无法等待我逐条回复：- 先把以上问题原样写到输出文件顶部的“需确认问题”区- 然后在“假设与边界”区写清楚你做了哪些默认假设，并在正文里用【需确认】标记受影响的结论## 1) 输入要求- 只基于我允许的信源工作- 所有事实要标注“证据来源”（链接或我提供材料的引用片段）- 不确定就写【需核验】，不要编## 1.5) Codex 工作台要求（关键）- 你必须把最终输出写入文件：reports/market-radar/YYYY-MM-DD.md- 同时更新索引文件：reports/market-radar/INDEX.md（追加一行：日期 + 一句话结论 + 文件相对路径）- 写完后给我一个“变更摘要”（3条以内）：新增了什么、更新了什么、有哪些需核验项- 如果当前目录是 Git 仓库： - 不要自动提交 - 输出 `git status --porcelain` 的结果## 2) 输出结构（固定）标题：行业/竞品监控简报（YYYY-MM-DD）一句话结论（<=30字）：### 1) 5条关键动态（按重要性排序）1. 标题： 来源：<链接/材料名> 时间：<时间> 摘要：<1-2句> 为什么重要：<1句>### 2) 影响评估（3条，面向受众）- 对业务/产品：...- 对竞品格局：...- 对我们本周决策：...### 3) 反例与风险（至少2条）- ...### 4) 行动建议（3条，含Owner建议）- 建议1：...（Owner建议：产品/运营/研发/我）## 3) 质量自检- [ ] 是否每条动态都有来源？- [ ] 是否混入了未经证实的数字/结论？- [ ] 行动建议是否具体到“谁做什么”？（不是口号）
Automation 建议
- 工作区：一个 Git 仓库（确保 Automations 用 worktree 跑，变更可用 diff 审）
- “运行
$market-radar。允许使用 cached web search。把结果写入 reports/market-radar/YYYY-MM-DD.md 并更新 INDEX.md。把‘需确认问题 + 执行摘要’同步到 Triage 里，等待我审核。不要自动提交。”
小提醒：如果你把它用于“港美股科技新闻辅助交易”，务必加一句风控声明：这不是投资建议，只是信息整理。
模板 2：PRD + 需求评审包（把“评审”从吵架变成流程）
适用：产品经理最痛的事之一不是写 PRD，而是“评审效率低、信息不对齐、风险没人背”。
把下面保存为：.codex/skills/prd-review-pack/SKILL.md
并在项目里准备产物目录（建议）：
prd/decision-log.md（自动汇总“需要谁拍板”的决策点）
---name: prd-review-packdescription: 基于材料生成“PRD+评审包”：目标/非目标/边界/方案/埋点/验收/风险/决策项。先提问确认后再输出，适配飞书文档结构。---你是我的产品助理。你的目标是产出一份可直接复制到飞书文档的“需求评审包”（1500-2500字）。## 0) 先提问（必须先问完再输出）开始前请问我：1. 需求一句话描述是什么？对应哪个业务目标？2. 目标用户是谁？关键使用场景是什么？3. 这次评审的“决策点”是什么？（要不要做/做哪种/做多大）4. 有哪些硬约束：时间/人力/合规/技术依赖？5. 现状数据/基线指标是什么？（没有就写【待补充】）6. 成功指标是什么？（北极星+过程指标各1个）7. 不做的范围（Non-goals）有哪些？8. 评审包要写入哪个文件？（默认：prd/<需求名>-review-pack.md）如果你运行在 Automation 里、无法等待我逐条回复：- 先把以上问题原样写到评审包顶部的“需确认问题”区- 然后先产出一个“最小可评审版本”：把缺失项用【待补充】标记，给出你建议我补充的数据口径/获取方式## 1) 输入要求- 我会提供：需求背景、用户反馈、竞品参考、历史文档、会议纪要- 所有数据必须来自输入；缺失则标注【待补充】## 1.5) Codex 工作台要求（关键）- 你必须把最终输出写入文件：prd/<需求名>-review-pack.md- 同时把“本次需要评审确认的3个问题”写入/追加到：prd/decision-log.md（便于开会直接过）- 写完后给我一个“评审摘要”（<=8 行）：- 需求一句话- 推荐方案-3个决策点-2个最大风险- 如果当前目录是 Git 仓库：- 不要自动提交- 输出 `gitstatus--porcelain`## 2) 输出结构（飞书评审包模板）标题：<需求名> 需求评审包（YYYY-MM-DD）### 1) TL;DR（一屏读完）- 需求一句话：- 为什么现在做：- 预计收益：- 关键风险：- 本次需要评审确认的3个问题：### 2) 背景与问题- ...### 3) 目标与非目标目标（Goals）：- ...非目标（Non-goals）：- ...### 4) 用户与场景目标用户：核心路径（用3-5步描述）：### 5) 方案（至少2个备选）方案A：- 优点：- 缺点/风险：方案B：- ...推荐方案：<A/B>，理由：### 6) 埋点与指标基线指标：【待补充/来自输入】成功指标：- 北极星：- 过程指标：### 7) 验收标准（最重要）- 验收1：...- 验收2：...### 8) 风险清单与对策- 风险：... 影响：... 对策：... 需要谁拍板：...### 9) 决策记录（Decision Log）| 决策点 | 选项 | 推荐 | 结论 | 拍板人 ||---|---|---|---|---|## 3) 自检- [ ] 验收标准是否可测试、可量化？- [ ] 是否把“需要谁拍板”的问题明确写出来？- [ ] 是否有Non-goals（避免范围膨胀）？
Automation 建议
- 输入方式：把本次需求材料统一贴到一个文件（例如
prd/inbox.md），避免散落在聊天记录 - “读取
prd/inbox.md，运行 $prd-review-pack。把评审包写入 prd/<需求名>-review-pack.md，把 3 个决策点追加到 prd/decision-log.md。把评审摘要放到 Triage，等我审核后再复制到飞书文档。不要自动提交。”
模板 3：用户反馈/工单归因与优先级（让“吵优先级”变成可解释）
适用：把散乱的反馈变成“可决策”的 Backlog：归因、聚类、优先级、下一步。
把下面保存为：.codex/skills/feedback-triage/SKILL.md
并在项目里准备输入/输出约定（这一步最能体现“工作台”）：
- 输入：
triage/inbox/feedback.md（把原始反馈贴进来，或让同事统一落这里） - 输出：
triage/out/<YYYY-MM-DD>-feedback-triage.md（每次跑一份可决策清单） - 可选：
triage/backlog.md（把 P0/P1 需求追加进去，长期积累）
---name: feedback-triagedescription: 将用户反馈/工单做归因聚类+优先级（RICE/ICE二选一），输出“可决策”清单与下周行动项。先提问确认后再输出。---你是我的用户洞察与需求分诊助理。你的目标是：把我给的反馈整理成可决策的清单。## 0) 先提问（必须先问完再输出）开始前请问我：1. 这批反馈来自哪里：客服工单/社群/评论区/销售转述？2. 时间范围：最近7天/30天？3. 我们现在的业务目标更偏：拉新/转化/留存/付费？4. 优先级模型用哪种：RICE 还是 ICE？5. 有哪些“必须修”的红线：安全/合规/崩溃/付费损失？6. 反馈输入文件在哪？（默认：triage/inbox/feedback.md）如果你运行在 Automation 里、无法等待我逐条回复：- 先按“默认安全口径”处理：把所有不确定项用【需确认】标记- 把上面问题写到输出文件顶部的“需确认问题”区，并继续生成一个“可讨论版本”（不拍板）## 1) 输入要求- 我会提供：反馈原文（最好带用户类型/付费状态/版本/设备）- 如果缺字段：在输出中标注【缺字段：xxx】，不要猜## 1.5) Codex 工作台要求（关键）- 你必须读取输入文件：triage/inbox/feedback.md（如果文件不存在，先提示我创建模板）- 你必须把最终输出写入：triage/out/YYYY-MM-DD-feedback-triage.md- 你必须把 P0/P1 级别的问题追加到：triage/backlog.md（如果不存在就创建）- 写完后给一个“执行摘要”（<=10 行）：-Top3 主题-P0/P1 列表- 需要我拍板的 2-3 个问题- 如果当前目录是 Git 仓库：- 不要自动提交- 输出 `gitstatus--porcelain`## 2) 输出结构（固定）### 1) 反馈概览- 总条数：- 主要来源：- 主要用户类型：### 2) 主题聚类（Top5）| 主题 | 典型原话（摘1-2句） | 可能归因 | 影响范围（粗略） | 备注 ||---|---|---|---|---|### 3) 优先级清单（可决策）| 优先级 | 需求/问题 | 归因 | 证据（原话/链接） | 评分（RICE/ICE） | 建议动作 | Owner建议 ||---|---|---|---|---|---|---|### 4) 下周行动项（3-5条）-...### 5) 需要我拍板的问题（2-3条）-...## 3) 自检- [ ] 是否每条都保留了“证据原话”？- [ ] 是否把“红线问题”置顶？- [ ] 是否给出了可执行的下一步（不是一句“优化体验”）？
Automation 建议
- 频率：每天一次（例如 19:00），或每周固定一次（例如周五 17:00）
- 输入方式：团队把反馈统一往
triage/inbox/feedback.md 追加（你只要维护一个入口） - “读取
triage/inbox/feedback.md，运行 $feedback-triage。写出 triage/out/YYYY-MM-DD-feedback-triage.md，并把 P0/P1 追加到 triage/backlog.md。把 Top 3 主题 + 需要我拍板的问题发到 Triage，等待我确认。不要自动提交。”
5. 最后给你一个“产品经理式”的底层建议
如果你想让 AI 真正变成生产力工具，我建议你不要从“提示词”开始，而是从这三个问题开始：
把这三个问题写清楚，你其实就已经写出了 SOP。
接下来只是把 SOP 变成 Skill，再把 Skill 接到 Automation。
这就是我理解的“AI 时代的产品化能力”：把一次成功，变成可复用的交付系统。
资料包领取
我把这 3 个模板整理成了一个可直接复制的资料包（含可改造建议）。
关注公众号 「硅基杠杆OS」，后台回复 「CODEX」 自动领取。
参考资料（建议你直接收藏本文）：
- OpenAI：Introducing the Codex app（2026-02-02）：https://openai.com/index/introducing-the-codex-app/
- OpenAI Developers：Codex app Features：https://developers.openai.com/codex/app/features/
- OpenAI Developers：Agent Skills：https://developers.openai.com/codex/skills
- OpenAI Developers：Codex app Automations：https://developers.openai.com/codex/app/automations
- Anthropic：Claude Code Skills（beta）：https://support.claude.com/en/articles/12512176-what-are-skills-beta-for-claude-code
- Anthropic：Claude Code Docs（命令 / agents / MCP 等）：https://docs.claude.com/en/docs/claude-code/overview
- Anthropic Blog：Claude Code Skills：https://www.anthropic.com/news/claude-code-skills
