AI 做产品？你是否也遇到了这些坎？

想用 Cursor 这类强大的 AI 编程工具，把脑海中的产品想法快速变成现实？但在激动地投入尝试后，你是否也遇到了这些令人抓狂、甚至想放弃的问题：

1. 想法很酷，代码“挠头”？ 懂产品、懂需求，但面对具体编码实现（或让 AI 实现）时，感觉力不从心，不知如何精确指导？
2. AI 时好时坏，像开“盲盒”？ 它有时能秒出惊艳代码，有时却生成一堆看似正确、实则隐藏 Bug 的“定时炸弹”？
3. “修复”变“破坏”？ 满怀希望让 AI 修改一个问题，结果它却“举一反三”地破坏了其他正常工作的代码，越改越糟心？
4. 过程失控，结果难料？ 感觉自己像在和 AI “摔跤”，而不是高效协作，项目进度和质量都难以把控？
5. 雄心勃勃开始，灰头土脸放弃？ 因为反复的挫败感和不确定性，最初那个让你兴奋不已的项目，最终停留在某个无法推进的节点，成了又一个“有缘再见”？

如果你对以上任何一点深有同感，那么问题很可能不在于 AI 能力不足，而在于我们缺少一套有效的“人机协同作战地图”和“AI 行为约束手册”。

这份文档，就是为解决这些痛点而生。它专为懂产品、懂需求，但编程经验相对有限，渴望利用 AI 独立完成产品开发的你（比如产品经理、设计师、运营人员或跨界学习者）量身定制。

它不教你高深的编程技巧，而是提供：

1. 一套结构化的项目落地流程： 从想法验证到部署维护，步步为营。
2. 一份核心的 AI 协作规范 (.cursor-guidelines.md)： 给 AI “立规矩”，让合作更顺畅。
3. 一系列即插即用的 Prompt 模板： 精准引导 AI，获取高质量输出。
4. 一套面向新手的审查与测试心法： 即使代码看得不全懂，也能有效把控质量。

目标只有一个： 帮你更有章法、更有信心地驾驭 AI，让它真正成为你手中可靠的创造工具，而不是难以预测的“黑盒子”，从而实实在在地把你的产品想法落地！

文档使用说明

1、定位与背景：

（1）本文档旨在为利用 AI 进行编程协同、独立完成项目落地提供一套结构化的方法论与实践指引。

（2）自己有七年 B 端为主、兼具 C 端经验的产品经理背景，23- 24 年在前公司深度参与 AI+电商领域的项目实践。虽然在具体编码层面属于初学者，但对软件工程的生命周期、需求管理、以及各阶段的交付标准有深入理解。这份指南正是融合了产品管理的结构化思维与 AI 编程的初步实践经验，试图为与 AI 高效、可控地共创价值探索一条路径；

（3）在技术架构、数据库、部署等笔者过往实践较少的领域，本文档记录了借助 AI 探索并形成推荐方案的过程，希望能为背景类似的开发者提供借鉴。

2、实践基础：

（1）本指南的方法论已在 Cursor、Trae 等 AI 编程工具的辅助下，应用于两个微信小程序和一个 Web 应用的实践，并通过与 DeepSeek、Gemini 2.5 Pro、GPT-4 等先进模型的深度探讨进行了迭代完善；

3、使用建议：

（1）鉴于自己的背景，本文档及配套 Prompt 在需求工程（想法验证、MRD、PRD）阶段着墨较多，力求通过清晰的需求定义来弥补编码经验的不足，为 AI 提供高质量的输入。

（2）在技术实现层面，则更侧重于明确约束、引导 AI 基于最佳实践和新手友好原则提供解决方案及理由。

（3）建议使用者根据自身的背景和具体项目需求，批判性地审视并调整本文档中的 Prompt 和流程细节。初期项目不妨直接采用以熟悉流程、建立“手感”，关键在于在实践中持续总结、迭代，形成最适合自己的 AI 协同模式

AI 编程感悟与原则

1、洞察 AI 边界，善用其能： 认识到 AI 在上下文理解、长程记忆上的局限性。关键在于通过结构化的文档（如 MRD->PRD->TDD 的依赖传递） 为其提供清晰、连贯的“记忆”和“指引”，最大化利用其在特定任务上的优势；

2、确立开发者主导地位： 始终铭记 AI 是助手而非决策者。开发者需扮演架构师、质检员和最终整合者的角色，对 AI 的输出进行严格的引导、审核与筛选。绝不盲从，保持批判性思维。

