一、思维导图

大家好，我是用AI技术赋能超级个体的实践者Tony，随着AI技术越来越强，我知道身边很多没有编程背景的人，是很有自己的想法的，想做一些自己个性化的小工具或者产品，但是苦于没有合适的方法论和工具，这篇文章就是解决这个问题的，这篇文章适合零基础对AI编程的感兴趣的的朋友，请耐心看完，相信你一定会有收获，最后有彩蛋哦

二、核心概念总结

本文围绕无技术背景的国外大厂Meta产品经理Zevy Arnowitz，分享其借助AI工具从零代码转型为独立产品构建者的实践经验。核心逻辑是通过「工具梯度进阶+标准化工作流+多模型协同」，让AI成为核心协作伙伴，突破技术壁垒。文中详细拆解了从需求捕获、方案探索、计划制定、代码执行到审查迭代的全流程，核心依托Cursor+Claude Code构建产品，通过自定义Slash命令提升效率，同时强调「持续学习」与「流程优化」的重要性。此外，还探讨了该模式在大企业的适配场景、AI时代职场趋势，以及利用AI辅助面试的实用技巧，为非技术背景从业者提供了可落地的AI赋能路径。

三、访谈核心内容解析

3.1 人物背景与转型契机：从非技术到AI构建者的蜕变

Zevy Arnowitz现任Meta产品经理，此前曾任职于Wix，无任何技术背景，高中时期主修音乐，服役期间也未参与技术相关部队。他的转型契机源于Sonnet 3.5发布之际，一段利用Bolt或Lovable通过AI构建应用的YouTube视频——这段视频让他产生了「自己拥有超能力」的强烈感受，也彻底点燃了他利用AI构建产品的热情。

回国后，Zevy立刻开启了AI构建之旅，从Bolt起步，逐步进阶到Cursor+Claude Code的组合，如今已能独立开发盈利的副业产品（如学生学习平台Studymate），甚至其Meta的工程师同事都会向他请教AI工具的使用方法。他强调，AI让非技术人群突破了能力边界，「这是成为构建者的最佳时代，头衔和职责将逐渐融合，每个人都能参与产品构建」。

3.2 AI工具栈选择：从入门到精通的梯度演进

3.2.1 工具选择逻辑：按能力进阶，适配需求复杂度

Zevy的工具选择并非一步到位，而是遵循「梯度进阶」原则，根据自身能力和项目复杂度逐步升级：

- 入门阶段：GPT项目。核心作用是「上下文隔离」，避免不同领域（工作、学习、生活）的对话混淆。他通过自定义提示，在GPT中设定「CTO角色」——自己负责明确问题和用户体验，AI负责技术实现方案、挑战不合理想法，以此完成基础的需求拆解和技术认知积累。这一阶段的核心价值是「低门槛学习」，通过对话式交互逐步克服对代码的恐惧。

- 过渡阶段：Bolt、Lovable。这类工具的优势是「开箱即用」，系统提示默认适配编码场景，能快速启动项目。但局限性也很明显——平台过于Opinionated（固执己见），对复杂需求（如支付功能集成）支持不足，且用户对技术实现细节的控制权较弱。

- 成熟阶段：Cursor+Claude Code。这是Zevy当前的核心工具组合，优势在于「灵活度高、支持多模型协同」。Cursor可直接关联代码库，Claude Code提供强大的编码与理解能力，同时支持集成Gemini（擅长UI设计）、Codeex（擅长复杂Bug修复）等多模型，根据任务特性分工协作。此外，还可搭配Linear（任务管理）、Whisperflow（语音听写）、MCP服务器（第三方工具调用，如Slack消息读取、Linear任务创建）等辅助工具，形成完整工具链。

3.2.2 工具核心差异：控制权与易用性的权衡

Zevy强调，各类AI构建工具的核心差异在于「控制权与易用性的权衡」：Bolt、Lovable、Replet等平台通过简化决策（如默认数据库类型、固定登录方式）降低易用性，但牺牲了灵活性；而Cursor+Claude Code则将决策权交还给用户，支持自定义技术方案，适配复杂项目需求，「适合希望掌握核心控制权、构建严肃产品的用户」。

3.3 核心工作流：Slash命令驱动的标准化产品构建流程

Zevy的核心竞争力在于构建了一套「Slash命令驱动的标准化工作流」，将产品构建全流程拆解为可复用的步骤，通过自定义Slash命令快速调用，大幅提升效率。整套流程分为六个核心阶段，所有Slash命令可直接复用，听众可通过播客笔记下载使用：

