cat README.md | head -50
momus-skill
一个会"怼你"的 AI 编程助手 Prompt 审查器。名字取自希腊神话中的讽刺之神 Momus——你的 coding 需求写得太烂？先过它这关再说。
// 目录
// 概览
// 一个让我「膝盖中箭」的项目
说真的，跑 GitHub AI 日报这么久，每天都在看各种「帮你写代码更快」的工具。但今天点开 momus-skill 的时候，我有那么几秒是沉默的——这玩意儿不是帮你写代码的，它是帮你审视你写代码时提的那些烂需求的。
项目 README 第一句就写着：「一个会怼你的 skill。当你随便跟 AI 写你的需求的时候，请小心了！」
我回想了一下自己跟 Claude Code 的日常对话——「帮我优化一下这个」「修复那个 bug」「做一个好看的前端页面」——好吧，如果 Momus 在场，我可能已经被怼到怀疑人生了。
这个项目的名字也不是随意的。Momus（摩摩斯）是希腊神话里的讽刺与批评之神，专门挑出神和人类的缺点。用这个命名一个 prompt 审查器，属实有点精准——你在给 AI 提需求的时候，写得太烂？Momus 会像挑剔的神一样告诉你哪里不行。
// 它是怎么「怼」你的
Momus 的逻辑不复杂，但设计得很系统。当一个 coding agent（Codex、Cursor、Claude Code 之类的）收到你的指令时，Momus 会先做一件事：拦住它，审一审这个 prompt 能不能执行。
触发时机
两种触发方式：
隐式触发——你说了「帮我修 bug」「优化一下」「做个前端页面」这种笼统到不行的词，Momus 自动跳出来说「你认真的？」
显式触发——你主动喊 $momus-skill，要求审查 prompt。
我也看了它的不触发清单——普通问题澄清、明确的文件修改、闲聊都不拦截。这个设计还挺聪明的，不会因为审查机制把正常对话搞得支离破碎。
7 维度审查引擎
Momus 从 7 个维度给 prompt 打分，这是它的核心判断框架：
| 维度 | 审查什么 | 烂的典型 |
|---|---|---|
| 目标 | 是否明确说了想要什么结果 | 「帮我搞一下」 |
| 上下文 | 是否有项目状态、报错信息、业务背景 | 直接甩一段代码零解释 |
| 完整性 | AI 原本需要猜测的关键细节是否都给了 | 「做个 dashboard」 |
| 结构 | 请求组织有序、能清晰提取任务与约束 | 大段文字无分段无重点 |
| 有效性 | 仅凭输入，一个合格 Agent 能否正确完成 | 需求自相矛盾 |
| 范围 | 是否明确了检查/修改/创建/避免什么 | 「把所有代码优化一下」 |
| 验收标准 | 怎样算完成，能否验证 | 「做到好就行」 |
这 7 个维度坦白讲没什么革命性的——任何一个有经验的工程师在分配任务时都会下意识做这个检查。但把它系统化成一套 skill，让 coding agent 在执行前自动跑一遍，这个想法我是买单的。
审查后的输出
Momus 不会冷冰冰地抛给你一个「缺陷列表」——它会用硅基生物吐槽碳基生物的语气，带着 playfully sarcastic 的调子指出你的 prompt 问题，然后给出改写后的可执行版本。
来看看一个真实例子——原始 prompt：
经过 Momus 审查和改写后：
最后它会抛一个嘲讽式确认问题——比如「就这水平还想让 AI 给你修 bug？要不要试试用这个版本？」——用户回「可以」就继续执行。
// 8 大领域标准：不只是 coding
我看了它的 references/prompt-standards/ 目录，Momus 不是只有一个通用的 prompt 模板。它把常见任务分成了 8 个领域，每个领域有自己专属的提示词标准。这个设计比想象中要用心：
| 编号 | 领域 | 典型任务 |
|---|---|---|
| 01 | 工程工作流 | 规划、架构评审、TDD、子代理、分支收尾 |
| 02 | 软件开发 | 编码、后端、API、全栈、调试、QA、部署 |
| 03 | 前端设计 | 网站/页面/组件/UI、落地页、响应式 QA |
| 04 | 产品/业务 | 产品策略、范围界定、创业思维、决策框架 |
| 05 | 数据分析 | 指标、仪表盘、报告、KPI 解读 |
| 06 | 内容/文档 | 文档编写、Word/Docs 类工件 |
| 07 | Office 文档 | Excel/PPT 表格与演示文稿 |
| 09 | 超能力工程 | Superpowers 插件集成的高级工程流程 |
第 08 号是一个扩展指南，用于新增领域。09 号优先于 01 号加载——因为它是基于 Superpowers 插件的增强版本。多领域任务最多加载 2 个文件：1 个主领域 + 1 个交付物领域。
我特别喜欢的一个细节：跨 IDE 适配。项目提供了针对 Cursor 和 Claude Code 的专用配置片段，因为 Momus 默认是为 Codex 设计的。Cursor 的配置里甚至说了「sarcasm 程度偏重，尖锐有对抗性」——这项目是真的在认真做「怼人」功能。
// 安装与使用
安装路径是标准的 Codex skills 目录结构：
Codex 会自动通过 SKILL.md 发现这个 skill。Cursor 和 Claude Code 则需要手动添加适配规则到各自的配置文件中。
不过有个槽点：README 里连最基本的 git clone 命令都没写，只说了「放进对应目录」。对于非 Codex 用户，你可能需要去翻 references/ide-adapter-snippets.md 才知道怎么配。这个门槛对早期项目来说不太友好。
// 架构流程
// 竞品对比
Momus 做的事情其实没有任何一个直接竞品——目前市面上没有第二个专门针对 AI Coding Agent 做 prompt 质量门控的 skill 工具。但如果在「prompt 质量保障」这条线上拉宽来看：
| 方案 | 类型 | 特点 | 与 Momus 的差距 |
|---|---|---|---|
| momus-skill | IDE Skill | 8 领域标准、sarcastic 交互、跨 IDE 适配、自动触发 | – (基准) |
| 手写 Cursor Rules | 手动配置 | 灵活但零结构，往往写成「请仔细分析任务」这种废话 | 无领域标准、无审查维度、无自动重写、无 sarcasm 趣味性 |
| Claude System Prompt | 系统指令 | Claude 原生能力，可注入「先确认目标再执行」等规则 | 每次要手写、无结构化审查框架、无跨 Agent 复用、无领域分类 |
| aider 的 /ask 模式 | CLI 工具 | 先提问再执行，但依赖人类自己回答 | 无自动审查、无 prompt 重写、无领域适配 |
| OpenAI Prompt Caching | 基础设施 | 节省 token 但不能帮你写需求 | 完全不相关领域，只优化成本不优化质量 |
说实话，Momus 最大的优势恰恰是它最大的限制：这个品类太小众了。愿意在 coding agent 里再加一个 skill 来审查 prompt 的人，通常是已经对 AI 编程有相当深度认知的用户。对大众用户来说，「帮我修 bug」就够了，他们不会在乎 Momus 说不说这句话太模糊。
// 质量维度评估
Momus 没有量化 benchmark 数据，但它自己的 7 维度框架可以用来反向评估它自身：
* 评估基于项目设计完整性、文档质量与已知社区数据的综合分析，非严格量化指标
// 博主观点
+ 概念精准：Prompt Quality Gate 这个定位在 AI Coding 生态里确实是空白
+ 结构完整：7 维度审查 + 8 领域标准 + 跨 IDE 适配，不是拍脑袋的 toy project
+ 交互有趣：sarcasm 风格让 prompt 审查这件事不枯燥，有记忆点
+ 规则详尽：SKILL.md 写了 400+ 行的触发规则、审查逻辑和输出格式，比大多数开源 skill 要严谨
+ 扩展性好：通过 references/ 目录 + 索引导航，新增领域标准零耦合
- 社区为零：0 Star / 0 Fork / 0 Issue / 0 PR，未经过任何真实场景验证
- Bus Factor = 1：单人维护，无协作者，一旦作者断更项目直接死亡
- 无许可证：没有 LICENSE 文件，开源社区不敢 fork 和使用
- 文档入门成本高：README 只有概念描述，缺少快速上手教程和 GIF 演示
- 实际效果未知：没有任何用户反馈、案例或 A/B 测试数据证明 Momus 真的能减少返工
- 使用门槛悖论：能理解 Momus 价值的深度用户不需要它；需要它的新手用户可能不理解它的价值
说实话，给这个项目打分我纠结了很久。从想法的角度，我真的很喜欢——每天对着 AI 说「帮我修 bug」的开发者太多了，如果有东西能逼他们多想一步，coding agent 的体验会好一大截。但 0 Star 和 3 commits 的现实也确实没法忽视。
我建议作者做几件事把这个项目盘活：
1. 加 LICENSE——Apache-2.0 或 MIT，这是开源社区的第一道门槛
2. 做 GIF 演示——拍一段在 Codex 里说「帮我优化项目」然后被 Momus 制裁的录屏，比一千字都有说服力
3. 去 Reddit/Twitter 发帖——r/cursor、r/ClaudeCode、「终于有人做了 prompt 审查器」这个叙事很适合传播
4. 打包成 npm/skill marketplace——降低安装门槛，不要指望用户手动 clone
5. 收集案例——搞一个「Momus 拯救了我的 prompt」合集，把优化前后对比列出来
这个项目不是代码量很大的那种，但设计思想是对的。就看作者有没有意愿把它从一个聪明的 idea变成一个可用的工具。