ai studio怎么写prd

今天带大家零到一口喷做一个 ai 产品经理的 p r d 生成的 skill。 首先给大家看一下我用这个 skill 针对于合同文件审查智能体生成的一个 p r d 文件，这个目录我是专门在这个 skill 里面去写进去的， 你可以发现这里的目录的链接是可以点击的跳转到对应的文件。 ai 产品的 p r d 和传统的 p r d 其实是非常不一样的，除了业务背景目标进行分析产品方案以外，大家可以看到详细设计，这边会有 a 证的工作流设计， prom 设计规范，术语模型， 然后非功能需求有一些性能的要求，以及我们讲 ai 产品经理非常重要的关于你产品的整个的评估体系，包括数据评测级和 bad case 分 析和迭代闭环。所以这个 prd 相对于来说是非常非常完整的。比如说这个 ai a 阵的角色的工作流设计， 这个里面会包括四个 a 阵的一个文档解析的 a 阵，这个 a 阵执行它的一个角色以及它需要的信息能力和工具清单其实都是有的。整个的这个合同智能体的 a 阵其实是一个多智能体协调架构，它包括四个 a 阵。 在这个 prd 里面所有的这种流程图都是可以通过 moment 来进行渲染的，非常非常直观。包括这里的持续图，包括所有的 prompt 设计规范，整个的工具调用规范，以及呃， ai 帮我们生成的评估的指标，生成的评估的测试体。整个的 prd 作为初稿来说，基本上六十分肯定是有的，还是需要去进行一些优化，同时把你优化调整的部分去不断的再去完善这个 skill。 给大家看一下我的 skill 文件，之前我也有很多视频跟大家讲了 skill 是 什么，这个里面包括概述使用方法，它的执行的流程，具体的信息，它的设计规范等。 呃，跟大家讲一下我的整个的这个 skill 开发的过程，我是把整个的 skill 开发完了以后，结合 excel 的 插件，让 ai 帮我自动形成了一个这个开发的流程。整体来说我的一点零的这个 skill 分 成四个阶段，第一个是我给到 ai 提供了一个优秀的 p r d 的 文件的样例以及核心模块的一个书写的要求， 同时要求他按照我给他提供的样例帮我去生成这个 p r d 的 呃 skill 的 md 的 文件，同时他创建了个进度管理文件，在第一阶段完成以后，出版本或说槽稿版本的 skill 就 已经开发完成了。这个时候我用出版本的 skill 我给他提供了个新的场景，说你帮我去写一个合同的审查智能提的这么一个 p r d 的 文件，在理解了我的需求以后，跟我写作了以后，基于这个 skill 帮我生成了 p r d 的 文件，然后我对于 p r d 的 文件去进行了一些检查以及校验，告诉他这个 p r d 文件里面哪里还有具体的问题， 跟他写作的过程当中去解决了很多 bug 以及优化的流程。最后基于这个 p r d 的 文件，我跟他写作过程，他在反向的去优化哦他的 skill 文件，直到我们把 p r d 完成了以后，形成了这个一点零版本的 skill， 然后给大家看一下我和他那个开发过程。首先第一句话我会给他发一个 quarry， 就是 我是一个 ai 产品经理，我想 做一个自动化写 p r d 的 skill， 请你参照 color skill 的 结构，帮我开发这个 skill， 并保存在 skill m d 文件当中。然后我就给了他两个参考文件，第一个是我们过往写作的一个优秀的 p r d 的 视例，第二个的话就是一个 ai 产品 p r d 的 核心模块的书写规范，我告诉他，请你参考这两个文件，帮我抽象出这个 p r d 写作 skill。 我 后续的所有的场景都需要附用这个 skill， 他就正在读取这两份 pdf 文件，在这个时候他就已经可以创建这个 skill md 的 文件了，也就是刚给大家展示的这个草稿的这个 skill 文件。第二步我就告诉他，请调用这个 prd 的 skill 文件，帮我写一个合同文件审查智能体的 prd， 我 会基于他生成的 prd 的 结果和他进行写作调整，逐步来完善这个 skill。 所以 在这个过程当中他就跟我交互，最后把这个合同文件审查智能体的 prd 写出来，也就是这份文件。针对于这份 prd 文件，我会发现有几个坑， 第一个坑是一开始他给我的时序图还有流程图都是代码形式的，但是我想要去做格式化呈现，所以我就告诉他，我想调用 mmm 工具来做格式化的呈现，他就给我去做了一些脚本上，以及嗯，帮我去建议我去加哪些插件，我就可以最终实现这样一个格式化的一个效果。同时我要求 他帮我把这条规则补充进 p r d skill 中，他就帮我去更新我的 skill 文件，包括说一开始他帮我做出的这个时序图和流程图，有一些色块和字体是看不清楚的，比如说像这种我就直接口喷告诉他需求他就可以给我改，对，改成这样 其实是非常快的。当我的 skill 开发完成了以后，我又艾特他，我当时给到他的一个对应的核心模块及规范，让他帮我 review 一下他现在生成的这个 skill 是 否已经完全的从这个核心模块规范文件当中抽象画出 p r d 写作的规范。在他 review 的 过程当中，他继续的帮我补充了一些信息，最后我将这个 skill 文件保存为一点零的版本， 同时告诉他帮我把这个 skill 研发的过程帮我总结一下。同时因为开发这个 skill 文件踩过了很多坑，所以我让他把这些经验教训保存在一个叫做 lessons md 的 这个文件当中。开发过程当中踩过了坑，后续的话不希望呃在其他的项目当中去复现。他给我形成的这个 lessons md 就是 开发经验教训与避坑指南，其实就在这里， 包括 moment 的 开发的问题，我看不清的问题等等各种各样的问题吧。所以也给大家一个启发，就是可以及时的和 ai 交流一些开发当中的坑，然后及时的去保存在这个经验教训的文档当中，你的 ai 会越用越聪明。我检查过程当中，我还发现他一看给我的目录只是文字的形式， 我觉得上下拖拉拽是非常难的，而且我很难定位，所以我又让他帮我去在目录这里去增加一个定位的超链接，让我对应点击就可以到对应的这个章节的内容，方便我去阅览我的 pdf 文件当中去 整个的 skill 的 研发过程当中，自己是没有写一行代码的，这种 skill 的 创建的过程，以及我们在研发过程当中和 ai 的 交互，包括经任教训的总结，以及整个开发流程的回顾， 以及给到 ai 相关的一些参考的信息，从具体的事例当中去抽象出一些规则，让 ai 自己去学习的这种方法是我们自己在 coding 的 一个可以积累的经验，如果你有兴趣的话，可以自己动手去试一试。

