Codex 进阶能力手册

本版定位

这一版覆盖 Codex 的进阶能力和真实业务场景：MCP、Skill、浏览器自动化、飞书、视觉、TTS、Office、文本处理、业务场景、项目实战和高级协作。

适合读者：

• 已经会用 Codex 完成基础文件修改的人。
• 想把 Codex 接入办公、内容、数据、项目开发的人。
• 想理解 Skill、MCP、多 Agent、Worktree 等进阶协作方式的人。

阅读前建议：

• 先读《Codex 零基础入门教程》。
• 至少完成一个小页面或一个 CSV 分析练习。
• 遇到具体任务时，优先按章节选择阅读，不必从头读到尾。

重要边界：Skill、项目实战和官方来源

截至 2026-05-21 复查，OpenAI 官方 Codex 文档已经包含 Skills 页面，并说明 Skill 是包含 SKILL.md 的文件夹，Codex 可以通过显式或隐式方式使用 Skill；对应链接见资料包附录 G.2。因此，本手册不把 Skill 章节降级为“Claude 专属体系”。正确口径是：

• 本书所说 Skill 以 OpenAI Codex 官方 Skills 文档为准。
• 不同 Codex 版本、客户端、插件和组织配置可能影响 Skill 的安装位置、发现方式和可用命令。
• 如果读者当前环境不能自动加载某个 Skill，就把该章当作“可复用工作流规范”，通过 AGENTS.md 显式引用、MCP 或自定义工具来落地。
• 涉及安装、目录和命令的地方，发布前必须回到官方文档和当前客户端复核。

项目实战章节也要降低承诺：如果没有真实仓库、真实运行记录、错误现场、成本记录和 git log，就只能叫“项目路线示例”，不能叫“可复现实战”。

本版目录

• 第17章 MCP 通用协议定位
• 第18章 Skill 的概念及定位
• 第19章 Skill 的目录结构与安装思路
• 第20章 元能力 Skill
• 第21章 浏览器 Skill：搜索、抓取与网页自动化
• 第22章 飞书 CLI：打通办公流
• 第23章 视觉创作 Skill：多模态配图与设计素材
• 第24章 TTS 语音 Skill：赋予内容声音
• 第25章 Office 自动化 Skill：从对话到专业交付物
• 第26章 文本与内容处理 Skill：全能转换与脱水专家
• 第27章 小白开发者的全栈 Skill 宝藏
• 第五部分：业务场景 Skill 实战
• 第28章 业务场景 Skill 的设计思路
• 第29章 实战：会议纪要 Skill
• 第30章 实战：教程改写与知识库整理 Skill
• 第31章 实战：数据分析与图表报告 Skill
• 第32章 实战：自媒体运营 Skill
• 第33章 实战：客户跟进与销售辅助 Skill
• 第34章 实战：飞书办公协同 Skill
• 第35章 实战：行业研究报告 Skill
• 第六部分：编程项目实战
• 第36章 从零搭建项目
• 第37章 文件数据清洗工具
• 第38章 智能体对话平台（待补真实仓库，否则降级为选题索引）
• 第39章 数字人口播视频工具（待补真实仓库，否则降级为选题索引）
• 第40章 开发一个小程序
• 第41章 开发 iOS APP（待补真机记录，否则降级为选题索引）
• 第42章 AI 硬件功能开发——以 ESP32 开发板为例（待补硬件记录，否则降级为选题索引）
• 第七部分：高级技巧
• 第43章 Agent 蜂群写作
• 第44章 Worktree：多分支并行开发
• 第45章 多 AI 工具协作：Stitch、前端设计与外部工具配合
• 第46章 成熟项目架构模板复用
• 第47章 常见踩坑与能力边界
• 结语

第17章 MCP 通用协议定位

17.0 本章你会学到什么

学完这一章，你会知道：

• MCP 是什么。
• 为什么它对 Codex 很重要。
• MCP 和普通插件、API 有什么区别。
• 新手什么时候需要关心 MCP，什么时候可以先不管。

这一章只讲定位，不带你写 MCP 服务。小白阶段先把概念放对，比一上来堆配置更重要。

17.1 一句话解释 MCP

MCP 的全称是 Model Context Protocol，可以先理解成：

一套让 AI 连接外部工具和外部资料的通用协议。

如果不用 MCP，Codex 主要能看到你给它的对话、文件、截图和本地项目。

有了 MCP，它就可以通过统一方式连接更多东西，比如：

• 文档库
• 设计工具
• 浏览器
• 数据库
• 工单系统
• 内部 API
• 公司知识库

你可以把 MCP 想象成一排标准插座。不同工具只要按这个标准做一个"插头"，Codex 就有机会接上去。

这就是它最重要的价值：不是为每个工具单独定制一套沟通方式，而是让工具接入变得更统一。

17.2 为什么 Codex 需要 MCP

Codex 再聪明，也不能凭空知道你公司数据库里的内容、Figma 里的设计稿、浏览器当前页面的真实状态。

如果你只靠复制粘贴，事情会变成这样：

1. 你打开网页。
2. 手动复制内容。
3. 粘到 Codex。
4. Codex 分析。
5. 你再把结果拿回网页操作。

这个流程能用，但很笨。

MCP 的目标，是让 Codex 可以更自然地连接这些外部环境。比如：

• 需要查内部文档时，让 Codex 通过文档 MCP 搜索。
• 需要看设计稿时，让 Codex 通过设计工具 MCP 获取结构信息。
• 需要操作浏览器时，让 Codex 通过浏览器相关工具查看页面状态。
• 需要读某个系统数据时，让 Codex 通过对应服务拿上下文。

这样 Codex 就不只是"读你贴过来的内容"，而是能在你授权的范围内主动使用工具。

17.3 MCP 和 API 有什么区别

很多人会问：这不就是 API 吗？

有点像，但不是一回事。

API 更像是某个系统自己的门。比如飞书有飞书 API，Notion 有 Notion API，GitHub 有 GitHub API。每个门的钥匙、格式、规则都不一样。

MCP 更像是给 AI 设计的一套通用接入方式。它不替代底层 API，而是把工具能力包装成 AI 更容易理解和调用的形式。

简单对比：

所以你可以这样理解：

API 是系统能力的原始接口，MCP 是把这些能力交给 AI 使用的一种标准方式。

17.4 MCP 在 Codex 里的常见形态

在 Codex 里，MCP 通常表现为"可配置的工具服务器"。

常见有两类：

1. 本地进程型：在你电脑上启动一个命令，由这个命令提供工具能力。
2. HTTP 服务型：连接一个网络地址，由远程服务提供工具能力。

你不需要一开始记这些技术细节，只要知道：

• 有些 MCP 工具跑在你本机。
• 有些 MCP 工具跑在远程服务。
• 有些需要 token 或 OAuth 登录。
• 配置通常会写在 Codex 的配置文件里，或者通过 Codex CLI 命令添加。

OpenAI Codex MCP 文档说明，Codex 可以通过 codex mcp 管理 MCP 服务器，也可以在 config.toml 里配置；默认用户级配置路径是 ~/.codex/config.toml，可信项目里也可以使用项目级 .codex/config.toml。具体命令会随版本变化，新手不要死背，跟着当前官方文档走。

17.5 新手什么时候需要 MCP

不是所有人一上来都要学 MCP。

如果你只是：

• 写一篇文章。
• 整理一个 Markdown。
• 生成一个简单网页。
• 分析一个本地 CSV。
• 修改几个本地文件。

那完全可以先不管 MCP。

当你遇到下面这些需求时，再开始关注它：

• 想让 Codex 访问某个外部系统。
• 想让 Codex 搜索公司内部知识库。
• 想让 Codex 读取设计工具里的结构。
• 想让 Codex 操作浏览器或办公系统。
• 想把公司已有 API 包成 AI 能用的工具。

一句话：

本地文件够用时，先不用 MCP；外部工具和外部数据变多时，再学 MCP。

17.6 MCP 的风险意识

MCP 很强，但也意味着 Codex 可能接触更多系统，所以要有边界意识。

新手尤其记住三点：

• 不要随便安装来路不明的 MCP 服务。
• 不要把重要 token、cookie、API Key 直接发给不可信工具。
• 不确定某个 MCP 会读写什么数据时，先查说明，再小范围测试。

如果一个 MCP 只读文档，风险相对低。

如果一个 MCP 能发消息、删数据、改线上配置，风险就高很多。

所以配置 MCP 时，不要只问"能不能用"，还要问：

它能访问什么？能修改什么？出错后能不能回滚？

17.7 本章小结

• MCP 是让 AI 连接外部工具和上下文的通用协议。
• 它不等于 API，而是把工具能力包装成 Codex 更容易使用的方式。
• 新手先把 MCP 理解成"给 Codex 加工具插座"就够了。
• 本地任务先不用急着学 MCP；外部系统、内部资料、自动化工具多了，再深入。
• MCP 越强，越要注意权限、凭证和数据边界。

下一章我们讲 Skill：如果 MCP 是连接工具，那 Skill 就是沉淀方法。

第18章 Skill 的概念及定位

18.0 本章你会学到什么

学完这一章，你会知道：

• Skill 是什么。
• Skill 和提示词模板有什么区别。
• Skill 和 MCP 又有什么关系。
• 新手应该怎么判断一个任务适不适合做成 Skill。

这一章的核心是：Skill 不是让 Codex 多一个工具，而是让 Codex 多一种稳定做事的方法。

官方依据：OpenAI Codex Skills 文档把 Skill 定义为一个包含 SKILL.md 的文件夹，用来给 Codex 提供可复用流程知识。本文后面的业务 Skill 示例，既可以按当前 Codex Skills 机制配置，也可以在暂时无法自动加载时作为团队内部工作流规范使用。

18.1 一句话解释 Skill

Skill 可以理解成：

一套可复用的 AI 工作流程说明。

比如你经常让 Codex 做这些事：

• 整理会议纪要。
• 把长文改成小红书风格。
• 检查 Markdown 文档格式。
• 从 CSV 生成分析报告。
• 按固定标准审查代码。

每次都重新写提示词，很麻烦，也容易漏步骤。

Skill 就是把这些重复使用的方法写成一个独立说明，让 Codex 在合适的时候加载并遵守。

它可以包含：

• 什么时候使用这个 Skill。
• 执行任务时的步骤。
• 输出格式要求。
• 注意事项。
• 可选脚本。
• 参考资料。
• 模板素材。

如果 AGENTS.md 是"这个项目怎么协作"，Skill 就是"这类任务怎么做"。

18.2 Skill 和普通提示词模板的区别

提示词模板通常是一段可以复制粘贴的话。

比如：

请帮我把下面内容整理成会议纪要，包含背景、讨论、结论和待办。

这当然有用，但它有几个问题：

• 每次都要手动复制。
• 模板长了以后不好维护。
• 很难携带额外脚本和参考文件。
• 很难让 Codex 自动判断什么时候该用。

Skill 更像一个小型工作包。

它有自己的名字、触发描述、说明文件，还可以带脚本、参考资料和素材。Codex 看到任务匹配时，可以主动加载这份说明。

对比一下：

所以，提示词模板适合轻量复用；Skill 适合沉淀一套真正的方法。

18.3 Skill 和 MCP 的区别

MCP 和 Skill 经常一起出现，但它们解决的问题不一样。

简单说：

• MCP 解决"能接什么工具"。
• Skill 解决"接到工具后怎么做事"。

举个例子：

你想让 Codex 帮你整理会议纪要。

可能需要：

• 通过日历或会议系统获取会议记录。
• 通过文档工具生成纪要。
• 按固定结构输出结论和待办。

这里面：

• 连接日历、会议系统、文档系统，可能靠 MCP 或插件工具。
• "怎么整理会议纪要"，更适合写成 Skill。

再举一个数据分析例子：

• MCP 让 Codex 读取某个表格系统。
• Skill 告诉 Codex 分析时先清洗字段、再看异常值、最后生成图表和结论。

工具是手，Skill 是手法。

18.4 Skill 适合沉淀什么

不是所有任务都值得做成 Skill。

适合做成 Skill 的任务通常有三个特点：

1. 重复出现：你一周或一个月会做很多次。
2. 步骤稳定：每次都差不多按同一套流程走。
3. 有质量标准：输出格式、检查项、注意事项比较固定。

比如适合：

• 每周整理会议纪要。
• 每天生成日报。
• 每次发版前检查文档。
• 每次分析表格都按固定模板出报告。
• 每次写教程都按固定章节结构展开。

不太适合：

• 一次性的随口问题。
• 还没想清楚的创意脑暴。
• 每次流程都完全不同的任务。
• 很危险、需要人工强审核的操作。

一句话判断：

如果你第三次写同一类提示词，就可以考虑把它变成 Skill。

18.5 新手可以先用哪些 Skill

新手阶段不一定要自己写 Skill，可以先学会使用现成 Skill。

常见方向包括：

• 文档处理 Skill：整理、润色、改写、生成结构化文档。
• 表格分析 Skill：读取 CSV/Excel，生成结论和图表。
• 浏览器 Skill：打开网页、截图、检查页面效果。
• 图片生成 Skill：生成配图、封面、素材。
• 办公自动化 Skill：处理文档、幻灯片、邮件、会议纪要。
• 代码审查 Skill：按固定标准检查变更。

先用现成的，再学会改，最后再自己写。

这和学做菜很像：先照菜谱做几次，知道味道和步骤，再慢慢改成自己的版本。

18.6 使用 Skill 的注意事项

Skill 虽然能提升稳定性，但不是魔法。

使用时注意三点：

• 描述要清楚：Skill 的触发描述越清楚，Codex 越容易在正确场景使用。
• 范围要收窄：一个 Skill 只解决一类任务，不要把所有功能塞进去。
• 结果要验证：Skill 只是流程说明，输出仍然需要检查。

不要写一个叫"万能助手"的 Skill。

这样的 Skill 听起来很厉害，实际最容易失控。更好的命名是：

• meeting-summary
• csv-report
• tutorial-polisher
• markdown-checker

名字越具体，越容易用对。

18.7 本章小结

• Skill 是可复用的 AI 工作流程说明。
• 它比提示词模板更系统，可以包含说明、脚本、参考资料和素材。
• MCP 偏"连接工具"，Skill 偏"沉淀方法"。
• 重复、稳定、有质量标准的任务，最适合做成 Skill。
• 新手先用现成 Skill，再学习修改和自定义。

下一章我们拆开一个 Skill 看看：它的目录结构通常长什么样，应该放在哪里，又该怎么安装。

第19章 Skill 的目录结构与安装思路

19.0 本章你会学到什么

学完这一章，你会知道：

• 一个 Skill 通常包含哪些文件。
• SKILL.md 是什么角色。
• scripts/、references/、assets/ 分别适合放什么。
• Skill 应该放在项目里，还是放在个人目录里。
• 新手安装 Skill 时要注意什么。

这一章会出现一点目录结构，但不用怕。你先把它当成普通文件夹理解就行。

19.1 一个 Skill 最少需要什么

一个 Skill 最少只需要两样东西：

1. 一个文件夹。
2. 文件夹里有一个 SKILL.md。

比如：

markdown-checker/
└── SKILL.md

SKILL.md 是这个 Skill 的说明书。

它通常会写：

• Skill 名字。
• 什么时候使用。
• 具体执行步骤。
• 输出格式。
• 注意事项。

一个非常简化的例子：

---
name: markdown-checker
description: 检查 Markdown 文档结构、标题层级、空链接、代码块围栏和常见排版问题。
---

# Markdown Checker

使用这个 Skill 时：

1. 先统计文件行数和标题结构。
2. 检查代码块围栏是否配对。
3. 检查空链接、图片缺失、TODO 标记。
4. 输出问题清单和修改建议。

注意开头的 --- 区域。它叫元数据，里面的 name 和 description 很关键。

Codex 会根据这些信息判断这个 Skill 是什么、什么时候可能该用。

19.2 常见目录结构

稍微完整一点的 Skill 可能长这样：

my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/

每个目录的作用：

不是每个 Skill 都需要这些目录。

如果只是告诉 Codex 一套写作流程，可能一个 SKILL.md 就够。

如果任务需要稳定处理文件，比如把一批 Markdown 转成网页，放脚本就很有价值。

19.3 SKILL.md 应该怎么写

新手写 SKILL.md，先别追求完美。按这个结构就够：

---
name: tutorial-polisher
description: 当用户需要润色教程章节、统一小白友好文风、检查章节结构时使用。
---

# Tutorial Polisher

## 什么时候使用

当任务涉及教程改写、章节补充、文风统一时使用。

## 工作步骤

1. 先确认目标读者和当前章节位置。
2. 保持原文核心观点，不随意删内容。
3. 统一为口语化、小白友好的表达。
4. 每章保留“本章你会学到什么”和“本章小结”。
5. 修改后检查标题层级、代码块和目录状态。

## 输出要求

- 先列修改摘要。
- 再说明是否还有待补内容。
- 如果发现事实可能过期，提醒用户查官方文档。

你会发现，它本质上就是把你希望 Codex 遵守的工作方法写清楚。

写 Skill 时，最重要的是 description。它不能太玄。

不要写：

description: 一个强大的教程处理工具。

更好的是：

description: 当用户需要润色教程章节、统一小白友好文风、检查章节结构时使用。

后者明确告诉 Codex：什么场景该用它。

19.4 Skill 放在哪里

Skill 可以有不同作用范围。

新手可以先按两类理解：

如果某个 Skill 只适合这本教程，比如"按本教程风格补章节"，就适合放在项目里。

如果某个 Skill 是你长期都会用的，比如"检查 Markdown"、"整理会议纪要"，就适合放到个人 Skill 目录。

OpenAI Codex Skills 文档说明，Codex 可从不同作用范围读取 Skills；实际路径、命令和管理入口会受客户端版本、插件和组织配置影响。新手不用先背路径，关键是理解作用范围：

• 项目级 Skill：跟项目走，适合团队共享。
• 用户级 Skill：跟你个人走，适合个人习惯。
• 系统或管理员级 Skill：通常由组织统一配置。

19.5 配置或启用 Skill 的基本思路

配置或启用 Skill，本质上就是让 Codex 能找到这个 Skill 文件夹，并知道什么时候使用它。

常见方式有三种：

1. 通过 Codex 当前界面或命令安装：适合官方或插件提供的 Skill，具体入口以当前客户端为准。
2. 从已有项目复制 Skill 文件夹：适合团队内部复用。
3. 自己创建一个 Skill 文件夹：适合沉淀个人流程。

新手优先用第一种。

如果你要手动配置，至少检查四件事：

• 文件夹里是否有 SKILL.md。
• SKILL.md 开头是否有 name 和 description。
• 有没有脚本需要额外安装依赖。
• 这个 Skill 会不会读取或修改敏感文件。

如果 Skill 来自陌生来源，尤其要小心 scripts/ 目录。因为脚本可能会执行命令，风险比纯文字说明更高。

测试时优先显式调用：在支持的 CLI/IDE 环境里，可以用 /skills 查看或用 $ 提及 Skill；如果当前环境没有这个入口，就把 SKILL.md 内容通过提示词或 AGENTS.md 明确交给 Codex，不要假设它已经自动加载。

19.6 如何测试一个 Skill 是否生效

安装后，可以用一个很小的任务测试。

比如你装了 markdown-checker，就可以问：

请使用 $markdown-checker 检查这份 Markdown 文档的结构问题。

或者不点名，直接说：

请检查这份 Markdown 文档的标题层级、代码块和空链接。

如果 Skill 的 description 写得好，Codex 可能会自动判断该使用它。

测试时不要一上来就丢真实大项目。先用一个小文件试：

