夜雨聆风过去一段时间，我用 Codex 和 Claude 搭了一套小红书 AI 工作站。
它不是一个简单的"AI 写笔记"工具，而是一整套从素材采集、AI 改写、AI 生图、草稿管理、飞书同步，到扫码发布的小红书图文内容生产工作流。
 |  |
这个项目从 5 月下旬开始做，用了两周时间从零到正式上线。上线后十来天，网站积分充值超过 1w。
消耗了可能有百亿 Codex token，也把一个 GPT Pro 20x 的额度打穿过。代码量超过 17 万行。
 |  |
但项目真正跑完以后，我反而觉得，Codex 只是把执行速度拉快了——快到以前不可想象的程度。
真正决定这件事能不能成的，仍然是需求判断、流程设计，以及上线之后有没有能力稳定交付。
所以这篇内容想跟大家复盘这个完整的过程：
一个不会写代码的人，是怎么把一个真实的内容生产需求，做成一套能收费、能被陌生人使用的工作流产品的 一套内容生产 AI 工作流，怎么从真实需求里长出来 怎么用 Claude + Codex 分工，从 0 到 1 完成全流程的 AI 开发 一个 demo，怎么扛到线上、付费、API 供应商、系统管理这些生产环境问题 API 稳定性和小红书 AI 标识这些"麻烦"是怎么处理的
这篇复盘我会分享做 AI 产品的经验与思考，会尽量写细！下面就按真实顺序来讲。
一、这套小红书 AI 工作流是什么
现在 AI 工具已经很发达了。
写文案有 ChatGPT、Claude，做图片有 GPT-image-2、Nano banana，做自动化有 AI 写脚本，做团队管理有飞书，做发布有各种插件。
单点能力都不差。但真正做小红书内容的时候，你会发现一个很尴尬的问题：
工具很多，流程还是散的。
它们没有真正按小红书内容生产的方式串起来。
写文案是一截，做图片是一截，存草稿是一截，团队审核是一截，最后发布又是一截。
每个工具单独看都能提高一点效率，但只要中间靠人手动复制、下载、上传、保存、切窗口、找状态，整体效率就提不上去。
所以我理解的小红书 AI 工作流，不是"让 AI 自动帮我写一篇笔记"。现在还很难做到很好！而是帮大家把各个AI环节都串起来，同时把小红书内容操作门槛也降下来。
这套工作站最核心的设计原则，其实就一句话：
所有内容入口，都进入 AI 改写页创作；所有生成结果，都进入发布列表发布。所有大模型，都选当下最好的。
具体功能的介绍可以看这篇内容的完整介绍，我这里就不重复说了！我用 Vibe Coding 搭了套小红书 AI 工作站，内容生产效率翻了 10 倍！
感兴趣的话可以去自由体验！目前网站每张图片生成只要 6 分钱，文案生成不到 1 分钱
网站地址是：ai.liuliangfeng.com
AI 味、AI 标识和平台风险，要拆开看
做这个产品时，很多人最关心一个问题：
小红书会不会识别 AI？这个问题不能简单回答。我更愿意把它拆成三层。
第一层：内容层面的"AI 味"
这也是最重要的一层。
所谓 AI 味，很多时候不是因为图片或文案真的被机器识别出来了，而是内容本身太空。
如果一篇内容标题很夸张，正文全是空话，图片很漂亮但没有真实感，评论区没人愿意互动，那它就算不是 AI 写的，也很难跑出来。
反过来，如果你的素材是真的，观点是你自己判断过的，案例来自真实业务，AI 只是帮你把表达效率提高，把图片和文案生产流程变快，那依旧有很好流量。
平台真正反对的，不是"你用了 AI"。而是低质、造假、侵权、无人运营。
一旦你把 AI 当成批量制造垃圾的机器，它会把垃圾制造得更快。
第二层：图片文件的来源标记
GPT-image-2 生成的 PNG 文件里会嵌入一段来源元数据，记录这是 AI 生成的、用了什么模型。也就是所谓的"暗水印"，小红书通过读取这段数据来识别并打上 AI 标识。
于是我们只做了一件很简单的事：图片保存到工作站的时候，把这段标记清掉。像素完全不变，图片质量完全不变，只是去掉了那段来源记录。
目前已经测试了上百篇笔记，都不会再带这个标识了，也就过了小红书初步的AI审核。也有很多学员反馈，用了工具后发出去的图确实没有 AI 标识。
 |  |