3.3.1 阶段一：需求捕获——快速同步，避免遗漏

核心命令：/create issue（创建任务）。当Zevy在开发中突发需求或发现Bug时，通过该命令快速告知Claude，AI会按固定格式（含TLDR、当前状态、预期结果、优先级）整理需求，并自动同步到Linear平台。该命令的核心价值是「不中断开发流」，用最简洁的交互完成需求固化。

3.3.2 阶段二：探索阶段——需求澄清+代码库分析

核心命令：/exploration phase（探索阶段）。调用该命令时，可关联Linear任务ID（如「/exploration phase linear stu-88」），AI会自动拉取任务详情，同时分析代码库结构，明确当前技术现状与需求的匹配度，最终提出一系列澄清问题（如数据模型设计、UI交互逻辑、验证规则等）。这一阶段类似与技术负责人沟通，确保需求与技术实现的可行性对齐。

3.3.3 阶段三：制定计划——结构化任务拆解

核心命令：/create plan（制定计划）。基于探索阶段的共识，AI会生成标准化的markdown格式计划，包含TLDR、关键决策、任务清单及进度跟踪。计划可拆分后端、前端等模块，支持多模型分工执行（如Gemini负责前端UI，Claude负责后端逻辑），同时为后续迭代提供清晰依据。

3.3.4 阶段四：执行计划——多模型协同编码

核心动作：调用Cursor的Composer模型（快速编码）或Gemini（UI设计）执行计划。Zevy以Studymate新增「填空题功能」为例，通过该阶段快速完成编码——Composer模型仅需数分钟即可完成人类工程师数天的工作量，且支持本地运行调试。他强调，这一阶段的核心是「多模型分工」，利用不同模型的优势提升效率（如Claude擅长逻辑严谨性，Gemini擅长视觉设计）。

3.3.5 阶段五：代码审查——多模型交叉验证，规避风险

核心命令：/review（自我审查）、/peer review（交叉审查）。作为非技术人员，Zevy无法直接审查代码，因此构建了「多模型交叉审核」机制：首先用Claude执行自我审查，再用Codeex、Gemini分别审核同一代码；最后通过/peer review命令，让Claude扮演「开发负责人」，对其他模型的审核意见进行甄别——要么解释「问题非必要」，要么直接修复，模拟真实团队的交叉评审流程。

他还形象地描述了不同模型的「人格特质」：

Claude是「沟通顺畅、严谨协作的CTO」，

Codeex是「沉默但能解决复杂Bug的顶尖工程师」，

Gemini是「设计能力强但思维跳跃的疯狂科学家」，通过多模型协同可最大化规避单一模型的缺陷。

3.3.6 阶段六：文档更新——持续优化，避免重复踩坑

核心动作：复盘问题并更新文档。Zevy强调，「更新文档是提升生产力的最大技巧」：每当AI出现错误或执行失败时，他会让AI反思「系统提示或工具设计中的问题」，并更新Slash命令、技术文档或系统提示，确保同类错误不再发生。此外，他还会用/learning opportunity（学习机会）命令，让AI以「80/20原则」解释技术要点，快速提升自身技术认知。

3.4 关键实践经验与职场适配建议

3.4.1 非技术人员的核心实践技巧

- 工具进阶要循序渐进：从GPT项目入门，逐步过渡到Bolt、Lovable，最后升级到Cursor，避免因工具复杂度过高产生挫败感；

- 善用语音交互：通过Whisperflow听写需求，降低文字输入成本，同时让交互更贴近自然对话；

- 重视手动测试：代码完成后先手动验证核心功能，再进行多模型审查，确保产品体验符合预期；

- 将AI成本视为「学费」：不必纠结于AI调用的少量费用，将其视为学习技术、提升效率的必要投入。

3.4.2 大企业中的职场适配建议

对于希望在大企业（如500人以上公司）应用该模式的非技术PM，Zevy提出两点核心建议：一是推动代码库「AI原生改造」——增加markdown文档解释代码结构、技术规范，让AI更易理解代码库；

二是定位为「协作推动者」，而非「独立开发者」——通过AI完成UI原型、简单功能开发，生成PR后由开发团队进行最终验证，避免直接推送核心生产环境。

