永无岛
13.1 你是不是这样的人
每天的工作 80% 围着"文字"转：
- 写文档（PRD、需求、方案、说明书）
- 写报告（周报、月报、复盘）
- 写邮件（汇报、协调、回复）
- 写文案（产品介绍、营销稿、社媒贴文）
- 整理（会议纪要、调研记录、用户反馈）
如果是，这一章为你而写。
文字工作者用 Codex 的核心思维是：把"每周/每天都要写一遍同类东西"的事情，沉淀成 Skill；剩下的"一次性写"的事情，用四要素法 prompt 高效完成。
我们用 5 个最高频的文字场景作为实战。每个场景都给一份完整的 Skill 模板（你可以直接拷贝去用）。
13.2 场景一：周报
痛点
每周五下午 4 点开始痛苦——这周做了啥？怎么写让经理觉得我"很忙又有产出"？怎么不重复上周的话？怎么把"打杂"包装成"价值"？
Skill：weekly-report
---
name: 周报生成
description: 根据本周日志和 git commit，生成一份按"完成/进行中/风险/下周"四块结构化的周报草稿
keywords: [周报, 周记, 周总结, weekly]
version: 1.0.0
---
## 何时使用
- 用户说"写周报"、"我要写周报"、"帮我整理本周工作"
- 不调用：日报（用 daily-report）、月报（用 monthly-report）
## 输入
- 本周日志路径（默认 ~/Documents/work-log/）
- Git 仓库路径（如有，默认 ~/code/）
- 周报受众（默认"直属经理"）
- 是否包含 KPI 数字（默认是）
如未提供主动问。
## 步骤
1. 读取日志目录下本周一到本周五的 .md 文件
2. 如有 Git 仓库，运行 `git log --since="last monday" --author="$(git config user.name)" --oneline` 获取本周 commit
3. 按四块整理：
- 完成：3-5 件，按重要性降序，每件 1-2 行 + 数字依据
- 进行中：列出 + 进度 + 预计完成日
- 风险：列出 + 影响 + 应对方案
- 下周计划：≤3 件 + 明确目标
4. 全文删除主观虚词："我觉得"、"应该是"、"可能"、"差不多"
5. 输出到当前目录 weekly-report-YYYY-WW.md（WW 为周数）
## 输出
- 文件：weekly-report-YYYY-WW.md
- 长度：300-600 字
- 风格：动词开头、客观、有数字
## 验收
- 4 块都不为空（如某项无，写"无"而非省略）
- 完成项每件有数字或"已完成"标识
- 下周计划 ≤3 件
- 没有主观虚词
- 用户审核后保存为最终版
怎么用
帮我写本周周报
Codex 会调用 Skill，问几个问题（日志路径、是否有 git），然后给出草稿。你审一下，可能改两句话，发给经理。全程 5 分钟。
进阶：自动化
设一个 Automation：每周五下午 4:55 自动跑这个 Skill，5:00 你打开 Triage，5:05 发给经理。这是真实可达成的"一次性把周报这件事解决"。
13.3 场景二：会议纪要
痛点
参加会议两小时，会后还要花一小时整理纪要——决议是什么、谁负责什么、什么时间前完成、下一步有哪些动作？经常会议结束就忘掉细节，纪要写得潦草。
Skill：meeting-minutes
---
name: 会议纪要整理
description: 把会议录音转写或随手记录，整理成"决议/待办/风险/参考"四块的标准纪要
keywords: [会议纪要, 会议记录, 会议总结, meeting, minutes]
version: 1.0.0
---
## 何时使用
- 用户提供会议录音、转写文本、或会中速记笔记
- 用户说"整理会议纪要"、"会议总结"
## 输入
- 原始材料：录音转写文件 / 速记笔记 / 视频转写
- 会议元数据：时间、参会人、主题（如未提供主动问）
## 步骤
1. 通读原始材料
2. 抽取"决议"：会议达成的明确结论（不是讨论中的提议）
3. 抽取"待办"：每条标注 owner（必须有人）+ deadline（必须有日期）+ 完成标准
4. 抽取"风险"：会议中提到但未解决的问题
5. 抽取"参考"：值得记下的数据、链接、引用
6. 按 assets/template.md 模板填充
7. 输出到当前目录 meeting-YYYY-MM-DD-主题.md
## 输出
- 文件：meeting-YYYY-MM-DD-主题.md
- 长度：根据会议时长，30 分钟会议约 300 字，2 小时会议约 800 字
- 风格：客观、简洁
## 验收
- 决议是"明确达成"的，不是"提到过"的
- 每个待办有 owner + deadline
- 风险项可执行（不是"要小心"这种空话）
- 没有"大家说"、"有人说"等模糊主语，必须具名
附 assets/template.md：
# 会议纪要 - {主题}
**时间**：{时间}
**参会**：{参会人}
**记录**：{记录人}
## 决议
{决议列表}
## 待办
| 待办 | Owner | Deadline | 完成标准 |
|------|-------|----------|----------|
| ... | ... | ... | ... |
## 风险
{风险项}
## 参考
{数据、链接、引用}
怎么用
我有一份会议录音转写，文件在 meeting.txt，
是今天上午跟产品团队对 Q3 规划的会议，
帮我整理成正式纪要。
Codex 调用 Skill，5-10 分钟出一份标准纪要。
13.4 场景三：PRD 评审包
痛点
每次评审一份 PRD，要从清晰度、可行性、商业价值、风险等多个维度看。评审人多了意见乱，评审人少了又不够全面。
Skill：prd-review
---
name: PRD 评审
description: 对一份 PRD 文档从清晰度、可行性、商业价值、风险四个维度打分并输出问题清单
keywords: [PRD, 需求评审, 产品评审, prd review]
version: 1.0.0
---
## 何时使用
- 用户提供一份 PRD 文档（.md / .pdf / .docx）
- 用户说"评审 PRD"、"PRD 打分"
## 输入
- PRD 文档路径
- 项目上下文（团队规模、技术栈、用户画像，如未提供主动问）
## 步骤
1. 读取 PRD 全文
2. 按四个维度打分（1-5 分，附理由）：
- 清晰度：目标是否明确、用户场景是否清楚、UI 描述是否具体
- 可行性：技术上能不能做、需要多少人月、依赖的外部系统是否就绪
- 商业价值：解决了什么真实问题、预期 KPI 是什么、ROI 估算
- 风险：技术风险、合规风险、市场风险、竞品差异化
3. 列出 5 个最值得追问的问题
4. 列出 3 个建议补充的内容
5. 给出整体推荐：通过 / 修改后通过 / 打回重写
6. 输出到当前目录 prd-review-{文件名}.md
## 输出
- 文件：prd-review-{文件名}.md
- 长度：800-1200 字
- 结构：评分总表 + 维度详评 + 追问清单 + 补充建议 + 推荐结论
## 验收
- 4 个维度都有分数和理由
- 5 个追问是"具体问题"不是"应该考虑..."
- 推荐结论明确，不模棱两可
怎么用
评审一下这份 PRD（prd-v3.md），
项目背景：5 人团队，2 个月开发周期，目标用户是 25-35 岁职场女性。
Codex 给出一份完整评审。比你叫一个 senior PM 来 review 都细。
一个意外的好处
PRD 作者自己用这个 Skill 自查，会大幅提升交付质量——因为他知道自己的 PRD 会被这 4 个维度+5 个追问审核，写的时候就主动避开问题。
13.5 场景四：客户咨询回复
痛点
客服每天回 100+ 条咨询，80% 是重复问题，但每条都要打字。回得太机械客户不满意，回得太走心又太慢。
Skill：customer-faq
---
name: 客户咨询回复
description: 根据 FAQ 知识库，为客户咨询生成专业、有温度的回复草稿
keywords: [客服, 客户回复, 咨询, FAQ, 回答客户]
version: 1.0.0
---
## 何时使用
- 用户提供一段客户消息，请求生成回复
- 用户说"帮我回这条客户咨询"
## 输入
- 客户消息原文
- 客户基本信息（如有：会员等级、历史订单等）
- FAQ 知识库：references/faq.md
## 步骤
1. 解析客户消息，识别核心诉求（最多 3 个）
2. 在 references/faq.md 中查找匹配的标准答案
3. 如无匹配，根据 references/policies.md 推断答案
4. 按客户消息的语气调整回复语气：
- 客户情绪正常 → 标准客服语气
- 客户着急 → 快速给答案、少寒暄
- 客户愤怒 → 先共情、再解决方案
5. 控制长度：能 100 字内说清就不用 300 字
6. 末尾问"还有什么需要帮助的"或具体的引导问题
7. 输出回复草稿（不直接发，等客服审核）
## 输出
- 直接展示回复草稿
- 标注：使用了哪条 FAQ、置信度（高/中/低）
- 如果置信度低，建议人工接管
## 验收
- 回答了客户的核心诉求
- 没有承诺无法兑现的事（如"立即处理"，但实际处理周期 3 天）
- 没有泄露内部信息（成本、销售数据、其他客户）
- 语气专业但有温度
怎么用
客服收到："我昨天买的衣服小了，能换大一码吗？"
帮我回这条客户咨询：[贴客户原话]
客户是普通会员，没买过其他东西。
Codex 给出回复草稿：
您好，感谢联系！可以为您安排换货。我们的政策是 7 天内未洗未穿可换码（您这单是昨天的，符合）。请告诉我您要换的尺码（XS/S/M/L/XL），我帮您下换货单。需要您把原件寄回我们仓库（地址会发您）。换货流程通常 5 个工作日。还有什么需要帮助的吗？
[使用 FAQ #023 换货政策，置信度：高]
客服点"发送"或者改两句话再发。速度比纯人工快 3-5 倍。
进阶：让 Codex 当一线值班
更激进的做法：所有非"特殊问题"由 Codex 直接回（设置自动批准），只有它判断"置信度低"或"涉及金额/退款"才转人工。这是很多公司在做的事，效率提升 10 倍，客户满意度也提升（响应速度快）。
但有边界：永远不要让 AI 做"承诺"——退款金额、补偿方案、SLA 承诺都要人工拍板。
13.6 场景五：选题简报
痛点
公众号 / 视频号 / 小红书运营每周要"选题"，但行业信息分散在几十个地方。每周一上午光是看资料就花 3 小时。
Skill：content-radar
---
name: 内容选题雷达
description: 扫描信息源，发现近期热点话题，给出可发布的选题角度建议
keywords: [选题, 选题雷达, 热点, 内容策划, 话题]
version: 1.0.0
---
## 何时使用
- 用户说"帮我找选题"、"今天发什么"、"选题雷达"
## 输入
- 账号定位：references/brand.md（必须，包含目标用户、主题领域、语气）
- 信息源：references/sources.md
- 时间范围：默认过去 3 天
- 数量：默认 5 个候选
## 步骤
1. 访问 references/sources.md 列出的所有信息源
2. 抽取过去 3 天的所有标题和摘要
3. 按"热度"排序（评论数、点赞数、转发数）
4. 按 references/brand.md 的定位过滤（不符合的丢掉）
5. 选出 TOP 5
6. 每个候选生成：
- 原始话题
- 你的账号可以从什么角度切入（独特视角）
- 标题候选（3 个）
- 预期热度（高/中/低）+ 理由
- 推荐发布时间
7. 输出到当前目录 topics-YYYY-MM-DD.md
## 输出
- 文件：topics-YYYY-MM-DD.md
- 长度：800-1200 字
- 结构：5 个候选每个独立段落 + 总体推荐顺序
## 验收
- 每个候选都标了原始来源链接
- 切入角度跟原始报道不同（避免成"二手新闻"）
- 标题候选符合账号语气（看 brand.md）
- 预期热度有理由，不是"我觉得"
怎么用
帮我做下周的选题雷达，
账号定位见 brand.md，
重点关注最近 5 天的 AI 工具相关话题。
Codex 出一份候选清单。你挑 2-3 个动手写。
团队场景
如果是团队（编辑部 5-10 人），可以让 Codex 每周一早上 8 点自动跑，结果发到团队飞书群。大家一起讨论选题，效率比"人肉刷资讯"高 5 倍。
13.7 通用文字工作的 4 个 Codex 用法
除了上面 5 个 Skill 化的高频场景，还有 4 个通用用法值得掌握：
用法 A：起草第一稿
帮我起草一封邮件给 [收件人]，主题是 [主题]。
要点：[1, 2, 3]
语气：[正式 / 友好 / 紧急]
长度：[一段 / 三段]
任何文字工作"起草"环节都能交给 Codex。你专注于"修改"和"判断"。
用法 B：润色与改写
帮我把这段话改成更口语化的风格：
[原文]
或：
这段话写得太长，砍到 100 字以内：
[原文]
用法 C：翻译（带专业术语）
帮我把这段中文翻成英文，注意专业术语：
- "需求" 翻成 requirement
- "评审" 翻成 review
- "上线" 翻成 release
[原文]
用法 D：自检与挑刺
读一下这份文档（doc.md），从专业读者的角度，
找出 5 个最大的问题（论据弱、逻辑跳、用词不当...）。
发出去之前自检一遍，比同事 review 快又准。
13.8 文字工作者的"工作台"配置
把所有写作类工作集中到一个 Codex 工作台：
~/codex-workspace/writing/
├── AGENTS.md # 全局写作规范
├── .codex/
│ ├── skills/
│ │ ├── weekly-report/
│ │ ├── meeting-minutes/
│ │ ├── prd-review/
│ │ ├── customer-faq/
│ │ └── content-radar/
│ └── memory.md
├── projects/ # 各类写作项目
│ ├── work-log/ # 日常工作日志
│ ├── reports/ # 各类报告
│ └── content/ # 自媒体内容
└── references/ # 共享参考资料
├── brand.md
├── faq.md
├── glossary.md # 行业术语表
└── style-guide.md # 写作风格指南
AGENTS.md（写作工作台专用）示例：
# 写作工作台
## 核心规则
### 风格
- 中文为主，专业术语用英文括号
- 不用 emoji
- 短句优先：超过 30 字的句子拆开
- 数据有出处，不编造
### 结构
- 长文（>500 字）必须有 H2 / H3 分段
- 列表用统一符号（- 或 1.）
- 表格用 Markdown 格式
### 禁忌
- 不写"我觉得"、"应该是"
- 不写营销词："极致"、"颠覆"、"赋能"
- 不用 emoji 装饰
## 输出格式
任何文字产出都用 Markdown，文件名格式：YYYY-MM-DD-主题.md
## Boundaries
### Always
- 写完自己读一遍，删冗余
- 数据写明来源
- 列出版权风险（如引用了别人内容）
### Never
- 不要自动发邮件 / 推社媒（永远人工拍板）
- 不要替我做"承诺"性的文字
- 不要在公开内容里出现客户名、内部数据
13.9 一个心态调整
很多文字工作者用 Codex 后有一种焦虑："AI 写得比我好，我还有什么价值？"
这个焦虑可以理解，但是错的。
AI 的"写"能力是替代你的体力部分；AI 永远替代不了你的"判断"和"取舍"。
具体来说：
- AI 能写一稿，但选哪一稿、改哪一句、用什么语气，你定
- AI 能整理素材，但什么值得说、什么不该说、什么时候说，你定
- AI 能批量产出，但读者是谁、怎么走心、怎么共情，你定
文字工作者用 Codex 后真正的变化是：从"打字员"升级为"主编"。
主编不打字，但主编决定每一个字是否该出现。这是一个更值钱的位置。
13.10 本章小结
- 文字工作者的核心思维：高频任务 Skill 化，一次性任务用 prompt
- 5 个高频 Skill：周报、会议纪要、PRD 评审、客户回复、选题雷达
- 通用用法：起草、润色、翻译、自检
- 搭一个"写作工作台"，集中管理 Skills 和 references
- 心态：从"打字员"升级为"主编"，AI 替你写体力活，你负责判断
下一章看数据和办公场景：第十四章 · 办公自动化。