• 看它是否按步骤执行。
• 看输出格式是否稳定。
• 看有没有误改文件。
• 看是否需要补充限制条件。

如果效果不稳定，优先改 SKILL.md，而不是每次在对话里补一堆说明。

19.7 本章小结

• Skill 最少是一个包含 SKILL.md 的文件夹。
• SKILL.md 里的 name 和 description 决定 Codex 能否正确识别它。
• scripts/ 放脚本，references/ 放参考资料，assets/ 放模板素材。
• 项目级 Skill 适合团队共享，个人级 Skill 适合长期习惯。
• 安装陌生 Skill 时，要特别注意脚本和权限风险。

下一章我们讲"元能力 Skill"：不是解决某个业务场景，而是教 Codex 更好地规划、调试、验证和复盘。

第20章 元能力 Skill

20.0 本章你会学到什么

学完这一章，你会知道：

• 什么是元能力 Skill。
• 它和业务 Skill 有什么区别。
• 常见的元能力 Skill 有哪些。
• 为什么它们是从入门走向熟练使用的关键。

如果说业务 Skill 是"帮你做某件事"，元能力 Skill 就是"帮你把事情做得更稳"。

20.1 什么是元能力

元能力听起来有点抽象，其实很好理解。

普通能力是：

• 写一篇文章。
• 生成一张图。
• 分析一份表格。
• 做一个网页。

元能力是：

• 怎么把需求问清楚。
• 怎么把大任务拆小。
• 怎么排查问题。
• 怎么验证结果。
• 怎么复盘流程。

也就是说，元能力不是直接产出某个业务结果，而是提升你做所有事情的稳定性。

放到 Codex 里，元能力 Skill 就是：

让 Codex 在规划、执行、调试、验证、复盘这些环节更有章法的 Skill。

20.2 业务 Skill 和元能力 Skill 的区别

对比一下：

业务 Skill 更像某个岗位的专业流程。

元能力 Skill 更像项目管理和工程习惯。

比如你要做一个数据分析报告：

• csv-report 这种业务 Skill 会告诉 Codex 怎么读取 CSV、怎么分析、怎么画图。
• writing-plans 这种元能力 Skill 会告诉 Codex 先把任务拆成步骤。
• verification-before-completion 这种元能力 Skill 会提醒 Codex 完成前必须跑验证。

两类 Skill 经常配合使用。

20.3 常见元能力 Skill

常见的元能力 Skill 可以分成几类：

1. 需求澄清类

适合任务还不清楚的时候使用。

它会引导 Codex 先问目标、范围、约束和成功标准，而不是马上动手。

适合场景：

• "帮我做个网站。"
• "帮我优化这个项目。"
• "帮我设计一个自动化流程。"

2. 写计划类

适合任务已经明确，但步骤较多的时候使用。

它会把任务拆成可执行步骤、文件范围、验证方式。

适合场景：

• 多文件修改。
• 长文档重构。
• 项目从 0 到 1 搭建。
• 需要分阶段执行的工作。

3. 系统调试类

适合遇到报错、测试失败、功能异常时使用。

它会要求先复现问题、收集证据、定位原因，再提出修改方案。

适合场景：

• 页面打不开。
• 脚本运行报错。
• 测试失败。
• 生成结果不符合预期。

4. 验证收尾类

适合任务接近完成时使用。

它会提醒 Codex 不要只凭感觉说"完成了"，而是要跑检查、看输出、确认结果。

适合场景：

• 改完代码。
• 补完文档。
• 生成报告。
• 发布前检查。

20.4 为什么元能力 Skill 很重要

新手常见的问题不是"不会让 Codex 做事"，而是：

• 需求没说清就开始做。
• 大任务没拆开就一次性执行。
• 报错时让 Codex 乱猜。
• 结果没验证就以为完成。
• 每次踩坑都没有沉淀。

元能力 Skill 正好管这些问题。

它们会把 Codex 从"聪明但容易跑偏"拉回到"按流程推进"。

这也是为什么越到后面，你越会发现：真正厉害的人，不只是提示词写得好，而是会让 AI 按正确流程工作。

提示词是一句话。

流程是一套系统。

元能力 Skill 就是把流程系统化。

20.5 新手怎么开始使用元能力 Skill

新手不用一下子学很多。先记四种场景：

这些话哪怕不绑定具体 Skill，也是在训练 Codex 使用元能力思维。

如果你已经安装了对应 Skill，可以更明确地说：

请使用 $brainstorming，先帮我梳理这个需求。

请使用 $writing-plans，把这个任务拆成可执行计划。

请使用 $systematic-debugging，帮我排查这个报错。

请使用 $verification-before-completion，检查这次修改是否真的完成。

名称可能因你的环境不同而不同，但思路一致。

20.6 把自己的经验变成元能力 Skill

当你和 Codex 协作久了，会慢慢形成自己的工作习惯。

比如：

• 写教程前，先列读者画像。
• 改文档前，先检查目录状态。
• 做网页前，先明确移动端尺寸。
• 数据分析前，先保留原始文件。
• 任务完成前，必须跑一遍结构检查。

这些经验如果只停留在脑子里，每次都要重新提醒。

更好的方式，是把它们写进 Skill。

例如你可以做一个 tutorial-writing-process：

---
name: tutorial-writing-process
description: 当用户需要补充、重构或检查小白教程章节时使用。
---

# Tutorial Writing Process

1. 先确认当前章节位置和读者水平。
2. 保持每章结构一致：学习目标、正文、常见误区、本章小结。
3. 遇到可能过期的工具信息，先查官方文档。
4. 修改后检查目录状态、标题层级、代码块围栏。
5. 最后输出修改摘要和剩余待补内容。

这就是把你的写作方法变成可复用能力。

20.7 本章小结

• 元能力 Skill 不直接服务某个业务结果，而是提升规划、调试、验证、复盘的质量。
• 业务 Skill 解决"做什么"，元能力 Skill 解决"怎么更稳地做"。
• 常见元能力包括需求澄清、写计划、系统调试、完成前验证。
• 新手先学会在关键节点提醒 Codex：先澄清、先计划、先排查、先验证。
• 当你的协作习惯稳定下来，就可以把它沉淀成自己的 Skill。

到这里，你已经理解了 MCP 和 Skill 的基本定位。

接下来几章会进入更具体的能力场景：浏览器 Skill、飞书 CLI、视觉创作、TTS、Office 自动化和内容处理。它们会把"工具接入"和"流程沉淀"真正落到业务里。

第21章 浏览器 Skill：搜索、抓取与网页自动化

21.0 本章你会学到什么

学完这一章，你会知道：

• 浏览器 Skill 能帮 Codex 做什么。
• 它和普通联网搜索有什么区别。
• 什么时候适合让 Codex 打开网页、截图、点击、检查页面。
• 新手使用浏览器自动化时要注意哪些风险。

这一章的关键词是：让 Codex 看见真实网页。

21.1 为什么需要浏览器 Skill

很多任务不是只看本地文件就能完成的。

比如：

• 检查你刚做好的网页在浏览器里是否显示正常。
• 看一个后台页面有没有报错。
• 打开某个网页，提取里面的标题和表格。
• 测试按钮点击后有没有弹窗。
• 截图给你看页面当前状态。

这些事情，普通聊天式 AI 做不了，因为它看不到你的真实浏览器。

浏览器 Skill 的价值，就是让 Codex 能通过浏览器观察网页、操作页面、验证结果。

你可以把它理解成：

给 Codex 一双能看网页、能点按钮的手和眼睛。

21.2 浏览器 Skill 和联网搜索的区别

很多人会把浏览器 Skill 和联网搜索混在一起。

它们不一样。

联网搜索更像查资料：

• 搜索关键词。
• 打开结果。
• 总结信息。
• 对比多个来源。

浏览器 Skill 更像操作网页：

• 打开一个具体页面。
• 看页面实际渲染效果。
• 点击按钮。
• 填写表单。
• 截图验证。
• 检查交互是否正常。

简单对比：

比如你问：

帮我查一下 Codex CLI 最新安装方式。

这更像联网搜索。

但你问：

帮我打开本地网页，看看手机宽度下按钮有没有被遮住。

这就是浏览器 Skill 的典型场景。

21.3 浏览器 Skill 能做哪些事

常见能力包括：

• 打开网页。
• 读取页面可见文字。
• 点击按钮和链接。
• 输入表单内容。
• 滚动页面。
• 截图。
• 检查页面布局。
• 验证本地开发页面。

对小白最实用的场景有三个。

场景一：检查本地网页

比如你让 Codex 生成了一个 index.html，可以继续说：

请用浏览器打开这个页面，检查是否能正常显示，并截图确认。

场景二：验证交互

比如页面里有筛选按钮：

请打开页面，点击筛选按钮，确认列表是否会更新。

场景三：查看真实页面状态

比如你怀疑页面布局乱了：

请在浏览器里检查 390px 宽度下的页面，看看有没有文字重叠或横向滚动。

这比只让 Codex "猜一下代码有没有问题"靠谱得多。

21.4 浏览器 Skill 在网页开发里的作用

做网页时，新手最容易犯一个错：

只看代码，不看页面。

代码看起来没错，不代表页面真的好看。

页面真实效果会受很多因素影响：

• 屏幕宽度。
• 字体大小。
• 图片加载。
• 按钮状态。
• 弹窗层级。
• 长文本换行。
• 移动端浏览器差异。

所以一个更稳的流程是：

1. 让 Codex 修改代码。
2. 启动本地预览。
3. 让浏览器 Skill 打开页面。
4. 截图或读取页面状态。
5. 根据真实效果再调整。

你可以这样要求：

改完页面后，请用浏览器验证桌面端和手机端显示效果。不要只看代码判断完成。

这句话非常值钱。

它能把 Codex 从"写完就算"拉到"看过真实效果再说"。

21.5 浏览器 Skill 适合抓取网页吗

可以，但要注意边界。

适合抓取：

• 你自己的网站。
• 公开文档页面。
• 少量网页信息整理。
• 用于学习和核对的内容。

不适合：

• 大规模爬取。
• 绕过登录限制。
• 抓取明显不允许转载的内容。
• 采集敏感个人信息。

浏览器 Skill 很方便，但方便不等于什么都该做。

新手记住一句：

能打开，不代表能随便抓；能抓到，不代表能随便用。

如果你要整理公开网页内容，最好让 Codex 输出摘要、要点和链接，不要整篇搬运。

21.6 一个小白友好的提示词

你可以直接这样说：

请用浏览器检查这个本地页面：

目标：
1. 页面能正常打开。
2. 桌面宽度下布局不乱。
3. 手机宽度下没有横向滚动。
4. 按钮可以点击，点击后有预期反馈。

请先截图或描述当前页面状态，再提出需要修改的问题。

这个提示词的好处是：它不是让 Codex 空泛地"看看页面"，而是给了检查标准。

浏览器自动化最怕目标不清楚。

你越明确它要看什么，它越容易给出有用结论。

21.7 本章小结

• 浏览器 Skill 让 Codex 能看见真实网页、点击页面、截图验证。
• 联网搜索偏查资料，浏览器 Skill 偏操作和检查页面。
• 做网页时，不要只看代码，要让 Codex 用浏览器验证真实效果。
• 抓取网页要注意版权、隐私和网站规则。
• 浏览器 Skill 最适合和"完成前验证"一起用。

下一章我们进入办公场景：飞书 CLI。它能让 Codex 从本地文件走向日历、文档、表格、消息这些真实工作流。

第22章 飞书 CLI：打通办公流

22.0 本章你会学到什么

学完这一章，你会知道：

• 飞书 CLI 是什么。
• 它能让 Codex 连接哪些办公场景。
• user 身份和 bot 身份有什么区别。
• 新手使用飞书 CLI 时最容易卡在哪里。

这一章不教你逐个命令细节，先帮你建立办公自动化的整体认知。

22.1 飞书 CLI 是什么

CLI 是命令行工具。

飞书 CLI 可以理解成：

一套让 Codex 通过命令操作飞书资源的工具。

如果配置好了，它可以帮助 Codex 参与很多办公场景，比如：

• 查询日历。
• 创建日程。
• 读取或创建文档。
• 操作表格。
• 搜索联系人。
• 发送消息。
• 管理任务。
• 整理会议纪要。

以前这些事情通常要你自己打开飞书、点来点去。

有了 CLI 和相关 Skill 后，Codex 就可以在你授权的范围内帮你操作一部分流程。

这就是"打通办公流"的意思。

22.2 飞书 CLI 和普通飞书网页有什么区别

飞书网页适合人手动操作。

飞书 CLI 适合自动化。

对比一下：

比如，你要每周整理一次会议纪要。

手动流程可能是：

1. 打开日历。
2. 找会议。
3. 打开妙记或会议记录。
4. 复制内容。
5. 整理成文档。
6. 发给群里。

自动化流程可以变成：

请查询我本周的会议，筛选出有纪要的会议，整理成周报草稿。

当然，前提是相关权限、登录和工具都配置好了。

22.3 user 身份和 bot 身份

飞书 CLI 里，一个特别重要的概念是身份。

常见有两类：

• user 身份：代表用户自己操作。
• bot 身份：代表应用或机器人操作。

这两者差别很大。

举个例子：

如果你想查"我的日历"，通常需要 user 身份。

如果你想让机器人往群里发一条通知，可能用 bot 身份。

新手最容易犯的错是：用 bot 去查自己的日历，然后发现什么都没有。

不是工具坏了，而是身份不对。

22.4 权限是最大卡点

飞书 CLI 最常见的问题不是命令不会写，而是权限不足。

比如你想读取日历，可能需要日历相关权限。

你想读文档，可能需要云文档相关权限。

你想发消息，可能需要消息相关权限。

所以遇到报错时，不要急着让 Codex 乱改命令。先看：

• 当前是 user 还是 bot。
• 缺的是哪个 scope。
• 是否需要去开发者后台开权限。
• user 是否已经完成授权登录。

一个更稳的提示词：

飞书 CLI 报权限错误。请先判断当前身份是 user 还是 bot，再根据错误里的 scope 和 hint 给我说明需要怎么授权，不要直接重试危险操作。

这能避免很多无效尝试。

22.5 飞书 CLI 适合哪些业务场景

对小白来说，先从低风险、高收益的场景开始：

1. 日程摘要

帮我整理今天的日程，按上午、下午、晚上分组，并标出需要准备材料的会议。

2. 会议纪要整理

帮我把昨天的会议纪要整理成：结论、待办、负责人、截止时间。

3. 表格读取和汇总

帮我读取这个飞书表格，统计本周新增客户数量和跟进状态。

4. 文档生成

根据这段内容创建一份飞书文档，标题是“项目周报”，结构包含进展、风险、下周计划。

5. 消息草稿

帮我起草一条发到项目群的更新消息，先给我看草稿，不要直接发送。

注意最后一句：先给我看草稿，不要直接发送。

涉及发消息、改数据、删内容，一定先预览。

22.6 安全使用飞书 CLI 的三条原则

原则一：读操作优先

刚开始先做查询、整理、总结，不要一上来就让 Codex 批量修改数据。

原则二：写操作先草稿

创建文档、发送消息、更新表格之前，先让 Codex 输出计划或草稿。

例如：

请先生成消息草稿，不要发送。

原则三：权限最小化

只给当前任务需要的权限，不要为了省事一次性开一堆权限。

权限越大，自动化越要谨慎。

22.7 本章小结

• 飞书 CLI 是让 Codex 通过命令连接飞书办公资源的工具。
• 它适合日程、文档、表格、消息、任务等办公自动化场景。
• user 身份和 bot 身份差别很大，查个人资源通常需要 user。
• 权限不足时，先看身份、scope、授权方式，不要盲目重试。
• 写入、发送、删除类操作一定先预览，再确认。

下一章我们讲视觉创作 Skill：怎样让 Codex 不只会写文字，还能帮你生成封面、插图、素材和页面视觉参考。

第23章 视觉创作 Skill：多模态配图与设计素材

23.0 本章你会学到什么

学完这一章，你会知道：

• 视觉创作 Skill 能解决什么问题。
• 它和普通"生成一张图"有什么区别。
• 如何给 Codex 说清楚你想要的图片。
• 教程、网页、自媒体和产品原型中，哪些图最值得生成。

这一章的关键词是：让内容有画面。

23.1 为什么教程也需要视觉素材

很多小白教程最大的问题不是内容不对，而是读者看累了。

一篇长教程如果全是文字，读者很容易丢失方向。

合适的视觉素材可以帮你做三件事：

• 让读者快速理解概念。
• 给章节之间提供节奏。
• 提升教程的完成度和传播感。

比如这篇 Codex 教程，就很适合配这些图：

• 每一部分开头的概念图。
• 每章核心概念的示意图。
• 操作步骤截图。
• 对比表格图。
• 社交平台封面图。

图片不是装饰，而是降低理解成本。

23.2 视觉创作 Skill 能做什么

视觉创作 Skill 通常可以帮你：

• 生成封面图。
• 生成章节插图。
• 生成产品概念图。
• 生成 UI 氛围图。
• 生成素材变体。
• 根据参考图改风格。
• 给网页或 PPT 提供视觉方向。

它和普通一句"帮我画张图"的区别在于：

普通生成图更像临时发挥。

视觉创作 Skill 更强调流程：

1. 先明确用途。
2. 再明确尺寸和平台。
3. 再确定风格。
4. 再生成图片。
5. 最后检查文字、主体、构图是否可用。

这样更适合真实项目。

23.3 生成图片前先说清楚五件事

想让 Codex 生成更可用的图，先说清楚五件事：

1. 用途：封面、插图、海报、头像、产品图、背景图？
2. 尺寸：横版、竖版、方图、手机壁纸、PPT 16:9？
3. 主体：画面中心是什么？
4. 风格：写实、插画、扁平、科技感、手绘、极简？
5. 限制：不要文字、不要人物、不要太暗、不要复杂背景？

比如不要只说：

帮我生成一张 Codex 教程配图。

更好的说法：

帮我生成一张 16:9 横版教程章节插图。
主题是“AI 助手连接工具箱”。
画面主体是一个简洁的电脑工作台，周围有文档、浏览器、表格、图片生成等工具图标。
风格要明亮、现代、适合小白教程，不要真实人物，不要画面内文字。

这就清楚多了。

23.4 教程最适合生成哪些图

如果你在写教程，优先生成这几类：

1. 章节封面

用于每一部分开头，让读者知道进入新主题。

2. 概念示意图

比如 MCP、Skill、AGENTS.md 这类抽象概念，用图能更快说明关系。

3. 流程图背景

不是复杂流程图本身，而是辅助解释步骤的视觉素材。

4. 社交平台封面

如果教程要发公众号、小红书、知识星球，封面图很重要。

5. 课程 PPT 配图

把教程改成直播课或录播课时，图片能直接进入幻灯片。

不建议大量生成纯装饰图。图太多会分散注意力。

一章一张核心图，比满屏无关配图更有效。

23.5 文字图片要特别小心

生成式图片最容易翻车的地方之一，是图里的文字。

很多图片模型可以生成视觉效果，但对中文小字、复杂标题、品牌字样并不总是稳定。

所以新手建议：

• 图片里尽量不要放正文。
• 标题文字后期用 PPT、Canva、Figma 或网页排版加上去。
• 需要准确文字时，先生成无字背景，再用设计工具叠字。

提示词里可以写：

画面内不要出现任何文字、字母、数字、水印或 Logo。

这样生成出来的图更适合作为封面背景或插图。

23.6 视觉素材的版本管理

图片生成很容易一口气生成很多版本。

如果不管理，文件夹很快会乱。

建议命名方式：