这个其实是 GitHub 上的一个开源项目，我们用了一两个小时接入进去了，感兴趣的可以研究看看：https://github.com/wiltodelta/remove-ai-watermarks
第三层：账号和平台AI识别
刚才说到小红书更在意的是账号有没有真人运营、是不是批量造假、是不是无人托管。
如果内容被判定AI标识，可以提交申诉，附上创作过程记录，把AI创作的图片放在稿定设计/可画中排版一下，改成真实创作的过程，然后提交申诉。
写清楚：制作时间、创作过程、为什么认为被误判。
现在小红书审核其实也很难准确判断什么是 AI，什么不是，附上过程记录申诉通过率很高。
二、验证需求：为什么要做这个产品
让自己成为用户，比自己更懂用户
我以前在大厂做产品经理的时候，经常有一种很难受的感觉：
我不是用户，我不知道用户到底怎么用。
很多需求来自老板安排，来自会议讨论，来自用户与竞品调研，来自"我们是不是也应该有一个这样的需求"。
那时候很容易做出一些看起来合理、实际上没人真的在意的东西。
做这个产品之前，我没有做过正式的市场调研。
我自己在做小红书内容，团队在做小红书内容，学员也在做小红书内容。大家碰到的问题高度一致：
AI 可以写，但流程太散，效率太低了；
AI 可以生图，但中文乱码；
工具有很多，但不会用、也不想自己配置复杂环境。
不是一两个人偶尔抱怨，是反复撞到同一堵墙。这种重复本身就是信号。
AI 改写小红书的需求其实一直都有，但过去有一个卡死的技术障碍：生图中文乱码。图文笔记如果图上的字都是乱的，这条链路就是残的。GPT-image-2 之后，中文渲染终于稳了。
需求还是旧需求，但解决方案的可行性变了。这是窗口期，不是新发现的需求。
这里还有一个更重要的点：
用户反馈给你的，通常不是产品方案，而是某种不舒服。
他说"我想要一个 AI 笔记工具"，这不是方案。他说"我想批量生成内容"，这也不是完整方案。他说"能不能自动发小红书"，更不是你应该直接照做的方案。
产品要做的，是把这些不舒服抽象出来：
他到底是产能不够，还是素材管理乱？他到底是想省发布时间，还是想降低账号风险？他到底是需要全自动，还是在平台边界下合规运营与发布？
用户给你问题，产品负责定义解决方案。
这个能力不是靠想出来的，是靠反复做、反复用、反复被真实问题打出来的。
所以我越来越觉得，定义产品的能力在 AI 编程时代反而是优势。
俞军的公式：一个功能值不值做
判断一个功能要不要做，我一直用俞军老师的那个公式：
用户价值 = 新体验 - 旧体验 - 替换成本
比如我自己开发的工具，我就会问自己：
旧体验是什么：多个工具之间来回复制、保存、切换，状态散落四处。
新体验是什么：一条工作流里完成采集、改写、生图、管理、发布，在一个地方看到所有状态。
替换成本是什么：用户不用自己折腾工具配置、内容采集、图片模型、发布链路，直接用工作站，用积分买结果。
用户不是为一个"生成按钮"付费，而是为少切 10 个窗口、少踩工具配置的坑付费。
这样购买理由，就足够清楚了。
我判断一个功能要不要做，基本围绕这几个问题：它是不是让新体验明显好过旧体验？它能不能降低用户迁移成本？它能不能增强用户付费理由？
如果不能，那就算它看起来再酷，也要往后放。
真正能上线的产品，必须先把产品价值想通，能真正识别到用户的真需求。要不然很容易成为自嗨的功能。
产品倒做：先想清楚谁会购买它
AI 给了我们供给能力，让开发产品的成本被极限拉低，但流量推广不会因为我们用了 AI 就自动出现。
这是独立开发者最常见的死法：花四十小时在产品上，找客户的时间不到四小时。
AI 时代这个结构直接杀死产品——供给成本越来越低，意味着市场上不缺产品，分发能力的稀缺性反而在不断放大。
所以做产品我更想强调"产品倒做"。不要从供给出发，甚至不从产品价值出发，而是从市场和流量出发。
先想清楚用户在哪里，他为什么信你，他为什么愿意付费——这些想清楚了，再去想做什么产品、怎么实现。
比如我自己，本来就在做小红书运营、AI 内容、知识付费，有公众号、朋友圈、学员社群，有上千个付费过的学员。
他们知道我在做什么，知道我自己就在用这套工具跑业务，我发出去，大概率他们会成为第一波种子用户——这是比任何冷启动策略都可信的背书。
我不需要上线就是爆款，只需要接在已有内容和服务体系上。这一点从立项那天就想清楚了。
产品不是孤立存在的，它会接着你后续的推广、运营和服务一起跑。
如果一个产品从第一天起就不知道怎么被看见，那它做得再快，也只是更快地做出一个没人用的东西。
只做 20%，但要比同行好 10 倍
AI 编程有一个特别大的诱惑：你会觉得什么都能做。
以前一个功能要排期、找工程师、沟通、开发、测试。现在丢给 Codex，可能半天就出来一个版本。速度一快，人就容易膨胀——这个也加，那个也加，功能越堆越多。
但现在用户的可选择性也很多。市面上 AI 内容工具已经不少了，用户第一次进来，三分钟没感受到核心价值，就会直接关掉。功能清单真的打不过核心体验。
我当时给自己定了一条原则：只做 20% 最痛的需求，但这 20% 要比同行好 10 倍。
我自己最痛的那条链路是：素材进来 → AI 改写 → 小红书预览 → 发布列表 → 飞书同步/扫码发布 → 积分计费。这条链路一旦跑通，用户完成一次真实生产，他就知道这个东西值不值。
剩下的有价值的功能先不做：批量上传功能（支持用户一次处理多条笔记）、分销产品（不是核心的功能体验）、小绿书内容同步（先聚焦一个平台内容生产）、小红书商品笔记内容只做。这些不是没价值，是不该现在做。
先把这条最痛的链路做好，好的产品体验和稳定性对用户来说远比功能多更重要。
每个功能都做到 60 分，在这个 AI 时代，用户不会记住你。
你必须找到那条最痛的链路，把它做到 90 分、95 分，甚至比用户原来的流程好 10 倍。
这时候产品才有机会被记住。
三、非技术背景如何用 Vibe Coding 做出来
我不懂服务器，不懂对象存储，不懂 CDN，不懂数据库，不懂微信支付，不懂测试环境，甚至看不懂一行代码。
开发过程中 Codex 问我"数据库要用 PostgreSQL 还是 MySQL"，我完全不知道这两个有什么区别，直接回了一句：你给我推荐，说清楚理由。
再比如整体网站技术栈是怎么选的？我的方法很直接：开多个 agent，让 Claude、Gemini、DeepSeek 同时推荐，哪个组合出现频率最高就选哪个。
三个都推 Next.js + TypeScript + PostgreSQL + Prisma + Tailwind CSS，我就选了这套。说实话这些词我也看不懂，但AI 共识越高的技术栈，理论上确定性越高。这样AI 训练数据越多，出了问题也越容易找到解法。
服务器部署也一样，对我来说完全是黑箱。
我不知道怎么配置服务器，不知道怎么管理进程，不知道出了问题去哪查日志。但我只需要做一件事：让 AI 能登录你的服务器，然后把服务器的所有操作都交给它接管。
具体就是让 AI 帮你配置一个 SSH 密钥可以登录服务器，之后不管是部署代码、重启服务、查错误日志、改环境变量，全部让 AI 来做。
不懂技术，现在真的不会影响产品做出来。 但这里有个很大的前提。
我们不能把一句话随意扔给 AI，然后等它自动给你变出一个产品。那不叫 Vibe Coding。那叫许愿。
你不一定要会写代码，但必须能做几件事：
把业务目标讲清楚。把用户路径讲清楚。把什么叫"做对了"讲清楚。
这些说不清楚，AI 越强，越容易把你带偏。
你说"帮我优化一下"，它就会优化。
但它不会天然知道，你的"优化"到底是让页面更好看，还是让转化更高，还是让发布链路更稳，还是让图片状态不要被改坏。
所以这个项目里，我最大的变化，不是学会了代码。而是学会了怎么管理 AI 干活。
工具怎么选：Claude + Codex 为什么是这个组合
这个项目里，我不是把需求扔给一个 AI，然后等结果。我更像是在管理一个小型 AI 团队。
Claude 更像负责需求把关和追问的人。Codex 更像执行工程师。Gemini、DeepSeek 这类模型，更多用来做复杂需求的旁路审查。
我自己负责产品方向、用户判断、体验验收和商业取舍。
这个分工很重要。因为 AI 有一个明显的短板：它不会主动说"你这个需求有问题"。它只会老老实实执行你给的任务，哪怕这个任务本身就是错的。
所以在需求阶段，我会反复跟 Claude 交流，让它做苏格拉底式的追问，不只是回答问题，而是反复追问。直到需求被完全确认！
很多时候我说一个需求，Claude 会先问我：这个功能给谁用？成功标准是什么？失败场景是什么？哪些路径不能破坏？这个需求是不是现在该做？这样我会知道很多我没意识到的边界！
复杂需求还会让多个 AI 去审查方案。当几个 AI 从不同角度都给出差不多的建议，而且我能听懂它解决的业务问题，方案大概就是符合预期的！
我才会让 Codex 往下做。要不然我很难判断一个 AI 给的答案对不对——AI 做执行时，对我们来说几乎是盲盒。
这些问题一项一项确认很烦，有时候能搞大半个小时。但能省掉大量返工。
Codex 的价值在于执行能力强、价格相对便宜，比Claude更划算些！还可以一次排一连串任务，让它挨个执行。
Codex 再执行时，先让它基于 Claude 的方案写执行任务卡和验收标准。
每个任务只做一条小链路，并且是独立垂直切片，完成一个小任务就可以独立验收，不允许一口气全部一大堆乱改，这样很容易出错。改完以后，再让它自己跑测试、跑检查、写结果。
最后我们再验收下用户路径和体验对不对，不需要看代码——因为我们完全看不懂——只是做用户体验测试。
如果一句话总结就是：
Claude 负责把模糊需求变清楚，Codex 负责把清楚任务变成代码，人负责验收它有没有真的解决问题。
一个需求是怎么跑完全流程的
整套工作流大概是这样：
我提出一个需求 Claude 追问澄清——一次一问，每个问题给推荐答案，让我做选择 输出需求文档（requirements.md），明确功能边界、异常情况、验收标准 Codex Planner 把需求拆成任务列表（task.md） Codex 执行——只改授权范围内的代码，不允许跨模块动 Codex 跑自动化浏览器测试——按验收用例逐项过，不需要我手动点 我 + Claude 做最终验收
这个项目一共积累了 285 个 Markdown 文档——AGENTS.md、context.md、requirements.md、task.md、验收报告、历史归档。这些都不是冗余，是整个项目最重要的"外置记忆"。
AI 没有跨会话的长期记忆。每次新任务开始，它只看得到当前上下文里有什么。你维护的文档系统，就是它的项目记忆。文档越清楚，它走偏的概率越低；文档缺失，它就只能靠猜。
 |  |
