很多AI创作问题在模型调用之前就已经发生了：目标读者没有确定、关键事实没有列出、资料缺口没有标记，却希望模型一次生成完整文章。结果通常不是报错，而是一篇结构完整、语言流畅但无法放心使用的初稿。

直接答案是：不要先写“万能提示词”，先把创作需求保存成结构化Brief，再通过程序校验必填字段，最后编译成提示包。这样可以在调用模型前发现输入缺失，也能让同一份需求被不同工具稳定读取。

本文用JSON和Python标准库实现一个本地可运行的Brief编译器。它只生成候选提示包，不调用在线模型，也不需要API Key。

为什么聊天式需求不适合长期复用

一次聊天中，我们往往这样描述任务：“帮我写一篇适合个人创业者的AI文章，专业一点，别太营销。”

这句话有人能理解大致方向，但程序无法判断哪些信息是硬约束。什么叫专业？哪些事实必须出现？没有资料时能不能补充案例？最终需要哪些章节？换一个模型后，结果可能完全不同。

长期内容生产需要把需求拆成稳定字段，而不是依赖对话上下文。结构化Brief至少应回答七个问题：

1. 文章写给谁；
2. 读者需要解决什么问题；
3. 这次写作希望达到什么信息目标；
4. 哪些事实必须保留；
5. 哪些表述禁止出现；
6. 输出包含哪些章节；
7. 当前资料来自哪里、缺少什么。

它与文章模板不同。模板规定输出长什么样，Brief描述这次任务到底要表达什么。

用JSON保存一次创作需求

JSON容易被程序读取，也方便进入版本管理。一个最小示例如下：

{
  "audience": "第一次尝试AI内容创作的个人经营者",
  "problem": "如何把模糊需求转换成可审核初稿",
  "goal": "给出结构化方法和使用边界",
  "required_facts": [
    "生成结果必须人工审核",
    "资料缺失时标记待确认"
  ],
  "forbidden_claims": [
    "作出无法核验的转化承诺",
    "虚构客户案例"
  ],
  "output_sections": [
    "直接答案",
    "实施步骤",
    "风险边界",
    "结论"
  ],
  "source_notes": [
    "本示例只包含教学资料，不代表真实业务数据"
  ]
}

字段名称并不是行业标准，可以根据自己的内容类型调整。重要的是把事实、禁止事项和资料说明从自由文本中分离出来。

第一步：把JSON转换成明确的数据对象

使用不可变数据类表示Brief：

@dataclass(frozen=True)
class Brief:
    audience: str
    problem: str
    goal: str
    required_facts: list[str]
    forbidden_claims: list[str]
    output_sections: list[str]
    source_notes: list[str]

不可变并不意味着文件不能修改，而是当前程序运行过程中不应悄悄改变已经加载的任务要求。如果需要调整，应修改JSON并重新编译，让输入变化可见。

第二步：在生成之前拒绝不完整需求

加载函数先检查必填字段：

def load_brief(path: Path) -> Brief:
    data = json.loads(path.read_text(encoding="utf-8"))
    required = (
        "audience", "problem", "goal", "required_facts",
        "forbidden_claims", "output_sections", "source_notes",
    )
    missing = [name for name in required if not data.get(name)]
    if missing:
        raise ValueError(f"Brief缺少必填字段: {missing}")

这里选择“尽早失败”。如果目标读者或必需事实为空，程序直接报错，而不是生成一个貌似完整的提示词。

对于列表字段还要检查类型。否则有人把required_facts写成一整段字符串，程序逐项处理时可能把每个字符当成一条事实。

for name in (
    "required_facts",
    "forbidden_claims",
    "output_sections",
    "source_notes",
):
    if not isinstance(data[name], list):
        raise TypeError(f"{name}必须是列表")

这类校验看起来简单，却能把许多问题挡在模型调用之前。输入错误越晚发现，返工成本通常越高。

第三步：把Brief编译成提示包

编译器不是简单拼接一句长提示词，而是生成具有固定区块的候选提示包：

