从提示词到协作：把 4D Framework 用在完整工作中
把委托、描述、辨别与责任放进一条完整的工作链。
很多提示词只规定“请扮演什么专家”，没有说明谁要使用结果、依据什么资料、哪里不能擅自决定。模型于是给出一份像样的答案，真正的工作却没有向前推进。
4D Framework 可以把这类问题拆成四件事：Delegation（委托）、Description（描述）、Discernment（辨别）和 Diligence（尽责）。它是一套协作判断框架，不是输入四个标题就能保证成功的公式。
先决定责任，再描述工作；用结果纠正描述，用后果重新检查委托。
01 / 定义：四种能力分别约束什么
| 能力 | 关键问题 | 可以看见的产物 |
|---|---|---|
| 委托 | 哪些工作交给AI？哪些决定保留给人？ | 任务边界与责任人 |
| 描述 | 依据、约束和完成标准是否足够明确？ | 输入清单与交付要求 |
| 辨别 | 结果是否正确、适用、完整？ | 核查记录与修改意见 |
| 尽责 | 这项协作对谁产生什么后果？ | 数据使用、发布和纠错安排 |
四者不是只能执行一次的流水线。发现材料不完整，要回到描述；发现任务涉及无法承担的后果，要缩小委托。让 AI 改错不是失败，而是协作循环的一部分。
02 / 推导：把“做一份分析”改成可交付任务
用一个虚构的产品迭代评审举例。你想判断“下个版本是否优先做批量导出”，手里有 6 条用户反馈、一个开发估时和当前导出限制。
- 这是一项产品取舍，AI 可以整理证据，但无法替你确认业务优先级。
- 要比较取舍，需要统一评价维度，而不是先生成支持某方案的理由。
- 反馈不是市场全貌，因此结论要标明样本局限，不能把六条反馈写成所有用户需求。
- 最终输出应包含建议与改变建议的条件，让评审会有可讨论的对象。
图中的最后一步不是写一个免责声明。谁能确认用户反馈、谁批准资源投入、出了错谁修正，必须能对应到实际行动。
03 / 应用：完成一份可讨论的迭代建议
① 先写任务契约
目标：比较“批量导出”和“优化现有单次导出”两个方向。
输入：6条访谈原话、当前功能说明、两份开发估时。
AI负责：提取证据、列比较表、识别缺失信息、形成建议草案。
人负责：确认样本解释、估时和业务优先级。
输出：一页决策备忘录，区分事实、推断和待确认项。
边界：不能补造用户数量、收入影响或确定的交付日期。
完成：每个主张能回到输入；两个方案采用相同维度。
② 先检查提取，不急着读结论
让 AI 列出每条原话支持的具体问题。例如“我要反复点导出”说明操作重复，尚不能证明必须批量导出：也可能是筛选不便或权限划分造成的。把观察与方案分开，才有比较空间。
③ 规定共同维度
- 解决哪类用户的哪一步工作？
- 有哪些支持证据，缺少哪些反证？
- 实现和维护的主要成本是什么？
- 如何小规模验证，失败后如何退回？
④ 给具体反馈
不要只说“再专业一点”。可以指出：“第三条把操作次数当作用户人数，删除这项推断；两方案都补上权限处理成本；保留缺失信息，不用猜。”然后核对修订版是否真正改变了这些内容。
⑤ 记录人的最终选择
例如先做一个不落库的导出原型，用三种权限角色走一遍。决策记录写明当前选择、理由、复核日期以及何种证据会推翻它。AI可以整理这个记录，但不能把建议自动升级为已批准需求。
04 / 验收：看四种错误，而不只看文风
| 错误 | 你会看到什么 | 回补方法 |
|---|---|---|
| 委托过度 | AI宣布上线或对外承诺日期 | 收回决定与发布权限 |
| 描述缺失 | 比较用了不同的统计口径 | 统一输入、样本与维度 |
| 辨别薄弱 | 只挑支持偏好方案的证据 | 要求最强反例并核对原文 |
| 责任空白 | 没人维护结论、没人处理反馈 | 补负责人、期限与纠错入口 |
实际检查时，把备忘录交给一个没有参加前面对话的人。他应当能说清“为什么选这个、还有什么不知道、谁决定下一步”。如果必须由你补讲十分钟，产物就还没有完成。
格式只是沟通效率的一部分。即使表格整齐，证据与责任混在一起，工作仍然无法可靠交接。
05 / 迁移：从共同写作到持续执行
临时分析适合边做边讨论；步骤稳定的任务适合固定流程；需要探索的任务可以给予更多执行空间，但应有预算、停止条件和回报要求。自主程度增加时，输入和验收不能减少。
让 AI 每周自动发客户周报，缺的只是一个定时器吗？
还缺数据范围、收件人授权、异常停发规则、草稿复核与撤回纠错机制。生成周报和发出周报具有不同后果，应分别委托。先在本地验证，再决定是否开启外部发送。
任务方法明确后，要把资料和决定留在可维护的位置，见工作空间与上下文组织。文件执行型委托的完整例子见Cowork 的委托与验收。