某个客户要求活动文案不用正式称谓，助手修改几轮后记住了。下一位客户的稿件却也沿用这套口吻。问题不是记得不够牢，而是把一次项目例外变成了所有工作的默认要求。
原助手的项目隔离和专用模板能解决时，就先用它们。客户不多，把资料分开放更容易核查。EasyNet 的连接价值在于让不同助手复用同一处理方法，同时按当前项目取得不同材料，而不是集中成一个无边界的记忆池。
项目负责人可以维护带客户、活动、有效期和确认人的规则条目。接出的查询函数接受获准项目标识，返回该范围的当前要求和版本；写作函数仍可复用，客户素材不混进公共模板。Context 保存引用，但规则继承与冲突处理需要专门实现。
访问范围应在查询服务判断，不能让模型随意填客户标识。发送给写作工具的材料只包含本次所需内容；默认不加载其他客户，再靠一句保密提示阻止引用。输出草稿也应标明依据哪份要求，供负责人核对。
活动结束后，哪些要求失效、哪些转为长期品牌规则，需要由人确认。全局规范与项目例外冲突时，返回冲突而非擅自提升例外优先级。即使访问范围正确，模型也可能模仿过去的措辞，交付前仍要阅读。
拿两个客户的任务同时试写，确认乙的查询没有返回甲的条目，再检查过期活动规则是否被排除。以后复用的是共同做法，例外留在有理由适用的那次工作里，不必在每次新任务开头提醒助手忘掉上一个客户。
- 01
选择客户乙任务
身份确定可读项目
- 02
取得有效要求
排除甲的例外与过期规则
- 03
复用写作函数
草稿附上所用规则版本
只选当前项目的有效规则
纯本地筛选例子；project 必须来自服务端已验证的任务范围，不能将这段筛选当身份认证。
本地示例 · python
rules = [
{"project": "A", "until": "2026-09-30", "tone": "casual"},
{"project": "B", "until": "2026-09-30", "tone": "formal"},
{"project": "B", "until": "2026-08-31", "tone": "playful"},
]
project, today = "B", "2026-09-07"
active = [r["tone"] for r in rules
if r["project"] == project and r["until"] >= today]
assert active == ["formal"]
print(active)预期结果：输出 ['formal']；甲的 casual 与乙的过期 playful 都不进入输入。
接入时的检查项
- 客户乙的测试任务是否不会读取客户甲的规则或材料。
- 过期例外是否被明确排除。
- 冲突的全局与项目要求是否有可检查的处理依据。