images/
├── part4-mcp-skill-cover-v1.png
├── part4-mcp-skill-cover-v2.png
├── ch21-browser-skill-illustration-v1.png
└── ch23-visual-assets-cover-final.png

命名最好包含：

• 章节或用途。
• 主题。
• 版本号。
• final 标记。

不要用：

image.png
image-1.png
新建图片.png

因为过几天你自己也不知道哪个是哪个。

23.7 本章小结

• 视觉创作 Skill 可以帮教程、网页、PPT、自媒体内容生成可用素材。
• 生成前先说清用途、尺寸、主体、风格和限制。
• 教程最适合生成章节封面、概念示意图、社交封面和 PPT 配图。
• 准确文字尽量后期叠加，不要依赖图片模型直接生成。
• 图片素材要做好命名和版本管理。

下一章我们讲 TTS：让文字不只停留在页面上，还能变成可听的声音。

第24章 TTS 语音 Skill：赋予内容声音

24.0 本章你会学到什么

学完这一章，你会知道：

• TTS 是什么。
• TTS Skill 能在哪些场景发挥作用。
• 文本变语音前，为什么要先改稿。
• 如何让 Codex 帮你准备适合朗读的脚本。

这一章的关键词是：把文字变成声音产品。

24.1 一句话解释 TTS

TTS 的全称是 Text To Speech，也就是文本转语音。

简单说：

你给一段文字，系统把它读成声音。

它可以用于：

• 课程旁白。
• 短视频配音。
• 播客草稿。
• 听书内容。
• 产品引导语。
• 客服语音。
• 盲人或低视力用户辅助阅读。

对内容创作者来说，TTS 的价值很直接：

一篇文章可以变成音频。

一个教程可以变成课程旁白。

一个产品说明可以变成演示视频配音。

24.2 TTS Skill 解决什么问题

很多人以为 TTS 就是把原文丢进去读。

这通常效果不好。

适合阅读的文字，不一定适合朗读。

比如文章里经常有：

• 长句。
• 括号。
• 表格。
• 代码。
• 链接。
• 项目符号。
• 中英混排。

这些直接读出来会很别扭。

TTS Skill 的价值，是在生成语音前先做"朗读稿处理"：

• 把长句拆短。
• 把表格改成口播表达。
• 把代码块改成说明。
• 给停顿和语气做提示。
• 删除不适合朗读的符号。
• 按段落分批生成。

所以，好的 TTS 流程不是：

文章 → 语音

而是：

文章 → 朗读稿 → 分段脚本 → 语音 → 检查与返修

24.3 什么内容适合做成语音

适合：

• 教程讲解。
• 每日简报。
• 课程开场白。
• 视频旁白。
• 产品功能介绍。
• 睡前知识音频。
• 公司内部播报。

不太适合直接做：

• 大段代码。
• 复杂表格。
• 需要频繁看图的教程。
• 数学公式密集内容。
• 很多链接和文件路径的说明。

如果必须朗读这类内容，需要先改写。

比如代码不要逐字符念，可以改成：

这里的代码作用是读取 CSV 文件，并把结果转换成图表数据。

读者听得懂，比逐字精确更重要。

24.4 让 Codex 准备朗读稿

你可以这样让 Codex 处理文章：

请把下面这章教程改成适合 TTS 朗读的脚本。
要求：
1. 保留核心意思。
2. 长句拆短。
3. 表格改成口语化解释。
4. 代码块只说明作用，不逐字朗读。
5. 每段控制在 80 到 150 字。
6. 输出时按“第几段”编号。

如果是短视频配音，可以更具体：

请把这段内容改成 60 秒短视频口播稿。
要求：
1. 开头 5 秒有钩子。
2. 语言口语化。
3. 每句话不超过 25 个字。
4. 结尾引导观众收藏。

TTS 前的文本处理，往往比选哪个声音更重要。

24.5 分段很重要

长文不要一次性生成语音。

建议先分段：

chapter24-audio/
├── 01-opening.txt
├── 02-what-is-tts.txt
├── 03-script-cleanup.txt
├── 04-use-cases.txt
└── 05-summary.txt

分段的好处：

• 某一段错了，只重生成这一段。
• 方便后期剪辑。
• 方便给不同段落设置不同语气。
• 不容易超出工具限制。

如果你要做课程音频，一章可以拆成 5 到 10 段。

如果你要做短视频，一条视频最好只保留一个核心观点。

24.6 声音风格怎么描述

如果 TTS 工具支持风格控制，你可以描述：

• 语速：慢一点、正常、稍快。
• 情绪：温和、兴奋、沉稳、专业。
• 场景：课程讲解、新闻播报、产品演示、故事旁白。
• 人群：适合小白、适合儿童、适合商务听众。

比如：

声音风格：温和、清晰、像老师讲课，不要播音腔，语速略慢，适合零基础用户。

但不要过度依赖风格词。

真正决定听感的，还是文本本身：

• 句子短不短。
• 信息密度高不高。
• 有没有自然停顿。
• 有没有一口气塞太多术语。

先改稿，再调声音。

24.7 TTS 的版权和合规意识

TTS 很方便，但也要注意边界。

新手记住三点：

• 不要克隆或模仿未授权的真人声音。
• 商用前确认工具授权和素材版权。
• 如果声音用于公开发布，避免让听众误以为是真人本人亲自录制。

特别是名人、同事、客户、主播的声音，不要随便模仿。

内容创作里，效率很重要，但信任更重要。

24.8 本章小结

• TTS 是文本转语音，不只是"把文章读出来"。
• 好的 TTS 流程是：文章、朗读稿、分段脚本、语音、检查返修。
• 适合阅读的文字，不一定适合朗读，表格、代码、链接都要先改写。
• 长文要分段，方便重生成和后期剪辑。
• 声音风格可以描述，但文本质量更决定最终听感。
• 不要未经授权模仿真人声音，商用前要确认版权和规则。

到这里，第四部分已经从"元能力"走到了三个具体场景：浏览器、办公流、视觉素材和语音内容。

下一轮我们会继续补第 25-27 章，把 Office 自动化、文本处理和小白开发者的全栈 Skill 宝藏收完。

第25章 Office 自动化 Skill：从对话到专业交付物

25.0 本章你会学到什么

学完这一章，你会知道：

• Office 自动化 Skill 能帮你做哪些交付物。
• Word、Excel、PPT 三类任务有什么不同。
• 为什么"能生成文件"不等于"文件能交付"。
• 新手应该怎样描述 Office 类需求，才能得到更稳定的结果。

这一章的关键词是：从内容生成，走向正式交付。

25.1 为什么 Office 自动化很重要

很多人的工作成果，最后不是代码，也不是聊天记录，而是这些文件：

• Word 文档
• Excel 表格
• PowerPoint 演示稿
• PDF 报告
• Google Docs
• Google Sheets
• Google Slides

你和 Codex 对话半天，如果最后只能得到一段文字，还不算真正省事。

真正省事的是：

你说清楚目标，Codex 帮你生成一份能打开、能编辑、能交付的文件。

比如：

• 把会议纪要整理成 Word。
• 把销售数据做成 Excel 看板。
• 把项目汇报做成 PPT。
• 把长文档改成可打印的 PDF。
• 把调研内容整理成 Google Docs 草稿。

这就是 Office 自动化 Skill 的价值。

25.2 Word 类任务：重点是结构和版式

Word 文档看起来简单，实际最容易翻车。

常见问题包括：

• 标题层级乱。
• 段落太密。
• 表格挤到页面外。
• 列表缩进不统一。
• 页眉页脚乱。
• 导出 PDF 后分页很难看。

所以 Word 类任务，不能只说：

帮我生成一份 Word。

更好的说法：

请把这份会议内容整理成一份正式 Word 纪要。
要求：
1. 包含会议背景、讨论要点、结论、待办事项。
2. 待办事项用表格，字段包括事项、负责人、截止时间、状态。
3. 语言简洁正式。
4. 生成后检查排版，确保表格不溢出页面。

Word 自动化的核心不是"写字"，而是把信息组织成适合阅读、打印和归档的形态。

25.3 Excel 类任务：重点是数据和公式

Excel 和 Word 不一样。

Excel 的核心是：

• 数据是否正确。
• 公式是否可复用。
• 表格是否容易筛选。
• 图表是否表达重点。
• 输入区和计算区是否分清楚。

如果只是让 Codex 生成一个漂亮表格，但公式错了，那就不能用。

描述 Excel 需求时，要说清：

• 数据来源是什么。
• 需要哪些字段。
• 哪些列是输入。
• 哪些列要计算。
• 需要哪些图表。
• 判断完成的标准是什么。

示例：

请根据这份 CSV 生成一个 Excel 销售分析表。
要求：
1. 保留原始数据页。
2. 新建汇总页，按月份统计销售额、订单数、客单价。
3. 关键指标用公式计算，不要手填。
4. 增加一张月度销售趋势图。
5. 检查公式没有错误。

Excel 自动化一定要强调"公式"和"验证"。

因为好看的表格不一定可信，可信的表格才有价值。

25.4 PPT 类任务：重点是故事线

PPT 不是把文字分到几页。

好的 PPT 要有故事线：

• 先讲问题。
• 再给证据。
• 再给结论。
• 最后给行动建议。

很多人让 Codex 做 PPT 时，只说：

帮我做一个项目汇报 PPT。

这样很容易生成一堆标题页和 bullet points。

更好的方式是给它汇报目标：

请根据下面材料做一个 8 页项目汇报 PPT。
听众是公司管理层。
目标是说明项目进展、当前风险和需要决策的事项。
每页只表达一个核心观点。
不要堆文字，尽量用表格、时间线和图表表达。

PPT 自动化的核心不是"排版"，而是帮你压缩信息、组织叙事。

如果你自己还没想清楚要说服谁、说服什么，PPT 很难做好。

25.5 Office 自动化的通用流程

不管是 Word、Excel 还是 PPT，一个稳的流程通常是：

1. 先明确用途：内部记录、正式汇报、客户交付、打印归档？
2. 再整理内容：先把材料清洗、归类、去重。
3. 确定结构：章节、表格、页数、图表、附录。
4. 生成文件：让 Codex 创建可编辑文件。
5. 渲染或打开检查：确认排版、公式、图表、分页。
6. 迭代修正：针对具体问题改，不要笼统说"再好看点"。
7. 最终交付：保留可编辑源文件，必要时再导出 PDF。

你可以把这句话加入提示词：

请不要只生成内容，还要检查最终文件是否适合交付。

这会提醒 Codex 不要停在草稿阶段。

25.6 新手最容易踩的坑

坑一：只说文件类型，不说使用场景

"做个 PPT"太模糊。

要说是路演、复盘、培训、周报，还是客户提案。

坑二：把所有内容都塞进正文

Word 可以有附录，Excel 可以有原始数据页，PPT 可以有备份页。

不是所有信息都要放到最显眼的位置。

坑三：不要求验证

Office 文件最怕"看起来生成了，但打开后乱了"。

所以一定要让 Codex 检查：

• Word：分页、表格、标题、列表。
• Excel：公式、图表、筛选、列宽。
• PPT：文字是否溢出、图表是否清晰、页面是否统一。

坑四：忽视可编辑性

正式工作里，可编辑文件比截图更重要。

除非你明确只要图片，否则尽量让 Codex 生成 Word、Excel、PPT 这类可编辑源文件。

25.7 一个万能 Office 提示词模板

你可以这样说：

请把下面材料整理成一份可交付的 Office 文件。

文件类型：
用途：
目标读者：
希望结构：
必须包含：
不要包含：
风格要求：
验证要求：

请先给出文件结构草案，我确认后再生成正式文件。

这个模板适合 Word、Excel、PPT。

如果你不确定结构，就把"希望结构"留空，让 Codex 先提建议。

关键是最后一句：

我确认后再生成正式文件。

重要交付物不要一口气生成，先看结构，再做文件。

25.8 本章小结

• Office 自动化 Skill 的目标是生成能打开、能编辑、能交付的文件。
• Word 重结构和版式，Excel 重数据和公式，PPT 重故事线。
• 好的 Office 自动化流程包括整理内容、确定结构、生成文件、检查验证、迭代修正。
• 新手不要只说文件类型，要说清用途、读者、结构和验证要求。
• 正式交付前，一定要检查排版、公式、图表和可编辑性。

下一章我们讲文本与内容处理 Skill：它不一定生成复杂文件，但能把各种杂乱内容变成可用材料。

第26章 文本与内容处理 Skill：全能转换与脱水专家

26.0 本章你会学到什么

学完这一章，你会知道：

• 文本与内容处理 Skill 能做哪些事。
• 什么叫"脱水"。
• 文本转换、摘要、改写、结构化之间有什么区别。
• 新手怎样让 Codex 处理长材料而不丢重点。

这一章的关键词是：把杂乱内容变成可用内容。

26.1 为什么文本处理是高频能力

你每天遇到的很多工作，本质上都是文本处理：

• 把聊天记录整理成待办。
• 把会议录音转写稿整理成纪要。
• 把长文章压缩成摘要。
• 把口语内容改成正式文档。
• 把资料拆成知识卡片。
• 把用户反馈归类成问题清单。
• 把多篇材料整理成报告大纲。

这些事看起来不"高级"，但非常耗时间。

文本处理 Skill 的价值，就是把这些重复劳动流程化。

它能让 Codex 不只是"帮我润色一下"，而是按明确标准完成整理、压缩、转换和重写。

26.2 什么叫脱水

"脱水"是内容行业里常用的说法。

简单理解就是：

去掉水分，留下有用信息。

比如一段会议讨论可能有很多重复、寒暄、跑题、语气词。

脱水后要留下：

• 事实。
• 观点。
• 决策。
• 待办。
• 风险。
• 分歧。
• 证据。

脱水不是简单变短。

变短只是压缩长度。

脱水是提高信息密度。

原文 5000 字，脱水后可能是 800 字，也可能是 1500 字。关键不是字数，而是是否去掉了无效内容。

26.3 文本处理的几种常见动作

新手经常把"总结""改写""整理""提炼"混在一起。

其实它们不一样。

你给 Codex 提需求时，最好直接说动作。

不要只说：

帮我处理一下这段内容。

要说：

请把这段会议记录脱水，输出结论、待办、风险和待确认问题。

动作越明确，结果越稳定。

26.4 长文本处理的正确姿势

长文本最怕两件事：

• Codex 漏掉重点。
• Codex 把细节编错。

处理长文本时，建议分三步。

第一步：先识别结构

请先阅读这份材料，只输出它的结构大纲和主要主题，不要总结细节。

第二步：再分块处理

请按章节逐段脱水，每段输出事实、观点、待办和风险。

第三步：最后合并

请基于上面的分块结果，合并成一份最终摘要，删除重复项，保留关键证据。

不要一上来就说：

把这 5 万字总结一下。

这很容易让重要细节被压扁。

26.5 内容改写要先定目标读者

改写不是随便换一种说法。

改写前先问：

• 写给谁看？
• 读者知道多少背景？
• 读完要做什么？
• 文风要正式、口语、销售、教学，还是社媒？

同一段内容，给老板看、给用户看、给小白看、给程序员看，写法完全不同。

比如：

请把下面内容改写成给零基础用户看的教程。
要求：
1. 少用术语。
2. 每个概念用生活类比解释。
3. 每段不要太长。
4. 保留关键步骤。

如果是发朋友圈或小红书：

请把下面内容改写成小红书笔记风格。
要求：
1. 开头有痛点。
2. 分点清楚。
3. 语气自然，不要硬广。
4. 结尾给一个行动建议。

所以，改写的核心不是"更好"，而是"更适合谁"。

26.6 结构化输出很重要

文本处理的结果最好不要只是一大段话。

更好的输出包括：

• 表格。
• 清单。
• JSON。
• Markdown 标题。
• 待办列表。
• 问题分类。
• 时间线。

比如处理用户反馈：

请把这些用户反馈整理成表格：
字段包括：反馈原文、问题类型、严重程度、是否需要回复、建议处理动作。

处理会议纪要：

请输出四部分：
1. 会议结论
2. 待办事项
3. 风险和阻塞
4. 待确认问题

结构化输出的好处是：你可以直接复制到文档、表格或任务系统里。

26.7 文本处理的质量检查

处理完以后，不要只看语言顺不顺。

至少检查四点：

• 有没有漏重点：原文里的核心事实是否都保留。
• 有没有乱加内容：输出里是否出现原文没有的信息。
• 分类是否合理：同类问题有没有被分散。
• 格式是否可用：能不能直接复制到下一步工具。

你可以让 Codex 自查：

请对照原文检查这份整理结果：
1. 是否遗漏重要结论。
2. 是否加入原文没有的信息。
3. 待办事项是否都有负责人或待确认标记。
4. 输出格式是否适合复制到表格。

这一步很适合和元能力 Skill 里的"完成前验证"配合。

26.8 本章小结

• 文本处理 Skill 适合摘要、改写、结构化、分类、提取、转换和脱水。
• 脱水不是简单变短，而是去掉无效内容，提高信息密度。
• 长文本要先识别结构，再分块处理，最后合并。
• 改写前必须明确目标读者和使用场景。
• 结构化输出能让结果直接进入文档、表格、任务系统或知识库。
• 处理完要检查有没有遗漏、编造、分类错误和格式不可用。

下一章我们把第四部分收束成一个工具地图：小白开发者到底应该优先掌握哪些 Skill。

第27章 小白开发者的全栈 Skill 宝藏

27.0 本章你会学到什么

学完这一章，你会知道：

• 小白开发者为什么也需要 Skill 工具箱。
• 哪些 Skill 最值得优先掌握。
• 怎么把这些 Skill 组合成真实工作流。
• 如何避免一上来装太多、学太散。

这一章不是列一个很长的清单，而是帮你建立自己的 Skill 学习路线。

27.1 什么叫小白开发者

这里说的小白开发者，不是指已经能熟练写工程代码的人。

而是这类人：

• 不一定会系统编程。
• 但愿意用 AI 做网站、小工具、数据分析、自动化。
• 会一点文件和目录概念。
• 能看懂基础报错。
• 愿意边做边学。

过去，这类人很难独立做完整项目。

现在，有了 Codex 和 Skill，门槛降低了很多。

你不需要一口气学完前端、后端、数据库、部署、设计、数据分析。你可以先学会把任务拆开，再让 Codex 和对应 Skill 帮你逐步完成。

27.2 最值得优先掌握的 Skill 类型

小白开发者优先掌握这七类就够了。

注意，这里面只有一部分是"开发"。

真实项目不是只写代码。

它还包括需求、文档、数据、视觉、测试、交付。

这些都可以由 Skill 帮你增强。

27.3 一个完整项目需要哪些 Skill

假设你要做一个"个人记账网页工具"。

可以这样组合：

阶段一：想清楚做什么

• 需求澄清 Skill：明确用户、功能、边界。
• 写计划 Skill：拆成页面、数据、交互、验证步骤。

阶段二：做出第一个版本

• 前端开发相关 Skill：生成页面结构和样式。
• 浏览器 Skill：打开页面检查真实效果。
• 系统调试 Skill：遇到报错时定位原因。

阶段三：补内容和素材

• 文本处理 Skill：写说明文案和帮助内容。
• 视觉创作 Skill：生成封面或空状态插图。

阶段四：处理数据

• 表格分析 Skill：准备示例 CSV，分析收支统计。
• Office 自动化 Skill：导出报告或表格模板。

阶段五：收尾交付

• 完成前验证 Skill：检查功能、文档、页面和文件。
• 文档处理 Skill：生成 README 和使用说明。

你会发现，一个项目不是靠一个 Skill 完成，而是多个 Skill 接力。

27.4 不要一上来装满工具箱

