写下“支持智能生成”之前，我得先答三个问题

做了一段时间 AI 产品，我对“把一个功能做出来”这件事的理解变了。

以前讨论功能，我从用户要完成什么、流程怎么走、哪些状态要处理开始。现在这些仍然要做，只是写完以后，还多出一个不太好回答的问题：模型到底能把这件事做到什么程度？同一个入口，同样一句要求，这次回答合适，下次未必。一次演示顺利，也很难据此告诉团队，这个功能已经可以交给用户了。产品方案里只有“支持生成”“支持问答”“支持智能推荐”，到了验收时，大家很可能各自在理解另一件事。

最明显的变化是，需求除了要描述做什么，还得解释什么结果能接受，做不好时怎么办。

功能列表之外，还需要一份能力说明

把传统软件叫作“建筑”，把大模型叫作需要训练的“动物”，这个比喻有一点帮助：前者更容易用明确规则约束结果，后者的输出存在不确定性。但我不愿据此否定规则设计。订单金额、权限、退款条件，不能因为接了模型就变成可以自由发挥的东西。

举个订票的例子。原来的功能描述是选择日期、出发地和目的地，查询班次，提交订单，每个输入框都有明确含义。换成一句“帮我订个下周去上海的票，要便宜点的”，输入方式轻了，产品要处理的判断反而多了。“下周”是哪一天，从哪里出发，便宜是优先价格还是可以接受更长的路程？信息不齐，模型应该追问，不能替用户做完所有决定。我会想把能力拆到这个程度：能识别哪些信息，哪些必须确认；冲突时先问什么；哪些建议可以直接给，哪些操作要等用户同意；查询失败和确实没有结果，分别怎么解释；最后交给用户的是候选方案，还是已经产生的订单。

错误也得重新分一分。碰到一个错误回答，我不想第一反应就是“再调一下 Prompt”。有时是没拿到最新资料，有时是检索找错了段落，有时是任务描述太宽，还有时是业务规则根本没写进系统。缺知识可能要补数据来源；没遵守格式，可以试约束输出和程序校验；权限判断不对，就该回到权限系统，不能指望多强调几遍“请严格遵守”。Few-shot 和 RAG 都能帮上忙，但它们没有固定的改善幅度，对我手上的任务有没有用，得用同一批案例比较。这种工作有点不习惯，不是每次修改都能立刻找到一个确定的“修好了”。

我需要写得更具体的三件事

提示词要写，PRD 也没有消失。“支持英文翻译成中文”足够说明方向，却没告诉模型专有名词怎么办，代码要不要动，原文有歧义时是直接猜还是留注释。我会把最容易分歧的要求写出来，和具体样例放在一起：

将输入的英文科技材料译成简体中文，保持专业、客观的语气。技术术语第一次出现时给出中文解释，并保留英文；代码块和标识符不要翻译。原文没有的信息不要补写，遇到影响理解的歧义，另列一句说明。

这段指令可以直接拿去试，比“翻译得专业一点”容易讨论。但 System Prompt 没有替代整份产品方案。谁能上传材料、哪些内容可以发送给模型、结果怎么编辑和保存、失败怎么重试，这些还要在产品和工程层面处理。

上下文要考虑取舍，不只是越长越好。一个助手反复询问已经说过的信息，会让人累。可把所有历史都塞回去，也未必好，里面可能有过时的决定、闲聊、重复附件。当前任务必须保留什么？对话长了以后，摘要能不能保住关键约束？用户改了主意，旧信息在哪里更新？“我不吃香菜”可以作为偏好，一次帮朋友点餐，未必该沿用。上下文窗口只是一次能放进多少内容的限制，不能等同于能记住几轮对话。

成本要算到一件事真正完成。只看一次调用多少钱，容易算错。一篇文案生成后还要反复重试、调用检查、人工返工，单次调用便宜，不代表完成这篇文案便宜。简单分类可以试较小的模型或规则，复杂分析再用能力更强的模型，这是路由的思路，但多一层路由也有代价。等待时间也一样，问一句话等几秒会觉得卡住，处理一批文件用户可能愿意等更久，前提是知道它还在工作。不存在一个适用于所有 AI 功能的两秒极限。

