我如何为一个真实 AI 产品建立内容质量标准

我最初为 Tap to Share 加入 AI 评价文案时，最直接的问题似乎是：这个功能能不能稳定生成一段格式正确的文字。这个门槛当然重要，但它离真实产品需要的质量还很远。

一段内容可以在技术上完整，却不是顾客愿意使用的起点。它可能太空泛、热情过头，写进顾客没有提供的细节，或者把顾客选择的重点堆成一串营销词。系统没有报错，内容也不代表已经适合上线。

这段差距促使我为产品建立一套内容质量标准。它不是一个 prompt，也不是一句“写得更好”。最后形成的是一组互相连接的产品决定：生成规则、信息使用边界、验证门槛、测试案例、人工审阅标准和回归测试（regression testing）。

下面讲的是这套标准怎样形成。文章不会公开 Tap to Share 的生产 prompt、内部评分逻辑、凭证、商家的私密信息或保密配置。

功能跑通之后，质量问题才真正出现

早期检查回答的是基础问题：请求有没有完成？语言是否正确？输出格式能不能使用？这些检查帮助我确认功能是否可靠。

它们回答不了另一个更接近顾客的问题：一个真实的人看到这段文案时，会不会觉得它可信，也能表达自己原本想分享的体验？

对评价文案产品来说，这个区别很重要。顾客始终是表达者，可以决定使用、修改或放弃建议内容。产品仍有责任给出一个有用的起点。空泛的段落会把工作留给顾客；夸张的段落会带来风险；如果一段写得很流畅的内容混入了未经支持的细节，问题反而更难发现。

我开始把内容质量当成一个独立的产品界面，为它设定自己的验收标准（Acceptance Criteria）。工作重点也随之改变：不再只是修改某一段输出，而是明确系统面对不同情境时可以做什么。

反馈只有变成“决定”，才能真正落地

“太像广告”“有点重复”都是有价值的反馈，但还不能直接变成产品规则。下一步要找出，反馈背后究竟是哪一个产品决定。

在 Tap to Share 的测试中，几类问题反复出现：

• 顾客选择的哪些信息可以进入文案？
• 正面表达可以推荐到什么程度？
• 哪些词会把普通好感写成没有依据的最高级或绝对判断？
• 怎样使用顾客选中的重点，又不把它们堆成关键词？
• 当顾客没有说明曾多次到访时，过去经历应该怎样表达？
• 不同语言怎样各自生成，才能像自然表达而不是翻译？

这些问题都可以转成明确边界。例如，“少一点广告感”如果进一步区分普通的正面感受和“最好、完美、一定优于其他选择”等说法，就更容易执行。“写得更具体”也只有在细节必须来自允许使用的背景时，才不会变成编造。

从感受走到决定，是整套质量标准的起点。

区分顾客表达和商家偏好

Tap to Share 允许商家提供活动背景、可选重点、素材和平台。这些内容可以让顾客更容易参与，却不能把顾客评价变成商家写好的广告。

因此，质量标准里需要一条清楚的表达归属边界。商家背景帮助系统理解场景，顾客选择说明对方希望提到什么。AI 生成的内容只是可以继续修改的建议；最终怎样表达、是否发布，仍由顾客决定。

这条边界会直接影响文案质量。如果系统把每一个商家提供的词都当成必须出现的关键词，结果很快会变得拥挤而不自然。我更倾向于把顾客选中的重点当作相关性依据：使用真正支持这段评价的细节，省略不合适的部分，也不围绕它们虚构新的故事。

推荐强度也因此更清晰。顾客选择了正面重点，代表系统可以在当前情境中使用正面语言；这并不等于顾客授权了一条适用于所有人的推荐，也不支持与所有竞争者比较，更不能凭空加入效果承诺。

标准需要区分不同类型的失败

如果只用一个总分，很多重要差异会被藏起来。我把质量标准拆成可以独立检查的决定。

这些分类让问题更容易定位。“输出不好”不再是一个笼统结论。团队可以判断，它涉及信息权限、事实精度、内容组织、语气、语言，还是产品整体是否好用。

