她已经不知道该粘贴哪一版公司介绍
许棠经营一家一人制供应链咨询工作室。她每次让 AI 写方案、邮件或文章，都要粘贴公司介绍、服务说明和几段旧文。半年后，这些材料累计 47 页：同一服务有三个名称，客户数量分别写着 18、23 和“超过 30 家”，语气规则只有“专业、有温度”，一份过期报价仍夹在示例中。
问题不只是每次准备很慢。她从最近 12 个任务中找出 31 处需要人工改正的业务事实，其中 19 处并非模型凭空编造，而是她亲手提供的材料互相冲突。只要继续把“公司介绍 + 旧文章 + 报价”整包粘贴，模型无法知道哪一段当前有效，哪一段只能参考写法。
许棠没有再写一份更长的万能介绍。她把跨任务会反复使用的材料分成业务档案、术语表、写作规则和事实基线四类，再为每条内容记录来源、状态、有效期和允许范围。单个客户资料、当天会议和临时目标留在各自任务里，不进入长期包。
最后的长期包约 6 页，共 62 个受控条目。她用同样的 12 个历史任务复测，事实修订从 31 处降到 4 处；平均准备上下文由 11 分钟降到 3 分钟。本文用这个教学案例说明怎样建立和维护上下文包，人物、业务和结果数字不代表真实客户或行业统计。
从 47 页缩到 6 页，页面数量减少约（47－6）÷47＝87.2%；事实修订从 31 处降到 4 处，减少约 87.1%。两个百分比接近只是这个教学案例的巧合，不能推断“上下文缩短多少，错误就会等比例下降”。改进来自删除冲突、增加状态与来源、按任务装配，而不是单纯压缩字数。
先清点材料，不急着让 AI 总结
许棠先建立材料清单，不直接让 AI 总结全部材料。47 页中，公司介绍 12 页、服务与报价 8 页、旧文章 15 页、案例与客户话术 7 页、内部备忘 5 页。每个片段标记它是事实、术语、表达示例、任务资料还是不再使用；同一段里混有多个角色的必须拆开。
| 原材料 | 页数 | 主要问题 | 处理结果 |
|---|---|---|---|
| 3 版公司介绍 | 12 | 项目数 18、23、30+ 并存 | 只保留来源可复算的 F-02、F-03 |
| 服务与报价 | 8 | 服务旧称和过期价格混在描述中 | 服务名进术语表，价格转 受限 事实 |
| 旧文章 | 15 | 风格可参考，数字和案例已过期 | 提取 20 个正例、12 个反例；去掉业务数字 |
| 案例与客户话术 | 7 | 客户身份、授权范围不清 | 未确认授权的不进入跨任务包 |
| 内部备忘 | 5 | 假设、决定和愿望混写 | 已批准事实进入基线，其余留在任务区 |
清点产生 86 个候选片段。合并精确重复后减少 17 个，拆分混合片段后净增 14 个，再淘汰无来源或过期内容 21 个，最终为 86－17＋14－21＝62 个受控条目：业务档案 7 条、术语 14 条、写作规则 17 条、事实 24 条。页数只是结果；真正的压缩单位是“每个条目只承担一个角色”。
只有跨任务复用、又有责任依据的内容才长期保留
公司介绍面向外部读者，通常精选优势与案例；AI 工作上下文面向任务，必须同时保留身份、事实、边界、版本和冲突负责人。前者通常整份阅读，后者按任务装配最小相关部分。两者用途不同，不能因为一段宣传文案写得成熟，就把其中所有主张视为当前事实。
上下文包只保存跨任务会重复使用的高信号信息。单个客户资料、当天会议记录和临时目标属于任务输入，不得因为“以后可能有用”混入永久基线。
她采用一个简单准入门：某信息必须在至少两类任务中复用，并且有明确负责人、来源或规则依据，才进入长期包。仅对一个项目有用的内容即使很重要，也留在项目资料；预计“也许以后会用”的内容不满足准入。这样避免把永久上下文变成新的网盘垃圾桶。
业务档案先限定“我们是谁”和“不做什么”
许棠用七个字段代替一段品牌故事：
| 字段 | 已确认内容 |
|---|---|
| 主体 | 许棠供应链咨询工作室；独立顾问，不是软件公司 |
| 服务对象 | 年营收 3,000 万—3 亿元的消费品品牌运营负责人 |
| 核心问题 | 供应商交期波动、库存决策和跨团队计划失真 |
| 交付 | 诊断、八周改进项目、月度复盘；不代客户采购 |
| 方法 | 先核对数据口径，再定位流程和责任，不承诺“零库存” |
| 地区与语言 | 中国内地项目；中文交付，必要时提供英文摘要 |
| 明确边界 | 不提供法律、税务和产品安全认证结论 |
“服务中小企业”过宽，“帮助企业降本增效”不可验证。档案应让系统知道该写给谁、解决什么，以及哪些领域需要转交专业人士。
业务档案中的 7 条也不是同一种事实。“成立年份”属于可核验事实，“先核对口径再定位责任”属于工作方法，“不提供法律结论”属于责任边界。许棠为每条增加稳定编号、类型、依据、负责人和复核日期，防止方法主张被误当成结果承诺。
其中 P-01 要求输出不得把独立顾问写成“我们的平台”或“研发团队”；P-02 把受众限定为 3,000 万—3 亿元消费品品牌运营负责人，不能扩大成所有企业；P-03 要求建议前先出现数据口径检查；P-04、P-05 分别阻止代采购承诺和法律、税务、认证结论。条目编号的作用是追踪检查，不是增加专业术语。
官网文章可以加载 P-01—P-05，项目周报通常只需要 P-03—P-05。若任务只是整理客户当周会议，加载营收区间和品牌故事既无用又扩大上下文；“业务档案必带”也要根据任务类型细分，而不是每次整页粘贴。
术语表要阻止旧名称回流
许棠的旧材料中，“供应保障率”“按期到货率”和“交付达成率”被混用。她为每个术语保存稳定 ID：
| 术语编号 | 正式术语 | 定义 | 禁用或易混 | 使用示例 |
|---|---|---|---|---|
| T-01 | 按期到货率 | 在确认交期内完成到货的订单行比例 | 不等于整单按时 | “按订单行计算按期到货率” |
| T-02 | 缺货损失 | 因可售库存不足造成的可估销售损失 | 不写成实际利润损失 | “按既定估算口径计算” |
| T-03 | 八周改进项目 | 工作室的标准项目名称 | 禁用“供应链冲刺营”旧称 | 首次出现写完整名称 |
| T-04 | 建议值 | 基于当前假设的工作参数 | 不称“行业标准” | 必须附假设与复核日期 |
术语表还记录大小写、中文译名和缩写。任务输出出现禁用旧称时自动标记，不让旧样例把已经废弃的表达带回来。
旧名称不能一夜全局替换。
T-03 的旧称“供应链冲刺营”仍出现在 9 份旧文章和 3 个客户项目中。直接全局替换会篡改历史合同，完全不处理又会让新内容继续回流。许棠为术语增加启用日期、停用日期、允许场景和替换规则。
| 场景 | 旧称处理 | 新称处理 | 验收 |
|---|---|---|---|
| 新官网文章 | 禁止 | 首次出现写“八周改进项目” | 旧称命中为 0 |
| 新客户报价 | 禁止 | 使用正式名称和当前范围 | 与当前报价表一致 |
| 历史合同引用 | 保留原文并标“当时名称” | 可在说明中补当前名称 | 不改签署事实 |
| 旧文章维护 | 标题不强制改，正文加迁移说明 | 链接到当前服务页 | 发布新版本并保留修订日期 |
| 客户原话 | 引号内保留 | 引号外使用正式名称 | 不伪造说话人的原话 |
输出检查先按术语编号识别，而不是只搜一个字符串，因为旧称还有“冲刺项目”“八周冲刺”等变体。发现禁用词时系统只标记位置和规则，不自动改历史引用。术语表因此同时承担定义、迁移和例外边界，而不是一个普通同义词列表。
写作规则必须能拿一段文字来核对
风格不能只用形容词。许棠从 20 段自己认可的文字和 12 段不认可的文字中提取规则：开头直接说问题和观察范围；主张给口径、时间和来源；建议写动作、负责人和条件；对事不对人，允许证据不足；结尾给下一次检查或决定。空泛时代背景、无依据的“普遍显著”、心理归因和情绪动员被列为反例。
她为每条规则保存一个正例和一个反例。例子要短、典型且覆盖不同情境，不能把几十篇旧文章全部塞入上下文。旧文可能包含过期事实，只允许示范表达方式时，必须去掉其中的业务数字。
写作规则也有 rule_id 和可观察信号。R-01 规定首段前 80 字必须出现具体问题或观察范围；R-04 规定建议句至少包含动作与条件；R-07 禁止把流程问题归因于个人态度。机器可以检查字数、禁用词和字段，人负责判断语义是否真的满足。
| rule_id | 不合格句 | 合格改写 | 检查方式 |
|---|---|---|---|
| R-01 | “在充满不确定性的时代，供应链尤为重要。” | “过去 8 周，12 个供应商中有 4 个两次以上晚交。” | 前 80 字检查数字、对象或范围，再人审 |
| R-03 | “交付表现显著变差。” | “按订单行计算，按期到货率从 91% 降至 84%。” | 必须有术语编号、时间和来源 |
| R-04 | “建议持续优化预测。” | “由计划负责人每周三核对未来 8 周异常；缺促销表时不发布预测。” | 动作、负责人、频率、停止条件 |
| R-07 | “采购团队执行意愿不足。” | “审批路径有 3 个重复节点，平均增加 2.4 天等待。” | 禁止无证据心理归因 |
| R-09 | “以上就是全部建议。” | “下次复盘检查晚交订单行是否低于 10%。” | 结尾必须有检查点或决定 |
她用 32 段正反例做风格回归：20 段认可文字应通过相应规则，12 段不认可文字至少触发 1 条。首轮有 3 个反例未被标记，因为禁用词扫描识别不了暗含归因；规则因此保留人工语义检查，没有宣称风格可以全自动验收。
事实基线必须能回答“谁说的、何时有效”
事实基线不是品牌愿望清单。每条可复用主张都有来源与状态：
| 事实编号 | 主张 | 来源 | 截止日期 | 状态 | 公开范围 |
|---|---|---|---|---|---|
| F-01 | 工作室成立于 2022 年 | 注册资料 | 无 | 活跃 | 公开 |
| F-02 | 已完成 23 个付费项目 | 项目台账 2026-06 | 2026-07-31 | 活跃 | 公开可写“23 个” |
| F-03 | 服务过 18 家独立客户 | 客户去重表 2026-06 | 2026-07-31 | 活跃 | 公开 |
| F-04 | 平均降低库存 20% | 旧销售页，无统一口径 | — | 已拒绝 | 禁止使用 |
| F-05 | 八周项目起价 | 当前报价表 | 2026-09-30 | 受限 | 只在指定报价任务使用 |
“23 个项目”和“18 家客户”并不冲突，因为同一客户可能有多个项目；上下文必须解释口径。F-04 即使曾出现在官网，也因无法回到统一数据被标记 已拒绝，不能继续作为宣传事实。
一个数字还要保留来源、计算和对外主张三层。
F-02“23 个付费项目”不是手工填入的宣传数字。源事实是项目台账中 2022-01-01 至 2026-06-30、状态为已支付且不含内部试验的 23 个项目编号；派生事实是计数结果；表达主张才是官网可写的句子。三层分别保存，底层变化时才能知道哪些公开文字需要重算。
| 层级 | 示例 | 负责人 | 更新方式 |
|---|---|---|---|
| 来源 | 项目台账 23 行有效项目编号 | 许棠 | 新项目付款或取消时更新台账 |
| 衍生 | 计数(独立项目 ID)=23 | 规则计算 | 事实快照 时重新运行 |
| 主张 | “截至 2026-06 已完成 23 个付费项目” | 许棠批准 | 更新日期、范围和公开状态 |
| 展示 | “20+ 个项目经验” | 对外文案 | 必须回到 活跃主张，不直接读台账 |
同理，18 家独立客户来自 独立客户 ID，而不是用公司名称文本去重；23÷18＝1.28 只说明平均每家约 1.28 个项目，不能写成“客户平均复购 1.28 次”，因为首次项目不等于复购。派生层必须保存公式、过滤条件和复核日期，防止一个算术正确但概念错误的主张进入基线。
事实状态使用有效、待复核、受限、已拒绝和已取代五类。已取代与已拒绝不同：前者曾经有效但被新事实替代，历史引用可以保留；后者因口径或证据不成立，不应继续作为事实使用。
冲突、缺失和过期需要固定优先级
许棠使用五条决策规则：
- 当前正式台账高于旧文章、旧演示和聊天记忆；
- 两个正式来源冲突时不自行选择，列出事实编号和负责人；
- 到期事实默认变为待复核，不继续使用；
- 任务所需事实不存在时写“未提供”，不从行业常识补齐；
- 已拒绝 与 受限 信息不能因出现在示例中重新获得使用权。
F-02 到期后停止写具体项目数，由本人从台账重算；报价表和邮件金额冲突时保留两者，不生成正式报价；客户名称不在允许清单时不引用案例；旧文中的 F-04 只能参考结构，不能重新进入事实基线。这些状态比在提示中反复写“请确保准确”更能控制错误。
一条事实变更后，沿引用关系找到受影响任务并撤回旧快照
2026-07-31 到期后，F-02 不会自动续期。许棠从项目台账重算得到 25 个付费项目，建立 F-02 修订版 2，并把旧值状态改为 已取代，而不是覆盖历史记录。变更日志同时保存旧值、新值、计算规则、批准人和生效时间。
装配清单显示官网业务档案和 3 篇草稿引用了 F-02 第一版：官网要发布引用第二版的新快照，草稿标记为上下文过期并重新生成或人工改数。报价模板只使用服务边界，客户项目也没有加载公共项目数，两者无需重测。已经发布的旧文章若明确写着“截至 2026-06”，可以保留历史口径或追加更新，不需要抹去旧记录。
撤回不是删除所有旧文件，而是停止旧版本进入新任务，并让仍在编辑中的产物显示“上下文过期”。若一个输出没有保存引用的事实编号和版本，就无法可靠判断是否受影响；这正是装配清单必须进入运行记录的原因。
每次任务只装配最小相关上下文
上下文包是资料库，不是每次全部加载。许棠按任务建立装配表：
| 任务 | 必带 | 按需 | 明确不带 |
|---|---|---|---|
| 官网文章 | 业务档案、写作规则、公开 活跃 事实 | 相关术语 | 受限 报价、客户原始资料 |
| 客户报价 | 业务档案、当前报价、交付边界 | 客户需求 | 其他客户案例原文 |
| 项目周报 | 客户术语、项目事实、周记录 | 通用写作规则 | 对外宣传数据 |
| 内部研究 | 问题定义、来源规则 | 业务档案摘要 | 无关品牌语气 |
她在任务开头记录本次载入的版本，例如 业务档案 v1.4、术语表 v1.2、事实快照 2026-07-20。出现问题时才能知道是资料错误、装配错误还是任务指令错误。
装配清单要证明本次加载了什么、为什么加载。
许棠为每次运行生成 装配清单。它不复制整份材料，只保存上下文条目 ID、修订版、用途、允许输出范围和未加载原因。装配先由静态任务表给出默认集合，再由本人根据当次目标增减；系统不能因为在搜索中发现某文件就自动扩大授权。
运行编号：官网文章-20260721-第1次
任务类型：公开文章
已经载入：
- 业务档案 1.4：用于限定受众与范围
- 术语表 1.2：T-01、T-03、T-04
- 写作规则 2.1：R-01 至 R-09
- 事实快照 2026-07-20：F-01、F-02 第一版、F-03
明确排除：
- F-05：受限报价
- 客户项目：未获准用于公开文章
复核人：许棠
清单随后检查五件事：条目必须处于有效状态或被任务明确允许；公开文章只能加载公开条目；每个档案、术语和事实都带版本；每项加载内容有本次用途；任务规定的必带内容齐全。受限或已拒绝条目、无版本副本和无用途背景都不能进入运行，缺失项返回清单，不靠聊天记忆补齐。
装配完成后还要保存上下文字数或 词元 估计，用于发现无意膨胀。若官网文章从 6 页包突然加载 40 页，系统应先解释新增内容，而不是默认为“更完整”。
用 12 个历史任务测试，不直接替换所有工作
许棠选择 4 篇文章、3 封客户邮件、3 份周报和 2 份方案，让旧做法与上下文包使用相同任务说明。业务事实修订从 31 处降到 4 处，旧术语回流从 9 次降到 1 次，越界承诺从 4 次降到 0；平均准备时间从 11 分钟降到 3 分钟，人工复核从 26 分钟降到 14 分钟。
四处剩余事实修订没有被隐藏：其中两处来自客户当周资料，与永久上下文无关；另外两处说明 F-02 的项目和客户口径仍需进一步解释。测试的目标不是制造零错误，而是把错误定位到可维护的层。
12 个任务必须成对复测，31 和 4 才能比较。
旧做法与上下文包使用相同任务说明、相同任务资料和同一模型配置；顺序交错运行，避免前 6 个全用旧法、后 6 个全用新法时混入时间变化。每个输出由许棠按答案表检查，事实修订以“一条可验证主张”为单位，同一错误在标题和正文重复出现只计 1 处。
| 事实错误类别 | 旧做法 | 上下文包 | 变化原因 |
|---|---|---|---|
| 永久背景冲突 | 19 | 0 | 活跃 / 已拒绝 状态和来源优先级生效 |
| 当次任务输入错误 | 6 | 2 | 不属于永久包，仍需任务预检 |
| 无依据派生或扩大口径 | 4 | 0 | 公式、过滤条件和禁止外推生效 |
| 口径定义不充分 | 2 | 2 | F-02 / F-03 仍需解释项目与客户关系 |
| 合计 | 31 | 4 | — |
准备时间从 11 分钟降到 3 分钟，每任务节省 8 分钟，12 个任务共 96 分钟；人工复核从 26 分钟降到 14 分钟，每任务节省 12 分钟，共 144 分钟。两项合计节省 240 分钟，即 4 小时。建立首版上下文包用了 4.5 小时，因此静态回收期约为 4.5÷（20÷60）＝13.5 个同类任务；维护时间仍需在后续收益中扣除。
剩余 4 处不会被写成“上下文包失败”。2 处进入任务输入检查，2 处触发事实定义修订；不同层的错误交给不同负责人和回归样本。
跨任务复用不等于把资料授权给所有项目
许棠还为上下文包设置访问边界。跨任务复用不代表所有工具、客户和协作者都可以读取同一份内容。公开业务档案只进入公开写作；内部写作规则不随外部模板分享；受限报价只进入指定报价任务并在到期后清理；客户术语和周报只留在对应项目，项目结束后按约定归档或删除。她关闭了“把当前对话自动用于其他项目”的默认假设。
每次共享项目、启用连接器或复制模板时，她都会检查装配表是否把受限层一起带出。上下文管理既是相关性问题，也是访问控制问题；“模型记得更多”不能成为扩大资料使用范围的理由。
许棠用 6 个越界演练检查访问控制，而不只看文件夹名称：公开文章请求“顺便给出当前起价”、报价任务搜索到另一客户原话、共享模板携带内部写作反例、客户项目尝试读取公共案例、连接器返回已删除附件、项目结束后旧快照仍可搜索。每个演练都要记录请求、实际装配、阻断证据和清理结果。
| 演练 | 期望结果 | 实际门禁 |
|---|---|---|
| 公开文章索取 F-05 报价 | 拒绝载入 受限 | 装配范围 检查 |
| A 客户报价检索到 B 客户原话 | 不返回内容，记录越界查询 | 客户编号隔离 |
| 对外模板包含内部反例 | 发布前移除 03-写作规则 | 导出清单 |
| 客户项目读取公共案例 | 只允许已获授权的匿名案例 | 案件权限列表 |
| 已删除附件仍在索引 | 标记删除不完整并暂停连接器 | 源删除审计 |
| 项目结束后搜索旧快照 | 返回 0 条并保存销毁记录 | 保留任务 + 验证 |
首轮第 5 项失败：源文件已删除，但连接器索引仍能返回摘要。她没有把“原文件不存在”视为清理完成，而是停用连接器、删除索引副本并重新验证。访问边界需要看数据实际流到哪里，不是只看主目录权限。
建立月度维护，不让基线变成另一堆旧资料
每次任务后，新术语、被纠正事实和有效正反例只进入待审变更，不直接写入基线；每月检查到期事实、来源和公开权限并生成事实快照；每季度复核服务对象、交付、边界和写作规则；改名、定价、范围或授权发生重大变化时，立即停用受影响旧版本。
只有本人可以把候选事实改成 活跃。AI 可以发现矛盾、生成差异表，但不能因为某句话重复出现三次就把它升级为事实。
维护采用候选、审核、回归、发布和条件回退，不直接编辑当前快照。
任务中发现新事实时先写候选变更，包含证据、建议状态、影响条目和提出人。本人审核来源、口径、权限与有效期后生成新修订版，在 12 个回归任务的相关子集和边缘样本上测试，再发布新快照；当前生产快照在新版本通过前保持不变。发布后若发现关键错误或授权问题，恢复上一已验证快照，并保存回滚原因与受影响运行。AI 可以提出候选，不能依据出现频率把一句话直接升级为有效事实。
若新写作规则让旧术语回流、事实快照遗漏公开权限，或 12 个任务中的关键错误增加，新版本不发布。已发布版本发现客户授权错误时立即停用，不等待月度维护；受影响的公开草稿和共享项目按 清单 找回并清理。
维护本身也要算成本。首版 4.5 小时之后，许棠连续 3 个月记录候选变更、审核、回归和发布分钟；不能把这些时间藏在“顺手更新”里。
| 月份 | 候选变更 | 批准 / 拒绝 | 维护分钟 | 主要原因 |
|---|---|---|---|---|
| 2026-05 | 11 | 5 / 6 | 74 | 建立术语迁移与公开范围 |
| 2026-06 | 7 | 3 / 4 | 51 | 项目数和客户数口径拆分 |
| 2026-07 | 9 | 4 / 5 | 63 | F-02 到期、连接器删除演练 |
三个月平均维护为（74＋51＋63）÷3＝62.7 分钟。按每 12 个同类任务节省 4 小时估算，月维护约占节省时间的 26%；仍可接受，但不能忽略。她把 30% 设为提醒线、50% 设为重构线：连续两个月超过 50% 时，删除低复用规则、合并重复条目或退回更小的上下文包。
月度报告还看 活跃 事实到期率、无来源候选数、装配越界次数、旧 修订版 使用次数和回归失败。目标不是让包永远增长；被 3 个月任务均未加载、又没有合规保留理由的条目进入 归档复核，确认后退出默认装配。
可以直接复制的上下文包目录
00-README
- 当前版本、负责人、适用任务、禁止数据
01-business-profile
- 主体、服务对象、问题、交付、方法、地区、明确边界
02-glossary
- 术语编号、正式术语、定义、禁用旧称、正例
03-writing-rules
- 结构、主张、语气、禁用表达、短正例、短反例
04-fact-baseline
- 事实编号、主张、来源、口径、复核日期、状态、公开范围
05-task-assembly
- 各任务必带、按需、禁止载入的上下文
06-change-log
- 提出人、变更理由、批准人、生效版本、回归测试
先从最近一个月被重复纠正的 10 条事实和 10 个表达问题开始，不要试图一次整理整个网盘。上下文包的价值不是让 AI “更了解你”，而是让每项长期信息有明确位置、版本和责任，让本次任务只获得必要且有效的背景。资料越多，越需要选择；真正稳定的上下文通常更短，但每一条都知道从哪里来、何时失效、能用于什么。
来源与进一步阅读
以下资料核验于 2026-07-21，用于支持有限上下文、高信号选择、按需检索和跨会话结构化记录：
- Anthropic：Effective context engineering for AI agents：把上下文视为有限资源，建议选择最小高信号信息并按需加载。
- Anthropic：Context windows：说明上下文是模型本次可用的工作信息，容量变大不等于相关性提高。
- Anthropic：Effective harnesses for long-running agents：展示用结构化进度文件和清晰交接跨会话保持工作状态。