夜雨聆风用官方技能规范和开源音乐模型，搭一条可重复、可留证的本地创作流程。
很多人搜索“AI 音乐怎么过原创”，真正想解决的不是某个检测技巧，而是两个更基础的问题：音乐是不是自己参与创作的，以及出了争议能不能拿出过程证据。
先说结论：没有任何源码、提示词或工具能保证通过所有平台的原创审核。更稳妥的做法，是从歌词、音乐描述、生成参数到后期工程都由自己完成并留档，再把这套流程交给 Codex 重复执行。
这周值得关注的组合，是 Codex 的技能机制和开源项目 ACE-Step 1.5。前者把重复步骤固化成工作流，后者在本机生成音乐。两者接起来，才是一套能长期复用的生产方式。
一、为什么用“技能”，而不是每次重新问
Codex 技能可以理解为一份给 AI 的标准作业说明书。它的核心文件是 SKILL.md，里面写清楚什么时候触发、按什么顺序执行、最后检查什么。
OpenAI 官方 Skills Catalog 在 2026 年 7 月 22 日的公开快照中有 24,054 个 Star；官方 Codex 仓库有 100,630 个 Star。需要说明的是，GitHub 没有单个技能的独立点赞榜，所以这些数字只能证明相关官方项目受到较高关注，不能写成“某技能本周点赞第一”。
对普通创作者来说，技能的价值很直接：第一次把流程写清楚，后面每首歌都能按同一标准保存提示词、歌词、参数和成品，不容易漏步骤。
二、先把 ACE-Step 1.5 跑起来
ACE-Step 1.5 是可本地运行的开源音乐生成项目。官方仓库在同一时间点有 11,753 个 Star，并提供 Windows、macOS、Linux 的安装方式和本地 API。
电脑需要 Python 3.11 或 3.12。官方建议有独立显卡，基础模式约需 4GB 显存，启用语言模型规划时建议 6GB 以上；第一次运行还要下载约 10GB 的核心模型。
在 PowerShell 中依次执行：
1 2 3 4
git clone https://github.com/ACE-Step/ACE-Step-1.5.git
Set-Location ACE-Step-1.5
uv sync
uv run acestep-api 看到服务运行后，在浏览器打开 http://127.0.0.1:8001/health。如果返回状态正常，说明本地音乐接口已经可用。
为什么要先检查健康状态？因为后面的错误如果来自服务没启动，继续改提示词没有意义。这个检查点能帮新手快速区分“环境问题”和“创作参数问题”。
三、用一段源码生成并保存音乐
新建 generate_music.py，安装请求库：
1
uv add requests 然后粘贴下面的代码：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67
import json
import os
import time
from pathlib import Path
import requests
BASE_URL = "http://127.0.0.1:8001"
OUTPUT_DIR = Path("music_output")
OUTPUT_DIR.mkdir(exist_ok=True)
api_key = os.getenv("ACESTEP_API_KEY", "")
headers = {"Content-Type": "application/json"}
if api_key:
headers["Authorization"] = f"Bearer {api_key}"
payload = {
"prompt": (
"warm electronic pop, original chord movement, clean female vocal, "
"bright synthesizer, restrained drums, hopeful mood"
),
"lyrics": "[Verse]\n把清晨写进风里\n让新的旋律慢慢醒来",
"thinking": True,
"vocal_language": "zh",
"audio_format": "wav",
"audio_duration": 90,
"bpm": 108,
"key_scale": "D Major",
"time_signature": "4",
}
task = requests.post(
f"{BASE_URL}/release_task",
headers=headers,
json=payload,
timeout=60,
).json()
task_id = task["data"]["task_id"]
while True:
query = requests.post(
f"{BASE_URL}/query_result",
headers=headers,
json={"task_id_list": [task_id]},
timeout=60,
).json()
item = query["data"][0]
if item["status"] == 2:
raise RuntimeError("生成失败，请查看本地服务日志")
if item["status"] == 1:
result = json.loads(item["result"])[0]
audio_url = BASE_URL + result["file"]
audio = requests.get(audio_url, headers=headers, timeout=300)
audio.raise_for_status()
(OUTPUT_DIR / "original-demo.wav").write_bytes(audio.content)
(OUTPUT_DIR / "creation-record.json").write_text(
json.dumps(
{"task_id": task_id, "input": payload, "result": result},
ensure_ascii=False,
indent=2,
),
encoding="utf-8",
)
break
time.sleep(5)
print("已保存音频和创作记录") 运行：
1
uv run python generate_music.py 代码会同时保存 WAV 音频和 JSON 创作记录。JSON 不是“原创证明书”，但它能保留歌词、提示词、任务编号和生成参数。出现争议时，有过程记录总比只有一个成品文件更有解释力。
如果你给本地 API 设置了密钥，只把密钥放进环境变量 ACESTEP_API_KEY，不要写进代码、截图或文章。
四、把这段流程封装成 Codex 技能
接下来调用 Codex 自带的 Skill Creator，让它创建一个名为 ai-music-original-workflow 的个人技能。给 Codex 的任务可以这样写：
1 2 3 4 5
使用 Skill Creator 创建 ai-music-original-workflow 技能。
当我要求生成原创 AI 音乐时，先检查本地 ACE-Step API 健康状态，
再读取我提供的原创歌词和音乐描述，调用生成脚本，
最后保存音频、创作记录和原创自检清单。
不得模仿指定歌手，不得承诺通过平台审核，不得在文件中保存密钥。 一个合格的技能至少要有 SKILL.md，需要稳定执行的代码放进 scripts 文件夹。创建后还要运行官方校验器，确认技能名称、YAML 头部和目录结构没有错误。
为什么不直接把几十行代码全塞进 SKILL.md？因为说明和程序分开后，Codex 读起来更省上下文，脚本也更容易单独测试。对用户的影响是：以后改生成逻辑时，只更新脚本，不必重写整份工作流说明。
五、发布前做四项原创自检
第一，歌词必须是自己写的，或已经取得明确授权。不要把网络歌词换几个词就当原创。
第二，提示词描述曲风、情绪、乐器和速度，不写“模仿某位歌手”或“做成某首歌一样”。风格相近不等于侵权，但点名模仿会明显增加争议风险。
第三，把生成结果导入自己的数字音频工作站，也就是常说的 DAW，重新处理结构、音色、混音或人声。人的实质性创作参与越清晰，作品过程越完整。
第四，保留歌词草稿、提示词、生成记录、工程文件和导出时间。平台如提供原创声明或版权检测入口，按平台当时规则提交，不能用技术手段绕过检测。
这四步不能替平台作出最终判定，却能把“想办法过检测”变成“真正建立原创过程”。长期做账号，后者才有复用价值。
总结
Codex 技能解决的是重复执行，ACE-Step 1.5 解决的是本地音乐生成，创作记录和人工后期解决的是可解释性。把三者连起来，你得到的不是一个“保证通过审核”的按钮，而是一条更稳妥、可检查、可持续改进的音乐生产线。
你更想先自动化哪一步：写歌词、批量生成，还是发布前的原创自检？