分类也避免一种通过掩盖另一种失败。一段内容可以通过禁用内容主张检查，却仍然太空泛；同样，一点不影响事实与使用价值的句式问题，也未必应该阻止一个版本结束验收。

硬性门槛和质量判断负责不同的事

我把重大问题和一般编辑问题分开处理。

当输出越过明确边界时，适合使用硬性门槛。例如，它虚构了一次购买、暗示顾客曾反复到访、加入没有提供的私密细节，或使用不允许的绝对化说法。这些问题不应该依赖审阅者碰巧看见。

另一些问题需要判断。句子节奏可能不够顺，两处表达也许有点接近。内容在安全、有用和可以编辑的前提下，仍然可能有继续润色的空间。如果每一种偏好都变成拒绝规则，系统很容易变得脆弱，也会陷入没有终点的调整。

因此，我的验收同时包含确定性检查和对实际输出的可见审阅。前者保护明确边界，后者判断内容作为顾客看到的产品是否成立。剩余的非重大问题可以进入后续改进记录，无需假装它们不存在，也不必让当前版本永远无法结束。

原生语言质量必须从生成开始

Tap to Share 支持多种语言。最方便的做法，是先生成一个源语言版本，再把它翻译出去。这样也许能保留信息，却未必能保留人们真正会怎样表达。

英文、简体中文和繁体中文在句子节奏、直接程度和推荐习惯上都有差异。因此，质量控制需要从生成阶段就分别处理语言，再通过后续审阅确认。

不同语言共享同一条事实边界：只能使用允许的背景信息。表达方式不需要逐句对应。这个区别让产品可以追求自然语言，同时避免本地化过程产生新的内容主张。

每一项质量要求都要有执行路径

写下标准只是开始。每一个重大要求都需要连接到产品中的实际控制方式。

1. 先定义产品决定

说明产品想保护或实现什么。“避免未经支持的顾客经历”比“保持准确”更容易执行。

2. 写出可观察的失败

记录审阅者或测试会看到什么。例如，只知道当前体验，文案却让人理解为顾客曾多次到访。

3. 说明可接受边界

保留合理表达空间。普通过去时可以描述当前经历，而不代表长期关系；正面感受可以被写出来，也不必使用绝对排名。

4. 选择控制层

有些要求适合放进生成规则，有些需要确定性验证、测试情境、可见验收，或几层共同负责。最严格的控制方式并不一定最合适，关键是它是否匹配问题类型。

5. 加入回归案例

重大问题一旦修正，就保留一个有代表性的测试。之后改进其他部分时，不应悄悄把同一个问题带回来。

这五步把一次反馈变成可以长期使用的产品资产。质量标准会影响 prompt 和周边逻辑，却不等同于其中任何一项。

回归测试避免改好一处、退回另一处

AI 内容质量的不同目标会互相影响。加强具体性，可能鼓励系统加入没有依据的细节；收紧 claim 过滤，可能让文案重新变得空泛；追求句式变化，也可能削弱内容与顾客选择之间的联系。

因此，每次重大调整之后，我都会重新检查已经通过的代表性场景。目标不是把某一个分数推到最高，而是维持信息权限、实用性、顾客声音、语言和风险之间的整体平衡。

我也一直把 Review AI 和 Social AI 的质量标准分开。社交帖子与顾客评价在表达者、推荐方式、平台情境和激励边界上并不相同。把所有规则复用到两个系统里，文档会更简单，产品边界却会更模糊。

“通过验收”是一项有边界的版本判断

Review AI 的一个质量版本最终通过了生产验收。这个结论有明确范围：当时定义的证据、必要流程、硬性门槛和可见测试输出，足以支持该版本进入下一状态。

它不代表未来每一次生成都会完美。生成式系统会遇到新的信息组合和语言情境。验收建立的是一个已经测试的基线，也让之后出现退步时有据可查。新发现可以进入质量改进清单（backlog），再根据影响程度决定何时处理，而不是自动推翻所有已经完成的判断。

这是这段工作的核心经验。AI 产品不会因为团队列出一串喜欢的形容词，就自然拥有质量标准。只有当真实反馈被转成明确决定、每一个决定都连接到合适的控制方式，而且产品变化之后还能重新验证整套标准，质量才真正成为系统的一部分。