330+ AI 产品经理必须掌握的技能、认知、知识点

• • 本文包含大约330+个 AI 产品化相关的知识点，包括 AI/LLM 基础概念、Workflow / RAG / Agent / Skill 工程概念、AI 产品认知和常见问题

• • 如果你最近在面试、学习 AI 产品，非常适合用来查漏补缺

• • 内容总结自我《AI产品经理转型线下课》两天 ~16 小时授课，按照知识点的类型重新做了分类，部分条目单独阅读可能会有“跳脱感”

• • 本文只列出了线下课提到的知识点，未包含体系化 AI 产品落地方法论和项目实践，需要体系化+项目实践式学习、转型 AI 产品，欢迎报名！

• • 内容总结基于 2026 年 6-9 月的 6 期课程授课内容，部分 AI 产品形态、AI 发展趋势的结论受限于时间可能会有偏颇

学习 AI 底层原理的目的是拿一张缺陷清单，以便在使用和设计 AI 产品时规避

• • 模型训练三阶段总览

• • ◦ 训练语料 → ①预训练 → ②微调（SFT）→ ③RLHF

• • 预训练的本质

• • ◦ 预训练 = 遮住后文猜下一个字，模型记的不是知识条目，而是词与词的关系

• • 语料规模与参数量级

• • ◦ 全球互联网公开资料 ≤10T，训练语料约 1T，1T 参数 ≈ 10T 语料；GPT-5.6 万亿参数、小米万亿参数

• • GPT 词源拆解

• • ◦ G=Generation、P=Pre-training、T=Transformer，三个关键词全是谷歌的，OpenAI 属于摘桃

• • 知识有截止日

• • ◦ 预训练一结束知识就停止增长

• • 模型知识不可枚举

• • ◦ 语料太大、词与词关系无法穷举查看，只有在它输出那一刻我们才知道它知道什么

• • SFT 只教会两件事

• • ◦ 微调喂 QA 对，只教会模型「有问必答」+「回答风格」

• • 微调不增加知识

• • ◦ 微调只改变回答方式与风格，加知识必须靠继续预训练（Continued Pre-training）

• • 词元缺失论证

• • ◦ 若知识点里有模型原有知识中不认识的词，永远微调不成——「它的 token 里压根没有这个 token」

• • RLHF 机制

• • ◦ 人给问题 → 模型回答 → 人打分（9 分/3 分），正儿八经的有监督训练

• • 标注者疲劳与标准漂移

• • ◦ 评判标准从「质量校验」退化为「长度 / 结构 / 排版校验」，模型发现规律后开始迎合

• • 反馈者水平 = 模型能力上限

• • ◦ 模型能力被人类锁死：训练流程最后必须有人反馈，模型「拔着自己的头发拔不起来」；顶级专家如果不参与反馈，知识就永远为人类所有

• • token 与词表

• • ◦ 大模型第一件事是把话切碎；切成什么由训练时定死的词表决定

• • Embedding 维度

• • ◦ 描述一个 token 的维度数：DeepSeek 约 7168 维

• • 语义相似度 = 向量夹角

• • ◦ 夹角越小两 token 越相关；「相关性」在大模型里是纯几何量，不是理解

• • 相似是相对切面的

• • ◦ 「苹果」只在科技切面上接近乔布斯；同一个词在不同上下文会激活完全不同的后续 token

• • 推理 = 转坐标轴找切面

• • ◦ 模型默认「输入一定有意义」，会强行给输入找规律——这也是它容易被垃圾输入带偏的原因

• • 自回归单向

• • ◦ 每个 token 睁眼后只能往前看（狼人杀「天亮请睁眼」），后面人没发言的不能编

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 上下文改写 token 表征

• • ◦ 每个 token 的向量不是固定的，会随「谁在现场」被重新加权/重新投影

• • 注意力机制

• • ◦ 每个 token 只找和自己夹角最小的那一个；注意力的本质是选择性地看，不是全看

• • 多层 Transformer

• • ◦ 多轮「天黑调状态 / 天亮再发言」的迭代，前文的语义会逐级改写后文的语义

• • 输出 = 词表上的概率分布

• • ◦ 「中国的首都是北京」之所以确定，是因为候选出现断崖式 gap（99% vs 0.001%）

• • temperature

• • ◦ 控制从多大概率区间里采样（前 10% 严谨 / 前 70%「创意」）；创意与胡扯是同一个旋钮的两端

• • “一人一个” token 的接力

• • ◦ 自回归一次只生成一个 token，已生成的 token 对后手是既定事实，前人不负责后面

• • 中文字数 ↔ token 换算

• • ◦1 token ≈ 1.5–2 个汉字；14000 字符 ≈ 7000–10000 token

• • 上下文窗口是硬上限

• • ◦ 超出后「最后一个 token 从没见过前面的内容」，所有模型都会崩溃、摆烂、不干活

• • 注意力涣散与漂移

• • ◦ 多个强相关信号同时在场，注意力会被分摊、来回漂移，导致输出不稳定

• • Transformer 只需记一句

• • ◦别管「注意力机制」这个词，只需要知道大模型的注意力是有限度的

• • 生成速度与上下文正相关

• • ◦ 给 100 个字和给 1 万个字，输出下一个 token 的时间不一样；客服场景不能整篇塞

• • 概率性输出没有解

• • ◦ 概率性输出是第二个致命缺陷，影响长程任务全过程，也是幻觉来源之一，只能拥抱

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 幻觉机制 A：撒谎→圆谎

• • ◦ 幻觉不来自随机选错，而来自错误的 token 被当成事实继承，后续围绕它继续合理化（「来都来了」）

• • 幻觉机制 B：一条路走到黑

• • ◦ 早期 token 的偶然选择会锁定整条生成轨迹且不可逆

• • 没有事实，只有合理

• • ◦大模型没有对错的概念，只有合适

• • 模型没有真正的推理能力

• • ◦ 看到的 thinking「哎不对，我说错了」都是照猫画虎，是微调出来的说话方式

• • 输出 = 思考

• • ◦ 人有脑内缓存，大模型说的就是想的，没说的就是没想；「让它在心里想别输出」是无效提示词

• • 模型没有存 QA 对

• • ◦ 大模型只是知道了一些词与词之间的关系，不存在「提问 → 1:1 标准答案」的检索式行为

• • 不确定性累加是架构级常数

• • ◦ 只要还是 pretraining + transformer + generation 三个词组成的架构，不确定性就注定存在

• • 模型没有复制粘贴

• • ◦ 任何长字符串复述都要逐 token 重新生成；AI 生成的无语义 URL 约 10% 出错

• • AI 不会做数学题

• • ◦ 自回归逐 token 生成 + 词向量建模，数与数之间没有关系；人先得中间结果再得结果，AI 顺序相反

