你的 AI 在读 3000 行上下文但只有最后 500 行有用——上下文窗口管理的三个技巧

# ❌ 全量投喂：800 行上下文一次性塞进去
背景：我们是一个电商团队，后端用 Python 3.12 + FastAPI
数据库是 PostgreSQL，缓存用 Redis，消息队列用 RabbitMQ
项目结构：src/api/、src/models/、src/services/...
上个月重构了用户模块，方案是...
上周踩了三个坑：并发锁、缓存雪崩、消息重试...
今天要做的任务是...

# ✅ 热数据（每次新对话必喂，控制在 100 行以内）
# 文件：CONTEXT_HOT.md
当前任务：[一句话]
最近完成：[近 3 天的关键产出]
遗留问题：[当前开放的问题]
已知陷阱：[和当前任务相关的已知坑]
关键约束：[本次任务必须遵守的规则]

# ✅ 冷数据（按需检索，不默认加载）
# 文件：CONTEXT_COLD.md
完整项目背景
技术栈详情
历史决策记录
事故日志

# ❌ 过程记录：300 行
3 月 15 日讨论数据库选型：
我说：MySQL 还是 PostgreSQL？
AI 说：PostgreSQL 在 JSON 查询上有优势
我说：但我们大部分查询是关系型的
AI 说：那 MySQL 在你的场景下性能更好
我说：但团队对 PostgreSQL 更熟悉
...
（省略 200 行讨论过程）
最终决定：用 PostgreSQL

# ✅ 决策摘要：5 行
## 数据库选型（2026-03-15）
决策：PostgreSQL
原因：团队熟悉 + JSON 查询需求（未来会用到）
替代方案：MySQL（关系型查询更快，但团队不熟悉）
约束：所有新表用 UUID 主键，不用自增 ID

def distill_to_summary(raw_log):
    summary = {
        "decision": extract_final_decision(raw_log),
        "reason": extract_key_reason(raw_log, max=2),
        "alternative": extract_rejected_option(raw_log, max=1),
        "constraint": extract_derived_constraint(raw_log),
    }
    return summary

# 输入：300 行讨论记录
# 输出：5 行决策摘要

# ❌ 只有肯定信息
技术栈：Python 3.12 + FastAPI
ORM：SQLAlchemy 2.0

# 有一天你让 AI 做性能优化
AI：可以用 raw SQL 替换 ORM 查询来提升性能
你：但我们之前试过 raw SQL，维护成本太高，放弃了
AI：好的，那我换一个方案
# 浪费了一轮对话

# ✅ 否定信息让 AI 不走重复的弯路
技术栈：Python 3.12 + FastAPI
ORM：SQLAlchemy 2.0
已排除方案：
  - raw SQL → 维护成本太高（2025-12 决定）
  - Redis 做主存储 → 数据一致性风险（2026-01 决定）
  - Celery → 太重，用内置 BackgroundTasks（2026-02 决定）

# 每次放弃一个方案时，录一条否定信息
class RejectedSolution:
    def __init__(self, what, when, why):
        self.entry = {
            "方案": what,
            "放弃时间": when,
            "放弃原因": why
        }

# 例子
RejectedSolution(
    what="用 Redis 做 session 存储",
    when="2026-03",
    why="引入额外运维复杂度，内置 session 够用"
)

def context_health_check():
    # 1. 新对话首次回答命中上次断点率
    #    → < 80%：热数据不够精确
    #    → > 95%：热数据可能太多了（在记无关信息）

    # 2. 单次对话中需要人工补充上下文的次数
    #    → > 3 次：冷热分层没做好
    #    → = 0：正常

    # 3. AI 重复推荐已排除方案的次数
    #    → > 0：否定信息没有覆盖所有关键决策
    #    → = 0：合格
    pass