【AI Coding】0-工程化视角理解AI Coding与LLM应用的上下文演化
- [AI Coding与LLM应用演进方向](#AI Coding与LLM应用演进方向)
-
- AI应用的问题
-
- [AI Coding的问题](#AI Coding的问题)
- LLM应用的问题
- 主流方案：上下文工程的演进路径
-
- 工程化视角：为什么上下文管理是核心命题？
- [Modern Context Engineering：四象限方法论](#Modern Context Engineering：四象限方法论)
- [Skills 与 Cowork：让上下文越来越纯粹](#Skills 与 Cowork：让上下文越来越纯粹)
- 模式对比：一张表看清上下文演化脉络
- [AI Coding 的设计趋势：系统侧编排取代对话内堆砌](#AI Coding 的设计趋势：系统侧编排取代对话内堆砌)
- 小结
AI Coding与LLM应用演进方向
这个系列会讲一些AI应用的事情，计划从演进方向到工程化应用，从问题到解决问题。
本篇会先讲述AI的问题与现在的主流方案。
AI应用的问题
AI应用在这里指的是AI Coding与LLM应用，在这几年的发展中，AI的应用一直有这不少的问题。
下面就上下文的演化进行说明。
AI Coding的问题
从rules到skills、cowork再到harness。
● 静默执行错误
AI在生成代码时，会根据上下文"脑补"一些不存在的信息。比如你给它一个API文档，它可能会"幻觉"出文档里根本没有的字段，然后基于这个幻觉继续编写调用代码。
这种情况下，代码看似正常跑通了，但实际逻辑完全跑偏。
静默执行错误认知行为，比如上下文幻觉，比如复杂上下文的信息丢失：
复杂任务的细节丢失，比如spec-kit生成的难以用来生成代码的产品白皮书和技术白皮书。
● 上下文信息丢失
现在AI Coding有一个头疼的上下文丢失现象，复杂项目做到后期，前面写过的设计决策、架构约定、业务规则"人间蒸发"。
也就是 Context Rot（上下文衰减），随着上下文窗口中的token增加，模型准确调用信息的能力会下降。
● 需求传递损耗
产品文档写得很好，但AI生成的代码完全不对味。或者分析的计划很好，但是执行计划的时候错漏百出。
比如Spec-Kit，从产品白皮书→技术方案→代码，这条信息传递链上存在巨大的语义损耗。
LLM应用的问题
从Simple RAG到Multi Agent，从Prompt Engine到Context Program。
RAG我们需要大量的召回，维护知识库。
Multi Agent我们需要复杂的记忆架构、角色拆分来应对逐步爆炸切各Agent之间不一定同步的上下文。
主流方案：上下文工程的演进路径
这些问题，无一不在诉说着我们需要对上下文进行更高效的管理。
随着 AI 能力的提升，我们在用越来越少的上下文工程，做到越来越高效的事情。
这背后有一条清晰的工程化演进脉络：
从"对话内堆上下文"→ 到"系统侧编排上下文"。
工程化视角：为什么上下文管理是核心命题？
从工程化的视角来看，AI Coding 与 LLM 应用的所有问题，本质上都可以归结为一件事：
如何在有限的上下文窗口里，让模型拿到它真正需要的信息，同时屏蔽掉它不需要的噪声。
早期的解法很直白：信息不够？塞进去。效果不好？再塞。
Prompt 里堆满了规则、示例、API 文档节选，上下文窗口越用越长，
模型却越来越"迷糊"------这就是典型的上下文膨胀陷阱。
真正稀缺的不是上下文长度，而是有效 Context 的组织能力 。
LLM 能力越强，我们越敢于做"减法"。
Modern Context Engineering：四象限方法论
现代上下文工程的核心，可以用四个维度来描述：
| 策略 | 含义 | 典型手段 |
|---|---|---|
| Offload（外置） | 将信息存到外部，不占窗口 | 向量库、知识图谱、外部记忆系统 |
| Retrieve（精召） | 按需精准检索，而非全量注入 | grep、LSP、语义搜索、结构化查询 |
| Reduce（压缩） | 对已有上下文进行智能摘要与裁剪 | 滑动窗口、摘要链、Token 预算管理 |
| Isolate（隔离） | 任务级别的上下文隔离，避免污染 | Skills、子 Agent、独立会话 |
正如 Claude Code 用 grep 替代全量向量检索------
正确的工具 + 精简上下文，远胜于冗长提示词堆砌。
当 LLM 不再被噪声淹没，静默执行错误、需求传递损耗等顽疾自然消解。
这正是"用更少上下文工程实现更高效能"的底层逻辑。
Skills 与 Cowork：让上下文越来越纯粹
近几个月火爆的 Skills 与 Cowork 模式，正在让上下文越来越少、越来越纯粹。
因为不再需要 LLM 使用大量的上下文去推理，去分析在长对话后可能出现幻觉的问题，
而是将任务直接派发给一个预置了专项能力和极简上下文的 Skill。
● Skills（技能）：可以理解为一个个"即插即用"的微服务
每个 Skill 都高度专业化（例如 ReactComponentSkill、SQLQuerySkill），
其内部已经固化了执行特定任务所需的最核心指令和工具。
当 LLM 接到一个复杂请求时，它不再需要翻阅大量的 API 文档和历史对话来"学习"，
它只需要做一个简单的路由决策："这个任务应该调用哪个 Skill？"
● Cowork（协同）：这是 Skills 模式的自然延伸
当一个任务需要多个 Skills 协同时，一个轻量的"协调者"（Orchestrator）会出场。
它的上下文极其纯粹：只包含任务目标、可用的 Skills 列表以及它们之间的输入输出约定。
它不关心每个 Skill 内部是如何实现的，只负责按照工作流将它们串联起来。
这就好比一个项目经理，他不需要懂得如何敲代码或画设计图，
但他清楚地知道：应该先让设计师出稿，再让工程师开发，最后让测试验收。
● ClawBot：协同的更高形态------容错与接替
如果说 Cowork 是让多个 Skills 像团队一样"各司其职"，
那么 ClawBot 则是让这个团队具备了**"主动补位"**的能力。
它的核心思想是动态故障检测与任务重新路由：
- 某个 Skill 执行失败？自动切换备用路径；
- 某段上下文检索结果置信度低？主动触发二次召回；
- 多个 Skill 输出结果有冲突？由 Validator 层进行裁决。
ClawBot 的本质，是将传统 Agentic Loop 中"人工兜底"的部分，自动化地内建进了系统架构。
模式对比：一张表看清上下文演化脉络
| 模式 | 核心逻辑 | 上下文特征 | 核心痛点解决 |
|---|---|---|---|
| Simple RAG | 向量匹配 Top-K | 碎片化、易丢失逻辑 | 补充外部静态知识 |
| Multi-Agent | 角色分工 + 状态机 | 冗余度高、同步难 | 处理跨模块复杂任务 |
| Skills/Cowork | 工具化 + 状态共享 | 精简、确定性高 | 消除推理幻觉，提升执行力 |
| ClawBot | Agentic Search（grep/LSP） | 按需加载、自验证 | 解决大规模工程的检索精度 |
AI Coding 的设计趋势：系统侧编排取代对话内堆砌
很多"需要塞进上下文让模型现场推理的东西"，
被前置固化为可复用的能力 / 工具 / 流程 ，
从而让在线上下文更短、更稳定，执行速度和输出一致性更好。
这不是"上下文工程变少了"，
而是从对话内上下文 迁移到了系统侧上下文编排 （检索、记忆、路由、工具协调），
仍然属于上下文工程的范畴。只不过，战场从 Prompt 窗口里，转移到了系统架构层。
用一句话总结这个趋势：
模型越强，越要让它专注于"决策"，而非"记忆"。
公司的 Aone Copilot 就很有潜力，是集成 Skills、Rules、McpServers 等配置的很好的平台。
它正在做的事，恰好是这套方法论的工程落地------把上下文的组织能力，沉淀进平台，而非每次都由开发者手工拼接。
小结
本篇从工程化视角出发，梳理了 AI Coding 与 LLM 应用在上下文演化这条主线上的核心问题与主流方案：
问题侧：
- 静默执行错误（上下文幻觉）
- Context Rot（上下文衰减）
- 需求传递损耗（语义损耗）
方案侧：
Simple RAG → Multi-Agent → Skills/Cowork → ClawBot
↓ ↓ ↓ ↓
全量召回 角色分工 工具路由 自主容错
（堆信息） （堆角色） （减上下文） （自愈系统）
趋势侧：
上下文工程的重心，从"对话内塞信息"转向"系统侧精准编排"。
越来越少的上下文，越来越高的执行确定性。
下一篇，我们将进入具体的工程化实践：
如何在真实项目中设计一套可落地的 Skills 体系？
从 Skill 的定义、注册、路由，到多 Skill 协同的编排设计，以及踩过的那些真实的坑。