如何给技术型 AI 产品写创作者 brief

规格表不是 brief。先说明使用者、困难任务和这次发布带来的变化，再解释实现机制。让内容有理由被关注，同时不丢掉技术实质。

明确主要受众和下一步。评估代码库的工程师与探索视频模型的导演需要不同背景，不要让一条帖子解释所有功能给所有人。

用短事实表记录名称、开放范围、支持环境、限制和有来源的结论。把建议 hook 与形式放在另一部分。创作者可以改变创意，不能即兴创造事实承诺。

对比较和基准测试提供原始来源、条件与日期。内部测试要注明是内部测试。没有可辩护证据，就不要使用最好或第一等笼统说法。

提供访问权限、样例输入与可复现流程。经历过实际限制的人比读脚本的人更能解释产品。列出技术联系人和报告演示故障的方法。

允许选择适合其受众的用例。教程、比较和个人工作流可以承载同一发布，同时增加不同信息。原创来自实际测试，不是替换复制文案里的词。

说明审核范围：事实准确、素材权利、禁发时间和付费关系披露。写明审批人和时间。披露不是可选备注，应使用适用的平台工具与规则。

审核应该纠错而不是抹掉声音。创作者发现限制时，应准确解释，不要假装不存在。保护信任也是交付的一部分。

回答七个问题：给谁看、改变什么、能证明什么、能试什么、不能声称什么、观众去哪、谁批准。把链接和负责人放在对应答案旁。

发布后记录 brief 漏掉的问题和纠正。下一次复用学习。brief 变好靠减少困惑，而不是增加品牌文件长度。