很多人在用外部抠钉开发产品时，都可能遇到一个问题， ai 总不听话，要么生成的功能不是自己想要，要么一大堆 bug 根本跑不通，要么改了很多次都改不到位。这类问题真正的原因往往在于我们的产品需求没有被描述清楚。 换句话说，我们缺少一份产品需求文档。 prd 这节课，我们就从源头上来解决这个问题。大家好，欢迎来到人人都能学会的 ai 公开课第二季， 从想法到落地，从 ai 工具到实践应用，带你把 ai 变成解决问题甚至创造收入的超能力。本课程由零代码创作社区海思内的响指联合 ai 生活实验室团队共同打造，大家先点个关注和收藏吧，下次不迷路。 产品需求文档， product requirement document 简称 prd， 它的作用是描述清楚产品是给谁用，能实现什么功能，怎么用，长什么样，做到什么程度算完成。简单来说， prd 是 产品清晰完整的施工图。 在传统的产品团队里， prd 的 作用是让产品经理、设计、开发、测试，对我们究竟做什么，形成统一理解，用来对其信息，避免产品开发过程中走歪。 在外部抠定的场景下，它的作用是让 ai 和我们的需求对齐，在写代码时不跑偏，能大大减少后续的调试和返工。如果不写 prd， ai 会自动补全你没说清楚的部分，但补全用的是它的平均经验，而不是你真实需求。 ai 不知道哪些功能必须有哪些明确，不做哪些以后再说，所以可能会在写代码时乱写一通。 比如，如果我们直接把一句话丢给 ai， 帮我做一个自动整理截图并生成笔记的应用。 ai 通常会给出这样的结果，功能列表看上去非常多，包含 ocr、 ai 接口、云同步、社交分享等内容， 但很可能全是 bug， 一个都用不了。而你想要的核心功能反而漏掉了，页面还巨丑无比。 要解决这个问题，我们就需要将需求梳理成清晰的文档，给 ai 明确的边界。我们可以让 ai 提问，帮我们把需求一步步拆清楚，然后形成清晰的 prd。 只需要将这段提示词发给 ai， 我想做一个名为截图速记的产品，用来帮用户自动整理手机里的截图，并且生成可拷锁的笔记。请你扮演资深产品经理，一次只问我一个问题，通过提问引导我共同把产品需求想清楚。 在我回答完所有关键问题后，请你把我们的对话整理成一份产品需求文档。 ai 一 般会从这些问题开始，询问目标用户是谁？回答是例，经常截图学习资料、文章、重点会议内容的上班族和学生用户最核心的痛点是什么？ 截图时觉得这个信息重要，但因为没有及时整理，一周后想找又找不到了，非常烦躁。产品的核心功能逻辑是什么？怎么实现 访问手机截图文件夹自动识别截图内容？对图片打标签并整理成已断摘药， 用于支持用户检测查看。为了实现和验证这一功能，我们还可以写清楚，接入多模态模型 jimmy 二点五 flash， 用来识别图片。在出版功能验证阶段的用户可以指定文件夹，方便测试 用户完整的使用流程是怎样的？用户截图软件自动抓取并整理。用户打开软件搜索、定位原图和笔记，整理后的笔记以怎样的页面呈现？ 可以参考小某书的图文混排页面，让查笔记有刷小某书的感觉。哪些功能在当前阶段暂时不做？ 暂时不做社交分享，不做跨设备同步，不做复杂分类体系？这个问题其实很重要。用最小可行产品原则给 ai 划定范围，别乱生成不必要的内容，让开发过程更聚焦。事实上，梳理 prd 的 过程，其实也是帮助我们把自己的需求真正想清楚的过程。 只有我们自己想清楚自己需要什么，才能更好地指挥 ai， 避免只有一句话的提示词。在对话结束后，我们可以让 ai 把所有信息整理成一份描述清晰的 prd。 它包含了产品背景、目标、用户使用场景、功能范围、流程描述和最小可行产品定义。 有了这些约束，后面所有的 prompt 开发插件、 ui 设计都可以围绕它们展开。我们需要认真一边读这份 p r d， 看 ai 理解的跟你想的是不是一回事，发现不对的地方马上改。现在改 p r d 只需要花五分钟，以后改代码可能要花五个小时。 然后我们可以直接将它扔给 ai， 比如响指 headphone， 让它快速生成一个简单的 demo。 于是有了这个截图数据 demo， 它可以识别图片，并将信息自动整理成小某舒适的图文混排页面。在后面几节课中，我们会学习如何基于一个 demo 一 点点完善它，让它的功能更强大，页面更好看， 并将它封装成 app， 在 app store 中上线。好了，今天课程就到这里。今天作业很简单，选用你在上节课中筛选出的 idea， 参考本节课中的提示词， 让 ai 一 步一步问自己问题，梳理精准产品需求，最终生成 prd。 下节课我们会在软件构架的角度，根据 prd 往下拆解学习精准提示词，持续优化和完善产品，我们下次见。

应用产品经理在意图识别这个节点，他需要产出的需求是什么？就是他的 p r d 文档里面跟开发区审审的时候，他要产出什么，他要写什么， 所以你是没概念的吗？不，不光光说是啊，就五个意图把它定下来好，意图怎么整理的，意图怎么设计的？意图的边界怎么定义的？意图体系怎么设计？技术实践方案是怎么什么 front 是 怎么写的，以及怎么优化的，以及说如果你这个智能客服肯定是支持多轮对话吗？对不对上下文？ 呃，那个叫什么纸带消解，然后意图切换，这些异常的分车情况如何处理的，这些东西实际上都是你的需求嘛？所以这些东西其实都是 prd 的 过程部分，你现在这部分你是缺的，看上去是因为你没有写 prd， 但实际上是因为 你没有深究过里面具体的落地的细节，你不知道每个节点需要 ai， 产品经理实际需要产出什么样的需求，而 prd 它只是一个承载的东西，一个壳，一个结果嘛。 在 prd 里面的，里面的各个节点的内容你一定要门清好，还有对工程优化，还有你这个简历里面说你还有 qa， qa 数据库和文档数据库该怎么样去做问答特别的设计，这些东西都是需要考虑的。还有你的整个的智能客服系统评估体系如何搭建，数据评测以及如何构建，模拟效果评估怎么做？ 你现在二零二四年十月到二零二五年十月做了一年起码做三个版本吧，这三个版本达成的里程碑事件，当时你怎么规划的？以及每个版本叫上一个版本之间模型效果的优化提升是怎么实现的，结果是什么其实都要有， 还能通过面试，还有 a 准 a 准的很多能力，一个是规划的能力， plan 规划你一个用户一个块进来，你怎么样去规划拆解任务？一个是执行动作的能力，然后执行动作，执行动作调接口，不管是方声 calling 的 能力，还是说你引入 m、 c、 p 有 多少工具，每个工具需要去梳理入餐是什么，出餐是什么，因为你要去构造你的方声 call 的 api 的 调用函数， 倒推过来，你的槽位该如何设计，你的槽位跟你的意图识别还有关联的关系，该如何去进行设计，这些东西都是需要去考虑的。就是围绕 agent 的 话，它的评估体系不光光是知识问答这么简单了，你还要去额外的去评估它本身的调用成功率， 草位抽取的准确率，工具函数构造的准确率，对话平均论数这些乱七八糟的评估体系还要加要工具，工具返回以后还有很多很多的正常状态和异常状态，需要去做很多的策略和兜底机制。

