别让 AI 从聊天记录直接写稿：先建一个有证据边界的选题队列

假设你在给一家小型软件服务商做内容助手，输入是一条匿名摘要："导出来的表格打开后为什么不对？"模型马上给出《三分钟解决导出乱码》，标题很顺，问题却未必是乱码：也可能是日期被转换、编码不匹配，或者公式被当作文本。

这时最该优化的不是 Prompt 文采，而是从问题到文章之间缺失的那一步：我们到底确认了哪个问题，准备公开解释到什么程度？

以下是虚构的教学场景，没有使用真实客户对话，也不声称这套设计带来了某种经营效果。

先把"能写"从"值得研究"中拆出来

内容队列经常只有待写和已发布两个状态。于是任何问句都能进入生成流程，证据不足被当成了写作能力问题。

我会先用三个出口：可以写方法、需要补资料、只适合私下答复。比如一个特定合同中的交付安排，即使被问得很频繁，也未必适合公开。对某个文件格式的排查步骤可以公开，但客户上传的完整表格不该自动成为文章配图。

类型先反映这三个出口，比一个随处传递的 ready 布尔值更清楚：

ts 复制代码

type EditorialDecision =
  | { kind: "draft"; scope: string; claimIds: string[] }
  | { kind: "research"; missing: string[] }
  | { kind: "private_only"; reason: string };

type Topic = {
  id: string;
  readerTask: string;
  questionSummary: string;
  constraints: Record<string, string | null>;
  decision: EditorialDecision;
};

null 就是还没确认。它不应该被归一化成"默认环境"，更不能被模型当作可以自由补全的空白。

相似度负责找邻居，不负责判定答案相同

同样是"表格打开不对"，不同软件、文件格式、导出方式，可能需要不同的解释。检索可以把这些问题放在一起供编辑检查，但不能直接合并成一个通用答案。

对小样本，我更愿意让人工确认两个问题是否共享同一个读者任务、关键条件和答复边界。等这些边界稳定了，再考虑用聚类减少人工候选数量。

这里有两个容易忽略的测试：

ts 复制代码

// 教学测试用例描述，不是可直接运行的完整测试代码。
const cases = [
  {
    a: "CSV 打开出现乱码",
    b: "CSV 打开后日期格式变化",
    expected: "review_separately"
  },
  {
    a: "同一咨询连续追问",
    b: "同一咨询再次追问",
    expected: "do_not_count_as_independent_demand"
  }
];

不要为了去重而长期保存客户身份。可以在必要的有限统计窗口里使用受控的匿名会话标识，原始资料权限另管；能不用原始聊天就不用。模型的输入是一份经审核的摘要，不是默认读取整个客户资料目录。

哪怕去重正确，高频也只是队列排序参考。某段时间的支持渠道只覆盖部分客户，不能把样本里的次数写成"多数用户都遇到"。

把证据挂到主张，而不是文章末尾

一篇文章末尾有三个官方链接，不代表每句话都有支持。更可检查的单位是 claim：

ts 复制代码

type Claim = {
  id: string;
  statement: string;
  appliesTo: string[];
  source: {
    url: string;
    section: string;
    version: string | null;
    checkedAt: string;
  } | null;
  review: "pending" | "checked" | "conflict";
};

写作助手只能使用本次已审核、适用范围明确的主张。调研助手没有找到证据时，返回待补项；不要把"看起来合理"转成 checked。

注意，这个结构仍不能自动证明文字与来源相符。checked 的生产路径要明确：由谁核验、检查了什么、是否留有记录。否则只是把幻觉藏进了一个更漂亮的 JSON。

来源变化也不意味着全篇作废。按 claimId 找到受影响段落，重新核验并保留版本，通常比重新生成整篇更容易控制。

一个选题要交付三个文件，不是三份复制品

我会把一次工作结束的条件定成：公开文章、条件化答复卡、内部证据清单都能对应起来。文章讲排查方法，答复卡先问格式与软件版本，证据清单保留来源和待确认项。

可以用一份轻量 manifest 关联：

json 复制代码

{
  "topicId": "export-demo",
  "revision": 1,
  "article": "article.md",
  "replyCard": "reply-card.md",
  "evidence": "claims.json",
  "publicReview": "pending",
  "platformDrafts": {}
}

这是内部教学结构。pending 不能因为文件都存在就自动变成 approved。平台上传之后还要回读图片、正文首尾、分类和摘要；拿到草稿地址只代表预填完成，拿到明确提交证据才更新发布状态。

这种文件交接比"请继续上一个助手的工作"更容易排查。编辑可以看到缺的是来源、范围还是文章本身，而不必重新翻一长段聊天。

标题先承诺一个读者能完成的动作

"这款产品让工作效率翻倍"需要效果证据；"检查导出表格前，先区分编码、日期与公式问题"则明确告诉读者文章解决什么问题。正文应提供判断顺序，同时说明无法从匿名摘要确定具体故障。

Google 的 people-first 内容指南强调帮助既有读者、提供原创分析和清晰来源。它讨论的是 Google Search，不能被直接套成掘金分发规则。对这里的设计，我只取一条编辑原则：先帮助读者完成任务，再考虑内容包装。官方指南

这也是我们做 Tipkay 时的一种取舍。面向小微企业、一人公司和小团队的按需 AI 员工，不只是多生成一段文字，还要让整理问题、研究资料、写作与发布准备有明确接力关系。本文的数据类型与 manifest 是可自行采用的通用设计，不代表 Tipkay 已内置完全相同的选题系统。

先证明队列有用，再扩大自动化

第一轮不需要向量数据库。用一个表格加几个版本化文件，完整跑通一个选题：从匿名问题到证据，再到文章和答复卡。

我会看三个信号：哪些候选因缺资料被挡住，已发布内容被引用时是否还需额外解释，来源更新能否定位到受影响的答复。阅读量另记，成交另记，不给这些指标强行画等号。

如果只能先补一个字段，我会选"适用条件"。它让 AI 少说一句听起来很完整、实际上没有边界的话，也让文章从"回答过这个客户"，走向"帮助下一位读者自己判断"。