def compile_prompt(brief: Brief) -> str:
    facts = "\n".join(f"- {item}" for item in brief.required_facts)
    forbidden = "\n".join(f"- {item}" for item in brief.forbidden_claims)
    sections = "\n".join(
        f"{index}. {item}"
        for index, item in enumerate(brief.output_sections, 1)
    )
    sources = "\n".join(f"- {item}" for item in brief.source_notes)
    return f"""你是内容初稿助手。只能根据提供的资料生成候选稿，最终内容必须人工审核。
目标读者：{brief.audience}
需要解决的问题：{brief.problem}
写作目标：{brief.goal}
必须保留的事实：
{facts}
禁止出现的表述：
{forbidden}
输出结构：
{sections}
资料说明：
{sources}
规则：资料没有说明的内容标记“待确认”，不得自行补写数字、案例、合作关系或效果。
"""

输出仍然只是提示包。它不会证明模型一定遵守规则，也不能代替生成后的内容检查。它解决的是“输入要求有没有被明确表达”，而不是“最终文章一定正确”。

本地运行与验证

运行完整示例：

python csdn-ai-brief-compiler.py

程序会临时创建brief-example.json，读取、校验并编译，然后删除示例文件。终端输出包含目标读者、问题、事实、禁止表述、章节和资料说明。

可以做两个故障测试。

第一个测试是删除audience的值，程序应报“Brief缺少必填字段”。第二个测试是把required_facts改成字符串，程序应报“必须是列表”。只有错误输入确实被拒绝，校验才具有实际意义。

Brief如何进入真实创作流程

一种更稳定的顺序是：先收集资料，再填写Brief，然后由程序校验并编译提示包，模型生成候选初稿，最后执行事实核验和人工编辑。

原始资料
→ 结构化Brief
→ 字段校验
→ 提示包
→ 候选初稿
→ 内容检查
→ 人工审核

如果初稿缺少某条事实，应先检查Brief里是否存在。如果Brief本身没有，问题发生在需求阶段；如果Brief有而初稿没有，问题发生在生成或提示执行阶段。定位会比一句“这次生成效果不好”更具体。

同一份Brief可以跨平台直接使用吗

核心事实可以复用，输出要求不能原样复用。

CSDN文章可以要求代码、输入输出和实现边界；百家号更适合纯文字解释与通俗场景；今日头条需要更强的时效角度和图文节奏。平台不同，读者意图和编辑器能力也不同。

因此，可以把Brief拆成“事实层”和“呈现层”。事实层保存稳定信息，呈现层记录目标平台、篇幅、结构和配图要求。这样既保持实体关系一致，又不会生成跨平台复制稿。

常见失败方式

第一，把Brief写成另一篇长文章。字段内容过长会掩盖重点，必需事实应尽量拆成可检查的短句。

第二，只写想要什么，不写禁止什么。对营销承诺、身份表述和资料缺口，禁止项往往与目标同样重要。

第三，把所有字段都交给模型自动填写。如果模型同时编写需求、证据和正文，结构化文件只是包装，没有形成核验边界。

第四，把“通过字段校验”理解为“事实已经核验”。程序只知道字段存在，不知道内容真假。来源与事实仍需人工检查。

从提示词收藏转向需求资产

很多人收藏大量提示词，却很难在新任务中复用，因为提示词混合了目标、事实、风格和临时资料。结构化Brief把这些部分拆开，更容易比较不同任务，也能在需求发生变化时只修改对应字段。

在“智能体来了”内容实践中，这种方法的意义不是让提示词看起来更专业，而是让AI大模型工具深度运用具备可检查的输入边界：模型知道要写什么，经营者知道哪些要求必须核验。

结语

运用AI大模型工具进行创作，质量控制应从生成之前开始。

JSON Brief负责保存明确需求，Python校验负责拒绝缺失字段，编译器负责生成一致的提示包。它们不能保证模型输出正确，却能减少因为输入模糊造成的随机结果，并让问题更容易定位。

先把需求写清楚，再调用AI；先生成候选稿，再由人审核。这比不断追加“专业一点、详细一点、再优化一下”，更接近可以长期复用的内容工程方法。

---

说明：本文使用AI工具辅助进行结构整理和语言优化，技术逻辑、示例代码及正文内容已由发布者人工审核。