我觉得 ai 能力很强，它应该成为我们的工具，但是它不能成为我们逃避的原因。聊一聊 ai 对 产品经理的改变啊。最近比较流行产品使用 ai 来辅助写 prd， 甚至我们认为 prd 已经是一个中间产物了，可能产品 将想法可以直接到达一个产出。我们理想中是这么认为的。呃，但是呢，我看到的是产品经理通过 a s studio 或者 cloud code 等等实现了它 产品所要的效果，然后这个只是代表一个设计和交互，它不能包含逻辑和策略啊。我理解 p r d 的 主要作用呢，就是要说明产品的设计，而产品设计呢？啊，包含了你的 u i 的 设计， 交互的设计，以及产品的逻辑，产品的策略等等。其实 prd 包含了很多的东西，它不仅仅是一个交互的描述，因为其实写 prd 是 一个非常复杂的事情， 对于这种复杂事情的工作呢，没有人愿意做的。所以产品经理认为用 ai 能够不写 prd 或者帮你写 prd 啊，是一个非常好的工作方式， 甚至不写 prd 反而成为 ai 公司的一种时尚。但是这样的话，我们会忽略你的产品的背景、策略、逻辑，而只注重于交互和 ui， 我 认为这样并不会带来更好的结果，甚至是一种资源的浪费。现在产品经理通过 ai 来进行市场调研，来做产品设计， 什么事情都是 ai 帮你做了。那么我们反过来想，其实就不需要产品经理了，因为这些事情并不是产品经理他自己可以做，是每个人都可以做。而十六年前有一本书叫做人人都是产品经理， 之前都以为是一种自嘲，没想到现在变成了现实。所以我们要思考， ai 能力很强，所以我们应该善用 ai 来达成自己的目标，而不是让 ai 成为我们逃避的理由。 文字的出现让很多人都能够识字，但是真正的小说家却没有几个。同理， ai 也是一样的，会用 ai 其实并不是一种能力，能够用好 ai， 让 ai 能够帮助你达成你自己的目的，这样才是难得的能力。

不知道大家在用 ai 开发的时候，有没有发现一个现象，就是 呃开发的过程当中， ai 它其实会生成非常多很标准的文档，就除了我们需求文档以外，各种各样的报告，嗯，各种各样的分析总结，然后可能配套还有一些设计的文档，进度的文档， 而且他做的都非常好，非常标准，嗯，内容也非常丰富。嗯，对于一个项目开发完成之后，这些文档在原来人工协助的开发流程里，他是没有的。嗯，那 这些文件随着 ai 的 开发，他全部都自动升上了，那这些东西有没有价值呢？我现在也没有想特别清楚，但是我觉得直接删除掉好像有点浪费。 所以现在我的做法是 ai 开发完成之后，我会把它生成的这些文档全部上传到呃项目的云空间里去。嗯，这是目前的做法。而且我还有一个认知上的一个转变，嗯，就是关于文档管理的。 文档管理，在没有嗯腾讯文档、飞书这种在线写作的平台之前，其实嗯更多的都是通过 office， 然后在自己的电脑上去做处理，然后通过邮件发送，这时候还是停留在主战场，还是在 pc 端本地的。 对，后来嗯在线写作文档开始，呃出现，大家就把所有的文档处理从本地都搬到了线上，然后突出写作的方便性。 嗯，现在又来到 ai 时代，那 ai 在 ai 的 抠定，它一定是在本地的，因为代码的管理已已经十几年二十年了，它都是在本地做开发，然后通过 get 的 管理，然后 退到代码仓库里，它都是从本地到线上的一个过程。那其实从这个视角来看，嗯， ai 生成的所有的文档也可以，我们也可以把它作为代码来看，对吧？甚至我觉得也不需要在未来上传到呃，写作空间或者在线文档里面去直接也可以 直接 get 到代码仓库里去进行管理，把我们所有的文档和报告都把它当做代码来进行管理，我也觉得也是 ok 的， 不知道大家怎么看？一起在评论区讨论一下吧。

老师，就是企业 bug 支付库这类项目的 pia， 你 能跟我讲一下要怎么写吗？我现在还是有点没概念，那我们来看一下啊，其实写 ai 产品的 pia 啊，尤其是我们现在在做这个企业 bug 支付的项目，核心是要把 ai 的 能力特殊性融入到你业务的产品思维中。 你像你过去做了一些这种传统拓币的项目哈，对业务的逻辑跟系统框架本身就比其他小伙伴有更好的理解，这个是你的优势。那现在只要在这个基础上我们叠加一层 ai 的 思考维度， 我们可以看一下具体呢？首先第一步啊，你要明确这个项目是在你企业现有系统之上叠加 ai 的 能力。比如说我们前面讨论的，你们有一个这个 ai 的 办公系统或者说运营管理的平台，现在要在这个门户上面增加一个智能问答的功能。那你 prd 的 第一部分就要描述清楚产品框架， 你的，你不能就是像以前只写，就是说我要做一个万达机器人，就你上一版交过来的这个作业，而是要说这个 ai 模块怎么跟现有的系统集成，比如说它是作为一个独立的服务接入的，还是通过 api 调用的？ 数据流是怎么打通的，权限要怎么控制，那这个架构层面的细节是要考虑明白的，我们产品经理一开始盘也是底层的，这些东西需要定义清楚。再接下来就是场景上面的定位， 就挖掘更多的场景。你像很多新手小伙伴一上来啊，就是想着说把所有的问题都交给 ai 解决，但其实 ai 是 不可能解决所有问题的，而且这样往往是做不好，所以你要想清楚为什么要先做这个 reg 知识库的场景， 可能是日常这个员工的咨询量太大，对吧？或者新员工培训的效率比较低，或者是啊，你之前说的这个什么售后支持，需要快速查找文档， 有这个时效性的要求，那你要给出决策的逻辑，就比如说基于用户需求调研，业务痛点分析，甚至是数据统计，只有明确了场景的价值，后续的设计才能比较有依据嘛。 然后接着就是你设计这个 agent 的 链路是怎么样的，那这块也是 party 比较核心的部分，你要考虑用户的输入形式，它是重文本还是支持多模态，比如说是不是要上传一些图片啊，语音输入啊这些，那如果是多模态，就涉及到语音的转写，图片解析这些额外处理， 那再接着就是对用户意图识别， query 的 改写，还有路由分发，最后到大模型生成回答。那这里每一个节点其实都可能涉及不同的模型选择，现在呢，已经不是一个模型走天下的状态了，你可能需要针对不同的任务去选不同的模型，就比如说你做意图识别，可以用一些小模型，对吧？ 那生成上面可以用一些大模型工具调用，也有一些专门的这种放生靠的模型，那这些选型的逻辑你要在 p r d 里面体现出来，要说明为什么这么选，是基于成本考量的还是效果，还是说响应速度上面原因要说明白了， 然后再接下来就是，嗯，你比较关心的这个 rag 的 一个构建，对吧？那 rag 系统其实是很基础的，就现在必须要掌握的，也是你作为想转化 ai 产品经理，需要跟算法工程同学深入讨论的地方。所以你这块你要明确知识库的类型， 它是纯粹的这种 qa 知识库呢？还是文档知识库，还是说两者结合的？你像 qa 知识库通常就是问题相似问答案这样的一个结构，处理逻辑跟分块策略都是不一样的。 而这种文档的知识库就需要处理各种格式，比如说你是 word 还是 excel， 还是 ppt 还是 pdf， 甚至是用图片的扫描件，对吧？那你需要梳理文档的来源，更新频率是怎么样的，格式的类型都有哪些，然后 对应的制定分块的策略，然后分块上面呢？其实现在已经不能简单的按这种传统 rag 的 形式去固定字数来切了，这样照回率吧，会比较惨。那你需要考虑是语音定义的这个边界是什么，比如说是按段落分， 标题表格这种等自然边界切分，同时还要考虑是否要添加一些标签去打标，对吧？你像一些文档类型啊，或者他所属的部门啊，还有时间戳啊这些东西，那这些都能相对应的提升召回准确率。另外多媒体的文档 最快的解析也很关键，就是你如果对 pdf 里面的图片扫描件呀，需要有这方面的需求，那就要借助文档解析的能力转成 markdown 的 格式，才能做后续的一些处理，这一些细节都要在 pdf 里面一一去做明确，因为算法和工程师要根据你的设计去做实现的主页逛逛，解锁更多 ai 产品面试求职技能。

