我做了一个无情的 Agent，专门用来毙你的伪需求 - 慎用！真会怼人。

大家好！我是瓜哥。前互联网技术副总裁，现在带队死磕 AI 编程。

这几天我在折腾一个 Skill。它的名字叫 idea-clarifier。

这不是一个帮你把想法包装得更好听，顺着你写 PRD 的 Skill。我对他的定义很冰冷：在你真正立项前，先把想法里没想清楚的地方全部拎出来。

项目已经放到 GitHub。

地址是：https://github.com/zhaodl1983/idea-clarifier

01 | 想法的起点

① 我不想再让 AI 过早写 PRD

我做很多产品，在一开始时，很容易出现两种情况。

第一种，是 自嗨的伪需求 。

idea 在脑子里闪现，头脑一热，就开始兴奋的燃烧 token，做到一半发现这好像是个自嗨的伪需求，常常因缺少深度思考而中途放弃。

第二种，是 过早文档化。

用户是谁没说清，痛点是什么没证据，核心链路没走通，商业模式也只是一个口号。这个时候让 AI 写 PRD，结果通常很危险。

看起来完整、像样，但没有立项价值。

最危险的地方，是它会给人一种 「已经想清楚了」 的错觉。

所以我想做一个 Skill，专门卡在 PRD 前面。作用很窄：不做高保真 UI，不写生产代码，也不直接进入开发，只逼你说清楚 产品想法。

② 它的核心角色必须够狠

我给它设计了两个 拷问官。

1.用资深产品经理和偏见型投资人双重视角，无情追问模糊产品想法。2.只有需求、价值、商业假设和 MVP 具备立项条件后，才允许产出 PRD。

第一个是 资深互联网产品经理。

盯的是用户痛点、需求优先级、场景、核心链路、MVP、体验和成功指标。只要你说 “上班族”、“效率提升”、“AI 工具”这种空泛的词，它就会继续追问。

第二个是 投资人。

盯的是市场、付费方、获客、增长、竞争、ROI、天花板、失败风险。因为真钱投出去以后，热情没有任何价值，证据才有价值。

我想要的是一个 立项约束。

它必须无情，尖锐，专业。

③ 名字也要收窄

最早讨论时，我考虑过更宽泛的产品经理 Skill。但这个方向太大且不聚焦。

既做需求澄清，又做 UI，又做交互。如果它还继续写 PRD，就会变得 边界失控。最后每个环节都沾一点，关键环节却不够硬。

所以最后把名字定为 idea-clarifier。

这个名字很直白：它只负责澄清想法。

02 | 实现的效果

① 当前 Skill 的真实结构

现在仓库里核心文件很清楚。

idea-clarifier/├── SKILL.md├── agents/openai.yaml├── assets/│   ├── gate-templates.md│   ├── prd-template.md│   └── wireframe-template.md├── evals/│   ├── evals.json│   └── trigger-queries.json└── references/    ├── amazon_working_backwards.md    ├── rubric.md    ├── workflow.md    └── writing-standards.md

SKILL.md 只放 触发条件、角色边界和运行规则。具体流程放进 references/。评分规则和模板放进 assets/。

这种拆法的好处很直接。

主文件短，Agent 更容易抓住 核心。

细节文件独立，后续迭代也更清楚。

② 它按 7 个阶段运行

当前工作流分成 7 个阶段。

这里最关键的是两个 约束。

产品约束没有达到 有条件通过 或 通过。它就不能进入 投资人阶段。

投资约束没有达到 观察 或 可小额试投。它就不能写 PRD。

这条规则很硬。因为如果产品价值没过关，直接聊商业模式，只是在给一个模糊想法套融资叙事。

③ 它输出的不是情绪价值

这个 Skill 的目标，不是让用户感觉自己很有远见。

它会输出追问清单、约束判断、被砍掉的想法。

它也会输出待验证假设、PRD 和 ASCII 线框图。

我特别保留了 低保真线框图。

但我砍掉了高保真 UI。

原因很简单：立项前真正需要验证的是逻辑和状态。

03 | 我的思考过程

① 我先把边界画死

做 Skill 最容易犯的错，是一开始就想做一个 大而全 的东西。在产品立项这个场景里，真正稀缺的是 拒绝能力。

一个想法不成立，就应该停在前面，不应该一路生成到 PRD、原型和代码。

所以 idea-clarifier 的边界很清楚。

它只做澄清、审问、约束、PRD 和 低保真线框图。

高保真 UI、品牌视觉、组件库、生产前端代码，全部不在它的职责内。