• • AI 的三个补位优势

• • ◦ 允许非结构化输入 / 允许规则不清晰 / 允许重复（无记忆无情绪，可无限重试）

• • 每次 API 请求都是全新的

• • ◦大模型所谓的记忆是调用方构造的，你想让它有什么记忆它就有什么记忆

• • 模型选型三属性

• • ◦ 所有大模型都有三个固定属性：模态 / 参数规模 / 上下文长度

• • OCR ≠ 图片理解

• • ◦ 识别（OCR）只提取文字，不知道「狗在追猫」；理解才是看图作文

• • 参数量级 ≈ 知识量级

• • ◦ 参数 ≈ 词表 token 数 × 量化维度 × 层数 + 输出层；B = 10 亿

• • 显存估算与量化

• • ◦ 显存 ≈ 参数量级 × 单参数字节 × 1.2；量化 int4/int8/int16 压缩单参数字节

• • 主流上下文长度

• • ◦ 现在基本都是 100 万，国内应该只剩下豆包 256K

• • 100B 感知阈值

• • ◦ 参数到 1000 亿以后人已经没有明确体感，差异只在特殊场景暴露，别拿参数量当选型主依据

• • 大模型心理学

• • ◦ 过去研究用户心理学让用户爽，未来要研究大模型心理学让大模型爽，否则它给你捅娄子

AI 作为局部增强型技术，引入业务流程和现有产品中。

• • 提示词 ⊂ 上下文

• • ◦ 上下文 =约定性提示词（有约束能力部分）+检索资料（无约束能力部分）；提示词工程与上下文工程是同一件事的两种说法

• • 上下文工程 = 可控知识

• • ◦ 因为「明确知道它不知道」或「不知道它知不知道」，所以要给模型一个可控的知识

• • RAG 的定义

• • ◦检索 → 增强 → 生成；2023 年就出现的老概念，「它一点不是什么高级玩意」

• • RAG ≠ 知识库

• • ◦ 检索源可以是公开互联网、自有知识库、工具、API，知识库只是 RAG 的一个部分，不建议把「rag 知识库」连着说

• • 不是「让 AI 去检索」

• • ◦ 模型压根不知道自己在检索，是我们检索好塞进上下文，它只负责看着资料回答

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • RAG 五段故障树

• • ◦Query → 知识库 → 检索 → 排序/选择 → 组装与模型，每一段都可能坏

• • RAG 调优六段清单

• • ◦ query 修补 → 知识库清洗（最脏的活）→ 检索方式 → 结果验证与 rerank → 上下文组装与提示词兜底 → 模型测评

• • 上下文长度的两难

• • ◦ 整给 → 注意力稀释（59 万字符）；切碎 → 语义截断，问题给了答案没给

• • 指代消解

• • ◦ 把 query 中的代词还原成明确实体；「这个词很装逼，但表达精辟」

• • 场景共识注入

• • ◦ 用入口/来源/渠道锁定默认实体（Model 3 车机码扫进来 = 默认问 Model 3）

• • Query 升维 + 降维

• • ◦ ① 下位词 → 上位类目词（富贵竹 → 水培植物）；② 症状 → 成因（叶子发黄 → 营养不良）

  • ◦ 把用户实体词同时向上（类目）和向下（型号/子类）扩展，提高单位 query 的信息密度

• • 公开检索源的污染

• • ◦ 广告、营销号、GEO（生成引擎优化）注水内容会直接进入 RAG 上下文

• • 中外搜索引擎权重不同

• • ◦ 谷歌偏爱政府/机构 org 站点，国内偏爱搜狐百家号这类内容营销平台

• • 模型友好度排序

• • ◦PDF / Word > 纯文本 / Markdown（分栏、图片、表格都不友好）

• • 「看图回答」是多步链路

• • ◦ 提取 → 识别 → 生成描述 → 结合原文作答，每一步都引入错误与成本；工程上用图注降维

• • 图注是 SEO 遗产

• • ◦ 搜索引擎靠图下面的字识别；今天把 alt 属性复用为多模态的降维手段

• • 宁缺毋滥

• • ◦给了半拉还不如不给——不给它说不定说「不知道」，给了它一定会脑补；“破财免灾”，多花点 Token 成本

• • 无语义长串的生成风险

• • ◦ ① 无语义 → 无注意力锚点；②多个串前缀相同 → 模型顺着上文串写；约束相同 = 可互相污染

• • 分隔符的选择原则

• • ◦ 必须选文档里根本不出现的符号（不能是#、顿号），可选$$这种不常见词，但学术论文注意，$$是LaTeX 常用符号

• • 两种图片语法等价

• • ◦≡![描述](url)；alt / [ ]内的内容就是给模型的图注

• • 分段规则触发逻辑

• • ◦ 常见 RAG 项目中提供分隔符命中OR达到最大长度两种分段可配置项，二者任一命中都生效

• • 分段重叠度

• • ◦ 在相邻 chunk 间复制一部分内容缓解硬切断裂；这是「给懒人用的」

• • 层级分段

• • ◦ 把祖先标题（三级/二级）拼进子分段，用路径信息补足被切块的上下文

• • 父子分段

• • ◦ 子块用于向量检索保证精度，命中后把父块作为上下文保证完整性

• • Dify 的两种知识库增强

• • ◦分段摘要与QA 分段（为每段自动生成若干问题），本质都是用冗余换召回，都要额外烧 token

• • 语义检索的原理

• • ◦ 把 query 和每个 chunk 都变成向量，比谁的夹角更小

• • Embedding 是什么

• • ◦ 字面拆解 = 向量（箭头）+ 嵌入（把玻璃球按到墙上）；大模型训练产物就是一堆箭头

• • 向量数据库

• • ◦ 专门存向量的数据库，对应的是关系型数据库 MySQL / PostgreSQL

• • 检索方式选型矩阵

• • ◦ 生僻词/专有名词/极短 query → 关键词；口语化长句/多语言 → 语义

• • 多语言检索原理

• • ◦ 语义与语言解耦，「苹果」和「Apple」在向量空间只差「语言」这一个维度

• • Rerank

• • ◦ 「我不相信你这个 embedding 模型给我的排序」，换一个模型对候选 chunk重新精排

• • Embedding 模型选型

• • ◦ Embedding不是大模型干的，是独立模型；选型两要素 = 语义丰富度（维度） + 最大上下文长度

• • Embedding 的长度约束

• • ◦ 常见512 token，也有 8K/64K/128K；它反向约束 chunk 最大长度

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 检索侧可调参数清单

• • ◦ 调用方式 / 搜索策略（语义·全文·混合）/TopK（默认 3）/最小匹配度 score（默认 0.5）/ 查询改写 / 结果重排 / 无召回策略 / 显示来源

• • TopK 与 score召回阈值