今天呢，我们主要来分享一下怎么样跟 jimmy 去聊需求，让他帮我们生成一个呃，相对可以操作的一个 prd。 我 这里呢例举了三个方式，大家可以一起来看一下。第一个就是我跟他讲帮我写一个无限生成的电子练习册生成器的一个 prd 啊，就这样的一句话，我们来看看他帮我生成的是一个怎么样的内容。 现在整一个 ai 的 自然语言理解能力是非常棒的，虽然你只跟他说了一句话，但是他就会去帮你补足很多背后的逻辑，那因为你没有跟他去限定一些背景或者是想要的功能，所以这个边界其实跟你想要的就会差很多。 第一个他告诉我们说这个项目背景主要就是一个传统纸质练习的一个痛点，然后他的目标是生成刚才我跟他讲的一个生成器，然后这里有一个用户画像，这个都是他自己来补足的。 然后在功能需求上面他也拆解了，进行了一个学科的拓展啊。然后后面包括整一个商业模式，他也给我进行了一个设想，然后给到了一个开发路径图。 所以其实如果，嗯，如果你对这个产品没有特殊的想法，你只是希望他给你一些建议的话，你这样一句话就可以了，已经能够达到百分之六七十的效果。第二种方法呢，就是我相对结构化的去跟他聊这个需求，我这里是这样写的，需求 啊，做无限生成的电子练习册生成器，现在需要生成一个 prd 文档。第二个最小的功能点就是本次仅支持单项或多项的一个练习内容的组合， 增加一个一键生成今日作业的功能，支持 a 四纸的打印。第三个我给他限定了一下，这个生成的逻辑是需要利用 ai 算法随机生成的。第四个就是组合排版生成一个 a 四纸并保存，同时我告诉他，我希望有一个商业模式的落地，我们来看看他给我们是怎么生成了一个什么样的内容。 ok， 他 给我们生成了，这里你看他的核心业务流程就跟刚才他自己输出的就会有很大的不同，他会这里会去写入口 配置，生成预览，然后有一个权益的判断和输出，那基本上是我给他的框架啊。然后下面的功能的详细需求就是把我刚才要的几个点详细的拆开，同时他会给到一些页面元素， 所以这一份文档你就会发现跟刚才的一个最大的区别是 ai 它不在自己发散式的去给你一些内容，而是在我的框架里面去进行一个更完整的一个布局。 嗯，所以这个就是我们为什么要结构化的去让 ai 来产生成这个 prd 文档的一个原因。在刚才第二个点的基础上，其实我们还可以更加结构化的一些的表达，然后看看 ai 它会有一些什么特殊的，就是不太一样的地方，这里我给他详细的呃规范了一下它自己需要输出的内容 啊。 prd 里面要需要包含以下四个内容，第一个是产品的概述，第二个是功能的列表，必须要罗列优先级。第三个是 a 四纸的一个呃，交互设计要对小朋友友好。第四个是技术方案的一个建议，最后呢我给他提了一个建议，就是说要用我能看懂的语言，不要太去俗话，这句话主要针对的就是这个技术方案的这个建议了。嗯， 那我们来看看他是怎么给我们生成的吧，他给我们已经生成了，这里跟第二版最大的不同就是我让他帮我生成了一个产品代数，这个就是以后可以帮你一句话去跟别人介绍你这个产品的，包括你的小程序，在提审的时候你也可以把这个话给贴上去。跟我们刚才不太一样的地方，就是功能点的一个裸列描述 啊，他基于我给到他的需求，他给我拆了六个点，其中 p 零的有三个， p 一 两个， p 二一个，这个就帮我们去很好的限定了你的 mvp 版本。 同时呢，它给了一个 a 四值的一个交互建议，非常的详细啊，里面有一个页面布变为题目区和页脚区啊，然后只要拿着这个页面布局，我就可以让它给我生成一个交互的 demo 了。最后呢，它就给了一个技术方案的一个建议，通俗版本，所以整一个，呃，你会发现我们三个不同的问法，你给这 是 gemini 给到你的一个产品文档就是不一样的。好，那我们总结一下，第一个一句话的这种需求描述最适合当你还没有特别的想要一个东西的时候，让 gemini 来告诉你啊，你从中再去获得一些思路。第二种相对结构化的表达， 给 gemini 一个框架，它会在这个框架里面去给到你想要的。那第三种呢，就是你自己已经非常明确的有侧重点啊，功能的优先级 啊，你帮我拆一下交互页面，你帮我设计一下，告诉我这个技术的那个选择啊，研发方案的选择，那他就会根据我的需求来输出了。那第二个版本跟第三个版本我个人认为没有太大的差别啊，只是你的一个侧重点不同而已。 对，所以，嗯，我觉得这样的跟 jama 的 一个沟通，能够极大的帮你在后面的口令里面能够减少很多反复啊，我觉得大家就可以都去用起来。

我们来看一下 ai 是 如何生成一份完整需求说明书的，里面自带业务流程图、操作流程图、系统架构图、持续图， ai 一 键生成。 借助产品经理的 ai 需求分析工作流，从想法到设计文档，再到最终的需求说明书。当你有一个需求可能还比较模糊或不清晰时，可以调用技能让 ai 帮你生成设计文档。 你只需要携带技能，把想法简单的需求描述告诉 ai， 他 就会进行需求分析，过程中会不断与你互动来确认需求，可以看到他会对你的需求拆解，与你进行详细确认。 待需求明确后输出设计文档。我们可以看一下输出的设计文档是否符合要求。设计文档中包含了核心功能、设计业务流程如何流转等内容。 有个设计文档后，直接让 ai 使用技能生成详细的需求说明书。当然，你自己有需求清单或者设计文档的话，也可以直接给 ai 加上技能描述后， ai 会根据设计文档或者你自己的需求清单自动生成需求说明书，等待 ai 执行完成后，打开需求说明书，可以看到里面包含了项目概述、 系统架构菜单、层级业务流程图、功能详细设计功能、持续交互图、页面权限矩阵、非功能需求技术方案等。需求说明书中的流程图都是 ai 自动生成的，确认没问题后直接跟 ai 说导出 word， 导出后打开，你会发现这份需求说明书已经可以直接交付了，里面的流程图也都是直接生成的，整个流程从模糊想法到可交付文档一小时搞定。如果你也想让 ai 帮你写 prd， 记得点赞收藏，下期继续分享产品经理的 ai 实战技巧。

