# AI、Agent与Codex：从理解、执行到判断

## 企业AI培训完整母稿

这场培训不追逐模型新闻，不比较哪一个聊天产品更热，也不要求所有人记住一批技术术语。

整场培训只解决三个问题：

1. AI和Agent到底是怎样工作的；
2. Codex怎样进入真实业务，把要求变成结果；
3. 当Agent越来越能执行，人怎样保留判断力。

三大板块构成一条连续主线：

> 第一板块解决“看懂”；  
> 第二板块解决“做成”；  
> 第三板块解决“做对”。

---

## 全场时间

| 环节 | 时间 | 核心结果 |
|---|---:|---|
| 开场 | 5分钟 | 建立三条主线 |
| 第一大板块：AI基础认知 | 45分钟 | 看懂三层结构、十个概念与常见AI名词 |
| 第二大板块：Codex进入真实业务 | 45分钟 | 看懂界面、执行过程与企业试点 |
| 第三大板块：问、借、辩、行 | 32分钟 | 建立判断、验证与复盘方法 |
| 全场收束 | 5分钟 | 形成完整工作闭环 |
| 合计 | 约132分钟 | 可根据现场讨论压缩到120分钟 |

完成主线和每个板块的关键互动，整场约120至135分钟。企业场景、名词辨认和问借辩行案例全部展开并允许现场讨论时，整场约135分钟；现场时间有限时，可以压缩场景讨论，但不删掉Agent名词地图、Codex界面、任务单和完整判断案例。

---

# 开场：今天不只讲AI，而是讲一种新的工作方式

过去两年，大家接触AI，大多从一个聊天框开始。

我们问一个问题，它给一个答案；我们让它写一段文案，它生成一段文案；我们觉得不满意，再说一句“优化一下”。

这当然有价值，但它只代表AI能力的一小部分。

今天要回答三个更重要的问题。

第一个问题：

> AI为什么能够读懂我们说的话，又为什么有时候会一本正经地说错？

第二个问题：

> 如果AI不只回答，而是能够读取文件、调用软件、修改项目、运行程序和检查结果，会发生什么？

第三个问题：

> 当AI执行得越来越快，人怎样保证它没有在错误方向上高速前进？

这三个问题分别对应今天的三个板块：

> 理解AI → 让Codex执行 → 保留人的判断

【现场互动】

先做一个简单选择：

> 在大家目前的印象里，AI更像什么？

- A. 一个更聪明的搜索框；
- B. 一个能够写内容的聊天助手；
- C. 一个能够进入项目、调用工具并交付结果的执行者；
- D. 一个已经可以独立承担所有判断的数字员工。

前三种能力都真实存在，但D不成立。

AI正在从“提供答案”走向“参与执行”，但目标、证据、权限和最终责任仍然属于人。

---

---

# 第一大板块：AI基础认知——从计算基础到Agent

## 板块目标

这一部分只保留十个理解后续内容必须知道的概念，并按照三层结构展开：

### 第一层：AI怎样处理和生成信息

1. Bit  
2. Token  
3. LLM  
4. Context  
5. Prompt

### 第二层：AI怎样连接外部世界

6. API  
7. Tool  
8. MCP

### 第三层：AI怎样持续完成工作

9. Agent  
10. Agent Skill

十个概念不是十个孤立名词，它们组成了一条完整路径：

> 计算机用Bit保存信息  
> → 模型把文本切成Token  
> → LLM在Context里理解关系  
> → Prompt告诉它当前任务  
> → API、Tool和MCP让它连接外部能力  
> → Agent围绕目标持续行动  
> → Agent Skill把成熟方法保存下来

---

# 第一层：AI怎样处理和生成信息

## 概念一：Bit——计算机世界最小的状态

Bit的英文写作Bit，中文叫“比特”，不是Beat。

一个Bit只有两种状态：

~~~text
0
1
~~~

为什么只有0和1？

因为计算机底层是电子电路。电路最容易稳定区分的是两种状态，例如：

- 有电和没电；
- 高电压和低电压；
- 开和关；
- 真和假。

单个Bit能够表达的信息非常少，但多个Bit组合起来，数量会快速增长。

~~~text
1个Bit：2种组合
2个Bit：4种组合
3个Bit：8种组合
8个Bit：256种组合
~~~

8个Bit通常组成1个Byte，也就是1个字节。

可以把Bit想象成一块只有黑白两面的积木。单独一块积木很简单，但数百万、数十亿块积木组合起来，就能表示文字、图片、声音、视频、3D模型和程序。

例如，十进制数字37046转成二进制，可以写成：

~~~text
37046 = 1001000010110110
~~~

这里不是说“37046的含义就是这串0和1”，而是说计算机最终能够用二进制状态保存和计算这个数字。

Bit解决的是计算机怎样存储和计算信息的问题。

但大语言模型不会把一句话当成无数个0和1直接理解。模型需要一个更适合语言处理的单位，这就是Token。

---

## 概念二：Token——模型处理文字时使用的信息小块

人看到一句话，习惯按照字和词来读。

模型处理文字时，会先经过Tokenizer，也就是分词器，把文字切成一块一块的Token。

例如：

> 我喜欢AI

为了理解过程，可以先把它简化成：

~~~text
[我] [喜欢] [AI]
~~~

但这只是教学示意，不是所有模型都会这样切。

不同模型使用的Tokenizer不同，同一句话可能被切成不同结果：

~~~text
[我] [喜欢] [AI]

或者

[我] [喜] [欢] [A] [I]

或者其他组合
~~~

Token可能是：

- 一个汉字；
- 一个词；
- 英文单词的一部分；
- 标点符号；
- 空格与单词的组合；
- 一段频繁出现的字符。

所以，“一句话有几个字”不等于“这句话就有几个Token”。

【现场竞猜：这句话有几个Token】

屏幕上只出现一句：

> 我喜欢AI

选项：

- A. 3个；
- B. 4个；
- C. 5个；
- D. 现在还不能确定。

答案是D。

“我喜欢AI”可以在教学中简化成三个信息块，但真实Token数量取决于具体Tokenizer。

这道题只留下一个记忆点：

> 字符是人看到的单位，Token是模型切分出来的单位。

### 第一步：切分

原始文字先被Tokenizer切成Token。

~~~text
我喜欢AI
↓
[我] [喜欢] [AI]
~~~

### 第二步：映射成Token ID

模型不能直接拿“喜欢”这两个汉字做数学运算。

每个Token会在当前Tokenizer的词表中找到一个编号，这个编号叫Token ID。

假设某个Tokenizer里：

~~~text
[我]   → 37046
[喜欢] → 9987
[AI]   → 15836
~~~

这些数字只用于说明过程，不代表所有模型里的真实编号。

Token ID更像图书馆的书目编号。

编号37046的意思是：“到当前词表的37046号位置，找到对应Token。”

它不是XYZ坐标，也不表示这个词在空间中的位置。

同一个Token在不同Tokenizer中可能拥有不同编号；同一个编号在不同Tokenizer中也可能代表不同Token。

### 第三步：Token ID变成向量

Token ID只是编号，编号本身没有表达丰富含义。

模型会通过一张学习得到的Embedding表，把Token ID查成一组数字，这组数字叫向量。

为了演示，可以把它写成：

~~~text
Token ID 37046
↓
[0.21, -0.73, 0.08, 1.14, ...]
~~~

真实向量通常有很多维，不是只有三个数字。

向量可以类比成“高维语义空间里的位置”，但它和普通XYZ坐标有两个重要区别：

1. 它可能有几百、几千甚至更多维；
2. 每一维通常不能直接解释成“情绪轴”“动物轴”或者“颜色轴”。

模型学习的是大量数字之间的组合关系。

在使用方式和语境上相近的内容，往往会形成某些接近的表示关系；但这个“接近”不是人手工画出来的，而是训练过程中学出来的。

因此，完整过程不是：

> 汉字直接变成一个空间坐标。

而是：

> 文字先切成Token  
> → Token找到Token ID  
> → Token ID查到向量  
> → 模型对向量进行计算

### Token和Bit是什么关系

Token是模型处理语言的单位，Bit是计算机底层存储和计算的单位。

可以把它们分别理解成：

- Token：模型阅读时使用的“词块”；
- Token ID：词块在词表中的“编号”；
- 向量：模型计算时使用的“内部表示”；
- Bit：这些编号和数字在计算机底层最终使用的二进制状态。

它们不在同一个层级，但彼此相连。

【现场互动】

> Token ID 37046更接近下面哪一种？

- A. 一个三维空间坐标；
- B. 一个词表编号；
- C. 这个词出现了37046次；
- D. 这个词的价格。

正确答案是B。

Token ID像书号，向量才可以粗略类比成高维空间中的位置。

---

## 概念三：LLM——负责理解关系并继续生成的大语言模型

LLM是Large Language Model的缩写，中文叫大语言模型。

“大”主要体现在训练资料、参数规模和计算规模；“语言模型”意味着它学习的是语言和符号之间的统计关系与结构规律。

### 先把几个常见名字和公司对上

| 常见模型家族 | 所属公司 | 先记住什么 |
|---|---|---|
| GPT | OpenAI | GPT是模型家族，ChatGPT是大家更常接触到的产品入口 |
| Claude | Anthropic | Claude既是模型家族名称，也是产品名称 |
| Gemini | Google | Google推出的模型家族，覆盖文字与多模态任务 |
| 豆包 | 字节跳动 | 字节跳动自研的大模型体系，企业服务通常通过火山引擎接入 |
| 通义千问（Qwen） | 阿里巴巴 | 阿里巴巴的模型家族，企业服务通常通过阿里云接入 |

这里先解决“它是谁家的模型”，不急着比较谁更强。产品名称、模型家族名称和某个具体版本并不总是同一个名字，具体能力也会随着版本更新。