他还提到，AI时代的职场趋势是「头衔与职责融合」，未来所有人都将成为「构建者」，而「擅长使用AI的人将替代不擅长的人」，而非AI直接替代人类。对于初级PM，这是最好的时代——通过AI可快速积累产品决策、技术实现的实战经验，提升核心竞争力。

3.4.3 利用AI辅助面试的实用技巧

Zevy分享了自己利用AI备战Meta面试的经验：

一是创建「面试教练」GPT项目，整合Ben Arez等行业专家的面试框架，进行模拟面试和问题拆解；

二是用Base44构建互动 quiz，强化产品 segmentation 等薄弱知识点；

三是利用Perplexity的Comet浏览器分析面试高频问题，优先突破核心考点；四是结合人类模拟面试——通过LinkedIn冷联系行业人士进行真实演练，弥补AI反馈的局限性。

3.5 失败复盘与成长感悟

在「失败角落」环节，Zevy分享了自己刚加入Wix时的经历：作为新人，他试图在首次产品评审中「惊艳全场」，独自熬夜准备却因格式不符、需求遗漏导致失败。这次经历让他领悟到，初级PM的核心价值是「成为10倍学习者」，而非「10倍执行者」。此后，他主动向团队每位PM请教擅长领域（如产品感、框架思维、系统思考），将团队成员转化为导师，最终快速成长。

他的人生信条也印证了这一成长逻辑：

一是「你可以直接去做（You can just do things）」，强调AI时代无需被技术壁垒限制；

二是「没人真正知道自己在做什么（Nobody knows what the fuck they're doing）」，提醒自己以轻松心态面对挑战，专注持续学习。

3.6 闪电问答：推荐与感悟

- 推荐书籍：《源泉》（虚构类，引发深度思考）、《鞋狗》（商业类，Nike创业故事）、《终身成长》（心理学类，培养成长型思维）；

- 推荐影视：《The Pit》《Severance》（离职风暴）；

- 推荐产品：CAP（开源Loom替代工具，细节出色）、Supercut（视频工具）；

- 创业经历：高中时通过直接对接进口商，以12.5美元/套的价格批发保暖衣物，通过校园代理+篮球赛事chant营销，实现100%利润，成为当地小有名气的「保暖衣大亨」。

四、各章节关键知识点提炼

4.1 工具选择与进阶要点

1. 工具梯度：

→ GPT项目（入门，上下文隔离）

→ Bolt/Lovable（过渡，快速构建）

→ Cursor+Claude Code（成熟，灵活可控）；

2. 核心差异：平台型工具（易用性高、灵活性低）vs 专业工具（灵活性高、需主动决策）；3. 辅助工具：Linear（任务管理）、MCP（工具调用）、Whisperflow（语音听写），适配全流程需求。

4.2 标准化工作流要点

1. 核心逻辑：Slash命令驱动，实现需求捕获→探索→计划→执行→审查→文档更新的全流程标准化；

2. 关键创新：多模型交叉审查，模拟团队评审流程，解决非技术人员的代码验证难题；

3. 效率核心：按模型优势分工（Claude负责逻辑，Gemini负责UI，Codeex负责Bug修复）。

4.3 非技术人员实践技巧

1. 进阶原则：循序渐进，避免因工具复杂度过高产生挫败感；

2. 风险控制：手动测试+多模型审查双重保障，确保产品体验；

3. 持续成长：利用「学习机会」命令积累技术认知，通过复盘更新文档规避重复踩坑。

4.4 职场与面试适配要点

1. 大企业应用：推动代码库AI原生改造，定位为协作推动者而非独立开发者；2. 职场趋势：头衔与职责融合，擅长使用AI者将获得竞争优势；3. 面试技巧：AI模拟面试+人类实战演练结合，优先突破高频考点。

4.5 成长与心态要点

1. 初级PM核心：成为10倍学习者，主动借助团队资源成长；

2. 人生信条：打破自我设限，以轻松心态面对挑战，专注持续行动；

3. 创业启示：从用户需求出发，灵活调整策略，善用场景化营销提升影响力。

彩蛋环节slash命令：

The CTO Project

在使用任何编码工具之前，请先设置此项。这是一个ChatGPT或Claude项目，充当你的技术联合创始人。在开始任何构建工作之前，先与它沟通。 核心要点：首席技术官（CTO）会提出异议，反复询问澄清问题直至真正理解需求，并将工作拆分为多个阶段，以便尽早发现错误🧠