另外自动化测试这步省了我大量时间。
Codex 可以控制浏览器跑真实链路：改写页保存后发布列表是否出现、删除图片后是否复活、二维码是否生成、积分是否扣对。
这些以前要手动挨个测，现在丢给 Codex，它自己跑完报结果，不对的就自己给你改了。
 |  |
这里有一个很关键的习惯：
我经常会先让 AI 只读分析，不要修改。
比如我会说：先对比需求文档、设计稿、当前实现，列出差异、风险、涉及文件和推荐方案，先不要动代码。
这一步很重要。因为很多问题不是"马上修一下"就能解决的。
尤其是这种已经上线、有计费、有图片、有发布链路的产品，你随手修一个地方，可能另一个地方就坏了。
先分析，再动手。这听起来慢，但实际更快。
最后还有一条规则大家必须知道！我踩了很多次坑：
同一个问题 Codex 失败两次，必须升级给 Claude/Gemini 做根因分析，不能继续让它在死路上撞。不要让它反复改！不要让它反复改！不要让它反复改！
这条规则省了我很多时间——AI 修 bug 最容易的模式是"在旧的错误基础上加保护逻辑"，问题表面看消失了，但根没动。
升级之后多角度重新分析，往往发现根因完全不在 Codex 以为的地方。
四、上线后才发现，demo 和产品差很远
上线前我以为最难的部分已经过了。实际上，上线是另一个故事的开始。
Codex 可以很快把功能做出来，但正式产品会死在另一批问题里：API 不稳定、图片状态混乱、计费逻辑漏洞、任务边界失控……
 |  |  |
