引言
随着 LLM、Agent 等技术在软件开发领域的快速发展，AI Coding 正在从“辅助工具”逐步演变为工程协作者。在实际开发中，我们经常会遇到两种极端情况：
- 用得不好：上下文越聊越乱、代码看似能跑却不可维护，返工成本反而更高
- 用得好：需求理解更准确、编码效率显著提升，且代码质量可控
本文基于个人在日常开发中的实践经验，总结了一套更工程化、更可控的 AI Coding 使用方式，重点覆盖以下几个方面：
- 上下文的管理方式
- Rule（规则）的定义与复用
- 渐进式的开发模式
- 规范驱动（Spec-driven）的变更管理
- Agent Skills
期望通过本次分享，帮助大家在享受AI带来效率提升的同时，能够保持对代码质量和需求理解的精准把控，真正实现人机协同的高效开发模式。
一、上下文管理
最重要的原则：一次任务占用的上下文越少，AI 越聪明。
上下文并不是“给得越多越好”，而是越聚焦当前任务，AI 的回答质量越高。
1.1 基本策略
● RAG：有选择地添加相关信息，以帮助LLM产生更好的响应
● 工具加载：仅选择相关的工具定义添加到您的上下文中
● 上下文隔离：在各自的专用线程中隔离上下文
● 上下文修剪：从上下文中删除不相关或不需要的信息
● 上下文总结：将积累的上下文浓缩成简明的总结
● 上下文卸载：在LLM上下文之外存储信息，通常通过存储和管理数据的工具
1.2 清晰、具体地描述问题
在描述问题时，应尽量提供具体且可定位的信息，例如：
- 功能点
- 文件名 / 类名 / 方法名
- 相关代码块
这样可以帮助模型更快定位关键上下文，避免在大量弱相关信息中“迷路”。
Bad Case：
Good Case：
核心目标不是“说很多话”，而是让 AI 少走弯路。
1.3 控制上下文长度
目前不少 AI 工具都会显示上下文占用比例。当超过一定阈值后，历史内容会被自动压缩。
需要注意的是：
- 压缩后的上下文会丢失大量细节
- 对复杂问题影响尤其明显
实践建议：
- 复杂问题尽量使用上下文窗口更大的模型 / 模式
- 避免在一个对话中混杂多个不相关任务
1.4 善用 Revert 与新开对话
节省上下文只是表象，保持上下文“干净”才是关键。
- 新问题与历史对话关联不大 → 直接新开对话
- 多轮对话中某一步走偏 → 回退到出错前的版本，重新调整 prompt
如果选择“在错误上下文上继续对话”，很容易叠加错误假设，导致后续修改越来越偏，最终整体质量失控。
1.5 提供多元化上下文信息
上下文不仅限于纯文本，还可以包括：
- 代码文件
- 图片 / 截图
- 网页链接
- Git 历史
- 当前 IDE 打开的文件
IDE 类工具在这方面支持更友好，而 CLI 场景下虽然灵活，但需要更谨慎地控制上下文。
二、Rule 定义（规则即契约）
Rule 可以理解为你与 AI 之间的“契约”，用于约束其行为边界。
| 目标 | 无 Rule | 有 Rule |
|---|---|---|
| 代码风格 | 随机选择 | 统一遵循项目规范 |
| 架构约束 | 可能放错位置 | 自动放入正确目录 |
| 技术选型 | 可能使用不合适的库 | 使用指定技术栈 |
| 最佳实践 | 实现方式不稳定 | 一致、可复用 |
Rule 的本质：可复用的上下文。
当你发现自己已经多次纠正 AI 同一类问题时，这个信息就非常适合沉淀为 Rule。
2.1 项目级 Rule
项目级 Rule 通常包括：
- 技术栈约束
- 项目目录结构
- 编码规范
- 架构边界
可通过 /Generate Cursor Rules 等命令自动生成基础规则，再根据项目实际进行补充。
2.2 用户级 Rule
示例：
- 在方案或编码过程中，如遇任何不确定性，必须第一时间向我确认决策
- 需要补充信息时，应主动询问，而不是自行假设
- 除非显式要求，不生成测试文件、文档、示例代码或日志
- 所有修改遵循最小改动原则
用户级 Rule 更偏个人偏好，但对结果稳定性影响非常大。
三、渐进式开发
实践中并不推荐：
先让 AI 输出完整方案，再一次性生成全部代码
需求越复杂，这种方式生成的代码质量越不可控。
我更推荐的方式是：把 AI 当作结对程序员，进行渐进式开发。
典型流程：
- 先让 AI 给出整体计划
- 逐步拆解任务
- 每一小块代码由人工控制生成
- 每一步都进行人工验收
- 有问题立即修正，没问题再进入下一阶段
这种方式的优势：
- 任务粒度小，更符合上下文限制
- 代码量可控，便于 Code Review
- 返工成本极低
计划本身也是一次低成本的需求校验。
四、OpenSpec：规范驱动开发
什么是SDD?
官方的定义:
OpenSpec（Spec-driven-Development）是一套用于管理代码变更提案的规范化工作流，其核心理念是：
先设计 → 再编码 → 最后归档
4.1 核心流程
4.2 基本使用
cd my-project
openspec init
4.3 目录结构说明
OpenSpec 将变更分为三个阶段：
- /openspec-proposal：提案阶段
-
- 只做设计，不写代码
- 产出 proposal.md / tasks.md / design.md / spec.md
- /openspec-apply：实施阶段
-
- 按 tasks.md 顺序逐条完成
- 持续更新任务状态
- /openspec-archive：归档阶段
-
- 部署完成后归档变更
- 保证规范可追溯
OpenSpec 特别适合：
- 中大型需求
- 多人协作
- 对变更可追溯性要求较高的项目
五、Agent Skills
5.1 什么是 Skill
pA skill is a directory containing a SKILL.md file that contains organized folders of instructions, scripts, and resources that give agents additional capabilities.
Skill 是一种轻量级的开放格式，用于为 AI Agent 提供额外能力。
本质上，一个 Skill 是一个包含 SKILL.md 的目录：
my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/
5.2 Skills 如何工作
Skills 采用 渐进式披露（Progressive Disclosure） ：
- Discovery：仅加载技能名称和描述
- Activation：匹配任务后加载完整指令
- Execution：按需执行脚本或引用资源
这种机制可以显著降低一次性上下文占用。
Skills 更适合：
- 固定重复工作流
- 希望沉淀个人经验、形成团队资产的场景
5.3 一些好用的skills
frontend-design
Skill Creator
六、一些感想
最佳实践就是开始实践！
模型技术和 Agent 生态仍处在快速演进阶段，整体发展速度非常快，今天看起来合理的实践，很可能在短时间内就会被新的方式所替代。
例如在 Agent 方向上，我认为其自主规划并持续沉淀 skills 的能力，很快就会成为常态。同时，Clawdbot 的爆火也让我们看到，AI 已经不只是工具升级，而是在真实地改变我们的生活方式和工作模式。
在这样的背景下，更现实的策略不是陷入技术细节，而是尽快用起来，把通用能力交给模型，把精力更多聚焦在业务价值本身。