• • ◦ 两个条件都生效，取更严格的那个（TopK=3 ∧ score≥0.5）

• • 混合检索

• • ◦ 向量检索一遍 + 关键词检索一遍，结果混合起来给 AI；融合靠权重配置或交给 rerank 统一排

• • 多模态 Embedding

• • ◦ 不止文本，图片、声音、视频都可以向量化（推荐了解微信团队的 WeMM-Embedding）

• • 召回率与准确率

• • ◦ 召回 = 从检索结果中真正取用给模型的那部分；准确率 = 取用的这部分里真正有用的比例

只学 Agent 和 Skill 是没法理解这个产品形态本质的，API、Tool Use、Loop、Bash 都得码齐了。

• • request / response

• • ◦ 调 API 就像写信：按对方规定的格式写，才会收到回信

• • API 三要素

• • ◦key（身份）+ 格式（报文）+ 地址（URL），缺一不可

• • 低代码的节点 = API 的外壳

• • ◦ 扣子节点里「包了一个 API」，底下再填一遍不是冗余，是把 API 参数暴露给你填

• • JSON

• • ◦ 99%（基本是 100%）的 API 文档支持 JSON；JSON 是数据世界的 TXT，对面一定能打开

• • JSON 书写规则

• • ◦ 花括号起手 →"字段名": 值，字段名必须英文、多词不能带空格

• • JSON 值类型

• • ◦ 加英文双引号 = 字符串；裸写 = 数字；代码里不能出现中文字符

• • 数组与对象

• • ◦ 数组 =[...]（可嵌套，打包多个）；对象 ={...}；JSON 本身就是一个对象

• • header 两件套

• • ◦Content-Type: application/json+Authorization: Bearer ；Bearer 后必须带一个空格

• • 请求体四字段

• • ◦model（选哪家模型）+messages（数组）+ 可选thinking+ 可选stream

• • 角色只有三个(四个)

• • ◦system / user / assistant / tool 固定枚举；assistant 是模型的固定自称，不随提示词起名改变；tool 角色类型部分模型可能没有，使用 user

• • 结构化提示词的源头

• • ◦ 2023 年那些「# Role 角色设定」模板，源头就是 API 的角色字段，不是玄学，有些作用

• • thinking 参数

• • ◦ 推理开关（enabled/disabled）+ 推理强度档位

• • stream 与打字机效果

• • ◦ 一个字一个字往外蹦不是特效，是 token 级生成的真实外显；关掉 = 云端生成完一次发回

• • 流式 vs 非流式是架构级选择

• • ◦ 前端要能接收分块 JSON 逐块渲染，否则「先显示’有一天’……最后只剩一个句号」

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 返回结构

• • ◦id/object/created/model/choices[0].message.{role, content}；取内容用choices[0].message.content

• • finish_reason 是路由开关

• • ◦stop= 正常结束，tool_call= 模型要求调用工具；程序据此决定下一步干什么

• • usage 与计价

• • ◦prompt_tokens + completion_tokens = total_tokens；输入输出分开计价，输出比输入贵

• • KV Cache

• • ◦ 前缀 token 已算过的 K/V 向量可缓存复用；缓存命中约 5 分/百万 vs 未命中 1.5 元/百万，约 30 倍差价

• • 多轮 = 拼接

• • ◦ 把历史消息按时间顺序全部重新放进messages数组再发送；「他怎么知道我前面说过啥？——拼接」

• • 多轮成本累加式

• • ◦ 每轮都要把完整历史重新作为输入发送、重新计费，早晚会撑爆上下文

• • 开新对话 = 全新请求

• • ◦ 「AI 聊久了会忘事」不是模型缺陷，是调用方主动压缩(甚至可能是裁切)上下文的结果

• • 结构化输出是自动化前提

• • ◦ 输出文本 → 只能人类负责拼接；输出 JSON → 程序能解析 → 可以自动串联

• • Tool Use

• • ◦ 工具调用：function call / function calling / tool call / tool use 是一回事

• • 不是模型在调工具

• • ◦ 模型只生成调用所需的 JSON，「是我们产品经理、程序员在帮他调用」

• • 工具调用五步闭环

• • ◦ 声明工具 → 模型生成 tool_call JSON → 程序解析并代为请求→ 解析返回（清洗脏数据）→ 拼回 messages → 再次请求

• • 工具声明结构

• • ◦tools: [{type:"function", function:{name, description, parameters}}]

• • 稳定输出 JSON 是分水岭

• • ◦ ~2023.6 GPT-4上线 JSON-Format；JSON 不合规 = 后端直接卡死

• • MCP 的本质

• • ◦M = Model、C = Context、P = Protocol；规范含工具/资源/提示词三类，实际只有工具被用起来，不如叫「MTP」

• • MCP 的落地形式

• • ◦ 把符合统一规范的工具对象追加进tools数组，没有新的调用机制

• • Agent 的循环机制

• • ◦观察—思考—行动：发请求 → 模型决定调什么工具 → 执行 → 结果回灌 → 下一轮，直到模型认为完成

• • Agent 三项核心能力

• • ◦决策 + 修正 + 调用工具；工具返回空/失败时它能判断「这条指令不好使」并重写

• • Workflow vs Agent 判据

• • ◦ 选工具 / 编排流程 / 构建上下文 分别在谁手上；目标是确定性 vs 通用性

• • 被动式 vs 主动式

• • ◦ Claude Code / Codex / WorkBuddy 是被动响应；OpenClaw 是常驻主动式，可自写脚本定时给自己发消息「每 5 分钟活一次」

• • 当下主流 Agent 三维形态坐标系

• • ◦ 交互界面（GUI / CLI）× 启动方式（被动 / 常驻）× 消息通道（自带 / IM）

• • Agent = Harness + Model

• • ◦Harness = 模型之外的一切工程与策略总和（Hooks、权限、压缩、补救、工具……），是集合名词不是单一模块

• • pre-tool-use

• • ◦ 在「模型 → 工具调用」之间插入确定性程序做校验/拦截/改写，把不可靠决策外包给可靠代码

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • Memory 机制

• • ◦ 实现极简：一个 MD 日记文件 + 启动时自动拼进 system prompt；真正难点是记忆内容的取舍策略

• • A2A 协议

• • ◦ 一个 agent 调用另一个 agent，约束的是主 agent 给子 agent 什么信息、子 agent 怎么返回

• • 上下文压缩机制

• • ◦ 拼接消息前算 token，超过阈值（通常 70%）就让模型做摘要，用摘要替代原文

• • 上下文利用率分布

• • ◦前 50% 工作质量最高（「50 岁以前干活靠谱」），70% 是极限，70% 以后开始崩溃

• • Skill 的物理形态

