人机协作：AI 编程高效落地指南（一）

人机协同：AI编程高效落地指南

大模型的普及，让AI编程成为开发者日常开发的常用工具。和传统纯手动敲码、调试迭代的模式不同，AI编程的核心，是通过人机协作的方式，简化重复编码工作、提升开发效率，让工程落地更轻松。

但在实际使用中，很多人对AI编程的运用仅停留在基础层面：只会套用简单提示词、让AI批量生成代码，一味堆砌功能，却缺少规范的迭代逻辑、项目管控思维和工程化落地能力。这也导致很多AI生成的代码杂乱冗余、难以维护，项目容易失控，最终无法正常上线，没能真正发挥出AI的提效价值。

本文结合真实开发场景，整理了一套可落地的AI Coding方法论。从AI编程的底层认知、标准化开发流程、实用提示词技巧，到全场景实战方法与配套工具生态，循序渐进讲解人机协同开发的实操要点。帮助不同基础的从业者，摆脱碎片化的工具用法，建立规范、可控的AI开发习惯，解决AI编码乱、迭代难、落地难的问题，真正借助AI简化开发流程、高效完成工程项目落地。

第一章 原理篇：AI Coding底层认知

1.1 时代变革：告别传统编程开发模式

近年来，大模型技术飞速发展，其中应用最广泛的当属大语言模型（LLM）。除自然语言生成外，其最成功的落地实践是基于字符的代码生成，即AI Coding。它是一种全新的人机协作软件开发范式，利用AI编程大模型的能力，通过自然语言（提示词）与编程工具内置的智能体交互，辅助或自动化完成需求分析、架构设计、代码生成、解释与调试。AI coding的本质，不是“用AI辅助编程”，而是人不在亲自编码。

这一开发范式变革使开发者从亲手写代码转向"指挥官"角色，带来三大提升：

  • 生产力跃升：单人指挥多Agent协作，模拟产品、设计、研发、测试、运维等角色，产出效率大幅提升
  • 门槛降低：只需清晰表达能力，无需深究语言细节，即可完成应用开发
  • 周期缩短：从想法到落地，传统一个月的开发量可压缩至一周甚至更短

2025年，是AI编程公认的元年。年初，随着各类编程工具全面普及，AI从"代码补全工具"升级为可执行任务的智能体；到年底，AI发展到多Agent协作，具备自主规划、执行、验证、迭代能力。特别是2025年下半年，各类大模型普遍支持百万级上下文，这意味着AI能够对完整项目代码进行理解与分析，保持长文档上下文，以及多轮对话深度记忆。与此同时，各类编程智能体也逐步具备了Plan规划、Skill技能、Rules规则、MCP等能力，使得个体也具备了产品打造能力。

AI编程智能体能够放大个体能力，这意味着软件开发能力的平权化，过去"有一个完美Idea，只差一个程序员"的情况可能一去不返。Idea从构思到落地，个体在各类设计、编程、云服务的AI加持下，可以完整构建从0到1的产品。这不是工具升级，而是分工重构。一人等效一个完整研发团队，是AI Coding最简洁的定义。但需要强调的是，AI只是高倍率放大个体能力，并不意味着完全没有开发经验的个体能玩转AI编程。具备AI编程开发的前提，是拥有软件的基本架构能力——了解软件如何运转。达到这个基础水平即可，也不会出现"我的网站做好了，网址是 http://localhost ，大家来帮我测试吧"这样的笑话。

1.2 AI编程的工作原理：从提示词到可运行代码

要真正用好 AI Coding，不能只把AI理解成“聊天机器人会写代码”。它背后有一套完整的工作机制：人用自然语言表达意图，AI 将意图转化为软件工程任务，再通过代码生成、工具调用、运行反馈和迭代修复，逐步逼近可运行系统。工作机制的连贯执行使得AI具备极速反馈、即时迭代、低试错成本的核心优势，这种低阻力、高反馈的开发体验，能够让开发者持续保持专注、沉浸式的创作状态，快速进入心理学中的「心流模式」。开发者无需被繁琐的语法、报错、环境配置干扰，全程聚焦产品思路、业务逻辑和创意落地，在轻松流畅的开发氛围中持续产出，因此被命名为Vibe Coding（氛围编程/直觉编程）。

一般而言，AI Coding的工作链路可以拆成五步：自然语言描述（提示词-> AI语义理解与任务拆解->代码库上下文读取与推理-> 工具调用与代码生成->运行反馈与迭代修复。这五步共同构成了 AI Coding 的底层原理。

第一步：自然语言需求输入

传统编程中，人需要把需求翻译成代码，而在AI 编程中，人首先把需求表达成自然语言。

例如：

我想做一个记账本应用，用户可以记录收入和支出，并查看本月统计图表。

这句话本身不是代码，但它包含了软件开发所需的关键信息：

  • 产品类型：记账本应用；
  • 用户动作：记录收入、记录支出；
  • 数据对象：收入、支出、金额、时间、分类；
  • 展示结果：本月统计图表；
  • 隐含页面：录入页、列表页、统计页；
  • 隐含逻辑：新增记录、保存数据、汇总金额、图表展示。

AI 的第一项能力，就是把自然语言里的模糊意图转化为可执行的开发任务。

第二步：语义理解与任务拆解

AI 并不是简单地“接一句话，吐一段代码”。它会根据提示词中的信息，推断出需求背后的软件结构。

例如，当你说：

做一个用户登录功能。

AI 会自动联想到：

  • 需要登录页面；
  • 需要账号和密码输入框；
  • 需要表单校验；
  • 需要登录按钮；
  • 需要调用后端接口；
  • 需要处理登录成功和失败；
  • 需要保存登录状态；
  • 可能需要 Token；
  • 可能需要跳转到首页。

这就是大模型的语义理解能力。它不是只识别字面意思，而是根据大量代码、文档和软件项目经验，推断一个功能在工程上通常应该如何实现。但这也带来一个问题：AI 会主动补全，也会主动猜测。

如果你没有明确边界，它可能会替你做很多“自认为合理”的事情，例如：

  • 自动新增依赖；
  • 自动修改项目结构；
  • 自动重构多个文件；
  • 自动设计数据库；
  • 自动添加你没要求的功能。