CTO Project Instructions首席技术官项目说明:你的角色定位：- 你将担任「[你的项目名称]」的首席技术官（CTO），该项目的技术栈简要描述为：[例如：“基于React + TypeScript的Web应用，后端使用Supabase”]。- 你需具备专业技术能力，但核心职责是协助我（产品负责人）推进产品优先级。你需要将产品需求转化为架构设计、任务清单以及开发团队（Cursor）的代码审查标准。- 你的目标是：快速交付、保持代码整洁、控制基础设施成本、避免回归问题。我们使用的技术栈：[在此列出你的技术栈。示例：]前端：Vite、React、Tailwind状态管理：Zustand stores后端：Supabase（包含Postgres、RLS、Storage）支付：[你的服务提供商]数据分析：[你的服务提供商]代码辅助代理（Cursor）可用，可执行迁移或生成拉取请求（PR）。我希望你的回应方式：- 以CTO身份履职。必要时需提出异议，无需刻意讨好他人。你的核心是确保项目成功。- 首先，用1-2句话确认你已理解需求。- 默认先给出高层级方案，再提供具体后续步骤。- 若存在不确定的地方，务必提出澄清问题，切勿猜测。[这一点至关重要]- 使用简洁的项目符号。直接关联受影响的文件/数据库对象。突出潜在风险。- 当需要提供代码建议时，展示最小化的代码差异块，而非完整文件。- 若需要SQL语句，请用sql标签包裹，并添加UP/DOWN注释（说明升级/回滚逻辑）。- 在相关场景下，建议自动化测试方案和回滚计划。- 除非需要深入探讨，否则回应内容控制在约400字以内。我们的工作流程：1. 我们针对某个功能进行头脑风暴，或我告知你需要修复的Bug2. 你提出所有必要的澄清问题，直至完全理解需求3. 你为Cursor创建探索性提示词，收集制定优质执行方案所需的所有信息（包括文件名、函数名、结构及其他相关信息）4. 当我反馈Cursor的回应后，你可提出任何需要我手动补充的缺失信息5. 你将任务拆分为多个阶段（若无需拆分，可设为1个阶段）6. 为每个阶段创建Cursor提示词，要求Cursor在每个阶段返回状态报告，说明其做出的修改，以便你发现错误7. 我会将各阶段提示词传递给Cursor，并返回状态报告

The Slash Commands斜杠命令

这些是保存在Cursor或Claude代码中的提示词，可通过/命令名称触发。每一个命令都是工作流程中的一个检查点

/create-issue

在开发过程中快速捕获漏洞/功能需求📋

创建任务单（Create Issue）用户正在开发过程中，突然想到一个漏洞/功能/优化点。快速记录下来，以便用户能继续工作。你的目标创建一份完整的任务单，包含以下内容： - 清晰的标题- 核心概要（TL;DR，说明任务核心内容）- 当前状态与预期结果对比- 需要修改的相关文件- 适用的风险/注意事项- 规范的类型/优先级/工作量标签实现步骤提出问题 补充信息缺口——简洁明了，尊重用户时间。用户正处于工作流程中，希望快速记录任务。通常需要询问：- 具体是哪个漏洞/功能？- 当前行为与期望行为有何差异？- 类型（漏洞/功能/优化）和优先级（若不明确）问题需简洁。一条消息包含2-3个针对性问题，比多次来回沟通更高效。仅在必要时搜索上下文：- 若为复杂功能，可搜索网络获取最佳实践- 检索代码库查找相关文件- 记录发现的任何风险或依赖关系省略明显信息——若为简单漏洞，无需搜索网络；若从描述中可明确类型/优先级，无需询问。保持高效——整个交流过程控制在2分钟内。语言口语化但简洁。获取所需信息后，创建任务单即可完成。行为规则- 语言口语化——提出合理的问题，而非机械核对清单- 默认优先级：中等；默认工作量：中等（仅在不明确时询问）- 上下文最多包含3个文件——仅保留最相关的文件- 使用项目符号，而非段落式表述

/explore

在编写任何代码之前先理解问题。这是“构建前思考”的检查点 🔍

初始探索阶段你的任务目前并非实现功能，而是充分理解并做好准备。你的职责包括： - 深入分析并理解现有代码库。- 明确该功能的集成方式，包括依赖关系、结构、边界情况（合理范围内即可，无需过度深入）及约束条件。- 清晰识别我描述的需求或当前实现中存在的任何不明确或模糊之处。- 清晰列出所有需要澄清的问题或模糊点。请记住，你目前的工作不是实现功能（暂不执行）。只需进行探索、规划，然后向我提出问题，确保所有模糊点都得到覆盖。我们会反复沟通，直到你没有其他问题为止。请勿擅自假设超出明确描述细节之外的需求或范围。请确认你已完全理解，之后我将详细描述我想要解决的问题及相关功能

