这篇值得看在哪里
作者从生财有术 MCP 的每日监控起步，筛出 AI 赋能本地生活流量方向。随后用 Hermes、Codex 和多 Agent，把《AI 同城流量超级术》中的内容生产流程做成视频工作台。离线测试共 253 项通过，但公网长期稳定运行仍待验证。
项目起点不是写网站，而是先从社区数据筛选方向
作者的起点是内测生财有术 MCP，并在 Hermes 上搭建每日帖子监控流程。过去他主要依赖搜索、收藏和人工整理，信息变多后很难判断哪些方向持续升温，也难以把案例变成项目清单。接入 MCP 后，帖子被转成可统计、检索和结构化处理的数据。作者进一步统计近一年、半年和三个月的精华帖与生财好事，结合自己的 AI 技术背景、Hermes 和 Agent 能力、真实业务场景、验证成本以及成交交付距离筛选方向。最终锁定 AI 赋能本地生活流量，并为父母开发视频号图书带货平台。这里的关键判断不是追逐帖子数量，而是选择已有资源、能较快形成闭环的方向。
他把《AI同城流量超级术》缩成一个具体的视频生产工作台
实战对象不是抽象的 AI 概念，而是《AI同城流量超级术》中服务同城获客的内容生产方法。作者没有把选城、选品、发布、投放、线索承接和成交复购全部塞进第一版，而是选择边界清楚、重复频率高的“参考内容拆解—创意改造—视频生成—人工审核—成片交付”链路。系统面向的是内容供给问题：上传参考视频和人物或商品素材后，完成镜头拆分、片段筛选、关键帧生成与审核、视频任务调用、原片复用、音频处理和成片导出，并记录状态以支持中断恢复。这个取舍让项目从完整业务愿景收缩为一个可重复使用、可审核的生产工具，也保留了人工审核这一道质量闸门。
真正的开发产物是业务动作与系统动作的对应关系
作者先让 MCP 读取精华帖，提炼流程节点、输入、操作、判断条件、输出、资源、自动化可能性和风险点，再把每个 SOP 节点改写成独立模块。比如“把视频改成我的人物”并不足以让程序稳定执行，还要明确参考图来源、哪些镜头需要修改、什么状态才允许调用付费接口、失败后如何继续以及文件如何保存。因此他把系统拆成路由、流程、服务和状态四层，并将图片、视频能力抽象为可替换供应商接口，开发阶段可用 Mock，联调时再接入 AutoDL ComfyUI 或 MiniMax。原文还记录了一个具体修正：需求过于宽泛时，Codex 会生成重复工具函数和状态判断；明确模块输入输出、审核闸门、任务互斥和轮询状态后，代码职责才稳定。
测试结果证明了可部署架构，但还不能等同于真实业务上线
项目使用 Python 3.11、FastAPI、Uvicorn、Jinja2 和原生 JavaScript，本地能够走通创建项目、拆镜、审核、生成和导出流程。仓库记录了 Python 编译检查和前端语法检查通过，完整离线测试共253项通过，测试还覆盖状态文件、路径安全、任务互斥、异常恢复和媒体处理。部署侧已准备 Docker、环境变量模板、健康检查、持久化卷，以及 Caddy 或宝塔 Nginx 的方案。不过作者明确区分了工程完成度和经营结果：当前证据只能说明已形成可部署架构和上线清单，不能证明系统已在真实公网长期稳定运行，真实供应商、对象存储、浏览器端到端和压力测试仍是上线前事项。因此，这更适合有明确内容业务、能理解 SOP 并愿意参与审核和验收的人继续研究，不适合只想让 AI 自动生成页面的人。
根据作者原帖及所附飞书文档整理。完整实操与材料见原文。
原文还会展开这些问题
- 生财有术 MCP 如何把社区帖子转化为项目方向信号？
- 作者为何选择《AI 同城流量超级术》作为实战对象？
- 视频生产工作台为什么只先覆盖内容生产环节？
- SOP 如何被翻译成 Codex 能执行的系统模块？
- 多 Agent 协作怎样避免职责重叠和结果失控？
- 当前测试通过为何仍不能证明网站已长期稳定运行？
原作者原话
最重要的产物不是代码，而是一张“业务动作—系统动作”的映射表
AI 编程降低了写代码的门槛，却提高了定义问题的价值
以上为原帖简短摘引。作者：Jason、mar。完整内容及访问条件以生财有术原帖为准。