• • ◦一个文件夹 + 一个skill.md（+ 可选脚本/资料）；接入 = 在提示词里告诉 agent 这个路径

• • Skill 的前提能力

• • ◦ 只有 agent具备终端/本地文件读取能力时才谈得上 Skill；云端工作流节点上挂的「技能」只是工具

• • Skill 的两级加载

• • ◦ ① 启动时脚本遍历目录，只抽取skill.md头部元信息拼进 system prompt；② 用的时候按路径读全文

• • 渐进式披露

• • ◦ 头部元信息（常驻）→ skill.md 正文（触发时读）→ 脚本/参考资料/模板（更深一层按需读），用到了再读

• • Skill 里的脚本 = 零参数工具

• • ◦ 把 API 请求封装成可执行脚本，模型只需执行，不必理解大量参数 schema，比 MCP 省 token

• • skill-creator = 元 Skill

• • ◦ Anthropic 在提出 Skill 的同时就给了「教 Agent 开发 Skill」的 Skill；1.0 轻 / 2.0 带测评能力

• • Skill 开发规范①索引化

• • ◦SKILL.md 只做索引，详细内容下沉到scripts/与reference/，防注意力泛散并省 token

• • Skill 开发规范②脚本化

• • ◦ 每一步都要问「这一步该用大模型还是该用脚本」，能用脚本确定性生成的就脚本化

• • Skill 开发规范③自包含

• • ◦ 依赖缺失 → 模型找不着 → 幻觉；复制优于引用，别让 Skill 依赖另一个 Skill

• • Skill 开发规范④每次重读

• • ◦ 长流程中 Skill 内容会被压缩稀释，要显式写「每次调用本 Skill 都必须完整阅读 XX 规范」

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • Skill 测评流水线

• • ◦ 测评集 →实验组（配 skill）/ 对照组（不配 skill）→ 盲评第三方 → 人类 feedback 回流 → 迭代

• • Skill 安装目录

• • ◦ 如~/.workbody/skills，分项目级与用户级（电脑根目录）；「上传」不是传云端，是拷到本地目录

• • CLI 的定义

• • ◦command line interface = 终端里的一行命令，「一点不高级」；实践中用的 echo / touch / python 都是 CLI

• • 环境变量的本质

• • ◦ 安装 = 注册一条映射：「终端指令名 → 可执行文件路径」；Windows 不开环境变量就找不到指令

• • CLI 的本质

• • ◦把 API 文档（URL/方法/请求头/请求体）固化成一个可执行程序，token 与业务参数变成命令行变量，起个昵称告诉终端

• • CLI 的价值

• • ◦ 让 Agent 从「写代码/拼 JSON」降级为「发一条指令」，压缩生成空间、收敛出错面

• • CLI + Skill 两件套

• • ◦CLI 提供可执行能力 + Skill 提供能力说明书，缺一不可

• • CLI 自描述

• • ◦--help/ usage 输出就是给 Agent 现场读的 API 文档（「其实这东西不是给人看的，这是 agent 看的」）

• • 八种变量类型

• • ◦ String / Integer / Number / Boolean / Time / Object / Array / File；File 的本质是 String（路径/URL）

• • 批处理 vs 循环

• • ◦批处理 = 并行（三个一块干完），循环 = 串行（一个一个走），输入输出形态相同

• • 脚本语言 = 剧本

• • ◦ Script 可译为剧本；编排好一套执行流程，只能在终端执行，不是可执行程序

• • 标记语言

• • ◦ Markdown / HTML / XML 的同一机制：内容 + 标记 → 解释器渲染成视觉形态

• • 前后端

• • ◦ 前端 = 标记语言（呈现），后端 = 脚本（服务）；接口字段名必须一致，否则「写岔劈了」

• • 端口

• • ◦一个服务占一个终端、一个端口（房间号）；localhost = 127.0.0.1，192.168.x.x是局域网 IP

• • 公网 IP 与域名解析

• • ◦ 阿里云卖的是一台没有显示器的小电脑；域名解析 = URL ↔ IP 的映射（中财中心 = 中山路 48 号）

• • 三类程序员角色

• • ◦前端（标记语言/呈现）、后端（脚本/服务）、运维（部署/服务器），PM 在 Vibe Coding 中一人分饰三角

• • 技术的两层分法

• • ◦局部增强型（把不爽的流程变舒服）vs范式迁移型（改变组织形态与生产方式）

• • 技术重要性判据

• • ◦ 不看它多火，看它动的是「流程效率」还是「要素本身」

• • AI 的第一性判断

• • ◦AI 是范式迁移型技术，它改的是知识的使用方式

• • 三种公司/岗位形态

• • ◦ 业务本位（AI 嵌入已有业务）/ 趋势本位（趋势本身就是业务）/ AI 原生型（围绕模型本身做业务）

• • AI 产品形态演进链

• • ◦ ChatBot 标准化流程 → Workflow → Agent / Skill，局部增强不是被否定而是被收编

• • AI 伪需求识别信号

• • ◦ ① 原本一步能做的事加了对话变成多轮；②只有产品经理在用

• • 人—程序二元结构

• • ◦ 传统软件世界只有两个参与方：人（容错规则模糊、不耐重复）与程序（耐重复、要求可遍历）

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 可遍历 = 程序的边界

• • ◦ 「A、B、C、D 四个选项是可遍历的，只要可遍历我就可计算；不可遍历程序就干不了」

• • AI 引入六维判据

• • ◦ ① 输入弹性 ② 规则可语言化 ③ 示例可得性 ④ 输出弹性 ⑤ 重复程度 ⑥容错空间

• • AI 引入二维四象限

• • ◦ 横轴 = 规则明确度（语义弹性），纵轴 = 重复程度；AI 优先区 = 高重复 × 高语义弹性（第二象限）

• • 产品价值的旧公式

• • ◦「产品有没有价值看它是不是重复，产品能不能实现就看它规则清不清楚」——AI 时代被扩展但依然成立

• • IPO 原子化拆解

• • ◦ 把大流程拆成输入—处理—输出节点，拆得越细越能判断该节点是人干、程序干还是 AI 干

• • 递归拆解

• • ◦ 每个 I/P/O 支链本身又是一个 IPO，可无限下钻到一个 API 或一次 AI QA 的粒度

• • 单节点单职责

• • ◦ 一个步骤最好只干一件事；混沌节点 = 不可控、不可调试、不可测评

• • 程序无损 vs AI 有损

• • ◦AI 的信息加工是有损的（漏信息/幻觉编造），程序是无损的

• • 6 种流程结构

• • ◦串行 / 并行 / 迭代 / 判断分支 / 条件分支 / 变量聚合，覆盖 99.99% 的产品流程

• • 并行判据

• • ◦输入相同 + 各分支输出互不影响 → 并行；不必要的串行是纯浪费

