核心 GUIDE
Prompt Specificity（提示词具体性）
Prompt Specificity 会把任务、约束、输出 Contract 与成功标准写得足够具体，让模型不必从含糊语言中自行补全关键 Requirement。
核心心智模型
把 Specificity 看成缩小“可接受行为空间”。好的 Prompt 会明确 Decision Boundary，但不会试图规定模型最终必须生成的每一个 Token。
为什么重要
模糊 Prompt 会把本应由产品决定的问题偷偷交给模型：什么叫完整、哪个 Source 优先、什么 Format 合法、何时应该 Clarify。Specificity 把这些选择移回可检查的 Contract，同时保留模型解决任务的空间。
01
明确 Decision、Constraint 与可观察 Acceptance
先写清最终 Task Outcome，再识别不可违反的 Constraint、相关 Context、Output Structure 与 Evidence Requirement。Example 只在它确实能澄清边界时使用。如果某项要求可以被代码或 Reviewer 检查，就应把它写成可观察条件，而不是依赖“高质量、认真、全面”这类形容词。
02
示例：“总结合同”隐藏了真正的决策
Legal Assistant 只收到“总结这份合同”，不同运行会强调不同 Clause，因为 Prompt 没说 Reader 是谁、哪些 Risk 最重要。改造后明确要求 Renewal Date、Termination Window、Payment Obligation、异常 Liability，并附 Source Section 与显式 Not Found 状态。模型仍有表达空间，但关键 Decision Surface 已被限定。
常见失败模式
- 增加很多文字，却没有澄清任何 Decision Boundary。
- 为了覆盖所有 Edge Case 把 Prompt 写到不可读。
- Example 意外覆盖了真正的 Policy 或 Output Contract。
工程启发
- 先明确用户最终看到的 Decision 或 Artifact，再谈 Style。
- 把关键 Requirement 转成可观察 Field、Check 或 Refusal Condition。
- 必要事实缺失时使用 Clarification，而不是让模型猜。
关键结论
- 01Specificity 的价值是减少模型必须猜测的 Hidden Requirement。
- 02具体 Prompt 定义 Boundary，不等于规定每个 Token。
- 03可观察 Acceptance Criteria 比强调语气更可靠。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。