夜雨聆风很多人第一次用 AI 写代码，体验都不错。但用久了会发现：写个小脚本很顺手，一到正经项目就开始频繁返工、代码风格不一致、越往后越难用。
这不是 AI 的问题，是你还没掌握用好 AI 编程的方法。
本文系统性地介绍 AI Coding 的核心概念、工具配置和实战流程，重点讲解 Spec Coding、Rules、Skills 这些工程化手段——它们是让 AI 从「玩具」升级为「生产力工具」的关键。
一、先搞清楚：AI 能替你做什么
AI 编程不是万能的。搞清楚它擅长什么、不擅长什么，才能真正用好它。
AI 擅长替代的工作：
机械重复的编码动作——写 CRUD、写单元测试框架、生成配置文件、翻译代码语言、批量重构。这些不需要理解业务意图，AI 干得又快又好。
AI 不擅长替代的工作：
理解需求背后的业务意图、做架构决策和技术选型、组织上下文、识别边界条件、对生成结果的质量判断与把控。这些依然需要人来完成。
一个核心认知：AI 替代的是动作，不是思考。
AI Coding 不是让你少思考，而是让你思考更值钱的部分。你把精力从「逐字逐句写代码」转移到「想清楚要做什么、边界在哪里、怎么验证结果」，效率才能真正提升。
二、几个绕不开的核心概念
在深入工具配置之前，先理解几个基础概念。它们会贯穿后面所有的实战流程。
大模型与 Agent 工程
大模型是底层的「大脑」，Agent 工程则是给大脑装上「手脚」——让 AI 能够调用工具、执行操作、保持状态。没有 Agent 工程，AI 只能回复文字，无法真正操作代码。
当你在 IDE 里看到 AI 自动读取文件、搜索代码、修改项目时，这背后都是 Agent 工程在起作用。不同的 AI 编程工具，本质上就是不同的 Agent 工程实现——它们在上下文管理、工具调用能力、任务拆解策略上各不相同。
Vibe Coding vs Spec Coding
这是两种截然不同的编程方式。
Vibe Coding 凭感觉走，随时开始随时改，适合个人原型和一次性脚本。它的代价是质量不稳定，代码难以维护，AI 在长对话中容易丢失上下文。很多初学者沉迷于 Vibe Coding 的快感，但一到需要维护的项目就傻眼了——AI 生成的东西自己都看不懂，更别说改。
Spec Coding 是规格先行的开发方式。在动手之前先整理好需求边界、状态定义、技术约束，然后用 AI 按照规格生成代码。输出质量可预期，返工率低，适合生产环境。
两种方式不是非此即彼。原型阶段可以用 Vibe Coding 快速验证，一旦验证通过要上线，必须切换到 Spec Coding 重新整理。这里有个关键判断：当你发现自己在同一个项目里对话超过 20 轮，代码开始出现风格不一致、前后矛盾的问题，就是该切换到 Spec Coding 的信号。
Harness Engineering
这个词可能听起来陌生，但它的核心逻辑很简单：怎么让 AI 生成更可控、更稳定？
答案是给 AI 提供充分的上下文约束。Harness（约束）思维的本质是给 AI 一个已有的实现作为参照，让它照着复刻，而不是凭空创造。约束越精准，生成代码的可用性越高。
打个比方：你要让 AI 帮你写一个 HTTP 客户端，如果没有约束，它可能写出一个完全不认识的风格；但如果你给一个现有的实现作为 Reference，AI 会自觉对齐这个风格。这就是 Harness 的力量。
Rules 和 Skills 就是 Harness Engineering 的两个核心组件。
三、主流工具横评：CURSOR / Claude Code / GitHub Copilot
选择合适的工具，能让 AI Coding 效率提升一个档次。目前主流的三款工具各有特点：
GitHub Copilot：入门首选，集成度最高
Copilot 是最早大规模商用的 AI 编程工具，以.inline suggestion（行内补全） 为核心形态。它的优势在于：
- • 深度集成 VS Code 和 JetBrains 全家桶，零学习成本
- • 补全速度快，适合边写边用
- • 适合简单重复性任务（补全函数、写注释、生成单元测试）
短板： Agent 能力弱，长任务处理能力有限，缺乏系统性上下文管理。Copilot 更像是一个高级的代码补全插件，而不是一个能帮你做事情的 AI 助手。
适用场景： 简单函数补全、代码片段生成、快速写测试用例。
Cursor：全能型选手，团队友好
Cursor 是近年来增长最快的 AI IDE，基于 VS Code 二次开发，定位是AI Native 的开发环境。
Cursor 最大的特点是它的 Agent 模式（Composer 和 Agent 模式）。你可以让它直接读取文件、修改代码、执行命令。更重要的是，Cursor 提供了Rules 功能（项目级上下文约束），团队可以在项目根目录放置 .cursor/rules/ 目录，定义编码规范、安全约束、架构要求，AI 会自动遵守。
Cursor 还支持多文件编辑、上下文引用、数据库 Schema 直连等功能。对于需要 AI 真正帮你完成任务而不是简单补全的场景，Cursor 是目前最成熟的选择。
适用场景： 中型项目开发、团队协作、需要 AI 完成多步骤任务。
Claude Code：最聪明的头脑，适合深度任务
Claude Code 是 Anthropic 官方推出的 CLI 工具，特点是能力最强但上手门槛最高。它没有图形界面，只支持命令行，但 Agent 能力极为强大。
Claude Code 的优势在于：
- • 上下文窗口大（20万 token），能处理超长对话
- • 擅长理解复杂需求，做深度任务拆解
- • 代码质量高，幻觉率相对较低
短板： 没有 IDE 集成，需要手动管理上下文，学习成本高。适合愿意投入时间建立工作流的个人开发者。
适用场景： 复杂重构、架构设计、跨文件批量修改、需要深度理解的复杂任务。
选择建议
新手从 Cursor 开始，企业团队用 Cursor 或 Copilot，深度开发者可以试试 Claude Code。不过工具不是固定的，很多人最终会组合使用：用 Copilot 做快速补全，用 Cursor 做复杂任务，用 Claude Code 做深度重构。
四、工具配置：Comate + 语音输入法
实操的第一步是把工具配好。这里以百度 Comate 为例，其他工具逻辑类似。
安装与基础配置
在 IDE 中安装 Comate 插件，登录账号后即可启用 AI 辅助。核心配置项不多：
- • 上下文窗口：决定 AI 能"记住"多少对话内容。越长越能处理复杂项目，但也越容易出现遗忘和幻觉。
- • 语言模型：选主力模型，追求稳定选旗舰模型，追求速度选轻量模型。
上下文窗口的选择有个实用技巧：如果你的项目代码量在 1 万行以内，选 32K 窗口足够；如果超过 1 万行，考虑上 128K 或更大的窗口。但要注意，窗口越大，AI 越容易"分心"——它会参考太多内容，容易出现风格漂移。
语音输入法：提升输入效率
很多人忽略了这一点：AI 编程的效率瓶颈往往不在 AI 本身，而在人怎么把需求说清楚。
语音输入法可以大幅提升描述需求的效率。你对着电脑说"我要一个分页组件，每页20条，支持跳转到指定页"，AI 立刻开始生成。相比打字，语音输入的速度可以快 3-5 倍。
建议开启 IDE 内的语音输入插件，把「说清楚」这件事也纳入效率优化的一部分。但要注意：语音输入适合描述需求和逻辑，不适合输入代码——代码还是要精确敲，不然 AI 会理解错。
五、Rules 和 Skills：让上下文持久化
这是本文最核心的内容。Rules 和 Skills 是让 AI 在长周期项目中保持稳定表现的关键。
Rules：持久约束
Rules 是什么：
Rules 是团队编码规范的 AI 版本。一旦配置好，任何时候、任何对话中 AI 都会自动遵守，不需要你在每次 Prompt 里重复。
打个比方：如果说 AI 编程是一场球赛，Rules 就是比赛规则——你不需要在每次进攻前提醒裁判什么叫越位，规则天然存在。
典型应用场景：
- • 项目编码风格（命名规范、注释要求）
- • 安全约束（禁止直接拼接 SQL、禁止硬编码密钥）
- • Git 规范（提交信息格式、分支命名）
- • 任何团队需要统一执行的标准
配置方法（以 Comate 为例）：
在项目根目录创建 .comate/rules/ 目录，放入 *.rules.md 文件。AI 在生成代码时会自动读取并遵守。
示例 api.rules.md：
# API 开发规范
## 命名规范
- RESTful 风格：`GET/POST/PUT/DELETE` 对应 `list/create/update/delete`
- 命名用小写字母 + 下划线，如 `get_user_info`
## 响应格式
所有接口统一返回：
{
"code": 0, // 0=成功，非0=错误
"message": "", // 错误描述
"data": {} // 返回数据
}
## 安全约束
- 禁止字符串拼接 SQL，必须用参数化查询
- 禁止在代码里硬编码密钥，必须从环境变量读取
- 用户敏感信息（手机号、身份证）必须脱敏返回再举一个更具体的 Rules 示例——前端组件规范：
# 前端组件规范
## 组件文件结构
每个组件必须包含：
1. 组件主体（.tsx）
2. 样式文件（.module.css）
3. 类型定义（types.ts，在同目录）
## Props 规范
- 所有 Props 必须有 TypeScript 类型定义
- 非必需字段后面加 `?`
- 组件必须有 defaultProps 或可选链处理
## 状态管理
- 组件内部状态用 useState
- 跨组件共享状态用 Context 或 Zustand
- 禁止直接修改 propsSkills：可复用任务模板
Skills 是什么：
Skills 是可复用的任务模板。当你要做某个具体任务时，调用对应 Skill，AI 会自动加载完整的执行步骤和上下文，而不是每次都从零描述。
Skills 和 Rules 的区别：
- • Rules 是「宪法」——任何时候都生效，约束所有人的所有行为
- • Skills 是「操作手册」——只在特定任务被触发时注入上下文
常见 Skills 场景：
- • 代码评审流程
- • 新功能开发流程
- • Bug 修复流程
- • 测试用例生成
- • 接口文档生成
配置方法：
在项目根目录创建 .comate/skills/ 目录，放入 *.skills.md 文件。
示例 code-review.skills.md：
# 代码评审 Skill
## 触发条件
当你听到「帮我 review 这段代码」「评审一下」「review」时执行。
## 执行步骤
### 第一步：逻辑审查
- 检查代码逻辑是否正确
- 验证边界条件是否处理完整
- 检查循环和递归是否有正确出口
### 第二步：性能审查
- 检查是否有重复计算（N+1 查询风险）
- 检查是否有用完未释放的资源
- 评估时间和空间复杂度是否合理
### 第三步：安全审查
- 检查是否有注入风险（SQL injection、XSS）
- 检查是否有越权风险（未校验用户权限）
- 检查敏感信息是否明文存储或传输
### 第四步：可维护性审查
- 命名是否清晰（变量、函数、文件）
- 注释是否说明「为什么」而不是「是什么」
- 函数长度是否适中（超过80行建议拆分）
### 输出格式
评审结论分为三类：
- 🔴 严重问题（必须修复）
- 🟡 建议优化（建议修复）
- 🟢 良好实践（可以保持）
每个问题列出：文件位置、问题描述、修复建议再举一个 Bug 修复的 Skill 示例：
# Bug 修复 Skill
## 触发条件
当你听到「修个 bug」「排查问题」「出错了」时执行。
## 执行步骤
### 第一步：复现问题
- 确认复现步骤（操作顺序、输入数据）
- 记录错误信息和堆栈
- 如果无法复现，询问最近一次正常运行的上下文
### 第二步：定位根因
- 根据错误信息定位到具体文件和行号
- 分析为什么出错（从错误堆栈往上找）
- 检查相关配置和环境变量
### 第三步：修复
- 只改问题根源，不做过度修复
- 修复后验证是否能通过
- 检查是否有副作用
### 第四步：复验
- 用相同的复现步骤验证问题已修复
- 检查相关功能是否受影响
- 更新或补充测试用例
## 注意事项
- 不要在没复现的情况下猜测原因
- 修复后必须验证，不能只靠「看起来对」
- 如果需要改多个文件，列出所有变更及原因Rules 和 Skills 的组合使用
真正高效的团队，会把 Rules 和 Skills 组合使用：
Rules 定义项目的「底线」——任何人、任何时候、任何任务都必须遵守。比如安全规范、编码风格、Git 规范。
Skills 定义特定任务的「最佳实践」——只有在执行对应任务时才生效。比如代码评审 Skill，只在评审时被触发。
这种分层设计的好处是：Rules 保证下限（不会犯低级错误），Skills 提升效率（每次任务都有最佳实践模板）。
六、实战流程：从需求到代码的标准步骤
概念理解了，工具配好了，现在进入真正有效的开发流程。
第一步：先出方案，不要直接写代码
接到需求后，第一件事不是让 AI 写代码，而是让它出技术方案。
反例：
"帮我写一个用户注册接口"
这种模糊的需求，AI 只能给你一个通用模板，边界条件一概不管，后续返工是必然的。
正例：
"我要做一个用户注册接口，有以下边界条件需要你考虑：
- 1. 邮箱格式校验（正则表达式验证）
- 2. 密码强度要求（8位以上，包含大小写和数字）
- 3. 重复邮箱检测（已注册返回友好错误）
- 4. 验证码有效期30分钟
- 5. 注册成功后发欢迎邮件
- 6. 防机器人的滑动验证
请先输出技术方案，包括接口设计、数据库表结构、异常流程处理。确认后我们再开始写代码。"
先出方案的好处是：在写代码之前就把问题暴露出来，而不是等到代码写完才发现方向错了。这个步骤节省的时间是巨大的——方向错了，代码写得越多，返工越多。
第二步：确认边界，形成 Spec
方案确认后，把边界条件整理成清晰的 Spec 文档。Spec 是你和 AI 之间的契约，后续生成和 Review 都围绕它展开。
一个实用的 Spec 模板：
# [功能名称] 技术规格
## 功能概述
一句话描述这个功能做什么。
## 接口定义
### 请求
- 方法：
- 路径：
- 参数及类型：
- 必填/可选：
### 响应
- 成功响应（code=0）的数据结构
- 错误响应（code!=0）的错误码和提示
## 边界条件
1. [具体场景1]
2. [具体场景2]
## 异常流程
- 网络超时如何处理
- 服务不可用如何处理
- 数据校验失败如何返回
## 依赖
- 依赖的外部服务
- 依赖的数据表
## 验收标准
- 功能正常运行
- 性能满足要求（如响应时间<200ms）
- 安全满足要求（如防止SQL注入）第三步：分步生成，不要一口气全写完
AI 生成代码时，不要让它一次性生成整个模块。
正确做法是分步生成、逐步确认：
模块1（注册逻辑）→ Review → 确认 → 模块2（验证码逻辑）→ Review → 确认 → 模块3（邮件发送）→ Review → 确认每完成一个模块就检查，避免问题累积。经验证明，分步生成能让整体返工率降低 50% 以上。
这里有个实用技巧：给 AI 的任务要足够小。一个合适的粒度是：AI 完成一个任务的时间在 3-5 分钟，输出代码量在 50-100 行。这样每次生成的结果都容易 Review，不容易出大问题。
第四步：Rules 托底，减少重复提醒
Rules 配置好之后，在生成代码的过程中不需要在 Prompt 里重复提醒。AI 会自动遵守后台的规则，你只需要专注于业务逻辑本身。
比如当你要求 AI "帮我写一个用户查询接口"，它会自动加上异常处理、自动遵守响应格式规范、自动避免 SQL 注入——这些不需要你说，Rules 已经托底了。
七、常见陷阱与解决方案
AI Coding 看似简单，但有几个高频踩坑点，提前知道能少走很多弯路。
陷阱一：AI 幻觉
大模型有时候会生成看似正确但实际有问题的代码——这就是幻觉。比如它可能引用一个不存在的 API，或者生成一段逻辑上有漏洞的代码。
为什么会有幻觉？
大模型的本质是「预测下一个词」，它生成的内容不一定是真实存在的。幻觉在代码场景下尤其危险，因为它看起来语法正确、逻辑通顺，但一跑就崩。
应对策略：
- 1. 养成 Review 习惯：AI 生成的代码必须人工 Review，不能直接信任。 这个习惯是最重要的，比任何技巧都重要。
- 2. 用 Rules 约束安全边界： 明确禁止某些危险操作。比如在你的 Rules 里写
禁止使用未定义的 API，AI 就不敢凭空创造。 - 3. 交叉验证： 对关键代码，用另一个 AI 或搜索引擎做交叉验证。如果两个 AI 给出的方案一致，出问题的概率会低很多。
- 4. 验证依赖： AI 生成的代码如果引用了第三方库或 API，要手动验证这些依赖是否真实存在、版本是否正确。
一个实测经验： AI 幻觉的高发场景是「你没有给出足够约束」的时候。你给 AI 的上下文越清晰、约束越具体，幻觉率就越低。
陷阱二：长对话上下文丢失
对话一长，AI 容易遗忘早期的重要信息，越往后越难用。这是大模型的固有限制——上下文窗口是有限的，超出窗口的内容会被"遗忘"。
什么时候该重启对话？
经验法则：当 AI 开始出现以下症状时，果断重启对话：
- • 不记得之前讨论过的边界条件
- • 生成的代码和之前风格明显不一致
- • 开始重复之前已经拒绝过的方案
- • 回答开始变得"泛泛而谈"，缺乏针对性
如何正确重启对话？
很多人重启对话时会简单地说"继续上一次的任务"，然后重新描述需求。这浪费了之前的所有上下文。
正确做法是：在重启前，让 AI 先总结当前进展和问题所在，然后将总结复制到新对话作为起点。
请总结当前进展：
1. 我们已经完成的部分
2. 当前遇到的核心问题
3. 接下来需要做的事情
（AI 输出总结后，复制到新对话开头）这种「交接文档」式的重启，比从零描述效率高得多。
陷阱三：过度依赖 AI
这是最隐蔽的陷阱。很多人用 AI Coding 时间长了，会产生一种「AI 写的代码我不用看」的错觉。
问题在哪里？
- • 你对代码的理解越来越浅
- • 当代码出问题，你不知道怎么修
- • 长期下来，你的编程能力会退化
正确姿势：
AI 是辅助工具，不是替代工具。AI 生成的每一行代码，你都应该理解它在做什么。如果不理解，就问 AI，直到弄懂为止。
一个简单的原则：你能向别人解释这段代码的逻辑，才算真正掌握了它。
八、进阶使用技巧
掌握了基础之后，这几个进阶技巧能帮你进一步提升效率。
技巧一：用好 Reference 让输出更可控
当你需要 AI 生成某个功能的代码时，如果能提供一个现有的实现作为 Reference，AI 的输出质量会显著提升。
比如你要 AI 帮你写一个新的 API，先把项目中已有的类似 API 代码发给它，让它「照着这个风格写」。AI 会自觉对齐这个风格，而不是自由发挥。
# 这是项目中已有的用户查询接口，请照着这个风格写新的订单查询接口
[粘贴现有代码]
要求：
1. 同样的命名风格
2. 同样的错误处理方式
3. 同样的响应格式技巧二：用好上下文注入顺序
AI 对上下文中不同位置的内容权重不同。一般来说，越靠后的内容权重越高。
这意味着：
- • 最重要的约束，应该放在 Prompt 的最后
- • 示例代码应该放在约束之后
- • 通用的规则说明可以放在最前面
一个实用的结构：
[背景说明 - 放在最前，不重要]
[通用规范 - 中间，可以用 Rules 替代]
[具体任务描述 - 靠后，重要]
[示例代码 - 靠后，重要]
[关键约束 - 最后，最重要]技巧三：建立你的提示词模板库
把高频使用的任务做成模板，下次直接调用。
比如「代码评审」「Bug 修复」「新功能开发」「写单元测试」这些高频任务，都应该有自己的提示词模板。
模板不需要完美，可以逐步优化。每次做某个任务时，如果 AI 的回复不够好，就调整提示词，记录下来。积累一段时间后，你会发现某些类型的任务几乎不需要改模板，AI 每次都能给出满意的结果。
技巧四：定期清理对话上下文
如果你的 AI 编程工具支持上下文管理，定期清理不再需要的对话历史。
长对话会让 AI"分心"——它会参考太多不相关的内容，输出质量下降。
一个实用的做法是：每个功能模块用独立的对话。写用户注册用一个对话，写订单查询用另一个对话。模块之间没有重叠，AI 的上下文永远是最相关的。
九、最重要的认知：质量在 Prompt 里
很多人有一个误区：AI 写得不好，是因为追问得不够多。
实际上，质量在 Prompt 里，不在频繁的追问对话里。
前置多花 10 分钟整理上下文，比后续反复迭代修改省时得多。投入时间整理 Spec、整理边界、配置好 Rules，这个时间回报率是整个开发流程里最高的。
当你开始系统性地整理上下文，而不是依赖追问来弥补，你就会从「会用 AI 写代码」升级到「会工程化驾驭 AI 写高质量代码」。
AI 是工具，上下文是核心，工程化是方法。把这两件事做好，AI Coding 的效率才能真正翻倍。