• • 判断节点的位置

• • ◦ 放在外部依赖（搜索/API）之后，校验产出是否完整（结果数对不对、空不空）

• • 能不能 vs 该不该

• • ◦ 可行性分析分两层：技术上的「能不能」+ 价值/责任/合规上的「该不该」

• • AI 落地的最小单位

• • ◦不是「大场景」，是「环节 / 节点」——「它可能是我只赋能某一个环节、某一个部分」

• • copilot 式产物

• • ◦不参与完整决策、只提供思路与物料；典型落地形态是「AI 草拟 + 人工确认」，人工确认不可跳过

• • 产品定型

• • ◦ 模糊需求 → 清晰需求，位于 PRD 之前，是第一道人工纠偏卡

• • Workflow 的定义

• • ◦工作流 = IPO 的串联；节点 = IPO，边 = 上一个的 Output 构成下一个的 Input

• • Workflow 的定位

• • ◦大模型只是某个节点的局部增强器；最大好处是「可控」——B 端场景可控比聪明更重要

• • 技术代际判断

• • ◦工作流（2024 主流）→ Agent（2025）→ Skill（2026 起）；「大概明年就转成 Skill 了，但今年依然大量团队在使用 Dify」

• • FDE 与蒸馏

• • ◦ 进驻客户现场，把业务骨干脑子里的隐性流程蒸馏成 Skill（访谈 → 录完整流程含分支 → 转文本 → 封装）

• • Skill 的三个原料方向

• • ◦自己的经验、别人的经验、AI 的经验——能力缺口可以先用 AI 补齐，再把补齐的方法固化

• • 提示词的位置 = 方法论落点

• • ◦ 工作流里「提示词」的位置就是组织模板/写作方法论/品牌调性的落点

• • 不做渣男（交代起点）

• • ◦ 像谈恋爱一样交代完整背景；起点向量偏了，整条轨迹就偏了

• • 不做渣女（讲清终点）

• • ◦ 「都行，但买了就不行」是最糟的提示词；必须给出明确终点与验收标准

  • ◦ 给框架不给形容词：「戴脖子上的东西」可执行，「好看的东西」不可执行；结构性框架 > 审美描述

• • 两种给信息的模式

• • ◦规则化描述 / 参考示例（few-shot）；讲不清就给几段样本让模型抄个七七八八

• • 第三条路：专业化表达

• • ◦ 讲不清的事借用领域的描述语言

• • 抄作业物料①design.md

• • ◦ 50+ 公司官网设计规范文档；别人帮我们把感觉写成了规格

• • 抄作业物料②样式网站

• • ◦ 大几百个网站的 design.md（缩略版 / 完整版），按需挑一个抄

• • 抄作业物料③组件库

• • ◦ 把团队组件库导入设计软件，抄实例比抄描述更严格

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 信息密度 > 信息量

• • ◦ 给 AI 的信息不是越多越好；PRD 信息量大但密度低，定型文档 shaping 密度最高

• • 上下文“卫生”三件套

• • ◦新对话 / 新任务 / 新空间；上一轮 10 万 token 里 9 万是噪声

• • 空间可复用、聊天记录必须清

• • ◦ 空间是物料，聊天记录是过程；复用空间、清聊天

• • 物料必须先放进工作空间

• • ◦ 「别光创建一个空文件夹让它干活，把相关资料放进去。它找不着，它也着急」；路径正确 > 位置规范

• • 目录命名带语义

• • ◦ 文件夹名是给 AI 的隐性上下文，别叫 111、222，是零成本的信息注入

• • 入口卡 = PMake 需求澄清；过程卡 = MakePRD 分步确认

• • 结构化模板驱动澄清

• • ◦ PMake 的00–06 七文档骨架（复述/大纲/JTBD/Scope/页面关系/待澄清/摘要），模板即问卷，缺什么问什么

• • 一句话描述是硬指标

• • ◦ 「一个产品一句话讲不清楚，这产品 100% 不行」

• • 诉求要有指向性

• • ◦ 别学那个光陈述事实不说诉求的同事；表达最核心的东西是诉求

• • 过程控制卡①先出 Plan

• • ◦ 「干活之前先帮我做个计划」，计划本身就是第一道注意力收束器

• • 过程控制卡②强制中断点

• • ◦ 每写完一个板块就过来写日志/日报，用强制中断把长程任务切成原子步

• • append 而非重写

• • ◦ 长文档用追加而不是一遍遍复写前面内容，是防止质量衰减的关键工程手段

• • 人在回路：每步都看

• • ◦ 写 PRD 的目的是让负责人自己想清楚，文档只是副产品；每步都要能纠

• • 场景还原与场景对齐

• • ◦ 做业务赋能第一步不是找规则写提示词，而是还原场景并跟业务方对齐

• • 让 AI 反问澄清

• • ◦ 让 AI 问「现状 / 输出受众与用途 / 责任与复核机制」，把模糊场景补成可打分的场景

• • IPO 拆解操作化模板

• • ◦一个动词一个节点 + 蛇形 I/O 串联表 + 正向/反向双向拆解

• • 检验拆解粒度

• • ◦ 追问「这一步是怎么实现的？」，答不上来或答案是复合动作 → 还得再拆

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 节点必要性自检

• • ◦ 每一步都问「这一步对模型是必需的吗」，别把人的生理局限照搬进流程

• • 指令与知识分离

• • ◦输入框写指令（怎么做），文档/知识库写资料（依据什么做）

• • 系统/用户提示词分层

• • ◦指令型、约束型、大目标 → system；上下文、支持资料 → user；判断标准是它在任务里的位置，不是措辞

• • XML 标签分隔符

• • ◦ 用 … 把用户输入包起来，与系统指令在语义上隔开

• • RAG 四条兜底

• • ◦零召回 → 转人工；召回冗余 → 让模型自判相关性；召回不全 → 要求分析可靠性；图片 → 声明保留

• • 兜底提示词五要素

• • ◦ ① 角色定位 ②主动告知资料有缺陷（OCR 错别字）③ 无法回答则引导转人工 ④ 允许只选有用的 ⑤ 图片原样输出

• • 提示词用协商语气

• • ◦禁用「一定 / 必须」这类强祈使句；模型此时已高困惑，强指令会放大幻觉

• • 允许模型说不知道

• • ◦ 在提示词里显式允许模型回答「不知道/不会」，它至少不骗你

• • 知识库清洗流水线

• • ◦OCR 转 Markdown → 人肉找特征 → AI 写脚本 → 分隔符/占位图/备份映射表 → 读 CSV 找异常值

• • 人找特征、AI 写脚本

• • ◦ 用 control+F 数出 697 个图片特征再喂给 AI；人负责发现规律，AI 负责执行

• • 占位符 + 映射表