资料核对：[OpenAI GPT](https://openai.com/research/)、[Anthropic Claude](https://www.anthropic.com/claude/api)、[Google Gemini](https://ai.google.dev/gemini-api/docs/models)、[火山引擎豆包](https://www.volcengine.com/)、[阿里云通义千问](https://ai.aliyun.com/)。

LLM最底层的生成动作，可以粗略理解为：

> 根据当前已经看到的内容，预测下一个最合适的Token。

例如：

~~~text
今天天气很____
~~~

“好”“冷”“热”“差”都有可能，模型会根据前文计算它们各自的概率，再生成其中一个。

它生成一个Token以后，会把这个Token加入当前内容，再继续预测下一个Token。

~~~text
今
↓
今天
↓
今天天气
↓
今天天气很好
~~~

我们看到的是一段完整回答，模型内部完成的是连续多次Token预测。

### Transformer是什么

多数现代大语言模型以Transformer为核心架构。

LLM和Transformer不是同一个概念：

- Transformer更像发动机结构；
- LLM是使用这种结构、经过大规模训练后形成的完整模型。

Transformer里最重要的机制之一叫Attention，也就是注意力。

它解决的问题是：

> 当前这个Token应该重点参考前文中的哪些内容？

例如：

> 小王把奖杯放进箱子里，因为它太大了。

“它”究竟指奖杯还是箱子，需要结合前后关系判断。

再例如：

> 我去银行办理银行卡。  
> 我坐在河边的银行上。

同样出现“银行”两个字，前后语境不同，含义也不同。模型需要观察句子中其他Token与它的关系。

Attention可以类比成开会时用荧光笔标出最相关的材料。不是所有内容都同等重要，当前问题不同，被重点关注的内容也不同。

### LLM为什么看起来知道很多

训练过程中，模型接触大量语言、代码和其他形式的数据，并不断调整内部参数，使预测结果越来越接近训练目标。

最终形成的不是一本可以逐页翻阅的百科全书，而是一套庞大的关系网络。

这也是为什么大模型会出现两个同时存在的特点：

- 它能够组织出非常完整、非常自然的答案；
- 它生成的内容不天然等于已经验证的事实。

流畅来自语言预测能力，真实需要证据和验证。

一句话记住LLM：

> LLM不是在查找一段固定答案，而是在当前上下文里一步一步生成最可能合理的内容。

---

## 概念四：Context——模型此刻能够看到的全部材料

Context中文通常叫上下文。

可以把Context想象成一张工作桌。

桌面上摆着什么，模型这一次就能参考什么。

这张桌子上可能包括：

- 系统规则；
- 当前问题；
- 前面的对话；
- 上传的文档；
- 表格和图片；
- 搜索结果；
- 工具返回的数据；
- Agent刚刚完成的操作记录。

所以，当我们只看到自己输入了一句：

> 再优化一下。

模型处理的可能不只是这五个字，还可能包括前面几十轮对话、原始材料、上一版结果和工具返回内容。

Context通常以Token计量，但“今天天气很好”到底使用几个Token，不能按照六个汉字直接得出答案。

它取决于：

- 使用哪个Tokenizer；
- 文字怎样被切分；
- 是否带有标点和空格；
- 系统是否同时加入其他信息；
- 前面是否还有历史内容。

### Context不等于长期记忆

Context是“这次工作桌面上有什么”。

长期记忆是“哪些内容被保存，未来还能够重新取回”。

二者可以一起工作，但不是同一件事。

### Context为什么重要

Context太少，模型缺乏必要背景，只能猜。

Context太乱，重要信息会被大量无关材料淹没。

Context太长，处理成本、延迟和干扰都可能上升。

真正有效的做法不是把所有资料一股脑塞进去，而是把完成当前任务真正需要的材料放上桌。

### Context和Token用量

模型处理Context时，这些文字和资料最终都要转成Token。

用户眼里可能只输入了五个字：

> 再优化一下。

模型这一次真正需要处理的内容却可能包括：

~~~text
系统规则
＋前面的对话
＋原始产品资料
＋上一版结果
＋工具返回信息
＋“再优化一下”
~~~

这些共同构成输入部分；模型新生成的回答则形成输出部分。

因此，不能仅根据用户眼前输入了几个字，判断模型实际处理了多少Token。

同一句话放在一个全新对话里，和放在一个已经积累了大量历史材料的对话里，实际处理量可能不同。

不同模型能够容纳的Context容量也不同。可以把它理解成工作桌大小：桌面越大，能同时放的材料越多，但材料越多不代表工作一定越好，关键仍然是相关、清楚和有序。

【现场竞猜：“再优化一下”为什么不一定轻】

问题：

> 用户只输入“再优化一下”五个字，为什么这一轮仍然可能处理很多Token？

- A. 因为“优化”是特殊收费词；
- B. 因为模型可能重新处理前面的对话、文件和上一版结果；
- C. 因为第二次回答自动翻倍；
- D. 因为五个汉字固定等于很多Token。

答案是B。

短Prompt不等于小Context。

一句话记住Context：

> Context不是聊天记录的另一个名字，而是模型当前能够使用的全部工作材料。

---

## 概念五：Prompt——交给模型的当前任务单

Prompt不是一句神秘咒语，也不等于越长越好。

Prompt本质上是当前任务说明。

一张清楚的任务单通常包含六部分：

1. 目标：最终要解决什么问题；
2. 背景：为什么做，面向谁；
3. 输入：可以使用哪些资料；
4. 约束：哪些事情不能做；
5. 输出：需要交付什么形式；
6. 标准：怎样判断完成。

例如：

> 帮我把这张产品图做得更高级。

“高级”藏在说话人的脑子里，模型只能猜。

把它改成：

> 保留产品主体和构图，将画面调整为克制的高端科技风。主色使用深灰与银色，减少装饰元素，增加留白，强化金属材质和柔和侧光。先指出原图三个主要问题，再给出修改方案；确认方向后再生成。产品结构不得改变。

第二个Prompt更容易得到稳定结果，因为目标、视觉标准、执行顺序和禁止事项都被说清楚了。

Prompt不是为了控制模型说漂亮话，而是为了减少猜测。

一句话记住Prompt：

> AI不怕要求高，AI怕标准只存在人的脑子里。

---

## 第一层关系回顾

一段文字进入模型，大致经历下面的过程：

~~~text
人输入文字
↓
Tokenizer切成Token
↓
Token映射成Token ID
↓
Token ID查成向量
↓
Transformer在Context中计算关系
↓
LLM预测下一个Token
↓
连续生成回答
~~~

五个概念各自解决不同问题：

| 概念 | 解决的问题 |
|---|---|
| Bit | 计算机怎样保存和计算信息 |
| Token | 模型怎样切分和计量文字 |
| LLM | 模型怎样理解关系并生成内容 |
| Context | 模型这一次能够参考什么 |
| Prompt | 人这一次要求模型做什么 |

---

# 第二层：AI怎样连接外部世界

只会生成文字的模型像一个坐在房间里、知识很多但没有手脚的人。

它可以告诉我们天气应该去哪里查，却不知道此刻的实时天气；可以说明Blender怎样操作，却不能自动打开本地文件；可以写一份表格结构，却不能凭空读取公司系统里的数据。

要进入外部世界，需要API、Tool和MCP。

---

## 概念六：API——软件之间按照规则办事的服务窗口

API是Application Programming Interface的缩写。

可以把API想象成银行服务窗口。

客户不能直接走进银行金库修改数据，而是按照规定提交请求：

> 我要查询余额。  
> 这是账户。  
> 这是身份信息。

窗口按照规则处理，再返回结果。

软件之间也是这样。

例如，一个系统查询天气：

~~~text
请求：
城市 = 杭州
日期 = 今天

返回：
温度、天气、湿度、风力
~~~

API规定了：

- 可以请求什么；
- 请求要使用什么格式；
- 需要什么身份和权限；
- 系统会返回什么；
- 失败时怎样表示错误。

API不是一个具体按钮，而是一套软件之间沟通和调用的规则。

一句话记住API：

> API是两个软件之间可以按照约定收发任务和结果的服务窗口。

---

## 概念七：Tool——Agent真正能够使用的外部能力

Tool就是工具。

对于Agent来说，Tool不是一个抽象概念，而是它能够实际调用的动作。

例如：

- 读取文件；
- 搜索网页；
- 查询数据库；
- 运行命令；
- 执行Python；
- 修改表格；
- 操作浏览器；
- 调用Blender；
- 发送一条经过授权的消息。

可以把API和Tool的关系理解成：

- API是服务窗口和调用规则；
- Tool是Agent能够拿起来使用的具体能力。

有些Tool通过API实现，有些Tool通过本地命令、脚本或者软件插件实现。

一个计算器可以被包装成Tool；一个天气API也可以被包装成Tool；一个本地Blender脚本同样可以成为Tool。

模型拥有“知道怎样做”的能力，Tool提供“实际动手做”的能力。

一句话记住Tool：

> Tool让AI从会说，变成能够对外部环境采取动作。

---

## 概念八：MCP——让不同工具使用共同接入方式

当Agent需要连接十个系统，如果每个系统都使用完全不同的接法，开发和维护会很复杂。

MCP是Model Context Protocol的缩写。

它可以类比成电脑上的通用接口。

过去，每种设备都有自己的插头；有了统一接口以后，设备仍然不同，但连接方式更一致。

MCP可以把外部能力按照统一方式提供给模型和Agent，例如：

- Tools：可以执行的动作；
- Resources：可以读取的资源；
- Prompts：可以复用的提示模板。

MCP不是把所有软件功能自动变出来，也不会绕过权限。

它解决的是“怎样连接得更标准”，不解决“是否有权连接”和“连接后做什么”。

可以把三者关系记成：

> API是单个系统的服务窗口；  
> Tool是Agent可以调用的具体能力；  
> MCP是把不同工具和资源接入Agent的一种通用协议。

【现场互动】

下面三句话分别对应什么？

1. “系统规定查询库存时要提交产品编号和身份凭证。”  
2. “Agent可以执行查询库存这个动作。”  
3. “库存、文档和项目系统都使用统一方式接入Agent。”

对应答案：

1. API；  
2. Tool；  
3. MCP。

---

# 第三层：AI怎样持续完成工作

模型有了大脑，Tool提供手脚，MCP帮助连接外部能力。

但如果每做一步都要等人重新下达一句命令，它仍然只是一个更强的工具箱。

Agent解决的是“围绕一个目标持续推进”的问题。

---

## 概念九：Agent——拿到目标后持续推进的执行者

Agent中文常被翻译成智能体。

最简单的理解是：

> 聊天AI主要回答问题，Agent围绕目标采取行动。

聊天AI的典型过程：

~~~text
问题 → 回答
~~~

Agent的典型过程：

~~~text
目标
↓
读取环境和资料
↓
制定或者调整计划
↓
调用工具执行
↓
观察结果
↓
检查是否达到目标
↓
未达到则修正
↓
交付
~~~

一个Agent通常包含几个部分：

- 模型：负责理解、推理和选择下一步；
- Context：保存当前任务需要的信息；
- Tool：负责读取、修改和执行；
- 权限：限定它可以进入哪些范围；
- 循环：执行、观察、检查和修正；
- 验收标准：判断什么时候可以结束。

例如，用户提出：

> 把这个文件夹里的产品资料整理成统一表格。

聊天AI可能告诉我们表格应该有哪些列。

Agent可以继续：

1. 读取文件夹；
2. 识别不同文件格式；
3. 提取产品字段；
4. 生成统一表格；
5. 标记缺失信息；
6. 检查重复项；
7. 保存文件并报告结果。

这里最重要的不是“它做了很多步”，而是每一步都服务于同一个目标，并且结果可以被检查。

一句话记住Agent：

> Agent不是回答得更长，而是能够在边界内持续行动，直到形成可验收结果。

【现场辨认：哪一个更接近Agent】

- A. 告诉我们怎样制作一份PPT；
- B. 给出一份PPT大纲；
- C. 创建PPT、检查排版、修改问题并交付文件；
- D. 使用很多专业术语解释PPT。

答案是C。

“告诉我们怎么做”更像顾问；“做出结果、检查结果并交付”更接近Agent。

---

## Agent补充解析一：把Agent拆开，它不是一个模型

这里暂停一下，把“Agent”再拆细一点。

很多人第一次接触AI时，会把模型和Agent理解成两种差不多的产品。更准确的关系是：

> 模型只是Agent的一部分，通常承担理解、推理和生成。

一套可以进入真实工作的Agent，通常由六部分组成：

1. **模型**：负责理解任务、推理和选择下一步；
2. **上下文与记忆**：保存这次任务的材料、规则和过去的工作记录；
3. **工具**：读取、搜索、修改、运行和调用外部系统；
4. **执行循环**：计划、行动、观察、修正，不在第一次生成后停止；
5. **运行环境**：决定它在本地、云端还是长期在线的机器上工作；
6. **权限与验收**：限定可以做什么，并规定出现什么证据才算完成。

可以把它理解成一个岗位，而不是一颗单独的大脑：

- 模型是这个岗位上的大脑；
- 上下文和记忆是工作材料与交接记录；
- Tool是手里的软件、设备和权限；
- 执行循环是工作的基本习惯；
- 运行环境是工位；
- 权限与验收是门禁和质检标准。

如果只有模型，它可以解释怎样整理一份产品表；如果组成Agent，它才可能进入文件夹、读取资料、生成表格、检查缺项并留下结果。

【现场问答】

问：把GPT换成Claude，Agent会不会自动获得长期记忆和24小时工作能力？

答：不会。换模型主要改变“大脑”，长期记忆、工具和运行时间仍然取决于Agent系统的其他部分。

---

## Agent补充解析二：先把AI名词放进六个抽屉

AI名词难记，不是因为每个名词都很复杂，而是公司、模型、产品和Agent经常同时出现在一句话里。

以后听到一个新名字，先放进六个抽屉：

| 抽屉 | 回答的问题 | 常见例子 |
|---|---|---|
| 公司 | 谁研发、运营或提供服务 | OpenAI、Anthropic、Google、字节跳动、阿里巴巴、DeepSeek |
| 通用模型 | 谁负责理解、推理和生成 | GPT、Claude、Gemini、Qwen、DeepSeek |
| 用户产品 | 人真正打开和使用什么 | ChatGPT、Claude、Gemini、豆包、千问 |
| Agent产品 | 谁进入项目并调用工具执行 | Codex、Claude Code、Cursor Agent、Qwen Code |
| 专项模型 | 谁专门生成图片、视频或声音 | Nano Banana、Seedance、Veo、万相 |
| 运行方式 | 它在哪里、以什么方式持续工作 | 本地、云端、后台、长期在线 |

这里有三条非常实用的判断规则：

第一，**公司不能和模型直接比较**。OpenAI是一家公司，Claude是Anthropic的模型与产品品牌，它们不在同一个抽屉里。

第二，**模型不能和App直接画等号**。GPT是模型家族，ChatGPT是用户产品。产品里除了模型，还有界面、账号、搜索、文件和工具。

第三，**专项模型不能和通用Agent直接比较**。Seedance擅长生成视频，Codex擅长进入项目执行，它们解决的问题不同。

现场可以把页面上的六个抽屉依次点开。每点一个，只问大家一句：

> 这个名字回答的是“谁家的”“大脑是谁”“打开什么”“谁来执行”“生成哪种媒体”，还是“在哪里运行”？

---

## Agent补充解析三：沿着公司看产品族

### OpenAI

- 公司：OpenAI；
- 通用模型：GPT；
- 用户产品：ChatGPT；
- Agent产品：Codex；
- 图像能力：GPT Image。

一句话区分：GPT是模型家族，ChatGPT是用户入口，Codex是执行型Agent。

### Anthropic

- 公司：Anthropic；
- 通用模型：Claude；
- 用户产品：Claude；
- Agent产品：Claude Code。

Claude这个词可能同时指模型和用户产品；Claude Code不是另一个大模型，而是使用Claude模型、能够读取代码库和调用工具的代码Agent。

### Google

- 公司：Google；
- 通用模型与用户产品品牌：Gemini；
- 终端Agent：Gemini CLI；
- 图像能力：Nano Banana；
- 视频能力：Veo。

Nano Banana是图像模型能力的昵称，不是聊天App，也不是24小时Agent。

### 字节跳动

- 通用模型：豆包模型、Seed系列；
- 用户产品：豆包；
- Agent搭建平台：Coze，也叫扣子；
- 图像与视频模型：Seedream、Seedance。

豆包不是公司，Seedance不是Agent，Coze也不是Cursor。

### 阿里巴巴

- 通用模型：Qwen，也叫通义千问；
- 用户产品：千问、Qwen Chat；
- 代码Agent：Qwen Code；
- 图像和视频模型：万相、Wan。

“千问”单独出现时，可能指模型家族，也可能指用户产品，要结合语境继续追问。

### DeepSeek

DeepSeek这个名字可能指公司、模型家族，也可能指用户打开的App或网页。DeepSeek模型还可以被接进第三方Agent，成为其中的大脑。

这里要记住：

> 同一个名称可能同时被用于公司、模型或产品；不是每家公司都必须拥有一套独立的Agent产品。

---

## Agent补充解析四：十三个常见名词怎样辨认

| 名称 | 它是什么 | 最容易混淆的地方 |
|---|---|---|
| GPT | OpenAI的通用模型家族 | 不是ChatGPT产品，也不是Codex Agent |
| ChatGPT | OpenAI的用户产品 | 产品背后可以组合模型、搜索、文件与工具 |
| Claude | Anthropic的模型与产品品牌 | 不等于Claude Code |
| Claude Code | Anthropic的代码Agent | 不是一个名叫“Code”的新模型 |
| Gemini | Google的模型与产品品牌 | 与Nano Banana不是同一层 |
| Nano Banana | Google的图像生成与编辑能力 | 不是通用聊天Agent |
| Seedance | 字节Seed的视频生成模型 | 不是豆包，也不是Coze |
| 豆包 | 字节面向用户的AI产品，也会出现在模型服务名称中 | 不是公司名 |
| 千问 / Qwen | 阿里的模型与产品品牌 | 代码Agent另称Qwen Code |
| Coze / 扣子 | Agent与工作流搭建平台 | 不等于Cursor |
| Cursor | Anysphere的AI代码编辑器与Agent产品 | 可以使用不同模型，自己不是一种底层模型 |
| Codex | OpenAI的代码Agent | 不等于GPT，也不等于普通ChatGPT聊天 |
| OpenClaw / 龙虾 | 持续型个人Agent框架 | 模型可更换，它本身不是大模型 |

你提到的“Coser”可能有两种情况：

- 如果指Coze，也就是扣子，它是Agent与工作流搭建平台；
- 如果指Cursor，它是围绕代码项目工作的AI编辑器与Agent产品。

两个名字读起来相近，但一个偏Agent搭建平台，一个偏软件开发环境。

【现场快问快答】

1. “我打开ChatGPT问了一个问题。”ChatGPT属于哪个抽屉？——用户产品。
2. “我用Seedance把图片变成视频。”Seedance属于哪个抽屉？——专项视频模型。
3. “Claude Code进入代码库修改了三个文件。”Claude Code属于哪个抽屉？——Agent产品。
4. “这个Agent把底层模型换成DeepSeek。”DeepSeek在这里扮演什么角色？——Agent的大脑。

---

## Agent补充解析五：项目级Agent和“24小时Agent”

“项目级”和“24小时”不是模型智力等级，而是运行环境、触发方式和持续时间不同。

### 第一种：对话助手

- 触发方式：人主动发消息；
- 持续时间：一次会话；
- 典型任务：问答、写作、文件分析；
- 主要风险：把一段回答误当成已经执行完成。

### 第二种：项目级Agent

- 触发方式：人给出项目目标；
- 持续时间：几分钟到数小时，以交付完成为止；
- 典型产品：Codex、Claude Code、Cursor Agent、Qwen Code；
- 典型动作：读项目、改文件、运行命令、检查结果。

它像一位为了完成当前项目进入现场的执行者。项目完成，这一轮工作结束。

### 第三种：后台Agent

- 触发方式：提交一项云端任务或队列事件；
- 持续时间：窗口关闭以后继续，任务完成后停止；
- 典型任务：批量处理、云端代码任务、长时间渲染与检查。

后台运行不等于长期值守。它只是把这一项任务放到另一个持续可用的环境中完成。

### 第四种：持续型Agent

- 触发方式：新消息、固定时间、文件变化或系统事件；
- 持续时间：系统长期可用，每次按事件执行一轮任务；
- 典型形态：OpenClaw一类个人Agent框架，或者企业的值守Agent。

OpenClaw被一些用户称为“龙虾”。它把可更换的模型接到消息渠道、记忆、工具、定时任务和一台持续运行的机器上。

因此，“24小时Agent”更准确的解释是：

> 系统一直可以被唤醒，不是模型24小时不停思考。

长期在线同时带来更严格的管理要求：账号凭证怎样保存、什么内容可以对外发送、费用怎样控制、误操作怎样暂停、每次行动怎样留日志，都必须提前设计。

【现场辨认】

- 让Codex进入网站项目，修复问题、运行检查并交付：项目级Agent；
- 把一个耗时任务交到云端，稍后回来查看：后台Agent；
- 每天九点自动读取数据并生成异常报告：持续型Agent；
- 打开Claude问“这个方案有什么问题”：对话助手。

这一组概念讲完以后，大家不需要记住所有品牌，只要形成一个固定动作：

> 先判断它属于哪一类，再判断它能否进入当前工作。

核验资料：[Claude Code官方说明](https://code.claude.com/docs/en/how-claude-code-works)、[Cursor Agent官方说明](https://docs.cursor.com/chat/overview)、[Gemini Image / Nano Banana](https://deepmind.google/models/gemini-image/)、[Seedance官方页面](https://seed.bytedance.com/en/seedance)、[OpenClaw项目页面](https://github.com/openclaw/openclaw)。

---

## 概念十：Agent Skill——把成熟做法保存成可复用的工作方法

同一个Agent第一次做一类任务时，可能需要临时摸索。

如果这类任务会反复发生，就不应该每次从零开始。

Agent Skill可以类比成岗位SOP或者专业技能手册。

它告诉Agent：

- 什么时候使用这套方法；
- 开始前检查什么；
- 按照什么顺序执行；
- 使用哪些模板和脚本；
- 哪些情况需要人工确认；
- 怎样检查质量；
- 最终怎样交付。

例如，一套“标准白底产品图”Skill可以包含：

1. 检查模型单位和中心点；
2. 检查车身材质插槽；
3. 使用指定相机角度；
4. 使用统一灯光；
5. 按照颜色批量渲染；
6. 按产品编号和颜色命名；
7. 检查图片数量、尺寸和背景；
8. 异常情况交给3D人员处理。

Tool和Skill的区别是：

- Tool回答“能不能做”；
- Skill回答“这类工作怎样稳定地做好”。

Prompt和Skill的区别是：

- Prompt是这一次的任务单；
- Skill是以后遇到同类任务时反复使用的方法。

Agent和Skill的区别是：

- Agent是执行者；
- Skill是执行者掌握的专业方法。

一句话记住Agent Skill：

> Skill把个人经验从“我会做”，变成团队以后可以重复调用的能力。

【现场思考：你的岗位里藏着什么Skill】

每个人在脑中找一件事情：

> 这件事我做得很好，但很难一次讲清楚，也很难直接交给新人。

继续回答四个问题：

1. 你判断好坏的标准是什么；
2. 你每次都会做哪些步骤；
3. 哪些错误最常见；
4. 做到什么程度才算完成。

这四个答案已经是一套Skill的雏形。

---

## 第一大板块总结：三层、十个概念

| 层级 | 概念 | 一句话记忆 |
|---|---|---|
| 计算基础 | Bit | 计算机底层的0和1 |
| 信息处理 | Token | 模型处理文字时使用的信息块 |
| 模型生成 | LLM | 在上下文中持续预测并生成Token |
| 当前材料 | Context | 模型这次能够看到的全部工作材料 |
| 当前任务 | Prompt | 交给模型的本次任务单 |
| 系统连接 | API | 软件之间按照规则办事的服务窗口 |
| 外部动作 | Tool | Agent可以实际调用的能力 |
| 通用接入 | MCP | 工具和资源接入Agent的一种统一协议 |
| 持续执行 | Agent | 围绕目标持续行动并检查结果 |
| 方法沉淀 | Agent Skill | 可重复使用的专业方法和SOP |

把十个概念连起来：

> Bit组成计算世界；  
> Token把语言变成模型能处理的单位；  
> LLM在Context里根据Prompt理解和生成；  
> API、Tool和MCP让模型连接外部世界；  
> Agent把理解和工具组织成行动；  
> Agent Skill把成熟行动沉淀成团队能力。

第一板块解决了“看懂”。

接下来进入第二板块：不再只看Agent是什么，而是看Codex怎样把这些能力带进真实工作。

---

---

# 第二大板块：从“会回答”到“能交付”——Codex如何进入真实业务

## 板块开场

第一板块里，Agent被定义为“围绕目标持续行动并检查结果的执行者”。

Codex就是一个具体的Agent。

它的核心能力不是陪我们聊得更久，而是在获得资料、工具和权限以后，进入真实项目，创建或者修改实际结果。

这一板块分为三个部分：

1. Codex是什么，它解决什么问题；
2. Codex怎样进入3D视觉生产；
3. Codex还能进入哪些企业工作。

---

# 第一部分：Codex是什么

## 1. 从聊天助手到执行型Agent

过去使用AI，最常见的过程是：

> 我问一个问题，AI给一个答案。

例如：

- 帮我写一段产品文案；
- 帮我分析一下这份数据；
- 帮我想几个活动方案；
- 告诉我这段代码哪里有问题。

这种方式的核心是“回答”。

Codex更接近一个进入工作环境的执行型Agent。它可以在授权范围内：

- 读取文件和文件夹；
- 理解已有资料、规则和模板；
- 把目标拆成步骤；
- 创建或者修改文件；
- 编写并运行程序；
- 调用软件和工具；
- 检查执行结果；
- 发现问题以后继续修改。

所以，Codex和普通聊天AI最大的区别，不一定是它回答得更聪明，而是它能够把要求继续向下执行，最后形成一个可以检查的结果。

OpenAI把Codex定位为coding agent。这里的代码不只用于开发网站和软件，也可以成为处理文件、调用专业软件、分析数据和自动化工作流程的手段。OpenAI公开的Codex应用案例已经覆盖数据处理、自动化、知识工作、内部工具和可复用工作流等方向。[Codex官方应用案例](https://developers.openai.com/codex/use-cases)

---

## 2. Codex界面怎样读

第一次打开Codex，不要只盯着中间的对话框。真正需要看懂的是六个区域：

1. **项目**：Codex当前被允许进入的工作目录或者代码仓库；
2. **任务线程**：一件持续推进的事情，目标、补充资料、修改意见和最终结果都留在这里；
3. **执行计划**：复杂目标被拆成哪些可以检查的步骤，当前推进到哪里；
4. **文件变更**：创建或者修改了哪些文件，具体结果在哪里；
5. **终端与工具输出**：程序是否真的运行、运行到哪里、有没有报错；
6. **授权确认**：网络访问、启动外部软件、删除或者覆盖文件等动作是否需要人批准。

OpenAI官方入门页面展示的基本结构，是左侧保留项目和任务记录，主区域围绕当前线程持续协作。Codex App还可以查看变更、终端和检查结果。[Codex官方入门](https://openai.com/academy/codex-how-to-start/)

现场要强调一句：

> 不能因为Codex说“已经完成”就判断完成。要同时看文件、运行记录和验收结果。

---

## 3. 同一个要求，两种不同结果

假设提出一个要求：

> 把这些产品资料整理一下，生成一份竞品对比表。

聊天AI通常会告诉我们：

- 对比表应该有哪些栏目；
- 应该从哪些角度分析；
- 可以使用什么样的表格结构。

Codex可以继续完成：

1. 打开指定资料文件夹；
2. 读取产品参数和竞品资料；
3. 提取价格、尺寸、功能和卖点；
4. 对齐不同来源的字段；
5. 生成结构统一的表格；
6. 标记缺失或者冲突数据；
7. 保存成指定格式；
8. 检查表格是否完整。

| 聊天AI | Codex |
|---|---|
| 告诉我们怎么做 | 在授权范围内实际去做 |
| 主要输出一段内容 | 可以输出文件、表格、程序和运行结果 |
| 一问一答 | 连续执行多个步骤 |
| 人承担全部操作 | 人负责目标、规则、授权和最终确认 |

前者更像顾问，后者更像执行同事。

---

## 4. Codex的五个核心动作

Codex的工作可以归纳为五个字：

> 读、想、做、跑、查。

### 读

读取文档、表格、图片、项目文件、程序、文件夹结构和历史记录。

Codex不会凭空知道公司内部发生了什么。资料放在哪里、开放哪些权限、提供哪些规则，决定了它能够工作到什么程度。

### 想

把一个较大的目标拆成可以执行的步骤。

例如：

> 把一款儿童电动车制作成红色、蓝色、黑色三套产品图。

真正执行起来包含：找到模型、检查材质、识别车身部件、创建三套颜色、设置灯光和相机、分别渲染、按照规则命名并检查结果。

### 做

创建或者修改真实成果：

- 文档和表格；
- 数据报告；
- 网页和内部小工具；
- 程序代码和自动化脚本；
- 图片、项目文件和任务清单。

判断Codex有没有完成任务，不能只看它说了什么，还要看它交付了什么。

### 跑

生成脚本或者程序以后继续运行，例如运行数据处理程序、批量整理文件、调用Blender、生成产品图或者执行测试。

### 查

检查文件是否生成、数量和尺寸是否正确、命名是否符合规则、程序是否报错、结果是否达到验收标准。

如果发现问题，继续修改并重新运行。

完整过程是：

> 读取资料 → 理解目标 → 拆解任务 → 调用工具 → 执行 → 检查 → 修正 → 交付

---

## 5. 一句要求怎样变成任务单

“帮我把这批产品资料整理一下，顺便把上架内容也做好”仍然只是一句口头要求。复杂任务交给Codex以前，至少写清六件事：

| 项目 | 要回答的问题 | 示例 |
|---|---|---|
| 目标 | 最终要改变什么 | 形成可核对的SKU主表和上架草稿 |
| 材料 | 依据在哪里 | 参数、历史内容、平台字段、品牌词库 |
| 规则 | 哪些不能猜 | 参数冲突标红，缺失项不自行补全 |
| 工具 | 可以动什么 | 只读指定文件夹，可以新建Excel和Word |
| 交付 | 最后要留下什么 | 主表、草稿、缺失清单和处理记录 |
| 验收 | 怎样判断完成 | 字段覆盖、来源可追溯，发布前由运营确认 |

现场记忆法：

> 目标＋材料＋规则＋工具＋交付＋验收。

---

## 6. 什么任务更适合Codex

一项工作越符合下面几个条件，就越值得先交给Codex尝试：

- 经常重复；
- 步骤比较明确；
- 输入资料可以提供；
- 执行规则能够说清；
- 输出结果可以检查；
- 错误可以撤回或者修正；
- 权限范围能够控制。

可以使用一个简单公式：

> 明确目标＋必要资料＋执行规则＋可用工具＋验收标准  
> ＝一个更适合Codex的任务

“帮我把这个产品做得更高级”不容易执行。

把它改成：

> 读取产品文件夹中的模型和参考图；保留现有造型；生成红、蓝、黑三套车身颜色；使用同一机位和灯光；输出三张1600×1600的PNG图片；文件名按照产品编号加颜色命名。

这个任务的目标、输入、约束、输出和验收都更加清楚。

---

## 7. Codex不替人承担最终责任

Codex擅长执行、整理、检查和重复运行，但下面这些判断仍然由人负责：

- 目标是否正确；
- 产品是否值得开发；
- 设计是否符合品牌；
- 画面是否真正有审美；
- 数据是否值得相信；
- 价格和预算是否调整；
- 内容是否合规；
- 结果是否可以对外发布。

更准确的分工是：

> 人负责方向、标准、授权和最终决定；Codex负责把明确的事情做出来。

---

# 第二部分：Codex在3D视觉生产中的应用

## 1. Codex和3D软件是什么关系

Blender、KeyShot和3ds Max像车间里的专业设备。

它们真正负责建模、材质、灯光、渲染和场景处理。

Codex不是另一套3D软件，也不是用来替代这些软件。它更像一个能够看懂任务单、编写操作程序、启动设备并检查结果的执行助手。

一条自然语言要求可以变成：

> 人提出视觉需求  
> → Codex拆解步骤  
> → 生成软件脚本  
> → 调用3D软件执行  
> → 生成图片和工程文件  
> → 检查结果  
> → 发现问题后继续修改

Blender、KeyShot和3ds Max都提供不同形式的脚本或批处理能力，但具体可调用范围取决于软件版本、授权、插件和企业现有环境。[Blender Python API](https://docs.blender.org/api/current/)、[KeyShot脚本说明](https://manual.keyshot.com/manual/scripting-2/scripting-examples/)、[3ds Max Batch说明](https://help.autodesk.com/view/3DSMAX/2025/ENU/?guid=GUID-0968FF0A-5ADD-454D-B8F6-1983E76A4AF9)

---

## 2. 现场演示任务

这次演示使用一辆简化的儿童电动车。

任务要求：

> 创建一辆儿童电动车的产品展示场景，设置统一棚拍灯光和45度相机，分别生成红色、蓝色和黑色三套车身效果，输出渲染图片、Blender工程文件、执行脚本和运行记录。

【现场预测：Codex拿到任务后第一步应该做什么】

- A. 立刻开始渲染；
- B. 先生成一段很完整的说明；
- C. 先查看工作目录、模型、软件环境和输出要求；
- D. 先宣布任务可以完成。

答案是C。

Agent进入真实项目时，第一步不是表演能力，而是看环境、看材料、看权限。

这次演示不比拼模型精细程度，只观察六件事：

1. Codex有没有理解目标；
2. 有没有主动查看文件和环境；
3. 有没有把要求拆成步骤；
4. 有没有生成并调用脚本；
5. 有没有得到真实文件；
6. 有没有检查错误并继续修正。

---

## 3. 演示第一步：先看环境，不急着生成

Codex先确认：

- 当前工作目录在哪里；
- Blender是否可以使用；
- 是否已有模型和参考资料；
- 输出文件夹是否存在；
- 最终需要生成哪些文件；
- 哪些动作允许自动执行。

这一步对应第一板块里的Context和权限。

没有先看环境，Agent就像刚到公司的新员工，还没有看资料就开始工作。

---

## 4. 演示第二步：把一句要求拆成任务

Codex把目标拆成：

1. 创建或者导入模型；
2. 检查产品比例和位置；
3. 创建车身材质；
4. 设置红、蓝、黑三种颜色；
5. 创建地面和棚拍灯光；
6. 设置45度相机；
7. 分别渲染三张图片；
8. 保存Blender工程；
9. 保存脚本和运行记录；
10. 检查文件数量和命名。

这一步不是在写一段更长的回答，而是在把目标转成执行计划。

---

## 5. 演示第三步：生成脚本并调用Blender

Codex把任务步骤转成Blender能够执行的Python脚本。

脚本负责：

- 创建或者调整对象；
- 设置材质颜色；
- 设置相机和灯光；
- 配置渲染参数；
- 保存工程文件；
- 输出渲染图片。

随后，Codex运行脚本，由Blender完成真正的3D处理。

这里可以看到第一板块几个概念的关系：

- Codex是Agent；
- Blender是Tool；
- Blender的脚本接口是软件连接方式；
- Python脚本是具体动作；
- 整套稳定流程可以沉淀成Agent Skill。

---

## 6. 演示第四步：检查而不是宣布完成

脚本运行结束不等于任务结束。

Codex继续检查：

- 三张图片是否全部生成；
- 三种颜色是否正确；
- 相机角度是否一致；
- 输出尺寸是否符合要求；
- 文件名是否符合规则；
- Blender工程是否成功保存；
- 运行过程是否出现报错。

如果缺少一张图片，或者脚本报错，正确动作不是解释“理论上应该成功”，而是回到文件和日志，找到原因，修改后重新运行。

演示真正要证明的是：

> Agent的价值不是第一次永远不出错，而是能够观察结果、发现问题、继续修正，并留下可验收证据。

---

## 7. 演示第五步：增加一次真实修改

第一轮完成以后，追加一个要求：

> 保留相机、灯光和其他颜色，只把蓝色车身调整为更深的海军蓝，并重新输出对应图片。

这一步观察Codex是否能够：

- 读取上一轮结果；
- 只修改需要改变的部分；
- 保留其他成果；
- 再次运行；
- 检查新图片；
- 报告修改内容。

真实工作很少一次结束。能否在已有项目上继续修改，比单次生成更接近企业使用。

---

## 8. 从Blender演示回到KeyShot和3ds Max

企业不需要为了使用Codex立即放弃现有软件，也不需要把全部工作迁移到Blender。

Blender在现场承担的是“证明完整执行链路”的角色。

真正进入生产时，可以保留现有KeyShot、3ds Max、模型、材质库、模板和专业经验，再把适合自动化的重复动作逐步交给Codex。

### KeyShot方向

- 同一产品批量更换颜色；
- 批量切换标准相机；
- 输出正面、侧面、背面和45度视图；
- 生成统一白底产品图；
- 按不同平台输出尺寸；
- 统一文件命名；
- 生成360度展示素材。

一个产品有六种颜色、四个角度、三个平台尺寸，就可能产生72个输出组合。

如果规则已经明确，脚本负责批量操作，设计师负责最终效果和异常情况。

### 3ds Max方向

- 将不同床、沙发或者户外家具替换进标准场景；
- 自动导入和定位产品模型；
- 检查场景单位；
- 检查缺失贴图；
- 检查对象命名和重复对象；
- 批量创建渲染任务；
- 按产品编号保存结果；
- 对多个场景进行批处理。

这类工作的共同特点是：已有模板、规则稳定、重复次数多、结果可以检查。

---

## 9. 哪些视觉工作仍然需要专业人员

下面这些工作不能简单理解成“写一个脚本就能自动完成”：

- 高要求的商业主视觉；
- 全新的创意场景；
- 复杂产品的材质真实性；
- 灯光氛围和画面情绪；
- 构图和品牌审美；
- 不规范历史模型的异常处理；
- CAD模型与渲染模型之间的复杂转换；
- 最终质量把控。

更合理的分工是：

> 3D设计师确定标准，Codex执行重复操作，设计师处理创意和异常。

过去，设计师的经验可能只存在个人操作习惯里。

以后，这些经验可以逐步变成：

- 标准场景；
- 相机模板；
- 材质规则；
- 对象命名规则；
- 输出规范；
- 自动化脚本；
- Agent Skill。

这不是简单减少操作，而是在把个人经验沉淀成团队生产能力。

---

# 第三部分：Codex在企业其他业务中的应用

3D视觉只是一个容易看见的案例。

企业内部还有大量工作具有相同结构：

- 资料分散在不同文件；
- 多个岗位反复整理相同信息；
- 步骤比较固定；
- 每天或者每周重复；
- 最后需要形成表格、报告或者任务清单。

在资料、权限和工具接入到位的情况下，这些工作同样可以成为Codex的应用场景。

先用六个岗位建立全貌：

| 岗位 | 值得先做的任务 | Codex留下什么 | 必须由人确认什么 | 最小试点 |
|---|---|---|---|---|
| 电商运营 | SKU字段对齐与平台草稿 | 主表、标题卖点、缺失与冲突清单 | 参数、合规、价格、发布 | 20个资料完整的SKU，只生成草稿 |
| 视觉生产 | 标准机位、换色、命名与导出 | 图片、工程、脚本和异常记录 | 审美、材质、主视觉、发布 | 1个模型做3色×4角度 |
| 产品管理 | 规格、BOM与版本一致性 | 版本差异和变更影响清单 | 工程、认证和生效决定 | 核对一个产品的三类核心文档 |
| 销售跟进 | 客户记录与下一步整理 | 客户摘要、行动项和跟进草稿 | 报价、交期、承诺与外发 | 5个活跃客户，只做内部跟进单 |
| 供应链 | 报价、库存与交期异常 | 报价比较和异常清单 | 采购量、付款和供应商选择 | 一类物料的三家报价，只读比较 |
| 内部管理 | 项目、会议与制度资料 | 状态表、责任清单、周报草稿 | 资源、绩效、敏感信息与组织承诺 | 一个进行中项目的一周行动清单 |

每个场景都按同样的五句话讲：输入是什么、Codex执行什么、交付物是什么、人确认什么、第一次只试多大范围。

---

## 1. 产品与竞品资料整理

常见输入：

- 产品参数；
- 竞品页面；
- 价格和功能；
- 用户评论；
- 客服与退货记录。

Codex完成：

- 提取并对齐字段；
- 分类用户评论；
- 统计高频问题；
- 生成竞品对比表；
- 标记缺失和冲突资料；
- 形成初步机会清单。

例如，儿童电动车的评论可能被归纳为：

- 安装困难；
- 电池续航问题；
- 遥控器操作问题；
- 占用空间较大；
- 草地通过能力不足。

Codex负责把信息整理清楚；是否开发新产品、优先解决哪个问题，仍然由业务人员决定。

---

## 2. 产品资料与上架内容

一款产品进入不同平台和部门后，通常需要：

- 产品标题和卖点；
- 详情描述；
- FAQ和安装说明；
- 视觉需求单；
- 视频脚本；
- 客服话术；
- 多语言版本；
- 不同平台字段。

如果每个岗位分别整理，容易出现参数冲突和版本混乱。

更稳定的方式是先建立一份统一产品资料，再生成不同输出：

> 一份产品基础资料  
> → 平台上架内容  
> → 视觉需求  
> → 视频脚本  
> → 客服问答  
> → 多语言版本

Codex同时标记缺失信息，避免在没有依据时自行补全关键参数。

---

## 3. 运营数据与客户反馈

Codex可以：

- 合并不同来源数据；
- 统一字段格式；
- 标记明显异常；
- 分类评论和退货原因；
- 统计问题频率；
- 生成责任部门清单；
- 形成周期报告。

例如，某款床架的退货原因集中在：

- 安装说明不清楚；
- 零件缺失；
- 用户误以为包含床垫；
- 实物颜色与页面展示存在差异。

这些问题可以分别进入产品、包装、详情页、客服和质量管理部门。

Codex负责发现、整理和分发问题；采取什么措施仍然需要负责人确认。

---

## 4. 项目、库存和管理报告

跨部门项目常常涉及产品开发、样品确认、视觉制作、内容上架、物流运输、库存准备和广告投放。

Codex可以：

- 汇总多个项目进度；
- 根据目标日期倒排任务；
- 标记延期节点；
- 识别缺失负责人和日期；
- 整理会议待办；
- 生成周报和管理摘要；
- 对库存和运输数据做基础检查；
- 把销售、广告、退货和物流数据整理到同一份报告。

它不是替负责人管理公司，而是让负责人更快看见：

- 现在进行到哪里；
- 哪些任务已经延迟；
- 哪些资料没有提供；
- 哪些问题需要人做决定。

---

## 5. 企业应用中的三种控制方式

### 绿色：可以直接执行

重复、规则清楚、风险较低：

- 整理文件；
- 统一命名；
- 清洗表格；
- 分类评论；
- 生成固定格式报告；
- 检查资料缺失；
- 生成第一版内容。

### 黄色：Codex处理，人确认后执行

需要业务判断：

- 竞品机会分析；
- 广告调整建议；
- 页面修改建议；
- 补货建议；
- 项目排期调整；
- 产品内容对外发布。

### 红色：必须由人决定

涉及重大风险和责任：

- 是否开发或者停止销售产品；
- 重大采购和预算；
- 产品定价；
- 合规与对外承诺；
- 品牌方向；
- 高风险外部操作。

一句话记住：

> 低风险工作让Codex执行，中风险工作让Codex准备，高风险工作由人决定。

---

## 6. 跨岗位的五种共同工作结构

岗位名称不同，但适合Codex先进入的工作通常属于五种结构：

1. **整理**：把分散资料统一成同一套字段，例如供应商报价对齐；
2. **生成**：基于真资料生成不同格式、平台和语言的第一版；
3. **检查**：按照规则找缺失、冲突、异常和版本不一致；
4. **批处理**：把同一动作作用在一批文件、图片、模型或者数据上；
5. **追踪**：持续查看状态变化，把异常送到正确负责人。

【现场互动】

> 你每周最耗时间的一件事，属于整理、生成、检查、批处理，还是追踪？

---

## 7. 企业试点的四级路径

### 第一级：单次任务

人在场，范围小，资料有限，结果逐项检查。先证明它能不能做出来。

### 第二级：固定模板

把成功任务的输入、规则、步骤和验收写成模板。证明第二次能不能稳定重做。

### 第三级：重复流程

连接固定资料和工具，按批次运行，异常自动转给负责人。证明规模扩大以后是否仍然可靠。

### 第四级：团队Skill

把标准、工具、权限、案例和失败条件沉淀成团队方法。证明换个人以后还能不能复现。

每一级都记录四类证据：节省时间、质量变化、风险位置和能否复现。

---

## 第二大板块总结

Codex最适合解决的，不一定是最有创意的问题，而是企业里大量重复发生、规则相对清楚、结果可以检查的工作。

它带来四个变化：

1. 从“告诉我们怎么做”走向“帮助我们做完”；
2. 把多个零散操作连接成完整流程；
3. 把重复劳动转化成可以反复执行的脚本和Skill；
4. 把个人经验逐步沉淀成团队能力。

但是，执行得快不等于方向正确，表达得顺不等于判断可靠。

当Agent越来越能执行，人就更需要回答下一个问题：

> 怎样保证它执行的是一个值得解决的问题，以及一个经过检查的方向？

这就是第三板块的“问、借、辩、行”。

---

---

# 第三大板块：问、借、辩、行——AI时代的判断力工作法

## 板块开场

第二板块解决的是：

> Codex能不能进入真实工作，把事情做出来？

第三板块解决的是：

> 当Agent执行能力越来越强，人怎样保证它没有在错误方向上高速前进？

导航软件可以找到最快路线，但如果目的地输错了，路线规划得越快，离真正目标越远。

AI也是一样。

它最大的风险不一定是答不出来，而是把一个错误问题回答得非常完整，再把一个未经验证的方案执行得非常迅速。

所以，人在AI时代仍然需要负责四个动作：

> 问清问题，借好视角，让分歧上桌，最后再行动。

---

# 第一部分：为什么AI越强，人越需要判断

## 先看四种常见的判断陷阱

### 1. 顺滑错觉

AI说得很顺，于是我们把语言流畅误认为事实可靠。现场动作：把事实、推断、假设和未知分别标出来。

### 2. 第一答案锚点

第一版答案足够完整，于是后续所有修改都围着它进行，真正不同的方向没有出现。现场动作：让不同视角先独立给方向，再互相看答案。

### 3. 迎合错觉

多个模型都同意我们，于是我们把一致意见误认为得到了验证。现场动作：要求每个席位写出反对理由、证据等级和推翻条件。

### 4. 速度错觉

Agent执行很快，于是我们忘了检查目标和路线。现场动作：高成本执行前，先设计一个能够推翻关键假设的小实验。

危险通常不是完全听不懂，而是答案听起来太合理，让人过早停止检查。

---

## 1. AI说得顺，不等于说得对

当我们给AI一个问题时，它通常会顺着问题里的前提继续回答。

例如：

> 我要给全公司做一次AI培训，帮我设计一套课程。

AI很容易立刻给出课程名称、结构、时间和互动环节。

答案可能很完整，但很多问题还没有确认：

- 为什么要做培训；
- 听众是谁；
- 他们真正遇到什么困难；
- 培训后希望产生什么行为变化；
- 怎样判断培训成功。

如果这些问题没有弄清楚，课程设计越详细，返工成本越高。

一句话概括：

> 问题没有问准，答案越完整越危险。

---

## 2. 两种AI使用方式

### 让AI替自己结束思考

> 提出模糊问题  
> → AI给出顺滑答案  
> → 直接接受  
> → 立即执行

这种方式速度快，但隐藏假设和方向错误会一起进入执行。

### 让AI帮助自己组织思考

> 提出问题  
> → 先审题  
> → 借专业视角检查  
> → 让证据和分歧发生碰撞  
> → 明确风险和最小验证  
> → 最后交给Codex执行

AI不会天然削弱人的思考。

真正影响判断力的，是用它快速结束思考，还是用它暴露问题、检查假设和组织行动。

---

# 第二部分：四步方法总览

| 步骤 | 核心动作 | 解决的问题 | 留下的结果 |
|---|---|---|---|
| 问 | 把问题问准 | 防止一开始就解决错问题 | 问题框架 |
| 借 | 借专业参照系 | 防止只从自己的角度看问题 | 专家视角卡 |
| 辩 | 让证据和分歧上桌 | 防止一味顺从和过早共识 | 分歧与裁决记录 |
| 行 | 把判断转成任务 | 防止讨论很多却没有落地 | 行动单与验收标准 |

最简单的记法：

> 问：这到底是什么问题？  
> 借：谁最懂这个问题？  
> 辩：这个判断最可能错在哪里？  
> 行：下一步怎样用真实结果验证？

这套方法用于方向不清、影响范围较大、存在多种方案、失败成本较高或者需要跨部门协作的问题。

简单查询、低风险修改和已有明确规则的重复任务，不需要每次完整走一遍。

---

# 第三部分：问——先诊断，不急着开药

医生不会在患者刚说“我不舒服”时立即开药，而是继续询问症状、时间、既往情况和检查结果。

“问”就是先做诊断。

## 问目标

- 真正想改变什么；
- 谁会因此采取不同的行动；
- 成功以后能观察到什么变化。

## 问假设

- 默认了什么；
- 哪个前提不成立，整个方案就会失效；
- 哪些是事实，哪些只是判断。

## 问边界

- 时间、资源和权限有哪些限制；
- 哪些事情这次明确不做；
- 哪些风险不能接受。

## 贯穿案例

最初的问题是：

> 我要为公司全员做一场AI与Agent培训。

经过追问以后，变成：

> 我要为公司员工设计一场AI与Agent培训，让大家从“AI只是聊天工具”升级到“AI可以进入工作流程”，理解Agent的基本逻辑，看到Codex操作真实软件和文件的过程，并掌握一套不盲目接受AI答案的判断方法。

这时，目标、对象、内容范围和期望变化都比原来清楚。

## “问”留下的问题框架

~~~text
真正的问题：
目标对象：
当前状态：
期望变化：
成功标准：
已知事实：
关键假设：
限制条件：
明确不做：
仍待确认：
~~~

## 苏格拉底式审题指令

~~~text
暂时不要给我方案。

先通过苏格拉底式追问，帮助我澄清：
真正目标、目标对象、当前问题、期望变化、成功标准、
限制条件、隐藏假设、最大失败风险和明确不做的内容。

每次只问最关键的问题。
信息不足时不要替我假设答案。
最后把结果整理成一份问题框架。
~~~

“问”的核心不是问题越多越好，而是找到那个一旦不成立，整个方向就会倒塌的承重假设。

---

# 第四部分：借——借专业参照系，不借权威背书

一个人站在房间里，只能从自己所在的位置看见一部分。

换到另外几个位置，同一个问题会呈现不同的风险和机会。

“借”不是请AI假装某位大师夸奖方案，而是借用不同专业人员的判断标准，检查自己没有看到的地方。

## 借什么

- 专业框架；
- 判断标准；
- 不同岗位的关注点；
- 反对者的质疑；
- 能够证明我们错的条件。

## 不借什么

- 不借名气替自己背书；
- 不要求AI证明原来的想法正确；
- 不把角色扮演当成真实专家意见；
- 不模仿某位专家的语气；
- 不把没有证据的观点写成事实。

## 借一个真实专家，先核验他为什么值得借

复杂项目里，“请扮演一个世界顶级专家”远远不够。

世界顶级是谁、凭什么顶级、他真正研究过什么、他的框架是否适合当前问题，这些都需要先核验。

真实专家至少满足三个条件：

1. 这个人真实存在，有可以核验的身份；
2. 他在相关问题上有公开研究、著作、项目或者长期实践；
3. 能够找到具体框架和材料，而不只是一个响亮名字。

选择专家的过程分成五步：

### 第一步：先确定要判断什么

同一个项目可能同时包含产品、用户、交付、成本和风险。

不要问“谁最有名”，先问：

> 当前最需要解决的是哪一种专业判断？

### 第二步：寻找真实候选人

查看候选人的：

- 官方任职；
- 公开著作和研究；
- 真实项目经历；
- 与当前问题直接相关的长期工作；
- 可以追溯的公开表达。

### 第三步：说明为什么选他

专家选择不能只写一个名字，还要说明：

- 他判断项目的哪一部分；
- 哪个公开框架与当前问题相关；
- 他的经验可能存在哪些偏向；
- 什么证据会让这个视角改变判断。

### 第四步：只使用公开框架

AI能够根据专家公开发表的研究、著作和方法进行框架化分析，但不能声称：

- “这就是专家本人对本项目的意见”；
- “专家一定支持这个方案”；
- “专家私下会这样判断”。

更准确的说法是：

> 根据这位专家公开的方法和研究，对当前项目进行一次框架化评估。

### 第五步：高风险项目仍由真人确认

涉及法律、医疗、财务、合规、重大投资和关键品牌决策时，AI提供的是前期分析，不替代真人专家的最终审核和签字。

## 贯穿案例：这场培训可以借谁的视角

如果要判断“AI培训是否真正改变员工的工作方式”，可以寻找研究AI、工作和教育的真实专家。

例如，Ethan Mollick是宾夕法尼亚大学沃顿商学院管理学副教授，并参与Generative AI Labs，其公开研究集中在AI对工作、创业和教育的影响。借用他的公开研究框架，重点检查的是：培训有没有让人真正与AI协作、有没有看见能力边界、有没有从知识介绍进入实际练习。[沃顿商学院官方资料](https://mgmt.wharton.upenn.edu/profile/emollick/)

如果要判断“内容是否好记、能否转化成行为”，可以寻找学习设计专家。

Julie Dirksen是学习设计领域的作者和实践者，其《Design for How People Learn》围绕学习者、目标、记忆、注意力、技能、动机和评估展开。借用她的公开框架，重点检查的是：听众是谁、希望形成什么能力、互动是否帮助提取记忆、培训后是否能够真正使用。[Pearson图书资料](https://www.pearson.com/en-us/subject-catalog/p/Dirksen-Design-for-How-People-Learn-2nd-Edition/P200000000217)

这两个人不会因为被写进Prompt就真的参加了项目。

AI做的是基于公开资料进行框架分析，而不是代替他们发表意见。

【现场选择：哪一种才是真正的“借专家”】

### 方式A

~~~text
请扮演世界顶级营销专家，证明我的方案是正确的。
~~~

### 方式B

~~~text
先寻找三位在这个问题上有公开研究或真实项目记录的专家。
列出身份来源、相关著作或框架、适合判断的项目部分和可能偏向。
在我确认专家以后，只根据可核验的公开框架评估项目，
并区分原始观点、事实引用和你的推断。
~~~

答案是B。

A是在借权威感，B才是在借专业参照系。

## 先选视角，再选模型

不要先认定某个模型永远最擅长创意，另一个模型永远最擅长逻辑。

应该先问：这个问题需要哪些判断视角？

通常三个视角已经能够产生有效检查：

- 领域视角：专业上是否成立；
- 用户或者一线视角：真实使用有什么阻力；
- 批判视角：哪个假设最危险，哪里可能失败。

涉及落地时加入交付视角；涉及成本时加入经营视角；涉及敏感信息时加入安全与合规视角。

## 贯穿案例

围绕公司全员AI培训，几个视角分别关注：

- 培训设计者：大家是否听得懂、记得住、能迁移；
- 业务负责人：培训以后是否产生真实行为变化；
- 普通员工：这件事和我的岗位有什么关系；
- 交付负责人：现场演示能否稳定完成；
- 批判审查者：这是否只是产品展示，而没有形成能力。

## “借”留下的专家视角卡

~~~text
真实专家或专业视角：
身份与来源：
公开研究、著作或实践依据：
最关心什么：
判断标准：
核心意见：
依据：
隐藏假设：
失败风险：
需要的证据：
改变判断的条件：
当前内容属于：事实引用 / 框架应用 / AI推断
~~~

## 真实专家选择与视角评估指令

~~~text
基于已经确认的问题框架，先不要直接评估项目。

第一步，寻找三位真实存在、与当前决策直接相关的行业专家。
每位候选人必须列出：
- 姓名和可核验身份；
- 公开研究、著作或者真实项目记录；
- 为什么与当前问题相关；
- 适合判断项目的哪一部分；
- 可能存在的偏向和盲区；
- 资料来源。

不要只按知名度选择。
不要编造身份、著作、观点和引语。

第二步，等待我确认其中一位专家。

第三步，只根据这位专家可以核验的公开框架评估项目，输出：
- 使用了什么公开框架；
- 框架怎样应用到当前项目；
- 当前方案的优势；
- 被忽略的假设；
- 最大风险；
- 需要补充的证据；
- 什么情况会改变判断。

明确区分：
- 专家的公开原始观点；
- 已验证事实；
- 框架在本项目中的应用；
- AI做出的推断；
- 仍然未知的信息。

不要声称这份分析代表专家本人对本项目的真实意见或背书。
~~~

一句话总结：

> 借专家，不是为了证明我对，而是为了发现我哪里可能错。

---

# 第五部分：辩——给方案做一次碰撞测试

汽车正式上路前要做碰撞测试。

碰撞测试不是为了证明汽车完美，而是主动寻找它会在哪里失效。

“辩”就是给方案做一次执行前的碰撞测试。

## 圆桌不是大家轮流说一遍

高质量圆桌包含五个动作：

1. 各个视角先独立给出判断；
2. 把事实、推断、假设和未知分开；
3. 找出会改变方向、范围或者时间的核心分歧；
4. 由明确的挑战者质疑明确的主张；
5. 留下采用、修改、拒绝或者待验证的裁决记录。

如果一个小实验比继续讨论更能增加信息，就应该停止讨论，进入验证。

## 单模型多角色

让同一个模型分别扮演用户、专家和反对者，适合快速预演、补充视角和发现明显问题。

但这些角色共享同一个模型的知识和偏差。

多个角色都同意，不等于得到多份独立证据。

## 不同模型怎样进入圆桌

不同模型确实会呈现不同能力倾向。

但这种差异来自具体模型版本、训练方式、工具配置、上下文和任务类型，不是永远不变的性格。

下面的分工不是模型排行榜，而是一张“选席位的起点”：

| 模型家族 | 当前公开能力与常见使用倾向 | 圆桌中的候选席位 | 使用边界 |
|---|---|---|---|
| GPT | 综合推理、代码、工具调用和结构化任务能力较完整 | 主持人、结构化分析者、行动收口者 | 不因为负责主持就自动拥有最终裁决权 |
| Claude | 长材料阅读、总结、写作、代码和跨文档分析能力突出 | 长文审查者、批判审稿人、风险检查者 | 长上下文仍需要整理重点，材料多不等于判断一定准 |
| Gemini | 原生多模态和长上下文能力突出，适合同时处理文字、图片、音频、视频；创意发散可作为常见试用方向 | 创意探索者、多模态研究员、替代方案提出者 | “更有创意”属于经验性倾向，要用同题测试确认 |
| 豆包 | 中文交互、多模态理解、复杂指令和本地产品语境较强 | 中国市场视角、一线用户代表、本地表达检查者 | 本地语感不能代替真实用户研究和实时市场证据 |
| 千问 | 中文、代码、多模态、Function Calling和企业工具接入较完整 | 中国企业技术视角、交付负责人、工具与数据检查者 | 企业生态适配不等于在所有内容任务上都更优 |

公开能力依据：

- OpenAI当前模型资料强调复杂推理、代码和工具能力，因此GPT适合作为结构化统筹和执行候选，但具体版本仍需按任务选择。[OpenAI模型资料](https://developers.openai.com/api/docs/models)
- Anthropic公开资料列出长文总结、写作、代码和文档分析能力；Claude平台同时强调长上下文需要进行内容整理，材料越多并不自动越准确。[Anthropic使用说明](https://support.anthropic.com/en/articles/7996845-what-are-some-things-i-can-use-claude-for)、[Claude Context说明](https://platform.claude.com/docs/en/build-with-claude/context-windows)
- Google官方资料强调Gemini的原生多模态和长上下文能力，适合同时处理文字、图像、音频和视频；将它放在创意探索席位属于工作流层面的经验性选择，不是官方永久排名。[Gemini Long Context](https://ai.google.dev/gemini-api/docs/long-context)
- 火山引擎公开资料强调豆包的中文、多模态理解、复杂指令与Agent任务能力；“本地语境席位”是基于产品环境形成的应用判断，仍需真实样本验证。[豆包大模型资料](https://developer.volcengine.com/articles/7610285824933445675)
- 阿里云百炼公开资料显示千问系列覆盖中文、视觉、代码、Function Calling和内置工具，可作为中国企业技术与交付席位的候选。[千问视觉与工具能力](https://help.aliyun.com/zh/model-studio/vision-model/)

### 同一个培训项目里的席位分配

围绕“怎样把这场AI培训做得既专业又好记”，可以进行下面的分工：

- GPT：主持上下文，整理问题、标准、分歧和最终行动单；
- Claude：通读完整母稿，寻找重复、矛盾、论证跳跃和过度承诺；
- Gemini：结合文字、图片和未来UI形式，提出三种不同的互动表达；
- 豆包：从中国企业普通员工的语言习惯出发，检查内容是否自然、是否过于技术化；
- 千问：检查中文技术术语、企业工具接入和演示交付是否说得通。

这不是把五个模型叫到一起自由聊天。

每个席位必须拥有不同职责，第一轮独立作答，不能先看到其他模型的结论。

【现场配对：这个任务先找谁试】

1. 阅读一份很长的制度和项目材料，专门寻找矛盾与遗漏；  
2. 同时理解产品图、视频和文字资料，提出三条完全不同的创意路线；  
3. 检查一段培训内容是否符合中国企业员工的自然表达；  
4. 把多方意见整理成一份结构化行动单；  
5. 检查中文技术方案、工具调用和企业落地链路。

一组常见起点是：

1. Claude；  
2. Gemini；  
3. 豆包；  
4. GPT；  
5. 千问。

这道题没有永久标准答案。真正的答案来自同一道任务、同一套标准下的小样测试。

## 真正的多模型圆桌

不同席位由不同外部模型或者真实专家独立作答，并记录实际来源。

它适合重要项目、较高风险判断和需要追溯过程的决策。

即便如此，多模型一致仍然不等于事实。模型数量不能代替证据质量，圆桌不能依靠多数票决定结论。

## 证据分级

| 等级 | 含义 | 例子 |
|---|---|---|
| A | 当前环境直接验证 | 实际运行、真实数据、现场测试 |
| B | 项目或用户直接证据 | 用户反馈、历史记录、样本测试 |
| C | 可信来源或有依据推断 | 官方资料、可靠研究、逻辑分析 |
| D | 尚未支持的假设 | 猜测、角色观点、未验证数字 |

最重要的原则：

> 五个模型都同意一个D级假设，它仍然只是D级假设。

【现场判断：圆桌能不能靠投票】

问题：

> 五个模型里有四个支持方案A，是否说明方案A一定更好？

- A. 是，多数决定；
- B. 不一定，要看证据以及模型是否真正独立；
- C. 是，模型越多越准确；
- D. 只听价格最高的模型。

答案是B。

多个模型可能使用相似公开资料，也可能共享相近偏差。

席位提交的是分析，不是选票。

## 贯穿案例中的分歧

### 概念多一点，还是实操多一点

- 培训设计者认为概念过多会降低记忆；
- 技术视角认为概念太少会误解边界；
- 普通员工更关心这些能力和岗位有什么关系。

裁决：

> 只保留理解后续内容必须知道的十个概念，每个概念使用一个简单例子，再用Codex现场演示把概念串起来。

### 完全现场从零生成，还是展示准备好的结果

- 从零生成更有冲击力，但现场环境不确定；
- 只展示准备结果更稳定，但缺少真实执行感。

裁决：

> 采用半现场方式。提前准备核心模型和备用结果，现场完成一次真实修改、运行、检查和修复。

圆桌的价值不是让所有人同意，而是找到会改变行动的分歧。

## “辩”留下的裁决记录

~~~text
已经确认的事实：
仍然存在的假设：
核心分歧：
被挑战的主张：
挑战结果：
最终采用：
有条件采用：
拒绝：
待验证：
推翻当前结论的条件：
最便宜的下一步验证：
~~~

## 对抗性审查指令

~~~text
基于问题框架和专家视角，组织一次对抗性审查。

第一轮让各个视角独立判断；
第二轮只选择一个会改变方向、范围或者时间的核心分歧；
指定挑战者和被挑战者，要求对方直接回应。

最后区分已验证事实、合理推断、未验证假设和未知信息，
并输出采用、修改、拒绝、待验证、推翻条件和最小验证动作。

不要以角色数量或者多数票决定结论。
~~~

执行前再检查三道门：

- 方向门：解决的是正确问题吗；
- 可行性门：这个机制真的能够成立吗；
- 交付门：当前团队能够在明确范围内做出来吗。

任何一道门没有通过，都不应该用其他两道门的高分掩盖。

【现场判断：什么时候应该停止讨论】

现在有两个选择：

- 继续再问五个模型；
- 用30分钟做一个能够产生真实数据的小实验。

如果更多讨论已经不会改变行动，而小实验能够直接验证关键假设，就应该停止圆桌，进入“行”。

---

# 完整案例：是否建立AI批量产品图流程

这个案例不假设项目已经产生了真实结果，只用来演示四步怎样连成一次决策。

原始提议是：

> 既然AI能做图，我们是不是可以把产品图全部自动化？

这句话把标准图、创意图、质量责任和系统改造混成了一件事。

## 问：重写问题

真实目标不是少用设计师，而是缩短标准白底产品图的制作周期，把设计师时间留给主视觉与异常处理。

- 承重假设：至少一部分产品可以进入稳定模板；
- 暂不讨论：品牌主视觉、创意场景和最终发布；
- 推翻条件：返工抵消节省时间，或者质量达不到平台标准。

## 借：建立判断标准

- 3D流程负责人判断模板和软件链路；
- 电商视觉负责人判断平台质量与品牌一致性；
- 合规与产品负责人判断参数、版权和发布边界。

输出不是一句“专家觉得可行”，而是一张质量、效率和风险三类验收表。

## 辩：暴露核心分歧

核心分歧不是“AI能不能做图”，而是：

> 模板覆盖率是否足以抵消异常处理和返工成本？

支持方提出标准白底图具备模板化条件；挑战方指出历史模型和材质差异可能制造大量返工。双方都需要用30个代表性SKU的人工介入时间回答，而不是继续交换观点。

## 行：两周最小试点

- 选择30个代表性SKU；
- 只处理标准白底图；
- 保留人工复核，不自动发布；
- 不覆盖原工程；
- 记录每张图的总耗时、异常类型、返工次数和最终通过情况；
- 两周后决定扩大、修改、暂停或者放弃。

此时要做的决定，不再是“全公司上不上AI”，而是“是否值得用两周验证一条小流程”。

---

# 第六部分：行——把判断变成Codex能够执行的任务

讨论形成的结论如果没有进入行动单，就像设计图没有交给施工队，仍然不会产生结果。

“行”不是立刻把所有事情全部做完，而是把当前最值得验证的一步，变成有范围、有权限、有交付物、有验收标准的行动。

## 行动前必须明确

- 最终采用哪个方向，为什么；
- 哪些方向没有采用，为什么；
- 哪些内容仍然不确定；
- 第一阶段只验证什么；
- Codex需要创建或者修改什么；
- 本阶段明确不做什么；
- 哪些动作可以自动执行；
- 哪些动作必须人工确认；
- 什么标准代表任务完成；
- 失败时怎样回退或者降级。

## “行”留下的行动单

~~~text
任务名称：

背景：为什么做？
目标：希望产生什么可观察的变化？
目标用户：谁会使用或者受到影响？
已确认事实：哪些内容已经有证据？
关键假设：哪些内容仍需验证？
采用方向：选择什么，为什么？
交付物：必须创建或者修改什么？
范围：本阶段做什么、不做什么？
执行顺序：按照什么步骤推进？
权限边界：哪些动作需要人工确认？
验收标准：怎样证明已经完成？
风险和备用方案：失败时怎样处理？
~~~

## 贯穿案例的最终行动

最初只有一句：

> 帮我做一场AI培训。

经过问、借、辩以后，变成：

> 在当前项目中制作一套公司AI与Agent培训内容，包含三个板块：AI基础认知、Codex实际应用、问借辩行。第一板块解释理解后续内容必须知道的十个概念；第二板块展示Codex读取资料、调用Blender、生成结果并检查的完整过程；第三板块讲清复杂问题如何从审题进入执行。先完成可以现场展示的版本，检查文字、案例、演示链路和备用方案。未经确认不要对外发布。最后报告完成内容、演示方式、验收结果、风险和仍需人工确认的事项。

这时，Codex得到的不再是一句模糊要求，而是一份可以执行、检查和交付的任务。

## 交给Codex的执行指令

~~~text
下面是一份经过问题澄清、专业审查和风险压测形成的行动单。

先检查目标、输入资料、交付物、验收标准、权限和依赖是否完整。
如果缺失信息会改变方向，先指出；如果信息足够：

1. 查看当前项目和资料；
2. 制定最小实施计划；
3. 按计划创建或者修改文件；
4. 运行并检查结果；
5. 发现问题后继续修复；
6. 根据验收标准逐项验证；
7. 报告完成内容、文件、运行方式、验收结果、遗留风险和待确认事项。

不要超出行动单范围。
不要进行未经授权的发布、付款、删除或者外部发送。
~~~

一句话总结：

> 判断没有进入行动单，就还没有真正进入执行。

---

# 行动之后：把证据写回方法

问借辩行不是“想清楚以后一次做对”，而是一条持续更新的闭环：

1. **结果**：实际交付了什么，完成到什么程度；
2. **证据**：时间、质量、错误和人工介入怎样变化；
3. **偏差**：哪些假设错了，问题出在资料、规则还是工具；
4. **决定**：扩大、修改、暂停，还是回到问题层重来；
5. **沉淀**：把有效做法和失败条件写回模板或者Skill。

> 没有复盘的执行，只完成了工作；能把证据写回方法，才形成组织能力。

---

# 第七部分：现场练习——把“提升销售”变成可执行任务

给出一个常见但模糊的问题：

> 帮我提升公司的销售。

## 问

- 提升哪一个指标；
- 当前基线是多少；
- 面向什么产品和客户；
- 当前最大的瓶颈是什么；
- 希望多长时间产生变化。

## 借

- 客户视角最关心什么；
- 运营视角认为瓶颈在哪里；
- 产品视角认为问题来自产品还是表达；
- 财务视角认为增长是否有利润；
- 反对者认为目标哪里最模糊。

## 辩

有人认为问题出在流量，有人认为问题出在转化，有人认为问题出在产品本身。

不能靠投票决定，应该先检查真实数据，找出哪一个环节对结果影响最大。

## 行

不直接执行一套庞大的增长方案，先完成一个最小验证：

> 读取最近四周的流量、广告、转化和退货数据，找出变化最大的环节，标记证据不足的判断，生成一份问题排序表。暂不调整广告和价格，等待负责人确认。

这就是从模糊问题走向可验证行动的过程。

---

## 第三大板块总结

### 问

把问题问准，留下问题框架。

### 借

借专业参照系，留下专家视角卡。

### 辩

让证据和分歧上桌，留下裁决记录和最小验证。

### 行

把判断变成行动单，交给Codex执行和验收。

最后只需要记住四个问题：

> 这到底是什么问题？  
> 谁最懂这个问题？  
> 我们最可能错在哪里？  
> 下一步怎样用真实结果验证？

---

---

# 全场收束：理解、执行、判断

今天完成了三次认知升级。

## 第一次升级：从聊天框到完整系统

过去看到的是一个聊天框。

现在看到的是：

> Bit、Token、LLM、Context、Prompt  
> → API、Tool、MCP  
> → Agent、Agent Skill

模型不是全部，聊天框也不是全部。

真正进入工作的是一套由模型、材料、工具、权限、方法和验收组成的系统。

## 第二次升级：从获得答案到形成交付

过去的要求是：

> 告诉我应该怎么做。

现在的要求是：

> 读取资料，制定计划，调用工具，创建结果，检查问题，完成交付。

Codex体现的是Agent从回答层进入执行层。

## 第三次升级：从依赖答案到组织判断

过去：

> AI给了一个答案，我判断要不要接受。

现在：

> 先把问题问准，借专业视角检查，让证据和分歧上桌，再把裁决转成可执行行动。

AI能力越强，人越不能只做一个“下指令的人”。

人仍然负责：

- 提出值得解决的问题；
- 定义判断标准；
- 区分事实和假设；
- 决定权限和风险；
- 选择是否继续；
- 验收最终结果。

---

# 全场只需要带走的十句话

1. Bit是计算机底层的0和1，Token是模型处理语言的信息块。  
2. Token ID是词表编号，不是空间坐标；向量才是模型内部的高维表示。  
3. LLM在Context中根据已有内容连续预测和生成Token。  
4. Prompt不是咒语，而是一张包含目标、材料、边界和标准的任务单。  
5. API是软件之间的服务窗口，Tool是Agent能够实际调用的能力，MCP提供通用接入方式。  
6. Agent不是回答得更长，而是围绕目标持续执行、观察、检查和修正。  
7. Skill把一次做法沉淀成以后可以重复使用的专业方法。  
8. Codex的价值不是只给方案，而是进入项目并形成可以检查的交付。  
9. 低风险工作让Agent执行，中风险工作让Agent准备，高风险工作由人决定。  
10. Prompt决定一次回答，方法决定长期质量，判断力决定最终方向。

---

# 培训后的第一个行动

每个人从自己的工作中找出一项任务：

- 每周都会发生；
- 至少需要30分钟；
- 步骤相对清楚；
- 结果容易检查；
- 出错可以撤回；
- 不涉及高风险决策。

把这项任务写成：

~~~text
目标：
输入资料：
执行规则：
允许使用的工具：
交付物：
验收标准：
需要人工确认的动作：
~~~

先让Codex完整执行一次。

执行成功，继续标准化；多次稳定，沉淀成Skill；出现问题，记录边界和异常处理。

Agent的能力边界不是靠听介绍听出来的，而是在真实任务中一次一次跑出来的。

---

# 最后一句

> 最好的AI培训，不是让大家记住Agent能做什么，而是让大家亲眼看到：一个想法怎样被理解、被判断、被执行，最后成为真实结果。

---

# 资料依据

- [OpenAI：Token是什么以及如何计算](https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them)
- [OpenAI：Codex应用案例](https://developers.openai.com/codex/use-cases)
- [Blender Python API](https://docs.blender.org/api/current/)
- [KeyShot脚本示例](https://manual.keyshot.com/manual/scripting-2/scripting-examples/)
- [Autodesk 3ds Max Batch](https://help.autodesk.com/view/3DSMAX/2025/ENU/?guid=GUID-0968FF0A-5ADD-454D-B8F6-1983E76A4AF9)