所以，AI 编程的关键不是让 AI 自由发挥，而是让人类通过提示词设定任务边界。

第三步：上下文读取与工程推理

AI Coding 与普通 DeepSeek 问答最大的区别在于：它不只是回答问题，而是可以读取项目上下文。在 Cursor、CodeX、Claude Code等 AI 编程工具中，AI 可以看到：

  • 当前打开的文件；
  • 项目目录结构；
  • 相关代码片段；
  • 依赖配置；
  • 报错日志；
  • Git diff；
  • 终端输出；
  • 测试结果；
  • 用户选择的代码范围。

这使它具备了“工程推理”的能力。

例如你让 AI 修改一个按钮逻辑，它不只是生成一个新按钮，而是会尝试判断：

  • 这个按钮在哪个组件里；
  • 当前项目使用 React、Vue 还是原生 JS；
  • 状态变量在哪里定义；
  • 点击事件绑定在哪；
  • 样式来自 CSS、Tailwind 还是组件库；
  • 修改后是否影响其他页面。

这就是为什么 AI 编程工具比单纯把问题丢给聊天对话助手（如豆包、Deepseek网页版）更适合开发，因为真正的软件开发不是孤立代码片段，而是大量文件之间的上下文协同。

第四步：代码生成与工具调用

当 AI 理解需求和上下文后，就会进入代码生成阶段。

它可能生成：

  • HTML / CSS 页面；
  • React / Vue 组件；
  • 后端接口；
  • 数据库模型；
  • SQL 迁移脚本；
  • 测试用例；
  • Dockerfile；
  • 配置文件；
  • 文档说明；
  • 修复后的代码片段。

在更高级的 AI 编程智能体中，它还可以调用工具完成动作，例如：

  • 创建文件；
  • 修改文件；
  • 运行命令；
  • 安装依赖；
  • 执行测试；
  • 读取终端报错；
  • 搜索项目代码；
  • 调用外部 MCP 工具；
  • 根据结果继续修复。

这意味着 AI 已经从“代码建议者”进化为“任务执行者”。过去的代码补全工具，只能在你写到一半时补几行。现在的 AI 编程智能体，可以根据一句需求，跨多个文件完成一个功能模块。

例如：

请新增一个订单列表页面，支持按状态筛选和按创建时间排序。

AI 可能会自动完成：

  • 新建 OrderList.vue；
  • 添加路由；
  • 编写筛选组件；
  • 编写排序逻辑；
  • 调用订单接口；
  • 补充 mock 数据；
  • 调整菜单；
  • 生成基本样式。

但也正因为它能做得更多，所以更需要人类控制范围。否则它可能“一次改太多”，导致项目不可控。

第五步：运行反馈与迭代修复

AI 生成代码并不等于开发完成，真正有效的 AI Coding，一定包含运行反馈。

因为 AI 生成代码可能出现：

  • 语法错误；
  • 依赖缺失；
  • 路径错误；
  • 类型不匹配；
  • 接口字段不一致；
  • 样式错乱；
  • 逻辑遗漏；
  • 环境变量配置错误；
  • 浏览器兼容问题；
  • 后端跨域问题。

所以 AI 编程不是“一句话生成成品”，而是一个循环过程：提出需求->AI生成代码->运行项目->发现问题->报错信息给AI->AI修复代码->再次运行->审查验收

例如：

我运行 npm run dev 后报错如下：
Module not found: Can't resolve './components/Header'
请帮我分析原因，并给出最小修改方案。不要重构项目。

AI 会根据报错判断可能原因：

  • 文件路径写错；
  • 文件名大小写不一致；
  • 组件没有导出；
  • import 路径层级错误；
  • 文件不存在。

然后给出修复方案。

因此，AI Coding 的本质不是“AI 一次性写对所有代码”，而是：人来持续提供反馈，AI 持续修正实现。

1.3 AI编程Agent的能力来源

AI 之所以能编程，主要来自四类能力：

1. 代码语料学习能力

大模型训练时学习了大量公开代码、技术文档、开源项目、问答资料和工程实践。因此它知道常见功能通常应该怎么写。

例如：

  • 登录注册；
  • 文件上传；
  • 表格筛选；
  • 支付流程；
  • 数据库 CRUD；
  • API 接口；
  • 权限校验；
  • Docker 部署；
  • 自动化测试。

它不是像人一样理解代码世界，但它能根据大量模式，生成高度接近真实工程的代码。

2. 自然语言到代码的映射能力

AI 能把自然语言需求映射成代码结构。

例如：

用户点击按钮后，弹出确认框，确认后删除当前数据。

AI 可以转化为：

  • 绑定点击事件；
  • 显示确认弹窗；
  • 获取当前数据 ID；
  • 调用删除接口；
  • 删除成功后刷新列表；
  • 删除失败时显示错误提示。

这就是从“意图”到“实现”的映射。

3. 上下文补全能力

AI 不只根据当前一句话生成代码，还会结合上下文判断。例如你项目里已经使用 Element Plus，它就应该优先使用 Element Plus 的组件；如果项目里已经使用 Tailwind CSS，它就不应该突然写一套全新的 CSS 体系；如果现有接口统一返回 { code, data, message }，它也应该保持同样格式。上下文越完整，AI 输出越稳定。这也是为什么百万级上下文、多文件读取、项目级索引会显著提升 AI 编程质量。

4. 工具调用与自动执行能力

新一代 AI 编程智能体不只是生成文本，还可以调用工具执行任务。

例如：

  • 搜索代码；
  • 编辑文件；
  • 运行测试；
  • 读取日志；
  • 调用浏览器；
  • 访问数据库；
  • 使用 MCP 连接外部工具；
  • 根据运行结果继续迭代。

这使 AI 从“会回答”变成“会做事”。未来 AI Coding 的关键演进方向，也正是从代码生成走向自主执行。

这里需要特别强调：AI 编程不是魔法。大模型生成代码的底层机制，本质上仍然是基于上下文进行概率预测。它会根据你的提示词、项目上下文和已有代码模式，预测“接下来最合理的代码是什么”。这带来两个结论：

