当学生说"Common App 活动栏写不下"、"这段活动描述超字数了"、"帮我把这几条压到限制内"时使用。先按官方申请表核对当季字符限额,再逐条检查;一次把所有条目量完并直接给出压缩版,只在需要砍掉实质内容时才用选择题问该保哪部分。每改一版都用工具重新数一遍字符,绝不凭感觉说"这样应该够了"。只压缩,不代写空白。
日本語の概要は準備中です。原文の説明を表示しています。
当使用者说"让 AI 写谱不要直接生成音频"、"做一个 AI 作曲的后端"、"LLM 输出 MIDI 怎么做"、"生成的音符老是越界/被截断"、"要能导出 .mid 给 DAW"时使用。
用 LLM(BYOK / OpenAI 兼容接口)从零生成可用的管弦乐 MIDI 与分轨音频:两级调用(整曲和声蓝图 + 逐乐器音符表)、提示词结构、被 max_tokens 截断时的残稿抢救、确定性校验修复、渲染与 MIDI 导出,以及全程的规则作曲降级策略。降级事实必须如实写进元数据,不假装是模型写的。
参考实现是 MaestrWave 的 M7 写谱演奏模式。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
从「调音频模型要一段 WAV」换成「AI 先写谱、采样器再演奏」时,产物仍是每件乐器一条音轨,下游(浏览/播放/混音/指挥)无感知,同时谱子落盘可导出 MIDI。核心是一条流水线:
蓝图(LLM 写和声走向)→ 分谱(LLM 每件乐器写音符)→ 校验修复 → 渲染成音轨 → 落盘 + 导出 .mid
.mid 供 DAW / MuseScore 使用不适用于 / Not for:
adversarial-lyric-writer 那一组用 chat_json(严格 JSON + 自动重试,temperature 偏低如 0.5),失败可退回规则和声(它只是分谱的参考,不该阻塞整曲)。
输入:调性、拍号、BPM、总小节数、风格描述、段落结构(每段的起始-结束小节 / 强度 / 是否高潮)、调内可用三和弦(允许 7 / maj7 / m7 / sus4 / 转位)。
输出要求:{"chords": ["每小节一个和弦符号", ...]},数组长度必须等于总小节数;每段最后一小节收束、全曲结尾回主和弦。
配套机制:
revision 号;调性/速度/拍号/时长改过后重建,旧声部标注"按旧蓝图写的",不自动重写已有声部(省 token)。asyncio.Lock,防止用户连点两件乐器时第二个请求把蓝图覆盖。每件乐器调一次。这是生成 MIDI 的核心步骤。
System 提示词要求只输出一个 JSON:
{"notes": [[小节, 拍, 时值, 音高, 力度], ...]}
字段全部是数字:小节从 1 开始不超总小节数;拍从 1 开始、0.25 的整数倍、小于每小节拍数+1;时值以拍为单位最小 0.25 允许跨小节;音高为 MIDI 音高必须在给定音域内;力度 1–127。
硬性要求(写进 system prompt):
User 提示词拼入:
第N小节: 和弦 逐行)已有声部的压缩视图:旋律声部给全量音符(新声部要跟着它走,且数量上限约 220 个才全量);其余声部只给 每小节: 音符数/音区min-max 的摘要。不压缩 token 直接爆。
用 chat_text 而非 chat_json:
chat_json 解析失败就整份丢弃重试。音符表动辄上千数字,最常被 max_tokens 截断,重来既慢又费额度。chat_text 返回原始文本、不做自动重试,让代码有机会从残稿里抢救。max_tokens 必须显式放大(如 12000)并显式发送。各家兼容层默认上限差很远,Anthropic 兼容端点强制要求该字段。残稿抢救算法(不要求整段是合法 JSON):
json.loads 整段试;支持剥掉 ```json 围栏。[小节,拍,时值,音高,力度] 数组(匹配 4~5 个数字的数组,力度缺省给 80)。_NOTE_RE = re.compile(
r"\[\s*(-?\d+(?:\.\d+)?)\s*,\s*(-?\d+(?:\.\d+)?)\s*,"
r"\s*(-?\d+(?:\.\d+)?)\s*,\s*(-?\d+(?:\.\d+)?)"
r"(?:\s*,\s*(-?\d+(?:\.\d+)?))?\s*\]"
)
LLM 输出不直接落盘,先过 validate_and_repair_part(修复而非报错):
part_empty 告警warnings({code, message, count} 形状),前端展示"X 处被修正"renderer.render_part(part, blueprint) → 每件乐器一个 WAV。渲染器可选外部合成器(FluidSynth,混响好)或纯 Python 采样播放器(零外部依赖)。写谱模式用固定增益不归一化,保住配器平衡;各声部采样数严格一致;尾音叠回开头做无缝循环。scores/{take_id}.json;take 参数记录 composer、降级原因、note_count、repairs、beat_grid(谱子本身就是拍网格真值:downbeat 精确落在 0 秒,教学评分直接读它,不需要起始点检测)。| 步骤 | 失败处理 |
|---|---|
| 蓝图(和声) | 退回规则和声表,只记 fallback_reason |
| 分谱(音符) | 退回规则作曲,source="algorithmic" + fallback_reason |
| 分谱输出无音符 | 同上 |
| 分谱输出被截断 | 保留截断前音符,标记截断 |
降级事实写进结果元数据(composer、fallback_reason),前端能显示"这一条是本地作曲写的",不会假装是模型写的。
LLM 走 OpenAI 兼容层 + 自定义 base_url(DeepSeek / 智谱 / Kimi / OpenRouter / Ollama 等均有兼容端点),用 httpx 手写单个 POST /chat/completions,不引 SDK。安全要点:key 只存后端(不落前端/localStorage)、base_url 白名单精确主机匹配、限流、任何接口不回显明文 key。
chat_json 用于大输出 → 解析失败丢整份,且部分 provider 忽略 response_format(400 时去掉该字段重试一次)。composer 和 fallback_reason 必须如实写进元数据并在界面上展示。这是这套设计里最不能让步的一条。{code, message, count} 如实记录并展示。MaestrWave 的 M7 写谱演奏模式:
composer.py:LLMComposer(blueprint + compose_part)、_SYSTEM 提示词、_salvage_notes 残稿抢救、_digest_existing 压缩视图、AlgorithmicComposer 降级score_gen.py:编排层(ensure_blueprint 并发锁、generate_instrument_score、repaint_instrument_score、project_midi)score.py:乐谱结构、和弦解析、validate_and_repair_part 确定性修复midi_out.py:手写 SMF type-1 导出render.py:FluidSynth 与纯 Python 两个渲染器llm.py:chat_text / chat_json、BYOK 通路(白名单/限流/密钥管理)| 版本 | 日期 | 变更 | 类型 |
|---|---|---|---|
| 0.1.0 | 2026-08-12 | 从 MaestrWave M7 写谱演奏模式归档进仓库,补触发场景与边界 | minor |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
当学生说"Common App 活动栏写不下"、"这段活动描述超字数了"、"帮我把这几条压到限制内"时使用。先按官方申请表核对当季字符限额,再逐条检查;一次把所有条目量完并直接给出压缩版,只在需要砍掉实质内容时才用选择题问该保哪部分。每改一版都用工具重新数一遍字符,绝不凭感觉说"这样应该够了"。只压缩,不代写空白。
日本語の概要は準備中です。原文の説明を表示しています。
当学生说"我参加过一些活动但没整理过"、"帮我把经历录进去"、"我的活动档案是空的"时使用。让学生一口气把记得的活动说出来,直接把这段话拆成结构化的长期事项(角色、组织、起止时间、做了什么、结果、级别),说不清的字段留空标"待补"而不是编,再用一张选择题卡把级别判定与是否重复这类关键项一次问完,然后提案入库。只记录学生真正说出口的内容,级别按事实判定,绝不往高了写。
日本語の概要は準備中です。原文の説明を表示しています。
当学生问"招生官会怎么看我的档案"、"我的背景还差什么"、"帮我评估一下现在的申请竞争力"时使用。以顶尖大学招生官的视角通读学生的档案、长期活动与已写下的反思,不问任何前置问题直接产出一份指名道姓的坦诚点评:这份材料的亮点、招生官真实的解读方式、明显的短板与空白、以及接下来最值得做的一到两件事。只读不写,不修改学生的任何数据,也不代写任何申请材料。
日本語の概要は準備中です。原文の説明を表示しています。
当使用者说"帮我填词"、"按这个字数模板写歌词"、"用多Agent对抗式写词"、"这首副歌帮我想几句"时使用,前提是字数骨架和这首歌写什么都已经有了;只有主题、还没定写什么时先用 lyric-concept-builder。拿一份字数骨架和意象系统,派三个 sonnet 子代理按不同路子并行独立起草(场景派 / 口语派 / 意象派),再派一个红队子代理逐句挑毛病,主 Agent 按句裁决拼稿,最后统一辙口与意象。收敛判据卡死:字数用 lyric-doctor 的脚本对模板数、每段同辙、hook 不含陈词、主歌二对主歌一有推进。不抄现有歌词,不替使用者决定这首歌要说什么。
日本語の概要は準備中です。原文の説明を表示しています。
当想知道一段 AI 回答"哪些能直接用、哪些必须先验证、哪些只能当建议"时使用。按声明类型分四级——低风险草稿材料、观点与策略建议、可查证的事实声明、会改变状态的可执行指令——每级配一句默认处置动作;再按影响半径排序,给出最小的下一步检查。可执行类一律标"不能直接执行;先做代码审阅/沙箱测试/回滚准备",其中破坏性或提权的命令排在最前。教的是一套可复用的复查习惯,不是替使用者把所有内容都核实一遍:本 skill 只分级、排序、定处置,要逐条核实走 ai-output-fact-checker,整段代码要做入库体检走 ai-code-onboarding-checklist。
日本語の概要は準備中です。原文の説明を表示しています。
当拿到一段 AI 生成的代码,还没决定要不要信、要不要跑、要不要往上继续加东西时使用。先做一遍客观体检:行数与嵌套深度、有没有测试、有没有硬编码密钥或遗留 TODO、依赖是不是真实存在、有没有危险调用(eval/exec、shell=True、递归删除、反序列化、提权、外发网络,按正文给的 grep 模式逐类查);再给风险评级和下一步动作。老实写明它查不了算法正确性——体检通过不等于代码是对的。回答里文字、事实和代码混在一起时先用 ai-answer-triage 分级;只审相对已有代码的一份改动用 ai-diff-review-protocol。
日本語の概要は準備中です。原文の説明を表示しています。