如果从零开始，怎样把它定义清楚

先写任务和边界，再决定要不要人格。聊天陪伴需要考虑语气和角色，发票抽取就不必写一千字人物小传。我会先写出正常输入、信息缺失、明显超范围三种情况，想清楚分别期待什么结果。

用样例把“好一点”讲清楚。“效果还可以优化”太宽了。放一组输入、当前输出、期待输出，再补一句原因，团队比较容易知道在改什么。样例可以用于提示词，也可以进入评估集，但训练材料和测试材料要分开。

RAG 和微调，从问题来源区分。RAG 是把当前问题相关的资料找出来交给模型参考，适合企业文档、经常更新的政策；代价是资料要维护，检索要评估。微调改变模型的参数，常用于让模型更稳定地遵循某类任务和表达方式，不适合当成随时更新事实的数据库。先确认主要问题发生在哪一层，再决定增加什么，固定格式的问题也可能用结构化输出和校验就能解决。

建一组真正会影响决定的测试题。从五十到一百个典型问题开始，既要有高频任务，也要有少见但出错代价大的情况。每个案例记录预期结果、不可接受的错误、判断理由。模型或提示词换了版本，用相同输入重新跑，看哪些变好了，哪些退步了。让另一个模型参与评分能减轻工作，但它也会偏爱某种表达，人工需要先校准评分口径，再抽查。

把这几步连起来，再看一次商品图生成

拿 Smart Photo 的商品图生成来说，我会试着把前面的内容放在同一页上。运营上传一张商品原图，选一个场景模板，也可以补一句自定义描述，产品要做的是生成一批候选图，让人从里面挑。它可以生成很多张，但能不能上架，不由生成本身决定。

一份最小任务说明，可以这样列：

这里的提示词样例、模型版本和前后处理，各自承担不同工作。一批图不对，我可以顺着这张表查：抠图就没抠好，场景模板不合适，还是模型对这个品类本来就弱？比只改一句提示词更接近问题。

测试用例也能从这里长出来。准备一批正常的商品图、一批透明材质的、一批原图本身就不清楚的，再加入模板和商品完全不搭的情况。每一种需要什么输出，允许自动走到哪一步，都应该事先有说明。不能看见画面好看，就把它算成成功。

做效果比较时，我还想保留一份简单的修改记录。当前改了什么，用哪些题比较，哪类问题改善，哪类没有。提示词改了以后，原来的错误消失了，但另一个高频任务开始失败，不能只报告前一半。之后换模型、换规则，至少知道当初为什么这样设计，而不是面对一段越来越长、没人敢删的提示词。

和不同的人讨论时，换一下重点

和负责人讨论，我更想讲清楚这个能力解决了哪段业务问题，预计节省什么，新增什么成本。“成本下降四成”这样的说法，没有实际测量，就不该写成成绩。和研发讨论，把任务和失败情况展开：是分类没分对、实体没抽全，还是取回来的资料不相关？和用户说明，不用把模型和技术路线全讲出来，他关心的是能省哪一步，还要自己做哪一步。“一句话生成周报”如果最后仍要补数据、查事实，也该交代清楚。

落回自己的工作

看一堆术语很容易越看越觉得欠账。我不想把这篇写成职业焦虑清单，也不觉得产品经理需要把研发的工作都接过来。可以给自己安排三件小事：挑一个小任务在 Coze 或 Dify 里搭起来，先把输入和输出跑通；找相关官方文档，弄清刚才用到的参数，温度影响采样随机性，不是创造力刻度；回到手上的一个功能，补上样例、评价标准和失败处理。先做其中一项就行。

做 AI 产品没有让我觉得过去的产品工作不重要了。用户怎么理解一个操作，系统怎样给出反馈，业务规则在哪里生效，这些反而经常决定模型能力能不能被用起来。变化在于，我现在需要更早接触实际输出。

下一次写下“支持智能生成”时，我至少希望自己能接着回答：生成什么，凭什么算好，哪里还不放心。