很多新手看到 Skill 会兴奋：

这个也装，那个也装。

最后结果是：

• 不知道哪个 Skill 该用。
• Skill 描述互相重叠。
• Codex 选择时容易混乱。
• 自己也记不住每个 Skill 的用途。

更好的方式是按阶段增加。

第一阶段：基础协作

• 需求澄清
• 写计划
• 完成前验证

第二阶段：内容和数据

• 文本处理
• 表格分析
• 文档生成

第三阶段：网页和视觉

• 浏览器验证
• 视觉创作
• 前端检查

第四阶段：办公和自动化

• 飞书 CLI
• Office 自动化
• 邮件、日历、任务类 Skill

每次只新增一两类，用熟再加。

Skill 不是越多越好，能稳定触发、稳定产出才好。

27.5 组合 Skill 的提示词

当你知道自己要用多个 Skill 时，不要只说：

帮我做完这个项目。

可以这样说：

请按阶段推进这个项目：

阶段 1：先澄清需求，不要写代码。
阶段 2：生成 PLAN.md，把任务拆成步骤。
阶段 3：按步骤实现第一版。
阶段 4：用浏览器验证页面效果。
阶段 5：完成前检查文档、页面和运行结果。

每个阶段结束后先汇报，再继续下一阶段。

这段话的重点是"阶段结束后先汇报"。

它能避免 Codex 一口气跑太远。

对小白来说，最安全的自动化不是完全放手，而是：

让 Codex 自动推进，但每个关键节点都能看见。

27.6 小白开发者的 Skill 学习路线

可以按这条路线走：

第 1 周：会用基础

• 学会 @文件名 引用文件。
• 学会让 Codex 读 AGENTS.md。
• 学会让 Codex 写 PLAN.md。
• 学会完成前让它自查。

第 2 周：会做内容

• 用文本处理 Skill 整理文章。
• 用文档 Skill 生成 Word 或 Markdown。
• 用视觉 Skill 生成简单封面。

第 3 周：会做网页

• 让 Codex 生成一个本地 HTML 页面。
• 用浏览器 Skill 检查页面。
• 根据截图反馈迭代。

第 4 周：会做数据和交付

• 用表格 Skill 分析 CSV。
• 生成 Excel 报告。
• 把结论整理成 PPT 或文档。

一个月不用追求精通。

只要你能把一个小任务从想法推进到可交付结果，就已经跨过了最重要的一步。

27.7 如何判断一个 Skill 值不值得长期保留

一个 Skill 是否值得留在你的工具箱里，看四点：

• 是否经常用：一个月用不到一次，可以先不装。
• 是否足够稳定：每次输出都差很多，就需要改说明。
• 是否边界清楚：它到底负责什么，能不能一句话说清。
• 是否真的省时间：如果用它比手动还慢，就别硬用。

你可以定期整理 Skill：

请帮我回顾当前项目用到的 Skill，判断哪些应该保留、哪些可以合并、哪些描述需要改清楚。

工具箱也需要打扫。

否则最后会变成一堆你自己都不敢碰的配置。

27.8 本章小结

• 小白开发者不需要先学完所有编程知识，也可以用 Codex 和 Skill 推进真实项目。
• 优先掌握需求澄清、写计划、浏览器验证、文本处理、表格分析、视觉创作、完成前验证。
• 一个项目通常需要多个 Skill 接力，而不是靠一个万能 Skill。
• Skill 不要装太多，要按阶段增加，用熟再加。
• 真正的全栈能力，不是你亲手写每一行代码，而是你能把需求、内容、数据、页面、验证和交付串起来。

到这里，第四部分结束。

你已经理解了 Codex 的元能力地图：MCP 负责连接工具，Skill 负责沉淀流程，浏览器、飞书、视觉、语音、Office、文本处理这些能力则把 Codex 带进真实工作场景。

下一部分开始，我们会进入业务场景 Skill 实战：不再单独讲工具，而是围绕会议纪要、知识库整理、数据分析、自媒体运营、客户跟进等真实任务，看看怎么把这些能力组合起来。

第五部分：业务场景 Skill 实战

前面我们已经讲了 MCP、Skill、浏览器、飞书、视觉、语音、Office、文本处理这些能力。

但工具学完以后，真正的问题是：

我在真实工作里，到底怎么把它们组合起来？

第五部分解决的就是这个问题。

我们不再单独讲某一个工具，而是围绕具体业务场景展开：

• 会议纪要怎么整理。
• 教程和知识库怎么沉淀。
• 数据分析报告怎么生成。
• 自媒体运营怎么辅助。
• 客户跟进怎么提效。
• 飞书办公协同怎么串起来。
• 行业研究报告怎么做。

这些场景的共同点是：它们都不是单步任务，而是一串流程。

业务场景 Skill 的意义，就是把这串流程变成可重复执行的工作方法。

第28章 业务场景 Skill 的设计思路

28.0 本章你会学到什么

学完这一章，你会知道：

• 什么是业务场景 Skill。
• 它和工具型 Skill、元能力 Skill 有什么区别。
• 设计业务 Skill 时要先问哪些问题。
• 一个业务 Skill 应该包含哪些固定模块。

这一章是第五部分的总开关。先学会怎么设计，再看后面的实战案例会清楚很多。

28.1 什么是业务场景 Skill

业务场景 Skill 不是单纯调用某个工具。

它解决的是一个完整工作场景。

比如：

• "整理会议纪要"不是只转文字。
• "生成数据分析报告"不是只画图。
• "自媒体运营"不是只写标题。
• "客户跟进"不是只发消息。

它们都包含一连串动作：

1. 收集材料。
2. 识别重点。
3. 按业务规则整理。
4. 生成结果。
5. 检查质量。
6. 必要时同步到文档、表格或消息系统。

业务场景 Skill 就是把这些步骤固化下来。

你可以把它理解成：

针对某类真实工作设计的一套 AI SOP。

28.2 三类 Skill 的区别

前面讲过很多 Skill，这里做个总表。

三者经常组合。

比如"会议纪要 Skill"可能会用到：

• 飞书会议或妙记工具。
• 文本脱水能力。
• 文档生成能力。
• 完成前验证流程。

所以业务 Skill 往往站在更上层。

它不关心某个命令有多酷，而关心最终业务结果是否可用。

28.3 设计业务 Skill 前先问五个问题

设计一个业务 Skill 前，先回答五个问题。

1. 输入是什么？

材料来自哪里？

• 聊天记录
• 会议录音
• 飞书妙记
• CSV
• 文档
• 网页
• 用户手动粘贴内容

2. 输出是什么？

最终要交付什么？

• Markdown
• Word 文档
• Excel 报告
• 飞书文档
• PPT
• 消息草稿
• 任务清单

3. 中间要经过哪些步骤？

比如先清洗，再分类，再总结，再生成。

4. 质量标准是什么？

什么叫做得好？

• 没漏结论
• 待办有负责人
• 数据公式正确
• 图表能说明问题
• 文风符合读者

5. 哪些事不能自动做？

比如：

• 不自动发送消息。
• 不自动删除数据。
• 不擅自改正式文档。
• 不编造缺失字段。

这五个问题回答清楚，一个业务 Skill 就有了骨架。

28.4 一个业务 Skill 模板

可以用下面这个结构设计：

---
name: business-skill-name
description: 当用户需要完成某个具体业务场景时使用。
---

# 业务场景名称

## 适用场景

- 什么任务适合使用这个 Skill
- 什么任务不适合使用这个 Skill

## 输入

- 需要哪些材料
- 材料可以来自哪些地方
- 缺少材料时怎么询问

## 工作流程

1. 收集材料
2. 清洗和分类
3. 提取关键信息
4. 生成结果
5. 检查质量

## 输出格式

- 输出结构
- 文件格式
- 命名规则

## 质量检查

- 检查项 1
- 检查项 2
- 检查项 3

## 安全边界

- 不做什么
- 需要用户确认的动作

这个模板适合大多数业务场景。

不要一开始就写很多高级逻辑。先把输入、流程、输出、质量检查和安全边界写清楚。

28.5 业务 Skill 最重要的是边界

业务 Skill 最大的风险是越做越宽。

比如你做一个"会议纪要 Skill"，一开始只是整理会议，后来你又想让它：

• 自动查日历。
• 自动拉参会人。
• 自动生成文档。
• 自动发群消息。
• 自动创建任务。
• 自动催办。

这些都能做，但不应该一开始全放进去。

更好的做法是分阶段：

第一版：只整理

输入会议内容，输出纪要。

第二版：加来源

支持从妙记、文档、聊天记录中获取材料。

第三版：加交付

生成飞书文档或 Word 文档。

第四版：加协同

在用户确认后发消息或创建任务。

业务 Skill 要像产品一样迭代，不要一上来做成大而全。

28.6 业务 Skill 的成功标准

一个好的业务 Skill，不是看起来高级，而是能稳定省时间。

可以用四个标准判断：

• 少问重复问题：每次不用重新解释流程。
• 输出稳定：结构和质量可预期。
• 可检查：结果有明确检查项。
• 能交付：不是一段聊天，而是能进入工作流的文档、表格、消息或任务。

如果一个 Skill 每次都输出风格不一样、字段不一样、边界不一样，那就还不成熟。

这时候不要怪 Codex，先回头改 Skill 的说明。

28.7 本章小结

• 业务场景 Skill 是针对真实工作设计的一套 AI SOP。
• 它通常会组合工具型 Skill 和元能力 Skill。
• 设计前先明确输入、输出、流程、质量标准和安全边界。
• 第一版要小而稳，不要一上来做大而全。
• 好的业务 Skill 要输出稳定、可检查、能交付。

下一章开始进入第一个实战：会议纪要 Skill。

第29章 实战：会议纪要 Skill

29.0 本章你会学到什么

学完这一章，你会知道：

• 会议纪要 Skill 应该解决什么问题。
• 一份好纪要应该包含哪些内容。
• 如何把会议内容整理成结论、待办、风险和后续问题。
• 飞书妙记、会议记录、聊天记录如何进入这个流程。

会议纪要是最适合做成 Skill 的场景之一，因为它高频、重复、格式稳定。

29.1 会议纪要不只是总结

很多人以为会议纪要就是：

把大家说了什么总结一下。

这不够。

真正有用的会议纪要应该回答四个问题：

1. 这次会议讨论了什么？
2. 最终决定了什么？
3. 接下来谁要做什么？
4. 还有哪些风险或待确认问题？

所以会议纪要 Skill 的目标不是"写得像文章"，而是让会后行动更清楚。

一个好的会议纪要，读者应该能在 3 分钟内知道：

• 结论是什么。
• 我是否有待办。
• 截止时间是什么。
• 哪些问题还没定。

29.2 输入来源有哪些

会议纪要 Skill 的输入可以来自很多地方：

• 会议录音转写稿。
• 飞书妙记。
• Zoom、腾讯会议等导出的文字。
• 会前议程。
• 会中聊天记录。
• 会后补充说明。
• 用户手动粘贴的会议内容。

如果接了飞书能力，常见路径是：

1. 先定位某个时间范围内的会议。
2. 找到会议对应的纪要或妙记。
3. 读取总结、逐字稿、待办或章节。
4. 整理成统一格式。

但新手不用一开始就自动化全部来源。

第一版会议纪要 Skill 可以先支持"用户粘贴文字"，等格式稳定后再接飞书或其他系统。

29.3 输出结构怎么设计

推荐结构：

# 会议纪要

## 一句话结论

## 会议背景

## 关键讨论

## 已确认结论

## 待办事项

| 事项 | 负责人 | 截止时间 | 状态 |
|---|---|---|---|

## 风险与阻塞

## 待确认问题

## 原始材料链接

这套结构的好处是：既能给管理者快速看结论，也能给执行者看待办。

如果是会议周报，可以再加：

• 本周会议数量。
• 高频主题。
• 跨会议重复问题。
• 需要管理层决策的事项。

29.4 会议纪要 Skill 的工作流程

一个可用的会议纪要 Skill 可以这样写流程：

1. 确认会议范围：单场会议、今天、本周，还是某个项目。
2. 收集材料：逐字稿、AI 总结、聊天记录、附件链接。
3. 提取结构：主题、结论、待办、风险、问题。
4. 消除重复：同一待办不要出现多次。
5. 补齐字段：待办缺负责人或截止时间时标记"待确认"。
6. 生成纪要：按固定格式输出。
7. 质量检查：确认没有把讨论误写成结论。
8. 交付方式：输出 Markdown、飞书文档、Word 或消息草稿。

关键是第 7 步。

会议里很多话只是讨论，不是决定。

Skill 要提醒 Codex 不要把"有人提议"写成"会议决定"。

29.5 一个会议纪要提示词

你可以这样用：

请把下面会议内容整理成会议纪要。

要求：
1. 先输出一句话结论。
2. 区分“讨论内容”和“已确认结论”。
3. 待办事项必须包含事项、负责人、截止时间、状态。
4. 如果负责人或截止时间不明确，写“待确认”。
5. 不要把未确认的建议写成最终决定。
6. 最后列出风险和待确认问题。

会议内容如下：
……

如果是飞书场景，可以加：

请整理我过去 7 天的会议纪要，生成一份会议周报。先列出会议清单和可用纪要，不要直接创建文档。

这能避免 Codex 直接进入写入操作。

29.6 质量检查清单

会议纪要完成后，至少检查：

• 有没有把讨论误写成决定。
• 待办是否有负责人。
• 截止时间是否明确。
• 风险是否单独列出。
• 待确认问题是否保留。
• 是否遗漏关键结论。
• 是否保留原始材料链接。

你可以让 Codex 自查：

请对照原始会议内容检查这份纪要：
1. 有没有编造结论。
2. 有没有遗漏明确待办。
3. 有没有把未确认建议写成决定。
4. 待办字段是否完整。

这一步非常重要。

会议纪要看起来像文案工作，其实本质是责任记录。

29.7 本章小结

• 会议纪要 Skill 的目标是让会后行动清楚，不只是总结发言。
• 好纪要要区分讨论、结论、待办、风险和待确认问题。
• 待办事项必须标出负责人和截止时间；缺失就写待确认。
• 第一版可以先支持粘贴文本，后续再接飞书妙记、会议记录和文档系统。
• 会议纪要必须做质量检查，避免把建议写成决定。

下一章我们看另一个高频场景：教程改写与知识库整理。

第30章 实战：教程改写与知识库整理 Skill

30.0 本章你会学到什么

学完这一章，你会知道：

• 教程改写和知识库整理有什么不同。
• 如何把零散内容变成可复用知识。
• 一个知识库整理 Skill 应该怎么设计。
• 如何避免把知识库变成资料垃圾堆。

这一章和你正在看的这篇教程关系很大。

30.1 教程改写和知识库整理的区别

教程改写的目标是让读者学会。

知识库整理的目标是让团队以后能查到、能复用。

对比一下：

比如一段聊天记录：

如果做成教程，你会写：

• 第一步做什么。
• 为什么这样做。
• 新手会踩什么坑。
• 跟着练一次。

如果做成知识库，你会写：

• 这个问题是什么。
• 适用范围是什么。
• 解决方案是什么。
• 相关链接有哪些。
• 谁维护、什么时候更新。

所以 Skill 要先判断目标：教学还是沉淀。

30.2 教程改写 Skill 的流程

教程改写适合这类输入：

• 直播逐字稿。
• 课程录音转文字。
• 社群问答。
• 操作步骤草稿。
• 技术文档。
• 用户手册。

流程可以这样设计：

1. 确认读者：小白、运营、产品、开发、管理者。
2. 确认目标：读完要理解、会操作、能复盘，还是能交付。
3. 提取核心步骤：把散乱内容变成顺序。
4. 补解释：术语要解释，动作要说明目的。
5. 加案例：让读者知道怎么用。
6. 加常见误区：提前帮读者避坑。
7. 统一文风：口语化、清楚、少术语。
8. 检查结构：标题层级、代码块、目录状态。

这篇教程前面的补充，其实就用了类似流程。

30.3 知识库整理 Skill 的流程

知识库整理更像信息归档。

流程可以这样：

1. 确认知识类型：FAQ、How-to、决策记录、概念解释、项目文档。
2. 提取核心信息：事实、步骤、结论、负责人、链接。
3. 选择模板：不同类型用不同结构。
4. 添加标签：方便以后搜索。
5. 链接相关内容：不要让页面孤立。
6. 标记状态：草稿、已确认、过期、待更新。
7. 写维护信息：作者、更新时间、适用范围。

知识库不是资料仓库。

资料仓库是"东西都放进来了"。

知识库是"以后能快速找到正确答案"。

差别很大。

30.4 一个教程改写提示词

请把下面这段内容改写成小白教程章节。

要求：
1. 保留核心观点，不要删掉重要步骤。
2. 用口语化表达，少用术语。
3. 每个术语第一次出现时解释一句。
4. 按“本章你会学到什么 / 正文 / 常见误区 / 本章小结”组织。
5. 如果内容里有可能过期的工具信息，标注“以官方文档为准”。

原始内容如下：
……

这段提示词适合把直播稿、课程稿、问答内容变成教程。

30.5 一个知识库整理提示词

请把下面内容整理成一篇知识库页面。

页面类型：How-to 指南
目标读者：刚加入项目的新成员

要求：
1. 标题清楚，能被搜索到。
2. 开头用 3 句话说明这个页面解决什么问题。
3. 列出适用范围和不适用范围。
4. 按步骤写操作方法。
5. 补充常见问题。
6. 最后列出相关链接和维护信息。

原始内容如下：
……

知识库页面最重要的是可查。

标题不要写得太文艺，要让人搜索得到。

比如不要写：

那些年我们踩过的配置坑

更好的是：

Codex 项目配置常见问题处理指南

30.6 知识库整理的质量检查

整理完以后，检查：

• 标题是否能被搜索到。
• 页面开头是否说明用途。
• 步骤是否可执行。
• 是否有适用范围。
• 是否有过期风险标记。
• 是否链接到相关页面。
• 是否留下维护信息。

你可以让 Codex 自查：

请检查这篇知识库页面：
1. 新人能不能根据它完成操作。
2. 标题和小标题是否方便搜索。
3. 有没有缺少前提条件。
4. 有没有可能过期的信息。
5. 是否需要补充相关链接。

知识库的价值不是写完，而是以后真的有人能用。

30.7 本章小结

• 教程改写重在教学，知识库整理重在检索和复用。
• 教程要有顺序、解释、案例和误区。
• 知识库要有类型、标签、链接、状态和维护信息。
• 标题要方便搜索，不要只追求好看。
• 整理完成后要检查新人是否能照着做。

下一章我们进入数据场景：如何把 CSV、Excel 或表格数据变成分析报告。

第31章 实战：数据分析与图表报告 Skill

31.0 本章你会学到什么

学完这一章，你会知道：

• 数据分析 Skill 应该如何设计。
• 为什么先理解数据比直接画图更重要。
• 一份图表报告应该包含哪些部分。
• 如何检查数据分析结果是否可信。

数据分析是 Codex 非常适合小白入门的场景，因为它能把文件处理、逻辑分析、图表生成和报告写作串起来。

31.1 数据分析不是先画图

很多人拿到 CSV 后第一句话是：

帮我生成图表。

这太急了。

正确顺序应该是：

1. 先看数据长什么样。
2. 理解每个字段含义。
3. 检查缺失值、异常值、重复值。
4. 明确业务问题。
5. 再决定用什么图。
6. 最后写结论。

图表不是目的。

图表是为了回答问题。

如果问题没问清楚，再漂亮的图也只是装饰。

31.2 输入可以是什么

数据分析 Skill 的输入通常包括：