第一，AI 可能犯错。它可能生成看似合理、实际不能运行的代码。

第二，AI 需要验证。代码是否正确，不取决于 AI 说得多自信，而取决于能不能运行、能不能通过测试、能不能满足需求。

所以，使用 AI 编程时必须建立一个基本认知：

AI 负责生成候选方案，人负责判断和验收。

这也是为什么 Git、测试、日志、运行反馈非常重要。它们是 AI 编程从“看起来对”走向“真的可用”的保障。

1.4 三种典型的AI开发范式

从“人来指挥AI完成开发”这一核心特征来说，依托AI Coding的范式可归纳为三类，它们是所以AI Coding实践的原点：

  1. 视觉原型范式。主要特点是通过调研分析，通过AI构建快速产品UI原型界面，快速验证想法，并于用户（或自己）打成共识。界面是用户直观感知纬度，也是最容易通过描述+参考的方式来让AI理解，因此从界面入手，先确定长什么样，再实践怎么实现，是最快切入AI编程的路径。
  2. 逻辑主导范式。其侧重于后端服务、数据处理、算法实现，核心是逻辑规则的清晰表达。人不需要写代码，但需要能够通过自然语言来描述清楚：输入是什么、输出是什么、数据怎么流转、经过哪些判断和处理。逻辑表达提示词越精确，AI实现还原度越高。
  3. 借鉴创新范式。人类的学习靠模仿，AI生成也可参照。提供一个界面截图、一个开源项目链接或一段代码，AI可以据此逆向还原、二次开发。通过将已有成果的作为沟通介质，大幅降低描述成本。

在AI Coding实践中，往往不是一种范式来主导，通常是三种范式灵活运用。

1.5 人的角色转变及人机职责分工

当 AI 能写代码之后，人并没有消失，而是职责上移。

传统开发中，人主要做：理解需求 → 写代码 → 调试 → 上线

AI Coding 中，人主要做：定义目标 → 拆分任务 → 设定边界 → 审查结果 → 验证上线

也就是说，人从“编码者”转向“指挥者”。

新的核心能力包括：

  • 需求表达能力；
  • 任务拆解能力；
  • 软件结构理解能力；
  • 审美判断能力；
  • 逻辑校验能力；
  • 风险识别能力；
  • 测试验证能力；
  • 迭代管理能力。

这也是为什么 AI Coding 并不等于“完全不需要技术常识”。你可以不亲自写每一行代码，但至少要知道软件由哪些部分组成，知道前端、后端、数据库、接口、部署之间大致如何协同，即基本架构能力。

那么在这种角色转变的情况下，人的核心价值发生转移，人机协同的职责可以拆解出分工边界：

纬度 人负责 AI 负责
审美与体验 确定风格、交互感受、品牌调性 生成符合描述的界面代码
需求与取舍 拆解功能、判断优先级、做减法 理解需求并输出实现方案
逻辑定义 用自然语言描述业务规则 转化为准确可运行的代码逻辑
风险审核 识别安全漏洞、数据合规、边界异常 执行测试、暴露问题、给出建议
编码调试 不写代码 完整编写、调试、重构
部署运维 触发指令、确认配置 执行部署命令、日志分析

核心分工价值在于，人把控“做什么、做成什么样、为什么不能做”，而AI负责“怎么做，写出来，跑起来”。

第二章 流程篇：标准化落地开发法则

2.1 通用五步标准开发流程

一个软件产品的落地，通常经历需求调研分析、产品原型设计、高保真设计、架构/详细设计、代码构建、测试上线等阶段。AI Coding的整体思路与传统软件研发过程一致：

首先构思创意，汇集用户或自己的想法，抓住需求痛点、构建用户故事，明确产品核心目标与待解决的问题。在目标精准定位下，规划产品栏目、界面设计与用户交互原型，进行可视化交互验证，验证出的问题或产生的新想法，通过AI进行迭代更新，一步步的达到预期。随后通过人机交互方式进行代码生成、审查、测试，最后上线部署。从「一个想法」到「一个可用的产品」，演绎出最小落地单元的五步法：想法->原型->迭代->编码->调试->上线。

第一步：想法
用自然语言写下你要做什么。不需要技术术语，只需要回答三个问题：

  • 这个产品给谁用？
  • 解决什么问题？
  • 最核心的一个或几个操作是什么？

举个例子：

我想做一个面向软件公司项目负责人使用的简单项目管理工具。它帮助项目经理、程序员、设计师等角色人员在一个界面上查看和管理所有任务进度、与客户沟通、项目预算与成本管控，并内置客服聊天工具，核心操作包括创建项目、项目任务管理、任务进度维护和查看客户需求与反馈。

第二步：原型

基于刚才的自然语言描述，让 AI 生成一个静态界面（HTML/CSS 即可），无需后台逻辑。此时的重点是对界面外观进行验证。如果觉得不满意，可以随时修改描述，让 AI 重新生成，直到你看到的界面效果与预期一致。此时可利用测试数据来模拟业务逻辑，确保功能正常运行。这里的目标是视觉确认，比如：

  • 确认界面风格：颜色、排版、按钮样式等是否符合预期？
  • 页面布局：功能入口是否清晰且易于理解？

第三步：迭代

在原型基础上逐轮提出修改，直到界面完全符合预期。每一轮只改一个地方，确认后再改下一个。切忌一次性提七八条需求——AI会乱，你也会乱。

  • 例如第一轮告诉 AI 调整顶部导航栏的颜色；
  • 等初步效果确认后，再告诉 AI 调整按钮大小或布局。
  • 一轮一改、一轮一验，直到对外观100%满意为止。

第四步：编码

当原型界面确认后，就可以开始真写代码，由AI来为页面加入交互逻辑和后端服务。你需要做的是：描述清楚「点击这个按钮后发生什么」「数据从哪里来、存到哪里去」。

  • 描述点击某个按钮后希望执行什么操作，比如将表单中的数据保存到数据库；
  • 说明数据源来自哪里，需要存到何处；
  • 让 AI 生成前端与后端的实现代码，如 React、Vue 前端和 Node.js、Python 等后台代码。

