一个亚马逊运营的
Vibe Coding
你可能听过这些词
它们正在改变"做东西"的方式
用自然语言"对话"编程
不写代码，而是描述你想要什么。Agent 负责翻译成代码、部署、调试。你说需求，它出产品。
关键词：自然语言 → 产品
One-Person Company
一人公司
一个人 + AI = 一个团队的能力。产品、运营、开发、部署，曾经需要多个角色的事，现在一个人就能闭环。
关键词：个体 × AI = 团队
Frontend Deployment
Engineer 前端部署工程师
2025 年因 AI 而兴的新职业。不写后端、不管数据库，专注用 AI 把产品从想法变成可访问的网页。
关键词：想法 → 网页，一人完成
这不是一场
纯技术分享
类型还是亚马逊平台技能分享，所以重点不是“我会不会开发”，而是“AI coding 能不能直接帮助运营解决业务问题”。
先认识 Agent 是什么
很多人已经在用云端 Agent，但常见用法仍然停留在聊天式提问。
再纠正错误预期
自然语言编程不是一句话神奇实现全流程，它依赖上下文、工具、数据和迭代。
再回到运营场景
红人筛选、评论调研、竞品监测、批量信息整理，本来就很适合被重做成工具。
最后用作品说话
我做的 YouTube 评论调研工具，不是概念页面，而是已经拿去给同事真实试用了。
很多人的使用层级
还停在聊天框
我之前整理过一份 AI 学习路线图。现在回头看，它依然有用：先分清聊天、工作流、工具链和 Agent，很多误用自然就容易解释了。
把 Agent 当聊天框
体验一定会打折
适合轻量任务、提纲、初步整理、快速试思路。
更适合把代码、文件、终端、项目环境和工具真正接起来，推进一段复杂流程。
决定效果的不是一句神 Prompt
而是能力是不是接全了
上下文
你是谁、你要解决什么问题、什么叫结果合格，这些都要说清楚。
API 与工具
没有接口、没有浏览器能力、没有执行环境，很多需求天然就做不完。
数据源
如果 Agent 拿不到你真正需要的数据，它再聪明也只能做表面文章。
反馈迭代
第一版通常很粗糙，真正的价值来自持续修正，而不是一次成片。
本地 Agent 并不是一个单点产品
而是一类工作方式
刚才聊的是 AI 能做什么
接下来看运营怎么用 AI
从一个真实的车型调研出发：用 Vibe Coding 的思路，把"搜视频 → 翻评论 → 手工记录"这条每周都在重复的动作，变成一个有入口、有输出、能分享的工具。
我做这个工具的起点
是一次很具体的车型调研
动作非常原始：搜索、点开、看视频、看评论、手工记录。能看的样本很少，重复信息又很多。
这不是普通闲聊，而是一个具体的产品使用限制。我继续去官网核对，发现官方也明确写了这件事。
评论不是噪音
它可以成为可验证的洞察
不写一行代码
用自然语言把业务动作变成可运行的工具
要做什么
Data API v3
→CSV 一条链路
拿到可分享链接
品牌设计、暗色模式
持续修 bug
从“我自己手工翻评论”
变成一个可重复使用的调研入口
关键词找视频
先从车型、品类、竞品或红人关键词出发，而不是先拿到一个视频 URL。
批量筛选勾选
先把有价值的视频集中起来，再决定看哪些评论，而不是反复打开同类结果。
评论导出成数据
评论被结构化后，后续才有翻译、汇总、关键词提取和 AI 分析的空间。
给业务动作提速
它不是一个“给开发者看的作品”，而是一个把调研动作压缩下来的业务工具雏形。
真正证明价值的
不是我觉得它有用
而是别人真的会用
同事给我的，不是泛泛的“不错”
而是很具体的业务反馈
“这个工具最大的用处，是可以找到对应车型的红人视频。如果能直接跳转到 YouTube，我就能直接看评论，不用导出了。”
“我自己找的话，YouTube 会不停给我显示重复的红人。”
“导出字幕很有用。”
“会用评论作为参考数据来源之一。如果能同时搜 Reddit、Facebook 就更好了。”
“批量导出不错，就是关键词搜索出来很多不是我的检索目标。”
“真实用户反馈很有参考价值。能不能加自动翻译功能？”
“没有全选、不能自定义排序、导出结果看不懂，挑出来的 bug 足够你改了吧。”
“导出速度挺快。有没有翻译、预览评论、点标题跳转视频页这些功能？”
“YouTube 对有些品类评论密度不高，但如果真能抓下来做分析，还是有参考价值。”
这批反馈至少说明了四件事
需求是真实的
不同岗位都能立刻说出可用场景，说明它不是我自嗨出来的需求。
问题也很真实
全选、排序、跳转、翻译、预览，这些都是业务使用里立刻暴露出来的摩擦。
边界也被看清了
不是所有品类都适合强依赖 YouTube 评论，信息密度和样本量会决定价值上限。
迭代方向出现了
下一步不只是“继续写代码”，而是围绕真实反馈补功能、做判断和扩数据源。
每周都重复、步骤固定、又有点无聊的事
最适合先被 Agent 化
手工点 Listing
逐条看反馈
Excel 筛选
人工贴标签
搜视频、看评论
手动汇总
多页面记录
再整理变化
多后台核对
再拉清单
多账户导出
拼表汇总
定期检查页面
和内容异常
高频、重复、步骤固定、数据驱动
Agent 真正压缩的
是判断前的那些动作
它们不是谁替代谁
而是谁更适合哪段流程
真正被放大的
不是写代码的手，而是你的业务判断
你先识别问题
哪些动作高频、低价值、重复，又确实影响效率，这个判断只有业务一线最清楚。
你再定义流程
目标、边界、数据源、验收标准，都是把业务动作翻译成可执行流程的关键。
Agent 负责实现
它把工具、接口和执行步骤组织起来，让你更快得到可运行的第一版。
所以才可能 1 + 1 > 2
业务能力决定方向，Agent 决定速度，真正的增量来自两者叠加，而不是单独任何一方。
不是所有场景都强需要它
但这不影响它在对的地方很有价值
如果某个品类在 YouTube 上评论本来就少，信息密度有限，工具价值自然会打折。
接口权限、抓取稳定性、搜索精度和翻译能力，都会直接影响业务体验。
Agent 不替你判断什么信息有价值，它最多只负责把“找”和“搬”的动作缩短。
所以正确做法不是全盘替换，而是先在高频、重复、可验证的场景里做试点。
你做 YouTube 评论，和亚马逊运营有什么关系？
YouTube 里大量 UTV/越野车评测评论，就是我们目标客群的真实声音。选品灵感、竞品弱点、用户真实关注点，都可以从这些评论里提炼。
为什么前面一直没提网站，到最后才看到成品？
故意的。因为成品工具甚至不是重点——真正有价值的是这个过程中，你有意识地去 coding、去和 AI 对话、去解决一个个报错，在这个过程中主动学到了 API 原理、部署逻辑、前端设计……每一次对话都在扩展自己能力的边界。工具只是副产品，能力才是资产。
Agent 写的代码靠谱吗？埋了坑我看不出来怎么办？
实话：不会 100% 完美。但 vibe coding 的核心不是"相信代码"，而是"发现报错 → 贴给 Agent → 快速修复"。跑得通的工具，就是好工具。
我们团队想试，第一步做什么？需要什么技术背景？
第一步：找个每周重复 3 次以上的手动操作。然后对着 Codex 描述你的需求。不需要会写代码——你需要的是把业务需求说清楚。
你花多长时间？值不值？
从描述需求到可用网页版，累计约 6-8 小时（零散对话）。外包同等质量至少 2 周 + 数千元。更重要的是：做完你就拥有了这个能力。
这玩意能长久用吗？会不会哪天突然不能用？
数据源变化是常态（API 改版、网页改结构），但只要你能和 Agent 对话，就可以让它适配。这套能力不会因为一个接口挂了就废掉。
如果让我把这次经历压缩成三条结论
自然语言编程不是一句话魔法
真正有效的做法，是目标更清楚、资料更完整、反馈更连续，而不是追求一条万能提示词。
先把最小版本跑起来再说
第一版不漂亮、甚至有 bug 都没关系。能先跑起来，迭代成本就会比想象中低很多。
真实试用比自我想象更重要
很多下一步不是我先想到的，而是同事在试用时直接指出来的。业务价值是在使用里长出来的。
不用一上来追求大系统
先跑一个真实业务试点就够了
AI coding 对运营真正重要的地方
是让个人方法开始可以被规模化
以前是你自己知道怎么做，现在可以把动作拆出来，沉淀成一个别人也能复用的流程。
以前是你手工执行判断前的动作，现在可以让工具先帮你完成收集、整理和初筛。
当业务理解能被做成小工具，个人效率就不再只是个人效率，而会变成一种能力杠杆。
AI coding 已经开始被放进
运营能力提升的讨论里
这不只是我个人的感受。Simon 上次分享里提到“AI 代码能力”是亚马逊运营个人能力规模化的路径之一，这本身就是一个很强的信号。
运营的价值不再只体现在手上做了多少，还会越来越体现在你能不能把自己的方法、判断和动作做成可复用的杠杆。
先把问题
翻译清楚
再让 Agent 去执行
🤖 别把 Agent 当成更会聊天的 Chat Bot
复杂任务的质量，取决于目标、上下文、工具、数据和反馈，而不是一句神奇提示词。
💻 本地 Agent 的优势，是更容易把能力真正接进来
API、数据库、文件、浏览器、执行环境，这些决定了它能不能真正推进业务流程。
🧠 业务能力 + Agent，才更可能做到 1 + 1 > 2
真正被放大的不是“会不会写代码”，而是你识别问题、定义流程、判断价值和持续迭代的能力。
Vibe Coding 了一个
亚马逊评论抓取
是一个可部署、可分享、有激活管理的完整工具
→ 抓取真实评论
→ 去重 · 筛选 · 导出 CSV
Thank You
Questions & Discussion Welcome