Appearance
AI 编程助手效率使用指南
AI 编程助手不是"替身"，而是"杠杆"。同样的问题，不同的提问方式，产出效率可以差 10 倍。本文从 prompt 策略、场景分类、上下文管理、工程化配置四个维度，提炼一套可复用的使用范式。
配套资料：具体工具的安装、配置、快捷键见 AI 编程工具域（Claude Code / CodeGraph / Agent vs Skill 深度解析）。
更新时间：2026-08-07
本文要回答的问题
- 写出高效 prompt 的核心原则是什么？
- 不同开发场景（新功能、重构、调试、文档）分别该用什么策略？
- 如何管理上下文，避免 AI "忘记"需求？
- 常见的低效用法有哪些？如何避免？
- 工程化配置（rules、CODEBUDDY.md、skills）如何放大 AI 的能力边界？
一、核心原则：把 AI 当"高级实习生"
AI 不会读心术。你脑子里没说的上下文，它永远猜不到。
1.1 三要素法则
每条 prompt 都应该包含三个要素：
| 要素 | 含义 | 好例子 | 坏例子 |
|---|---|---|---|
| What | 要做什么 | "给 calc_cpu_usage() 加缓存，避免每 200ms 读一次 /proc" | "优化一下 CPU 计算" |
| Where | 在哪做 | 指明文件路径或粘贴代码片段 | "在我的项目里" |
| Constraint | 约束条件 | "保持现有接口不变，缓存 TTL 建议 5 秒" | 不说约束 |
1.2 上下文即一切
AI 的工具箱里有文件读取、代码搜索、目录浏览——但它需要你告诉它去看哪。最省事的做法不是"你把整个项目读一遍"，而是：
"帮我看一下 demos/tlb-thrashing/main.cpp 里的 thrash_tlb() 函数，
然后给 attack_page_count 参数加一个命令行选项支持。参考 demos/cpu-demo/main.cpp 里 argparse 的用法。"这条 prompt 给了三个精确锚点：
- 目标文件：
demos/tlb-thrashing/main.cpp - 目标函数：
thrash_tlb() - 参考实现：
demos/cpu-demo/main.cpp的 argparse 模式
1.3 描述"期望产出形态"
❌ "帮我生成 TLB 抖动实验文档"
→ AI 不知道你想写多长、什么结构、给谁看
✅ "参考 demos/tlb-thrashing/README.md 的实验文档模板，
写一份新的实验文档，回答'TLB miss 对吞吐量的衰减曲线是什么样的'。
包含：实验设计、代码设计、预期、数据、分析、结论六段。
数据暂用占位符，我来填实际数字。"
→ AI 知道模板在哪、结构是什么、输出到什么程度二、场景分类与策略
2.1 场景-策略速查表
| 场景 | 推荐策略 | 关键动作 |
|---|---|---|
| 新功能开发 | 先给设计稿，再分步实现 | 先让 AI 画出调用链，确认无误再写代码 |
| Bug 修复 | 给出复现步骤 + 错误日志 | 贴 stack trace、说清楚"预期行为 vs 实际行为" |
| 代码重构 | 小步快跑，每步验证 | 一次只改一件事，改完编译运行再下一步 |
| 代码审查 | 指定审查维度 | "检查线程安全性" 比 "帮我 review 一下" 有效 |
| 文档撰写 | 给模板 + 写多少字 | 给一篇已有文档做参考，指定段落结构 |
| 学习/探索 | 让 AI 先画图，再看代码 | PlantUML → 调用链 → 源码走读 |
| 环境配置 | 写清 OS + 工具版本 | "Ubuntu 22.04, perf 6.2, 需要火焰图" |
| 多文件联动 | 列出所有涉及文件 | 不要让 AI 猜还有哪些文件要改 |
2.2 新功能开发：先设计，后实现
反例：一次让 AI 改 8 个文件新增一个功能 → 大概率某个文件会出错 → 修复过程反复修改 → 效率比一步步来更低。
2.3 调试场景：给足线索
✅ 高效 Prompt：
"demos/echo 运行到 day-20 时，客户端报了 'Connection reset by peer'。
我怀疑是 accept queue 溢出。帮我检查：
1. server.cpp 里 listen() 的 backlog 参数
2. 和 day-09 里的 somaxconn 设置对比
3. 给一个诊断脚本检查当前系统的 somaxconn 值"
❌ 低效 Prompt：
"echo 程序连接被重置，帮我修一下"2.4 文档场景：给模板 + 给字数 + 给读者
✅ "以 concepts/cache/cache-organization.md 为模板，
写一份 cache-coherence-basics.md，
面向刚学完计算机组成的本科生，
控制在 1500 字以内，
必须覆盖：MSI 状态机、false sharing、MESI 的优化点"三、上下文管理策略
3.1 什么时候重新开一个对话
| 信号 | 建议 |
|---|---|
| AI 开始重复之前的错误 | 开新对话，把核心约束重新贴进去 |
| 上下文超过 50 轮 | 开新对话，把"总结"作为新 prompt 前缀 |
| 换了完全不同的功能模块 | 开新对话，避免旧上下文干扰 |
| 对话里改过 10+ 个文件 | 开新对话，让 AI 重新读取当前状态 |
3.2 长任务的分段策略
每段对话结束时，让 AI 输出一个"状态总结"，作为下一段对话的 prompt 前缀：
"上一段我们完成了：
1. 在 demos/tlb-thrashing/ 下新建了 experiment-v2.cpp
2. 实现了可配置的 stride 和 page_count 参数
3. 编译通过，make 成功
接下来要做：添加 perf stat 测量脚本和实验文档"3.3 CODEBUDDY.md / rules 的作用
CODEBUDDY.md 是给 AI 的"项目入职文档"。你写在里面的内容会在每次对话时自动注入上下文。应该包含：
| 必须写 | 建议写 | 不要写 |
|---|---|---|
| 技术栈版本（语言、编译器、关键依赖） | 目录结构说明 | 过于细节的 API 文档（AI 自己会查） |
| 构建命令 | 数据流/调用链概述 | 大段代码（浪费 token） |
| 代码风格约束 | 常见陷阱提醒 | 歧义描述 |
| 禁止事项（如不要改某个文件） | 设计决策的背景 | 显而易见的信息 |
本项目的 CODEBUDDY.md 就是一个好例子：目录结构、构建命令、知识金字塔、语言约束、文档规范、PlantUML 排版要求——这些信息每次对话都在用。
四、常见低效模式与改进
4.1 反模式对照表
| 低效做法 | 问题 | 改进 |
|---|---|---|
| "帮我写一个函数" | 没说输入输出 | "写一个 calc_cpu_usage()，输入采样前后的 jiffy 快照，返回 0-100 的百分比" |
| 一次让 AI 改 10 个文件 | 错误连锁扩散 | 分 3 次：核心逻辑 → 调用方 → 测试/文档 |
| 不说"参考已有代码" | AI 自己造 API 风格 | "参考 demos/cpu-demo/main.cpp 里的 argparse 模式" |
| 改完不看 diff 直接接受 | 可能引入非预期改动 | 每条修改先看 diff 摘要，再确认 |
| 不敢让 AI "试错" | 反复确认浪费回合 | 让 AI 先改 → 编译报错 → 贴错误让它修，比自己排查更快 |
| 对话太长不重置 | 上下文污染 | 50 轮左右开新对话 |
| 不维护 CODEBUDDY.md | AI 每次都在摸索项目结构 | 花 10 分钟写好，后续省无数轮对话 |
4.2 "试错驱动" vs "确认驱动"
确认驱动（慢）：
你: 可以在 xxx 文件加一个函数吗？
AI: 可以，要我写吗？
你: 写吧
AI: [写代码]
→ 3 轮对话才出代码
试错驱动（快）：
你: 在 demos/xxx/main.cpp 加一个 print_affinity() 函数，用 sched_getaffinity，
参数是 pid，返回 void，风格参照现有的 calc_cpu_usage()
AI: [直接写代码，你 review diff]
→ 1 轮对话出代码原则：对 AI 来说，写 50 行代码的成本约等于写 5 行。所以不需要"先论证再写"——直接让它写出来，你审阅 diff 判断质量。
五、工程化配置：放大 AI 的能力边界
5.1 三层配置架构
| 层次 | 是什么 | 什么时候生效 | 例子 |
|---|---|---|---|
CODEBUDDY.md | 项目入职文档 | 每次对话自动加载 | 构建命令、代码风格、目录结构 |
| rules | 行为约束/自动化 | 按匹配条件触发 | "文档必须用中文"、"每次更新加时间戳" |
| skills | 领域知识包 | 用户显式调用 | PDF 处理、Excel 分析、PlantUML 模板 |
5.2 怎么写好 CODEBUDDY.md
写好 CODEBUDDY.md 是回报率最高的投入——花 20 分钟写，后面每次对话都省钱。
markdown
# CODEBUDDY.md
## Commands（构建/测试/部署命令）
- 列出所有常用命令，一行一个
- 标注每个命令干什么、在哪个目录执行
## Architecture（架构概览）
- 目录树 + 每个目录一句话职责
- 调用链 / 数据流概述（一图胜千言）
## Key constraints（关键约束）
- 语言约束（中文文档、英文代码）
- 平台约束（Linux only / macOS 也能跑）
- 不要改的文件（配置文件、自动生成的代码）
## Editing conventions（编辑约定）
- 文档格式规范（PlantUML + 表格 + 一句话总结）
- 提交规范
- Review 流程5.3 自动化任务
适合交给 AI 自动执行的周期性任务：
| 任务 | 频率 | 示例 prompt |
|---|---|---|
| 检查死链 | 每周 | "遍历所有 .md 文件，检查内部链接是否有效" |
| 更新 OVERVIEW.md | 有新增文档时 | "把新加的 concepts/elf/static-init-order.md 加到 OVERVIEW.md 的知识金字塔里" |
| 格式一致性检查 | 每次提交前 | "检查最近变更的 .md 是否符合 PlantUML + 表格 + 一句话总结规范" |
| 站点地图更新 | 每周 | "重新生成 sitemap.xml，包含最近一周新增的文档" |
六、效率度量：怎么判断自己用得好不好
| 指标 | 入门 | 熟练 | 高效 |
|---|---|---|---|
| 单次任务平均回合数 | 6-8 轮 | 3-4 轮 | 1-2 轮 |
| 是否需要解释项目背景 | 每次都解释 | 偶尔提醒 | 不需要（CODEBUDDY.md 自动给） |
| 代码产出一轮通过率 | 30% | 60% | 85%+ |
| 遇到复杂任务时的处理 | 一条 prompt 扔进去碰运气 | 拆 2-3 步 | 先设计再实现，每步验证 |
| 对话管理 | 一个对话用一整天 | 按模块切换对话 | 模块切换 + 定期重置 + 状态总结接力 |
一句话总结：AI 编程助手的高效用法不是"学会下指令"，而是"学会给上下文"——What（做什么）、Where（在哪里做）、Constraint（什么约束），三条到位，效率翻 10 倍；再配合 CODEBUDDY.md 固化项目知识，让每次对话都站在上一次的肩膀上。