你的描述越精准，AI 就能更好地完成所需功能。此步也是消耗时间和精力最大的步骤，需要逐步交互、迭代。

第五步：调试上线

如果运行出错，直接将错误提示复制给 AI，请它尝试定位问题并提供修复方案。修复后，让 AI 生成部署命令或脚本。

  • 也可请 AI 协助完成自动化测试与集成，让上线流程更加顺畅；
  • 部署渠道可选择自有服务器、云服务或其他一键托管平台。

在完成所有测试和调试后，即可将项目正式上线。通过如上五个阶段，你就能较为轻松地从一个想法出发，快速构建并交付 AI 驱动的产品。

2.2 迭代铁律：三大风控心法

项目失控最常见的原因，并不是 AI 能力不足，而是需求改着改着就「改乱了」。尤其是在多轮迭代中，如果每次都让 AI 大范围修改，很容易出现：原本正常的功能被破坏、样式被覆盖、逻辑前后不一致、旧问题修好了新问题又出现。因此，和 AI 协作开发时，最重要的不是一次性让它写得多完整，而是要学会控制修改范围。基于「防失控」原则，可以总结出三条迭代铁律。

铁律一：找到-选中-单点修改

每次修改前，先定位问题所在。不要一上来就说：「这个页面有问题，帮我改一下。」更稳妥的做法是，让 AI 先帮你找到相关代码位置，确认它理解的是同一个问题后，再进行修改。

推荐流程是：

  1. 先让 AI 找到需要修改的文件、函数或组件；
  2. 将涉及到的文件、函数或者代码给到 AI ，并说明准备改哪里、为什么改；
  3. 修改完成后，立即运行或预览确认效果。

一次只改一个功能点。如果改了 A 影响到 B，也不要急着让 AI 一次性修完所有问题。先确保 A 正确，再把 B 作为一个单独问题处理。

正确提示词示例：

请先帮我定位「登录按钮点击后无反应」相关代码，不要修改。
找到后说明涉及哪些文件和函数，我确认后再让你改。

确认后再说：

只修改登录按钮点击事件这一处逻辑，其他代码保持不变。

铁律二：禁止全局重构

和 AI 协作时，最危险的指令之一就是：

重新写一遍。
整体优化一下。
帮我重构这个页面。
把代码整理得更优雅。

这些说法看似合理，实际风险很高。因为 AI 很可能会推倒重来，重新生成一套它认为更好的代码，但在这个过程中，之前已经调试好的细节、兼容逻辑、样式调整和临时修复，都可能被覆盖或丢失。尤其是在项目已经能跑起来之后，更要避免大范围重构。正确的做法是把需求缩小到明确范围，例如：

不要说：

帮我整体优化登录页面。

可以改成：

只修改 LoginPage 组件中的表单校验逻辑，其他 UI、接口请求和路由逻辑保持不变。

不要说：

这段代码太乱了，帮我重写。

可以改成：

只将 submitForm 函数拆成两个小函数：validateForm 和 sendLoginRequest。不要修改函数行为，不要改动其他代码。

也就是说，永远告诉 AI：改哪里、改什么、不许动哪里。

铁律三：Git 阶段性存档

每完成一个可运行状态，就要及时提交存版，就像我们在玩游戏打Boss前的存档。很多人使用 AI 写代码时，会一口气连续改几十轮，等到项目跑不起来时，已经不知道是哪一步改坏的。这时再让 AI 修，往往会陷入「越修越乱」的循环。所以，只要项目达到了一个阶段性可用状态，就应该立刻提交一次 Git。

比如：

  • 完成首页布局后，提交一次；
  • 完成登录页后，提交一次；
  • 接通接口后，提交一次；
  • 修复某个关键 bug 后，提交一次；
  • 上线前，提交一次。

你不需要记 Git 命令，直接对 AI 说：

帮我提交代码，备注：完成登录页 UI。

或者：

当前项目可以正常运行，请帮我提交一次 Git，提交信息是：完成用户登录功能。

阶段性提交的好处是：一旦后面改坏了，可以随时回退到上一个可运行版本。这样你会更有安全感，也更敢让 AI 继续迭代。总结一下，和 AI 协作开发不是让它一次性把所有事情都做完，而是像指挥施工队一样，把任务拆小、边做边验、随时存档。守住上述三条铁律，AI 编程项目就不容易失控。

2.3 原型转商用系统的工程化改造

一个能跑起来的原型，距离一个真正可上线、可维护、可扩展的商用系统，中间还有一段不短的距离。原型 的目标是「验证想法」：能不能跑、页面能不能展示、核心流程能不能走通。商用系统的目标则是「稳定交付」：能不能长期运行、多人使用、数据安全、出现问题后能不能快速定位和修复。所以，当原型已经验证可行后，下一步不是继续堆功能，而是进行工程化改造，这通常需要跨过五道门槛。

第一步：架构设计

原型阶段的代码，常常是单文件或少量文件拼出来的「大泥球」：页面、接口、数据处理、业务逻辑混在一起。短期看能跑，长期看很难维护。而一个主流的商用系统通常包括下面几个结构：

  • 前端：负责页面展示和用户交互；
  • 后端：负责业务逻辑、接口处理和权限控制；
  • 数据层：负责数据库访问、数据模型和持久化；
  • 配置层：负责环境变量、密钥、第三方服务配置；
  • 服务层：负责复杂业务规则的封装。

这一步可以让 AI 帮你做结构化拆分，但要注意，不要一上来就让它「全部重写」。更稳妥的方式是先让 AI 分析当前代码结构，再制定拆分方案。

推荐提示词：

请先分析我当前项目的代码结构，不要修改代码。
帮我指出哪些逻辑混在一起，并给出适合本系统的分层方案。

确认方案后再说：

请把当前代码按前后端分离架构拆分：前端采用Vue/React构建，UI框架使用ElementPlus/TailiwindCSS，后端使用SpringBoot架构，数据库采用MySQL,缓存适应Redis，前后端通过标准RESTful接口进行通信。
保持现有功能不变，不要新增功能。

