把海量项目精华帖做成网站：我用生财 MCP + Codex 跑通了一套项目拆解 SOP
Jason、mar原帖作者原文提供的是完整开发流程、踩坑记录，以及仓库测试报告记录的 253 项离线测试通过和可部署架构与上线清单，未给出收入、流水或利润的统一口径，故不作为收益结论。
这篇文章讲了什么
作者以《AI 同城流量超级术》精华帖为对象，走通从社区内容到上线系统的路径：先用生财有术 MCP 统计近一年、半年、三个月精华帖与生财好事的项目分布，结合自身资源筛选方向；再让 Agent 拆解帖子提炼 SOP，并翻译成带输入、处理逻辑、判断条件和输出的开发文档；接着按路由层、流程层、服务层、状态层搭骨架，由前端、后端、开测三个 Agent 分组填充真实逻辑，Mock 先行再逐层替换。文中还记录了弱模型返工、Agent 无限拆分、本地并发拖垮电脑三个坑。
值得读的实操细节
用 MCP 统计选题分布，再结合自身资源筛方向
让生财有术 MCP 统计近一年、半年、三个月内精华帖与生财好事的项目类型和数量，重点看三个维度：哪些方向长期有案例、哪些近三个月增长明显、哪些有持续更新的 SOP 和航海资料。作者强调帖子多不等于适合做，随后把统计结果交给 Hermes，按是否匹配 AI 技术背景、能否复用 Hermes 与 Agent 能力、是否有真实业务场景、能否低成本验证、能否沉淀成工具或 SOP、是否离成交交付足够近来打分，最终锁定 AI 赋能本地生活流量方向。
把帖子拆成可执行 SOP，再翻译成开发文档
作者要求 Agent 按『流程节点→输入→操作→判断条件→输出→所需资源→可否自动化→风险点』的结构输出，同时提炼目标用户、操作步骤、需要人工判断的环节、交付结果与收费复购方式。核心区分是：SOP 写给人看，开发文档写给 Codex 和开发 Agent 看，两者不能画等号；原则是一个业务节点对应一个系统模块，每个模块必须有明确输入、处理逻辑和输出。例如把业务语言里的『把这个视频改成我的人物』，细化为参考图从哪里来、哪些镜头要改、什么状态允许调用付费接口、失败后如何继续、最终文件放在哪里。
先搭骨架再填血肉，三个 Agent 分工、Mock 先行
骨架分四层：路由层只做参数校验、返回结果和启动后台任务；流程层组织拆镜、关键帧生成、视频生成、时长对齐和成片导出；服务层封装 FFmpeg、图片生成、视频生成与对象存储，并把图像视频能力抽象成可替换供应商接口；状态层用项目清单和镜头状态驱动流程，通过原子写入与备份支持断点恢复。开发先用 Mock 跑通流程，再按风险逐层替换真实服务：本地 FFmpeg/FFprobe 与关键帧抽取、图片生成加人工审核闸门、AutoDL 或 MiniMax 视频任务、最后时长对齐与成片导出。前端、后端、开测三个 Agent 分别关注用户能否走通、状态能否正确流转、异常下是否可控。
多 Agent 的收敛规则与模型任务分层
踩坑：给多 Agent 系统权限过宽且未限制层级，总控创建子 Agent、子 Agent 再拆任务，很快接近 100 个子 Agent，导致不知道哪个结果最新、哪些修改可合并、谁对结果负责。收敛规则包括：限制 Agent 总数和最大层级、子 Agent 不允许再创建子 Agent、每个任务只指定一个负责人、禁止多个 Agent 同时修改同一文件、所有任务基于同一版开发文档、每个任务必须有验收标准、由总控汇总并运行测试。模型也做分层：简单整理和格式转换用低成本模型，单文件低风险修改用普通编码模型，跨模块开发、复杂调试与架构调整交给 Codex，最终关键逻辑由更强模型加人工检查。作者还提到曾为省额度把跨模块任务交给 Terra-Max，结果修改互相覆盖，只能重新梳理需求让 Codex 重做。
你能从原帖了解哪些问题
- 01
用 MCP 统计出的『帖子数量多』，与你最终的选题决策之间还差哪些判断步骤？
- 02
把 SOP 翻译成开发文档时，如何判断哪些环节必须保留人工审核，哪些可以交给自动化？
- 03
多 Agent 分组开发中，同一份开发文档如何维护版本，避免前端与后端理解出现分歧？
- 04
文中提到系统尚未证明已在真实公网长期稳定运行，上线前还差哪些生产验收项？
原作者的一句话
AI 编程降低了写代码的门槛，却提高了定义问题的价值。
—— Jason、mar
如果一个任务不值得单独写清楚输入、输出和验收条件，就不值得单独创建一个 Agent。
—— Jason、mar
领取三天生财有术体验卡
扫码领取，在生财有术里阅读更多圈友的实践与复盘。
AI 集市整理于 2026-09-11。项目结果为作者自述；本页为精选解读。
