黎小葱我最早意识到自己的“技术护城河”不够用，是在一次AI项目评审会上。我拿着PRD讲用户需求，研发负责人问了一句：“这个AI生成的结果，你准备用什么指标判断好坏？如果模型输出错了，回退逻辑是什么？”我当时愣住了。作为一个产品经理，我能描述体验、画流程图、写需求文档，但面对“AI这种根本不按套路输出的系统”，我发现自己判断不了它到底行不行。
后来我花了大半年时间补课，慢慢悟明白一个道理：产品经理跟AI打交道，真正需要的不是会写代码，而是具备Engineering思维。这里的Engineering不是“工程师专属”的意思，而是一套把不可控变可控、把感性判断变可度量结果的方法论。掌握之后，你会发现AI不再是一个“神秘的盒子”，而是一个可以通过输入、输出、反馈和约束来管理的系统。
这篇文章就把我自己的实践经验完整拆开，适合正在跟AI工具、AI Agent、提示工程打交道，但又不知道怎么系统化落地的产品经理和项目负责人。我会从为什么需要Engineering思维讲起，再到Prompt写作、Loop Engineering、评估测试集、Harness Engineering，最后附上我踩过的坑和排查思路。内容都是可复现的，你可以直接抄作业。
1. 为什么产品经理必须先建立“Engineering思维”
1.1 AI不是魔法，是系统
很多产品经理接触AI的第一反应是“它很聪明”，第二反应是“它有时候很蠢”。这两种感受加在一起，就很容易让人把AI当成一个薛定谔的工具：好用的时候夸它，出错的时候骂它，但始终搞不清它为什么会这样。
这就是典型的“黑盒思维”。而Engineering思维的第一步，恰恰是拒绝把一个系统当黑盒。你不需要理解Transformer里面的注意力机制，但你一定要理解：AI的每一次输出，都遵循一个最基本的链路——输入、处理、输出、反馈。产品经理要管的不是模型内部的数学，而是这条链路每一环你能不能控制、能不能观测、能不能修正。
我打个比方。你带过一个实习生，他工作不稳定，心情好的时候产出优秀，心情差的时候漏洞百出。你怎么管理他？你不会每天抽签碰运气，你会给他明确的任务目标（定义输入），拆分工作步骤（控制过程），要求他交付前自查（检查输出），出了问题复盘（反馈修正）。管AI，本质上就是管一个能力很强但纪律性很差的实习生。区别在于，AI没有情绪，但AI有概率性——同一个提示词，它每次回答都可能不一样。这个特性决定了，你必须有系统方法来兜底，而不能只靠一句“你再试一次”。
1.2 拒绝“凭感觉调参”：把玄学变成可复现的实验
产品经理最常犯的一个错误，是拿着AI对话窗口反复改提示词，改到某一版输出看起来不错就说“成了”。但第二天再打开，同样的提示词，出来的结果完全变样，然后就陷入“改词—试—再改—再试”的恶性循环。
这是典型的“感觉驱动型调参”，之所以会失败，是因为你根本没有区分两个问题：提示词本身的质量，和模型这次抽样的运气。比如你让AI写一段产品介绍，它可能这次写得通顺，下次写得啰嗦。你以为是你加了一个词起的效果，实际上可能只是随机性带来的波动。在这种情况下，你根本没法判断自己到底改对没有。
Engineering思维告诉我们，任何优化都必须基于可重复的实验。你改了一个变量，其他条件必须保持不变，然后跑多次结果，看统计趋势，而不是看单次效果。这套思路说起来简单，但我在实际项目里看到90%的产品经理都没有做到。他们甚至不会记录自己改了什么提示词，更不用说做A/B对比了。
我当时给自己定了一条规矩：每次修改Prompt，必须记录版本号、改动内容、测试时间和测试结果。没有记录的修改，一律视为无效操作。这条规矩很笨，但它直接把我从“AI玄学”里捞了出来。
1.3 产品经理需要借用的四件工程工具
如果你不是工程师背景，完全不用慌。Engineering思维并不等于写代码，它本质上是四件工具的集合：
第一件叫作“拆解”。把一个大任务拆成小块，每个小块都能单独验证。比如“让AI帮我写一份季度汇报”是个大任务，但“先让AI提取数据要点—再让AI按STAR结构写初稿—再让AI压缩到500字”是三个可以分别测试的小任务。
第二件叫作“版本控制”。你对AI说的每一句话，都应该像代码一样有版本。改Prompt不只是复制粘贴，要留档。今天我用的Prompt版本是v1.3，明天改成v1.4，我清楚知道改动在哪里，效果差异在哪里。
第三件叫作“测试用例”。你的AI功能应该有固定的验收题目。就像测试工程师用一组用例验证软件一样，你也应该用一组输入，反复验证AI的输出是否合格。没有测试用例的AI功能，上线就是碰运气。
第四件叫作“护栏”。工程系统都有异常处理机制，AI系统更需要。超时怎么办？输出不合格怎么办？超出合理范围怎么办？你要预设这些异常，而不是出了问题再救火。
这四件工具，就是我说“技术护城河”的底气所在。它不是让你去跟工程师比谁代码写得好，而是让你在AI项目里拥有自己的判断尺子。当你能说出“这个Prompt版本比上一个在测试集上准确率提升了8%”的时候，你在团队里的话语权是完全不同的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 用Engineering思维拆解AI能力：从Prompt到Agent
2.1 Prompt Engineering的结构化写法：把对话框当接口
很多人以为Prompt Engineering就是“会说话”，这可能是最大的误解。你要是把AI对话框当成聊天窗口，那你的Prompt就永远停留在“人机闲聊”的层面。但如果你把对话框当成一个接口，你就会开始思考：这个接口接收什么参数，返回什么格式，出错时怎么提示。
我用的是三段式结构，效果稳定很多：角色与目标、上下文与约束、输出格式要求。
先看角色与目标。你要明确告诉AI它扮演什么角色，以及你要达成什么目标。比如“你是一名资深SaaS产品专家，请帮我评估一个需求的价值。”这句话看起来简单，但它能显著影响回答的深度和语气。我自己实测下来，给了角色之后，AI输出的结构化程度明显提高。
再看上下文与约束。这是产品经理最容易遗漏的部分。AI不知道你的产品背景，不知道你的目标用户，不会读心术，你必须在Prompt里把所有关键背景写清楚。比如你要写一份用户调研问卷，你得告诉AI：目标用户是中小企业的HR，他们的核心痛点是招聘流程繁琐，问卷最多10题，每题选项不超过5个。这些约束，就是AI回答的边界。
最后是输出格式要求。如果你要的是一份表格，就直接写“请以Markdown表格输出，包含三列：优先级、需求描述、预估工作量”。如果你要的是JSON数据结构，就明确告诉AI字段名和类型。AI非常在意指令的明确程度，你写得越像接口文档，它返回的东西就越规整。
我自己还有一个习惯：在Prompt后面加一句“如果你觉得信息不足，请先列出你需要补充的问题”。这句话能大幅降低AI瞎猜的概率。很多AI输出跑偏，不是因为它笨，而是因为它太“配合”了——信息不够它也硬答。你要允许它说“我不知道”，这在工程上叫作“让系统具备失败提示能力”。
2.2 用版本管理和测试用例管理Prompt
Prompt进入版本管理，是一个产品经理成熟的标志。操作上一点不复杂，你不需要上什么专业工具，就是建一个文件夹，每个版本一个文件，命名规则用日期加版本号。比如20250420_demand_analysis_v1.3.md，里面写好改动日志。这样你就可以回答老板的灵魂拷问：“这个功能为什么效果变差了？”你可以直接翻出历史版本对比，而不是支支吾吾说“可能是模型更新了”。
但你可能会问：“如果有时候不是Prompt变了，而是模型自己更新了，导致输出变化，怎么办？”这个问题我确实遇到过，而且当时困扰我很久。解法是：保留历史测试结果，形成基线。当你发现某个Prompt版本过去的测试结果是90分，今天突然变成70分，而你对Prompt没有做过任何改动，那大概率就是模型端发生了变化。这时候不是忙着改Prompt，而是先确认模型版本和参数配置。我在实际项目里维护一个简单的Excel表，记录每次测试的日期、Prompt版本、模型版本、测试得分，一查便知。
测试用例方面，我建议产品经理为每个AI功能准备20到50条固定输入。这个量级不需要太多，但覆盖面要够。比如你做客服摘要功能，测试用例里至少要有：正常咨询、复杂投诉、多轮对话、英文夹杂中文、用户发了不相关消息、用户情绪激烈等典型情况。你不一定每条都要人工写标准答案，但至少要有一个可接受的判断标准。然后把AI的输出人工打一个“通过/不通过”，再定期回放全部用例，看有没有回归问题。
这套做法看起来麻烦，却是我在项目中反复验证过性价比最高的投入。有了版本记录和测试集，你就有了跟研发平等对话的基础。你提的需求不再是“我觉得AI说得不对”，而是“我这边测试集里3个用例回归不通过，请你帮忙排查”。这种表达方式，工程师一听就懂，而且会当成正经问题对待。
2.3 从单轮Prompt到Loop Engineering：让Agent闭环干活
当你开始用AI Agent而不是单次对话时，局面又不一样了。Agent的特点是可以自主执行多步任务——它先规划，再调用工具，再根据结果决定下一步动作。这种自主性带来了巨大的能力，但同时也带来了巨大的失控风险。这时候你需要用到的概念，就是热词里的Loop Engineering。
Loop Engineering，简单说就是管理AI的循环过程。你可以把一个Agent的任务拆成“计划—执行—检查—修正”四步循环，并用工程手段控制每一轮循环什么时候开始、什么时候结束、最多循环几次、什么情况下必须停下来求助。
举个例子，我做过一个需求分析Agent，它的任务是把客户反馈自动转化成需求池。如果我只写一个Prompt让它“帮我整理一下这些反馈”，它给出的结果永远是泛泛而谈。但如果我用Loop思路设计，任务就变成了一步一步的流水线：先让Agent读取反馈原文并提取关键标签；再让Agent对照已有的需求分类标准做映射；然后把不确定的条目单独挑出来，再次循环让Agent给出置信度和理由；最后通过一个质量校验模块检查是否有遗漏和重复。
这中间每一轮循环，我都设置了检查和退出条件。比如“不确定的条目不能超过5条，超过就停止处理，转入人工”。这就是把“AI猜答案”替换成“AI在自己的能力边界内干活，超出边界就交还给人”。我觉得这是产品经理驾驭Agent最重要的心法：不要追求AI一次做对，而要追求AI在出问题时能被人及时发现和控制。
这里顺便说一下Harness Engineering，它本质上是在AI外围加一个“套笼头”的控制层，也就是护栏体系。Loop Engineering处理的是Agent的内在循环，Harness Engineering管的是外在约束。好的产品设计方案，会同时考虑这两个层面：既能跑，又不会跑飞。
3. 把AI接入产品流程的实操方案
3.1 先定义评估指标：可量化、可回归
我接触过的很多AI产品项目，最大的问题不是模型能力不行，而是团队压根没定义清楚“什么叫表现好”。产品经理说“效果还行”，研发说“准确率还可以”，测试说“有些问题但不好判断”。这种各说各话的局面，根源就在于缺少统一的指标口径。
做AI评估，我建议先分清三类指标：质量类、体验类和成本类。质量类指标衡量输出本身的正确程度，比如信息完整率、忠实度（有没有编造内容）、格式合规率；体验类指标衡量用户感受，比如响应速度、可理解性；成本类指标衡量整个AI链路的资源消耗，包括模型调用费用和延迟。
这三类指标要怎么落到实际项目里？以“AI总结用户需求”这个功能为例，我的评估表可能是这样的：
| 指标维度 | 具体指标 | 目标值 | 计算方式 |
|---|---|---|---|
| 质量 | 关键信息覆盖率 | ≥95% | 人工核对AI总结是否包含原文的必含要点 |
| 质量 | 幻觉率 | ≤2% | 人工标记AI总结中原文不存在的信息占比 |
| 体验 | 单次生成平均耗时 | ≤3秒 | 从调用到返回全链路计时 |
| 成本 | 单次调用成本 | ≤0.05元 | 计费平台数据汇总 |
定了指标之后，产品经理在项目里的动作就完全变了。你不再是“催研发快点儿”，而是“现在召回率达到目标了，但幻觉率还超标，需要优先解决”。这种表达方式，能帮你直接切入优先级排序和资源协调，而不是困在模糊的“效果不好”里。这是Engineering思维给我的最大回报之一。
3.2 搭建小规模评估测试集：给AI做回归测试
做软件的都知道回归测试，但很多人做AI产品时，却完全忘了这一套。你还记得上一次更新模型版本或改Prompt后，原来的功能突然变差的经历吗？如果没有固定的测试集，你是发现不了这些回归问题的。
我自己搭建评估测试集，分为三步。
第一步，收集真实历史输入。这是最宝贵的数据来源。把过去三个月用户真实发给AI的请求整理出来，挑选有代表性的，脱敏后存成固定文件。注意一定要用真实数据，而不是你自己编的题目。真实数据里才有各种你没预料到的表达方式。
第二步，给每个输入标注“标准答案”或“可接受标准”。这一步比较费人工，但值得做。产品经理可以自己完成第一版标注，然后邀请研发和运营同事复核。标准不一定要很长，但必须能判断“通过/不通过”。比如对于自动摘要任务，标准就是“AI输出是否包含用户名字、问题类别、紧急程度这三个关键要素”。
第三步，定期跑回归并记录结果。我建议每修改一次Prompt、每换一次模型版本，都跑一轮测试集。跑完之后把结果记录到表格里，注意保存每次测试的原始输出。这样以后争议出现时，你能拿出来回看，而不是凭记忆争论。
很多产品经理觉得50条测试用例太少，不放心。但就我的经验，先有20条能用起来，比没有强100倍。测试集是可以持续扩充的，重要的是你先建立起来“每次变更都有验证”的节奏。
3.3 用Harness Engineering的思路给AI“套笼头”
Hot search term中经常出现“harness engineering”，这个词在AI产品里的含义，直白地说就是给AI套上约束和护栏。很多AI功能刚上线时表现不错，用着用着就出事，往往不是因为模型变笨了，而是因为当初根本没设计护栏。
我会从四个层面给AI上护栏。
第一层是输入护栏。用户发给AI的内容，不是什么都该直接进模型的。比如你做一个公网产品，要防住用户输入里可能让人尴尬的内容或恶意指令。做法是在输入侧做关键词过滤、长度限制、敏感信息拦截。你别小看这些基础操作，它能把大量垃圾请求在进入模型之前就挡掉，既保护安全，又节省成本。
第二层是输出护栏。AI生成的内容，不能直接展示给用户。必须要经过一道校验关卡，比如检查是否包含用户不应看到的联系方式、是否出现明显与主题无关的内容、是否超过规定的长度。我习惯用规则加模型双重校验：先跑简单规则快速过滤，再过一次成本较低的分类模型做兜底。工程上这叫分级校验，效果好且省钱。
第三层是权限护栏。AI Agent要调用外部工具时，你务必控制它能干什么。比如Agent可以读数据库，但不能删除数据；可以调用接口，但不能修改核心配置。这就像给员工发门禁卡，只开放必要区域的权限。没有权限控制的Agent，就是在你的系统里放了一个开盲盒的能力，出事的概率只是时间问题。
第四层是人工确认护栏。对于高风险动作，AI只能给出建议，最终执行必须由人来确认。比如自动生成合同条款后的付款操作、自动回复客户中的退款承诺，这类动作务必加一道人工审批。技术再成熟，我也建议你保留这一步，因为你不能用用户信任去赌模型的稳定性。
3.4 落地真实场景：客服、内容生成、数据分析
光讲方法论不够，我拿三个真实场景举例，你看完就知道怎么套用前面的思路了。
第一个是智能客服摘要。这个场景在很多公司都在做，但做得好的不多。最常见的问题是：AI把用户说的话总结得很通顺，但漏掉了关键信息。你用Engineering思维拆解，就会发现关键是定义“关键信息”是什么。我当时和业务方一起确定了七个必含字段：用户ID、产品线、问题类型、情绪等级、是否复购意向、建议处理方式、紧急程度。然后我写了严格的输出校验规则：AI输出里缺少任何一个字段，都判定为不合格，直接触发重新生成或转人工。这样一来，“AI总结好不好”就从主观感受变成了“七个字段有没有齐”，可测可回归。
第二个是内容批量生成。有一次我们要给几百个客户写个性化的运营文案，如果靠人写，三周都写不完；如果直接丢给AI批量生成，又可能会出现某些文案里编造客户信息的情况。我的处理方式很朴素：用模板加变量。把文案拆成固定框架，AI只要负责生成中间可替换的创意段落，客户名称、历史订单、优惠金额这些关键变量全部由程序填入，AI完全碰不到。这样既保留了生成内容的多样性，又切断了幻觉数据进入业务系统的通路。这件事让我深刻理解了一个道理：不要给AI能力范围之外的自由度。
第三个是数据分析辅助。AI可以帮你把Excel里的数据生成摘要，但如果用户直接上传一个文件让AI自由总结，那输出的质量就是碰运气。我的做法是让AI只能面向固定的数据表格提问，并且把可分析的指标提前列在白名单里，比如销售额、转化率、客单价、复购率，超出白名单的指标一概拒绝分析。另外我会在输出的末尾强制附上“数据来源与统计口径”字段，确保用户能看到AI的判断依据。这本质上就是给AI限定工作半径，防止它跳出数据瞎编。
这三个案例背后，全是同一套思路：明确任务边界、定义合格标准、控制信息流、加人工兜底。AI能力本身决定上限，但产品经理的Engineering思维决定这个项目实际能达到多少分。
4. 常见问题与排查技巧实录
4.1 现象：AI回答不稳定，同一句话两次结果差很大
这个问题基本每个用AI的人都遇见过。我第一次遇到的时候很慌，以为是哪里配置错了，后来才明白，这是AI的天然特性：采样过程有随机性，尤其是在模型“温度”参数调高的情况下，输出的多样性会成倍增加。
排查这个问题的思路，不是“消灭随机性”，而是“确定可接受范围”。你可以先把AI的随机参数调低，比如温度设为0到0.3，让输出更稳定。如果你的产品场景需要多样性，比如标题生成、文案创意，那就要在Prompt里明确“请给出三个风格不同的版本”，然后把“多样性”作为预期行为管理起来。
同时，稳定性和质量不是一回事。有时候你觉得AI回答“变了”，可能只是语气变了，关键信息都在，那这属于正常波动；但如果关键信息变了，那你就要检查上下文是否完整、输入是否有歧义。我的习惯是，遇到不稳定的情况，先固定问题跑五遍，把五份输出做个对比，再判断是信息层面变了还是表达层面变了。这个排查动作很简单，却非常有效。
4.2 现象：AI Agent跑飞了，陷入循环或乱改数据
AI Agent跑飞，是比单次输出不稳定更严重的问题。它表现为Agent不断自己调用自己，迟迟不结束；或者它越过了权限边界，干了你不希望它干的事。
排查思路要先分两类：是Agent的逻辑循环，还是行为越界。逻辑循环的典型表现是，Agent在“检查结果不满意—重新执行—再检查—再执行”中出不来。这往往是因为你没有一个退出条件。我之前那个需求分析Agent就出过这种事，后来我硬性规定了两条铁律：最多允许Agent循环三次，超过就停止并把中间结果交给人工；每次进入下一轮之前，必须先输出一个简短的理由说明“上一轮哪里不合格”。有了这两个机制之后，跑飞问题基本消失。
行为越界又是另一回事。如果你发现Agent调用了你禁止的工具，那问题大概率出在权限设计上，而不是Prompt写得不好。你要检查这个Agent挂载的工具权限清单，确认它有没有可能通过别的途径访问到受限资源。我的经验是：在系统设计上，就按“最小权限原则”给Agent配工具，而不是指望它在运行时自我克制。你自己可以测试一下，让Agent执行一个明显越界的请求，看它会不会拦截，就知道护栏有没有用。
4.3 现象：评估指标提升了，但用户反馈变差了
这是一个特别值得警惕的情况，很容易让你误判项目健康状况。我自己就遇到过：测试集准确率从80%提到了92%，结果上线后用户投诉反而增加了。一开始我百思不得其解，后来拉数据看到了真相——我们的测试集太“干净”了，全是标准提问，但真实用户的问题充满了错别字、口语化表达和上下文省略。AI在标准问题上的表现优化了，在面对这些“脏输入”时反而变笨了。
根因在于评估集跟真实数据分布脱节，你测的东西不是用户真正用到的。解法也很简单：持续收集线上真实输入，定期把它们补充到测试集里。我更推荐你直接建一个线上反馈通道，用户在AI回复下方点“有用/没用”，然后把“没用”的记录自动流入评估池，每周挑出新增的失败案例补充进测试集。这样测试集就会跟着真实情况一起演进，你的指标才真正有意义。
另一个可能的原因是，你优化的指标跟用户价值不一致。比如你为了降低延迟，把回答压缩得更短，结果用户觉得信息不完整。这时候指标本身没有错，错在你只盯住了单点指标，忽略了全局体验。我的建议是，每次指标优化都要同时检查跟它相关的上下游指标。延迟降低了，完整率有没有下降？成本降下来了，用户满意度有没有波动？你要用“指标组合”来看效果，而不是孤零零地看一项。
4.4 现象：改一个Prompt，另一个功能也跟着变坏了
这个坑，凡是维护过AI应用的人应该都踩过。你可能同时维护好几个AI功能，共用一个模型或者一套底层Prompt变量。某天你为了优化A功能的Prompt，加了一个新要求，结果B功能的输出也变了。
问题就出在“共用依赖”上。AI不像传统代码，你在一个地方改了全局变量，影响范围可能完全看不见。我的解法很土但很踏实：每个功能的Prompt都进行独立的版本管理，绝不共用一套通用Prompt。共享的部分可以抽成固定不变的“公共说明”，但每个业务功能的特定指令必须独立成文件。所有功能在修改之后，都跑一遍自己的测试集，不光跑改过功能的，也要跑相关功能的，确保没有回归问题。
我还有个习惯，就是重大修改前先拉一条“分支”出来。就像Git分支一样，不在稳定版本上直接改，而是复制一份做实验，实验确认有效之后再合并到正式版本。这个习惯帮我躲过了好几次事故。你不需要用多复杂的工具，复制一个文件改名就行，重在养成“先验证再上”的习惯。
5. 最后分享几个让我少加班的小习惯
既然讲到这儿了，我把最近常用的几个工作习惯一并分享出来，虽然单看都很简单，但它们确实帮我少加了不少班。
第一个习惯是“所有AI对话都要留痕”。我截屏、复制、归档，所有重要的调试过程都留档。可能短时间内看不出价值，但等到要复盘的时候，你会发现留痕是最大的救命稻草。尤其是项目做了三个月后，你会面临“当初为什么要这么设”的灵魂拷问，有记录就能回答，没记录就只能干瞪眼。
第二个习惯是“给每次Prompt修改写一句话的理由”。不用写多，一句话就行，比如“把输出要求改为表格形式，因为有下游系统需要解析”。这句话会逼着你想清楚改动背后的逻辑。如果写不出来，说明这次改动就是瞎试的，不如不做。我以前瞎试的Prompt一大堆，后来回头看，绝大多数都没有真正改善效果，真正有用的改动，都是我能清晰说出理由的改动。
第三个习惯是“周期性地做一次AI能力盘点”。我会每隔一个季度，用一个固定的模板重新测试所有在用的AI功能和Agent，然后更新一张状态表，记录哪些指标下降、哪些能力升级、哪些场景可以切入。很多产品经理把AI能力当成一成不变的，实际上模型更新的频率很快，你不复测就发现不了能力变化，由此带来的机会和风险，迟早都会变成事故。
我在这个过程里还有一个很深的体会：技术护城河的本质，不是比别人多知道几个工具或几个命令，而是你能比别人更稳定地交付结果。AI时代的一个真相是，工具会过时，模型会迭代，但你掌握的那套“定义问题—拆解任务—建立评估—控制风险—持续回归”的方法论，会一直有效。只要这套核心方法在你手里，换任何模型你都能快速上手，AI能力再强的模型也不会干扰你的判断力。
刚才说的那些案例，大部分都是踩坑踩出来的教训。我踩得多了之后，反而觉得AI项目跟传统项目最大的不同，就是你永远不可能拿到一个“完美的模型”再开工，你只能在约束条件下不断逼近目标。想清楚这一点，你就不会再把“效果不好”当成灾难，而是会把它当成一个正常信号去分析、去拆解，一步步用工程手段修复。这套思维，会慢慢变成你的本能反应。