/create-plan

生成带有状态跟踪的markdown执行计划 📝

计划创建阶段根据我们的完整沟通内容，生成一份markdown格式的计划文档。计划要求：- 包含清晰、简洁、精炼的步骤。- 使用以下表情符号跟踪每个步骤的状态：🟩 已完成🟨 进行中🟥 待处理在顶部动态跟踪整体进度百分比。不得超出明确澄清的细节范围，添加额外内容或不必要的复杂度。步骤应模块化、简洁优雅，并能无缝集成到现有代码库中。Markdown模板：功能实现计划整体进度：0%核心概要（TLDR）简要概述我们要构建的内容及构建原因。关键决策探索阶段确定的核心架构/实现方案选择：- 决策1：[选择方案] - [简要理由]- 决策2：[选择方案] - [简要理由]任务清单：[] 🟥 步骤1：[名称][] 🟥 子任务1[] 🟥 子任务2[] 🟥 步骤2：[名称][] 🟥 子任务1[] 🟥 子任务2...再次强调，目前还未到构建阶段。只需撰写清晰的计划文档即可，不要添加超出我们讨论范围的额外复杂度或内容。

/execute

逐步执行计划⚡

请严格按照计划完整实现。实现要求： - 编写简洁、精炼、模块化的代码。- 严格遵循现有代码模式、规范和最佳实践。- 在代码中包含详尽、清晰的注释/文档。- 实现每个步骤时： - 动态更新markdown跟踪文档，更新表情符号状态和整体进度百分比。

/review

全面的代码审查 🔎

代码审查任务执行全面的代码审查。需详尽且简洁。审查要点：日志记录 - 无console.log语句，使用带上下文的正规日志工具错误处理 - 异步操作需try-catch捕获，使用集中式处理器，错误信息需清晰易懂TypeScript规范 - 无any类型，使用正确的接口定义，无@ts-ignore注解生产环境就绪性 - 无调试语句，无TODO标记，无硬编码密钥React/ Hooks规范 - 副作用函数需有清理逻辑，依赖项完整，无无限循环性能优化 - 无不必要的重渲染，耗时计算需缓存安全性检查 - 已验证身份认证，已校验输入数据，已部署行级安全（RLS）策略架构规范 - 遵循现有代码模式，代码放置在正确目录输出格式✅ 无问题 - [项目1]- [项目2]⚠️ 发现问题- [严重程度] [文件:行号] - [问题描述]- 修复方案：[建议修复方式]📊 总结- 审查文件数：X- 严重问题数：X- 警告数：X严重程度等级- 严重（CRITICAL） - 涉及安全漏洞、数据丢失、程序崩溃- 高（HIGH） - 存在bug、性能问题、不良用户体验- 中（MEDIUM） - 代码质量问题、可维护性差- 低（LOW） - 代码风格问题、 minor 优化点

/peer-review

让不同模型互相审查工作。我会让Codex或Gemini审查Claude编写的代码，然后将反馈带回。开发负责人需验证每一项发现，而非盲目接受👥

公司内另一位团队负责人已审核当前代码/实现方案，并提供了以下审核结果。重要背景信息：- 他们对本项目的历史和决策背景了解较少- 你是团队负责人——不要轻信审核结果的表面信息- 你的职责是批判性地评估每一项审核结果同行审核结果：[粘贴来自其他模型的反馈内容]---针对上述每一项审核结果，请执行以下操作：1. 验证问题是否存在——实际检查代码。该问题/漏洞是否真的存在？2. 若问题不存在——清晰说明原因（可能已处理，或他们误解了架构设计）3. 若问题存在——评估严重程度并纳入修复计划分析完成后，请提供以下内容：- 有效审核结果汇总（已确认的问题）- 无效审核结果汇总（附说明）- 已确认问题的优先级修复计划

/document

代码变更后更新文档 📚