3、 精准沟通，赋能 AI： AI 的表现高度依赖于输入的质量。清晰、具体、上下文丰富的 Prompt 是获取高质量输出的前提。学会“对 AI 说人话，更要说内行话”。

4、 分而治之，降低复杂度： 将宏大目标拆解为 AI 更易于处理的、小而美的任务块，是控制风险、保证质量、实现快速迭代的有效策略。

5、 验证闭环，永不信任： AI 可能犯错，且错误有时极其隐蔽。理解、审查、多层次测试（单元、集成、手动） 是不可或缺的质量保证环节，形成“生成-验证-反馈-修正”的闭环。

6、 拥抱迭代，持续优化： 将 AI 的每次输出视为待完善的草稿。通过多轮提问、修正和共同探索，逐步逼近理想状态。耐心和迭代是 AI 协作的常态。

7、 巧用工具，放大效能： 深入学习并利用 Cursor 等先进 AI 编程工具的特性（代码感知、上下文注入、智能建议等），让工具与方法论相得益彰。

8、 保持敏锐，与 AI 共进化： AI 技术日新月异，保持对新工具、新能力的关注和学习，是持续提升 AI 协同效能的关键。

为了将这些原则系统性地融入日常开发，构建了 .cursor-guidelines.md 文件。它不仅是规则的集合，更是我们与 AI 建立高效、可靠协作关系的契约蓝本，是实现“让 AI 成为合格副驾驶”目标的核心支撑。

AI 编程协同项目落地

在理解了 AI 编程的基本原则之后，为了确保项目能够有序、高效地推进，我们需要在正式开始具体流程之前，先构建一个清晰、规范的基础框架；

基础框架包含了对应的项目文件组织结构，作为核心“规则书”的 .cursor-guidelines.md 文件的概览及其重要性，以及项目中各类关键文档的职责分工。

明确框架的好比在动工前拥有了详细的建筑图纸和施工规范。它不仅能帮助我们（以及 AI）在后续的开发过程中保持方向一致、信息规整，更能显著提升 AI 协作的效率和准确性，为最终成功落地项目奠定坚实的基础；

1、项目结构设计理念：

