“设计一个数据看板”可以得到结构完整的方案，却无法回答该看哪些指标、接哪些现有接口、谁来使用以及怎样验收。问题不一定是回答中有明显错误，而是任务没有提供影响决策的本地信息，模型只能补出通用做法。本文不讨论提示词修辞，而是把上下文整理成六类可检查信息：目标、输入、约束、证据、输出和未知项，并用一份任务合同减少隐含假设。
先找到回答无法执行的具体原因
不要只评价“太泛”，把问题定位到缺失变量：
| 泛化表述 | 缺少的本地信息 |
|---|---|
| “关注转化和留存” | 团队认可的指标定义与数据口径 |
| “使用主流前端框架” | 现有技术栈、版本和组件约定 |
| “增加权限管理” | 已有身份系统与角色模型 |
| “提供实时刷新” | 业务时效要求、数据源和资源限制 |
| “优化用户体验” | 目标用户、关键路径和验收指标 |
每一条无法落地的建议，通常都对应一个任务没有说明的选择。如果这些选择必须由业务或工程负责人决定，就不应让模型静默补全。
六类上下文
目标：要改变什么可观察结果
目标描述使用者、场景和完成后的行为，不只是产物名称。
不是：做一个运营看板。
而是：让客户成功经理在每日跟进前识别需要优先联系的续约客户。
输入：任务可以使用什么
列出数据、文档、代码、接口和已有方案，并说明来源位置与可信度。不存在的输入要明确，不允许模型假设已经具备。
约束：哪些选择已经确定
包括技术栈、时间、权限、合规、兼容性、团队能力和不可修改范围。约束要能检查，例如“沿用仓库现有组件库”，比“保持技术一致”更明确。
证据：结论必须回到哪里
要求指标引用口径文档、代码结论引用文件与符号、选型结论引用官方资料或实测记录。没有证据的建议应标为假设或待验证项。
输出：交付格式和验收方式
说明需要的是决策表、实现计划、代码 Diff、测试报告还是原型，以及谁验收、检查哪些字段。输出格式不是美化要求，而是下游工作接口。
未知项：哪些空白不能自动补齐
提前列出负责人、数据口径、权限、截止时间或兼容条件等未知项。模型遇到未知项时应提问、保留占位或停止，而不是编造完整答案。
把六类信息写成任务合同
【目标】
谁在什么场景下遇到什么问题；完成后可观察到什么变化。
【输入】
允许使用的文件、数据、接口、样例和来源位置。
【约束】
必须沿用的技术与流程；禁止变化的接口、权限和范围。
【证据】
每类事实需要引用什么；没有依据时怎样标记。
【输出与验收】
交付结构、详细程度、验收人和验证方法。
【未知项处理】
哪些问题必须先问；哪些可以采用明确假设；遇到什么情况停止。
这个结构不要求每次写成长文。简单任务可以只有几行，复杂任务则把稳定背景放到项目文档，把本次变化放进任务单。
一个数据看板示例
模糊输入：
帮我设计一个客户运营数据看板。
改写后的任务合同：
【目标】
使用者是客户成功经理；在每日跟进前识别本周期需要人工复核的续约客户。
【输入】
只使用已提供的客户、合同和工单字段说明，以及指标口径文档。
【约束】
沿用当前后台技术栈和现有权限系统；本阶段只做最小可行方案，不设计实时大屏或新权限平台。
【证据】
每个指标写明来源字段与口径文档位置；无法映射的指标列为缺口。
【输出与验收】
输出用户任务、指标表、页面信息结构、接口缺口和验收清单，不生成未经确认的业务数值。
【未知项处理】
先确认续约周期、客户范围和工单状态口径；没有答案时保留待确认，不自行选择。
这份合同没有要求模型“更聪明”，只是把方案必须依赖的选择显式化。
让模型先检查信息充分性
任务开始前可以使用以下提示：
先不要生成最终方案。
检查目标、输入、约束、证据、输出和未知项是否足以决定方案。
只提出会改变架构、范围、数据口径或验收方式的关键问题。
对可以采用的假设，说明假设、依据和错误时的影响。
等待确认后再输出。
问题数量不是质量指标。与结果无关的偏好问题会增加沟通成本；真正关键的问题应能指出不同答案会导致哪项设计变化。
区分三种缺失信息
必须由人决定
业务口径、授权、优先级和风险接受通常属于负责人决策。模型只能列选项和影响，不能替负责人批准。
可以从项目证据读取
技术栈、测试命令、接口定义和目录规则应优先从仓库文档与配置读取。读取后引用位置，避免让用户重复提供已经存在的信息。
可以采用可撤销假设
对低风险、易更改的展示顺序或占位名称，可以使用明确假设继续，但要集中列出，方便替换。不可逆或高影响决策不属于这一类。
稳定上下文与任务上下文分开
团队中长期不变的信息，例如术语、数据分类、技术栈、代码约定和禁止事项，可以维护在版本化项目文档或知识库中。本次任务只引用必要章节，并补充当前目标与变更范围。
不要把所有组织资料塞进每次上下文：
- 无关信息会增加冲突和过时内容风险。
- 敏感信息可能被不必要地暴露。
- 文档越多，越难知道具体结论来自哪里。
上下文包应有维护者、适用范围和更新时间。出现冲突时，任务应说明采用哪个来源，而不是让模型自行挑选。
用反例测试任务合同
提交给模型前检查：
如果使用者换成管理层，当前输出是否仍然成立？
如果数据只能按日更新，是否还会建议实时方案？
如果接口字段缺失，是否会虚构指标？
如果仓库使用旧版框架，是否会擅自升级？
如果权限未批准，是否会继续设计数据访问？
反例暴露的是隐含默认值。把对应条件写回约束或未知项，任务合同就会逐步变得可执行。
结果仍要做上下文回归检查
模型输出后逐项核对：
- 是否真正服务目标使用者和场景。
- 是否只使用允许输入。
- 是否违反任何显式约束。
- 事实与结论是否能回到证据。
- 输出是否满足下游格式与验收。
- 未知项是否被诚实保留。
发现泛化内容时，不要只要求“更具体”。指出它缺少哪类上下文，补充来源或把它删除。
结论与限制
AI 回答“正确却无法执行”时，应定位它缺少哪个决策变量，而不是不断调整语气。目标、输入、约束、证据、输出和未知项组成的任务合同，可以减少通用默认值进入本地方案，并让提问集中在真正影响结果的地方。
上下文更完整仍不保证结论正确。资料可能过时、来源可能冲突，模型也可能误读。最终结果仍需要负责人确认业务选择，并用项目证据和实际验证检查。