ARTICLE · 1158481
AI到底怎么用在工作里(4):不会编程的我,竟然做了个小红书运营系统
AI到底怎么用在工作里(4):不会编程的我,竟然做了个小红书运营系统以前觉得做小红书最麻烦的是写内容。后来有了AI，文案几分钟就能出来，配图也能生成，可事实并没有想象中轻松：还是得找选题、看什么内容火、调整图片、安排发布。AI把一个个动作变快了，运营却依然要在几个工具之间来回切换。有一天我突然想，既然流程每天都差不多，能不能干脆让AI替我搭一条“内容生产线”？ 年初，我用Google的Antigravity，试着给自己做了个网站（现在强力推荐用Codex或者Claude Code做，会更加靠谱）。我设想的工作方式很简单：每天开启服务、登录小红书，输入品牌和关键词，网站就去整理相关帖子，按照热度和相关性筛选内容方向；接下来生成文案、生成图片，按照我设定的数量和时间进入发布流程。后台还要能设置内容策略、查看任务队列和运行日志。说起来只有几句话，真做的时候才知道，每一句话背后都有一堆细节。比如热门内容按点赞、收藏还是评论排序？一篇内容要多长？图片不满意是重新生成，还是交给人修改？遇到发布失败要不要重试？这些规则如果没提前想清楚，AI也只能一边写一边猜。 
我又不是程序员，难道还得从零学写网站？其实没必要。一个很实用的办法，是先让AI去GitHub寻找功能相近的开源项目，让它读项目说明、梳理代码结构，再告诉你哪些模块可以借鉴、哪些需要改。如果已经有人做过任务调度或后台页面，就不必每个轮子都重造。当然，代码能找到不等于能随便拿来用，许可证、安全性、维护情况都要先检查。以前我觉得GitHub是程序员逛的地方，现在它更像一座工具零件仓库，而AI能帮普通人看懂里面装的是什么。 网站的框架有了，真正干活的又是谁？答案是API。我把DeepSeek的API接进来负责生成文案，再接入即梦的API生成图片。网站把选题、品牌定位和文字要求送出去，收回文案，再把配图需求发送给图片服务，最后把结果交给后续流程。API听着技术，其实你可以把它想成不同工具之间的传送带。作为业务人员，我最需要说清楚的是三个问题：送进去什么、希望完成什么、拿回来什么。至于接口参数、调用和报错，可以让AI一起处理，但密钥和权限也不能随意交出去。对接前还得确认接口是否正式开放、怎么计费、有多少调用额度，以及返回内容能否用于相应的商业用途。 
看着后台逐渐有了品牌关键词、发布数量、策略设置、任务队列，还真有点兴奋：原来脑子里的一个想法，可以一步步变成能点、能操作的页面。不过高兴没多久，现实就来了。控制台显示“运行中”，任务列表却冒出一个个failed。接口返回异常、字段对不上、图片格式不合适，页面能打开也不代表任务能稳定完成。我只好盯着日志，把报错交给AI，让它修改、再测试。本来是想给自己找个AI运营，没想到先把自己变成了产品经理、测试员和售后。 更棘手的是，小红书不是一个可以随便采集、批量发布的试验场。平台规则、登录方式和风控机制会变化，频繁抓取热点或未经允许的自动发布，都可能带来限流甚至封号风险。让AI不断学习怎么绕过反爬，并不是可靠的长期方案。更稳妥的做法，是优先使用平台允许的数据来源和发布方式，在选题、内容审核和发布环节留出人工把关。尤其是热点，热度高不代表适合品牌，生成得快也不代表值得发。 
折腾这一圈，我最大的收获反倒不是做出了一个网站，而是对“用AI”这件事换了个想法。以前我让它写一篇文案、画一张图，做完就结束；现在我开始让它把几个工具连接起来，尝试完成一段完整的工作流程。对不会编程的业务人员来说，AI最让人兴奋的不是一句话就能造出完美产品，而是有机会用很低的试错成本，把一个想法先做成可测试的版本。 今天是小红书内容工具，明天也可能是客户管理、报价核对或市场监控的小系统。真正的门槛，逐渐从“我会不会写代码”，变成“我能不能讲清楚需求、发现错误、判断风险”。做得出来和用得稳定当然是两回事，但至少以前只能停留在脑子里的想法，现在可以落地实现了。