交付标准落在文稿上的样子
标准存在的意义是减少来回。客户团队把内部审核要求提前给到项目组，项目组按本页条目产出内容方案，双方在同一套口径上判断是否完成，避免方案已经写完才发现表述方式与内部要求不一致。涉及流程步骤的说明请查看 合作流程 页，涉及服务项目适用阶段的说明请查看 服务范围 页。
交付标准条目表
下表按标准类别逐条列出内容方案的判定方式与责任方。判定方式描述的是可以当场核对的动作，责任方说明该条目由谁主要承担，双方共同承担的条目需要客户团队在确认环节明确表态。
| 标准类别 | 条目 | 判定方式 | 责任方 |
|---|---|---|---|
| 选题依据 | 选题与客户业务目标、传播节点有明确对应关系 | 方案开头写明选题来源与对应任务，客户团队能指出该选题服务于哪项业务目标 | 项目组主责，客户团队确认 |
| 选题依据 | 热点判断说明判断理由，不直接给结论 | 方案中保留判断依据段落，可看到取舍逻辑，而非只有一句“建议跟进” | 项目组 |
| 事实核查 | 涉及的数据、时间、名称均有可追溯来源 | 逐条核对方案中的事实性表述，来源标注到具体出处，无法核实的表述删除或改为限定说法 | 项目组核查，客户团队提供内部资料 |
| 表述合规 | 不使用效果承诺、绝对化说法与未经证实的比较 | 通读方案，凡涉及数量、排名、效果结果的表述一律检查，未获证实的一律改写或删除 | 项目组 |
| 表述合规 | 行业表述符合客户所在领域的用语习惯与监管要求 | 客户团队提供行业禁用词与必用表述清单，项目组按清单逐项比对 | 客户团队提供清单，项目组执行 |
| 格式规范 | 结构完整，标题层级、段落长度与标点统一 | 按客户团队提供的格式模板逐项检查，模板未覆盖的部分按项目组默认规范执行并标注 | 项目组 |
| 格式规范 | 交付文件命名、版本号与留档方式统一 | 交付时附带文件清单，命名规则与版本号在项目启动时约定，后续修改沿用同一规则 | 项目组 |
修改轮次与确认方式
修改不是无限次重写，而是在已确认方向上做调整。
内容方案首次提交后，客户团队在约定时间内给出汇总意见，项目组按汇总意见完成一轮集中修改。把意见分散在多个渠道陆续提出，会让修改失去参照点，也容易让已确认的部分被反复推翻。
确认方式以书面回复为准。客户团队在回复中明确标注“确认”“按意见修改”“保留待议”三类状态，项目组据此推进。标注为“保留待议”的部分不进入本轮修改，单独记录，等条件成熟再处理，避免整份方案被个别未定事项拖住。
如果修改意见超出原定方向，例如更换选题角度或调整目标受众，这类调整按新的工作范围处理，项目组会先说明影响范围与所需资料，客户团队确认后再推进。
事实核查与合规责任划分
核查与合规需要双方各自承担清楚的一部分。项目组负责公开信息的核查与表述层面的合规检查，客户团队负责提供内部资料并对自身业务口径负责。
-
项目组承担的部分
核查方案中引用的公开信息，标注来源；检查表述是否含有未获证实的效果说法；按客户团队提供的行业禁用词清单逐项比对；在交付时列出仍需客户团队确认的事项。
-
客户团队承担的部分
提供与业务相关的准确资料，包括产品名称、业务范围、内部术语口径与行业监管要求；确认方案中涉及自身业务的表述是否与实际一致；对内部尚未定论的事项提前说明，避免方案建立在未定信息上。
-
双方共同确认的部分
涉及对外发布的表述，由客户团队最终确认。项目组提供核查结果与合规检查记录，客户团队结合自身判断给出确认意见，确认记录随方案一并留档。