任务目标提示词精炼

问题：需求很真实，但目标提示词很难写

很多人用大模型做自动化任务时，不是模型能力不够，而是第一句 /goal 没写好。用户对着语音输入随口说了一段话——想做 5 个落地页、要挂在线上、风格要“疯一点”——但真正决定模型能不能跑起来的，是这份提示词有没有把交付物、数量、受众、工具、质量标准、落点说清楚，以及有没有给模型一条可以自检的完成条件。写长了目标被稀释，写短了模型只能瞎猜。

这个技能就是来解决这件事：你不直接写代码，你写的是一份能粘贴进全新自主会话的高质量 /goal 提示词。

核心能力与工作方式

技能的核心哲学是不要挡在模型前面。一个好的目标提示词不 micromanage「怎么做」，而是钉死「做什么」，同时显式授权执行自由度，并要求模型在完成前自我验证。这里有一个大多数提示词会忽略的推论：done 必须可观察——每个交付物都要有一条会话能自己检查的完成条件，比如页面能加载、脚本能在真实输入上跑通、链接能打开，而不是一句模糊的“做好一点”。

工作流程围绕这个原则展开：

• 先做错工具检查：如果用户其实只是想让东西现在就被做出来，技能会先明说这一点，并主动提出直接帮你构建，而不是写一份没人会粘贴的提示词。
• 提取六槽位：从用户的碎片表达里提炼交付物、数量、受众/利害关系、点名的工具、质量标准、落点六个槽位，并按意图而不是字面词来解读（比如把“Quad MD”理解为 CLAUDE.md）。
• 默认值填缺 + 一次性提问：小缺口自己合成，只有在结果、规模、落点、资产、品牌事实这几项真的会改变提示词时才提问，且所有问题一次性问完，绝不一轮轮地访谈。
• 先验证再点名：花 30 秒确认要写进提示词的路径、能力或 MCP 真的存在——ls 一下路径、看一眼可用工具列表。环境才是事实来源，不是配置文件。只点名那些既验证过又承重的资源（通常 2–4 个），其余交给模型自己去发现。
• 七段式成文：把欲望与利害、质量标准、工具清单与发现授权、创作自由与决策权、验证循环、交付方式、目标行与自主指令织成一段自然的第一人称散文，不堆标题、不列清单。
• 自检后再交付：交付前核对交付物与数量是否具体、点名的资源是否验证过、创作自由条款是否存在、验证循环是否匹配媒介、落点是否明确、是否以目标行收尾，长度控制在 150–350 词。

适用边界与注意点

这个技能不自动安装依赖、不修改系统权限、不创建持久化任务、不执行下载内容。涉及发送、发布、删除、付款、部署或其他外部写入时，会先展示目标与影响，并取得明确确认。凭据只用于用户指定的对应官方服务，不回显、不记录、不转发。命令和代码默认作为参考，只有在用户明确要求执行且目标范围清楚时才会运行。

要避免的反模式包括：micromanage 执行步骤（一步步的指令会把会话缠死）、点名幽灵资源（未验证的资源会让新会话陷入死胡同）、完成条件不可验证（会话会提前宣布胜利）、把目标行埋在中间、编造利害关系（虚假的紧迫感会训练用户写 fiction）、以及访谈螺旋（最多一次批量提问）。