• CSV 文件。
• Excel 文件。
• Google Sheets。
• 飞书表格。
• 数据库导出。
• 手动粘贴的小表格。

无论来源是什么，第一步都应该做数据理解：

• 有多少行、多少列。
• 每列字段叫什么。
• 字段类型是什么。
• 是否有空值。
• 是否有明显异常。
• 是否有时间字段、金额字段、分类字段。

你可以让 Codex 先做：

请先读取这份数据，输出字段说明、数据规模、缺失值、异常值和你建议分析的业务问题。先不要画图。

这句话能让分析更稳。

31.3 常见业务问题

数据分析不能只问"有什么发现"。

最好问具体业务问题。

比如：

• 销售额最近有没有下降？
• 哪个渠道转化最好？
• 哪类客户复购率最高？
• 哪些商品毛利低但销量高？
• 哪个地区投诉最多？
• 活动前后数据有没有变化？
• 本月新增用户来自哪里？

如果你不知道该问什么，可以让 Codex 先建议：

请根据这份数据，帮我提出 5 个最值得分析的业务问题，并说明每个问题需要用哪些字段回答。

这比直接生成十张图更有价值。

31.4 图表怎么选

常见图表选择：

新手常犯的错是图太多。

一份报告不需要把所有字段都画一遍。

更好的结构是：

• 3 到 5 个核心结论。
• 每个结论配 1 张图或 1 个表。
• 图后面写一句解释。
• 最后给行动建议。

31.5 图表报告的结构

推荐结构：

# 数据分析报告

## 1. 摘要

- 核心结论 1
- 核心结论 2
- 核心结论 3

## 2. 数据说明

- 数据来源
- 时间范围
- 字段说明
- 数据质量问题

## 3. 关键发现

### 发现一：

图表 / 表格

解释：

### 发现二：

图表 / 表格

解释：

## 4. 风险和限制

## 5. 建议动作

报告里一定要有"风险和限制"。

比如：

• 数据只有一周，不能代表长期趋势。
• 部分字段缺失。
• 数据来自抽样，不是全量。
• 没有成本数据，所以无法判断利润。

这能避免读者过度解读。

31.6 质量检查：防止一本正经地错

数据分析最怕的是：

结论写得很自信，但算错了。

所以必须检查：

• 行数是否对。
• 分组字段是否正确。
• 时间范围是否正确。
• 金额是否需要去重。
• 百分比是否用对分母。
• 图表标题是否和数据一致。
• 结论是否超出数据能支持的范围。

你可以让 Codex 自查：

请检查这份分析报告：
1. 每个结论是否有数据支持。
2. 百分比和排名是否计算正确。
3. 是否存在把相关性当因果的表述。
4. 是否有超出数据范围的判断。
5. 图表标题是否准确。

数据报告一定要给自己留一点怀疑精神。

31.7 一个数据分析 Skill 提示词

请按数据分析报告流程处理这个文件。

要求：
1. 先读取并理解数据，输出字段说明和数据质量检查。
2. 根据数据提出 3 到 5 个值得分析的业务问题。
3. 我确认问题后，再生成图表和报告。
4. 报告必须包含摘要、数据说明、关键发现、风险限制、建议动作。
5. 所有结论都要能追溯到数据，不要编造原因。

这个提示词的关键是"我确认问题后"。

数据分析最重要的不是跑得快，而是方向对。

31.8 本章小结

• 数据分析不要先画图，先理解数据和业务问题。
• 图表是为了回答问题，不是为了装饰报告。
• 一份好报告包含摘要、数据说明、关键发现、风险限制和建议动作。
• 结论必须有数据支持，不要把相关性写成因果。
• 让 Codex 先提出分析问题，确认后再生成图表，会更稳。

下一章开始，我们继续看更多业务场景：自媒体运营、客户跟进、飞书办公协同和行业研究报告。

第32章 实战：自媒体运营 Skill

32.0 本章你会学到什么

学完这一章，你会知道：

• 自媒体运营 Skill 能帮你做什么。
• 为什么它不只是"帮我写一篇文章"。
• 选题、拆稿、改写、发布计划和复盘怎么串起来。
• 如何避免让 AI 产出千篇一律的内容。

这一章的关键词是：把内容生产变成流程。

32.1 自媒体运营不是只写文案

很多人让 Codex 做自媒体时，第一句话是：

帮我写一篇小红书笔记。

这当然可以，但只是其中一小步。

完整的自媒体运营至少包括：

• 选题。
• 受众分析。
• 标题和封面方向。
• 内容大纲。
• 正文撰写。
• 平台适配。
• 发布节奏。
• 数据复盘。
• 选题迭代。

自媒体运营 Skill 的价值，不是一次写出"爆款"，而是帮你稳定完成这套流程。

真正可持续的内容生产，靠的是选题库、素材库、复盘和迭代，而不是每次临时灵感。

32.2 自媒体运营 Skill 的输入

常见输入包括：

• 一段原始观点。
• 一篇长文。
• 一段直播稿。
• 一份产品说明。
• 一组用户问题。
• 一份案例资料。
• 一个账号定位。
• 历史爆款内容。

输入越清楚，结果越好。

比如你只说：

帮我写一篇关于 Codex 的自媒体文。

范围太大。

更好的输入是：

账号定位：面向零基础 AI 工具学习者。
平台：小红书。
主题：为什么 Codex 不只是写代码。
目标：让读者收藏，并愿意跟着教程实践。
素材：下面这段教程内容。

自媒体内容不是凭空写，而是围绕定位、平台、读者和素材加工。

32.3 工作流程怎么设计

一个自媒体运营 Skill 可以这样设计：

1. 确认账号定位：写给谁，解决什么问题。
2. 提炼选题：从素材里提炼 5 到 10 个可发选题。
3. 筛选角度：按痛点、收益、反差、教程、案例分类。
4. 生成标题：每个选题给 3 到 5 个标题方向。
5. 生成大纲：先看结构，不急着写正文。
6. 撰写正文：按平台风格写。
7. 生成配图建议：封面、图文页、截图点。
8. 发布前检查：标题是否夸张、内容是否准确、行动引导是否自然。
9. 复盘记录：发布后记录数据和反馈。

不要让 Codex 一口气从"想写什么"跳到"最终正文"。

中间的选题和大纲，决定了内容质量。

32.4 平台适配要讲清楚

不同平台内容形态不同。

你给 Codex 的提示词里，要明确平台。

同一段内容，发公众号和发短视频，结构完全不同。

比如短视频更需要：

• 前 5 秒钩子。
• 口语化句子。
• 画面提示。
• 节奏点。
• 结尾行动。

公众号更需要：

• 完整论证。
• 清晰标题层级。
• 案例和解释。
• 可收藏结构。

32.5 一个自媒体运营提示词

请把下面这段教程内容拆成一组自媒体选题。

账号定位：面向零基础 AI 工具学习者
平台：小红书
目标：让读者收藏并愿意实践

要求：
1. 先给 10 个选题，不要直接写正文。
2. 每个选题包含：标题方向、目标读者、核心卖点、适合配图。
3. 标注哪些适合做图文，哪些适合做短视频。
4. 不要制造焦虑，不要夸大效果。
5. 选出最推荐的 3 个，并说明理由。

素材如下：
……

选题确认后，再写正文：

请把第 3 个选题写成小红书图文笔记。
要求：
1. 标题给 5 个备选。
2. 正文分成 6 页图文卡片。
3. 每页给标题、正文和配图建议。
4. 语言口语化，但不要夸张承诺。

这就是分阶段生产内容。

32.6 自媒体内容的质量检查

发布前至少检查：

• 是否符合账号定位。
• 标题是否过度夸张。
• 有没有事实错误。
• 有没有平台不适合的表达。
• 是否有清晰行动建议。
• 是否能从素材追溯来源。
• 是否避免过度承诺。

你可以让 Codex 自查：

请检查这篇自媒体内容：
1. 是否有夸大或误导表达。
2. 是否符合零基础用户阅读习惯。
3. 是否有事实可能过期，需要标注以官方为准。
4. 是否适合拆成图文卡片。
5. 是否有自然的收藏或实践引导。

自媒体不是越刺激越好。

长期账号靠的是信任，不是一次性标题。

32.7 本章小结

• 自媒体运营 Skill 不只是写文案，而是选题、拆稿、平台适配、发布和复盘的流程。
• 输入要包含账号定位、平台、目标读者、主题和素材。
• 先产出选题和大纲，再写正文，质量会更稳。
• 不同平台内容结构不同，提示词里要写清平台。
• 发布前要检查事实、边界、夸张表达和行动引导。

下一章我们进入销售和客户场景：客户跟进与销售辅助 Skill。

第33章 实战：客户跟进与销售辅助 Skill

33.0 本章你会学到什么

学完这一章，你会知道：

• 客户跟进 Skill 能帮销售和运营做什么。
• 如何把聊天记录、会议纪要和客户资料变成跟进计划。
• 客户分级、下一步动作、消息草稿怎么设计。
• 为什么销售辅助必须保留人工确认。

这一章的关键词是：让客户信息不再散落在聊天里。

33.1 客户跟进的真正难点

客户跟进难点通常不是"不会发消息"，而是信息太散：

• 聊天记录在群里。
• 客户需求在会议里。
• 报价在表格里。
• 待办在脑子里。
• 上次沟通时间没人记。
• 客户真实顾虑藏在几句话里。

客户跟进 Skill 要解决的，是把这些信息整理成可行动的计划。

它应该回答：

• 这个客户现在处于什么阶段？
• 客户最关心什么？
• 上次承诺了什么？
• 下一步应该做什么？
• 谁负责？
• 什么时候跟进？
• 发什么内容比较合适？

33.2 输入来源有哪些

常见输入：

• 客户聊天记录。
• 销售通话纪要。
• 会议纪要。
• CRM 导出表格。
• 客户资料表。
• 报价单。
• 历史跟进记录。
• 客户反馈或异议。

如果接入办公工具，还可以结合：

• 飞书群聊消息。
• 飞书任务。
• 飞书表格。
• 日历会议记录。

但第一版建议先从简单输入开始：

客户资料 + 最近聊天记录 + 当前目标

先把整理流程跑通，再接更复杂的数据源。

33.3 输出结构怎么设计

推荐输出：

# 客户跟进建议

## 客户概况

## 当前阶段

## 关键需求

## 主要顾虑

## 已承诺事项

## 下一步动作

| 动作 | 负责人 | 截止时间 | 优先级 |
|---|---|---|---|

## 跟进消息草稿

## 需要人工确认的问题

注意最后一项：需要人工确认的问题。

销售场景里，AI 不能乱猜客户意图。

如果客户没有明确说预算、决策人、时间表，就应该标为待确认，而不是自动补上。

33.4 客户分级不要复杂化

新手可以先用简单分级：

分级必须有理由。

不要只输出：

客户等级：A

要输出：

客户等级：A
理由：客户已明确需求、预算范围和上线时间，但仍需确认最终决策人。

这样销售才知道下一步该补什么。

33.5 跟进消息必须先草稿

客户沟通很敏感。

不要让 Codex 直接发送消息。

正确做法是先生成草稿：

请根据客户情况，生成一条微信/飞书跟进消息草稿。
要求：
1. 语气自然，不要过度销售。
2. 先回应客户关心点。
3. 只推动一个明确下一步。
4. 不承诺未确认的价格、排期或功能。
5. 先给我确认，不要发送。

发送前一定人工看一眼。

尤其是：

• 报价。
• 合同。
• 折扣。
• 交付时间。
• 法务承诺。
• 定制开发范围。

这些不能让 AI 自己决定。

33.6 一个客户跟进 Skill 提示词

请根据下面客户资料和沟通记录，生成客户跟进建议。

要求：
1. 先总结客户当前需求和阶段。
2. 标出客户主要顾虑。
3. 列出已承诺事项，不要编造。
4. 给出下一步动作，包含负责人、截止时间、优先级。
5. 生成一条跟进消息草稿，但不要发送。
6. 把不确定信息放到“需要人工确认的问题”里。

客户资料：
……

沟通记录：
……

如果要批量处理客户，可以改成：

请读取这份客户跟进表，按 A/B/C/风险 四类分组，并为每类客户生成下一步建议。不要直接发消息。

批量处理更要保守，避免误伤客户关系。

33.7 本章小结

• 客户跟进 Skill 的重点是整理客户状态、需求、顾虑、承诺和下一步动作。
• 客户分级要简单，并且必须写清理由。
• 跟进消息只能先生成草稿，不要自动发送。
• 报价、合同、折扣、交付承诺必须人工确认。
• 不确定的信息要标为待确认，不要让 AI 猜。

下一章我们进入飞书办公协同，把日历、群聊、任务、文档这些能力组合起来。

第34章 实战：飞书办公协同 Skill

34.0 本章你会学到什么

学完这一章，你会知道：

• 飞书办公协同 Skill 可以串起哪些场景。
• 日历、群聊、任务、文档、表格之间怎么配合。
• user 身份和 bot 身份为什么会影响结果。
• 写入类动作为什么一定要先确认。

这一章的关键词是：把分散的办公动作串成流程。

34.1 飞书办公协同不只是发消息

很多人一想到飞书自动化，就想到：

帮我发一条群消息。

这只是很小的一部分。

真正的办公协同通常包括：

• 查日历。
• 找会议。
• 整理会议纪要。
• 创建任务。
• 更新任务状态。
• 创建或更新文档。
• 读取表格。
• 搜索群聊记录。
• 给群里发送草稿消息。

飞书办公协同 Skill 的价值，是把这些动作按业务目标串起来。

比如"项目周报"：

1. 查本周会议。
2. 汇总会议纪要。
3. 查未完成任务。
4. 整理风险和进展。
5. 生成周报文档。
6. 起草群通知。
7. 用户确认后再发送。

这才叫协同。

34.2 典型场景一：每日站会摘要

输入：

• 今天日历。
• 未完成任务。
• 昨天会议纪要。
• 项目群重要消息。

输出：

• 今日会议列表。
• 今日重点任务。
• 需要提前准备的材料。
• 可能阻塞项。

提示词示例：

请整理今天的站会准备材料。
要求：
1. 汇总今天的日程。
2. 列出与我相关的未完成任务。
3. 标出需要我提前准备材料的会议。
4. 输出一份简短摘要，不要创建任务或发消息。

先从只读摘要开始，是最稳的。

34.3 典型场景二：会议后行动项落地

输入：

• 会议纪要。
• 待办事项。
• 负责人列表。
• 项目任务清单。

输出：

• 待创建任务列表。
• 任务负责人。
• 截止时间。
• 群消息草稿。

流程：

1. 从纪要中提取待办。
2. 检查每个待办是否有负责人和截止时间。
3. 缺失信息标为待确认。
4. 生成任务创建清单。
5. 用户确认后再创建任务。
6. 起草群消息。
7. 用户确认后再发送。

写入类动作一定要分两步：

请先列出准备创建的任务清单，不要直接创建。

确认后再说：

确认创建这些任务。

34.4 典型场景三：项目周报

项目周报可以组合多个来源：

• 本周日程。
• 本周会议纪要。
• 任务完成情况。
• 项目表格数据。
• 群聊里的风险反馈。

输出结构：

# 项目周报

## 本周进展

## 已完成事项

## 进行中事项

## 风险和阻塞

## 需要决策

## 下周计划

提示词示例：

请整理本周项目周报。
要求：
1. 先列出你会读取哪些来源。
2. 只读数据，不要改任务或发消息。
3. 把结论和证据分开写。
4. 需要决策的事项单独列出。
5. 生成周报草稿后等我确认。

这类场景最重要的是证据链。

周报里的结论最好能追溯到会议、任务或表格。

34.5 user 和 bot 身份的影响

飞书协同里最容易卡的是身份。

简单记：

• 查"我的日历""我的文档""我的任务"，通常需要 user 身份。
• 机器人发群消息、机器人管理应用资源，可能用 bot 身份。

如果身份不对，结果可能是：

• 查不到日历。
• 看不到群消息。
• 联系人只显示 ID。
• 无法访问文档。
• 无法创建或更新任务。

所以飞书 Skill 里最好写一条规则：

执行前先确认当前身份是 user 还是 bot；如果结果为空，先排查身份和权限，不要直接认为数据不存在。

这能避免很多误判。

34.6 权限和安全边界

飞书办公协同涉及真实工作数据，必须谨慎。

建议规则：

• 读操作可以先执行，但要说明来源。
• 写文档前先给结构草稿。
• 创建任务前先列任务清单。
• 发消息前先生成消息草稿。
• 删除、撤回、批量修改必须二次确认。
• 遇到权限错误，先说明缺什么 scope，不要盲目重试。

你可以把这段写进 Skill：

## 安全边界

- 不自动发送消息。
- 不自动删除或撤回内容。
- 不自动批量修改任务。
- 所有写入动作必须先输出预览，并等待用户确认。

办公自动化越接近真实协作，越需要保护边界。

34.7 本章小结

• 飞书办公协同 Skill 是把日历、会议、群聊、任务、文档、表格串成流程。
• 典型场景包括站会摘要、会议后行动项、项目周报。
• user 和 bot 身份会影响能看到什么、能操作什么。
• 写入、发送、删除、批量修改必须先预览再确认。
• 遇到空结果或权限错误，先排查身份和 scope。

下一章是第五部分最后一个场景：行业研究报告 Skill。

第35章 实战：行业研究报告 Skill

35.0 本章你会学到什么

学完这一章，你会知道：

• 行业研究报告 Skill 应该如何设计。
• 为什么资料来源比写作能力更重要。
• 一份行业报告应该包含哪些结构。
• 如何避免 AI 编造数据和结论。

这一章的关键词是：证据链。

35.1 行业研究最怕什么

行业研究最怕的不是写得慢，而是：

• 数据来源不清。
• 结论没有证据。
• 把旧数据当新数据。
• 把营销稿当事实。
• 把个案当趋势。
• 引用来源混乱。
• AI 编造机构和数字。

所以行业研究报告 Skill 的第一原则是：

先找证据，再写结论。

不要一上来就让 Codex "写一份行业报告"。

应该先让它列研究问题、来源范围和证据清单。

35.2 行业研究 Skill 的输入

输入可以包括：

• 研究主题。
• 目标行业。
• 地区范围。
• 时间范围。
• 目标读者。
• 已有资料。
• 竞品名单。
• 关注问题。
• 输出格式。

比如：

研究主题：AI 编程工具在教育培训行业的应用机会
地区：中国市场
时间范围：近两年
目标读者：课程产品负责人
输出：一份 3000 字研究简报
重点关注：用户需求、竞品、商业机会、风险

这些信息越清楚，研究越不会跑偏。

35.3 先设计研究问题

行业研究不要先写正文，先设计问题。

比如：

• 这个行业现在的规模和增长趋势如何？
• 用户是谁，痛点是什么？
• 主要玩家有哪些？
• 他们分别怎么收费？
• 技术或政策有什么变化？
• 哪些需求还没被满足？
• 新进入者机会在哪里？
• 最大风险是什么？

提示词：

请先不要写报告。请根据这个研究主题，设计 8 到 12 个研究问题，并说明每个问题需要哪些证据来源。

这一步能避免报告变成泛泛而谈。

35.4 来源分级

行业研究资料要分级。

报告里可以引用低可信来源，但不能让它单独支撑重大结论。

比如"很多用户抱怨价格高"可以来自社交平台观察。

但"市场规模达到多少亿"必须来自更可靠来源。

35.5 报告结构怎么设计

推荐结构：

# 行业研究报告

## 1. 执行摘要

## 2. 研究范围与方法

## 3. 行业背景

## 4. 市场规模与趋势

## 5. 用户需求与痛点