你有没有这样的困扰，产品经理熬夜写 prd、 架构师通消化架构图开发，还在等需求确认？一个需求从想法到上线，要经历无数次沟通、返工、等待。如果有一个工具能让你一个人干四个人的活，而且还能保证质量，你信吗？ 今天我们要给你推荐一款神器，全链制设 for chain design， 它不是普通的 ai 工具，它是你的产品合伙人、架构参谋、测试专家三位一体，覆盖从需求设计到代码的完整链路。智能辅助， 你只需要输入一句话，需求智构就能帮你完成四件事，第一，深沉专业架构设计方案，从技术选型、模块划分、数据流到部署架构一气呵成。 第二，自动拆解用户故事标准格式，作为谁想要什么，以便什么验收标准都帮你写好。第三，输出完整的产品需求文档背景功能、非功能需求、风险假设应有尽有。 第四，设计详细测试用力表格格式、优先级步骤与其结果、测试经历见了都要点赞。更厉害的是，它还能帮你开评选会，一键启动多角色设计评选架构师、产品总监、测试专家，所有角色同时上线，从不同角度给你的方案挑刺、提建议， 然后 ai 会帮你整合所有意见，输出优化后的最终方案会议都不用开了，你以为这就完了？智构还内置了版本管理，每一次改动都自动保存，随时对比回滚。 一键生成项目脚手架、 spring boot、 fast api express， 你 想用的技术站，它都能生成。 自动绘制架构图 memory 代码一键复制，还能导出图片。从想法到落地，从需求到代码，智构让你告别碎片化工具，把时间留给真正重要的事，思考和创新。 ai 驱动的全流程设计协助平台，无论你是产品经理、架构师还是开发工程师，他都能成为你最得力的助手。现在访问官网，立即体验 ai 带来的设计革命。下面我们快速演示一下工具写作的过程， 感兴趣的小伙伴可以私信我，一起交流，创造更多小而美的智能工具。

百分之九十的人让 ai 写需求文档，写出来的全是废话，为什么？因为你没有让他真正理解你的需求，他只能给你一份通用的模板。 我总结了三步，让 ai 能够写出真正能用的需求文档。第一步，和 ai 对 话聊需求，让 ai 反过来问，你别上来就说帮我写一个 prd， 先跟他说我要做一个什么东西，然后你先问我十个问题，把需求搞清楚， 他会问你目标用户是谁，核心功能有哪些？有什么限制？你一个一个回答，他才能够真正理解你想要什么。第二步，让 ai 整理成文档，需求聊透了，就再让它输出一个完整的 p r d， 包括功能列表、页面结构、交互逻辑。 这一步推荐用 cloud， cloud 写出来的文档结构更清晰。第三步，人工审核 p r d。 的 一个细节。有时候 ai 会漏遗漏一些东西，比如说边界情况异常处理，它很容易忽略， 你必须自己过一遍，把细节抠出来，改完才能够用。总结一下，先让 ai 提问，再让 ai 去整理。最后，人工审核这三步写出来的需求文档，才是真正能照着做的需求文档。关注我，我会持续分享 ai 相关的内容。

ai 编辑产品到底做了什么？是不是这些 prd 画画流程图啊？我只能说一句，你真的以为 ai 能上线，是靠流程图接一个 gpt 就 能跑起来了吗？ 今天我就带大家来看一看 ai 编辑产品的一天。首先第一个需求不是听用户说，而是要算模型能不能做。每天最重要的是是和业务方碰撞需求，但和传统的 pm 呢？又不一样，我们不是要听用户说，哎，我想用一个某某功能，然后就开始画图，对吧？画圆形图， 我们的第一反应是说，这个场景大模型现在能力到底能不能支撑？有没有更可靠的数据作为支撑？边界条件多不多？出了错谁的兜底？举个例子啊，业务说，我想要做一个客服安检，听起来很简单，但我要评估的是问题是不是都是标准问题？ 用户的语言有没有上下文的跳跃？模型能不能 carry 百分之八十以上的意图知识库？要不要去做一些规则的兜底？ 这个时候呢，就得和算法一起来敲定边界，一步一步的拆解。所以说， ai 产品经理不是要听用户说，而是要把模型这些都听完之后，反问一句，这个用模型真的能搞定吗？边界的拆分非常重要。 第二个，设计不是画界面，而是要拼能力面。如果我们要进入到一个产品的设计阶段，你以为画个圆形就完事了吗？其实不是的，大屏产品的设计不是页面，而是能力面加反馈面加数据面。举个例子啊，做一个 angel， 帮运营去写推广文案，不只是说输入产品名，输出一段话， 我要确定的是说要用哪个模型，用 prompt 搞定还是微调模型？能力不够时，有没有一些外部知识的补充？那用户不满意的时候，有没有一些反馈标准的机制，输出的文案能不能和用户运营节奏联动等等一系列的东西？ 大模型的产品经理不拼功能堆叠，拼的是能力的组合跟反馈的闭环。那第三个阶段是什么呢？上线不是推代码对吧？我们是要扛着预期差，因为你到项目快要推进上线的时候，普通的产品经理想的是发布的节奏啊，或者类似的一些东西。 而 ai 产品经理要想的是说，哎，这个东西上线之后，他会不会翻车？举个例子啊，你做一个 a 型，比如说给销售用， 结果销售上线当天就说，哎，这东西太啰嗦了，节奏不对啊，怎么，怎么类似的这种，对吧？客户问价格啊，一系列的东西， 那应该要怎么办？所以呢，上线前我们就要先去搞小规模的恢复，给真实用户去做测试，设置清晰的 kpi， 目标转化率啊，跳出率啊，对吧？类似这种设计一些兜底的机制加失败案例的一些反馈的标准借口，或者啊，写一些提出让大家知道。 哎，这是 ai， 不是 人，上线，其实不是结束，是复反馈的开始，你安紧上线的那一刻，你才刚刚开始干活呢。那第四个阶段，调优不是修 bug， 是 调策略加微数据加换策略， 上线后我们还要跟算法同学去复盘的数据。大模型项目最大的问题是说，你永远不知道他哪次就发飘了，昨天还打得好好的，今天就开始一本正经的胡说八道了，哎，你就得分析是数据变了还是用户问题分布变了等等一些东西。 然后呢，就要开始去做一些 prom 的 迭代，数据的清洗啊，设计的微调啊等等一系列的。所以说， ai 产品经理不是要修 bug， 而是要修脑子模型的脑子。听到这你可能会想，这工作可能也太复杂了吧。 好吧，确实是有点复杂，但也正因为是这样，才能有巨大的机会窗口啊。所以未来的产品经理百分之九十都要会懂 ai， 会拆能力，会搭数据闭环，会去搞这个调油的策略。而 ai n 级产品经理就是要在这个转型的风口浪尖上。 最后一句话送给准备转型的你，一个 ai 的 产品经理，不是写 pr 的 工具人，而是连接模型用户跟业务目标的能力操盘手。 最后呢，我也是整理了一份某个大厂要求 ai 产品经理必须要学的一个文档，里面就包含了整个 ai 产品的研发流程，大模型的未来发展方向，以及 ai 产品当前存在的一些问题，有需要的可以去看一下。