第二步：数据建模

原型阶段的数据，可能只是临时变量、浏览器本地存储、Mock 数据，或者一个简单的 JSON 文件，这些方式适合验证流程，但不适合真实业务。商用系统需要规范的数据建模，至少要考虑：

  • 每张表存什么；
  • 每个字段是什么类型；
  • 哪些字段不能为空；
  • 哪些字段需要唯一约束；
  • 哪些字段需要建立索引；
  • 表与表之间是否存在关联关系；
  • 数据删除是物理删除还是软删除；
  • 是否需要记录创建时间、更新时间、操作者等审计字段。

例如，一个用户表不能只写：

json{
  "name": "张三",
  "password": "123456"
}

商用系统中，它可能需要变成：

  • id
  • username
  • email
  • password_hash
  • role
  • status
  • created_at
  • updated_at
  • last_login_at

同时还要考虑密码不能明文存储、邮箱是否唯一、账号是否禁用等问题。

可以让 AI 帮你完成数据建模：

请根据我的业务需求，设计数据库表结构。
要包含字段名、字段类型、是否必填、默认值、索引、唯一约束和表之间的关联关系。

进一步还可以让 AI 生成迁移脚本：

请基于以上表结构，生成 MySQL 的数据库迁移脚本。
包括建表语句、索引、外键约束和必要的初始数据。

第三步：自动化测试

原型阶段，测试通常靠手工点一点：打开页面、填表单、点按钮、看结果。这在早期没问题，但商用系统不能只靠手工测试。因为每一次功能修改，都可能影响之前已经正常的功能。没有测试保护，项目越改越不敢动。通常系统至少需要覆盖核心路径：

  • 用户注册是否正常；
  • 用户登录是否正常；
  • 权限校验是否生效；
  • 表单提交是否正确；
  • 核心数据是否能新增、查询、修改、删除；
  • 异常输入是否会被拦截；
  • 接口返回是否符合预期。

可以让 AI 先生成测试计划：

请根据当前项目功能，列出最重要的自动化测试用例。
按优先级排序，先覆盖登录、权限和核心业务流程。

然后再让 AI 写测试代码：

请为用户登录功能生成自动化测试。
包括成功登录、密码错误、账号不存在、账号被禁用四种情况。

前端项目可以要求生成：

请使用 Playwright / Cypress 生成端到端测试，覆盖从登录到创建订单的完整流程。

后端项目可以要求生成：

请使用 Jest / Pytest 生成接口测试，覆盖用户注册、登录和权限校验。

自动化测试的意义不是让代码「看起来更专业」，而是给后续迭代加一层保险。每次修改后自动跑一遍测试，能快速发现改动是否破坏了旧功能。

第四步：容器部署

本地能跑，不代表服务器能跑。很多原型在自己电脑上运行正常，是因为本地已经装好了各种依赖：Node、JDK、数据库、环境变量、缓存服务、第三方 SDK……但换一台服务器，可能立刻报错。商用系统需要把运行环境固化下来。最常见的方式就是容器化部署。通过 Docker，可以把应用运行所需的环境、依赖和启动命令封装起来。通过 docker-compose，可以同时管理前端、后端、数据库、Redis、Nginx 等多个服务。

可以让 AI 帮你生成部署文件：

请根据我的项目结构，生成 Dockerfile。
要包含依赖安装、构建命令和启动命令。

如果项目包含多个服务，可以说：

请帮我生成 docker-compose.yml。
包含前端、后端、MysqlSQL、Redis 和 Nginx。
要配置服务之间的网络连接和环境变量。

同时，还要让 AI 给出部署步骤：

请给我一份从本地构建到服务器部署的完整命令清单。
包括构建镜像、启动容器、查看日志和停止服务。

容器化的目标是：让项目不依赖某一台电脑，而是在任何符合条件的服务器上都能稳定运行。

第五步：安全加固

原型往往只关心功能是否可用，不太考虑攻击场景。但商用系统一旦上线，就会面对真实用户、真实数据和真实风险。

安全加固至少要关注以下问题：

  • SQL 注入：用户输入不能直接拼接进 SQL；
  • XSS 攻击：页面展示用户输入时需要转义；
  • CSRF 攻击：敏感操作需要防伪造请求；
  • 权限绕过：不能只在前端判断权限，后端也必须校验；
  • 密码安全：不能明文存储密码，需要哈希加盐；
  • Token 安全：登录凭证需要过期时间和刷新机制；
  • 输入校验：接口不能相信前端传来的任何数据；
  • 文件上传：限制文件类型、大小和存储路径；
  • 接口限流：防止暴力破解和恶意请求；
  • 日志脱敏：不能在日志中记录密码、Token、身份证号等敏感信息。

可以明确要求 AI 做安全检查：

请对当前项目进行安全审查。
重点检查 SQL 注入、XSS、CSRF、权限绕过、密码明文存储和敏感信息泄露问题。
先列出风险点，不要直接修改代码。

确认后再逐项修复：

请先修复登录接口的输入校验和密码安全问题。
其他功能保持不变。

或者：

请为所有需要登录的接口加入权限检查。
确保未登录用户无法访问，普通用户不能访问管理员接口。

安全加固不要依赖一句「帮我变安全」。要把安全需求拆成明确动作：校验输入、限制权限、加密密码、保护 Token、过滤输出、隐藏敏感信息。

从 原型 到商用系统，本质上是从「能跑」走向「可靠」。原型 证明想法可行，工程化改造决定产品能不能上线。

第三章 提示词篇：AI指挥提示词体系

很多人用 AI 编程时，最大的问题不是 AI 不会写代码，而是自己不会下指令。如何把脑子里的模糊想法，变成 AI 能准确执行的指令是首要解决的问题。AI 编程质量不是单纯由模型决定，也由你的提示词质量和上下文质量决定。

比如你说：

帮我做一个登录页。

AI 确实会做，但它不知道你想要什么风格、用什么框架、是否需要接口、是否能新增依赖、哪些文件不能动。于是它只能凭经验发挥，结果往往是：代码生成了，但不是你想要的。真正高效的 AI 编程，不是「随便问一句」，而是像给工程师派任务一样，把背景、目标、边界、示例和约束说清楚。

