一句话看懂：一位不会编程的《诗经》爱好者，用 AI 编程工具 Codex 和音乐生成模型 MiniMax-Music，在 20 天内做出一张可交互的《诗经》地理地图，并为全部 305 首诗生成了 AI 歌谣。这个案例的价值在于：当 AI 让“做出来”变得容易，作品质量反而更依赖人的判断与审美。
事件核心：发生了什么
7 月 28 日，少数派作者“好奇的阿哲”发布了一个名为“诗经山河图”的网页应用。项目从 2026 年 7 月 2 日启动，作者本人不会编程、未写一行代码，而是通过对话式 AI 编程工具 Codex 构建了可缩放、可交互的历史地图原型，并在之后 10 天内完成全部 305 篇《诗经》内容的地理标注、文本注解和译意校对。
随后，作者为了让《诗经》恢复“歌”的属性，又用音乐生成模型 MiniMax-Music 为 305 首诗制作歌谣。据作者统计，整个过程中共生成 2837 个音乐候选版本，并搭建了一个内部“听审台”，由机器先检查读音、旋律与情绪，再人工试听筛选。项目于第 20 天上线 2.0 版本，地址为 songs.campzhe.com。作者也在文中披露了与产品的直接利益相关关系，并承认 305 首歌谣中仍存在错音、漏唱等问题。
为什么重要
这个案例有双重意义。第一，它展示了当前大模型在“个人完整项目交付”上的能力边界：Codex 负责将文字描述转化为可运行的交互应用，MiniMax-Music 负责将文本转化为音乐，加上人工内容验收，形成了一条完整的 AI 辅助生产链路。第二，它更清晰地划出了“做出来”与“做好”之间的分界线——AI 能把 305 首诗迅速摆上地图，却无法判断译文是否自然、旋律是否贴合诗篇的情绪、换行是否破坏了诗歌的节奏。
换句话说，AI 降低了执行门槛，但把更多“定义标准”的责任推给了人。这在 AI 应用从单点生成走向复杂系统的过程中，是一个具有代表性的现象。
对用户/开发者/创作者的影响
对普通用户和内容创作者，这是一个可复制的创作范式：不需要先掌握编程或音乐制作，而是从“我想要什么”出发，把 AI 当作快速生成原型的工具，再通过反复反馈修正结果。作者的实际工作流是“描述不满意之处→AI 修改→继续人工验收”，其中表达和审美能力的重要性超过了技术能力。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对开发者而言，这个项目展示了组合多个 AI 服务（聊天式编程工具 + 音乐生成模型）构建复合应用的可行性。目前公开信息显示，作者使用的技术方案均为现有商用或开源工具的集成，而非自研模型；这意味着类似的“AI 组装式应用”开发成本已经降到个人可承受范围。
对 AI 行业观察者，值得注意的还有其中的数据点：305 首诗的最终版本，背后是 2837 个候选音乐片段。AI 生成并未省去筛选和判断，而是把工作量从“制作”转移到了“选择和修正”。
值得关注的后续
一是作者是否会开源这个项目的代码和内容数据，如果开放，其他文化主题（如《楚辞》、唐诗地理）可能很快出现类似应用；二是 MiniMax-Music 等音乐生成模型在多音字、生僻字发音和情绪控制上能否继续改进，将决定 AI 歌谣是否能从“能听”走向“耐听”；三是这个项目的长期维护方式——305 首歌谣的听审纠错依赖社区反馈，作者是否会公布听审台或纠错入口，有待观察。
来源：sspai