如何用 tree 完全开发一个微信小程序？第二期，今天我们的主要内容是使用 tree 创建我们的项目，然后创建两个 ai 智能体，一个是我们的软件产品经理，另外一个呢是我们的 ai 技术经理。 那通过这两个智能题，我们今天要输出我们的需求，细化后的软件产品 prd 文档，以及技术经理输出我们的技术方案，可行性分析还有风险，以及 最终的就是方案报告。首先我们先打开 tree， 然后在设置中选择智能体，这里可以看到我已经创建好了这两个智能体，创建的方法也很简单，点击创建，然后这里这个智能生成不是好用，大家可以点击取消， 然后在这里输入智能体的名称，这里的提示词我已经准备好了，所以我直接把它粘贴上去， 主要是一个角色定义，然后技能描述，还有一个是输出，然后给他一个英文标识，何时调用，这里我们就写，当用户提出开发需求，需要确认软件开发的具体需求和细节时 才调用，然后所有的都保持默认，点击创建，然后选择立即使用就可以了。这里我们还是用我们之前创建好的软件产品经理来给大家演示，这是我已经准备好的需求， 然后粘贴给他。 接下来呢我们就把这个需求发给我们的软件产品经理，可以看到他已经开始在分析问题了，因为我要求他是以对话的方式，需要我去主动澄清一些需求的问题，所以他会向我提问，并且给我一些选择， 我会按照我实际的一个要求去做一些选择。 ok， 那 接下来我们就和他一起对话，完成我们所有的需求澄清。 最后在他所有的步骤都完成以后呢，我们实际上就得到了一个最终的 prd 文档，然后这个 prd 文档我也是做了一些阅读和修改，最终生成了 我们最终的 prd。 接下来就是把我们的 prd 文档给到我们的技术经理去做技术拆解，同样也是要创建一个技术经理的智能体。这里我就不再演示了， 我会把提示词分享在评论区。嗯，这里可以看到他实际上最开始给的一个方案是后端用腾讯云去开发，但我们实际上是要用自己的私有服务器去部署， 所以这里我修改一下他的提示词，让他重新和我通过对话的方式重新完成这个技术方案。 最终我们可以看到他最后是交付了一个技术架构图和一系列的文档。 那这个里面就比较符合我们现在的一个技术需求。首先微信小程序通过 ninjix 反向代理做 s t t p s 反向代理，然后 后端使用 node js 开发，然后使用 mac 的 数据库，然后由后端再去调用扣子工作流动语音识别 以及做这个邮件同步。 ok， 那 通过今天这期内容呢，我们可以看到，实际上我们在用 ai 编程的时候，并不说直接上来给 ai 提了需求就让他去干， 而是我们先通过前期跟 ai 协同的规划，搞清楚我们要做什么，怎么做。 嗯，其实这也是大家用 web coding 去编程很容易犯的一个常见的误区，就是一上来就开始让 ai 去做一些模糊的需求，这就会导致后期项目很难去把控，还有 bug 可能会出现反复解决不掉的问题。 所以我认为 web coding 最重要的就是第一个，磨刀不误砍柴工，我们一定要在前期把如何做，怎么做，规划好技术架构是什么， 然后将这些以文档的形式约定好告诉 ai， 这样的话 ai 在 后期开发的时候才不会偏离的太离谱。 ok， 那 本期内容就到这里，如果你感兴趣的话可以点一个关注。下期我们将做三个内容，第一个就是创建我们的 ai 工程师 去开发前端和后端。第二个就是在虚拟机上安装一个本地的 linux 来模拟我们真实的服务器。最后一个就是让我们的后端工程师能够操作这个 linux 服务器完成开发。

虽然你看这个内容之前已经了解了非常多的 prd 教程了，但是你打开 word 还是不知道怎么写，我说的对不对？所以今天呢，就给大家分享一个非常实用的 prd 框架，我敢说它一定是最简单的，为了让你能够清晰的去了解它，为它分类起步。首先第一步，你要知道为什么需要 prd， prd 呢，它是开发的参考文档，当然呢，如果有锅的话，也是背锅的证据。 前后端的开发同学和测试同学会参考你的 prd 去开发和测试它的功能。但重点啊，你要了解到我需要写到什么程度，它可以很多，也可以很少，什么时候学我都需要特别了解。首先，如果是零件转行的同学，是不需要在面试之前去学这个东西的， 因为面试不考，那如果你是个小厂同学，他一般是不规范的，所以这个时候呢，你大概率是只需要把常规的框架学清楚就好了。那稍具规模的一些中大厂呢，我们是需要把需求文档写的特别的详细，当然呢，也要去看我们的技术他是怎么要求的。 但不管怎么样，我们对自己的能力还是有要求的，你务必要做到功能描述要详尽。第二个，文档内的图形文字看起来要简单清晰易懂，也就是我们所谓的圆形图，思维导图，框架图，以及你整个的 markdown 的 结构，以及你文档整个的结构描述形式。 第二步就是需要了解整个的框架了，我们先写一个日文档，日制呢，代表着我们每一次更新我的 prd 的 时候，到底更新了什么内容， 自己列个表，分为时间版本号、变更人，变更内容，你每次去把它写出来就好了，这个是非数文档，所以他有的时候可以直接能看到具体的人啊，变更人是谁，以及变更的内容，可以点击直达他到底去到了哪里。 第二步，一个需求非常重要的就是他的项目背景，需求背景你需要非常详尽的把你做这件事情的背景影响面以及相关业务的影响面，用过了痛点，你所遭受的一些问题，在背景里面讲清楚，让别人知道做这个事情是有价值，有必要的。 再者呢，描述清楚你这个事情的目标和价值，就是你要达成什么样的目标，这个目标可能是短期目标，也可能是阶段性的长期目标。需求的相关方你可写也可以不写，他不是特别重要，主要是内部人去看的时候，你大概描述一下就好了， 最重要我觉得就是需求描述，一般来说一个比较复杂的系统呢，我们需要进行一个名词解释的，这个名词解释呢一定是仅针对于我们这个项目的，跟项目不相关的一些内容我们是不需要去处理的。还有就是镜本分析，做产品功能的时候，镜本分析是非常非常重要的一个点，你想要去做镜品的功能， 行业内是怎么做的，好的坏的我拿过来参考，以及我在它的基础上怎么去优化迭代的，把这个逻辑写到你的 p r d 里边。当然如果你的功能是比较简单的，不需要去参考外部的竞品的时候，那么你可以直接把它剔掉。这边给大家输入的是一个关于标题的形式的一个竞品分析。 再者就是流程图了，流程图它的操作是非常简单的，但是你能够把它融到你的需求文档里边，结合你的业务画出来，这个是有难度，它是需要你能够对你本产品的流程，对用户流程，不同系统间的流程有一个非常清晰的认知， 所以呢把这个认知落地到这个图里边，这个是有难度的，并且呢你要让别人看到你这个图，它是足够的简单清晰，你要符合基本的流程图的逻辑，这里面有一个描述，大家可以参考一下。 功能列表，你为什么做这件事情，推导出来我要做哪些功能，却把它列出一个表来来进行优先级排序，你可能在这个项目里边做十个需求，那这个十个需求一定是有优先级的，一二三四五六七八九十。 那为什么一二三五六七八九十？你要把它说清楚，每个模块的具体是干什么的，说清楚需要谁说清楚，如果是一个比较大的项目，他需要有相关的跨部门协助的团队的。再者呢是圆形图，圆形图目前 常用的就是 figma， extra 以及一些其他的工具了，看自己喜欢，我目前比较推荐大家在画圆形的时候，以交互图的形式去画， 就是你能够把你的产品从正常流程、异常流程一个图，通过各种判断啊，点哪里到哪里，非常清晰的去展示，这样你后续的交互同学啊， u i 同学，你的开发同学看的都非常的清晰，包括你的逻辑也非常的清晰， 可以长治其他。当然有同学现在进入 ai， 我 觉得也非常不错，那 u e 图和 ui 图呢？和圆形图大了，二选一就好了，但是你写 p r d 文档里面图最好是已经确定的，这样你在 评选的时候呢，你的需求是固定的，不会因为后续改稿子导致你的需求发生变更。然后就是想尽的功能描述了，这点非常重要。功能描述呢，我们的展现形式有很多种，有的同学愿意是上面是 文字，下面是图，有的同学是愿意画 excel， 这面是文字，这面是图。还有的同学呢，是喜欢在直接在圆形图里面去描述，这个是图，这边是文字。当然我觉得无所谓， 看你自己的选择，你觉得哪种方便，你就用哪种就好了。但是我一般建议大家如果更加清晰的话，还是以 excel 这种形式会比较好一点。同样道理， 接下来如果是偏 c 端产品的，我们是需要进行 a b 测试的，但是很多小厂目前 a b 测试是不全面的，但是呢， a b 测试的方法我觉得大家还是需要去学习一下。一般来说，我们是 a b 测试平台的使用方，我们不是开发平台的地方，所以我只需要去了解怎么用它的平台，怎么能够让我的数据变得显著，比如说 p 值啊，密等啊，比如最小样本量啊，比如说我的实验周期啊等等等等。 那做 a b 测试的时候，首先应该确定就是总体目标分流的情况，进行不同分组以及切流的过程，需要把它强行的记录下来啊。 如果你想做 a b 测试，它有个前提，你的买点一定要非常清晰，我们 a b 测试一定在某个页面某个模块下进行的，那这个模块新版本和旧版本它的买点一定是不一样 的，所以一定要去学习买点。当然这个买点也是分你具体的产品，如果是个 b 端产品，一般来说可能也不需要买点，那么 c 端产品来说是一定需要大量的买点，你对买点的方法一定要特别特别清晰。大家可以参考我们过去发的一些视频，里边有很多相关的教学 后面外部的约束条件，这些可写可不写，也可以去把它描述进来。再者就是这个项目的计划，后续如果排期出来以后，你可以把这项目计划表直接拉过来，在这边一般是他叫干特图啊。好，这个就是我们整体的 p r d 文档，大家可以好好去学一下，用这套框架把你所有的需求全部都套里面。