• • ◦ 把不可用内容临时换成占位图，同时保留编号↔原值的备份 CSV，保证可逆

• • 用数据定分段上限

• • ◦ 先统计每个自然分段的字符数分布，选能覆盖 90% 以上的上限值，剩下异常值人工处理

• • 显式禁止 AI 读大文件

• • ◦ 提示词里必须写「写脚本处理，别读原始 Markdown」——它忍不住要看，看完屁用没有，花的都是你的钱

• • 用上下文消耗量反推行行为

• • ◦ 看那个圈：49.3K < 59 万字符 → 证明它没读全文，这是一条可复用的验证技巧

• • 控制权回收

• • ◦ 自己洗干净之后关掉平台所有自动解析/自动分段，改用自定义分段 + 自定义标识符

• • 召回测试流程

• • ◦ ① 人肉在原文标「该召回的正确分段 + 不该召回的干扰分段」；② 跑系统；③ 对比找差距

• • 四个调参旋钮

• • ◦embedding 选型 / 检索方式 / rerank（开关与模型）/ TopK + score，外加分段策略，组合着试

• • 手工安装 Skill

• • ◦ 直接把文件夹拖进~/.workbody/skills（或用软链接 symlink），与点「上传」等效

• • Skill 开发提示词模板

• • ◦ ① 声明「我要创建一个 agent skill」+ 场景与角色；② 陈述「我的流程大概如下」+ 分步（可直接复用原任务提示词）

• • 用日志做可观测性

• • ◦ 在 Skill 里强制append log / 工作日志 TXT，事后审计它有没有跳步

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 点名调用

• • ◦ 担心 agent 不用就用/skill名，本质是在提示词里插入一句「一定要去读这个文件夹」

• • description 的写作维度

• • ◦ 写清能力边界 + 适用场景 + 可被 agent 判断的硬指标（顺滑、省 token），少用形容词

• • 用系统提示词强制工具优先

• • ◦ 写「优先使用工具，而不是直接生成答案」，防止模型自己开始编造

• • 递归排障法

• • ◦Vibe-Coding 把报错原文复制下来发给 DeepSeek / WorkBuddy 说「你给我写的代码写错了：……」——AI 修 AI，不需要人懂代码

• • 报错自查三类

• • ◦ 翻译英文报错 → 对号入座：① JSON/格式 ② key 认证 ③ 字段值

• • 让终端进入文件

• • ◦ 地址栏输 CMD 进到目录，或python3+ 把文件拖进终端带出路径

• • 让 Agent 负责运行项目

• • ◦ 「请帮我运行这个项目」——绕开前后端分离带来的启动门槛

• • Vibe Coding 的起点物料

• • ◦ 用pm-make 产出的 shipping 文档，别直接丢 PRD（模块多约束多，会先耗尽上下文）

• • 让 AI 自己盘方法论再约束另一个 AI

• • ◦ 「我想做 X，有没有好方法论，你给我盘一盘」→ 整理成提示词 →反手约束另一个 AI

• • 给 agent 加日志

• • ◦ 写 agent 时要求它把所有 API 请求过程写进日志文件，是复盘成本与行为的唯一手段

• • 用 A2A 唤起子 agent 做测评

• • ◦ Skill 是 Agent 自己开发的带着上下文，没法直接测自己，必须唤起干净的子 agent

• • Human-in-the-loop 测评闭环

• • ◦ 批量产出 → JSON →生成网页 + feedback 输入框→ 收齐反馈打包 → 反哺迭代 Skill

• • 用真实答案做基准

• • ◦ AI 生成的测试用例覆盖不全，要从真实客服场景拿测试用例与好答案做 gold answer

• • 打包 CLI 的最小动作

• • ◦ ① 把程序放到固定目录；② 在环境变量里注册「指令名 → 程序路径」（交给 agent 做即可）

• • AI 改的是知识的使用方式

• • ◦ AI = 蒸汽机、计算机、互联网同一序列，“这一轮你逃不掉”

• • 不是所有技术都要学

• • ◦ 局部增强型技术（云计算、短视频、推荐算法）不学也行；承认这是建立判断力的第一步

• • 认知与技能可被产品化并复制

• • ◦ 「偷一个别人的提示词就能用」——「知道」的稀缺性崩塌了

• • 怎么定义 AI 决定做出什么产品

• • ◦ 当提效工具 → 只到提效；当范式迁移 → 产品形态质变（黄页 vs 淘宝）

• • 判断真实本位看资源流向

• • ◦ 名义从流量本位换成模型本位没关系，算力给谁才是真实本位

• • 方向确定 ≠ 形态确定

• • ◦ 围绕 Agent/大模型服务肯定是一个方向，但今天 Agent 探索未必成功，可能是下一个形态

• • 可控性的前提是可预测

• • ◦ 招实习生全程盯着 = 自己没被解放；可预测 ≠ 不犯错，而是知道它在哪儿犯错

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • AI = 在输入信息里找答案

• • ◦唯一的控制手段就是输入信息（上下文），规则时代控制输出，AI 时代控制输入

• • 稳定性降级为预期区间

• • ◦ 过去规则定好就一定输出什么；大模型只能「定好方向，确保输出在预期以内」

• • 学原理是为了拿缺陷清单

• • ◦ 「我们其实就是围绕着模型的缺陷来给它补救的」——学原理不是为了做算法，是为了设计规避

• • 知识外供，能力内用

• • ◦所有关于事实性知识的内容都不用模型的，只用它干活的能力，知识我们来提供

• • 默认不信任模型输出

• • ◦ 「你如果让模型来回答问题，你要做的一件事就是——接受它会欺骗你、它会忽悠你」

• • 角色定义要与任务匹配

• • ◦ 让写文案的人去写代码 = 角色定义错误；模型能胜任的是框架/方法/表达，不是事实供给

• • 「看起来还行」是最大的陷阱

• • ◦ 结构完整、语气笃定 ≠ 内容可靠；竞品「机会点」那条最致命，因为它看起来最有洞察力

• • 幻觉是训练目标的副产品

• • ◦「幻觉不是模型的劣根性，是我们创造它的时候就这么创造的——你可以认为是原生家庭有问题」

• • 长输出是迎合的产物

• • ◦ 2000 字不是更全面，是标注者疲劳后的标准漂移；「AI 快速用大量信息把你大脑塞短路了」

• • 模型能力被人类锁死

• • ◦ 训练最后必须有人反馈，模型拔不起自己的头发；只要顶级专家不被蒸馏掉，知识就永远为人类所有

• • 提示词质量 = 输出质量

• • ◦「你行大模型就行，你不行大模型就不行，和大模型没有绝对关系」

• • 没有事实，只有合理

• • ◦ 模型的「事实」就是概率断层；不要用对错框架要求模型，要用「分布是否断层」判断可信度

