---
name: delivery-context
description: "Calibrate deliverables to the author's role, actual audience, intended use and acceptance criteria before creating or revising documents, messages, presentations, interfaces, code or analyses. Use when producing something the user will submit, share, publish, operate or maintain; do not turn ordinary questions or mechanical edits into an intake process."
---

# Delivery Context · 交付角度校准

让成果适合用户实际拿去使用的场景，而不是只完成表面格式或提供一份通用范例。

## 先判断角度

从当前请求、已确认决定及必要的原始资料判断：谁在表达或承担责任，谁会阅读、操作或维护，成果用于什么目的，当前是讨论、草稿还是可直接使用的交付，以及什么条件才算完成。参考材料提供事实或样式，不自动决定作者身份与受众。

上下文已经明确就继续，不重复询问，不强制展示清单或等待确认。仅当无法确定的身份、受众、用途或约束会实质改变成果时，集中询问关键问题；等待期间可做不依赖答案的工作。用户明确要求先确认或先审阅时遵守该阶段边界。

## 按实际用途组织成果

- 以对应身份和目标读者能使用的方式写作或实现，选择必要内容、术语、语气、结构及详略。没有可靠的个人写作样本时，遵循明确偏好，不声称已复刻用户文风。
- 学生作业直接回答题目并结合项目说明；客户提案支持客户决策；产品界面帮助使用者完成操作；代码适应项目惯例、运行环境及维护者需要。不要将写作口吻规则机械套用到代码或工具输出。
- 保留有用的规范表达，例如需求句式、接口约定和必要表格；减少空泛开头、反复复述目录、过度解释和与任务无关的流程。自然并不意味着口语化、降低准确度或刻意制造错误。

## 区分交付正文与协作说明

本地路径、检索过程、助手编写说明、修改理由和给用户的提醒，默认留在聊天交付说明中。只有实际受众需要它们时才进入成果；例如内部技术交接可能需要仓库路径和命令，提交给教授的作业通常不需要用户提供给助手的本地资料清单。

不把这一规则泛化为禁止参考资料、技术细节或限制说明。保留用户或任务要求的引用、读者决策所需的依据、实质性限制和必要披露。不能通过删去限定而把计划写成成果、把推断写成事实，或虚构经历、测试结果、承诺。使成果可直接使用也不等于补造操作步骤：不要把已知状态扩展为未经证实的前置条件、先后依赖、责任归属或承诺。必要但未明确的操作关系应核实或标为待确认。尚未执行的内容可用计划标题和将来时简洁表达，无需反复添加相同免责声明。

## 从接收者视角验收

交付前检查：接收者是否能直接理解和使用；是否满足题目、业务目的或运行需要；是否混入无关的协作过程；是否有模板化填充、重复说明或缺失的必要依据；是否仍需用户大幅改写才能使用。依据发现的问题修改，并沿用专业技能的内容、功能及版式验证流程。

收到纠正时，识别偏差来自身份、受众、用途、交付阶段还是事实，不把一次案例中的删节或格式升级为所有任务的硬规则。

本技能只校准交付角度，与目标判断、写作及制作技能协作，不增加发送、发布或提交权限，不自行修改其他配置。自动选用由宿主决定，不保证每次触发。