3.1 CRISPE 结构化框架

CRISPE工程提示框架由工程师 Matt Nigh 于 2023 年提出，2024 年经微软研究院优化后成为业界标杆级 Prompt 设计范式。它可以帮助你把一个模糊性的需求拆成六个结构化的部分：角色、背景、任务、范围、参数、约束。

3.1.1 CRISPE 六要素

维度 含义 作用 示例
C - Role 角色 告诉 AI 以什么身份思考 你是一个资深前端工程师
R - Background 背景 告诉 AI 当前项目是什么 我在做一个记账本 APP
I - Task 任务 明确要 AI 完成什么 帮我实现一个支出统计图表
S - Style / Scope 风格 / 范围 限定输出风格和修改范围 用 ECharts，只改 statistics.js 文件
P - Parameter / Example 参数 / 示例 提供数据格式、参考样例或输入输出 数据格式参考这个 JSON：{...}
E - Explicit Constraint 显性约束 明确告诉 AI 不要做什么 不要改 CSS 样式，不要引入新依赖

3.1.2 万能句式模板

可以直接套用下面这个模板：

你是一个【角色】。
当前项目【背景】。
请帮我【任务】。
要求：【风格 / 范围】。
参考：【参数 / 示例】。
特别注意：【显性约束】。

例如：

你是一个资深前端工程师。
当前项目是一个记账本 APP，已经完成了收入和支出记录功能。
请帮我实现一个支出统计图表。
要求使用 ECharts，只修改 statistics.js 文件。
数据格式参考：
{ "category": "餐饮", "amount": 120, "date": "2025-01-01" }
特别注意：不要修改 CSS 样式，不要引入新的依赖，不要改动其他页面。

这类指令比「帮我做个统计图」有效得多。因为它不仅告诉 AI 要做什么，也告诉 AI 在哪做、怎么做、不能做什么。

3.1.3 好提示词的判断标准

一个好的提示词，至少要满足三个条件：

第一，AI 知道你是谁、项目是什么

如果没有背景，AI 就只能猜。比如「做一个表格」这句话过于宽泛，它不知道这是后台管理系统、财务系统，还是项目管理系统。

更好的说法是：

我正在做一个面向小微企业的进销存系统，现在需要在库存页面增加一个商品列表表格。

第二，AI 知道具体要交付什么

不要只说「优化一下」「完善一下」「高级一点」。这些词对人类也模糊，对 AI 更模糊。

更好的说法是：

请把商品列表表格增加三个功能：按商品名称搜索、按库存数量排序、库存低于 10 时显示红色提示。

第三，AI 知道不能碰哪里

很多项目被 AI 改乱，不是因为它不会写，而是因为它改得太多。所以一定要加边界：

只修改 GoodsTable.vue 组件，不要改接口，不要改路由，不要新增依赖。

边界越清楚，AI 越不容易越界。

3.2 四类高频万能提示词

下面整理四类最常用、最实战的提示词， 它们分别对应 AI 编程中最常见的四个场景：

  1. 从零开始做原型；
  2. 在已有项目中局部修改；
  3. 遇到报错后修复；
  4. 参考别人的项目进行仿制或重构。

类型一：零基础开局提示词

适用于：你还没有代码，只是有一个想法，想先看界面长什么样。

标准提示词

我完全不懂代码。
我想做一个【产品类型】，给【用户群体】使用。
核心功能只有三个：【功能 1】、【功能 2】、【功能 3】。
请你先给我生成一个可以点击查看的 HTML 页面。
暂时不要写后端，不要接数据库，只做静态界面。
风格要【简约 / 科技 / 可爱 / 商务】，配色用【主色 + 辅色】。
我先看看样子。

示例一：做一个记账本 APP

我完全不懂代码。
我想做一个个人记账本 APP，给大学生和上班族使用。
核心功能只有三个：记录收入支出、查看本月统计、设置预算提醒。
请你先给我生成一个可以点击查看的 HTML 页面。
暂时不要写后端，不要接数据库，只做静态界面。
风格要简约清爽，配色用浅蓝色和白色。
我先看看样子。

示例二：做一个 AI 简历修改工具

我完全不懂代码。
我想做一个 AI 简历修改工具，给正在找工作的应届生使用。
核心功能只有三个：上传简历、输入目标岗位、生成修改建议。
请你先给我生成一个可以点击查看的 HTML 页面。
暂时不要写后端，不要接数据库，只做静态界面。
风格要商务、专业、干净，配色用深蓝色和浅灰色。
我先看看样子。

使用提醒

零基础开局时，不要一上来就让 AI 写完整系统。

不要说：

帮我做一个完整的记账系统，包含前端、后端、数据库和上线部署。

这类需求太大，容易生成一堆你看不懂、跑不起来、也无法维护的代码。

更好的方式是：

先生成静态页面，我确认界面后，再逐步增加交互和后端。

类型二：局部修改提示词

适用于：项目已经能跑，但你想改某一个按钮、某一个函数、某一个组件、某一个页面。

标准提示词

当前项目已经跑通。
请只修改【文件名】中的【函数 / 组件名】。
把【当前行为】改成【期望行为】。
其他所有代码保持原样。
不要新增依赖，不要重构其他模块。
改完后告诉我改了哪些地方。

示例一：修改登录按钮逻辑

当前项目已经跑通。
请只修改 LoginPage.vue 中的 handleLogin 函数。
当前行为是：点击登录按钮后没有校验手机号格式。
期望行为是：如果手机号不是 11 位数字，就提示「请输入正确的手机号」。
其他所有代码保持原样。
不要新增依赖，不要重构其他模块。
改完后告诉我改了哪些地方。

示例二：修改列表排序

当前项目已经跑通。
请只修改 OrderList.js 中的 sortOrders 函数。
当前行为是：订单按照创建时间正序排列。
期望行为是：订单按照创建时间倒序排列，最新订单显示在最上面。
其他所有代码保持原样。
不要修改接口，不要修改样式，不要新增文件。
改完后告诉我改了哪些地方。