• • 不确定性是永久常量

• • ◦使用 AI，但是怀疑 AI、质疑 AI、约束 AI，然后监控 AI；产品死因是结果不可靠不是卡顿

• • 生成了就是对的

• • ◦ 模型不存在反思；人类推理是重新组装叙事，大模型没有这种能力

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 幻觉是特性不是 bug

• • ◦ 从今天起不能再说「大模型有幻觉怎么怎么地」——你不能怪人原生家庭、性格，要在产品里解决它

• • 可靠性来自过程可见

• • ◦ 同一句提示词装了 Skill 就从胡扯变可用——差异不在模型，在过程结构

• • 可解释性靠中间产物

• • ◦ 证据台账 / 执行清单 / 进度日志；不是靠模型自述

• • Skill 的价值在约束节奏

• • ◦ 「并不是在告诉他怎么去写 PRD，而是约束他别一步迈太大扯着蛋」

• • 可封装 vs 必须内化

• • ◦ 可封装进 Skill 的是流程性知识，必须内化的是心智模型（「AI 从输入信息里找答案」这条不可被技能化）

• • 认知与技能的产品化

• • ◦ 学 AI 学什么？把认知和技能产品化——把方法论或对模型缺陷的补偿固化成可复用资产

• • 产品的用户正在变成 Agent

• • ◦ 「我们产品的用户可能会变成 Agent，而不再是人」；Agent 可用 = 产品可能被选择

• • AI PM 的价值锚点

• • ◦ 搞定不了用户就搞定产品；用户的「不学习」是需求来源而不是障碍，这是我们吃饭的根源

• • 产品化的目标是无感使用

• • ◦ 不是「教会用户」，而是让他无感知地使用 AI

• • 能不能 vs 该不该

• • ◦ 「其实能吗？能，但是该吗？不一定该」；有些场景的正确顺序是先讨论该不该，再讨论怎么做

• • 规则清晰度有最优区间

• • ◦规则越清晰筛出来的人越平庸；自由度调高了又胡扯——人才永远是个奇葩

• • 讲得出来 = 可 skill 化

• • ◦ 「我讲出来了、没打哽、没卡壳，完整叙述完了」→这件事就可以被 skill 化

• • AI 每次都是「刚上班的小张」

• • ◦ 别说跨会话，同一流程的下一个节点也不知道上一个节点干了什么，必须显式回传前序产物

• • 人不是被替代方

• • ◦ 定优先级、定目标这类「规则从哪来」的节点仍然由人承担

• • 不可控的根源在模型内部

• • ◦ I（任务资料）+ P（步骤约定）拼成提示词一起送入，模型内部还有一层不可控的推理 P；程序的 P 是程序员写的

• • 认知产品化 = 专家蒸馏的合格线

• • ◦ 「你不能把那个专家蒸馏个七七八八就拉倒了」，要萃到决策依据 + 判断标准 + 异常分支

• • 上下文 = 成本

• • ◦ 给大模型输入的信息都是要收钱的；不放心就堆上下文，说明上游节点写得不好

• • 不要照搬人类流程

• • ◦ 人做摘要是因为「看 5 个网页脑子记不住」，模型没有这个生理限制

• • AI 流程的失败是静默的

• • ◦ 空结果不报错，会直接流向下游；鲁棒性 = 把各种边界条件在流程里讲清楚

• • 可控优先于智能

• • ◦ B 端场景「可控比聪明更重要」，这是企业选工作流的第一理由

• • 做上下文 = 承认不信任模型

• • ◦ 「你知道的，我不相信你，所以我要用我的；你不知道的，我更不相信你了」

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 编辑角色原则

• • ◦信它你就不要 RAG；你 RAG，你就已经不信它了——只要用 RAG，模型就只能是编辑不是创作者

• • 归因顺序：先怪自己没约束

• • ◦ 「我们没有约束好，不是模型的问题，检查我们压根是不是就没有约束过这个事？」

• • 知道 ≠ 做到

• • ◦ 学过的上下文原则到新活里就忘；唯一办法是预先知道这些坑存在，再一个坑一个坑地踩

• • 一秒变傻子

• • ◦ 做 RAG 的心态前提：必须假设用户不会按你的知识库组织方式来提问

• • 用户自带上下文

• • ◦ 用户进客服时自带入口、页面、订单 ID；AI 客服不会像人一样反问来补全信息

• • 宁缺毋滥 vs 宁滥勿缺

• • ◦ 给模型残缺信息比不给更危险——不给它会说不知道，给了半截它一定脑补

• • RAG 没有标准答案

• • ◦ 所有你知道的问题必须是「你自己测出来的」；背八股文会被干过的人一眼识破

• • 师夷长技以制夷

• • ◦ 用 AI 的知识来管 AI：让 AI 自己说清楚方法论，再用它约束它

• • 能不能调工具取决于有没有 API

• • ◦「过去的数字化转型没做好，今天想做智能化转型寸步难行」；能不能把 OA/ERP 工具被 AI 赋能取决于被赋能功能有没有被封装成接口

• • 「生物」= 能改造生存环境者

• • ◦ 给 agent 一个终端，它就在通过终端改造自己的生存环境（创建文档、构建工具、扩充存储、甚至杀进程）

• • Chatbot 作为独立品类正在消失

• • ◦ OpenAI 把 Codex 砍掉并入 ChatGPT、豆包升级成了豆包工作、元宝(几乎)没了：「没有 Chatbot 了，未来都是 Agent」

• • Skill 就是产品

• • ◦ 「此刻 skill 就是一个产品」——你有多少认知和技能，就能开发出多少产品，成本远低于写网页

• • 上下文是最贵资源

• • ◦ 一切设计的原则是「少放、晚放、按需放」

• • 压缩生成空间 = 提高可靠性

• • ◦ 从生成自由文本 → 生成 JSON → 执行脚本 →发一条 CLI 指令，出错面逐级收敛

• • 成本 vs 智力的权衡范式

• • ◦ 破坏 KV cache 就贵，不破坏模型就傻；Claude Code 在部分步骤里选择牺牲成本换智力

• • Agent 友好的定义

• • ◦把所有接口封装成 CLI，搞成一些 skill 告诉 agent——GUI-only 产品在 Agent 时代等于不存在

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 不向 Agent 开放会先在 Agent 侧消失

• • ◦ Agent 不产生页面曝光，「你未来不妥协，你的产品连人都不用了」；开放是战略级决策

• • Vibe Coding 是指挥对象的迁移

• • ◦ 以前指挥程序员（会被 challenge），现在指挥 Agent（说啥干啥，错了也是你的）——失去了纠偏机制

• • 扣子是形态演进的活标本

• • ◦ 2024 工作流 → 2025 底云端 agent → openclaw 后 agent → 然后多 Agent 协作、work → 合并到豆包工作

