这批社区内容怎样标注示例
这批社区内容包含预先准备的编辑材料，以及编设的教学场景。读者无论在哪里看到它们，都应看到清楚的标注。它们不应被包装成客户自发的交谈，也不能拿来证明某次解读产生过真实结果。
以下标注方法是一份待审草案，说明在决定发布之前，这批内容应怎样区分示例。它不表示 Mystilink 已采纳某项社区政策，也不表示这些帖子已经发布。
说清读者眼前是什么
虚构练习帖应在开头附近标明是虚构练习；讨论拟议功能时，应说清功能尚属提案；模拟支持场景应说明问题是假设的。这些标签回答的问题不同，应保持具体。
比如，一个标题标为学习练习的帖子，可能介绍一位学习者如何比较同一图像的两种解释。开头应写清，这是为讨论而编设的场景。回复便可以提出不同方法，而不让人误以为几名真实用户分别经历过这件事。
产品说法还需要单独标注状态。虚构场景可能谈到检查过的仓库里存在的功能，但这不能证明已发布构建版本中可以使用。如果场景性质和功能状态都会影响理解，两者都要标明。
如实呈现身份与发言来源
预备帖子不得编造客户身份、专业资质或个人经历。教学材料可以用对话语气写得好读，而无须声称无人提供过的体验。编辑提示可以问“你会怎样记录这种不确定？”，再附上明确标为预先准备的示例回答。
如果用几种声音展示分歧，应说明它们是示例回复，不要让人误以为来自相互独立的客户。“我已经用了好几年”是在声称真实经历，除非确有其事并获准使用，否则应删掉。
署名贡献者只应获得与其实际贡献相符的署名。AI 辅助和编辑责任，应按团队正式采纳的披露规则说明。这批内容本身不能替公司制定这些规则。
区分讨论材料与证据
编设的帖子可以教一种方法，却不能证明客户需求、用户满意度或产品可靠性。虚构支持场景可以示范一份有用报告应包含什么信息，但不能计为真实缺陷报告。
同样，预备回复彼此赞同，也不证明社区持有共同观点。编辑应避免把这类帖子概括成用户共识。以后若收集到真实回应，应把它们的来源和性质，与预备示例分开。
虚构解读可以示范怎样保留牌序、怎样限定解释，却不能描述为准确预测。如果练习包括后来的结果，结果同样是编设的一部分，也必须保持相应标注。
让标记跟着复制内容走
读者经常通过预览、搜索摘要、截图或被引用的回复看到帖子。关键状态应写在容易与示例一同传播的文字中。标签藏在长页面底部，开头被分享出去时，它就可能丢失。
模拟支持场景可以用“假设性的故障排查练习”开头，让目的清楚可见。回复摘录可能还需要自己的简短说明，比如“预先准备的示例回复”。不要只靠颜色或小图标标记性质。
也要审查封面和图片说明。工作区插图若不是已发布功能的截图，就不应配上这样的说明。示意界面只要标为提案，并且不包含私人信息，也可以有用。
用另一套流程处理真实材料
以后若有真实社区成员提供案例，应取得符合预期用途的许可，并审查身份信息。公开用户名，并不自动代表允许把详细的个人故事重新刊载到营销文章里。
原始贡献和编辑改动都应有据可查。编辑压缩案例时，要保留影响含义的限定。不能靠选择性摘引，把一次不成功的体验变成正面证言。
团队也应决定，贡献者怎样申请纠正或移除。这些是拟议的流程要求，不是在宣称已有特定渠道或响应承诺。只有负责人批准且能够执行后，才应公布这些细节。
导入内容包之前审查标签
编辑审阅应检查每个标题、开头、回复和图片说明，找出隐含的经历声明。留意暗示实际使用、个人结果或集体认同的措辞。保留恰当的假设表述，改写含混的段落。
再把几个例子拿出完整语境单看：预览卡片、复制的回复、封面说明。只要其中任何一个像是未标注的客户叙述，就应在导入或分享前修正。
标记应帮助读者决定怎样使用材料。人们可以从虚构例子里学习，同时明白它提供的是可供讨论的方法，而不是某位客户身上真实发生过什么的记录。