第二篇：AI结对编程实战指南｜工具篇进阶：从"问问题"到"下指令"
真正的高手，从不问AI"能不能"，而是告诉它"怎么做"
在上一篇文章中，我们提出了AI时代开发者技能树的四阶段模型（工具→思想→架构→技术地图）。今天，我们深入第一阶——工具篇，但这不是教你怎么"问问题"，而是教你怎么下指令。
在过去的几个月里，我与AI结对完成了多个项目，从零到一的产品，到复杂的系统重构。我发现一个惊人的事实：多数开发者还在把AI当搜索引擎用，而高手已经把它当成执行团队了。
编程任务的三个阶段拆解
任何项目的开发过程，都可以被分解为三个递进的阶段：原型→MVP→迭代。每个阶段，你给AI的指令方式都完全不同。
第一阶段：原型开发｜让AI当你的产品副驾
任务目标： 从模糊想法到具体设计
很多人在这里就出错了。他们直接让AI"写一个电商网站"，得到的只能是泛泛而谈。
正确的提问范式是：
# 产品需求描述
我需要一个智能相册应用，核心功能是：
1. 自动整理手机里的所有照片（支持10万+数量级）
2. 基于大模型进行智能分类（人物、场景、事件）
3. 支持快速检索和智能相册创建
# 产品设计要求
- 目标用户：摄影爱好者和普通用户
- 核心价值：解决照片太多找不到的问题
- 主要场景：浏览回忆、查找特定照片
# 请帮我：
1. 完善产品设计，输出PRD文档（先确认你的理解）
2. 以产品经理视角讨论功能取舍和交互细节
3. 基于业务目标提炼技术要求
关键对话点：
- 确认理解： "根据你的理解，这个产品的核心用户痛点是什么？"
- 技术提炼： "这个需求会引入后端服务吗？哪些功能必须在后端实现？"
- 技术选型： "基于这些要求，请输出技术设计文档和初步技术栈建议"
我的实战经验：
当我说"芯图相册需要支持整理10万+照片"时，AI立刻意识到这需要：
- 本地存储优化策略
- 增量扫描机制
- 分类任务的异步处理
- 可能的后端服务用于模型推理
这个阶段，AI往往能轻松完成任务。你不需要懂技术细节，但必须懂业务逻辑。几轮对话后，一个可操作的产品原型就清晰可见。
第二阶段：MVP实现｜让AI当你的架构搭档
任务目标： 从设计到可用系统
这里是大多数项目失败的地方。很多开发者在这里当"甩手掌柜"，结果AI"按了东瓢起西瓢"，留下一堆需要巨大测试工作量的代码。
问题出在哪里？
AI是细节思维、局部思维。它看到一棵树，但看不到整片森林。
正确的协作方式是：
# 当前架构问题
我们现在需要重构数据层，现有问题：
1. 跨平台适配代码重复
2. 缓存更新机制混乱
3. 界面渲染与数据更新不同步
# 我的架构想法
我设想：
1. 提取统一的DataService层
2. 采用响应式数据流
3. 统一缓存策略（LRU + 按需更新）
# 请帮我：
1. 评估这个设计，给出完善建议
2. 分析可行性风险和潜在运行风险
3. 几轮沟通后，输出具体的TODOLIST
关键洞察：
AI有时甚至会"暗示"你："你似乎需要考虑更系统的架构设计。"
这不是AI的"智能"，而是它在大量代码库中学到的模式识别。听懂这个暗示，是你从"使用者"变为"审查者"的第一步。
我的工作流：
- 提出架构想法 → AI给出反馈
- 几轮讨论后 → AI输出TODOLIST
- 将最终的设计约束固化到Cursor的默认提示词中
为什么需要固化设计约束？ 因为AI不会记得你项目里的所有代码。它每次推理时：
- 调用IDE的MCP工具快速读取"相关"代码
- 这个"相关性"是根据文字表面意思判定的
- 会有疏漏，一定会
所以你必须通过提示词，反复强调："我们的架构原则是XXX"、"我们采用了XXX模式"。
第三阶段：功能迭代｜让AI当你的资深工程师
任务目标： 在稳定架构上增量开发
到了这个阶段，技术选型和架构主体已经确定，种子用户开始试用，新的需求不断涌现。
最危险的陷阱： 每次新功能都重新发明轮子。
正确的指令范式：
# 功能需求
用户希望增加"照片故事"功能：自动将相关照片组合成时间线故事
# 实现思路
1. 复用现有的照片聚类算法
2. 增加时间线数据模型
3. 在现有相册页面增加入口
# 注意事项
1. 最小化代码改动，避免重复逻辑
2. 复用已有缓存机制
3. 保持与现有UI组件一致
4. 特别注意性能影响（照片数量可能很大）
核心原则： 你不是在问"如何实现"，而是在说"我要这样实现，你帮我完善细节"。
提问范式的根本转变
通过这三个阶段，你会发现一个模式变化：
- 代码规模小时： 提需求/提BUG的比例大
- 代码规模大时： 提思路/提要求的比例大
这背后的本质是：AI编程提问不是问问题，而是：
- 提需求： 我要什么功能
- 提思路： 我打算怎么做
- 提要求： 必须满足什么约束
- 提BUG： 现在有什么问题
争议与反思：我们是否限制了AI？
读到这里，你可能会有个疑问：这种高度主导的协作方式，会不会反而限制了AI的创造力？
毕竟现在很多人觉得AI"无所不能"，我们应该放手让它自由发挥。
我的思考是：
-
对于确定性问题（算法实现、代码重构、BUG修复），明确的主导能极大提升效率。AI就像一位极其勤奋但需要明确指引的工程师。
-
对于探索性问题（创新功能、未知领域、技术选型），我们需要给AI更多"发挥空间"。这时可以问："有哪些我们还没想到的实现方式？"
关键在于区分问题的类型。在工具篇，我们讨论的主要是确定性问题。而在后续的"思想篇"和"架构篇"，我们会更多探讨如何利用AI进行创造性思考。
你的实战经验是什么？
现在，我想听听你的实践：
- 你在哪个阶段与AI协作最顺畅？哪个阶段最头疼？
- 有没有遇到过AI"按了东瓢起西瓢"的情况？你是如何解决的？
- 你认为高度主导的协作方式，会限制AI的潜力吗？
留言区分享你的经验，点赞最高的三位读者，我会送出我整理的《AI结对编程实战提示词库》（包含50+经过验证的工程化提示词模板）。
下期预告： 思想篇——当AI给出一个看似完美的并发方案时，你如何一眼看出其中的性能陷阱？我们将深入高并发场景，看看技术原理如何让你从"代码审查者"升级为"架构预见者"。