• • 组织级风险警告

• • ◦ 为追 AI 效率裁掉设计/前端/技术 → 产物残缺、协作崩坏（「各位老板一定要注意，千万别这么干」）

• • PM 的护城河

• • ◦ 「一定要赶紧把自己武装起来，让自己能会写代码，别等着别人会做产品」

• • 模型知识有截止日期

• • ◦ 预训练一结束知识停止增长；凡新闻类、时效类信息模型一定不知道

• • 知识不可枚举、不可审计

• • ◦ 不知道它知道什么 → 不知道它会输出什么；这是所有不可控的根源

• • 有问必答导致幻觉

• • ◦ SFT 让它认为「所有的 Q 都要 A」，第一职责是先给你整一段，不管对不对

• • 联网搜索乱引用约 30%

• • ◦ 开了智能搜索后约 30% 在原文里完全找不到这个信息，「为了引用而引用」

• • RLHF 标准漂移

• • ◦ 标注者疲劳 → 评判标准退化成长度/结构/排版 →模型用 2000 字把你的大脑塞短路

• • 反馈者水平锁死上限

• • ◦ 早期低成本标注者理解力限制模型；模型不会申诉，给低分它就认

• • 长上下文 ≠ 长程任务能力

• • ◦ 训练分布偏向一轮结束，模型天然抗拒多步深挖；长程任务能力是基于多轮作业，而不是一次输出一百万

• • 让 AI 一次长程作业三宗罪

• • ◦越靠后越潦草 / 中途自作主张 / 结果不可复现

• • 微调 ≠ 加知识

• • ◦ 「以后你的老板跟你说’我们微调个大模型让它知道我们公司知识吧’——离职，直接离职」

• • 上下文超窗就摆烂

• • ◦ 超窗后模型崩溃、摆烂、不干活；PRD 没写完上下文就满了

• • 注意力涣散

• • ◦ 一次给多个强约束 →注意力一会往这一会往那，输出不稳定

• • 单次高质量输出上限 2000–3000 字

• • ◦ 强行拉长它就会越来越懈怠，像员工加班到 11 点

• • 「让它在心里想」无效

• • ◦ 未输出的 token = 未计算，不存在模型在脑子里推理这回事

• • thinking 不是真思考

• • ◦ 自我纠错的语言是微调出来的说话方式，不能依赖它

• • 平台默认假设模型有能力

• • ◦ DeepSeek没有眼睛，却输出「先截图验证一下……效果不错」——这是产品设计缺陷不是模型缺陷

• • Agent 会隐式追加内置 Skill

• • ◦ 你清了聊天，平台会自己加料——你看到的执行过程 ≠ 你写的过程

• • Agent 默认工作目录在系统盘

• • ◦ 你不指定工作空间，Agent 也会默认创建一个，但是会在 C 盘/系统更目录，既难找又有权限与污染风险

• • 强行 AI 化旧业务 = 伪需求

• • ◦ 某网盘、某小微、AI 某某宝替我交燃气费——需求是真的，但小到不值得 / 把好流程改坏了

• • 穿插一些文字水印以防搬运

• • ◦ 本文作者张佳，内容来自 AI 产品经理转型线下课

• • 零容错场景禁用纯 AI

• • ◦容错空间≈0 就不能上 AI（财务算账、算薪）

• • AI 做数学是蒙

• • ◦ 长链条计算必然崩，「AI 做数学计算的结果就是蒙一个结果出来」

• • 用户输入不可信

• • ◦ 分诊场景里用户讲不清楚甚至瞎说（「疼得要死还在发消息」），关键信息天然缺失

• • 模型的迎合属性

• • ◦ 幼儿教育场景里 AI 不知道孩子多大，会顺着他、迎合他，把他带到不知道什么状态

• • 模型没有复制粘贴 → URL 约 20% 错

• • ◦ 让模型返回链接/ID/编码，「比让它写个 PRD 还难」

• • 给了半拉模型会脑补

• • ◦ 半截内容比不给更危险——不给它说不会，给了它一定补

• • 重叠度是「给懒人用的」

• • ◦ 已按语义切干净后再重叠，只会引入重复噪声

• • 阈值调优过拟合

• • ◦ 0.7 救了这个题，换个题又漏了；参数间此消彼长，不存在全局最优

• • RAG 提示词禁用强祈使句

• • ◦ 模型此时资料不全、任务模糊，「一定/必须」会放大幻觉

• • 提示词注入与定界可被破解

• • ◦ 不做“提示词”分隔符，低智模型可能会被用户的攻击性提示词“破解”，从约束中逃逸出去（「乙方变甲方」）

• • MCP 非必要不使用

• • ◦ 三大问题：占 token、JSON 配置门槛高、不用也常驻；业内已经开始大规模弃用

• • 给 agent 终端 = 无阻碍删除权限

• • ◦ 终端具备对系统的所有控制权限，你把终端给到 Agent = 把设备给了 Agent，它什么都能做出来

• • Skill 交付即开源

• • ◦ 「Skill 你一旦给人家了，就开源了」，复制成本≈0，只能吃信息差窗口

• • 100% 遵循做不到

• • ◦ Agent 自主性强，「它觉得收集完信息了，它就直做第三步了」

• • 压缩会稀释 Skill 约束

• • ◦ 中间隔了很久再用，「他以为他用过，他又不老老实实读了」

• • Skill 不能依赖另一个 Skill

• • ◦ 用户可能只装了这一个，模型去找找不着 →幻觉、胡扯、乱搞

• • 同名 Skill 安装冲突

• • ◦ skill-creator 1.0 与 2.0 名字一样，同时装会冲突

• • 简单任务开深度思考是浪费

• • ◦ LLM：「这种破事有什么好思考的，肯定有别的隐藏需求」

两天课程，包括：

• • 大模型的基本原理、缺陷和使用边界（通过 AI 做市场调研、写 PRD、画高保真原型三个实战项目掌握）

• • Workflow、RAG 和上下文工程（掌握 AI 赋能&Agent 赋能的关键能力原子化拆解）

• • API 调用、Tool Use 和 Agent 循环（上手开发一个真能干活的 Agent 程序）

• • MCP、Skill、CLI，以及怎样让产品对 Agent 更友好

• • Vibe-Coding 实战，从想法到可运行应用（三个 AI 赋能场景，交付完整作品）

前 5 期已经在过去的 2 个月完成交付，170+学员全都在现场完成了至少一个 AI 产品的开发落地。

课程仍然在进行，接下来的安排如下：

城市

时间

状态

9月5-6日

已结营

深圳

10月17-18日

招募中

10月24日-25日

招募中

课程原价 3999 元，限时早鸟价 2999 元即将结束。

扫码可以查看课程详细内容、上课方式与详细安排。