context-engineering：上下文工程，解决 AI Coding 问题
1. 为什么需要 AI Coding
1.1 真实痛点：不是“写不出来”，是“写出来不好用”
在实际开发里，大家遇到的通常不是“AI 不会写”，而是：
- 代码能跑但不可用，改来改去反而更慢
- 业务逻辑不靠谱，只能当 demo 看
- 修 AI 产物的时间 > 自己写的时间
- 明明写了规则（国际化、命名规范等），但它总会漏、会偏
很多时候问题不在模型，而在我们有没有把“它需要看的信息”组织好。换句话说：
你掌控 Context 的能力，往往比你选哪个模型更关键。
1.2 技术演进：本质是“Context 利用能力”在升级
AI Coding 这几年看起来是产品形态在变，底层其实是对 Context 的使用越来越强：
| 阶段 | 能力表现 | 依赖的 Context 特征 |
|---|---|---|
| TAB（2021） | 代码补全 | 局部 Context（附近代码） |
| Chat（2022） | 对话式生成 | 短上下文（对话片段） |
| Agentic（2024） | 自动规划执行 | 长上下文 + 动态构建/更新 Context |
趋势也很直白：
Prompt Engineering → Context Engineering → Harness Engineering
越往后走，越像是在做“上下文的调度系统”。
1.3 当前瓶颈：长任务质量不稳定
现在 AI Coding 最大的问题往往是：
- 长任务不稳定，完成度忽高忽低
- 输出不可控，细节容易偏
- 很容易跑到另一个方向上去
更根本的原因通常是：
Context 不完整 / 不合理 / 不可控。
2. AI Coding 的本质：Context Engineering
2.1 三个核心要素：模型只是上限，Context 才是杠杆
可以把 AI Coding 拆成三件事：
| 要素 | 本质作用 |
|---|---|
| LLM | 推理引擎（决定上限） |
| Context | 决策依据（决定效果） |
| Agentic | 构建、筛选、压缩、更新 Context 的系统 |
一句话总结：
模型决定上限，Context 决定落地效果。
2.2 什么是 Context（以及它到底包含什么）
Context = 模型做决策时“能看到的全部信息”。
常见组成（按实际影响力理解）：
- System Prompt（角色设定） + 规则文件（user/project rules）
- 工具体系
- Tools（文件读写、搜索、目录遍历、问答等）
- Skills（固化的结构化能力/流程）
- MCP Servers（外部数据/能力接入）
- 项目相关信息
- 文件树、当前文件、选中代码段
- 相关引用文件、依赖关系
- 环境信息
- 语言/框架/运行时等
- 对话历史
- 以及过往工具调用结果
- 当前用户输入
这里有个常被忽略的事实：
AI 并不理解你的项目，它只是在你给的 Context 上做概率推断。
所以“给什么”“怎么给”直接决定输出走向。
2.3 Context 的几个关键特性（决定你怎么组织它）
1）容量限制：装不下就会被截断
- Context Window 有上限，超出的内容会丢
- 还要给输出预留空间
结论：不可能把一切都塞进去，只能把“相关性”做到极致。
2）注意力分布：中间最容易被忽略（Lost in the Middle）
常见表现：
- 开头关注高
- 中间关注低
- 结尾关注又高
实操建议（非常好用）：
- 开头放规则/硬约束
- 中间放参考资料
- 结尾放当前任务与验收标准
3）长输出退化：越写越不守规矩
输出很长时，常见现象：
- 规则遵循下降
- 步骤被省略
- 细节开始“想当然”
解决思路：拆任务，不要一次性生成大而全。
4）无状态：所谓“记忆”靠重建
LLM 本质无状态：
- 不记忆历史
- 每次都是新任务
所谓“记住了”，往往是 Agent 把历史重新塞回 Context。
通常对应两类：
- 会话记忆
- 持久化记忆（规则、文档、规范等）
5）成本与性能：Context 越长越慢、越贵
生成每一个新 token，都要回看之前的输入和已生成内容。
所以内容越长，计算越重、成本越高。
3. AI Coding 的工作原理（从 Context 视角）
一句话：
Agent 的核心职责不是“自动写代码”，而是让模型在有限空间里看到更相关的信息。
它实际在做的是：
- 构建 Context（把信息凑齐）
- 压缩 Context（把噪音挤出去）
- 筛选 Context（只保留相关）
- 更新 Context（根据执行结果迭代）
4. 怎么把 Context 工程做好
很多成熟工具已经帮我们做掉了不少上下文管理，但开发者仍然要做好三件事：
沉淀规则、写好提示词、学会在合适的时候新开会话。
4.1 Rules：长期记忆与最高优先级约束
Rules 的价值是：稳定注入高优先级 Context，并且可复用、可迭代。
写规则的原则（越朴素越有效）：
- 简洁：减少噪音
- 明确：避免歧义
- 可执行：别停留在口号
- 有示例：强化模式
推荐做法：分层规则结构 + 渐进式披露
把通用约束写在总入口，把细节拆成独立文件，按需引用。
示例结构（表达方式参考）：
- AGENTS.md（总入口）
- 项目配置规范
- 国际化规范（指向独立规则）
- 工具类使用规范（指向独立规则）
- 日志规范（指向独立规则）
这样做的直接收益：
- 控制 Context 体积
- 提高加载效率
- 规则更易维护
Skill vs Rules：编码规范场景优先 Rules
经验结论（来自实际尝试）：
- Skill 的调用效果对 Agent 架构和模型能力依赖更强
- 编码规范这种“硬约束”，Rules 的确定性更高
- 团队沉淀规范时，优先用 Rules 体系更稳
4.2 Prompt：即时输入，但本质仍是“补齐 Context”
好 Prompt 不是会说话，而是信息给得准。
一个对比就够了：
- 不好：
- “帮我写个登录功能”
- 更可执行：
- “实现登录功能：JWT；支持手机号与邮箱；不改现有接口；给出关键模块与验收点”
再比如：
- 不好：“这段代码有问题”
- 更可执行：“空列表触发 IndexError；需要兼容空数据；保持原有函数签名不变”
核心原则：
问题模糊 → 结果必然模糊；Context 清晰 → 输出才可控。
实际工作里也不用追求一次写完：
可以先跟 Agent 把方案、边界、验收聊清楚，再把对话收敛成一个靠谱 Prompt。
4.3 Context 管理的几个实用技巧（可直接上手）
- 新开会话：避免旧任务残留导致 Context 污染
- 精准引用：用“@文件 / @代码段”把相关内容喂准，别泛泛描述
- 关闭无用扩展：不需要的 MCP/Skill 关掉，它们的描述本身就会占 Context
- 复杂任务拆解：推荐流程是
- plan → spec → execute
本质是把问题边界压实、让 Context 结构化
- plan → spec → execute
- 方向错了马上停：跑偏时继续让它写，只会把错误放大
5. 案例：用 Context 解释“为什么这次做得好/差”
5.1 连续续费功能开发：完成度由 Context 决定
背景：原有 VIP 购买功能新增“连续续费”产品支持。
准备工作（这一步其实就是补齐 Context）：
- 从云端拿到接口变更信息
- 从 PRD 和 UI 稿拿到新样式与交互
提示词设计：用结构化文档描述需求（例如 task-pay-plan.md），把信息按“接口 / UI / 交互 / 跳转 / 文案 / 验收”组织起来。
执行效果：约 85% 完成，剩余主要是 UI 位置和弹框细节调整。
为什么整体成功：
- 结构化文档把 Context 交代完整
- 接口 + UI + 交互边界明确
- rules 足够清晰，减少“自由发挥”
为什么还会剩细节：
- UI 细节缺失时，模型会靠“常识补完”，但常识不等于你的项目规范
- 项目里某些控件用法（例如 BottomSheetDialog）如果没有规则或示例，它容易选错实现方式
结论可以写得更直白一点：
AI 完成度 ≈ Context 完整度 × 模型能力 × 工具能力
在其他条件相同的情况下，Context 完整度最决定结果。
5.2 Skill 的安全问题：敏感信息进了 Context 就有泄露风险
背景：把业务接口细节（签名算法、登录流程、字段结构等）直接写进 Skill 里。
问题：
Skill 可能被共享、上传，或被工具链注入到上下文中，等于把敏感细节暴露给了不该看到的人/系统。
更稳的方案：Skill + CLI 架构
- Skill：只描述“流程”，不放敏感细节
- CLI：本地执行真实逻辑（把敏感实现留在受控环境）
本质要点：
敏感信息不要进入 Context。
6. 总结
- 模型决定上限，Context 决定效果
- AI 输出不好时，别先怀疑模型，先检查 Context：是否缺关键约束、是否混入噪音、是否边界不清
- 工具平台会自动化一部分 Context 管理，但开发者的职责正在从“写代码”转向“定义约束与规则”
- 越早选定你的主力工具，越早形成自己的规则与工作流，收益越大