二零二六 google ai studio 入门二现在让我们创建一些实际内容。我们将为你新的网站生成一个头图，并编辑一张产品照片，而且完全不需要使用 photoshop。 点击 playground， 然后在标签中选择 images， 你会看到三个主要选项。 nano banana 是 标准图像生成模型，基于 gemini 二点五 flash image 非常适合快速生成图片。 nano banana pro 基于 gemini 三 pro image 是 google 最先进的选项， 具有更好的文本渲染，四 k 分 辨率和更高细节。免费用户每天有一定数量的生成额度，之后会回到标准 nano banana， 所以最好把它留给最重要的任务。 image 四专门针对写实照片优化，并且有最好的文字渲染效果。这意味着图像看起来像真实照片，而且文字不会出现奇怪拼写。现在我们生成网站投图 使用 nano banana， 在 提示框输入生成一张写实风格的有机咖啡店投图，展示一个温馨的清晨场景。 一个陶瓷杯中冒着蒸汽，带有日出金色光线。在设置面板中把比例设置为十六比九，分辨率可以选择一 k 到二 k。 点击 run， 图片就生成了。现在我们编辑一张已有的产品照片。回到 emoji 标签，在提示框右下角点击加上传图片。假设这是一个有人穿着带有 logo 的 衬衫照片，而你想删除这个 logo。 输入删除衬衫上的 logo， 并保持纹理自然。点击 run， 就这样， logo 被删除了，但衣服的纹理仍然保持完整。这可以替代很多产品摄影中基础的 photoshop 操作。对于图像生成，免费用户生成数量有限，并且图片上会有 gemini 水印。在 ultra 版本中，如果你曾经反复输入同样的提示说明，有一个功能可以节省你的时间。 system instructions 可以 把它理解为给 gemini 设置一个固定的性格，让它应用到所有回答中。私信体检领投放前九项体检表加首页结构模板，按你类目送一句优化建议。