## 6. 主要玩家与竞品对比

## 7. 机会判断

## 8. 风险与不确定性

## 9. 建议行动

## 10. 来源列表

如果是给老板或客户看的简报，可以压缩成：

• 一页摘要。
• 三个核心结论。
• 证据表格。
• 机会和风险。
• 建议动作。

不要一上来写 50 页。

先写 5 页清楚的简报，比 50 页堆资料更有用。

35.6 防止编造的规则

行业研究 Skill 里必须写安全规则：

## 事实规则

- 没有来源的数据，不写成确定事实。
- 不确定的数字，标注“待核实”。
- 过期数据必须标注年份。
- 不把单个案例上升为行业趋势。
- 不编造机构、报告、专家、链接。
- 结论后面尽量附上证据来源。

你也可以在提示词里说：

如果缺少可靠来源，请直接写“资料不足”，不要猜。

这句话非常重要。

研究报告宁可保守，也不要自信地错。

35.7 一个行业研究提示词

请帮我设计一份行业研究报告。

研究主题：
地区范围：
时间范围：
目标读者：
报告用途：
已有资料：

要求：
1. 先不要写正文。
2. 先提出研究问题和证据来源清单。
3. 区分事实、推测和观点。
4. 所有数据都要标注年份和来源。
5. 缺少可靠来源时，写“资料不足”，不要编造。
6. 最终报告包含执行摘要、市场趋势、用户痛点、竞品对比、机会、风险和建议。

如果你需要联网研究，可以补一句：

请优先查官方、公司官网、权威报告和一手资料，再参考媒体报道。

这能让来源质量更高。

35.8 本章小结

• 行业研究报告 Skill 的核心是证据链，不是漂亮文字。
• 先设计研究问题，再收集来源，最后写报告。
• 来源要分级，重大结论不能只靠低可信来源。
• 数据必须标注年份和来源，缺资料就写资料不足。
• 不要把单个案例写成行业趋势，不要编造报告和数字。

到这里，第五部分结束。

你已经看完了 8 个业务场景：业务 Skill 设计、会议纪要、知识库整理、数据分析、自媒体运营、客户跟进、飞书协同和行业研究。

下一部分开始，我们会进入编程项目实战。正式出版版建议只保留 3 个代表性项目：从零搭建项目、文件数据清洗工具、小程序；智能体对话平台、数字人口播视频工具、iOS APP、AI 硬件功能开发如果没有真实跑通记录，应降级为“后续选题索引”。

第六部分：编程项目实战

前面五部分主要解决"怎么用 Codex 做事"。

第六部分开始，我们进入更接近开发的场景。

这里的"编程项目实战"不是要求你马上变成程序员，而是让你学会：

• 怎么把一个想法拆成项目。
• 怎么让 Codex 生成项目骨架。
• 怎么做一个能跑的小工具。
• 怎么验证结果。
• 怎么遇到报错时不慌。
• 怎么从小项目逐步走向更复杂的应用。

这一部分会出现网页、小工具、智能体平台、视频工具、小程序、iOS APP、ESP32 硬件这些案例。

不用一次学完。你可以先挑一个最贴近自己工作的项目，跟着做一遍。

发布前硬标准：保留的项目章节必须补齐真实 starter 包或仓库链接、Codex 版本、使用模型、token/费用估算、至少 3 个翻车现场、5 到 10 轮真实对话、验证截图和 git log --oneline。没有这些材料的章节，不能包装成“完整实战”，只能作为路线说明。

第36章 从零搭建项目

36.0 本章你会学到什么

学完这一章，你会知道：

• 从一个想法到项目文件夹，中间应该经过哪些步骤。
• 为什么新项目不要一上来就让 Codex 写代码。
• README.md、PRD.md、DESIGN.md、PLAN.md、AGENTS.md 如何一起工作。
• 新手如何控制项目范围，先做最小可用版本。

这一章是所有编程实战的起点。

36.1 新项目最容易失败在哪里

新手做项目最常见的失败方式是：

帮我做一个完整的 XXX 系统。

这句话听起来很有目标，其实范围太大。

比如"做一个客户管理系统"，里面可能包含：

• 登录注册。
• 客户列表。
• 客户详情。
• 标签分类。
• 跟进记录。
• 数据导入。
• 权限管理。
• 提醒通知。
• 报表分析。
• 部署上线。

你一口气让 Codex 全做，很容易变成：

• 文件很多，但跑不起来。
• 功能很多，但都很浅。
• 改一个地方，另一个地方坏。
• 自己看不懂项目结构。

所以新项目第一原则是：

先做最小可用版本，不做完整系统。

36.2 从想法到项目的五步

推荐流程：

1. 写清想法：一句话说明这个项目要解决什么问题。
2. 写 PRD：明确用户、功能范围、不做什么。
3. 写 DESIGN：决定技术方案、页面结构、数据流。
4. 写 PLAN：把第一版拆成小步骤。
5. 再开始写代码：按步骤做，做一步验证一步。

这和前面四文档法则是一致的。

不要跳过文档。

文档不是为了装专业，而是为了让 Codex 少猜。

36.3 一个从零开始的提示词

你可以这样开始：

我想从零做一个项目。

项目想法：做一个本地运行的个人记账网页。
目标用户：不会编程的普通人。
第一版只做：录入收入支出、查看列表、按月份汇总。
第一版不做：登录、云同步、多人协作、手机 App。

请先不要写代码。
请帮我生成 README.md、PRD.md、DESIGN.md、PLAN.md 和 AGENTS.md 的初稿。
要求：每份文档都面向新手，内容精简，可执行。

这段提示词最重要的是两句：

• 第一版只做什么。
• 第一版不做什么。

范围一清楚，项目就稳了一半。

36.4 项目目录怎么设计

新手项目可以先用简单目录：

my-project/
├── AGENTS.md
├── README.md
├── PRD.md
├── DESIGN.md
├── PLAN.md
├── src/
├── data/
├── output/
└── tests/

每个目录作用：

小项目可以更简单，但不要所有东西都堆在根目录。

目录清楚，Codex 也更容易理解。

36.5 第一版只做垂直切片

什么叫垂直切片？

就是从用户动作到结果展示，先跑通一条最小流程。

比如记账工具第一版，不要先做十个页面。

先做：

1. 输入一条收入或支出。
2. 保存到本地数据。
3. 在列表里显示。
4. 汇总当月总收入和总支出。

这就是一条完整闭环。

哪怕很丑，也比"页面很多但不能用"强。

Codex 做项目时，最稳的方式就是先跑通闭环，再逐步增强。

36.6 新项目要先验证环境

项目搭好后，第一件事不是继续加功能，而是验证：

• 能不能安装依赖。
• 能不能启动。
• 能不能打开页面。
• 测试命令是否能跑。
• README 里的命令是否真实可用。

提示词：

请先按 README 的步骤从零运行这个项目，确认安装、启动、测试命令是否可用。发现问题先汇报，不要直接扩展功能。

这一步能避免后面越做越歪。

很多项目失败不是功能写错，而是最基础的运行流程没打通。

36.7 本章小结

• 新项目不要一上来做完整系统，先做最小可用版本。
• 从想法到代码，先经过 PRD、DESIGN、PLAN、AGENTS.md。
• 第一版只做垂直切片，让核心流程跑通。
• 项目目录要清楚，不要把所有文件堆在一起。
• 写功能前先验证环境，确保项目能安装、能启动、能测试。

下一章我们做一个非常适合小白的实战项目：文件数据清洗工具。

第37章 文件数据清洗工具

37.0 本章你会学到什么

学完这一章，你会知道：

• 什么是文件数据清洗工具。
• 为什么它适合作为第一个编程小项目。
• 一个 CSV 清洗工具可以包含哪些功能。
• 如何让 Codex 按测试和样例一步步实现。

这个项目很适合练手，因为它目标清楚、结果可验证、和真实工作关系很近。

37.1 数据清洗工具解决什么问题

很多工作里都会遇到脏数据：

• 表头不统一。
• 日期格式混乱。
• 手机号有空格。
• 金额里有逗号或货币符号。
• 重复行。
• 空值。
• 多余列。
• 编码乱码。

如果每次都手动改 Excel，很费时间，也容易错。

文件数据清洗工具的目标是：

输入一个脏文件，输出一个更干净、更规范的文件。

比如：

input/customers.csv → output/customers_clean.csv

37.2 第一版功能不要太多

第一版可以只做 CSV。

功能控制在 5 个以内：

• 读取 CSV。
• 去掉空白行。
• 统一表头名称。
• 去除单元格前后空格。
• 删除完全重复的行。
• 输出清洗后的 CSV。

不要一开始就做：

• Excel 多工作表。
• 数据库导入。
• 图形界面。
• 拖拽上传。
• 自动识别所有字段。
• 云端同步。

这些可以后面再加。

第一版的目标是：能稳定清洗一个示例 CSV。

37.3 准备样例数据

先准备一个小 CSV：

姓名, 手机号 ,金额
张三, 138 0000 0000 , ¥1,200
李四,13900000000,800
张三, 138 0000 0000 , ¥1,200
,,

期望输出：

name,phone,amount
张三,13800000000,1200
李四,13900000000,800

有了样例和期望结果，Codex 就不需要猜。

数据工具最重要的是可验证。

如果没有样例，"清洗干净"这四个字太模糊。

37.4 用测试驱动实现

数据清洗工具非常适合用测试驱动。

你可以让 Codex 先写测试：

请先不要实现功能。
请根据下面输入 CSV 和期望输出，先写测试用例。
要求：
1. 测试去掉空白行。
2. 测试去掉重复行。
3. 测试手机号去空格。
4. 测试金额去掉货币符号和逗号。
5. 先运行测试，确认失败后再实现。

为什么要先测试？

因为数据清洗工具最怕"看起来处理了，但结果不对"。

有测试，Codex 每改一次都能确认没有把旧功能改坏。

37.5 一个项目计划示例

PLAN.md 可以这样写：

# PLAN.md

## 目标

做一个命令行 CSV 清洗工具。

## 本次范围

本次做：

- 读取 CSV
- 清洗表头
- 去除空白行
- 去除重复行
- 规范手机号和金额
- 输出新 CSV

本次不做：

- 图形界面
- Excel 文件
- 数据库
- 云端上传

## 步骤

- [ ] 准备示例输入和期望输出
- [ ] 写测试
- [ ] 实现读取和输出
- [ ] 实现清洗规则
- [ ] 跑测试
- [ ] 写 README 使用说明

这份计划很简单，但足够执行。

新手项目不怕简单，怕不清楚。

37.6 输出报告很有用

清洗工具最好不只输出干净文件，还输出一份报告。

比如：

清洗完成：
- 原始行数：1000
- 删除空白行：12
- 删除重复行：34
- 手机号规范化：256
- 金额规范化：812
- 输出文件：output/customers_clean.csv

这能让用户知道工具做了什么。

否则用户会不放心：它到底改了哪些数据？

数据处理工具一定要透明。

37.7 后续可以加什么

第一版跑通后，可以逐步增加：

• 支持 Excel。
• 支持字段映射配置。
• 支持错误行导出。
• 支持清洗前后对比报告。
• 支持批量处理多个文件。
• 支持网页上传界面。
• 支持图表化展示数据质量。

每次只加一两个功能。

每加一个功能，都补测试。

这样项目会越长越稳，而不是越长越乱。

37.8 本章小结

• 文件数据清洗工具适合小白练手，因为输入输出清楚、结果可验证。
• 第一版先做 CSV，不要一上来支持所有格式。
• 先准备样例输入和期望输出，再让 Codex 写测试。
• 清洗工具最好输出处理报告，让用户知道改了什么。
• 后续功能要分阶段增加，每加一个功能都补测试。

下一章我们进入更像产品的项目：智能体对话平台。

第38章 智能体对话平台

38.0 本章你会学到什么

学完这一章，你会知道：

• 智能体对话平台是什么。
• 它和普通聊天页面有什么区别。
• 第一版应该做哪些功能，不应该做哪些功能。
• 构建 AI 对话产品时要注意哪些安全和成本问题。

这一章只讲项目设计和实现路线，不写死具体 API 代码。因为模型、SDK 和平台能力变化很快，真正开发时要以官方文档为准。

38.1 什么是智能体对话平台

普通聊天页面通常是：

用户输入一句话 → AI 回复一句话

智能体对话平台更进一步：

用户提出目标 → AI 理解任务 → 调用工具 → 多步执行 → 返回结果

比如用户说：

帮我分析这个 CSV，并生成一份图表报告。

普通聊天可能只告诉你怎么做。

智能体平台可以：

1. 上传文件。
2. 读取数据。
3. 分析字段。
4. 生成图表。
5. 输出报告。
6. 保存结果。

这就是智能体和普通聊天的区别：它不只回答，还能执行流程。

38.2 第一版不要做太复杂

智能体平台很容易越想越大：

• 多用户登录。
• 多智能体协作。
• 文件系统。
• 工具市场。
• 权限管理。
• 计费系统。
• 对话记忆。
• 后台管理。
• 数据看板。

第一版先别做这些。

建议第一版只做：

• 一个聊天界面。
• 一个后端接口。
• 支持选择一个智能体角色。
• 支持基础对话。
• 支持显示工具调用状态。
• 支持保存简单对话记录。
• 支持错误提示。

第一版目标不是做平台，而是跑通：

用户发消息，智能体回复，并能清楚展示过程。

38.3 一个最小功能清单

可以这样定义：

## 第一版功能

- 用户输入消息。
- 页面显示用户消息和 AI 回复。
- 支持选择智能体：通用助手 / 数据分析助手 / 写作助手。
- 后端负责调用模型接口。
- 如果发生错误，页面显示友好提示。
- 本地保存最近 10 条对话。
- README 写清如何配置 API Key。

## 第一版不做

- 用户登录。
- 计费。
- 多人协作。
- 长期记忆。
- 文件上传。
- 复杂工具调用。
- 生产环境部署。

这个范围对新手更友好。

先把最小对话跑通，再谈工具、记忆和多智能体。

38.4 技术结构怎么理解

一个简单智能体对话平台通常分三层：

简单流程：

用户输入
  ↓
前端发送请求
  ↓
后端调用模型或 Agent SDK
  ↓
模型可能调用工具
  ↓
后端返回结果
  ↓
前端展示回复

新手不要把 API Key 放在前端页面里。

API Key 应该放在后端环境变量里。

这是安全底线。

38.5 使用官方能力时要看最新文档

构建智能体平台时，常见会涉及：

• Responses API
• Agents SDK
• 工具调用
• 文件搜索
• 网页搜索
• 代码执行
• 追踪和评估

这些能力变化很快。

教程里只给思路，不写死某个接口细节。

真正开发时，你应该让 Codex 先查官方文档：

请先查 OpenAI 官方文档，确认当前推荐的智能体构建方式，再给我设计第一版架构。不要使用过期接口。

这样能避免跟着旧教程写旧代码。

38.6 安全和成本意识

AI 对话平台一定要注意两件事：安全和成本。

安全方面：

• API Key 不放前端。
• 不让模型随便执行危险命令。
• 文件上传要限制类型和大小。
• 工具调用要有权限边界。
• 用户输入不能直接变成系统指令。

成本方面：

• 限制单次输入长度。
• 限制历史消息数量。
• 给长任务加确认。
• 记录调用次数。
• 对大文件先摘要再处理。

新手做本地练习时可以简单一点，但这些意识要从第一天建立。

否则项目一上线，很容易出问题。

38.7 一个智能体平台提示词

我想做一个本地运行的智能体对话平台。

第一版功能：
1. 一个聊天页面。
2. 一个后端接口。
3. 支持通用助手、写作助手、数据分析助手三个角色。
4. 支持保存最近 10 条本地对话。
5. API Key 放在后端环境变量里。

第一版不做：
1. 用户登录。
2. 文件上传。
3. 计费。
4. 多智能体协作。
5. 生产部署。

请先不要写代码。
请生成 README.md、PRD.md、DESIGN.md、PLAN.md 和 AGENTS.md。
并在 DESIGN.md 里写清前端、后端、模型调用和安全边界。

拿到文档后，再按 PLAN.md 一步一步做。

38.8 本章小结

• 智能体对话平台不只是聊天，而是围绕目标调用工具、多步执行。
• 第一版先做最小对话闭环，不要一上来做完整平台。
• API Key 不要放前端，模型调用应通过后端完成。
• OpenAI 智能体相关能力变化快，开发前要查官方文档。
• 从第一版开始建立安全和成本意识。

下一章我们继续扩展到内容生产项目：数字人口播视频工具。

第39章 数字人口播视频工具

39.0 本章你会学到什么

学完这一章，你会知道：

• 数字人口播视频工具由哪些模块组成。
• 第一版应该先做什么，不应该做什么。
• 文案、TTS、字幕、画面、导出之间怎么串起来。
• 为什么数字人项目一定要重视授权和合规。

这一章适合内容创作者、课程团队和想做视频自动化的人。

39.1 数字人口播视频工具是什么

数字人口播视频工具，可以理解成：

把一段文字变成一条带声音、字幕和人物画面的视频。

一个完整流程通常包括：

1. 输入主题或脚本。
2. Codex 帮你改成口播稿。
3. TTS 生成语音。
4. 数字人或头像生成画面。
5. 自动生成字幕。
6. 合成音频、字幕、画面。
7. 导出视频。

听起来很复杂，但第一版不用全自动。

新手要先做"半自动工具"：

脚本整理 → 生成语音 → 生成字幕 → 合成视频

数字人画面可以先用固定背景、头像或占位视频，后面再接更复杂的数字人服务。

39.2 第一版不要追求全自动数字人

数字人项目最容易贪心：

• 想自动写脚本。
• 想自动生成声音。
• 想自动生成真人口型。
• 想自动配图。
• 想自动剪辑。
• 想一键发布多个平台。

第一版先别这样。

建议第一版只做：

• 输入一段文本。
• 改成口播稿。
• 分段。
• 生成字幕文件。
• 允许用户放入已有音频或 TTS 音频。
• 用固定背景和字幕合成视频。
• 导出 MP4。

这已经是一个完整闭环。

等这条流程稳定，再加数字人、口型、批量生成和平台发布。

39.3 项目模块怎么拆

可以拆成 5 个模块：

新手第一版可以先不做语音识别，也不做复杂口型同步。

先让 Codex 生成：

• script.txt
• voice.mp3
• subtitle.srt
• output.mp4

文件清楚，流程就清楚。

39.4 口播稿处理很关键

不要把文章直接拿去配音。

口播稿要更短、更自然。

可以让 Codex 先处理：

请把下面文章改成 90 秒口播脚本。
要求：
1. 开头 5 秒说明痛点。
2. 每句话不超过 25 个字。
3. 不读表格、代码和链接。
4. 术语第一次出现时解释一句。
5. 输出分段脚本，每段标注预计时长。

视频工具里，文案质量决定一半效果。

很多视频难看，不是技术问题，而是稿子不适合听。

39.5 字幕文件是什么

常见字幕格式是 SRT。

它大概长这样：

1
00:00:00,000 --> 00:00:03,000
大家好，今天我们讲 Codex。

2
00:00:03,000 --> 00:00:06,000
它不是普通聊天工具。

字幕的重点是：

• 时间轴准确。
• 每行不要太长。
• 不要一屏堆太多字。
• 标点和断句适合观看。

第一版可以先用估算时间生成字幕。

后面再根据真实音频时长校准。

39.6 视频合成怎么理解

视频合成本质上是把几层东西叠起来：

背景画面
  + 人物或头像
  + 字幕
  + 音频
  = 最终视频

第一版可以用固定模板：