这些在 demo 里几乎不会出现，因为 demo 是你自己用，数据干净，流程短，出错了刷新重来。真实用户不会刷新重来，他们只会告诉你"坏了"。
只有线上环境，才有真实模型、真实用户、真实数据、真实计费、真实发布。线上用户真实的使用，才知道系统能不能扛真实世界。
第一个坑：供应商不是越便宜越好
做 AI 产品，绕不开模型供应商。
文案要模型，图片也要模型。一开始我也会本能地看价格。比如一张图多少钱，一次文案生成多少钱，哪个接口更便宜。
但真正跑起来以后，我发现价格只是最表层的问题。
刚上线几天就发现，主力图片供应商资源不太够，特别是高并发的情况下，生图要么很慢，要么生成失败，甚至还出现连续几个小时无法生图。
那段时间用户提交任务，要么一直转圈，要么报错——他们感受到的是"这个产品坏了"。跟供应商出了什么问题没有任何关系。
后来我才意识到，选模型供应商不能只看单价。
至少要看四件事：
第一，生成质量是不是稳定。
第二，失败时能不能知道为什么失败。
第三，速度是不是能给用户一个可接受的预期。
第四，出问题时能不能快速切换或恢复。
如果便宜但不稳定，最后省下来的几分钱，会以用户投诉、失败重试和信任损耗的形式还回来。
更重要的是稳定性。用户不会区分这是我的代码失败，还是上游模型失败。
他只知道：我点了生成，图没出来。那就是你的产品失败。
那次之后我做了一件事：把图片接入层重构成支持两个供应商快速切换。主线挂了，备线顶上，用户感知不到切换。
当然价格也不能完全不管——国内用户对价格相对敏感。为了找到合适的供应商，前前后后试了不少线路，做了大量压测！这些具体测试都可以丢给 AI 来跑，让他给你出分析报告
 |  |
