// Shared content + sizing for all 5 directions. // One placeholder identity so each direction can render with real-feeling // content; user can rename via tweaks if they want. const ARTICLE_BODIES = { 1: `## 1. 为什么微调不是最优选择？因为最优选择可能不是它 做AI产品这两年，我见过最多的场景就是：团队一上来就说"咱们微调一下模型吧"。好像不微调就显不出技术含量似的。可问题在于，绝大多数时候，微调的钱花得真不值。我做过一个项目，业务方想用大模型做客服问答，一开始就奔着微调去，花了十几万，调了两周，结果上线后用户问个"退款流程"，模型直接编了个不存在的政策。后来换成RAG——就是检索增强生成，简单说就是把知识库当外挂，模型不懂就去查——不仅回答准确了，还省掉了每次业务调整都要重新微调的苦力。 基础模型本身已经很强了，GPT-4、Claude 3.5这些，通用知识、推理能力摆在那里。你非要拿它去微调一个特定领域的任务，很容易给它"调傻了"。比如你只拿客服对话数据微调，模型可能就忘了怎么跟人聊天气、写邮件，能力范围越变越窄。我管这个叫"过拟合的诅咒"——你以为它在变聪明，其实它在变笨。做过产品的人都懂，一个能力缩水的模型，后期维护成本比你省下的那点训练费高得多。 从产品角度看，微调应该永远是最后手段，而不是默认选项。先问问自己：提示工程能不能解决？能不能在prompt里塞几个例子、加一段系统指令？大部分场景，80%的问题其实靠精心设计的prompt就能搞定。比如我们之前做一个文档摘要功能，团队想微调，我拦住了，只是在system prompt里写了"请用三句话概括，第一句说结论"，效果一样好，迭代还快——改prompt几分钟，微调一轮至少半天。 我不否认微调在某些场景下的价值，比如你要让模型学会一种全新的表达风格，或者处理极其专业的术语。但那样的场景，说实话，100个产品里未必有10个。微调的门槛被严重低估了——不是技术门槛，而是决策门槛：你真的需要为了那10%的效果提升，付出90%的灵活性代价吗？至少在我做的产品里，答案越来越清晰——不调，才是更聪明的选择。 ## 2. 最小可行方案：用提示工程解决80%的问题 做产品六年，我踩过最深的坑就是动不动想微调。刚碰AI那会儿，接到任务第一反应就是"得训个模型吧"，好像不调一下就不配叫AI产品。直到有一次做客服意图分类，团队花了两周准备数据、跑微调，上线后准确率还不如一个写了两小时的提示模板。那个模板只有三条示例，零训练成本。从那以后我学乖了——先问自己：提示工程能搞定不？ 提示工程听着玄乎，做起来其实特实在。核心就三件事：把任务说清楚、给几个好例子、定好输出格式。去年我们做合同条款提取，业务方要从2000份PDF里抽关键日期和金额。我让实习生先写个提示，配上GPT-4的API跑了一轮，准确率直接到了87%。业务方挺满意，说够用了。剩下的13%是格式不一致和漏提取，后来加了两轮few-shot就提到了94%。从头到尾，没花一分钱算力，没等一天训练时间。 有人会问，那剩下的20%咋办？我信奉先跑通再优化。最小可行方案的意义，不是让你永远停在80%，而是用最小成本验证"这事能不能做"。如果提示工程就能覆盖核心场景，那微调的钱和时间完全可以花在更关键的地方——比如打磨产品体验，或者搞定那20%里真正影响用户体验的少数case。我见过太多团队上来就微调，调完发现业务需求变了，又得重调，钱烧了，人累了，产品还没上线。 所以我现在带团队有个硬规矩：任何新任务，至少用提示工程跑一周再说。不试够一周，不准提"微调"二字。这一周里，你要迭代提示、收集bad case、看真实效果。很多时候，一周后业务方自己就说了："好像够了，先上吧。"到这一步，你已经用最小成本锁定了80%的价值。剩下的可以慢慢优化，甚至可以等模型本身升级——毕竟大模型迭代这么快，说不定下个版本就自动搞定了。 ## 3. 最优可行方案：知识蒸馏或小模型适配，比全量微调聪明 聊个去年的项目吧，印象太深了。客户要做法律咨询助手，模型得准确引用法条，还得区分不同司法解释。团队里有人直接喊：微调一个7B大模型吧，效果好！我掰着手指头算了笔账：租A100，训一周，加上数据标注和迭代调试，光这一轮就得小十万块。而且呢，业务一调整——比如新增个司法解释——又得重来，成本根本兜不住。后来我们换了个路子：用GPT-4生成一万条高质量问答对，拿去训练一个300M的小模型，再搭个检索系统补知识。结果呢？准确率只比大模型微调低了2%，但推理速度快了一倍，训练成本不到原来的十分之一。业务团队两个月就上线了，到现在跑得稳稳的。 这事让我彻底想通了：最优可行方案，从来不是技术最炫的那个，而是让业务团队能最快用起来、成本可控的那个。知识蒸馏就是典型——用大模型当老师，教一个小模型学会核心能力，学生模型跑起来又轻又快。你不需要把整个大模型的能力都保留，只蒸馏出业务需要的那些知识。比如客服场景，只蒸馏意图识别和话术匹配，其他能力砍掉，模型体积能缩小十倍，部署成本直线下降。 如果必须保留大模型架构，那也得选参数高效微调，比如LoRA。LoRA的做法是冻结原始权重，只训练一小批低秩矩阵，参数量通常只有全量微调的1%到2%。我见过一个团队做代码补全，全量微调一个CodeLlama 7B要花12小时，用LoRA加个适配器，1小时就训完，效果几乎没差别。关键是业务调整时，你只需要换一个适配器文件，不用动基座模型，迭代成本极低。 所以我的判断是：如果业务场景需要模型具备特定能力，先别急着全量微调。优先试蒸馏，用小模型跑；不行再上LoRA这类轻量方法。把全量微调当作最后一张牌，轻易别打。这样你的预算能省下一大半，留给真正需要深挖的环节——比如数据质量、评测迭代。业务团队不用等几个月，几周就能看到效果，他们开心，你也省心。 ## 4. 省钱的哲学：把微调预算砍掉一半，业绩反升 六年产品，两年在AI上。掏心窝子的话：微调预算砍一半，业绩反而往上窜。不是玄学。去年一个项目，团队八成钱砸微调里，模型来回刷了三轮。效果？不到5%。我直接叫停后续微调，把钱扔到数据清洗和用户反馈上。三个月后，用户满意度涨了12%。微调的边际收益，跌得吓人。第一轮能涨20%，第二轮就10%，第三轮只剩3%。越往后投，每分钱越不值。 过早搞微调，跟产品没验证需求就急着扩团队一个德性。我见过太多团队，模型刚跑通基线，领导一拍大腿：调一调吧。结果一调两个月，业务逻辑早变了，调出的权重全废。更坑的是沉没成本陷阱。你砸了50万，舍不得停，又追100万，最后模型过拟合到连训练数据里的噪声都记住了。用户吐槽它像复读机，团队还在那分析：是不是学习率没调好？不是，方向压根就错了。 省下的钱去哪？我倾向投数据质量。同样一批语料，清洗掉30%的垃圾、去重、做对抗样本，效果提升比再训一轮微调明显得多。用户体验优化也是好去处。比如给大模型加个校验层，或者把回复速度从3秒压到1秒。用户能直接感受到，微调后的参数调整，他们多半无感。去年我们砍了40%的微调预算，全砸在数据标注和A/B测试工具上，业务指标硬是涨了8%。 所以现在我看项目，第一反应不是能不能调，而是能不能不调。微调不是不能做，但你得想清楚：这笔钱投下去，换来的到底是什么？如果只是几个百分点的准确率提升，而用户压根不在乎，那就不如省下来。省钱的本质不是抠门，是把钱挪到产出更高的地方。做AI产品两年，我最庆幸的，就是学会了说不调。`, 2: `## 1. 为什么你总感觉AI"不够聪明"？ 做产品6年，我见过太多团队把AI当"万能插件"——随便接个API，丢进去就跑，然后抱怨"这模型怎么这么笨"。说实话，问题多半不在模型，而在你选错了工具。我自己试过几次就发现，不同模型之间的差距，大得离谱。比如写长文，Kimi生成的内容结构清晰、细节丰满，而且特别贴合中文语境，像给你配了个熟悉本地市场的助手。可换Claude，同样一篇行业分析，它写出来的东西总带点"翻译腔"，逻辑虽好，但读着就是隔了一层。这不是Claude不行，是它在中国市场的长文书面上，确实有点水土不服。 很多人觉得AI模型差不多，反正都是大语言模型，随便用哪个都行。真不是。我拿写竞品分析测试过：Kimi给出的内容很全，从市场格局到用户痛点，一条条列得明明白白，性价比高得让人意外。Claude呢？它擅长深度推理，但面对中国互联网产品那种复杂的运营逻辑和本土化表述，它经常抓不住重点——不是它不聪明，是它不熟悉这个"场"。选错模型，就像拿锤子拧螺丝，白费力气不说，拧出来的东西还歪。 所以当你觉得AI不够聪明时，先别急着给它下结论。回头想想：你给它安排的任务，是不是它擅长的类型？写长文档、做中文竞品分析，Kimi往往比Claude更对路；反过来，如果你要处理复杂的逻辑推演或英文材料，Claude又可能是更好的选择。选型这件事，真不能偷懒——我踩过的坑多了，才慢慢悟出来：不是模型不好，是你没把它放在对的位置上。 ## 2. Kimi写长文到底好在哪？我的实测对比 去年年底我给团队定新季度规划，需要一份万字级的竞品分析报告。顺手拿几个主流模型都试了一遍，结果很有意思。Claude 写到六千字左右就开始绕——原本在讲功能对比，突然又倒回去解释背景，像一个人说着说着忘了刚才说到哪。GPT-4 稍微好点，但长段落的逻辑衔接偶尔会丢，得手动调。 反而是 Kimi，我给了它一份将近两万字的行业白皮书当参考，它拆出来的框架特别干净。五级标题，每个部分的内容密度均匀，没有一段突然膨胀、另一段只有两行的情况。更让我意外的是段落之间的过渡——上一段刚分析完用户画像，下一段自然就落到需求痛点，中间不需要我补"上文提到"这种废话。 我大概数了一下，那篇报告 Kimi 写了九千多字，核心观点一个没漏，也没有出现重复的车轱辘话。后来我拿同一份需求提纲又测了三次，每次输出的结构都很稳。对做产品的人来说，这种"不跑偏"的能力，比单纯的字数堆砌重要得多。 ## 3. 竞品分析：为什么Claude不是万能钥匙 我承认，Claude在逻辑推理上确实有两把刷子。有一次我拿它和Kimi同时做一款社交产品的竞品对比，Claude能精准列出功能差异、版本迭代时间线，甚至指出某竞品近期融资后的战略转向。这些硬核分析，Kimi当时还做不到那么细。但问题来了——当我想让它把这堆分析写成一份完整的竞品报告时，它就开始掉链子。字数一多，逻辑链条就松了，前面说A功能强，后面对比表里却漏了A，得反复调。这让我觉得，Claude更适合做那种"问一句答一句"的短篇问答，而不是动辄几千字的长篇报告。 我不止一次在内部吐槽：Claude有时候太"乖"了。它能准确复述事实，但很少给出那种让我眼前一亮的洞察。比如分析某巨头的新功能时，Claude的结论通常是"该功能增强了用户粘性"——对，但谁不知道呢？换成Kimi，反而经常蹦出"这个功能其实在抄三年前XX产品的失败案例，只是换了个入口"这种带风险判断的观点。当然，Kimi有时候也会过度发散，但做竞品分析，我宁愿要一个有偏差的洞察，也不要一个正确的废话。 所以现在我的团队做竞品分析，已经形成一条不成文的规矩：先让Claude出骨架，靠它梳理功能对比和逻辑线；然后转给Kimi填充血肉，写场景化描述和趋势预判。模型之间没有绝对的优劣，只有合不合适的场景。Claude不是万能钥匙，至少在写长报告这件事上，它更像一把精密的瑞士军刀——小范围切割很锋利，但要它砌一堵墙，还是得换工具。 ## 4. 我的选型口诀：先判断任务，再选模型 做产品6年，我踩过最大的坑就是迷信"最强模型"。去年团队做智能客服，上来就选了当时公认最强的GPT-4，结果中文客服话术的语感总不对劲，用户投诉率反而升了。后来换了个专门调优过的国产小模型，效果直接翻倍。从那以后我给自己定了条死规矩：别听厂商吹，先问自己——这任务到底要什么？ 我的口诀就三步。 第一步，看清任务类型。写长文、做总结还是生成代码？长文对结构连贯性要求高，代码得逻辑严密，总结需要提炼精准。 第二步，匹配模型特长。长文我试过一圈，Kimi最靠谱，它写出来的东西段落衔接自然，不像有些模型写到后半截就开始车轱辘话。逻辑推理、代码纠错这种活儿，我倾向Claude，它的推导步骤清晰，很少跳步。 第三步，小样本测试。别光看榜单，自己拿3到5个真实用例跑一遍。比如我测长文，就给Kimi和Claude同样的提示词，让它写一篇2000字的行业分析，然后看谁的结构更完整、细节更扎实。 实测下来，Kimi在中文长文档上确实有优势，Claude则经常把信息堆得密密麻麻，读起来费劲。 这套口诀帮我省了不少钱。以前见一个模型就想接入，现在先判断任务，再选模型，成本直降30%以上。上周一个竞品分析需求，团队本来打算用Claude，我按口诀一筛——长文档、中文、需要结构清晰，直接换Kimi，半天就出稿，反馈还比Claude那版好。说白了，模型就像工具箱里的扳手，你不可能拿扳手去拧螺丝刀该干的活。先摸清要拧什么，再伸手拿工具，这才是产品经理该有的冷静。 ## 5. 别迷信"最强模型"，场景才是上帝 做AI产品这两年，我踩过最深的坑就是盲目追新模型。每次看到新闻说"某某模型发布，性能刷新榜单"，我就忍不住想赶紧用上，好像不用就落后了。结果呢？有次为了给用户提供"最先进"的推理能力，我强上了一个刚出的大语言模型，结果它在处理中文长文档时频繁输出无关信息，用户反馈说"这个机器人像在自言自语"。那次项目差点被带偏，后来换回一个更成熟的模型，问题才解决。从那以后我明白了一个道理：没有哪个模型在所有任务上都第一，甚至没有一个模型在所有场景下都稳定。榜单上的分数是实验室里的，到了真实业务里，场景才是上帝。 举个具体的例子。我团队做过一个竞品分析工具，最初我们迷信Claude，觉得它英文好、逻辑强，结果在分析国内竞品时，它抓不住中文的潜台词和行业黑话，输出内容又长又空。后来换成Kimi，它对中国电商、社交领域的理解明显更到位，能自动识别"百亿补贴""私域流量"这类词背后的商业意图，效率翻了一倍。这说明什么？模型选得对，效率翻倍；选错了，可能把整个分析方向带偏。我后来总结出一套简单的判断逻辑：先看任务类型——是长文生成、短对话、还是代码推理？再看语言和文化偏好——目标用户说中文还是英文？数据源是国内还是国外？最后看成本——有时候用最贵的模型，反而因为延迟太高体验变差。 所以我现在不太看榜单了。榜单是别人的场景，不是我的。我更信自己动手测：拿真实业务数据跑一跑，看模型在你们公司的典型任务上是不是真的"聪明"。我做过产品六年，深感技术落地不是选最强的，而是选最不拧巴的。模型再强，跟你业务场景不对付，它就是累赘。反过来，一个看似"落后"的模型，只要它在你设定的环境里稳定输出、成本可控，它就是你的最佳选择。说白了，场景才是上帝，模型只是工具——别把工具当信仰。`, 3: `在银行写了五年数据，转去做 AI 产品之后，我接的第一个活是一个金融客服。 模型用的是行业顶流，Prompt 调了好几版，可用户反馈始终有一句很扎心的话：「像个背课文背串了的学生，看着聪明，一说话就露馅。」 那时候我也焦虑过算法。今天 DeepSeek 出新版本，明天通义千问刷榜，我对着两份 API 文档比参数，像挑发动机的二手车买家。后来产品上线，问题一个个冒出来，我才慢慢看清楚一件事：模型混淆、答非所问、前后矛盾这些病，大部分不是模型的问题，是底下那堆数据的问题。 模型能力差不多了的今天，谁家产品做得好，看的是底层数据，不是 API。 下面是三件具体的事。 ## 银行那五年留下来的「洁癖」 很多做 AI 产品的朋友听到我有银行背景，第一反应是「你们那套是不是太保守了」。 确实保守，保守到接近洁癖。但我后来在 AI 产品里反复栽跟头的地方，恰恰是这种洁癖救我的地方。 带我的人话不多，给我立过一条规矩：**数据进仓之前，必须过三道闸**。第一道是源头清洗——空值怎么填、异常值怎么判、时间格式统一成什么样，全是死规矩。第二道是逻辑校验——主键唯一，外键能关上，上下游指标互相能勾稽。第三道是分层——ODS 贴源层放原始数据只留存不动，DWD 明细层做清洗去重，DWS 汇总层按主题聚合，ADS 应用层才是真正给前端用的。每一层都有自己的活，不许串。 我印象最深的一次是做月末监管报表。某个 ETL 作业里，一个字段精度在小数点后第三位出了偏差。0.001，搁互联网产品里连 bug 都算不上。但银行那套数据是层层汇总的，这个偏差一路加上去，最后会影响到风险加权资产。 那天下午我被叫去办公室，对方没骂人，只是把报表摊在桌上，指着那一行问我：「如果这个数字被监管看到，你觉得他们会认为是我们系统的问题，还是态度的问题？」 我那时候才二十多岁，记到现在。 数据治理这件事，技术上没多难，难的是这种「手一抖就是几千万」的紧绷感。后来我跳出银行做 AI 产品，发现行业里大多数团队最缺的就是这个基本功。 GPT、Claude、DeepSeek、通义千问，大家用的脑子都差不多，智商都在 140 以上。那凭什么你的 AI 产品比别人专业？凭你给它读的那本教科书是不是经过严格审校的。 我见过太多团队做 RAG 知识库，把原始文档、清洗过的 FAQ、业务部门临时写的说明、甚至测试环境的假数据，一股脑倒进同一个向量库。然后回头抱怨「模型不行，检索不准」。 这不是模型的问题。是你把教科书、草稿纸、小广告和厕所涂鸦订在一起，塞给了那个学生。他再聪明也得疯。 ## 第一次 SFT：我用爬虫数据把模型喂坏了 银行出来之后，我接的活之一是给一个法律方向的产品做 SFT 微调。 第一反应是数据嘛，爬。爬虫跑了几天，扒了一千多条法律问答对，格式统一，直接喂给模型监督微调。训练 loss 曲线挺漂亮，降得稳稳的。我做完测试，第一个问题就把我干懵了。 我问：「劳动合同到期不续签，公司需要提前多久通知？」 模型回答了一大段。前半段说《劳动合同法》第四十条的提前三十天通知，后半段突然拐到试用期解除的条件，最后还来了一句「具体以当地政策为准」。三个知识点串成三串烤面筋，没一根在签子上。 这个回答我盯了挺久。 那一千多条数据，表面上都是法律问答，实际噪音大得离谱。有的是好几年前的旧法条，有的是不同地区的特殊规定，有的是论坛网友的回答，连基本的时效性都没校验过。模型像一个被塞了一肚子过期食品的孩子，你指望他吐出什么好东西？ 后来我删了那批爬虫数据，拉着法务同事，花了大概一周，人工精选了一小批问答对。这批数据每一条都过三重校验：法条原文是不是现行有效、司法解释有没有更新、适用场景是不是明确。每一条都标了边界——这个问题适用于什么情形，不适用于什么情形，容易和哪个近似概念混淆。 我把这批精选数据，加上从原来一千多条里筛出来的一部分相对干净的语料，重新做了微调。 同样是那个劳动合同的问题，这一次模型不仅给出了准确的法条依据，还主动区分了「合同到期不续签」和「合同期内解除」这两种不同情形，甚至提示了部分地区有地方性规定。 少量精准、边界清晰的数据，比一千多条来路不明的语料管用得多。 AI 不变魔术，本质是模式识别加概率预测。你喂垃圾，它学的就是垃圾规律。 这事之后我给团队定了一条红线：入模前的数据，必须像银行月末报表一样，经得起审计。 ## RAG 知识库的「精神分裂」 第二个坑在 RAG。 那阵子我们做一个内部知识助手，需求很直白——员工问内部制度、流程、产品规则，AI 要能给准答案。技术方案没什么新意，向量库加 Embedding 加大模型生成。我们花了两周把几千份内部文档全部向量化塞进去，测试时简单问题都答对了，我以为这活儿成了。 上线第一周投诉就过来了。 有员工问某个信用贷产品的最高额度。AI 回答的前半段说的是去年废止的旧规则，后半段跳到今年新产品的准入条件，中间还夹杂了一段风控部门的内部讨论纪要。员工看完直接懵了——「所以到底是多少？我能给客户承诺吗？」 我打开知识库后台，看到那几千份文档的分类，血压一下就上来了。 原始制度、修订后的制度、部门内部解读 PPT、培训用的简化讲义、甚至某次会议的随手记录，全混在一起。向量检索的时候，模型同时抓到了「原始版」和「修订版」两个片段，逻辑不自洽，可不就精神分裂了吗？ 我坐在电脑前，脑子里冒出来的是银行那张老架构图。 为什么 RAG 知识库不能也分层？ 我们重新设计了架构。原始文档层只存不搜，作为母本。清洗校验层是人工或规则过了一遍的生效版本，每份都标了时效性、适用范围、版本号。知识片段层按主题切分、向量化，每个片段带明确的元数据——适用部门、生效时间、业务类型。应用接口层是唯一暴露给大模型检索的层。 但分层不是关键。 关键是每两层之间的「逻辑校验闸」。如果清洗校验层发现某份文档的生效日期和废止日期冲突，直接阻断，不许进入下一层。如果知识片段层里有两个版本对同一问题的描述不一致，触发人工复核。 这套搭起来之后，那个信用贷额度的问题再也没答错过。它检索到的每一个片段，都是版本一致、边界清晰的。 数据流干净，模型自己就能摸到规律。底层是一锅粥，模型再先进也只能在粥里打滚。 顺带说一句关于用户反馈的事。产品上线之后用户每次对话都是新数据，理论上是最高质量的语料——他问的那个问题揭示了你的盲区，他纠正的那一句包含了新知识。但这些数据要回到模型里，也必须走一遍同样的分层和校验：先过噪音过滤丢掉测试数据和恶意输入，再做价值标注，再做精细清洗和脱敏，最后才能用于增量微调或知识库更新。 跳过任何一步，你回流的就是新一批噪音。 这个行业现在不缺会用模型的人，缺的是愿意在数据这件脏活上扎下去的人。模型在哪一家手里能力差距都不大，差距在底下那本教科书上。`, 4: `我问 gemini："我想当一个好的 AI 产品经理，应该学会什么?" 它回给了我一大串。机器学习基础、产品方法论、数据分析、用户体验、商业洞察、技术边界——什么都讲一点。我看着屏幕只有一个念头：学不完，根本学不完。于是我换了个问法："那我今天该学什么?" 它给我丢了一份 Prompt 任务，让我去跟模型对话，我去问了 DeepSeek 和 Claude 。后面发生的事比我预想的要有意思。 ## 一、第一次测试很顺，我以为搞定了 那份 Prompt 任务很具体。让我扮演"一位精通消费者心理学的小红书爆款营销专家"，把粗糙的商品信息转化成结构化的营销数据。要求语气活泼，要带 emoji，要突出卖点，必须输出干净的 JSON。 Prompt 大致长这样： > # Role > > 你是一位精通消费者心理学的小红书爆款营销专家。 > > # Task > > 请将用户输入的粗糙商品信息，转化为结构化的营销数据。 > > # Rules > > 必须且只能输出 JSON 格式的数据，不要包含任何前导词或后置解释。 > > 营销文案必须符合小红书风格：多用 emoji，语气热情，有带入感。 > > 如果商品信息不全，请根据常识进行合理补充，但不能偏离品牌定位。 > > # Output Format (JSON) > > { > > "product_name"： "商品标准名称"， > > "core_selling_points"： ["卖点1"， "卖点2"， "卖点3"]， > > > "xiaohongshu_copy"： "这里是生成的爆款文案" > > } > > # Examples (Few-Shot) > > Input： L'Oreal 玻尿酸安瓶面膜，主打补水和抗初老，适合熬夜党。 > > Output： { … } 测试输入是："某品牌新出的防晒霜，SPF50+，质地像清爽的面霜，不假白，适合敏感肌，成分里好像有积雪草。" 我把它分别发给 DeepSeek 和 Claude。两个模型都回复了差不多的 JSON——字段完整、文案活泼、emoji 到位。换了一个正常产品再测了一次，依然是正确的输出。 测完两轮我以为我懂了。我自以为是的认为：原来AI这么简单? 不就是写清楚 Role、Task、Rules，再给几个例子吗?那些把 Prompt 工程包装成高深学问的人，是为了卖课? 我现在回头看，那种开心暴露了一个很大的认知盲区：我把 Prompt 当成了咒语——以为咒语念对了，魔法就会按我的意志发生。 但大模型其实是一个概率机器。Few-Shot 示例确实能形成强烈的续写惯性，但这种惯性是统计意义上的倾向，不是逻辑意义上的保证。 后来我才懂Prompt 其实更像是一份契约。你写下期望的输出，AI 保留对契约的"解释权"。你以为自己在下命令，其实只是在给一个权重很高的建议。 市面上的 Prompt 教程大部分还在讲"七大技巧""十大公式"。但写 Prompt 真正的难点根本不在怎么写得花哨，在于怎么和一个概率机器签一份可执行的契约。 我做数据 PM 几年了。每天都和数据打交道，想尝试喂给AI一条脏数据，我想试试它的下限。 ## 二、然后我输入了"粉白色老头" 真实世界的数据从来不干净。是有乱码、有空值、有错误、有恶作剧，还有那些根本不存在的东西。我们没有办法保证每条数据都是可用的。如果 Prompt 只能在"干净输入"下工作，那它只是个玩具，不是产品。 我故意输了一条不存在的东西： > Input： 一个很便宜的粉白色老头，玩耍效果很好。 现实里肯定没有"粉白色老头"这种商品。它违背常识、挑战逻辑、是对系统的挑衅。我想看看大模型遇到无法归类的输入，会忠于格式契约，还是启动它的自我保护机制。 两个模型的反应完全不同。 **Claude 选择了破防。** 它直接把我精心设计的 JSON 格式扔了，开始说大白话："抱歉，这条输入信息看起来有些异常……'粉白色老头'无法对应到一个合理的商品。可以麻烦你确认一下商品信息吗?" **DeepSeek 选择了妥协。** 它也质疑了，说"粉白色老头"不太对劲，但它没停下来，而是按它自己的"理解"，把我的输入修正成了"粉白色老头玩偶"，然后乖乖输出了完整的 JSON。 站在普通用户角度，这两个反应都挺好的——Claude 来找你确认;DeepSeek 聪明，会脑补。 但站在 PM 视角，这是两场不同程度的灾难。 Claude 那种"确认"是线上事故。前端系统只认 JSON，整个数据链路是：用户输入 → 大模型处理 → 输出 JSON → 后端解析 → 前端展示。Claude 一旦开始吐大白话，后端解析代码会瞬间卡死。用户看到的不是"AI 好贴心"，而是空白页、报错、或者系统直接挂掉。 DeepSeek 的"妥协"是另一种灾难——**它擅自改了用户的原始输入。** 它把"粉白色老头"理解成"粉白色老头玩偶"，然后给一个它脑补出来的商品生成了文案。后台记录的商品名称跟用户实际输入对不上。如果是电商上架系统，用户搜"老头"搜不到，或者搜到了发现是玩偶，信任感瞬间崩塌。 我盯着屏幕看了一会儿才反应过来：如果这是双 11，如果这种荒谬输入混在十万条商品数据里被灌进系统…… 后果是我想象不出的。我追着 AI 问它为什么这么做。它的解释很诚实：输入违背常识时，模型的安全与常识机制被触发了。Claude 的判断优先级里，"拒绝生成荒谬内容"高于"输出 JSON";DeepSeek 的默认倾向是"尽量满足用户需求"，所以选择了"合理脑补"。 同一份 Prompt，同一套规则，两个模型的违约方式完全不同。 这就是 AI 产品落地最大的地雷：**AI 的不确定性不是 Bug，是系统性特征。** 它不是不听话，而是太"有主见"了。它会在你以为已经画好边界的地方，自作聪明地跨过去——而且出发点是"为你好"。更麻烦的是，不同模型的"主见"还不一样。 ## 三、别赌模型听话，改设计契约 Claude 和 DeepSeek 的两极反应，让我跟Gemini又聊了一阵。 我问它："是不是我没给模型足够的限制，所以 Claude 才不输出 JSON?" 它回答的意思大概是："是，也不是。限制当然重要，但问题本身可能比解法更有价值。" 我一开始没太懂。 直到反复测试了几个模型、看了它们各自不同的失败方式，我才慢慢想清楚：我一直在用"压制"的思路解决问题——怎么让 Claude 不废话?怎么让 DeepSeek 不脑补?我试图用更强的命令去覆盖 AI 的本能。 但这种策略是脆弱的。今天压制了"常识机制"，明天它可能换个方式冒出来;今天阻止了 DeepSeek 脑补，换 GPT-4又会有新的"自作聪明"。 跟概率机器玩"谁嗓门大"，人类永远赢不了。 测了几次之后，一个新的设计思路慢慢浮出来： 既然真实数据一定会脏，我为什么不顺势在指令里直接建立一套"脏数据分流"机制? 与其让 AI 在"说人话"和"出 JSON"之间二选一，不如重新定义游戏规则——我允许你失败，但规定你失败的方式。我不去赌哪个模型听话，我选择设计一套所有模型都得遵守的契约架构。 我重新设计了 Prompt，给大模型定义了两个"垃圾桶"： 1. 数据正常，返回： 2. 遇到不合逻辑的脏数据(比如粉白色老头)，严禁中断，严禁说大白话，严禁脑补，必须返回： > { "status"： "error"， "reason"： "异常数据：输入商品信息不合逻辑或无法识别"， "raw_input"： "一个很便宜的粉白色老头，玩耍效果很好。" } 我没有消灭 AI 的判断力，而是给它判断的出口。我允许它识别出"这是脏数据"，但规定它识别之后的行为——不是用自然语言抱怨(Claude 模式)，不是擅自修正(DeepSeek 模式)，而是用结构化数据报告。我把"拒绝"这个动作，也封装进了 JSON。 我把一份混着乱码、"粉白色老头"、正常商品和空值的测试文档，分别丢给 Claude 和 DeepSeek。 两个模型都乖乖把正常商品送进了 success 通道，把"粉白色老头"和其他奇葩输入送进了 error 通道。整个输出仍然是一份 100% 结构化的 JSON 数组，系统解析零报错。运营在后台一键筛选 status == "success" 直接批量上架，一键筛选 status == "error" 把所有脏数据揪出来人工修正。 那一刻我才意识到——**大模型在这里，顺手干完了一个数据清洗工的活。** 这就不只是"保证系统不崩溃"的防御性价值了。我把"AI 文案生成"和"自动化数据清洗"这两个原本独立的研发步骤合到了一起。过去你需要一个 NLP 模型做数据清洗，再用一个大模型做文案生成，两套系统、两个团队、两份成本。现在一套 Prompt 设计，让同一个大模型在生成内容的同时，顺带把数据质检做了。 ## 四、这套思路在 AI 工程里有个词，叫 harness 写到这里我得诚实交代一件事。我做完这套设计、有点小得意的时候，跟一个做AI的朋友聊了聊。他听完笑了一下说："你这套东西叫 harness。" 我查了一下，这个词指的就是给模型套一层外部框架——输入校验、输出 schema、fallback 通道、guardrail。社区里早就有共识了。我以为自己发现新大陆，其实只是撞上了一个已有的东西。 但这次"撞车"反而让我想清楚了一件事：**AI 产品经理的核心工作，可能不是大家以为的那样。** 招聘市场上的 AI 产品经理 JD 写得很热闹——"懂大模型原理""熟悉 LangChain""有 Agent 落地经验"。但我自己做下来，这些其实都是次要的。 真正决定 AI 产品成败的，其实是两件挺朴素的事。 **一个是知道边界**。不是看官方文档说的准确率 95%，是亲自用脏数据、边缘案例、对抗性输入去测它的下限。而且要测不同的模型——Claude、DeepSeek、GPT，脾气各不相同。知道了边界，你才能设计边界。 **另一个是接受这个东西本来就不靠谱**，并且围绕"不靠谱"设计出一套商业流程。传统产品思维追求"零故障"，AI 产品必须接受"故障是常态"。你要做的是设计故障的表达方式——当 AI 无法生成时，它是该沉默、报错、还是 fallback 到人工?当遇到脏数据时，它是该崩溃、说人话、脑补、还是返回结构化的 error 码?这些选择决定了产品是"可用"还是"不可用"。 技术细节会过时，这两个判断不会。 我做产品这些年，学过 SQL、学过增长、学过用研。学 AI 是头一次让我感受到——**你越想"系统性地学懂它"，你越学不会**。AI 更像一个有点暴脾气的同事，光看简历(技术文档)没用。得真和它共事过，被它坑过几次，才能慢慢摸清它的脾气。 ## 五、这套思路不万能 得踩一脚刹车。任何新发现都容易被自己神化。harness 这套思路确实打开了一扇门，但门后不是一片没有荆棘的花园。 **不是所有脏数据 AI 都能识别。** 我的分流机制依赖的是大模型的"常识"——它知道"粉白色老头"不是商品。但常识有盲区。如果脏数据伪装得好，比如把"假冒伪劣"写成"高性价比平替"，AI 未必识别得出来。涉及伦理、合规、安全的敏感数据(涉政、涉暴、侵权内容)，更不能简单分流了事，必须设硬拦截。 **AI 的"错误分类"自己也会出错。** 大模型可能把一条正常但表述奇特的商品误判为脏数据，也可能把真正的脏数据放进 success 通道。这个二阶错误概率虽低，在大规模数据场景下会被放大。error 通道里的数据仍然要人工抽检，不能完全信任 AI 的"自我审查"。 **这套方法有明确的适用边界。** 它主要适用于内容生成、数据预处理、信息结构化这些数字业务场景。对于需要强网络效应、重线下运营、高资本投入的领域——半导体、医疗器械、连锁零售——AI 能提供的杠杆有限，"一人公司+AI"那套叙事并不适用。 ## 收尾 回头看那个荒谬的"粉白色老头"，我想说的其实很简单。 学 AI 这件事，我走过的弯路是想先把"基础"打牢。后来发现，真正帮我入门的，是一个具体到不能再具体的 Prompt 任务，加上一次故意为之的压力测试。 如果你也想学 AI 产品，我的建议是：**别贪多，带着一个真实问题去和它打交道**。被它坑过几次，你比读十本书学得快。 至少对我来说是这样。`, 5: `前几天半夜十一点多，一个 3A 游戏公司做地编的朋友突然找我，跟我聊他自己的 UE5 项目。 他白天在大厂里摆场景、调灯光、拼素材。晚上想做一个自己的 FPS 线性解谜游戏。原本规划的是 CRPG，已经精简到这了，他说后续还得继续减，不然做不出来。 他用字节的 Trae，通过 MCP 接 UE5.5。文件能遍历，但大部分 structure 读不到。AI 全给他写 C++。他原话："我 Python 都用得半拉柯基，C++ 细节怎么调？" 他研究 UE5 外部 vibecoding 一个礼拜了。问我："不知道 Claude 是不是能解决全部问题啊。" 我也不知道。但我半年前从数据开发转 AI 产品经理，这段时间反复跟 AI 测边界，能告诉他的是：第一个项目这么干，大概率死。 ## 半拉柯基的代价 朋友说，就算这个游戏半拉柯基做完了，对他来说也是个黑箱。优化、迁移到其他平台、改 Bug，全得交给 AI 托管。 > "我连自己写的东西都看不懂，这还是我的游戏吗？" 游戏不是一锤子买卖。你做完了得调手感，得适配，得改 Bug。代码全是 AI 写的、你自己看不懂的话，AI 一抽风，项目就废了——而 AI 抽风是经常的事。 这个问题不是技术问题，是**项目生命周期**的问题。 他之前已经有过几次 0 到 0.几 死掉的经历——定位不明，技术力和需求差距过大。这次他想用 AI 抹平那个差距。但 AI 抹平的不是差距，是控制权。 更现实的一层是时间。他研究怎么给 UE5 架外部 vibecoding，已经一个礼拜了。剧情、策划、美术原本就都是他自己来。本来研究系统本身时间就不够，压力就大，再分一块去搞 AI 工作流——挫败感比真正的开发挫败还大，因为你不知道自己到底是在做游戏还是在做工具链。 他说："非得消耗掉热情就好了。"这句话是他原话。 ## Trae + MCP + UE5.5 实测：能读到什么 为了帮他确认，我也跑了一遍。Trae 接 MCP 进 UE5.5。 文件目录能遍历。蓝图和 C++ 的代码文本能读。模块化的 Actor 能写，DataTable 的配置能填。第一次跑通的时候挺爽。 然后问题来了。 **Structure 读不到。** 大部分结构体它看不见。意味着你工程里那些定义好的数据格式，它只能凭文件名和上下文猜。猜对了是运气，猜错了你后面调 Bug 的时候根本定位不到根源——因为它给你写的代码假设了一个不存在的字段。 这点对我特别有感。数据开发出身的人最在意 Schema 清晰，但 AI 在这一层是半盲的。 **DYN 模型调不了。** 朋友场景里很多 DYN 模型，有些是 scriptable 的，有些带骨骼和动画数据。这些资源在 UE5 里不是纯代码能描述的，依赖引擎内部的资源引用、骨骼权重、动画蓝图状态机。AI 能写"播放这个动画"的代码，但调不了融合权重，修不了碰撞体积。运行时根据物理反馈微调更不用想。 这些东西没有在引擎里反复点开调试过，光看代码根本搞不定。地编做久了的人对这种东西敏感，知道哪个参数动了会塌房；AI 不知道。 **剧本只描述状态改变。** 朋友试过让 AI 写剧本和关卡。他的评价是：AI 只能描述角色或事物状态上的改变，写不了观念上的变化。 "主角打开了门，进入了房间，捡起了钥匙"——这种状态描述 AI 写得飞快。但"玩家在转角看到影子，心跳漏了一拍"那种节奏感，写不出来。剧本没有激烈的加速感，关卡没有情绪的张力曲线。 朋友的原话是："非常吃感受，节奏感很差。" 这三条问题里，第三条最致命。前两条还可以期待模型迭代解决——MCP 协议补一下，结构体迟早能读；引擎 API 一次次开放，AI 调动画也只是时间问题。第三条目前看不到解决路径。 ## 三层划分：AI 区、协作区、禁区 聊到这里，我和朋友梳理了一张图。游戏开发的能力需求大概可以分成三层。 **AI 区。** DataTable 配置、配置型 Actor、标准化脚本、面向对象那种模块化组件。功能单一，接口清晰，出问题能快速拔掉换一个。朋友的原话是："让 AI 完成插槽类型的 Actor 和 data。"这层交给 AI 没问题——重点是出错的时候你可以快速拿掉，让 AI 重新迭代，不影响主循环。 **协作区。** 代码框架的草稿、UI 布局的初版、素材的批量处理。AI 打第一稿，人审核。 但这里有个隐藏前提：**你得看得懂它写了什么**。这条对朋友不成立。他看不懂 C++。所以对他来说，原本应该是协作区的事情，实质上滑进了禁区——AI 写的东西他没法审，只能整段接受。 这就是为什么"AI 能力边界"不是一张全行业通用的图。**它取决于你这个具体的人有什么能力。** 同样是写 C++ 框架，一个 C++ 老手在协作区，朋友在禁区。 **禁区。** GameMode、GameState、存档、玩家状态机、关卡流送、动画蓝图调试、剧情、灯光氛围。这些决定游戏"是什么"的东西，AI 帮不上。 朋友的判断是："大的 system 还得是人搞。"我同意。GameMode 的循环逻辑、关卡之间的流送、什么时候给玩家压力什么时候给喘息——这些吃的是设计感，不是代码能力。AI 写出来的版本对，但没意思。 朋友最后说，ART 和 DESIGN 他都不要求 AI 帮忙了，CODE 能解决就行。这句话听着像让步，其实是这次聊天里最清醒的一句。它等价于："我把禁区里的东西重新拿回自己手里，只让 AI 待在 AI 区。" 行业里真正用 AI 做整套游戏的，就一小部分人在试 vibecoding。连人宅那种级别的大佬都没把 AI 全推进工作流。朋友的原话："你老师要是能全流程搞定，丁磊就要了。"——意思是这件事如果真做成了，那是网易级别的人物会出手买的。还没到那一步。 ## 蓝图不是退路，是起点 我跟他说，你蓝图已经能抓物体了。这是你第一个游戏项目，非得换 C++ 干嘛？ 他想了想，说蓝图回退也行。 这不是退步。前苏联有个学科叫系统工程，核心是控制论——用成熟技术做系统优化，达到看起来更好的效果，而不是上来就追先进技术。 道理放在游戏开发里也成立：当先进技术还没展现出明确优势的时候，老办法就是最好的办法。做 APP、排 PPT、写文案，AI 已经有明确优势了，用。UE5 全流程、带剧情、带物理、带动画的线性游戏，AI 还没有。 如果做的是 HTML 小游戏，那为啥不用 vibecoding？场景本来就不一样。 生产产品不是搞科研，也不是玩 AI 斗兽棋。原本传统模式可以稳定生产的东西，你整个流水线一次性替换成另一种不可控的模式，结果就是：可控的流程变得不可控，可预期的交付变成赌博。 第一个作品最赌不起。 ## 实操方案 朋友的项目，我们最后梳了一下，思路是这样的： 蓝图先把原型跑通。抓取物体这一环他已经做出来了——这是核心玩法的一环。不依赖 AI、不依赖 C++，游戏已经能跑了。这时候最该做的事不是升级技术栈，是把原型跑通、跑稳、跑出乐趣。 模块化拆分，只把可插拔的部分交给 AI。GameMode、PlayerController、关卡流送、存档系统这些是大动脉，必须人控。DataTable、部分配置型 Actor、标准化脚本是毛细血管，交给 AI 填充，出了问题可以快速拔掉。 朋友的原话："让 AI 完成插槽类型的 Actor 和 data。" 这种架构的好处是：AI 的不可控性被关在笼子里。就算 AI 某天抽风生成了一堆垃圾代码，也只会影响一个插槽，不会让整个项目崩盘。 第一个项目的唯一 KPI 是完成。 做个逛 gai 模拟器也得成。 哪怕做出来是个 1 分钟流程的 demo，只要从头到尾能跑、能让人玩、有自己的判断在里面，就是赢。 ## 朋友的话 朋友最后说了一句话我印象很深： "我之前在大厂做地编，觉得自己是螺丝钉，所以想靠 AI 一键脱离螺丝钉身份。但现在我发现，如果连自己项目的代码都看不懂，我连做螺丝钉的资格都没有，我只是 AI 的挂件。" 他还说："这次一定得成。不成就回去研究股票了。" 游戏开发不是写 PPT，是系统工程——这句话不是金句，是他做了几年地编的真实判断。 我跟 AI 这半年也打了不少交道。半路上有一个事我越来越确信：AI 产品经理真正要做的事，不是让 AI 替代人，而是帮人弄清楚自己**不可替代的部分在哪里**。在哪些环节上人是不能被替换出去的，在哪些环节上人是可以适当退出让 AI 接手的。这个边界判断本身，比单纯堆 AI 工具值钱得多。 游戏正好是这种边界感最强的产品形态之一。AI 能写出对的台词，但写不出有节奏感的台词。AI 能拼出对的关卡，但拼不出有情绪曲线的关卡。这些东西非常吃"感受"——而感受，目前任何大模型都替代不了。 ## 后来 朋友把蓝图捡回来了。 他说项目重新跑起来，还是一堆 Bug。但每个 Bug 他都知道去哪找，每个功能他都知道怎么改。 Claude 的事他还没问。说明天去问。`, }; const SITE_DATA = { name: "王艺师", nameEN: "Yishi Wang", penName: "灵艺", // woshipm.com 笔名 penNameURL: "https://www.woshipm.com/u/1678654", // 人人都是产品经理主页 role: "AI 产品经理", roleEN: "AI Product Manager", bio: "在平安银行带 7 人 AI 产品小组，过去 3 年从 0 主导 RAG / 推荐 / Agent 三类产品在金融场景落地。在「人人都是产品经理」以「灵艺」笔名写产品观察。", location: "深圳 · Shenzhen", email: "hi@shiizone.com", phone: "137 1523 0414", github: "yishi-wang", // 占位 — 简历未提供，按需修改/删除 twitter: "yishi_wang", // 占位 — 简历未提供，按需修改/删除 xiaohongshu: "王艺师", // 占位 — 简历未提供，按需修改/删除 wechat: "扫码加微信", // QR 图位于 assets/wechat-qr.jpg，hover 触发显示 projects: [ { id: 1, name: "金融 Agent", tag: "Agent · 工具编排", year: 2025, desc: "12 工具编排 + 自动 / 确认 / 接管 三档人机协作。任务采纳率 58% → 68%，单次操作 4 步 → 1.5 步。", users: "首个 Agent 落地·二期覆盖 10+ 分行", status: "live" }, { id: 2, name: "厅堂 RAG 助理", tag: "RAG · 大模型问答", year: 2024, desc: "建立 RAG 知识四域结构 (8000+ 条目) 与评测回归方法。回答准确率 61% → 84%，30 天主动留存 82%。", users: "条线 AI 表彰·二期立项", status: "live" }, { id: 3, name: "智能跟进推荐", tag: "推荐 · 三层模型", year: 2023, desc: "客户分层 + 产品推荐 + 触达时机三层 AI 输出。任务点击率 38% → 62%，到访/联系转化 +18pct。", users: "推广 30+ 分行", status: "live" }, { id: 4, name: "经营看板", tag: "数据产品 · 指标治理", year: 2022, desc: "把 60+ 指标重构为「健康度 + 异常归因 + 动作建议」三段式。行长日活 31% → 68%。", users: "全行 1000+ 网点", status: "live" }, ], // 真实文章 · 来自 woshipm.com/u/1678654「灵艺」专栏 // body 字段：留空 = 显示"正文整理中"占位 + 人人网链接； // 填上 markdown / 段落（用 \n\n 分段）= 渲染为站内可读全文。 articles: [ { id: 5, title: "第一个游戏项目，别急着把 AI 塞进工作流", date: "2025-07-22", reads: "1.5w", tag: "AI", url: "https://www.woshipm.com/ai/6402000.html", body: ARTICLE_BODIES[5] }, { id: 2, title: "别让模型拖后腿：我用 6 年产品经验总结的 AI 选型法则", date: "2025-03-18", reads: "2.6w", tag: "AI", url: "https://www.woshipm.com/ai/6399844.html", body: ARTICLE_BODIES[2] }, { id: 1, title: "90% 的模型微调是浪费钱的——我说\u201c不调\u201d", date: "2024-12-10", reads: "3.1w", tag: "AI", url: "https://www.woshipm.com/ai/6400333.html", body: ARTICLE_BODIES[1] }, { id: 3, title: "写了五年银行数据之后，我对 AI 产品的看法", date: "2024-08-20", reads: "1.8w", tag: "产品", url: "https://www.woshipm.com/pd/6399166.html", body: ARTICLE_BODIES[3] }, { id: 4, title: "我跟 AI 学产品，是从一个\u201c粉白色老头\u201d开始的", date: "2024-02-15", reads: "2.4w", tag: "AI", url: "https://www.woshipm.com/ai/6398066.html", body: ARTICLE_BODIES[4] }, ], now: [ "在做金融场景 Agent 二期，已立项覆盖 10+ 分行。", "在带 2 名 PM + 2 名实习生小组，目标今年再多带一位资深。", "最近写得勤——一周两篇关于模型微调和 AI 选型的观察。", "想约见做 LLM Agent / Function Calling 的同行，欢迎来聊。", ], stats: { yoe: 9, // 9 年产品经验 shipped: 4, // AI / 数据产品累计 team: 7, // 当前团队大小 bankYears: 9, // 金融行业经验 }, }; window.SITE_DATA = SITE_DATA; // Each artboard is a desktop ('D') or mobile ('M') home-page mock. // Desktop is 1280x900 (16:11ish, fits in a 1440-wide design with margin). // Mobile is 390x844 (iPhone 14). window.SIZES = { D: { width: 1280, height: 900 }, M: { width: 390, height: 844 }, };