• 背景图。
• 左侧头像或数字人视频。
• 右侧标题和要点。
• 底部字幕。

不用一开始做复杂剪辑。

如果用命令行工具合成视频，Codex 可以帮你写脚本，但你要让它先做小样：

请先用 10 秒素材生成测试视频，确认字幕、音频、画面都正常，再处理完整视频。

视频处理耗时，先小样验证非常重要。

39.7 授权和合规边界

数字人项目一定要注意：

• 不要未经授权克隆真人声音。
• 不要未经授权使用真人肖像。
• 不要让观众误以为是真人亲自录制。
• 商用前确认数字人平台和素材授权。
• 涉及医疗、金融、法律等内容要谨慎。

如果你用的是自己的头像和声音，也要保存授权和素材来源。

数字人技术越逼真，越要透明。

效率不能建立在误导上。

39.8 本章小结

• 数字人口播视频工具由脚本、语音、字幕、画面、合成五部分组成。
• 第一版先做半自动闭环，不要一上来追求完整数字人。
• 口播稿要先改写，文章不能直接拿去配音。
• 字幕要控制长度、时间轴和可读性。
• 视频合成先做 10 秒小样，再处理完整视频。
• 真人声音和肖像必须授权，公开发布要避免误导。

下一章我们进入移动端轻应用：开发一个小程序。

第40章 开发一个小程序

40.0 本章你会学到什么

学完这一章，你会知道：

• 小程序项目适合解决什么问题。
• 第一版小程序应该怎么控制范围。
• 页面、数据、接口和发布之间是什么关系。
• 用 Codex 做小程序时应该怎么提需求。

这一章以通用小程序思路为主，不绑定某个平台的最新细节。具体开发时，以对应平台官方文档为准。

40.1 小程序适合什么场景

小程序适合轻量、明确、频繁使用的小工具。

比如：

• 活动报名。
• 预约登记。
• 商品展示。
• 课程目录。
• 打卡记录。
• 客户查询。
• 简单表单收集。
• 门店导航。

它不适合一上来做特别复杂的系统。

小程序的优势是：

• 用户不用安装独立 App。
• 分享方便。
• 适合手机端使用。
• 适合连接微信、支付宝、飞书等生态。

但它也有平台规则、审核、接口限制和账号配置。

所以第一版要简单。

40.2 第一版小程序怎么选题

适合新手的第一版：

• 页面不超过 3 个。
• 数据结构简单。
• 不做复杂支付。
• 不做复杂权限。
• 不接太多第三方服务。

比如做一个"课程资料小程序"：

第一版做：

• 首页展示课程列表。
• 详情页展示课程介绍。
• 收藏或报名按钮先做本地状态。

第一版不做：

• 会员体系。
• 支付。
• 直播。
• 评论区。
• 后台管理。

这样更容易跑通。

40.3 小程序的基本结构

大多数小程序都可以按这几块理解：

新手先把页面和数据跑通。

例如：

首页 → 列表数据 → 详情页

这条链路跑通后，再考虑登录、云端、支付和分享。

40.4 用 Codex 设计小程序第一版

可以这样说：

我想做一个课程资料小程序。

第一版功能：
1. 首页展示课程列表。
2. 点击课程进入详情页。
3. 详情页展示标题、简介、适合人群、学习收获。
4. 数据先写在本地 JSON，不接后端。

第一版不做：
1. 登录。
2. 支付。
3. 评论。
4. 后台管理。

请先不要写代码。
请生成 PRD.md、DESIGN.md、PLAN.md 和页面结构说明。

先让 Codex 设计页面和数据结构，再写代码。

小程序项目里，页面关系和数据字段特别重要。

40.5 开发小程序时怎么验证

小程序不能只看代码。

要在对应平台开发者工具或模拟器里看：

• 页面是否能打开。
• 路由是否正确。
• 数据是否显示。
• 按钮是否可点击。
• 手机尺寸下是否溢出。
• 网络请求是否成功。
• 控制台是否报错。

提示词：

请帮我检查小程序第一版：
1. 首页能否显示数据。
2. 点击列表项能否进入详情页。
3. 手机尺寸下文字是否溢出。
4. 控制台是否有报错。
5. 只修复阻塞问题，不新增功能。

每次只修阻塞问题，不要边修边加功能。

40.6 小程序发布前注意什么

发布前至少检查：

• 平台账号是否配置。
• 应用名称和类目是否符合规则。
• 隐私政策是否需要。
• 是否使用用户信息、位置、相册等权限。
• 是否有测试数据或调试入口残留。
• 接口域名是否配置正确。
• 页面是否符合平台审核要求。

这些平台规则会变化。

所以正式发布前，一定让 Codex 查当前平台官方文档：

请根据当前平台官方文档，帮我列出这个小程序发布前检查清单。

教程里不建议死记审核规则。

平台规则以官方为准。

40.7 本章小结

• 小程序适合轻量、手机端、分享方便的场景。
• 第一版页面不超过 3 个，先用本地数据跑通。
• 先设计页面关系和数据结构，再写代码。
• 验证要在开发者工具或模拟器里看真实效果。
• 发布前检查平台账号、权限、隐私政策、接口域名和审核规则。

下一章我们进入更完整的移动端应用：iOS APP。

第41章 开发 iOS APP

41.0 本章你会学到什么

学完这一章，你会知道：

• iOS APP 项目和网页、小程序有什么不同。
• 第一版 iOS APP 应该如何控制范围。
• Codex 可以在 iOS 开发里帮你做什么。
• 真机测试、权限和上架为什么不能忽略。

这一章仍然面向小白，重点讲项目方法，不要求你马上精通 Swift 或 Xcode。

41.1 iOS APP 和网页有什么不同

网页通常是：

• 浏览器打开。
• 更新快。
• 发布门槛低。
• 适合跨平台。

iOS APP 则更接近原生应用：

• 需要开发环境。
• 需要模拟器或真机测试。
• 需要处理系统权限。
• 上架要符合 App Store 规则。
• 可以更好地使用相机、通知、传感器、本地存储等能力。

所以 iOS APP 更适合：

• 高频使用。
• 需要手机系统能力。
• 需要更好体验。
• 需要长期产品化。

不适合拿来做非常临时的一次性工具。

41.2 第一版 iOS APP 做什么

第一版建议非常小。

比如做一个"习惯打卡 APP"：

第一版做：

• 显示习惯列表。
• 添加一个习惯。
• 点击完成今日打卡。
• 本地保存数据。
• 显示连续打卡天数。

第一版不做：

• 账号登录。
• iCloud 同步。
• 推送通知。
• 付费订阅。
• 社交分享。
• 复杂统计图。

iOS 项目调试成本比普通网页高，所以第一版越小越好。

41.3 Codex 能帮你做什么

Codex 在 iOS 项目里可以帮你：

• 设计 APP 功能范围。
• 写 README.md、PRD.md、DESIGN.md、PLAN.md。
• 生成 Swift 或 SwiftUI 代码。
• 解释 Xcode 报错。
• 拆分视图和数据模型。
• 写简单单元测试。
• 整理上架前检查清单。

但你仍然需要：

• 安装 Xcode。
• 打开项目。
• 在模拟器或真机里运行。
• 查看系统权限弹窗。
• 用真实设备验证体验。

Codex 能帮你写和改，但真实运行环境还要你配合。

41.4 一个 iOS APP 提示词

我想做一个 iOS 习惯打卡 APP。

第一版功能：
1. 展示习惯列表。
2. 添加习惯。
3. 今日打卡。
4. 本地保存。
5. 显示连续打卡天数。

第一版不做：
1. 登录。
2. 云同步。
3. 推送通知。
4. 订阅付费。
5. 社交分享。

请先不要写代码。
请生成 README.md、PRD.md、DESIGN.md、PLAN.md 和 AGENTS.md。
DESIGN.md 里请说明页面结构、数据模型、本地存储和测试方式。

文档确认后，再让 Codex 按步骤生成代码。

不要一上来直接说"写一个 iOS APP"。

41.5 iOS 项目怎么验证

iOS 项目验证至少包括：

• Xcode 能打开项目。
• 模拟器能运行。
• 页面能正常显示。
• 基本交互可用。
• 数据关闭重开后还在。
• 权限弹窗文案合理。
• 控制台没有关键报错。

如果有真机，最好真机测一次。

模拟器和真机体验可能不同，特别是相机、麦克风、蓝牙、通知、定位这些能力。

提示词：

请根据当前 iOS 项目，帮我列出第一版真机测试清单。重点检查本地数据、页面跳转、权限和异常状态。

41.6 上架前不要忽略规则

如果只是本地练习，不需要马上上架。

如果要上架 App Store，需要考虑：

• 应用名称和描述。
• 隐私政策。
• 数据收集说明。
• 登录和账号删除。
• 内购和订阅规则。
• 权限用途说明。
• 崩溃和性能。
• 审核截图和演示账号。

这些规则会变化。

所以上架前，不要只看旧教程。

让 Codex 查最新官方文档和审核指南，再生成检查清单。

41.7 本章小结

• iOS APP 比网页和小程序更接近完整产品，开发和发布成本更高。
• 第一版一定要小，先跑通一个核心流程。
• Codex 可以帮你写文档、代码、测试和排查报错，但真实运行需要 Xcode、模拟器或真机。
• 涉及相机、定位、通知等系统能力时，必须真机测试。
• 上架前要查最新 App Store 规则，不要只依赖旧教程。

下一章我们进入硬件世界：用 ESP32 做一个 AI 硬件功能开发案例。

第42章 AI 硬件功能开发——以 ESP32 开发板为例

42.0 本章你会学到什么

学完这一章，你会知道：

• ESP32 是什么。
• AI 硬件项目和纯软件项目有什么不同。
• 第一版 AI 硬件功能应该怎么设计。
• 用 Codex 开发硬件时，如何避免盲目烧录和乱接线。

这一章只做入门定位，不要求你马上懂电路。

42.1 ESP32 是什么

ESP32 是一类常见的微控制器开发板。

你可以先把它理解成：

一块便宜、常见、能联网、能接传感器的小电脑。

它常用于：

• 物联网设备。
• 传感器采集。
• 智能家居。
• 简单语音设备。
• 屏幕显示。
• 蓝牙/Wi-Fi 控制。
• 原型验证。

它不是用来直接跑大型 AI 模型的电脑。

更常见的做法是：

• ESP32 负责采集输入和控制硬件。
• 云端或本地电脑负责 AI 推理。
• ESP32 接收结果并执行动作。

42.2 AI 硬件项目和软件项目的区别

软件项目错了，大多是页面报错、测试失败、文件不对。

硬件项目错了，可能是：

• 接线不对。
• 电压不对。
• 串口选错。
• 驱动没装。
• 供电不足。
• 引脚冲突。
• 板子型号不一致。
• 传感器坏了。

所以硬件项目不能只看代码。

必须同时检查：

• 硬件型号。
• 接线图。
• 供电方式。
• 开发环境。
• 串口日志。
• 固件版本。
• 真实设备反馈。

这就是硬件开发比软件更需要耐心的地方。

42.3 第一版项目怎么选

新手不要一上来做"AI 语音机器人"。

可以先做一个小闭环：

案例：AI 情绪灯

输入：

• 用户在网页或手机上输入一句话。

AI 处理：

• 判断这句话的情绪：开心、平静、紧张、愤怒。

硬件输出：

• ESP32 控制 RGB 灯显示不同颜色。

第一版做：

• ESP32 连接 Wi-Fi。
• ESP32 接收一个简单指令。
• 根据指令控制灯光颜色。
• AI 判断部分先放在电脑或后端。

第一版不做：

• 语音识别。
• 离线大模型。
• 复杂屏幕 UI。
• 电池供电优化。
• 外壳设计。

先把"AI 结果控制硬件"跑通。

42.4 项目结构怎么设计

可以拆成三部分：

ai-hardware-demo/
├── firmware/      # ESP32 固件代码
├── server/        # 后端或本地控制服务
├── web/           # 简单网页控制台
├── README.md
├── DESIGN.md
└── PLAN.md

每部分负责：

第一版也可以不要 web/，直接用命令行发请求。

越简单越容易排查。

42.5 先写硬件检查清单

让 Codex 写代码前，先让它写检查清单：

我想用 ESP32 做一个 AI 情绪灯。
请先不要写代码。
请帮我列出硬件检查清单：
1. 需要哪些硬件。
2. 每个硬件的作用。
3. 接线注意事项。
4. 供电注意事项。
5. 烧录前要确认什么。
6. 串口日志应该看什么。

硬件项目里，检查清单比代码更先行。

因为很多问题根本不是代码问题。

42.6 调试时先分层

如果灯不亮，不要直接让 Codex 改一堆代码。

按层排查：

1. 供电层：板子是否通电，灯是否接对。
2. 烧录层：固件是否成功烧录。
3. 串口层：串口日志是否输出。
4. 网络层：Wi-Fi 是否连接。
5. 通信层：后端能否发指令。
6. 硬件层：引脚是否正确控制灯。
7. AI 层：情绪分类结果是否合理。

提示词：

ESP32 灯没有反应。请不要直接改代码，先按供电、烧录、串口、网络、通信、引脚、AI 结果分层排查，并告诉我每一步要看什么证据。

这就是系统调试思路在硬件项目里的应用。

42.7 安全注意事项

硬件项目一定要注意安全：

• 不确定电压时不要接。
• 不要让开发板承受超过规格的电流。
• 不要短接电源。
• 接线前先断电。
• 电池、继电器、电机等高风险部件要更谨慎。
• 不懂强电就不要碰市电。

本教程只建议做低压、安全、入门级原型。

涉及电机、大功率灯带、继电器、家电控制时，一定要找懂硬件的人确认。

AI 能帮你查思路，但不能替你承担物理风险。

42.8 本章小结

• ESP32 是常见联网微控制器，适合做 AI 硬件原型。
• AI 硬件项目通常由硬件、后端、网页或控制端组成。
• 第一版先做小闭环，比如 AI 结果控制 RGB 灯。
• 硬件项目要先写检查清单，再写代码。
• 调试要按供电、烧录、串口、网络、通信、引脚、AI 结果分层排查。
• 硬件有物理风险，低压入门项目也要注意接线和供电安全。

到这里，第六部分结束。

你已经看完了 7 个编程项目实战方向：从零搭建项目、文件数据清洗工具、智能体对话平台、数字人口播视频工具、小程序、iOS APP 和 ESP32 硬件功能开发。

下一部分进入高级技巧：Agent 蜂群写作、Worktree 多分支并行、多 AI 工具协作、成熟项目架构模板复用，以及常见踩坑与能力边界。

第七部分：高级技巧

前面六部分已经覆盖了从入门到项目实战的完整路线。

第七部分讲的是更进阶的用法。

这些技巧不是新手第一天必须掌握的，但当你开始做长文档、大项目、多工具协作时，它们会非常有用：

• 多 Agent 分工写作。
• 用 Worktree 做并行开发。
• 让设计工具、AI 编程工具、浏览器验证配合起来。
• 复用成熟项目架构。
• 识别 Codex 的能力边界和常见坑。

这一部分的核心不是"更炫"，而是"更稳"。

当任务变大，真正重要的不是让 Codex 跑得更快，而是让它有边界、有分工、有验证、有回滚。

第43章 Agent 蜂群写作

43.0 本章你会学到什么

学完这一章，你会知道：

• 什么是多 Agent 写作。
• 它适合哪些任务，不适合哪些任务。
• 如何把长文档拆给不同 Agent。
• 为什么最后必须有统一主编。

这一章适合写长教程、研究报告、知识库、课程大纲和项目文档的人。

43.1 什么是 Agent 蜂群写作

Agent 蜂群写作，可以简单理解成：

让多个 AI 助手分工处理同一个大写作任务。

比如要写一本长教程，可以拆成：

• 一个 Agent 负责目录和结构。
• 一个 Agent 负责资料整理。
• 一个 Agent 负责章节草稿。
• 一个 Agent 负责案例补充。
• 一个 Agent 负责错别字和格式检查。
• 一个 Agent 负责最终统稿。

这听起来很高效，但也有风险。

如果没有主线，多个 Agent 写出来的内容会变成：

• 风格不一致。
• 章节重复。
• 观点打架。
• 术语不统一。
• 质量忽高忽低。

所以多 Agent 写作不是简单"多开几个会话"。

它更像一个编辑部，需要分工，也需要主编。

43.2 适合多 Agent 的任务

适合：

• 长教程。
• 行业研究报告。
• 多章节课程。
• 大型知识库整理。
• 多来源资料归纳。
• 多角度方案比较。

不适合：

• 很短的文章。
• 观点需要高度统一的短文案。
• 还没想清楚方向的任务。
• 事实非常敏感、必须单一来源确认的内容。

判断标准：

如果任务能自然拆成几个互不干扰的部分，就适合多 Agent。

比如"写第 1 章、第 2 章、第 3 章"可以拆。

"把这一段话润色得更自然"就没必要拆。

43.3 分工前先写总纲

多 Agent 写作前，一定先写总纲。

总纲至少包含：

• 目标读者。
• 文风。
• 章节结构。
• 每章固定格式。
• 禁止事项。
• 术语表。
• 引用规则。
• 交付格式。

比如：

# 写作总纲

目标读者：零基础 Codex 新手。
文风：口语化，少术语，先讲用途，再讲步骤。
章节结构：学习目标、正文、常见误区、本章小结。
禁止事项：不编造工具功能，不写死易过期规则。
术语规则：第一次出现英文术语时，用一句话解释。

没有总纲就开工，多 Agent 只会把混乱放大。

43.4 怎么拆任务

拆任务时，尽量让每个 Agent 只负责一件事。

不好的分工：

Agent A：帮我把这本教程写好。
Agent B：帮我也写一点。
Agent C：你看看还缺什么。

好的分工：

Agent A：只负责第 1-3 章草稿，按总纲写。
Agent B：只负责第 4-6 章草稿，按总纲写。
Agent C：只负责检查所有章节术语是否统一。
Agent D：只负责找重复内容和结构断裂。

任务越具体，输出越可控。

如果是 Codex 里使用子 Agent，也要注意：只有当任务真的独立、能并行推进时，才适合分派。

43.5 最后必须有主编

多 Agent 写作最关键的一步，是统一。

最后一定要有一个主编角色做这些事：

• 合并内容。
• 删除重复。
• 统一语气。
• 统一术语。
• 检查章节顺序。
• 检查目录状态。
• 检查事实是否需要来源。
• 检查是否有前后矛盾。

提示词：

请担任主编，统一下面多位 Agent 产出的章节。
要求：
1. 不新增新观点，先解决重复和冲突。
2. 统一小白友好文风。
3. 统一章节结构。
4. 标出事实不确定或需要查证的地方。
5. 输出合并后的版本和修改摘要。

多 Agent 写作的质量，不取决于写得最多的 Agent，而取决于最后统稿是否认真。

43.6 常见坑

坑一：分工太模糊

每个 Agent 都写一点，最后没人负责整体。

坑二：没有统一术语

同一个东西，一会儿叫 Agent，一会儿叫智能体，一会儿叫 AI 助手。

坑三：没有事实检查

多个 Agent 都在写，错误也会被复制和放大。

坑四：没有最终主编

拼接出来的内容看似很多，读起来却像碎片。

所以多 Agent 写作的核心不是"多"，而是"分工清楚、统一收口"。

43.7 本章小结

• 多 Agent 写作适合长文档、研究报告、课程和知识库。
• 开工前必须有总纲，明确读者、文风、结构和禁区。
• 每个 Agent 只负责一个清楚任务。
• 最后必须由主编统一内容、风格、术语和事实边界。
• 多 Agent 能提高速度，但不能替代统稿和审校。