1. 中心化与就近化结合: 全局性文档（PRD、架构）存放于 docs/，便于宏观查阅；与特定代码模块紧密相关的技术笔记则放在 src/features/*/README.md，实现“文档随代码”，方便开发和 AI 理解局部上下文。
2. 关注点分离:docs/ 存放“是什么”、“为什么设计”；src/ 存放“如何实现”；.cursor-guidelines.md 关注“如何协作”；根 README.md 负责“快速上手”。职责清晰。
3. 可扩展性: 模块化的 src/features/ 结构便于未来功能的扩展和维护。

2、核心协作规范 (.cursor-guidelines.md 概述)

（1）.cursor-guidelines.md 是本方法论的“灵魂”所在，它将前述的 AI 编程感悟转化为具体、可执行的操作指令和行为规范。它不是一份束之高阁的文档，而是需要 AI 和开发者在每一次交互、每一次代码生成、每一次文档更新中都参照执行的“契约”。

（2）作为与 AI 协作的全局指导，可配置在 cursor 对应的规则里面，也可作为对应的每个项目初始文档建立，用于存放发规范和 AI 协作规则，指导开发过程。目前我测试下来，如果放在设置里面，貌似不会一直被引用。

（3）其核心价值体现在：

1. 约束 AI 行为，提高可预测性: 通过明确 AI 的角色、沟通方式和工作流程，减少 AI 的“自由发挥”，使其行为更符合项目预期。
2. 统一标准，保证质量与一致性: 无论是编码风格、错误处理，还是文档要求，统一的标准有助于 AI 生成更高质量、更一致的产出。
3. 沉淀最佳实践，赋能开发者: 将与 AI 高效协作的模式、Prompt 技巧固化下来，帮助开发者（尤其是新手）快速掌握与 AI 共舞的要领。

（4）.cursor-guidelines.md文档内容

3、根 README.md生成对应的 prompt:

（1）目标读者:

1. 任何人（包括未来的你、潜在的协作者、甚至 AI 快速了解项目）

（2）内容:项目的入口和门面。

1. 包含：项目标题、一句话简介、核心功能列表、如何快速启动和运行项目 (Quick Start)、项目状态、指向 docs/ 目录的链接以获取更详细信息、贡献指南（如果开源）、许可证。
2. 特点: 简洁、引导性强，侧重于“是什么”和“怎么跑起来”。

（3）不同阶段 readme 文档通常需要包含、补充或修正的内容：

1. 阶段 0：项目初始化 (仓库创建，仅有 "Hello World" 或项目骨架)
2. 此时状态： 刚刚创建项目，代码非常基础，甚至只有一个空框架。
3. README 内容 (创建基础版):
4. 项目标题: (必须) 明确的项目名称。
5. 一句话简介: (必须) 用一句话说明这个项目的核心想法或目标（可以非常初步）。
6. 状态说明: (推荐) 标注项目当前状态，如 "孵化中"、"规划中"。
7. 基础设置/运行指令 (如果可能): (必须，即使很简单)
8. 如何克隆仓库 (git clone ...)。
9. 安装最基本依赖的命令（如果有，如 npm install）。
10. 运行这个 "Hello World" 或骨架的命令（如有，如 npm run dev）。
11. 许可证 (License): (推荐) 预留位置或指定一个（如 MIT）。
12. 目的： 建立项目的基本标识，提供能让开发者（包括您自己）克隆并验证项目初始状态的最基本指令。
13. 阶段 1：初步开发阶段 (MRD/PRD 初稿完成，基础代码结构搭建，核心模块开始开发)
14. 此时状态： 对要做什么有了更清晰的认识 (MRD/PRD)，代码结构开始形成，确定了主要技术栈。
15. README 内容 (补充和修正):
16. 完善简介: (修正) 根据 MRD/PRD 的内容，让项目简介更准确、更有吸引力。
17. 核心功能列表 (高级别): (补充) 从 PRD 中提取 V1.0 的主要功能点，简要列出。
18. 技术栈概览: (补充) 简要列出已确定的主要技术（语言、框架、数据库/BaaS、部署平台等），可以链接到 docs/architecture/tech_stack.md（如果该文档已开始编写）。
19. 详细的本地开发设置: (修正/补充) 提供更完整的安装依赖、配置环境（如 .env 文件说明）、运行开发服务器、访问应用的方式等指令。
20. 文档链接: (补充) 添加指向 docs/ 目录（或 docs/README.md）的链接，引导查阅详细文档。
21. 贡献指南 (占位): (补充) 可以先创建一个标题，表示未来会添加贡献说明。
22. 目的： 提供更丰富的项目背景信息，指导开发者配置好本地开发环境，了解项目的主要构成和目标。
23. 阶段 2：活跃开发阶段 (MVP 核心功能开发中或接近完成)
24. 此时状态： 大部分核心功能已经实现，项目结构稳定，测试和部署开始提上日程。
25. README 内容 (补充和修正):
26. 更新功能列表: (修正) 标记各功能的状态（如 已完成、开发中）。
27. 添加测试指令: (补充) 如何运行单元测试、集成测试等。
28. 添加部署信息: (补充) 简要说明如何部署，或者提供指向 Vercel/Netlify 项目地址或 docs/deployment.md 的链接。
29. 更新或确认技术栈: (修正) 如果开发过程中技术选型有微调，及时更新。
30. 完善贡献指南 (如果需要): (补充) 如果希望他人参与，可以开始添加具体的贡献流程、代码风格要求等。
31. 目的： 反映项目当前的开发进度，提供测试和初步部署的信息，为可能的协作打下基础。
32. 阶段 3：发布后或持续维护阶段 (MVP 发布或后续版本迭代)
33. 此时状态： 项目已有可交付的版本，或进入长期维护和迭代。
34. README 内容 (补充和修正):
35. 添加版本信息: (补充) 标注当前的稳定版本号。
36. 更新功能列表: (修正) 突出当前版本的主要特性。
37. 截图/Demo (可选): (补充) 加入少量截图或 GIF/视频演示链接，让用户更直观地了解产品。
38. 最终确认部署链接: (修正) 提供准确的线上访问地址。
39. 确保所有链接有效: (修正) 检查文档、贡献、许可证等链接是否都正确。
40. 更新快速启动 (如果需要): (修正) 确保快速启动指令对最终用户或新加入的开发者仍然有效。
41. 目的： 作为产品/项目的正式介绍页面，服务于最终用户和新的贡献者，提供最准确、最新的信息。

（4）用户与 AI 的互动方式：

1. 初始创建 (阶段 0): 用户提供项目名和初步想法，使用 README Prompt，AI 会生成一个包含标题、初步简介、基础运行指令（如果 AI 能推断或用户提供）以及大量占位符的初版 README。
2. 后续更新 (阶段 1-3): 随着项目进展，用户主动发起对 README 的更新请求，例如：
3. “请帮我更新 README.md 中的‘核心功能列表’，根据 docs/PRD_v1_draft.md 中 v1.0 的范围来写。”
4. “我们确定了技术栈，请更新 README.md 的‘技术栈概览’部分，内容参考 docs/architecture/tech_stack.md。”
5. “请在 README.md 中添加‘运行测试’的指令：npm run test。”
6. “项目 v1.0 发布了，请在 README.md 开头添加版本号信息，并更新部署链接为 [新链接]。”

4、不同文档差异

文件/目录 (File/Folder)

主要目的 (Primary Purpose)

关键内容/示例 (Key Contents/Examples)

主要读者 (Primary Audience)

README.md (根目录)

项目入口与概览：提供项目基本信息和快速启动指南。

项目名称/简介、核心特性、如何安装/运行/测试 (Quick Start)、技术栈概览（可选）、指向 docs/ 的链接、贡献指南、许可证。

任何人（开发者、用户、AI 初次接触）

.cursor-guidelines.md

开发流程与 AI 协作规范：定义如何在本 K 项目中进行开发和协作。

AI 角色定义、交互原则、工作流程协议（需求/编码/调试/文档）、通用编码原则、文档标准、(可引用 docs/architecture/ 中的具体技术规范)。

开发者、AI

docs/ (目录)

项目详细文档库：存放所有深入、结构化、持久化的项目文档。

PRD、架构设计、部署指南、配置说明、深度教程、API 设计原则等。

开发者、项目经理、运维、AI（深入了解时）

docs/README.md (或 index.md)

文档库索引/目录：作为 docs/ 目录的导航页，方便查找。

docs/ 内主要文档的列表、简要说明和链接。

开发者、项目经理、运维、AI

docs/PRD.md

产品需求定义：详细描述“产品做什么”，包括功能、用户故事等。

项目目标、用户画像、功能详述（含 Feature ID、状态）、用户流程图、验收标准、非功能需求、版本变更历史。

产品经理、开发者、测试、AI

docs/architecture/ (目录)

系统架构与技术设计：描述系统“如何构建”，包括结构和技术选型。

架构图、组件说明、技术栈选型详情 (语言/框架/数据库)、数据模型定义、API 设计原则、关键技术决策记录 (ADR)。

开发者、架构师、运维、AI

docs/architecture/tech_stack.md (示例)

技术栈选型详情(可选独立文件)：集中记录使用的技术和版本。

主要语言、框架、数据库、缓存、消息队列、关键库及其版本号和选择理由。

开发者、架构师、运维、AI

docs/setup_guide.md

详细环境搭建指南：指导如何从零配置可运行的开发环境。

系统依赖列表、环境变量设置、数据库初始化脚本、特殊工具安装与配置步骤。

新开发者、运维

docs/deployment.md

部署流程说明：描述如何将应用发布到生产或其他环境。

构建命令、部署脚本用法、服务器要求与配置、CI/CD 流水线解释、回滚策略。

开发者、运维

src/ (目录)

源代码实现：包含项目所有可执行逻辑和核心代码。

按功能模块 (features/)、核心库 (core/)、工具函数 (utils/) 组织的代码文件、主入口文件。

开发者、AI（代码分析/生成时）

src/.../README.md 或 _docs/

模块级技术文档：记录特定代码模块内部的设计、实现要点或笔记。

模块职责说明、复杂算法/逻辑解释、模块内部特定配置、内部接口说明、使用示例、开发者遇到的坑或技巧 (与该模块代码紧密相关)。

维护该模块的开发者、AI（处理该模块时）

AI 编程协同落地流程

接下来，我们将详细拆解一个借助 AI 进行协同的、从想法到产品落地并持续迭代的完整流程。

对应的包含了以下八个关键开发阶段：1. 想法验证与初步构思，2. 需求定义 (MRD)，3. 产品设计与规格定义 (PRD)，4. 技术设计与规划 (TDD)，5. 开发与迭代，6. 测试与质量保证，7. 部署，以及 8. 维护与迭代。

1、想法验证与初步构思 (Idea Validation & Brainstorming):

（1）目标 (Goal): 将脑海中模糊的、可能仅有点状的初始想法，通过结构化的提问与探讨，进行初步的可行性验证、核心价值挖掘和概念澄清，为后续更严肃的需求定义（MRD）降低方向性风险并奠定认知基础。

（2）核心输入 (Input): 开发者脑海中的原始 Idea（可能只是一句话或一个模糊的概念）。

（3）关键活动与 AI 协作 （Key Activities & AI Collaboration）：

1. 此阶段 AI 的角色是**“产品壁打ち伙伴” (Sparring Partner) 和“初级市场分析师”**。
2. 使用下方的 “想法验证 Prompt” 启动与 AI 的对话。
3. 通过 AI 的引导性提问，深入挖掘想法背后的核心问题，探索潜在的目标用户及其痛点，构思使用场景，并尝试提炼核心价值主张。
4. 利用 AI 的知识库进行初步的市场扫描，了解是否存在明显竞品或替代方案。
5. 引导性地思考简化方案与 MVP (最小可行产品) 的可能性。
6. 整个过程强调开放性和发散性，但也需 AI 协助聚焦，避免漫无边际。请始终参照 .cursor-guidelines.md 中的通用交互原则与 AI 沟通。

（4）主要产出与流向 (Output & Flow):

1. 产出形式通常是非正式的笔记、备忘录、或是对话记录总结，内容包含：初步澄清的核心概念、粗略的用户画像、明确的核心问题与价值主张、关键使用场景、MVP 构想、初步风险识别等。
2. 这些产出物将作为下一阶段撰写 MRD 的关键素材和输入。

（5）核心 Prompt:

2、需求定义 (MRD市场需求文档):

（1）目标 (Goal): 基于第一阶段验证和构思的成果，系统性地梳理和定义产品的市场定位、目标用户、核心价值、高阶功能范围及成功标准，形成一份结构化的 MRD 文档，作为产品后续设计的战略输入和边界约束。

（2）核心输入 (Input): 阶段一产出的想法备忘录、用户画像草稿、初步分析等。

（3）关键活动与 AI 协作 （Key Activities & AI Collaboration）：

1. AI 角色转变为**“文档助理”和“结构化思考辅助”**。
2. 使用下方的 “MRD Prompt (v2.0)”，将阶段一的关键信息作为输入，让 AI 生成 MRD 文档的结构化初稿。
3. 针对 AI 生成的初稿，进行审阅和迭代：利用 AI 进一步澄清目标、细化用户描述、提炼价值主张、评估高阶功能的合理性与优先级。可以提出如：“针对这个目标用户，还有哪些潜在需求我们没考虑到？” 或 “这个高阶功能是否真正服务于核心价值主张？”等问题。
4. (可选质量增强步骤) 如您在文档说明中提到，可以将 AI (如 Cursor) 生成的 MRD 初稿，输入到其他大模型（如 Gemini, GPT, DeepSeek）中，请求它们扮演“评审专家”的角色，提出改进意见或潜在盲点。将这些反馈整合后，再返回给 Cursor 进行最终的文档完善。
5. 全程交互需遵循 .cursor-guidelines.md 规范。

（4）主要产出与流向 (Output & Flow):

1. 产出物是一份结构化的 MRD 文档（建议保存为 docs/MRD.md）。
2. 这份文档明确了“为什么做”和“做给谁”，为下一阶段 PRD 的“做什么”提供了清晰的方向和基础。

（5）核心 Prompt:

3、产品设计与规格定义 (PRD产品需求文档):

（1）目标 (Goal):

将 MRD 中定义的高阶需求和目标，转化为具体、详细、可执行的产品功能规格说明。PRD 是开发团队（包括 AI）理解“要做什么”以及“如何算完成”的核心依据，并包含初步的版本规划和迭代蓝图。

（2）核心输入 (Input):

已定稿或基本稳定的 MRD 文档 (docs/MRD.md)。可能的界面草图或交互想法笔记。

（3）关键活动与 AI 协作 （Key Activities & AI Collaboration）：

1. AI 角色类似于**“初级产品经理”或“需求分析师”**。
2. 使用下方的 “PRD Prompt (v2.0)”，以 MRD 为核心输入，引导 AI 生成包含版本规划、用户故事、验收标准等的 PRD 初稿。
3. 重点与 AI 协作细化功能：将 MRD 的高阶功能分解为具体的 User Stories；为每个 Story 编写清晰的描述和可测试的 Acceptance Criteria (AC)。可以反复提问：“这个 AC 是否足够具体？能否覆盖所有主要场景？”
4. 与 AI 共同规划版本和迭代：讨论 MVP 范围的合理性，梳理功能的依赖关系和优先级，形成初步的 Roadmap。
5. 如果需要，可以让 AI 辅助构思用户流程或描述界面布局（基于文本描述）。
6. 交互需遵循 .cursor-guidelines.md 规范。

（4）主要产出与流向 (Output & Flow):

1. 产出物是PRD 文档（建议保存为 docs/PRD.md，并持续维护为活文档）。
2. PRD 是连接需求与实现的关键桥梁，直接指导下一阶段的技术设计 (TDD) 和后续的开发与迭代 (Stage 5)。

（5）三方 AI 完善校验，反向补充

1. 可以使用 gemini、gpt、deepseek 等工具，把对应的文档输入，让他提出改进意见；
2. 根据改进意见完善后再补充到 cursor 文档告知cursor；

（6）核心 Prompt:

4、技术设计与规划 (TDD文档):

（1）目标 (Goal): 基于 PRD 定义的产品需求，以及开发者（您）的背景和偏好，设计系统的技术实现方案。核心是进行对新手友好的技术选型（语言、框架、数据库/BaaS、部署平台等），并勾勒出初步的系统架构，为后续编码提供清晰的“施工图”。

（2）核心输入 (Input): PRD 文档 (docs/PRD.md)，开发者背景描述（新手、运维经验少等），明确的技术偏好或限制（如有）。

（3）关键活动与 AI 协作 （Key Activities & AI Collaboration）：

1. AI 角色转变为**“技术顾问”或“初级架构师”，特别需要具备“同理心”**，理解新手开发者的痛点。
2. 使用下方的 “TDD Prompt (v2.1)”，清晰告知 AI 所有背景信息和需求，引导其推荐技术方案。
3. 重点关注 AI 对 BaaS 和 Vercel/Netlify 等简化方案的推荐理由及权衡分析。针对这些推荐进行深入提问：“Supabase 的免费额度够用吗？” “如果未来用户量增长，从 Vercel 迁移会困难吗？” “这个 BaaS 能满足 PRD 里 XX 功能对实时性的要求吗？”
4. 让 AI 辅助生成初步的数据模型草稿（例如，基于 BaaS 的表结构建议）或API 设计思路（如果需要）。
5. 与 AI 共同绘制或描述一个简洁的架构图/说明。
6. 开发者基于 AI 的建议和解释，结合自己的理解和偏好，做出最终的技术选型决策。交互需遵循 .cursor-guidelines.md。

（4）主要产出与流向 (Output & Flow):

1. 产出物是技术设计相关的文档，建议存放在 docs/architecture/ 目录下，可能包括 overview.md, tech_stack.md 等。
2. 这份技术蓝图将直接指导下一阶段的开发与迭代 (Stage 5)，包括代码结构创建、库的选择与使用等。

（5）核心 Prompt:

5、开发与迭代 (AI 编程核心环节):

（1）目标 (Goal): 基于 PRD 和 TDD，将产品功能通过编写代码的方式逐步实现出来，产出可工作、符合质量要求的软件。这是 AI 编程工具发挥核心价值的阶段。

（2）核心输入 (Input): PRD 文档 (docs/PRD.md)，TDD/架构文档 (docs/architecture/*)，模块级文档 (src/.../README.md)，.cursor-guidelines.md。

（3）关键活动与 AI 协作 （Key Activities & AI Collaboration）：

1. AI 角色是**“编码助手”、“代码审查员（初级）”、“调试伙伴”**。
2. 遵循“小步快跑”原则： 将 PRD 中的用户故事或功能点拆分为更小的编码任务。
3. 使用精确指令与上下文： 向 AI (如 Cursor) 发出具体的编码请求，明确功能、输入输出、依赖关系，并利用工具特性（如选中代码、@文件）提供充足上下文。
4. AI 生成代码： 让 AI 生成函数、类、组件、配置文件、甚至基础的模块骨架代码。
5. 开发者审查与验证 (核心环节 - 新手策略):
6. 绝不直接复制代码！
7. 利用 AI 解释： 要求 AI 逐段、逐行解释代码逻辑和意图。
8. 聚焦行为测试： 编写（或让 AI 生成并解释）单元测试用例，重点理解测试场景是否覆盖需求，然后运行测试验证代码行为。
9. 手动调试与验证： 运行程序，手动操作，结合 console.log 或调试器（可让 AI 辅助使用）观察执行流程和变量值。
10. 利用工具： 运行 Linter/Formatter 检查代码规范和基础错误。
11. 对比学习： 让 AI 提供相关库/函数的官方文档链接，对比示例代码。
12. 逻辑审查： 从 PRD 需求出发，在高层次上判断代码逻辑是否合理。
13. AI 辅助重构与优化： 对于已有的或 AI 生成的初步代码，让 AI 辅助进行重构以提高可读性、性能（需谨慎评估建议）或应用特定设计模式。
14. AI 辅助调试： 遇到 Bug 时，将错误信息、相关代码片段提供给 AI，请求分析原因和修复建议。
15. 创建/更新模块文档： 在开发过程中，及时在对应模块的 README.md 或 _docs/ 中记录重要的设计决策、复杂逻辑解释或注意事项。可让 AI 辅助生成初稿。
16. 版本控制: 每次完成一个小功能或重要修改后，使用 Git 提交代码。
17. 全程遵循 .cursor-guidelines.md 第 3.3 节“编码与实现”的详细规范。

（4）主要产出与流向 (Output & Flow):

1. 产出物是位于 src/ 目录下的可工作的源代码、相关的单元测试代码、以及更新后的模块级文档。
2. 开发完成的功能模块将进入下一阶段的测试与质量保证 (Stage 6)。

(注：此阶段没有单一的核心 Prompt，而是根据具体任务（生成、重构、调试、解释、测试等）使用不同的、具体的指令与 AI 交互。)

6、测试与质量保证 (Testing & QA):

（1）目标 (Goal):

系统性地验证已开发的功能是否符合 PRD 定义的需求和验收标准，确保软件质量，发现并报告 Bug，为最终部署发布提供信心。

（2）核心输入 (Input):

开发完成的功能代码 (src/)，PRD 文档 (docs/PRD.md，特别是验收标准)，TDD/架构文档（了解组件交互）。

（3）关键活动与 AI 协作 （Key Activities & AI Collaboration）：

1. AI 角色是**“测试用例设计师”、“测试代码生成器”、“初步缺陷分析师”**。
2. 执行已有测试: 运行开发阶段编写的单元测试和集成测试。
3. AI 辅助生成测试用例:
4. 基于 PRD 验收标准或代码逻辑，让 AI 建议更全面的测试场景（包括正常、异常、边界情况）。
5. 让 AI 将这些场景转化为具体的单元测试代码 (使用 Jest, Pytest 等) 或集成测试/端到端测试的步骤大纲或代码框架 (使用 Cypress, Playwright, Supertest 等)。参考之前提供的“AI 辅助测试”的 Prompt 示例。
6. AI 辅助生成测试数据: 让 AI 根据需要生成符合特定格式的 Mock 数据或测试账户。
7. 开发者手动探索性测试: 模拟真实用户场景，进行全面的手动测试，特别关注用户体验、易用性和 PRD 未明确覆盖的边缘情况。这是 AI 难以替代的关键环节。
8. Bug 管理: 发现 Bug 后，记录清晰的 Bug报告（问题描述、复现步骤、预期与实际结果）。
9. AI 辅助 Bug 分析: 对于难以定位的 Bug，可以将 Bug 报告信息和相关代码提供给 AI，请求初步的原因分析或调试方向建议。
10. 交互需遵循 .cursor-guidelines.md 规范。

（4）主要产出与流向 (Output & Flow):

1. 产出物是测试报告（或测试执行结果）、Bug 列表。
2. 发现的 Bug 需要返回到开发与迭代 (Stage 5) 进行修复，形成“开发-测试”的循环。
3. 当主要功能通过测试，达到发布标准后，流程进入下一阶段部署 (Stage 7)。

(注：此阶段同样是使用多种具体 Prompt 与 AI 交互，辅助测试用例设计、代码生成和问题分析。)

7、部署 (Deployment):

（1）目标 (Goal): 将通过测试的应用程序代码，安全、可靠地发布到目标环境（如 Vercel, Netlify, 或其他平台），让最终用户可以访问。

（2）核心输入 (Input): 经过测试的稳定代码 (src/)，TDD 中确定的部署策略和平台 (docs/architecture/*)，可能的配置文件或环境变量。

（3）关键活动与 AI 协作 （Key Activities & AI Collaboration）：

1. AI 角色是**“部署配置助手”、“脚本生成器”**。
2. 根据 TDD 策略进行配置: 参照 TDD 中推荐的部署平台（如 Vercel, Netlify）和流程进行操作。
3. AI 辅助生成配置文件:
4. 如果使用 Vercel/Netlify 等平台，通常配置较少。但可以询问 AI：“我的项目使用 [框架名]，部署到 Vercel 需要特别配置vercel.json文件吗？如果需要，请给一个基础配置示例。”
5. 如果需要构建步骤，可以让 AI 生成 package.json 中的 build 脚本。
6. 如果（尽管不推荐新手）需要容器化，可以让 AI 生成 Dockerfile 或 docker-compose.yml 的基础配置。
7. AI 辅助生成 CI/CD 脚本:
8. 如果希望实现自动化部署（例如 Git push 后自动部署），可以让 AI 生成基础的 CI/CD 配置文件（如 GitHub Actions 的 .github/workflows/deploy.yml，GitLab CI 的 .gitlab-ci.yml），并根据所选平台（Vercel CLI, Netlify CLI 等）定制部署命令。
9. Prompt 示例: "请为我的 [前端框架/Node.js] 项目编写一个 GitHub Actions 配置文件，实现在 main 分支 push 时，自动构建并通过 Vercel CLI 部署到生产环境。"
10. 开发者执行部署: 开发者负责连接 Git 仓库到部署平台、设置环境变量、触发首次部署，并监控部署过程和结果。
11. 交互需遵循 .cursor-guidelines.md 规范。

（4）主要产出与流向 (Output & Flow):

1. 产出物是成功部署并在线上运行的应用程序。相关的部署配置、脚本应纳入版本控制。部署步骤和注意事项应更新到 docs/deployment.md。
2. 部署成功后，项目进入维护与迭代 (Stage 8) 阶段。

8、维护与迭代 (Maintenance & Iteration):

（1）目标 (Goal): 保障线上应用的稳定运行，及时修复用户反馈或监控发现的 Bug，并根据新的需求或用户反馈，持续地对产品进行小范围的功能改进或迭代。

（2）核心输入 (Input): 线上运行的应用、用户反馈、监控数据、Bug 报告、新的小需求。

（3）关键活动与 AI 协作 （Key Activities & AI Collaboration）：

1. AI 角色回归到**“编码助手”、“调试伙伴”、“文档助理”**。
2. 监控与告警: (通常由部署平台或专门工具负责，AI 辅助较少，但可咨询相关设置)。
3. Bug 修复:
4. 利用 AI 分析 Bug 报告和相关代码，快速定位问题。
5. 让 AI 辅助生成修复代码，并严格审查、测试。
6. 修复后，更新相关文档和测试用例。
7. 小功能迭代: 对于小需求或改进，可以快速重复 “Mini-PRD -> Mini-TDD (如果需要) -> 开发 -> 测试 -> 部署” 的流程，每个环节都可借助 AI 提效。
8. 文档更新: 无论是 Bug 修复还是功能迭代，都要及时更新受影响的代码注释、模块 README、PRD (如果需求有变)、用户手册等。可让 AI 辅助完成。
9. 对于重大的新功能或架构调整: 应返回到流程的前期阶段（如 MRD 或 PRD 或 TDD），进行更全面的需求分析、设计和规划，而不是在维护阶段直接进行大的改动。
10. 交互需遵循 .cursor-guidelines.md 规范。

（4）主要产出与流向 (Output & Flow):

1. 产出物是持续更新、更稳定、功能更完善的应用程序和同步的文档。
2. 这是一个持续循环的过程，直到项目生命周期结束，或者被新的、更大的迭代需求中断并返回早期阶段。

结语

读到这里，你手中握有的不仅是一份文档，更是一套旨在应对 AI 编程不确定性、提升个人项目落地成功率的实战框架。

它提供了一套从 0 到 1 的结构化流程、可执行的 AI 协作规范 (.cursor-guidelines.md) 和或许能激发你灵感的 Prompt 模板。我们希望，用好它，能让你更有底气地驾驭 AI，将时间和精力聚焦于你最擅长的产品洞察与创新本身。

当然，这只是我们基于当前实践梳理出的 v1.0。AI 技术日新月异，最佳实践也在不断演化，这份指南本身也需要拥抱变化，持续迭代和完善。这份 v1.0 的指南，是基于当前实践的一份阶段性总结，希望能为你提供一个有价值的起点和参照。当然自己也会持续迭代，期待再次见面