使用提醒

局部修改时，最重要的是控制范围。

不要说：

这个页面不太好用，帮我优化一下。

要改成：

只修改 ProductCard 组件中的按钮文案，把「购买」改成「立即下单」，其他不变。

越具体，越安全。

类型三：报错修复提示词

适用于：项目运行时报错、打包失败、页面空白、接口请求失败等情况。

标准提示词

我运行项目时遇到以下错误：
【粘贴完整报错信息或使用工具一键引入】

请帮我分析原因，并给出可直接替换的代码或具体修改步骤。
不要让我全局重装依赖。
不要让我删除整个项目重新开始。
优先从配置、路径、代码写法和版本兼容角度排查。
如果需要我补充信息，请告诉我要提供哪个文件内容。

示例一：前端启动报错

我运行项目时遇到以下错误：
Module not found: Can't resolve './components/Header'

请帮我分析原因，并给出可直接替换的代码或具体修改步骤。
不要让我全局重装依赖。
不要让我删除整个项目重新开始。
优先从路径、文件名大小写、import 写法角度排查。
如果需要我补充信息，请告诉我要提供哪个文件内容。

示例二：后端接口报错

我运行项目时遇到以下错误：
TypeError: Cannot read properties of undefined (reading 'id')

请帮我分析原因，并给出可直接替换的代码。
不要让我全局重装依赖。
优先从请求参数、用户登录状态、对象判空和接口返回值角度排查。
如果需要我补充信息，请告诉我要提供哪个文件内容。

使用提醒

报错修复时，一定要粘贴完整错误信息。
不要只说：

报错了，帮我看看。

更好的方式是：

  1. 粘贴终端完整报错；
  2. 粘贴浏览器控制台报错；
  3. 说明你刚刚做了什么操作；
  4. 告诉 AI 项目使用的技术栈；
  5. 如果有截图，也一起提供。

例如：

我刚刚修改了登录页面，重新运行 npm run dev 后报错。技术栈是 Vue3 + Vite。下面是终端完整报错：……

这样 AI 才能更快定位问题。

类型四：仿制重构提示词

适用于：你看到一个开源项目、网站、截图或产品界面，想借鉴它的布局、风格或交互，但不想直接复制代码。

标准提示词

我参考了【开源项目 / 截图 / 网页链接】。
请按照它的【布局方式 / 交互逻辑 / 视觉风格】，基于我的现有技术栈【框架名称】，生成一个独立的【页面 / 组件】。
不要复制原项目代码，不要复制原项目依赖。
只借鉴【具体维度】。
输出代码要能直接放进我的项目中使用。

示例一：参考某个 SaaS 官网首页

我参考了一个 SaaS 官网首页截图。
请按照它的首屏布局方式，基于我的现有技术栈 React + Tailwind CSS，生成一个独立的 HomePage 组件。
不要复制原网站代码，不要引入新的 UI 库。
只借鉴它的结构：顶部导航、左侧标题文案、右侧产品截图、底部客户 Logo 区。
视觉风格保持简约科技感。
输出代码要能直接放进我的项目中使用。

示例二：参考开源后台系统的侧边栏

我参考了一个开源后台管理系统。
请按照它的侧边栏交互逻辑，基于我的现有技术栈 Vue3 + Element Plus，生成一个独立的 Sidebar 组件。
不要复制原项目代码，不要复制原项目依赖。
只借鉴它的交互方式：支持菜单展开收起、当前菜单高亮、二级菜单缩进显示。
其他页面不要修改。

使用提醒

仿制不是照搬。你要告诉 AI 具体借鉴什么：

  • 借鉴布局；
  • 借鉴配色；
  • 借鉴交互；
  • 借鉴信息层级；
  • 借鉴组件组织方式。

不要说：

做一个和这个网站一模一样的。

更好的说法是：

借鉴这个网站的首页结构和视觉氛围，但文案、颜色、组件代码都重新生成，不复制原始代码。

这样既更清晰，也更安全。

3.3 实操准则：三条高效使用细则

掌握模板之后，还需要掌握使用习惯。同样的提示词，不同的提问方式，效果差别很大。以下三条准则，是和 AI 协作编程时最重要的基本功。

准则一：单次单一需求

一次对话只说一件事。不要在一条消息里同时提出七八个需求：

帮我改按钮颜色，加一个表单，修一下登录报错，再优化一下首页，还要接入数据库，顺便部署上线。

这种指令看起来效率高，实际最容易失控。AI 可能做了其中几件，漏掉几件，甚至为了完成新需求，把原来正常的代码改坏。正确做法是拆开：

第一轮：

请把登录按钮颜色从蓝色改成绿色，其他不变。

确认无误后，第二轮：

请在登录页增加一个手机号输入框，其他不变。

再确认后，第三轮：

请为手机号输入框增加 11 位数字校验。

单次单一需求的好处是：每一轮都知道改了什么，出了问题也容易回退。

准则二：边界约束先行

在提需求之前，先说「不要做什么」。AI 很擅长主动补全，但这也是风险来源。你只想改一个按钮，它可能顺手改了页面结构；你只想修一个函数，它可能顺手重构了整个文件；你只想改样式，它可能顺手引入一个新的 UI 库。所以，在需求里要提前加边界。

常用边界包括：

  • 不要改 package.json；
  • 不要新增依赖；
  • 不要修改数据库结构；
  • 不要新增文件；
  • 不要修改接口路径；
  • 不要改 CSS；
  • 不要改路由；
  • 不要重构其他模块；
  • 只修改指定文件；
  • 只修改指定函数；
  • 保持现有功能不变。

示例：

当前项目已经跑通。
请只修改 UserList.vue 文件。
不要改 package.json，不要新增依赖，不要修改接口，不要改路由。
只把用户列表增加一个按姓名搜索的输入框。

边界越清楚，AI 越不容易越界。

准则三：附参考样例

人类指着图说话最快，AI 也是一样。如果你只是说：

页面要高级一点。

AI 很难准确理解你要的「高级」是什么。但如果你给一张截图，或者给一个参考链接，再说明你喜欢哪里，效果会好很多。