② 我把“狠”写成规则

“无情” 如果只写在描述里，Agent 很容易跑偏，我把它落成了 可执行规则。

每轮最多问 3 个问题。问题必须要求证据、数字、场景或选择，用户回答含糊时，要引用原话，然后指出它为什么阻塞。

评分也不能凭感觉。

rubric.md 给两个 约束 都设了 0-2 分维度。

比如：PM Gate 要看目标用户、问题、价值，还要看核心链路、MVP 范围和成功指标。

任何关键维度为 0，就直接 不通过。

③ 我没有让投资人提前登场

这里我纠结过一个 流程问题。

产品经理约束没过时，要不要允许进入投资人阶段？

最后答案是不允许。

因为用户、痛点、价值、MVP 都没讲清楚时。

投资人视角只会审一个 空壳。

这不是商业判断，只是对空洞故事做二次包装。

所以现在的流程是：产品经理先把需求洞察压实，再交给投资人审商业假设。

04 | 调试的细节

① 我先做了物理分割

它来自旧的 ai-product-manager 讨论。

但我没有直接改旧 Skill。

我把它创建成新的 独立仓库。新 Skill 的名字是 idea-clarifier。这样旧 Skill 还能保留，新 Skill 的定位也不会被历史包袱污染。

于是，我删除了 GEMINI.md（早期这个 Skill 是 Gemini CLI 的专属配置），这次目标是符合 Agent Skills 标准，不该绑定某一个 Agent。

② 我做了本地多端同步

本地采用了一个 单源多端同步 方案。

~/.agents/skills 是唯一 源目录。

三端再从这里同步。

当前策略是：Codex 和 Gemini 使用软链接。

Claude 使用 镜像副本。原因是 Claude Code 在非交互模式下。它可能拒绝读取部分软链接引用文件。

这个方案不算漂亮。

但它解决了 真实问题：同一个 Skill，只维护一份源文件。

③ 我复跑了标准校验

不是停留在 “提交成功” 这种表面结果。

本地执行过 Agent Skill 校验。它返回 Skill is valid。

仓库远端也核对过。GitHub 地址、中文描述、v0.1 release 都能对应上。

我还验证过 三端调用。Claude Code 默认非交互模式有 权限差异，所以最终把它纳入镜像同步策略。

这一轮调试的结论很直接。

Skill 本体可用，多端注册可正常使用。

05 | 分享 Skill 获取地址

① 仓库地址

项目地址是 GitHub 仓库。

https://github.com/zhaodl1983/

idea-clarifier

当前版本是 v0.1。

Release 路径是 releases/tag/v0.1。

仓库 README 已经改成中文。

里面写了安装方式、使用方法和 工作流。

② 最简单的安装方式

如果你的 Agent 支持标准 Agent Skills。

可以直接克隆 仓库。

git clone https://github.com/zhaodl1983/idea-clarifier.git idea-clarifier

Codex 本地可以放到这个目录。

mkdir -p ~/.codex/skillsgit clone https://github.com/zhaodl1983/idea-clarifier.git ~/.codex/skills/idea-clarifier

调用时可以直接说：

使用 $idea-clarifier，在写 PRD 前先拷问我的产品想法：我想做一个……

在其他的 Agent 里也是一样的调用方法，比如：Antigravity CLI

③ 它适合什么人

这个 Skill 适合三类 使用场景。

• 第一类，脑子里有产品想法，但还没说清楚用户和痛点的人。

• 第二类，准备写 PRD 的人。但核心链路、成功指标和 MVP 范围 还没定。

• 第三类，想做创业项目，但对市场、付费、增长和竞争还只有一句口号的人。

如果你只是想快速生成一份漂亮 PRD。

它可能会让你 不舒服。

因为它会先告诉你：现在写 PRD，太早了。

写在最后

我做完 idea-clarifier 最大的感受很简单。

Agent Skill 的 价值，不该只是把提示词包装成文件。

真正有用的 Skill，应该拆出 专业流程，它要可迁移，可复用，也可验证。

idea-clarifier 现在只是 v0.1。

已经能跑完整的 约束流程，包括产品经理约束、投资人约束、PRD 和低保真线框图。

下一步我更想补的是案例库和评测样本。因为一个无情的 Skill，不能只会问尖锐问题，还要稳定地区分两种 状态。

一种是真的没想清楚，另一种是已经足够进入验证。

欢迎大家克隆使用，如果觉得不错记得留下的 star，给我一点小鼓励。