用活动通知 Skill 做一次事实检查：正式变更与冲突怎么处理

经常写活动通知的人，最怕的不是句子不好看，而是 AI 把旧时间写回去，或者热情地补出一个根本不存在的报名入口。这节课使用一份准备好的练习技能，检查它能否先处理事实与变更，再写通知草稿。它不发朋友圈，不创建报名表，也不替你决定活动安排。

你需要一个纯文本编辑器。要安装验证，还需要已经能正常使用自定义 Skill 的宿主；免费资源入门说明了 Claude 网页上传的准备步骤。本文先写文件、再用两组材料检查，不要求购买服务或运行代码。

先知道这次要检查什么

这次只处理“根据活动材料生成通知草稿”。输出分两部分：一段给主办者看的待确认项，以及一段供人工审核的通知。发生冲突时保留证据，不用更好听的说法掩盖问题。

为什么不顺手加海报、报名、群发？因为那些动作需要额外素材、工具和授权。先把文字里的事实做对，才能判断这份技能是否真的有用。本课不要求你设计新技能；后面的完整文件只是让所有读者使用相同的练习条件。

保存这份教学技能，准备同一套测试条件

在电脑上新建 event-notice-draft 文件夹，用记事本创建 SKILL.md。保存类型选择“所有文件”，使用 UTF-8 编码，并检查文件不是 SKILL.md.txt。下面是完整的原创教学模板，可以直接保存；它不依赖其他文件：

---
name: event-notice-draft
description: 根据活动原始材料整理事实、识别冲突并写中文通知草稿。用于社区活动、读书会等通知撰写；不创建报名入口或执行发布。
---

# 活动通知草稿

仅使用用户提供的活动事实。先检查活动名称、时间、地点、对象、人数、费用、报名方式和特殊安排。

区分正式决定、明确变更、个人猜测与尚未确认事项。只有材料明确说明替代关系的正式变更才替换旧信息；同级来源冲突且无替代关系时，列出冲突请用户确认，不自行按出现顺序选择。

材料没有提供的内容写“待确认”，不编造地址、费用、报名链接或联系人。不要根据未下雨的天气猜测取消雨天安排。

先输出“主办者待确认”，指出缺失、冲突及影响；再输出“通知草稿”。重要时间、地点仍冲突时，草稿保留醒目的待确认标记，不写成可直接发布的定稿。

通知采用清楚、友好的中文，先交代活动内容，再写参与条件和行动方式。已取消的安排不混入当前参与须知。

最后检查人数、日期、费用、物品限制与原始材料一致。只输出草稿，不发布、不发送、不创建表单。

文件夹名与顶部 name 对应；description 负责说明何时使用，正文负责说明怎么做。本练习不需要额外的 scripts 或 references 文件夹。先保持提供的文件不变，才能把“资料引起的变化”与“规则被你改过”区分开。

第一组材料：有明确的正式变更

保存文件后，在兼容宿主按其官方方式导入并启用完整文件夹。若使用本课链接里的 Claude 网页路线，把 event-notice-draft 文件夹压缩为 ZIP，包内保留该文件夹，不把所有文件直接散在 ZIP 根层。上传后在技能列表确认名称；普通聊天附件不等于安装。

新建对话，发送：

请使用 event-notice-draft，根据下面材料写通知草稿，不发布。
以下均为虚构练习材料。

A｜主办者初稿，9月1日：清风旧书交换会，9月12日周六14:00，社区图书馆一楼，限30人，免费。每人最多带5本，不收教辅。雨天照常。
B｜主办者正式更正，9月3日：活动开始时间改为15:00，替代9月1日初稿的14:00；其余安排不变。
C｜志愿者闲聊：我猜可能需要提前扫码，但还没看到报名通知。
主办者暂未提供报名方式，也没有提供联系人。

下面是教学预期，不是实测返回：主办者待确认部分应列“报名方式、联系人待确认”；时间使用15:00，因为 B 明确替代 A；地点、人数、费用、物品限制和雨天安排继续保留。C 是猜测，不能成为“请扫码报名”。

通知草稿可以这样写：

清风旧书交换会，带几本读过的书来换一份新发现。
时间：9月12日（周六）15:00。
地点：社区图书馆一楼。
活动免费，限30人；每人最多携带5本书，不接收教辅，雨天照常。
报名方式及联系人：待主办者确认。
本稿待补齐报名信息后再发布。

这里没有把“报名方式未知”包装成“现场自由参加”，也没有把“限30人”写成“仅剩30个名额”。一个是容量，一个是余量，不能互相替代。

第二组材料：同级来源冲突

换一个新对话，仍然使用这个技能，但换成全新输入：

活动：小河亲子拼图日，免费，最多12组家庭。
材料A：主办方打印单写9月20日10:00，活动室二楼。
材料B：主办方工作群消息写9月20日10:30，活动室二楼。
两份材料没有日期，也没有写哪个替代哪个。
请给通知草稿，我很着急。

这次正确行为不是挑10:30，也不是取中间值10:15，而是指出开始时间冲突，向主办方确认哪个有效。可以先写其他确定内容，但时间必须保持“待确认”，不能因为用户说着急就擅自定稿。

如果它总选最后出现的一条，回看你的规则是否写了“以最新内容为准”。“最后粘贴”不等于“最新正式决定”。本模板把这个区别直接写进正文，比补一句“千万别出错”更有用。

再检查一次：它会不会到处抢任务

发出一个不相关请求：“请解释什么是光合作用。”这个请求不应被活动通知格式接管。若宿主仍自动调用该技能，检查描述是否过宽，或是否在同一对话中被你明确指定持续使用。用新对话复测，避免把上下文延续误判成触发错误。

反过来，发“根据这些活动信息写一份群通知”应属于它的适用范围。测试时同时记录“应当使用”和“不应当使用”的情况，才能发现描述是否真正有区分度。

修改时一次只修一个真实问题

如果5本变成5件，修物品单位；如果漏掉雨天安排，增加末尾事实复核，不必因此规定所有通知都必须有天气条款。如果模型编了报名入口，先确认规则是否加载，再修补缺失项处理。

每次修改后重新导入或按宿主更新方式保存，换新对话再测两组材料。只看旧对话里“我明白了”不够，因为那可能只是本轮聊天记住了要求，并非文件已经更新。

最后，保留你手里的原始材料与审核后的草稿。Skill 的价值是减少重复交代、稳定工作方法，不是取消人的确认。你能解释15:00来自哪份更正，也能在10:00与10:30冲突时停下来，这份小技能才真正帮上了忙。