03 · 有效实践：怎样用得好
总原则
把 AI 当成高带宽、低可靠的初级同事：给足上下文，收紧权限，强制验收，保留否决权。
好用法几乎都在优化三件事：输入质量、过程可控、输出可证。
1. 先写清意图，再让它动手
坏提示：
帮我优化一下这个服务
好提示包含：
- 目标：用户可见结果是什么
- 非目标：这次明确不做的事
- 约束：性能、兼容、风格、依赖边界
- 验收：怎样算做完（测试、截图、指标）
- 上下文入口：关键文件、错误日志、相关 PR/设计
模板可以很短：
目标：...
非目标：...
约束：...
请先：读这些文件/跑这个复现
完成标准：...
不确定时先问，不要猜业务规则
意图工程 > 提示词花活。
2. 上下文是第一生产力
模型不知道：
- 你们团队上周刚踩过的坑
- 那个「暂时先这样」的历史妥协
- 生产上真正的流量形态
- 哪个模块是神圣不可乱改的
你要主动喂：
| 类型 | 做法 |
|---|---|
| 代码库结构 | 维护 CLAUDE.md / AGENTS.md / 架构说明 |
| 规范 | lint、测试约定、命名、错误处理标准 |
| 运行证据 | 失败日志、trace、复现脚本、截图 |
| 决策记录 | ADR、为何不选某方案 |
| 反例 | 「上次 AI 这样改翻车了，禁止再犯」 |
没有仓库级记忆时，AI 每次都在「新入职第一天」。
3. 小步闭环，而不是一次生成宇宙
更稳的循环：
- 最小可验证切片
- 生成/修改
- 跑测试 / 类型检查 / 本地验证
- 看 diff，修约束
- 再扩大范围
反模式：
- 「把整个模块重写」一句话扔出去
- 没有测试就连续让它「继续完善」
- 多个无关目标塞进同一会话
会话会腐坏。 目标漂移、上下文污染、错误假设累积时，开新会话往往比硬聊更便宜。
4. 测试与类型是你的外骨骼
在 AI Coding 里，测试不只是质量保障，更是：
- 给模型的 可执行规格
- 给自己的 快速否决器
- 给评审的 行为证据
优先顺序建议：
- 能表达业务不变量的测试
- 类型系统与静态检查
- 关键路径的端到端验证
- 最后才是「肉眼觉得 diff 好看」
没有自动门禁的仓库，用 AI 等于开着油门却没有刹车。
5. 审查要改焦点
人审 AI diff 时，优先看：
- 行为是否匹配意图（而不是变量命名是否完美）
- 错误路径与边界条件
- 安全与权限
- 数据一致性与并发
- 是否引入隐藏耦合/重复抽象
- 是否删除了重要注释、检查、回滚路径
- 依赖与配置变更的爆炸半径
可以跳过（或交给 lint）：
- 纯格式
- 显而易见的样板
- 已被测试锁死的细节
但不要跳过：「它为什么这样实现」。问一句实现理由，常能逼出幻觉。
6. 权限与爆炸半径
Agent 越强，权限设计越重要：
- 默认只读探索，写操作分域
- 推远程、改密钥、碰生产数据必须人工门
- 破坏性命令（硬重置、批量删）默认拒绝
- 用 worktree / 分支隔离实验
- 记录它跑过什么命令（可审计）
「为了流畅全部 allow」会在某一天用一次事故还清利息。
7. 让 AI 做它擅长的，人做它不擅长的
| 更适合 AI | 更适合人 |
|---|---|
| 样板、迁移、重复重构 | 产品取舍与优先级 |
| 从错误日志定位候选原因 | 判断业务正确性 |
| 补测试、写脚本、生成文档草稿 | 定义「什么叫好」 |
| 探索多种 API 设计草稿 | 选定长期架构方向 |
| 跨文件机械修改 | 组织协调与责任归属 |
| 解释陌生代码 | 识别政治/历史包袱 |
最佳状态不是「AI 全包」或「人全包」，而是 高频乒乓：人给方向，AI 给草案，人收束，AI 落地，人验收。
8. 建立团队级「AI 工程规范」
个人技巧到了团队会失效，除非写成共享资产：
- 仓库说明文件（给人和给模型）
- 标准任务提示模板
- 禁止事项清单（安全、合规、数据）
- 何时必须人工设计评审
- PR 模板：说明哪些部分由 AI 生成、如何验证
- 事故后更新「模型易错点」
把提示词私藏在个人笔记里，是最低级的组织浪费。
9. 衡量并迭代用法，而不只是换模型
换更强模型有用，但边际收益常小于：
- 更好的复现步骤
- 更干净的模块边界
- 更高的测试可信度
- 更短的反馈环
- 更明确的完成定义
先修工作流，再追模型版本。
10. 个人日常节奏（可直接抄）
- 用 5 分钟写清目标/非目标/验收
- 让 AI 先读相关代码并复述理解（纠错成本最低的一步）
- 要求它提出计划，而不是直接大改
- 批准计划后小步实现
- 每步跑验证
- 你自己走一遍关键路径（不只看测试绿）
- 写清 PR 描述与风险
- 把可复用约束回写进仓库文档
下一篇：风险与边界