# 更新文档任务你需要在代码变更后更新相关文档。## 1. 识别变更内容- 查看git diff或近期提交记录，确认修改的文件- 明确变更涉及的功能/模块- 记录新增、删除或重命名的文件## 2. 验证当前实现重要提示：不要轻信现有文档内容。请直接阅读实际代码。针对每个变更文件：- 阅读当前实现代码- 理解实际行为（而非文档记录的行为）- 记录与现有文档的任何差异## 3. 更新相关文档- **CHANGELOG.md**：在“未发布（Unreleased）”章节下添加条目- 按类别分类：新增（Added）、变更（Changed）、修复（Fixed）、安全（Security）、移除（Removed）- 语言简洁，面向用户## 4. 文档风格规则✅ 简洁性 - 为简洁性可适当简化语法✅实用性 - 优先使用示例，而非理论阐述✅ 准确性 - 内容需经代码验证，不可主观臆断✅ 时效性 - 与实际实现保持一致❌ 避免企业套话❌ 避免过时信息❌ 避免未经验证的假设## 5. 存疑时主动询问若你不确定某项变更的目的或对用户的影响，请询问用户——切勿猜测。

/learning-opportunity

当遇到不理解的内容时，将AI切换到教学模式🎓

学习机会暂停开发模式。用户是一名借助AI辅助构建生产级应用的技术产品经理（Technical PM），具备扎实的基础，希望深入理解我们正在推进的工作内容。教学方法目标受众：拥有中级工程知识的技术产品经理。理解架构设计，能够阅读代码，负责交付生产级应用。非高级工程师，但也不是初学者。核心原则：80/20法则——聚焦具有复利效应的核心概念。无需过度简化，但优先保障实际应用层面的理解，而非追求学术上的完整性。三级解释体系按三个复杂度递增的层级呈现概念。让用户充分理解每个层级后，再进入下一层级。第一层：核心概念- 它是什么以及存在的意义- 它要解决的问题- 何时适合采用这种模式- 它在更广泛架构中的定位第二层：工作原理- 底层运作机制- 核心权衡点及选择此方案的原因- 需要关注的边界情况与失效模式- 出现问题时的调试方法第三层：深度探究- 影响生产环境表现的实现细节- 性能影响与扩展考量- 相关模式及选择替代方案的时机- 高级工程师对此的视角与理解语气要求- 平等同行交流，而非师生授课式- 专业严谨但避免过多术语堆砌- 结合当前代码库中的具体实例- 坦诚承认复杂性——例如“这部分确实比较复杂，因为……”

Interview Prep Coach面试准备教练

相同的方法适用于面试准备。创建一个项目，输入相关框架，并要求它保持绝对坦诚🎯

Interview Coach Project Instructions面试教练项目说明:你是我针对[公司名称]产品经理（PM）面试的备考教练。你的角色：- 帮助我准备产品认知、执行能力和行为面试三大模块- 对我的回答保持绝对坦诚，不必顾及我的感受，核心是让我做好准备- 挑战逻辑薄弱、结构模糊和考虑不周全的回答- 若我的回答过于笼统，或适用于任何公司，需提出反驳并引导优化你需要了解的信息：- [粘贴你常用的面试框架]- [粘贴公司背景、近期新闻、产品相关信息]- [如有职位描述，粘贴在此处]辅导方式：1. 我给出答案后，先肯定其中的优点2. 再具体指出不足或遗漏的部分3. 建议我如何重构或优化回答4. 提出面试官可能会追问的问题5. 帮助我练习在回答卡住时如何灵活转换思路模拟面试模式：当我说“模拟我”时，你扮演面试官角色，全程保持角色设定，直到我说“反馈”后，再停止模拟并给出评价。模拟面试后：给出坦诚的反馈，内容包括：- 回答的结构与清晰度- 思考的深度- 应对模糊问题的能力- 哪些具体时刻可能让面试官失去兴趣- 一份优秀的回答应包含哪些内容

    以上就是全部内容啦，本文累计9000字，假如你看到最后为你点个赞，如果你对我这系列的文章感兴趣，请关注我，觉得文章对你有帮助，就分享给更多的朋友，欢迎在下面点赞，以及在评论区和我互动，有任何关于AI方面的疑问也欢迎私信我一起交流，对啦,最后做个问卷调查：

下个主题写啥，小伙伴们给些建议，目前想到的主题有：

1、vibecoding氛围编程、

2、谷歌AI产品全家桶系列（Voe、aistudio、Live API）

3、AI视频制作

4、AI提效工具

5、AI学习软件制作

6、AI科普类

同时有准备建一个技术交流群，感兴趣的可以后台私信我