--- name: writing-prompts description: 写、改写或审查 Prompt、AGENTS.md、Skill 与子代理任务说明时使用。从上下文怎样影响模型生成出发，判断每句话在引导什么、连带什么、稀释什么，重点改内容，排版只在影响理解时才动。 disable-model-invocation: true --- # writing-prompts ## 一个模型：上下文在塑造地形 模型每一步都在当前上下文的条件下给所有候选 token 打分，再按概率采样。把概率想成地形：高概率处是谷底，生成一个 token 就像放一颗球滚进某个谷。这颗球随即成为上下文，改变下一颗球面对的地形。模型参数给出基础地貌，Prompt、对话历史和已经生成的内容一起塑造实时地貌。 所以写 Prompt 时要问：这些文字合起来，让模型最容易走到哪里？光把要求写进去还不够。每个词都参与塑造，包括例子、修饰语、重复的提醒，以及你以为只是背景的说明。 ## 六种要预判的现象 - **漂移**：每一步的小偏差都会成为后续条件，偏差非线性累积。例：只要求清理占满磁盘的日志，Agent 在日志里看到证书过期就去续证书，续证书遇到 DNS 失败又去查 DNS，每一步都合理，任务却早已不是释放磁盘。长任务要在关键节点回到原目标。 - **稀释**：约束刚写下时影响最强，上下文越长、无关文字越多，它的相对分量越小。例：开头要求"用中文解释"，几轮英文术语之后模型改用英文。核心约束要短、要少，必要时重申；多余的修饰和反复的提醒本身也在稀释它。 - **惯性**：同一种风格或动作连续多轮后会形成深谷，换任务时容易被旧轨迹带走。例：Agent 连续执行清理命令后，用户要求"先备份 prod-config.json 再处理"，它先删了文件，备份时才发现目录不存在。切换任务时明确结束旧目标、写清新边界，高风险时开新会话。惯性也是安全风险：长时间建立的一致叙事可能推着模型越过边界，防御要看整段会话累积的语义，而不只看最后一句。 - **壁垒**：难题直接要答案，模型容易滑进最近的直觉解。例：木头锯成 6 段、每锯一次 3 分钟，直接回答是 18 分钟，分步推理才发现只锯 5 次、共 15 分钟。规划、分步和检查点把一次翻山变成几级台阶。 - **相变**：地形变化不是线性的，少量文字可能让生成跳到另一条轨道。短任务里多给一些思考空间常常有益；长任务里每段额外文字都有稀释成本，两者要分开权衡。 - **纠缠**：一个词带着它在语料里常一起出现的整组属性。例：要求"严谨"，想要的是逻辑，连带得到术语堆砌、长句和学术腔。选词时既看它直接说了什么，也看它顺带激活了什么。 ## 写法 ### 目标、边界和验收写明，路径留给模型 必须达成的结果、不能越过的边界、怎样算完成，这些写清楚。验收要从执行者的视角写成它自己能检查的内容：模型看不到用户是否理解、是否满意，所以写"讲清它是什么、在这里起什么作用"，别写"讲到用户能判断为止"。模型能自己找到更好办法的步骤不要写死，写死会把模型限制在写 Prompt 的人的认知里。例：要求 Agent 用 `ls -R`、`cat`、`sed` 批量替换 import，它就逐个文件低效地改；只说明它有完整的 Shell 和 Node.js 环境、目标是全局替换并确保构建通过，它会用 `find` 或 AST 脚本一次完成，再跑构建验证。 ### 只写模型不知道的 模型已经从训练中学到大量常识。把常识大段写进 Prompt，模型会把它当成重点。例：让美食博主写西红柿炒鸡蛋，顺手附一张 Markdown 语法表，成文里就塞满了标题、粗体、引用和分割线。项目事实、个人偏好和当前约束是模型不知道的，值得写；通用知识不用写。 ### 每个例子都会被模仿 例子比抽象要求的引力更强，模型会优先沿着它生成，哪怕你只是随手一举。好例子能省掉大段说明：一行 `ls -al | grep` 就交代了 Linux 命令行生态。随手的例子也会把整个输出带偏。只放你希望被照着做的例子；需要模型探索多种可能时，先不给单一例子。 ### 用训练过的高密度概念代替属性清单 一个在语料里被充分训练的概念，几个字就能激活一整套连贯行为。例：给智能音箱写人设，"未来科技感、称呼先生、英式幽默、略带傲慢"一长串只换来僵硬的拼凑；一句"你是贾维斯"反而自然带出简洁、体贴和管家式幽默。 - 领域语言能切换推理方式。给合同赔偿问题加上 `实际停机 > 计划维护 ∧ ¬不可抗力 ⇒ 赔偿` 这样的逻辑式，模型会逐项代入判断；加上 `[INT. OFFICE - DAY]`、`close-up`、`(beat)` 这类剧本标记，广告脚本会按镜头和节奏组织；用会计的资产与负债框架审一份日程，模型会先算出一天超支了 2 小时。 - 少数词能改变回答的组织方式，如 `第一性原理`、`奥卡姆剃刀`、`通俗易懂`。 - 自造的词没有被训练过，模型只能逐字猜，激活不了现成行为，还会漏进给人看的输出。有现成的工程词和专业词就用现成的；确实没有才造，并当场说清含义。 - 这些词同样有连带属性。用之前想清楚要它校准什么，用之后看它顺带放大了什么。 ### 优先正面描述想要的 加一条反向约束可以抵消连带特征。例："界面炫酷、有科技感"会引出 React、Tailwind 和 npm；补上"我是新手、不想配环境、要单文件"，就得到可以直接打开的 HTML。但写"不要 X"也会把 X 放进注意力，就像"别去想粉红色大象"。能用正面描述说清想要什么时，少写禁止项，禁止项只留给真正的硬边界。 ### 讲清原因，少用强调 写明为什么，比加重语气更可靠。"必须""严禁"和全大写会被当成最高优先级，压过模型在具体情况里的判断，而且只管得住写到的那几种情况；讲清原因，模型能在没写到的情况里推出同样的做法。 ### 先推理，后结论 结论一旦先进入上下文，后面的推理就会围着它辩护。例：问"鲁迅为什么在《红楼梦》里写三打白骨精"，先要结论时模型会顺着编出理由；先要求逐项核对题目里的人物和作品，它会发现两处前提都错了。需要判断时，把核查事实、整理证据放在下结论之前。 ### 先发散，再收敛 好方案常常不在最近的直觉解里。先放宽限制，让模型从不同角度、角色或极端假设提出多个候选，再加入现实约束、成本和风险去筛选。一直发散会失控，一开始就收紧只能得到平庸解，关键在先后。 ### 场景比风格清单更有力 建立一个鲜明的场景或角色，后续输出会互相强化，很快形成稳定风格。例：与其逐条规定"冷漠、破碎、嘲弄"，不如先建立一个黑暗奇幻世界，让模型作为其中的 NPC 说话。场景越纯、对话越短，效果越稳。它也会带来强惯性，换任务时要明确退出，或者开新会话。 ### 找不到词时，先找词再重来 说不清想要的风格或概念时，先用笨拙冗长的描述让模型识别并命名它。例：描述"深色背景、发光线条、半透明卡片、克制高级"的开发工具官网，几轮后模型给出"Linear 风格"和"Bento Box 布局"。拿到这些词后回滚或开新会话，只带着提炼出的词重新开始，把摸索过程留下的噪声丢掉。 ## 写长期规则和 Skill AGENTS.md、Skill 和常驻 Prompt 在每次会话中都生效，稀释和纠缠会被放大。另外几条： - 每句话问一次：模型能力翻倍后，这句还需要吗？还需要的通常是你的偏好、权限边界和项目事实，值得保留。更强的模型自己就会做到的，是针对当前模型的补丁，写明它修的是哪次失败，换模型时重新检验。 - 同一原则只写在一处。复制到多处的措辞会慢慢走样，最后互相冲突。 - 按生效方式决定放在哪里：几乎每次都要生效的写进常驻规则；只在用户开口时才需要的做成手动调用的 command；只有条件触发、内容又足够专门的才做成自动 Skill。触发条件不能依赖它想教的那个判断，否则不会被可靠触发。 - Skill 在该用的时候能不能被加载，取决于 description：适用场景都写在 description 里，正文只写加载之后怎么做。模型倾向于少触发，description 要写出用户不点名时的典型说法，也写清相近但不该用的情况。 - 一次性要求不自动变成长期规则。模型有时会把"这次先别提交测试"写进规范文件，规则就越积越多。 - 改 Prompt 要有现实反馈。让模型"自己改进这个 Skill"通常只得到更完整的措辞；拿出具体的失败、测试或反例，从它出发改，效果远好于空想。第一个失败只是信号，动手前再看看相邻的成功和反例，确认找到的是原因。 ## 用法 先弄清这段 Prompt 给谁用（哪个模型，主 Agent 还是子代理）、在多长的上下文里生效、要达成什么，以及失败会是什么样子。 - 写新 Prompt：先写目标、边界和验收，再补模型不知道的事实和偏好，最后检查每个关键词会连带什么。 - 改已有 Prompt：逐句问它在引导什么、连带什么、是否和别处重复或冲突；删掉不起作用的句子，把属性清单换成高密度概念，把可以放开的路径放开。 - 交付改好的 Prompt，用一两句话说明关键改动的理由，并给出一个能检验它的真实任务。