最终才确定两条既便宜、又相对稳定的链路。
目前image2 的 2K、4K 图片稳定生成这块，还没找到足够好的供应商，仍在摸索中。
第二个坑：任务边界不清楚，AI 会把另一条路改坏
Vibe Coding 做 demo 很快。但做正式产品，最怕的是任务边界不清楚。
因为 Codex 很擅长局部修复。你告诉它发布列表有问题，它会去修发布列表。你告诉它上传图片有问题，它会去修上传图片。你告诉它二维码有问题，它会去修二维码。
但如果这些功能共用同一套图片、同一套状态、同一套计费规则，它修一处，就可能影响另一处。
比如只修发布列表，改坏 AI 改写页。只修上传图片，改坏插件导入。只看前端状态，忘了后端真正保存的状态。
这类问题很隐蔽。
因为每次修完，局部看起来都对。但用户一走完整流程，就出问题。有一次我甚至花了快两天时间重新梳理、串联整个图片管理链路。
这也是我前面说的：AI 需要外置记忆。
因为它不知道你过去为什么这么设计，它只看到眼前这个 bug。
如果你不给它边界，它就会用最直接的方法修眼前问题。
所以后来我给 Codex 的任务会写得很细：哪些老路径必须保留，改完以后必须跑哪些回归测试。如果影响图片、积分、发布这类共享链路，必须把相关路径都测一遍。
产品开发不是由一个个眼前问题拼起来的。产品是由一套长期规则撑起来的。
Codex 可以很快把功能做出来，但正式产品真正考验的是稳定服务。
也是我最想提醒所有想用 AI 做产品的人：
不要被第一个 demo 跑通的兴奋骗了。那只是产品有了心跳。真正的产品，是它在真实用户反复使用、反复出错、反复恢复之后，还能继续稳定跑。
五、10 天变现 1w+ 是怎么来的
最后说一下大家最关心的变现。这个部分其实没有那么神秘。
不是产品上线以后，我出了什么爆款，然后陌生用户疯狂涌进来。
真实情况很简单：
我们发了 2 篇公众号文章。朋友圈做了一下宣传。
付费学员社群里也同步了一下。然后第一批种子用户就来了。
十来天，积分充值超过 1w。
 |  |