欢迎今天呢，咱们来聊一个特别有意思的话题，就是你每天都在用的那些软件，那些 app， 它们到底是怎么从一个想法一步步变成你手机里那个好用又好看的样子的？你有没有想过这个问题， 感觉就像是变魔术一样，对吧？其实啊，这背后是一趟特别奇妙的旅程，从一个最简单的点子开始，最后才呈现在你的屏幕上。好，那我们现在就一头扎进去，看看这趟旅程到底是怎么回事。 咱们旅程的第一站呢，是开发者的工作室，你可以想象一个充满创造力的地方，在这里代码还只是个乱糟糟的草稿，这个阶段我们就叫它开发模式。 其实任何一个 app 都活在两个完全不同的世界里，一个呢，是它被创造出来的地方，一个私密的可能有点乱，但是充满活力的工作室，而另一个世界就是咱们拥护看到的那个光鲜亮丽、完美无瑕的公共展厅。 在这个工作室里啊，开发者们有一个超能力，叫做热宠仔，这是个什么神仙工具呢？就是说开发者那边刚改完一行代码，一保存，我们这边浏览器里的 app 立刻就更新了，而且就连你刚刚在表单里输入的数据都还在， 这就彻底改变了游戏规则，这意味着什么呢？意味着开发者可以非常非常快地去尝试新东西，修改 bug， 这就像是给了他们一个实时反馈的魔法镜，那最终对我们用户的好处就是那些我们盼着的新功能，还有那些烦人的问题修复都能更快的多的送到我们手上了。 好了，我们了解了开发者是怎么工作的，那么他们构建出来的这个 app， 它本身的蓝图又是什么样的呢？ 要想理解一个现代的 app， 咱们可以把它想象成一家餐厅，每个 app 基本上都分成两半，一半呢叫前端。这就好比是餐厅里你坐着用餐的大堂， 另一半叫后端，也就是你永远也看不见的那个热火朝天的后厨，他俩干的活可是完全不一样的。 你看这张表，就很清楚地说明了他们的分工。前端就负责所有你能看到能摸到的东西。比如说餐厅的装修好不好看，菜单清不清晰，你点菜方不方便。 而后端呢，它就像是整个餐厅的大脑和心脏，它处理的是核心的菜谱，管理着食品储藏室里的数据，还要核对预定名单，保证用户的账户安全。 那么问题来了，如果说前端是大堂，后端是后厨，那你的订单是怎么从你的餐桌一路跑到厨师手里的呢？ 答案就是通过 api。 你 可以把 api 想象成餐厅里那个来回穿梭的服务员，他把你点的单子，也就是你的请求送到后厨，等菜做好了，再把菜也就是数据给你端回到桌上，他就是个勤劳的信使。 所以你看这整个过程，就像是一只配合默契的舞蹈。第一步，你在 app 上点了一个按钮。第二步，前端马上通过 api， 这个服务员发出一个请求。 第三步， api 就 把这个请求送到了后端。第四步，后端叮叮当当一通忙活，处理完请求，把结果再交给 api。 最后一步， api 再把结果带回到前端，展示给你看，你看整个流程行云流水。 好，现在 app 在 工作室里跑得挺顺畅了，但这还只是个原型，它还没准备好。面向全世界， 它需要经过一个叫做构建的流程。咱们再换个比喻，把这个过程想象成一个工厂，为大规模生产做最后的准备。 这里有个比喻，我觉得特别贴切，就是说这个构建的步骤啊，就像是把一份乱糟糟的草稿，变成一本印刷精美，人人都爱读的书。 他把那些方便开发者理解的粗糙的代码，转变成一个给所有人用的流畅又高效的版本。在这个工厂里都发生了什么呢？ 简单说就是给 app 瘦身和提速，代码会被压缩，让整个 app 变得更小，这样你下载起来就更快，性能也会被优化，用起来更流畅。还有那些只有开发者才看得懂的调试信息，也通通都清理干净了，最后完美打包，准备发布。 所以你看这张图，就形象的展示了整个旅程，从那个有点乱，但是创意无限的开发者工作室出发，经过高效运转的工厂进行打包，最后闪亮登场，来到我们用户面前的这个展厅里。 好，现在 app 终于上线了，进入了生产模式，这就像是盛大的首研之夜。但是有时候你可能会觉得，哎，怎么好像卡住了，有点不对劲。 我猜你肯定遇到过这种情况吧，你反复的刷新一个网页，但看到的内容就是不更新，明明朋友都说看到新东西了，就你这还是老样子，这背后的导弹管啊，十有八九就是一个叫缓存的东西。 缓存是什么呢？你可以把它理解成是你浏览器的短期记忆，它会把你刚看过的图片啊、数据啊暂时存一下，像你下次再来，就不用重新下载所有东西， app 加载的速度就嗖嗖的快， 这本来是件好事儿，对吧？但问题就出在，有时候这个短期记忆太好了，它忘了去更新。 app 本身明明已经发布了新版本，可你的浏览器还是出于好意，执着地给你看它记忆里的那个旧版本。那这种时候该怎么办呢？别急，有一个小秘诀是开发者们天天都在用的，而且超级管用。 这个开发者的秘密武器就是强制刷新。在大多数浏览器上，你只要同时按住 ctrl、 shift 和 r 这三个键就行了。如果你用的是 mac 电脑，那就是 command shift 和 r。 记住这个组合，下次再觉得 app 卡住了，就试试它，它会直接告诉浏览器，别看你自己的小本本了啊，去给我拿网上最新的东西 好了。从开发者的草稿到你手机里的数字世界，这趟旅程我们算是走完了。那么下一次，当你再打开一个 app 的 时候，会不会试着去分辨一下 哪里是精心布置的前端餐厅，背后又有哪些看不见的后端厨房和 api 信使在为你忙碌的工作。

这是一个可以让开发团队集体失业的开源项目，每天一个提效神器第二十三期，今天要讲的是 输入你的需求， ai 分 身就自动拆解任务，产品经理写 prd 文档，架构师设计系统流程程序员负责代码实现， qv 做测试，从想法到原码落地流程全部搞定。过去需要开发团队熬夜干几周的活，现在一个人几分钟就能跑通。觉得有用的话可以点赞收藏一下。

以前 ai 只能回答问题，你问他，他来回答，现在呢， ai 不 仅能回答问题，还能帮你干活。今天我就给你介绍一款文档编辑器的软件，在接入 ai 以后，文档工程师的效率得到了巨大的提升。这个编辑器叫做 action 编辑器，是一款支持结构化文档编辑和发布的软件。 最近他们开发了一个 ai 插件，接入了 ai， 该插件内置了很多的 ai 功能，比如说内容的生成、内容改进、翻译等等。 他不仅能够回答问题，还能帮你进行操作，比如说读取你的产品 p r d 文档，帮你创建目录，创建手册，并且进行初稿的编辑。今天我就来演示一下如何使用这个工具来编辑和发布文档。 现在你看到的就是 action 这一期在右侧是这个 ai 插件，目前我是配置让它连接了 deepsix 大 模型。在左边是这个项目的项目文件，这里有个文件是研发团队发过来的需求文档。 我今天的任务呢，就是根据这个需求文档编写这个产品的安装说明。这是一个教学专用的电子阅读器软件产品，它呢主要是给老师和学生用的。 整个产品呢分为后端和前端两部分，这是它的详细的需求。那么现在我就用这个软件来编写它的安装说明。 我说在这个项目的 content 目录中，帮我增加一个新的目录，叫做 booklab， 然后呢，在下面增加一个叫做 installation guide， 点编辑 map 的 小文件 好了。他根据我的要求创建了这个目录，并且创建了一个新的手册，但目前这些手册里都是假的数据。 接下来我哥来说帮我整理这个 data map 文件，把它变成 book map， 并且将首首色的语言设置成中文，然后加上 book title 和 frontmatter， 在 frontmatter 后面加入简介、安装、配置这三张，并且帮我调整。如果是需要的话，帮我建立新的 data map 文件。 嗯，执行完了，全部保留。 现在你看到他把这个 map 变成了 book map， 并且把这个手册设置成中文，并且加了相关的章节。我把它重新看一次，因为它这个需要重新装载一下， 我看数据有什么问题没有？嗯，验证成功，基本上没什么问题。然后呢，我不需要 back back method， 把它去掉。 好了，他对这个 google map 进行了一些调整。呃，然后目前呢，他手册结构已经建立好了，但是这些内容都是他自己想的， 这是目前他写的简介内容。然后呢，我跟他说， 产品研发团队发过来了产品文档，在这个目录里面的这个文件，请根据这个文档来改写。简写这部分内容。 好了，它根据我们的需求文档重新写了这个简介这部分。现在目前这个简介部分就比较接近于我们的需要了，我们可以对它进行修改。 我说把剪辑中的 section 拆分成独立的 type 文件，并且在 mac 中的剪辑章节里增加对它们的引用。 好，执行完以后，他让我确认，现在大家看到剪辑又被拆分成了四五个章节。 针对这部分，我说 帮我改写这部分内容，将列表改成表格。 好，它修改完了，确认一下。好，我把这个手册发布成 pdf 格式和 html 格式两种， 这就是这个产品的安装指南，这是枫叶，这也是目录，这是表格清单 前一部分，这是第一张 这个这个产品的 pdf 手册就已经生成好了， 再看一下，这是他生成的 html 格式的手势。我们进到剪辑这部分，看到上面的核心价值，上面的架构，核心用户角色， 好了，这就是我想演示的。从这个演示的过程中，你可以看到，通过这个 ai 插件，我通过自然语言对话，就可以让他帮我完成不少的事情。在全过程中间，我基本上没有做什么具体的手工操作，是不是很方便？ 我们摩拿是这个产品的代理，如果你想尝试一下，联系我们来获取试用版的莱克斯。