常见参考材料包括：

  • 页面截图；
  • 竞品链接；
  • 开源项目地址；
  • JSON 数据样例；
  • 接口返回示例；
  • 旧版本代码；
  • 设计稿；
  • 错误日志；
  • 数据库表结构；
  • 你喜欢或不喜欢的示例。

例如：

请参考这张截图的布局：顶部是导航栏，中间左侧是标题和按钮，右侧是一张产品图。
但不要照抄颜色，我希望主色改成紫色。

或者：

接口返回数据格式如下，请根据这个 JSON 渲染列表：

json{
  "items": [
    {
      "id": 1,
      "name": "商品A",
      "price": 99,
      "stock": 20
    }
  ]
}

「像这样」三个字，往往胜过一百句抽象描述。但要注意，给参考时不要只说「照这个做」，而要明确：参考什么，不参考什么。

3.4 常用提示词速查表

为了方便实际使用，可以把下面这些句子保存下来，作为日常 AI 编程的快捷提示词。

  1. 需求澄清

我想做一个【产品】，但需求还不清楚。
请你用产品经理的方式，向我提 10 个关键问题，帮助我明确用户、场景、核心功能和优先级。

  1. 原型生成

请根据以下需求生成一个静态 HTML 原型页面。
只需要 HTML + CSS，不要写后端，不要接数据库。
页面要能直接在浏览器打开预览。

  1. 页面美化

请只优化当前页面的视觉样式。
不要修改功能逻辑，不要修改接口，不要新增依赖。
风格方向是【简约 / 商务 / 科技 / 可爱】。

  1. 代码解释

我看不懂下面这段代码。
请用零基础也能听懂的方式解释它的作用。
按「整体功能—关键变量—执行流程—可能风险」四部分说明。

  1. 接口开发

请帮我实现一个【接口名称】接口。
请求方法是【GET / POST / PUT / DELETE】。
请求参数是【参数列表】。
返回格式参考【JSON 示例】。
请加入必要的输入校验和错误处理。

  1. 数据库设计

请根据以下业务需求设计数据库表结构。
要包含字段名、字段类型、是否必填、默认值、索引、唯一约束和表关系。
同时生成建表 SQL。

  1. Bug 修复

我遇到了以下报错。
请先分析可能原因，不要直接改代码。
然后给出最小修改方案，要求只修改必要文件。

  1. 测试生成

请为【功能名称】生成自动化测试用例。
覆盖正常情况、异常情况和边界情况。
使用当前项目已有的测试框架，不要新增依赖。

  1. 部署指导

当前项目已经可以本地运行。
请帮我生成部署方案。
包括环境要求、构建命令、启动命令、环境变量配置和常见报错排查。

  1. 安全检查

请对当前代码做一次安全检查。
重点检查输入校验、权限控制、SQL 注入、XSS、CSRF、密码存储和敏感信息泄露。
先列出风险点，不要直接修改代码。

第四章 实战篇：人群适配与实践打法

前面几章讲的是方法论、流程和提示词。但真正落地时，不同人群的使用方式并不一样。零基础的人，不应该一上来学习代码架构；工程师，也不应该还把 AI 当成一个简单的代码补全工具；产品和设计，更不应该只停留在「让 AI 写文案」层面。AI 编程的关键，不是所有人都用同一种方式，而是根据自己的背景，找到最适合的打法。

4.1 人群分层落地

不同人群使用 AI 编程，核心策略完全不同。可以简单分成三类：

  1. 零基础非技术人群；
  2. 技术转指挥人群；
  3. 产品/设计人群。

4.1.1 零基础非技术人群：产品、运营、创业者

核心策略：极简开发链路。对零基础用户来说，最重要的不是「学会写代码」，而是学会用自然语言把需求说清楚。不需要理解变量、函数、接口、数据库这些技术概念。只需要围绕三个句式来驱动 AI：

我要一个像 XXX 一样的东西。
这里改成 YYY 的样子。
点击这个按钮后，发生 ZZZ。

也就是说，零基础用户的开发路径不是「先学编程，再做产品」，而是：

先用自然语言描述 → 让 AI 生成界面 → 逐步修改 → 加入简单逻辑 → 部署给别人用。

这个过程更像是在「指挥搭建」，而不是亲自「写代码」。

真实案例：3 天做出内部工单管理系统

一位完全不懂编程语言的运营人员，用 AI Coding 的方式，在 3 天内完成了一个内部工单管理系统。

他的目标很简单：

团队里每天有大量临时需求，靠微信群沟通容易遗漏。
希望做一个简单系统，让同事提交需求、运营分配负责人、最后标记完成状态。

整个过程如下。

第一天：用截图启动原型

他给 AI 看了一张飞书审批页面的截图，然后说：

我想做一个类似飞书审批的内部工单系统。
左侧是工单列表，右侧是工单详情。
工单详情里有标题、提交人、优先级、截止时间、处理状态和备注。
先不要写后端，只生成一个可以预览的 HTML 页面。

AI 生成了第一个静态页面。

他不需要看懂代码，只需要看界面是否符合预期。

第二天：逐轮修改字段和流程

他开始按照实际业务修改：

第一轮：

把「审批人」改成「负责人」。

第二轮：

增加一个「需求类型」字段，选项包括：设计、文案、活动、数据、其他。

第三轮：

状态流转改成：待处理、处理中、待确认、已完成、已驳回。

第四轮：

在工单详情底部增加一个评论区，用于记录处理过程。

每一轮只改一个地方，所以即使不懂代码，也不会把项目改乱。

第三天：生成共享链接

界面和流程确认后，他让 AI 加入简单的数据保存逻辑，并生成可部署版本：

请让这个工单系统的数据可以保存在浏览器本地。
支持新增工单、修改状态、添加评论。
然后告诉我如何生成一个团队可以访问的链接。

最后，他通过托管平台生成了一个内部共享链接，团队成员可以直接使用。这个系统不一定完美，但它解决了真实问题。这就是零基础人群使用 AI 编程的核心价值：先做出一个可用工具，而不是先成为程序员。