把 Prompt 变成团队工作流
本步 3 个知识点
学习目标
能把个人技巧沉淀成别人也能用的 SOP。
先记这一句话
晋升价值来自可复用流程，不是一次漂亮回答。
知识点清单与业务判断
先会用，再理解
1. SOP
知识点讲解把使用入口、输入要求、输出解释和复核方式写清楚。
老师板书
SOP
工作流
先有流程，再谈 AI 自动化；没有 SOP，AI 只是在加速混乱。
先用人话讲明白
SOP 是稳定可复用的操作流程。AI 要进入团队协作，必须嵌入 SOP，而不是依赖某个人临场发挥 Prompt。
类比可以把它理解成给一个聪明实习生写工作说明书：越清楚，返工越少。
为什么要学把一次性提问变成可复用流程。
把关键词拆开看
- 步骤固定：谁在什么条件下做什么。
- 输入输出明确：每一步接收什么、产出什么。
- 可培训：新人照着做也能达到基本质量。
入门版理解：把使用入口、输入要求、输出解释和复核方式写清楚。
适用范围和边界
1. 优先原则：先满足前提，再谈使用
在实际工程里，任何概念都不能脱离场景硬套。学习「SOP」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。
- 先看它服务的专业判断是不是「工作流」：把一次性提问变成可复用流程。
- 任务有稳定流程，至少能写出输入、处理步骤、输出和失败分支。
- 输出要么给人使用，要么给系统消费，格式不能随意漂移。
2. 引入边界：同时满足这些条件，才值得推进
只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。
- 当「SOP」能改变客服话术、故障归因、需求评审、测试用例生成、发布说明整理里的设计、评测或风险控制动作时，才值得进入方案。
- 适合把个人临场经验沉淀成团队可复用的 AI 工作流。
- 适合客服、研发、测试、运营等重复性文字和判断任务。
3. 反向边界：这些情况先停下来
专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。
- 没有 SOP 的流程，AI 只能放大个人习惯差异。
- SOP 过旧时，AI 会把过时流程自动化。
- 不要用 Prompt 掩盖流程不清、资料缺失、权限失控的问题。
- 不要让模型自由输出给系统消费，结构化输出必须校验。
- Prompt 改动没有版本记录，会导致线上质量变化无法复盘。
4. 上线前判断：能回答这些问题再落地
- 能写出 Prompt 模板：角色、目标、输入、约束、输出、失败处理。
- 能准备正例、反例、边界例，并用同一评测集比较版本。
- 现场追问：换一个同事来用，能不能得到差不多质量的结果？如果不能，说明流程还没写清。
架构师总结：先有流程，再谈 AI 自动化；没有 SOP，AI 只是在加速混乱。 对架构师来说，SOP 不是一个要背的名词，而是一把判断尺：先看前提是否成立，再看收益是否大于复杂度，最后看失败时有没有证据、兜底和责任人。
通用例子：先脱离技术看懂它
客服处理退款有固定流程，AI 只能在流程内辅助填写、查询和建议，不能随意改变规则。
这个例子要看见的重点：把一次性提问变成可复用流程。 所以例子不是为了记故事，而是为了训练你在新场景里做同类判断。
投影 / Android 实战推演
- 业务推演：投影 Android 业务里，可以把“用户反馈投屏失败”的 SOP 固化为：收集设备信息、确认网络、拉取日志、检索已知问题、生成排障步骤、必要时建研发工单。
- 你要补的证据：围绕「工作流」列出数据、文档、日志、用户反馈或人工标注，避免只凭感觉判断。
- 可交付物：沉淀 Prompt 模板、输入表单、输出结构、失败分支和版本记录。，让同事能照着复用，而不是只听你口头解释。
- 验收指标：至少选一个质量指标、一个效率指标、一个风险指标；比如正确率/一次解决率、定位耗时/追问轮次、误导用户率/转人工率。
- 迁移能力：同一套思路也能迁移到客服、测试、研发效率、运营分析和产品决策，不局限于投影业务。
老师会这样检查你是否真会了
- 你能不能用一句人话解释「SOP」，并说出它解决的是「工作流」里的什么问题？
- 你能不能举一个适用场景和一个不适用场景，并说明边界来自数据、流程、风险还是权限？
- 你能不能把它落到一个真实小任务：输入是什么、输出是什么、验收指标是什么、失败时谁兜底？
- 老师追问：换一个同事来用，能不能得到差不多质量的结果？如果不能，说明流程还没写清。
- 练习产物：选一个重复工作，写出标准输入、处理步骤、输出模板和异常分支，再考虑 AI 插在哪一步。
精通标准：先有流程，再谈 AI 自动化；没有 SOP，AI 只是在加速混乱。 能精通的人，不是能背定义，而是能把它迁移到一个新业务里，写出判断表、数据要求、风险边界和落地动作。
2. 质量指标
知识点讲解用采用率、返工率、节省时间、问题发现率衡量效果。
老师板书
质量指标
评测
质量指标让 AI 从“感觉不错”变成“证据不错”。
先用人话讲明白
质量指标是衡量 AI 输出是否可用的标准，包括正确性、完整性、可读性、可执行性、一致性和用户满意度。
类比可以把它理解成给一个聪明实习生写工作说明书：越清楚，返工越少。
为什么要学把好不好从感觉变成可比较的证据。
把关键词拆开看
- 任务指标：回答对不对、分类准不准。
- 体验指标：是否清楚、是否省时间。
- 流程指标：是否减少人工、是否提高处理效率。
入门版理解：用采用率、返工率、节省时间、问题发现率衡量效果。
适用范围和边界
1. 优先原则：先满足前提，再谈使用
在实际工程里，任何概念都不能脱离场景硬套。学习「质量指标」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。
- 先看它服务的专业判断是不是「评测」：把好不好从感觉变成可比较的证据。
- 任务有稳定流程，至少能写出输入、处理步骤、输出和失败分支。
- 输出要么给人使用，要么给系统消费，格式不能随意漂移。
2. 引入边界：同时满足这些条件，才值得推进
只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。
- 当「质量指标」能改变客服话术、故障归因、需求评审、测试用例生成、发布说明整理里的设计、评测或风险控制动作时，才值得进入方案。
- 适合把个人临场经验沉淀成团队可复用的 AI 工作流。
- 适合客服、研发、测试、运营等重复性文字和判断任务。
3. 反向边界：这些情况先停下来
专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。
- 单一指标会诱导模型优化偏，比如只追求简短会漏信息。
- 指标要能被采集，否则无法持续改进。
- 不要用 Prompt 掩盖流程不清、资料缺失、权限失控的问题。
- 不要让模型自由输出给系统消费，结构化输出必须校验。
- Prompt 改动没有版本记录，会导致线上质量变化无法复盘。
4. 上线前判断：能回答这些问题再落地
- 能写出 Prompt 模板：角色、目标、输入、约束、输出、失败处理。
- 能准备正例、反例、边界例，并用同一评测集比较版本。
- 现场追问：换一个同事来用，能不能得到差不多质量的结果？如果不能，说明流程还没写清。
架构师总结：质量指标让 AI 从“感觉不错”变成“证据不错”。 对架构师来说，质量指标 不是一个要背的名词，而是一把判断尺：先看前提是否成立，再看收益是否大于复杂度，最后看失败时有没有证据、兜底和责任人。
通用例子：先脱离技术看懂它
一个文档总结助手不能只看语句流畅，还要看是否漏掉关键风险、是否编造内容。
这个例子要看见的重点：把好不好从感觉变成可比较的证据。 所以例子不是为了记故事，而是为了训练你在新场景里做同类判断。
投影 / Android 实战推演
- 业务推演：投影 Android 场景里，AI 排障建议的质量指标可以包括：是否识别正确问题类型、是否引用正确版本文档、用户是否解决、是否减少客服二次追问。
- 你要补的证据：围绕「评测」列出数据、文档、日志、用户反馈或人工标注，避免只凭感觉判断。
- 可交付物：沉淀 Prompt 模板、输入表单、输出结构、失败分支和版本记录。，让同事能照着复用，而不是只听你口头解释。
- 验收指标：至少选一个质量指标、一个效率指标、一个风险指标；比如正确率/一次解决率、定位耗时/追问轮次、误导用户率/转人工率。
- 迁移能力：同一套思路也能迁移到客服、测试、研发效率、运营分析和产品决策，不局限于投影业务。
老师会这样检查你是否真会了
- 你能不能用一句人话解释「质量指标」，并说出它解决的是「评测」里的什么问题？
- 你能不能举一个适用场景和一个不适用场景，并说明边界来自数据、流程、风险还是权限？
- 你能不能把它落到一个真实小任务：输入是什么、输出是什么、验收指标是什么、失败时谁兜底？
- 老师追问：换一个同事来用，能不能得到差不多质量的结果？如果不能，说明流程还没写清。
- 练习产物：为一个 AI 功能设计 5 个质量指标，并说明每个指标从哪里采集。
精通标准：质量指标让 AI 从“感觉不错”变成“证据不错”。 能精通的人，不是能背定义，而是能把它迁移到一个新业务里，写出判断表、数据要求、风险边界和落地动作。
3. 版本迭代
知识点讲解记录 prompt 版本、失败案例和改进原因。
老师板书
版本迭代
运营
AI 迭代要像发版一样可追踪、可比较、可回滚。
先用人话讲明白
版本迭代是持续改进 Prompt、知识库、模型、工具和评测集的过程。AI 应用不是一次写完，而是靠反馈闭环变强。
类比可以把它理解成给一个聪明实习生写工作说明书：越清楚，返工越少。
为什么要学让 Prompt、知识库和模型变化可追踪。
把关键词拆开看
- 版本记录：每次改了什么要可追踪。
- 对比评测：新旧版本用同一批样本比较。
- 回滚能力：新版本变差时能快速退回。
入门版理解：记录 prompt 版本、失败案例和改进原因。
适用范围和边界
1. 优先原则：先满足前提，再谈使用
在实际工程里，任何概念都不能脱离场景硬套。学习「版本迭代」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。
- 先看它服务的专业判断是不是「运营」：让 Prompt、知识库和模型变化可追踪。
- 任务有稳定流程，至少能写出输入、处理步骤、输出和失败分支。
- 输出要么给人使用，要么给系统消费，格式不能随意漂移。
2. 引入边界：同时满足这些条件，才值得推进
只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。
- 当「版本迭代」能改变客服话术、故障归因、需求评审、测试用例生成、发布说明整理里的设计、评测或风险控制动作时，才值得进入方案。
- 适合把个人临场经验沉淀成团队可复用的 AI 工作流。
- 适合客服、研发、测试、运营等重复性文字和判断任务。
3. 反向边界：这些情况先停下来
专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。
- 不要在没有评测的情况下频繁线上改 Prompt。
- 只看成功案例会让迭代方向失真，失败样本更重要。
- 不要用 Prompt 掩盖流程不清、资料缺失、权限失控的问题。
- 不要让模型自由输出给系统消费，结构化输出必须校验。
- Prompt 改动没有版本记录，会导致线上质量变化无法复盘。
4. 上线前判断：能回答这些问题再落地
- 能写出 Prompt 模板：角色、目标、输入、约束、输出、失败处理。
- 能准备正例、反例、边界例，并用同一评测集比较版本。
- 现场追问：换一个同事来用，能不能得到差不多质量的结果？如果不能，说明流程还没写清。
架构师总结：AI 迭代要像发版一样可追踪、可比较、可回滚。 对架构师来说，版本迭代 不是一个要背的名词，而是一把判断尺：先看前提是否成立，再看收益是否大于复杂度，最后看失败时有没有证据、兜底和责任人。
通用例子：先脱离技术看懂它
Prompt 改了一句话后，如果没有版本记录和评测，很难知道线上效果变化来自哪里。
这个例子要看见的重点：让 Prompt、知识库和模型变化可追踪。 所以例子不是为了记故事，而是为了训练你在新场景里做同类判断。
投影 / Android 实战推演
- 业务推演：投影 Android 业务里，每次 App 发版、知识库更新、错误码新增，都可能影响 AI 助手。要记录模型/Prompt/知识库版本与 App 版本的对应关系。
- 你要补的证据：围绕「运营」列出数据、文档、日志、用户反馈或人工标注，避免只凭感觉判断。
- 可交付物：沉淀 Prompt 模板、输入表单、输出结构、失败分支和版本记录。，让同事能照着复用，而不是只听你口头解释。
- 验收指标：至少选一个质量指标、一个效率指标、一个风险指标；比如正确率/一次解决率、定位耗时/追问轮次、误导用户率/转人工率。
- 迁移能力：同一套思路也能迁移到客服、测试、研发效率、运营分析和产品决策，不局限于投影业务。
老师会这样检查你是否真会了
- 你能不能用一句人话解释「版本迭代」，并说出它解决的是「运营」里的什么问题？
- 你能不能举一个适用场景和一个不适用场景，并说明边界来自数据、流程、风险还是权限？
- 你能不能把它落到一个真实小任务：输入是什么、输出是什么、验收指标是什么、失败时谁兜底？
- 老师追问：换一个同事来用，能不能得到差不多质量的结果？如果不能，说明流程还没写清。
- 练习产物：建立一张迭代表：版本号、改动内容、评测结果、线上观察、是否回滚。
精通标准：AI 迭代要像发版一样可追踪、可比较、可回滚。 能精通的人，不是能背定义，而是能把它迁移到一个新业务里，写出判断表、数据要求、风险边界和落地动作。
学习产出
一个可复用的文档/代码/测试 Review Agent 工作流
10 分钟练习
把一个 prompt 改成团队 SOP，包括谁用、何时用、怎么验收。
老师怎么判断你学会了
提交作业交一份 AI 工作流 SOP 和前后对比指标。
- 合格别人能照着用。
- 优秀能证明节省时间或降低返工。
- 没通过只有个人收藏的 prompt，没有复用和指标。