文章发布当天，还带来了几单知识付费课程的成交。那个算额外收入，不算在工具积分充值里。要不然就有好几万了
本身我们会有很多过去的积累，没有这些积累，同样一个产品发出去，结果可能会完全不同。
工具 + 服务，不要单独卖工具
国内做工具，对小团队来说其实不容易。不是因为大家完全不愿意付费。
而是用户的选择太多了，免费的也多，便宜的也多，能替代的也多。
你单独拿一个小工具出来卖，用户会很自然地问：
为什么我要用你的？
为什么我要现在付费？
这个工具会不会过两天就没人维护？
所以早期工具变现，本质上卖的不只是功能，还包括信任。
用户相信你会持续迭代，相信出了问题有人能解决，相信你不会跑路。
这也是为什么第一批用户基本来自已有内容和已有关系的积累。
另外我现在越来越觉得，小团队做工具，最好不要把工具孤零零地放在那里卖。尤其是在国内。
单独卖工具会很难。 因为用户会拿你和所有免费工具、低价工具、大厂工具、开源工具比较。
一比较，很容易陷入功能战和价格战，小团队根本打不赢。
但如果工具接在服务后面，情况就不一样。
比如我本来就在做小红书虚拟电商和培训陪跑。这时候工具不是一个孤立商品。
它是整个服务体系的一部分。工具帮学员提效，学员使用过程里的反馈，又反过来帮工具迭代。工具用得好，学员更容易做出结果。
工具给服务提效，服务给工具导流。这个闭环就跑起来了。这比单独卖一个软件要稳很多。
这段经历也验证了一个很重要的判断：
用户更愿意为完整工作流服务付费，但前提是这个工作流接在真实业务和真实信任上。
做产品的能力，是从垃圾里磨出来的
这个 AI 工作站是我在 AI 产品这条路上，做的第三个能让人直接付费的东西。
在这之前，我做过浏览器插件、影刀 RPA 脚本、小工具变现、桌面软件——全是垃圾。bug 一堆，功能难用，经常被用户拉去远程调试，很多时候我自己都觉得尴尬。
自己尝试了很久，没参加任何课程，没找任何人请教，就靠自己瞎琢磨。
但这些尝试没有白费。它们让我慢慢知道用户到底在哪些地方卡住，也让我知道一个工具从"能跑"到"能收钱"之间差了多少东西。
直到今年，才慢慢做出几个真的能拿出来独立收费的东西：
小红书扫码发布的飞书字段捷径——一个在飞书多维表格帮大家发布小红书笔记的工具，现在每个月大概带来一两千收入，虽然真的不多，但也是一个正向闭环。
 |  |
