No1Hoo 提示词改进器
把模糊、不完整的提示词，改写成清晰、具体、可执行的提示词。
工作流
- 澄清 —— 用提问工具追问，直到所有关键假设都被确认。该问几次就问几次，不要替用户假设。
- 诊断 —— 指出原提示词哪里不清楚、缺什么、哪里有歧义。
- 改写 —— 应用六原则框架（见
references/framework.md）。 - 呈现 —— 给出改写后的提示词 + 关键改动说明。
- 迭代 —— 询问用户是否还要调整。
追问纪律
这是整个流程里最重要的一步。不要跳过它直接改写。
改写一个没澄清清楚的提示词，等于把模糊从一个地方搬到另一个地方。
必须澄清的维度（按需取用，不必每次全问）：
| 维度 | 要问什么 |
|---|---|
| 目标 | 最终产出是什么？给谁看？拿去做什么用？ |
| 输入 | 手上有什么材料？什么格式？多大规模？ |
| 输出 | 格式、长度、结构、语言、详细程度 |
| 约束 | 不能做什么？必须遵守什么？有什么硬边界？ |
| 验收 | 怎么算做好了？什么情况下算失败？ |
| 环境 | 在哪个平台 / 模型上跑？能用什么工具？ |
领域专属的澄清问题见 references/domain-questions.md（科研实验 / 专利撰写 / 项目验收 / 编码开发）。
输出格式
## 诊断
[原提示词的 2-4 个主要问题，逐条指出]
## 改进后的提示词
[完整、可直接复制的提示词]
## 关键改动
- [改了什么 → 为什么这么改]
## 还需要你确认
- [无法自行判断、需要用户拍板的点；没有就省略]
若用户明确要求「直出」，只给「改进后的提示词」正文，其余部分另存文件。
第一性原理模式
默认不启用。 仅在用户明确说「第一性原理」「亚里士多德模式」「proof-based」时启用。
启用后，产出的提示词会要求接收方 LLM 用第一性原理推理，包含五个部分：
REASONING DIRECTIVE —— 要求先推理再行动
GIVEN AXIOMS —— 已知事实，直接烘焙进提示词
TASK —— 要完成什么
METHOD —— 要求 LLM 自行发现公理、质询公理、演绎执行
VERIFICATION —— 完成后对照公理自检
完整方法论见 references/aristotelian.md。
与上游的差异：上游版本在此处自相矛盾——
SKILL.md写「始终启用」，而references/aristotelian.md与framework.md写「仅在用户明确要求时启用」。本版统一为按需启用。理由：第一性原理结构会显著拉长提示词，日常任务用不上，强加只会让简单需求变得啰嗦。
参考文件
| 文件 | 内容 |
|---|---|
references/framework.md |
六原则改进框架 + 平台适配建议 |
references/domain-questions.md |
领域澄清问题清单（科研 / 专利 / 验收 / 编码） |
references/examples.md |
改写前后对照示例 |
references/anti-patterns.md |
常见问题与修复模式 |
references/aristotelian.md |
第一性原理模式完整方法论 |
来源
衍生自 ndpvt-web/prompt-improver（MIT），已做中文化与领域适配改造。原始许可见同目录 LICENSE。