下一章我们讲 Worktree：当多个开发任务要并行推进时，如何让它们互不干扰。

第44章 Worktree：多分支并行开发

44.0 本章你会学到什么

学完这一章，你会知道：

• Worktree 是什么。
• 它和普通 Git 分支有什么区别。
• 为什么它适合 Codex 多任务并行。
• 新手使用 Worktree 时要注意哪些安全边界。

这一章适合已经开始用 Git 管理项目的人。

44.1 Worktree 是什么

Git worktree 可以理解成：

同一个 Git 仓库，打开多个独立工作目录。

普通 Git 分支是在同一个目录里切来切去。

Worktree 则是让不同分支同时存在于不同文件夹里。

比如：

my-project/
worktrees/
├── feature-login/
├── fix-chart-bug/
└── docs-update/

每个目录都像一个独立项目，可以分别打开、运行、修改。

这样你就不用在同一个目录里反复切分支。

44.2 为什么 Codex 适合配合 Worktree

Codex 做项目时，经常会出现多个任务：

• 修一个 bug。
• 补一个功能。
• 改一份文档。
• 重构一段代码。
• 做一次实验性尝试。

如果都在同一个目录里做，容易互相影响。

Worktree 的好处是：

• 每个任务一个独立目录。
• 不同分支互不干扰。
• 实验失败可以直接丢掉对应目录。
• 多个 Codex 会话可以分别处理不同任务。
• 适合并行开发和并行验证。

它特别适合高级用法：让不同 Agent 或不同会话处理不同任务，再由你统一合并。

44.3 Worktree 和普通分支的区别

普通分支够用时，不一定要用 Worktree。

当你发现自己频繁切分支、多个任务互相打架时，再上 Worktree。

44.4 一个典型流程

假设你要同时做两个任务：

• feature-export
• fix-mobile-layout

可以创建两个 worktree：

git worktree add worktrees/feature-export -b feature-export
git worktree add worktrees/fix-mobile-layout -b fix-mobile-layout

然后分别进入：

cd worktrees/feature-export

或：

cd worktrees/fix-mobile-layout

每个目录独立运行、独立测试、独立提交。

做完后再回主项目合并。

44.5 新手安全规则

使用 Worktree 时注意：

• 确认项目是 Git 仓库。
• Worktree 目录最好放在 .worktrees/ 或 worktrees/。
• 确认 worktree 目录不会被误提交。
• 每个 worktree 对应一个清楚任务。
• 不要在多个 worktree 里改同一批文件。
• 合并前先跑测试。
• 不确定时先看 git status。

特别重要的一点：

Worktree 是为了隔离任务，不是为了逃避提交和测试。

每个 worktree 里仍然要保持清晰提交记录。

44.6 和 Codex 配合的提示词

我想用 Git worktree 并行处理这个项目。

请先检查当前目录是否是 Git 仓库。
然后帮我设计 worktree 方案：
1. 每个任务对应哪个分支。
2. 每个 worktree 放在哪里。
3. 哪些文件可能冲突。
4. 每个任务完成后如何测试。
5. 合并前检查清单。

先给方案，不要直接创建。

如果你已经熟悉，可以再让 Codex 执行创建。

新手阶段，先看方案更稳。

44.7 本章小结

• Worktree 让同一个 Git 仓库拥有多个独立工作目录。
• 它适合多任务并行、实验分支和多个会话协作。
• 普通分支够用时不必强上 Worktree。
• Worktree 目录要管理好，避免误提交。
• 每个 worktree 仍然要跑测试、做提交、按流程合并。

下一章我们讲多 AI 工具协作：Codex、Stitch、设计工具、浏览器验证如何一起工作。

第45章 多 AI 工具协作：Stitch、前端设计与外部工具配合

45.0 本章你会学到什么

学完这一章，你会知道：

• 为什么一个项目可以让多个 AI 工具各做擅长的部分。
• Stitch 这类 AI 设计工具适合放在哪个环节。
• Codex、设计工具和浏览器验证如何配合。
• 多工具协作最容易出什么问题。

这一章的核心是：不要指望一个工具包办所有事情。

45.1 为什么需要多工具协作

Codex 很适合：

• 读项目。
• 写代码。
• 改文件。
• 跑测试。
• 查日志。
• 生成文档。

但在某些任务里，外部工具更擅长第一步。

比如：

• UI 视觉探索。
• 多个界面方案对比。
• 快速生成设计稿。
• 生成图像素材。
• 做 PPT。
• 做表格模型。

这时最好的方式不是硬让 Codex 包办，而是让不同工具接力。

比如：

Stitch 生成 UI 方向
  ↓
Codex 落地成前端代码
  ↓
浏览器验证真实页面
  ↓
Codex 根据截图修正

每个工具都做自己擅长的事。

45.2 Stitch 放在哪个环节

Stitch 是 Google Labs 的 AI UI 设计工具，公开定位是帮助用户用自然语言快速生成、迭代和协作高保真 UI。

你可以把它放在"设计探索"阶段。

适合：

• 快速生成多个页面方向。
• 从自然语言得到界面草案。
• 做移动端或网页 UI 概念。
• 和团队讨论视觉方向。
• 给 Codex 提供更明确的实现参考。

不适合直接当成最终产品代码。

它生成的设计和代码，仍然需要：

• 设计检查。
• 响应式调整。
• 可访问性检查。
• 真实数据适配。
• 工程重构。
• 浏览器验证。

所以 Stitch 更像"前期设计加速器"，不是"最终工程交付器"。

45.3 一个多工具协作流程

以做一个数据看板为例：

1. 先用 Codex 写需求

输出 PRD.md 和页面信息架构。

1. 用 Stitch 或设计工具探索界面

生成 2 到 3 个 UI 方向。

1. 选定一个方向

记录颜色、布局、组件和交互。

1. 让 Codex 实现前端

根据设计参考生成代码。

1. 用浏览器验证

检查桌面端、移动端、真实数据、交互状态。

1. 回到 Codex 修正

根据截图和问题清单迭代。

1. 形成设计规则

把颜色、字体、间距、组件规则写进 DESIGN.md 或 AGENTS.md。

这个流程比"直接让 Codex 做个好看的页面"稳定得多。

45.4 给设计工具的提示词

请设计一个网页数据看板界面。

目标用户：运营负责人
核心任务：快速查看本周关键指标、趋势和风险
页面包含：
1. 顶部关键指标卡片
2. 趋势图区域
3. 渠道表现表格
4. 风险提醒区域

风格要求：
- 专业、清爽、信息密度适中
- 不要营销落地页风格
- 适合桌面端管理后台
- 预留移动端适配思路

注意，不要只说"现代、好看"。

要说目标用户、核心任务、模块和风格禁区。

45.5 给 Codex 的落地提示词

拿到设计方向后，可以这样给 Codex：

请根据这个设计参考实现前端页面。

要求：
1. 保留页面信息架构，不要擅自删模块。
2. 使用项目现有技术栈。
3. 把颜色、间距、字体规则整理到 DESIGN.md。
4. 先实现静态页面和示例数据。
5. 实现后用浏览器检查桌面端和移动端。
6. 如果设计稿里有不适合工程实现的地方，先说明取舍。

Codex 最擅长的是把设计约束变成工程文件。

你给它的设计参考越具体，落地越稳定。

45.6 多工具协作的常见坑

坑一：设计稿和真实数据不匹配

设计稿里只有短文字，真实数据一长就溢出。

坑二：工具之间上下文断裂

Stitch 生成的风格没有写进 DESIGN.md，Codex 下一轮就忘了。

坑三：直接复制生成代码

设计工具导出的代码不一定适合项目结构，要让 Codex 重构进现有工程。

坑四：不做浏览器验证

看起来像实现了，但真实页面有遮挡、溢出、移动端错位。

所以多工具协作的关键不是工具多，而是交接清楚。

45.7 本章小结

• 多 AI 工具协作的核心是让每个工具做擅长的事。
• Stitch 适合设计探索和界面方向生成，不应直接替代工程实现。
• Codex 适合把设计参考落地到项目代码，并通过浏览器验证。
• 设计规则要沉淀进 DESIGN.md 或 AGENTS.md，避免上下文断裂。
• 最终效果必须用真实数据和浏览器检查。

下一章我们讲成熟项目架构模板复用：如何少走弯路，站在已有项目结构上做新项目。

第46章 成熟项目架构模板复用

46.0 本章你会学到什么

学完这一章，你会知道：

• 什么是项目架构模板。
• 为什么复用成熟模板比从零搭更稳。
• 复用模板时要保留什么、删除什么。
• 如何让 Codex 帮你把模板改成新项目。

这一章适合已经做过几个小项目，想提高起步速度的人。

46.1 什么是成熟项目架构模板

成熟项目架构模板不是简单复制旧项目。

它是一套已经跑通过的项目骨架，通常包含：

• 目录结构。
• 技术栈。
• 基础配置。
• 代码规范。
• 测试框架。
• 构建命令。
• README。
• 示例页面。
• 部署配置。
• 常见工具封装。

比如你已经有一个跑通的 React 管理后台项目。

下次再做类似后台，就不用从零搭。

可以把它整理成模板：

admin-template/
├── src/
├── tests/
├── README.md
├── AGENTS.md
├── package.json
└── ...

新项目从模板开始，会比从空文件夹开始稳很多。

46.2 什么时候适合用模板

适合：

• 多个项目技术栈相似。
• 页面结构相似。
• 部署方式相似。
• 团队有固定规范。
• 你已经验证过这套结构能跑。

不适合：

• 新项目需求完全不同。
• 旧项目本身很乱。
• 模板里有大量业务耦合。
• 你还没理解模板结构。

如果旧项目是乱的，复制只会复制混乱。

模板复用的前提是：这个模板值得复用。

46.3 复用前先做模板清理

把旧项目变成模板前，先清理：

• 删除真实用户数据。
• 删除 API Key 和凭证。
• 删除客户名称和敏感信息。
• 删除无关业务页面。
• 保留通用组件和配置。
• 保留测试和运行脚本。
• 更新 README。
• 写清模板适用范围。

最重要的是敏感信息。

不要把旧项目里的 .env、token、客户数据复制到新项目。

提示词：

请检查这个旧项目是否适合整理成模板。
重点检查：
1. 是否包含敏感信息。
2. 哪些目录可以保留。
3. 哪些业务代码应该删除。
4. 哪些配置需要改成示例。
5. 模板适合什么类型的新项目。

46.4 新项目如何基于模板启动

流程：

1. 复制模板到新目录。
2. 修改项目名称。
3. 删除旧业务内容。
4. 更新 README、PRD、DESIGN、PLAN、AGENTS.md。
5. 安装依赖。
6. 跑测试。
7. 启动本地服务。
8. 用浏览器检查基础页面。

提示词：

我想基于这个模板创建一个新项目。

新项目名称：
目标用户：
第一版功能：
第一版不做：

请先检查模板结构，然后生成改造计划。
要求：
1. 列出要保留的文件。
2. 列出要删除或替换的业务内容。
3. 列出要更新的配置。
4. 给出验证命令。
5. 不要直接删除文件，先给我确认。

模板复用也要先计划，再动手。

46.5 模板里应该放 AGENTS.md

一个好模板应该自带 AGENTS.md。

它可以写：

• 技术栈。
• 目录约定。
• 组件规范。
• 测试命令。
• 样式规则。
• 不要动的文件。
• 新项目初始化步骤。

这样每次基于模板开新项目，Codex 都能快速理解这套结构。

示例：

# AGENTS.md

## 模板说明

这是一个后台管理页面模板，适合数据看板、运营工具和内部管理系统。

## 规则

- 新业务页面放在 `src/pages/`。
- 通用组件放在 `src/components/`。
- 不要修改构建配置，除非任务明确要求。
- 每次新增页面后运行 `npm test`。

模板不是只有代码，协作规则也要一起复用。

46.6 复用模板的常见坑

坑一：把旧业务也复制过去

新项目里出现旧客户、旧接口、旧文案，非常危险。

坑二：模板太重

一堆新项目用不到的功能，反而拖慢理解。

坑三：依赖过期

模板放太久，依赖和构建工具可能过期。

坑四：没跑基线测试

模板本身都跑不起来，就别拿来开新项目。

所以模板要定期维护。

一个好模板，也是一项长期资产。

46.7 本章小结

• 成熟模板是跑通过、清理过、可复用的项目骨架。
• 复用模板比从零搭更稳，但前提是模板本身质量好。
• 复用前必须清理敏感信息和旧业务内容。
• 新项目基于模板启动时，要先写改造计划。
• 模板里最好自带 AGENTS.md，把协作规则一起复用。

下一章是全书主章节的最后一章：常见踩坑与能力边界。

第47章 常见踩坑与能力边界

47.0 本章你会学到什么

学完这一章，你会知道：

• Codex 使用中最常见的坑有哪些。
• 哪些问题不是提示词能完全解决的。
• 怎么判断该继续让 Codex 做，还是该停下来确认。
• 如何建立安全、稳定、长期的 AI 协作习惯。

这一章是前面所有内容的收束。

47.1 坑一：需求没说清就开做

最常见。

你说：

帮我做一个好看的页面。

Codex 不知道：

• 给谁用。
• 做什么业务。
• 有哪些内容。
• 用什么风格。
• 哪些功能必须有。
• 哪些不能做。

结果自然容易跑偏。

解决办法：

• 先写目标。
• 再写范围。
• 明确不做什么。
• 给参考。
• 大任务先让 Codex 写计划。

模糊需求不是 AI 的燃料，是跑偏的源头。

47.2 坑二：让 Codex 一口气做太多

比如：

帮我做一个完整 SaaS 平台，包含登录、支付、后台、数据分析、部署。

这类任务太大。

正确做法是拆成阶段：

1. 第一版只做本地原型。
2. 第二版做核心页面。
3. 第三版接数据。
4. 第四版加登录。
5. 第五版再考虑部署。

每个阶段都要有验证标准。

Codex 很能干，但也需要任务边界。

47.3 坑三：不看运行结果

很多新手只看 Codex 说"完成了"。

但真正重要的是：

• 页面是否能打开。
• 命令是否能跑。
• 测试是否通过。
• 文件是否生成。
• 图表是否正确。
• 文档是否能交付。

所以每次完成后都要问：

请说明你如何验证这次修改已经完成，并给出验证结果。

如果是网页，要看浏览器。

如果是代码，要跑测试。

如果是文档，要打开检查。

如果是数据，要核对行数和公式。

47.4 坑四：遇到报错就让它乱改

报错时最怕：

报错了，快修。

Codex 可能会猜。

更好的方式：

请先阅读完整报错，复现问题，定位根因。不要先改代码。先告诉我问题发生在哪一层。

排查顺序：

• 环境。
• 依赖。
• 配置。
• 输入数据。
• 代码逻辑。
• 权限。
• 网络。

先找根因，再修。

这个习惯会帮你避免很多二次问题。

47.5 坑五：把 AI 当成绝对正确

Codex 会犯错。

常见错误包括：

• 记错版本。
• 编造不存在的 API。
• 忽略边界条件。
• 漏看文件。
• 写出能跑但不符合需求的代码。
• 过度自信地总结。

所以你要建立一个默认心态：

Codex 的输出是高质量草稿，不是免检成品。

重要任务必须验证。

涉及法律、医疗、金融、安全、账号权限、生产数据，更要人工确认。

47.6 Codex 的能力边界

Codex 很适合：

• 整理资料。
• 写代码。
• 改文件。
• 查项目结构。
• 生成页面。
• 分析数据。
• 写文档。
• 拆任务。
• 排查报错。

但它不应该替你决定：

• 公司战略。
• 法律责任。
• 医疗诊断。
• 财务投资决策。
• 未授权数据使用。
• 是否发送敏感消息。
• 是否删除生产数据。

AI 可以给建议，但责任仍然在人。

这不是泼冷水，而是让你更安全地使用它。

47.7 一个长期协作清单

每次开始任务前：

• 说清目标。
• 说清范围。
• 说清不做什么。
• 指明相关文件。
• 大任务先写计划。

执行中：

• 分步骤推进。
• 每步有验证。
• 遇到报错先排查。
• 不确定就停下确认。

完成前：

• 跑测试。
• 打开结果。
• 检查文件。
• 对照需求。
• 总结改动。

长期维护：

• 更新 AGENTS.md。
• 更新 PLAN.md。
• 保留关键决策。
• 定期清理 Skill。
• 重要项目使用 Git。

这套清单，比任何一句神奇提示词都重要。

47.8 本章小结

• Codex 最常见的坑，是需求模糊、任务过大、不验证、乱修报错、盲目信任。
• 大任务必须拆，小任务也要有完成标准。
• 遇到报错先找根因，不要直接让 Codex 猜。
• Codex 输出是高质量草稿，重要结果必须验证。
• AI 可以帮你做很多事，但最终判断和责任仍然在人。

到这里，正文 47 章就全部完成了。

你已经从"Codex 是什么"一路走到安装、基础使用、项目文档、Skill、MCP、办公流、业务场景、编程实战和高级协作方法。

最后还剩结语和附录：常用命令速查、术语解释、学习路径与练习建议。它们会帮助你在学完正文后快速复习和继续练习。

结语

如果你一路读到这里，其实已经完成了一次很重要的转变。

刚开始，Codex 可能只是一个陌生工具：

• 不知道它能做什么。
• 不知道该怎么提需求。
• 不知道文件会不会被改坏。
• 不知道报错该怎么办。
• 不知道 Skill、MCP、Agent 这些词到底有什么用。

读到最后，你应该已经能看出来：

Codex 不是一个"帮你写代码的聊天框"。

它更像一个可以参与真实工作的协作者。

你可以让它整理文档、分析数据、生成页面、拆解任务、排查问题、写项目说明、做办公自动化、协助开发小工具，甚至参与完整项目从想法到交付的过程。

但这件事有一个前提：

你要学会和它协作。

会协作，不是会写一句神奇提示词。

会协作是：

• 知道什么时候先说目标。
• 知道什么时候先写计划。
• 知道什么时候该让它读文件。
• 知道什么时候必须验证结果。
• 知道什么时候该停下来问人。
• 知道哪些事情可以交给 AI，哪些责任必须自己拿住。

这本教程从基础讲到进阶，其实一直在重复一个底层方法：

1. 先说清目标。
2. 再定义边界。
3. 把大任务拆小。
4. 让 Codex 按步骤执行。
5. 每一步都验证。
6. 把有效经验沉淀成文档或 Skill。

你不需要一次掌握所有章节。

真正推荐的做法是：读一部分，做一个小练习；再读一部分，再做一个小项目。

AI 工具最怕只看不练。

只要你愿意把一个个小任务真的交给 Codex 做，再认真检查结果，你会很快建立手感。

最后送你一句最重要的话：

不要把 Codex 当答案机器，要把它当协作伙伴。

答案机器只负责回答。

协作伙伴会和你一起拆问题、试方案、改错误、做交付。

你越会组织工作，它越能发挥价值。

希望这本教程能帮你跨过第一道门槛：从"我不会编程"变成"我能用 AI 做出东西"。

接下来，就别只看了。

打开 Codex，建一个文件夹，从一个最小任务开始。

进阶版使用建议

这一版适合在你已经能完成基础任务之后阅读。建议不要从头硬啃，而是按任务选择章节：

• 想扩展工具能力：看第 17-22 章。
• 想做内容和办公自动化：看第 23-35 章。
• 想做完整项目：看第 36-42 章。
• 想提高复杂协作稳定性：看第 43-47 章。

Prompt 模板、故障排查、资料包说明已经拆到《Codex 实战资料包使用手册》。