我最初为 Tap to Share 加入 AI 评价文案时，最直接的问题似乎是：这个功能能不能稳定生成一段格式正确的文字。这个门槛当然重要，但它离真实产品需要的质量还很远。
一段内容可以在技术上完整，却不是顾客愿意使用的起点。它可能太空泛、热情过头，写进顾客没有提供的细节，或者把顾客选择的重点堆成一串营销词。系统没有报错，内容也不代表已经适合上线。
这段差距促使我为产品建立一套内容质量标准。它不是一个 prompt，也不是一句“写得更好”。最后形成的是一组互相连接的产品决定：生成规则、信息使用边界、验证门槛、测试案例、人工审阅标准和回归测试（regression testing）。
下面讲的是这套标准怎样形成。文章不会公开 Tap to Share 的生产 prompt、内部评分逻辑、凭证、商家的私密信息或保密配置。
功能跑通之后，质量问题才真正出现
早期检查回答的是基础问题：请求有没有完成？语言是否正确？输出格式能不能使用？这些检查帮助我确认功能是否可靠。
它们回答不了另一个更接近顾客的问题：一个真实的人看到这段文案时，会不会觉得它可信，也能表达自己原本想分享的体验？
对评价文案产品来说，这个区别很重要。顾客始终是表达者，可以决定使用、修改或放弃建议内容。产品仍有责任给出一个有用的起点。空泛的段落会把工作留给顾客；夸张的段落会带来风险；如果一段写得很流畅的内容混入了未经支持的细节，问题反而更难发现。
我开始把内容质量当成一个独立的产品界面，为它设定自己的验收标准（Acceptance Criteria）。工作重点也随之改变：不再只是修改某一段输出，而是明确系统面对不同情境时可以做什么。
反馈只有变成“决定”，才能真正落地
“太像广告”“有点重复”都是有价值的反馈，但还不能直接变成产品规则。下一步要找出，反馈背后究竟是哪一个产品决定。
在 Tap to Share 的测试中，几类问题反复出现：
- 顾客选择的哪些信息可以进入文案？
- 正面表达可以推荐到什么程度？
- 哪些词会把普通好感写成没有依据的最高级或绝对判断？
- 怎样使用顾客选中的重点，又不把它们堆成关键词？
- 当顾客没有说明曾多次到访时，过去经历应该怎样表达？
- 不同语言怎样各自生成，才能像自然表达而不是翻译？
这些问题都可以转成明确边界。例如，“少一点广告感”如果进一步区分普通的正面感受和“最好、完美、一定优于其他选择”等说法，就更容易执行。“写得更具体”也只有在细节必须来自允许使用的背景时，才不会变成编造。
从感受走到决定，是整套质量标准的起点。
区分顾客表达和商家偏好
Tap to Share 允许商家提供活动背景、可选重点、素材和平台。这些内容可以让顾客更容易参与，却不能把顾客评价变成商家写好的广告。
因此，质量标准里需要一条清楚的表达归属边界。商家背景帮助系统理解场景，顾客选择说明对方希望提到什么。AI 生成的内容只是可以继续修改的建议；最终怎样表达、是否发布，仍由顾客决定。
这条边界会直接影响文案质量。如果系统把每一个商家提供的词都当成必须出现的关键词，结果很快会变得拥挤而不自然。我更倾向于把顾客选中的重点当作相关性依据：使用真正支持这段评价的细节，省略不合适的部分，也不围绕它们虚构新的故事。
推荐强度也因此更清晰。顾客选择了正面重点，代表系统可以在当前情境中使用正面语言；这并不等于顾客授权了一条适用于所有人的推荐，也不支持与所有竞争者比较，更不能凭空加入效果承诺。
标准需要区分不同类型的失败
如果只用一个总分，很多重要差异会被藏起来。我把质量标准拆成可以独立检查的决定。
| 质量范围 | 标准需要回答的问题 | 常见控制方式 |
|---|---|---|
| 信息权限 | 每一个重要细节是否都有输入依据？ | 输入规则与内容主张门槛（claim gate） |
| 具体程度 | 内容是否使用了有意义的细节，同时没有补写故事？ | 生成规则与测试案例 |
| 推荐强度 | 正面语言是否停留在顾客表达的范围内？ | 用词边界与验证 |
| 顾客经历 | 文案是否暗示了未被确认的到访次数或时间长度？ | 情境规则与回归检查 |
| 重点使用 | 选中的信息是否自然进入文案，而不是被堆成关键词？ | 组织规则与人工验收 |
| 语言质量 | 每一种语言是否符合真实使用场景中的自然表达？ | 分语言生成与审阅 |
| 产品适配 | 它是否是顾客可以继续修改、也愿意使用的起点？ | 验收审阅与测试案例 |
这些分类让问题更容易定位。“输出不好”不再是一个笼统结论。团队可以判断，它涉及信息权限、事实精度、内容组织、语气、语言，还是产品整体是否好用。
分类也避免一种通过掩盖另一种失败。一段内容可以通过禁用内容主张检查，却仍然太空泛；同样，一点不影响事实与使用价值的句式问题，也未必应该阻止一个版本结束验收。
硬性门槛和质量判断负责不同的事
我把重大问题和一般编辑问题分开处理。
当输出越过明确边界时，适合使用硬性门槛。例如，它虚构了一次购买、暗示顾客曾反复到访、加入没有提供的私密细节，或使用不允许的绝对化说法。这些问题不应该依赖审阅者碰巧看见。
另一些问题需要判断。句子节奏可能不够顺，两处表达也许有点接近。内容在安全、有用和可以编辑的前提下，仍然可能有继续润色的空间。如果每一种偏好都变成拒绝规则，系统很容易变得脆弱，也会陷入没有终点的调整。
因此，我的验收同时包含确定性检查和对实际输出的可见审阅。前者保护明确边界，后者判断内容作为顾客看到的产品是否成立。剩余的非重大问题可以进入后续改进记录，无需假装它们不存在，也不必让当前版本永远无法结束。
原生语言质量必须从生成开始
Tap to Share 支持多种语言。最方便的做法，是先生成一个源语言版本，再把它翻译出去。这样也许能保留信息，却未必能保留人们真正会怎样表达。
英文、简体中文和繁体中文在句子节奏、直接程度和推荐习惯上都有差异。因此，质量控制需要从生成阶段就分别处理语言，再通过后续审阅确认。
不同语言共享同一条事实边界：只能使用允许的背景信息。表达方式不需要逐句对应。这个区别让产品可以追求自然语言，同时避免本地化过程产生新的内容主张。
每一项质量要求都要有执行路径
写下标准只是开始。每一个重大要求都需要连接到产品中的实际控制方式。
1. 先定义产品决定
说明产品想保护或实现什么。“避免未经支持的顾客经历”比“保持准确”更容易执行。
2. 写出可观察的失败
记录审阅者或测试会看到什么。例如，只知道当前体验，文案却让人理解为顾客曾多次到访。
3. 说明可接受边界
保留合理表达空间。普通过去时可以描述当前经历，而不代表长期关系；正面感受可以被写出来，也不必使用绝对排名。
4. 选择控制层
有些要求适合放进生成规则，有些需要确定性验证、测试情境、可见验收，或几层共同负责。最严格的控制方式并不一定最合适，关键是它是否匹配问题类型。
5. 加入回归案例
重大问题一旦修正，就保留一个有代表性的测试。之后改进其他部分时，不应悄悄把同一个问题带回来。
这五步把一次反馈变成可以长期使用的产品资产。质量标准会影响 prompt 和周边逻辑，却不等同于其中任何一项。
回归测试避免改好一处、退回另一处
AI 内容质量的不同目标会互相影响。加强具体性，可能鼓励系统加入没有依据的细节；收紧 claim 过滤，可能让文案重新变得空泛；追求句式变化，也可能削弱内容与顾客选择之间的联系。
因此，每次重大调整之后，我都会重新检查已经通过的代表性场景。目标不是把某一个分数推到最高，而是维持信息权限、实用性、顾客声音、语言和风险之间的整体平衡。
我也一直把 Review AI 和 Social AI 的质量标准分开。社交帖子与顾客评价在表达者、推荐方式、平台情境和激励边界上并不相同。把所有规则复用到两个系统里，文档会更简单，产品边界却会更模糊。
“通过验收”是一项有边界的版本判断
Review AI 的一个质量版本最终通过了生产验收。这个结论有明确范围：当时定义的证据、必要流程、硬性门槛和可见测试输出，足以支持该版本进入下一状态。
它不代表未来每一次生成都会完美。生成式系统会遇到新的信息组合和语言情境。验收建立的是一个已经测试的基线，也让之后出现退步时有据可查。新发现可以进入质量改进清单（backlog），再根据影响程度决定何时处理，而不是自动推翻所有已经完成的判断。
这是这段工作的核心经验。AI 产品不会因为团队列出一串喜欢的形容词，就自然拥有质量标准。只有当真实反馈被转成明确决定、每一个决定都连接到合适的控制方式，而且产品变化之后还能重新验证整套标准，质量才真正成为系统的一部分。