后来又做了小红书虚拟笔记工具箱，可以帮小红书虚拟卖家导出文件、做笔记排版、上传飞书等，现在付费几十个人，收入也破万了。
 |  |
再到这次小红书 AI 工作站，才有了十来天积分充值超过 1w 的结果。
它更像是一堆早期烂产品、一堆用户反馈、一堆失败尝试之后，终于慢慢长出来的一个阶段性结果。
做产品的能力，不是想明白才开始。而是在学中干，在干中学！一开始做得烂真的很正常。
你要真的把东西做出来，让用户用，让用户骂，让用户付费，让用户告诉你哪里不顺。
然后一版一版改就好了！
结尾：两个值得带走的判断
AI 内容的核心不是 AI 率，而是信息密度
我现在越来越确定一件事：
AI 内容的核心，不是 AI 率，而是信息密度。
很多人把问题理解错了。以为只要不被识别成 AI，内容就安全了。
但真实情况刚好相反。
一篇笔记如果没有真实经历、没有具体细节、没有可验证的判断，就算它是人写的，也很难跑出来。
一篇笔记如果有真实素材、有明确观点、有具体场景，AI 只是帮你提高表达效率、提高生产效率，它反而更接近平台想要的"有用内容"。
所以未来真正的差距，不是你会不会用 AI 生成内容。
而是你有没有能力判断：
什么内容值得生成。什么素材值得改写。什么角度值得发布。
什么表达只是看起来很顺，但其实没有信息量。
这才是反直觉的地方：
AI 降低的是生产门槛，提高的是判断门槛。
以前不会写，可能自己也懒得发。以后人人都能写出来、发出来，但大多数内容依然没人看。
因为平台不缺内容。平台缺的是有信息密度、有真实场景、有用户价值的内容。
就拿这篇文章来说，文字是 Claude 写的，图片是 GPT-image-2 生成的，飞书排版是 lark-cli 完成的，AI 深度参与了全程。
但这个过程中，我的判断、我的思考、我的真实经历，就是 AI 替代不了的。
AI 不会替你做产品，只会放大你的产品能力
AI 编程最容易给人一种错觉：
好像只要我会提需求，就能快速做出产品。
但这次做完以后，我反而更确信一件事：
AI 不会替你做产品。它只会放大你原本的产品能力。
需求没想清楚，它会更快地做错。
流程没设计好，它会更快地制造混乱。
边界没说清楚，它会更快地把一个局部问题修成系统问题。
真正起作用的，是判断这个需求是不是真的痛，能不能抽象成一条闭环，能不能拆成一项项 Codex 能执行的任务，能不能在产品跑起来以后判断它有没有真的解决问题。
这些能力，过去产品经理需要。现在 AI 编程时代反而更需要。
因为执行变快以后，错误决策的代价也会被放大。你会更快地拥有一个没人用的功能。
这种做产品的感觉需要持续练，先从一个很小、很具体、很痛的需求开始。
哪怕第一个版本很烂，哪怕被用户骂，哪怕 bug 一堆。做出来，卖出去，听反馈，再改。
我相信产品能力就是这么长出来的，不是想出来的，是被真实问题慢慢磨出来的。
我们只是刚好可以用 AI，能把这个过程压缩得更快了一点。
但真正有价值的，还是那件最笨的事：
持续解决真实问题，先做一个垃圾出来！
我有一个社群，针对小红书从业者的，你能获取很多高价值信息差，详细介绍是这篇文章👇
还要一个陪跑服务，是关于小红书虚拟电商的，一个月入过万不算难的副业👇
更绪&尹星河——小红书虚拟电商4.0陪跑，标准化 + 工具化 + AI原创化！
==全文完==
本文原创首发于公众号：日更一绪作者：更绪，流量蜂传媒创始人，充满激情，雅俗共赏，互联网圈最潇洒的00后，
微信：gengxu04，分销与狗，不得加我好友（淘金之路和生财有术除外）
