夜雨聆风
AI 编程协作手册10 个实战技巧,让 AI 成为你的高效开发搭档
这本手册最有价值的地方，不是告诉你 Claude Code 有哪些功能，而是告诉你怎么把 AI 真正放进开发流程里。
它不是讲”让 AI 多写一点代码”，而是讲人负责方向、边界和质量，AI 负责调研、拆解、实现、补测试和重复劳动。
整套方法可以压成一句话：
先把需求讲清楚，先让 AI 给方案，一个功能一个功能做，做完就测，重要信息写进项目文档，别让 AI 只靠聊天硬记。
一、这本手册真正讲的是什么
一句话结论： 这不是工具功能说明书，而是一套把 AI 用进开发流程的方法论。
如果只从表面看，Claude Code 好像就是”更强一点的代码助手”。但它真正想表达的是：开发方式已经变了。
以前是人自己一步一步查资料、读代码、写实现、跑命令、看报错、改代码。现在是人先想清楚方向，再把很多执行动作交给 AI 去做。
关键认知转变：
-
从”它会不会写代码” → “你会不会带着它一起做开发” -
从”功能菜单” → “AI 协作开发入门” -
从”想知道它哪里比别的 AI 强” → “我该怎么跟 AI 分工”
最值钱的是什么？ 不是教你点哪里，而是教你怎么带着 AI 一起做事。
二、Claude Code 到底是怎么工作的
一句话结论： Claude Code 不是只会回答问题，而是会边读文件、边调用工具、边修改、边验证的 AI 工程助理。
普通聊天型 AI 更像老师——你问它问题，它回答你，然后真正动手的是你。
Claude Code 更像一个会用工具的实习工程师。你告诉它任务，它会先想下一步该做什么，然后去读文件、搜代码、列目录、改代码、跑命令，再根据结果继续往下走。
所以它强，是因为它不是只会说；
它也会跑偏，是因为它只知道当前上下文里有什么。
核心原则
- 模型负责思考，工具负责动手
- 它不是自动知道整个项目，只知道它读过的内容
- 你给它的上下文越清楚，它越稳定
使用建议
不要默认它”懂项目”。如果某个限制、规则、依赖关系、已有约定对任务很重要，就应该主动告诉它，或者先让它去读相关文件。
示例提示词：
先不要实现。请先阅读认证模块、用户模型和项目规则文档。
三、为什么 AI 特别适合处理胶水代码
一句话结论： AI 最适合接管那些重复、琐碎、但又必须做的连接性工作，也就是开发里大量的胶水代码。
胶水代码不是系统最”聪明”的部分，但它负责把系统连起来。
典型的胶水代码场景
-
读配置和环境变量 -
做参数校验 -
调第三方接口 -
处理异常和日志 -
把数据库结果转成接口返回格式 -
把一个模块的输出转成另一个模块能接的输入 -
编排一整条流程
这些代码不一定难，但真的很费时间，而且经常重复。
实践建议
如果一个任务本质上是”把已有模块接起来”，或者”给已有模块补齐连接层”，那通常很适合先让 AI 来做：
-
给现有接口补参数校验 -
给服务层补日志和错误处理 -
给数据库访问结果加响应模型转换 -
给一批函数补测试或文档
记住： 胶水代码不一定最难，但最磨人，所以也最值得先交给 AI。
四、为什么先计划比先写代码更重要
一句话结论： 复杂任务先计划再实现，能在写代码之前先纠正方向、范围和风险，返工成本最低。
很多时候，真正浪费时间的不是”写代码”，而是”写了一堆以后才发现方向不对”。
计划模式的价值
先让 AI 把”准备怎么做”讲出来，你先看它理解的目标、会影响哪些模块、数据怎么流、有没有明显越界、哪里需要拍板。方向对了，再让它动手。
计划应该回答的问题
-
它理解的目标是什么 -
涉及哪些模块 -
数据或调用链怎么走 -
风险点在哪里 -
什么算完成
计划模式模板
先不要写代码，请进入计划模式。目标：我要做 X。背景：这个功能给谁用，解决什么问题。本次范围：只做 A、B。本次不做：C、D。约束：继续使用现有技术栈，只允许修改 M、N，不要动 P。请先输出：1. 你对需求的理解2. 模块级实现方案3. 涉及的模块和文件范围4. 数据流或调用流程5. 风险点6. 需要我确认的地方7. 验收标准如果信息不够，请先提问，不要自行假设。
五、提示词到底该写到什么程度
一句话结论： 提示词不用细到实现代码，但一定要把目标、范围、约束和验收标准说清楚。
两个极端要避免
|
|
|
|---|---|
| 太空 |
|
| 太死 |
|
更合适的方式
你提供目标和边界，AI 提供方案和实现细节。
最短可用模板
先不要写代码。本次目标：X。本次范围：只处理 A、B。本次不包括：Y、Z，不要顺手重构。只允许修改：M、N。保持现有技术栈和项目结构。如果信息不足，先问我，不要自行扩展。请先输出方案和待确认项。跑偏纠偏模板
你刚才跑偏了，请先停止实现。问题在于：你现在做的是 A，但我要的是 B。本次范围只包括 X，不包括 Y 和 Z。请重新输出模块级方案，不要直接写代码。如果有不确定的地方，先问我，不要自行假设。
六、如果需求不清，怎么让 AI 先帮你问清楚
一句话结论： 需求不清时不要急着让 AI 实现，先让它反过来追问你，把问题和边界补齐。
很多开发者不是不会写代码，而是不知道自己到底要做什么。脑子里只有一个模糊想法，直接让 AI 开做，通常只会把模糊放大成返工。
需求澄清模板
先不要给方案，也不要写代码。请先像产品经理和技术负责人一样，问我 8 到 10 个关键问题，帮助我明确：1. 用户是谁2. 痛点是什么3. 核心场景是什么4. 输入和输出是什么5. 本次先做什么6. 本次不做什么7. 什么算成功等我回答完，再给我模块级方案。核心认知： 需求很多时候不是”想出来”的，而是”问出来”的。
七、一个功能应该怎么开发和推进
一句话结论： 最稳的开发节奏不是一次做完整系统，而是一个功能一个闭环地推进。
AI 最大的诱惑，就是它看起来能一下做很多事。但做很多不等于做得稳。
单功能开发闭环
定义功能 → AI 出方案 → 方案确认 → 实现 → 验证 → 下一个功能单功能开发模板
这次只做一个小功能，不要扩展到整个系统。目标：X。本次不做：Y、Z。请先给模块级方案。我确认后再实现。实现完成后，请输出：1. 改动摘要2. 受影响模块3. 主流程验证步骤4. 边界情况检查点5. 建议补充的自动化测试
八、测试、验证和人工监督怎么配合
一句话结论： 测试不是完全交给 AI，也不是全靠手工，而是AI 多写多跑、人来盯关键业务和风险。
分工建议
AI 适合做：
-
写单元测试 -
补常见失败场景 -
跑测试 -
整理验证清单 -
找明显回归
人必须盯：
-
核心业务规则有没有测到 -
边界情况有没有漏 -
权限、安全、数据一致性有没有覆盖 -
AI 的测试是不是只是”证明它自己写得对”
测试验证模板
实现完成后，请不要继续扩展。请输出：1. 改动摘要2. 本次新增或更新的自动化测试3. 主流程手工验证步骤4. 失败场景和边界场景检查点5. 仍未覆盖的风险如果测试不足，请先补测试，再汇报结果。
九、项目结构和项目记忆怎么让 AI 不失忆
一句话结论： 项目结构越清楚，AI 越稳定；会话越长，越要靠项目记忆文档接住上下文。
最小项目记忆四件套
|
|
|
|---|---|
| CLAUDE.md |
|
| PRD.md |
|
| README.md |
|
| progress.md |
|
Python 项目最小分层建议
api/ # 接口层schemas/ # 输入输出模型services/ # 业务逻辑repositories/ # 数据库访问integrations/ # 第三方调用core/ # 配置、日志、鉴权、错误处理tests/ # 测试新会话恢复上下文模板
先不要写代码。请先阅读 CLAUDE.md、PRD.md、README.md、progress.md。然后输出：1. 你对项目目标的理解2. 当前状态3. 本次任务约束4. 冲突和不确定点5. 你建议的下一步在我确认之前，不要开始实现。
十、并行工作流和自主循环什么时候该用
一句话结论： 边界清楚的任务适合并行，规则明确的任务适合自动循环，而需要持续判断的任务不该直接放手。
并行工作流
适合： 范围清楚、互不重叠的任务
并行模板：
你负责这次任务中的 A 子任务。你的工作范围只限于 X 目录或模块。不要修改 Y、Z 以及任何无关文件。先阅读相关文件并输出计划，不要直接实现。如果需要超出范围，请先说明理由并等待确认。不要顺手重构，不要扩展需求。完成后请输出：1. 改动摘要2. 影响范围3. 风险点4. 验证建议自主循环
适合自动跑的任务：
-
批量补文档 -
批量补测试 -
按固定规则重构 -
统一补日志和参数校验
不适合自动跑的任务：
-
新功能设计 -
架构调整 -
权限、支付、核心数据库逻辑 -
你自己都没想清楚的任务
最后总结
如果把整本手册再压成一句话：
Claude Code 最强的地方，不是替你思考，而是替你执行。你负责方向、边界、判断和质量，它负责调研、拆解、实现、补测试和重复劳动。
真正好用的顺序
- 先澄清需求
- 再进入计划模式
- 一个功能一个功能做
- 每做完一个小步就验证
- 重要信息写进项目记忆
- 边界清楚时再做并行和自动化
最土但最好用的一句话
先把话说清楚，再让 AI 干活，每干一步就验一步，重要东西写下来，别让它靠聊天硬记。
附录：提示词模板
本文配套的 9 个可直接复用的提示词模板，已单独整理：
包含：计划模式、需求澄清、事前约束、跑偏纠偏、打断模板、单功能开发、测试验证、恢复上下文、项目记忆速查。