Context Engineering for Outbound

✍ Nicolas Finet🕐 2026-07-14📦 10.7 KB 🟢 已读 𝕏 文章列表

文章探讨了上下文工程在外拓代理中的应用，强调通过精心设计上下文窗口（包含角色、案例、证据和规则四层），解决模型幻觉和生成内容泛化的问题。文章介绍了组装、撰写和优化三个核心技能，以提升个性化消息的质量和响应率。

# Context Engineering for Outbound **作者**: Nicolas Finet **日期**: 2026-07-13T16:32:13.000Z **来源**: [https://x.com/nifinet/status/2076706274226684376](https://x.com/nifinet/status/2076706274226684376) --- Give two outbound agents the same model, prompt, and buying signal, and they will still send completely different messages. One opens with the exact reason a fresh round puts a new problem on that team's desk this quarter. The other sends "Hi {{firstName}}, I noticed your company is growing" to its whole title. What separates them is context: everything that goes into the window before the model writes a word. Context engineering is the work of building that window. For each step the model takes, you decide what it should see and what to leave out. What follows applies it to outbound, as three small skills you can read here and clone at the end. I will start with the idea, because it changes what you build, then the four layers that make up a context window, then the three skills that assemble that window, write from it, and sharpen it over time. ## Prompts vs Context A prompt is what you tell the model to do, and context is what it can see while it does it. Most of what people call hallucination is really an empty window. The model invented a figure because the real one was never put in front of it, or it sounded like a robot because nothing showed it how you write, or it pitched the wrong thing because it could not see the two emails you had already sent that account. None of that is reachable from the prompt. You fix it by engineering the window: deciding, for each step the model takes, what it needs to see and, just as much, what to keep out of view. ## The four layers of a context window: Role, Case, Evidence, Rules A good window for an outbound decision carries four things and no more. Role is the single job of this step, which is never "run outbound" but something narrow, like reading a stream of activity to pull out the real company moves, or scoring one account, or writing one first line. Hand the model the whole job at once and it spreads thin, the output turns to mush, and you cannot tell which part failed. Give it one labelled step and both of those problems go away. Case is the instance: this one company, this one person, and the exact signal that fired this week. Where the role stays fixed across every account you touch, the case is the part that makes a message about this person and nobody else. Without it you are back to a template with a merge field. Evidence is what the model is allowed to know and say, and it comes in two halves. The first is the account's own history, what fired before, what you already sent, whether they went quiet, so the model does not reopen a dead angle. The second is the proof you are cleared to quote, the real numbers and outcomes, so it never reaches for one that does not exist. This is the layer that stops hallucination, because a fact that is not in it is a fact the model may not use. Rules cover how the message must sound and what the agent may never do, from the voice and the length and the output shape down to the hard stops: no pricing, no unverified claim, nothing sent without a human in front of it. This is the guardrail that lets you leave the thing running. Drop any one of the four and you can predict the failure. Lose Role and the model does the whole job badly at once. The other three fail more quietly: without Case it writes to a segment, without Evidence it makes things up, and without Rules it sends something you would never have put your name to. Three skills work those four layers. One assembles the window, one writes from it, and one refines it after the replies come back. That is the whole pack, and here is each. ## Skill one, assemble: build the smallest window that is sufficient The instinct is to hand the model everything, the full CRM row, the whole knowledge base, every past email, because more feels safer. It is also the most reliable way to produce bland copy. A window with too much in it makes the model average across all of it, and the average of your knowledge base is a generic sentence, while a window with too little sends it back to guessing. Assemble picks the minimum that is enough for one step and composes it from the four layers: ``` def assemble(step_role, account, signal, record, kit): """Build one context window. Nothing else touches the model.""" return { "role": step_role, # the one job of this step "case": {"account": account, "signal": signal}, "evidence": { "history": record.get(account, {}), # what we know + already said "proof": kit.proof_for(signal.bucket), # only claims that are real }, "rules": { "voice": kit.voice, # how it must sound "format": step_role.output_shape, # the exact output "never": kit.hard_bans, # pricing, unverified, no auto-send }, } ``` The interesting part is what it leaves out. There is no product sheet and no back catalogue of old emails in there, only the one signal, the slice of history that stops a repeat, and the proof that fits this kind of moment. ## Skill two, write: one message, grounded in the window Write takes a window and returns one line. It never touches your database, only the window assemble handed it, and it may use a fact only if that fact sits in the Evidence layer. The whole skill is a single instruction: ``` WRITE = """You write one first line from a context window, nothing else. INPUT: role, case (account + signal), evidence (history + allowed proof), rules. Open on the signal in CASE. Never a template opener. Use a proof figure only if it appears in EVIDENCE. If none fits, write the outcome with no number. Obey every ban in RULES.voice. Three sentences, one small ask. Output JSON only: {"first_line":"","proof_used":"quote from evidence or 'none'"}""" ``` The point of context engineering is that this instruction never changes and the output still does, because the window does. Give write the bloated window, heavy on product sheet and thin on the signal, and it pitches: > "Hi Alexis, congrats on the new role. Our platform helps growth teams do more with less. Worth a quick call?" That is fluent, generic, and gone the second she reads it. Give the same instruction the assembled window instead (the role set to open on what they did, the case naming Alexis's Growth Ops post from six days ago, the evidence carrying one proof point that fits a hiring moment and nothing else), and it comes back with: > "Saw the Growth Ops role went up right after you stepped in. Usually that hire spends month one firefighting attribution instead of building, so we take that half off the plate for teams your size. Worth a look, or too early?" Nothing changed but the window, and the second one reads like someone actually looked. ## Skill three, refine: write the context back The skill people skip is the one that makes the whole thing compound. Refine runs after a batch of replies, reads what happened, and edits the context files so the next window is sharper. It is the same weekly-learn idea from the loops build, pointed at the window rather than the score: ``` REFINE = """You update the context files after a batch, so the next window is sharper. INPUT: outcomes [{signal_bucket, first_line, result}], result is replied|meeting|no_reply|bounced. A first_line that earned a reply: promote it into the proof file as a pattern that works. A signal_bucket that keeps earning no_reply or 'not now': rewrite its meaning so it is read later or dropped. Never add a proof figure that is not real, even if it would help. Output JSON only: {"promote":[""],"reweight":{"bucket":"new meaning"},"note":"one line"}""" ``` Its output goes straight back into the files that assemble reads on the next run, so the system gets better without anyone retraining anything. The messages improve on their own because the context underneath them does. ## How the three skills chain into a loop In a full outbound loop a nightly job assembles a fresh window for each step in turn: 1. one to extract the real signals out of the day's activity 2. one to score who has earned a message and why 3. one for write to draft the first line 4. and one to check that draft as a skeptic before it goes anywhere. Refine runs weekly over the outcomes. The output of a loop built this way is a ranked shortlist with a reason beside each name, and the reason quotes the actual trigger, because the Case layer put it there and the Rules layer refused to let a generic one through. ## Clone the three skills Assemble, write, and refine are in a repo, built as three Claude Code skills with the context files they read. Drop the folder into a project you already open with Claude Code and the skills are picked up on their own. There is one real piece of work: fill the four-layer files with your ICP, your signal readings, your proof, and your voice. The files ship shaped and filled with a worked example, so you are editing, not starting from a blank page. Then run the loop by hand on one real prospect. Ask Claude to assemble the window, then to write from it, and after the replies come back, to refine the files. Wire it into your own loop once the messages are good by hand. If you want to see it move before touching your own data, it also runs offline with no model and no API key: it builds a window and writes the example message end to end. Comment "CONTEXT" and I will send it over. It will not manage your deliverability or clean ten messy data sources for you. It is enough to feel the difference between prompting a model and engineering what it sees. ## Or use the full one The pack is the manual version. The agent we built at Sortlist, yourmax.ai, assembles these windows for you: it learns your best-fit buyer, watches the signals, drafts the message with the real reason attached, and waits for your approval before anything sends. You connect the tools you already use and describe the routine in chat. It is live now, in limited demos at yourmax.ai. ## 相关链接 - [Nicolas Finet](https://x.com/nifinet) - [@nifinet](https://x.com/nifinet) - [8.2K](https://x.com/nifinet/status/2076706274226684376/analytics) - [yourmax.ai](http://yourmax.ai/) - [yourmax.ai](http://yourmax.ai/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [12:32 AM · Jul 14, 2026](https://x.com/nifinet/status/2076706274226684376) - [8,238 Views](https://x.com/nifinet/status/2076706274226684376/analytics) --- *导出时间: 2026/7/14 10:10:34* --- ## 中文翻译 # 面向外拓的上下文工程 **作者**: Nicolas Finet **日期**: 2026-07-13T16:32:13.000Z **来源**: [https://x.com/nifinet/status/2076706274226684376](https://x.com/nifinet/status/2076706274226684376) --- 如果给两个外拓智能体相同的模型、提示词和购买信号，它们发送的信息依然会截然不同。其中一个会用确凿的理由作为开场，说明新一轮融资为何在本季度给那个团队带来了新问题。另一个则向所有同类职位的人发送“嗨 {{firstName}}，我注意到贵公司在发展”这种信息。将它们区分开来的是上下文：即在模型开始写字之前填入窗口的所有内容。上下文工程就是构建这个窗口的工作。对于模型执行的每一步，你都要决定它应该看到什么，以及应该忽略什么。以下内容将其应用于外拓场景，分为三项小技能，你可以在这里阅读，并在文末进行克隆。我将先从理念开始，因为它决定了你要构建什么；接着介绍构成上下文窗口的四个层级；最后是三项技能，它们负责组装窗口、基于窗口撰写内容以及随时间推移对其进行优化。 ## 提示词与上下文提示词是你告诉模型去做什么，而上下文是它在执行过程中能看到的内容。人们所谓的“幻觉”大多其实是一个空窗口。模型编造了一个数字，是因为从未把真实的数字放在它面前；或者它听起来像机器人，是因为没有任何东西向它展示你的写作风格；又或者它推销了错误的产品，是因为它看不到你已经发给该客户的两封邮件。所有这些问题都无法通过提示词本身来解决。你需要通过工程化窗口来解决它：即决定在模型执行的每一步中，它需要看到什么，同样重要的是，需要屏蔽什么。 ## 上下文窗口的四个层级：角色、案例、证据、规则一个用于外拓决策的良好窗口只需要包含这四样东西，多一样都不要。角色是指这一步的唯一任务，它绝不是“运行外拓”，而是某种狭窄的任务，例如读取活动流以提取真正的公司动向、给某个客户评分，或者撰写一行开场白。如果你一次性把整个工作交给模型，它的精力就会分散，输出结果会变得模糊不清，你也无法判断是哪个部分出了问题。给它一个标记明确的步骤，这两个问题就都会消失。案例是指具体的实例：这家公司、这个人，以及本周触发的确切信号。角色在你接触的每个客户中是固定的，而案例则是让信息只关于这个人而不关于其他人的部分。没有它，你就退回到只能使用带有合并字段的模板。证据是模型被允许知道和可以说的话，它分为两半。第一半是客户自己的历史记录：之前触发了什么、你已经发送了什么、他们是否已沉默，这样模型就不会重提一个已无希望的话题。第二半是你被获准引用的证明，即真实的数字和结果，这样它就不会去捏造一个不存在的数字。这是阻止幻觉的层级，因为不在其中的事实就是模型不能使用的事实。规则涵盖了信息必须呈现的语气以及智能体绝不能做的事情，从语调、长度和输出格式，到硬性底线：不报价、不做未经验证的声明、没有人工把关绝不发送。这是护栏，能让你放心地让系统持续运行。缺少这四者中的任何一个，你都能预测到失败。失去角色，模型就会一次性把整件事做得很差。其他三者的失败则更为隐蔽：没有案例，它写给的是一个细分群体；没有证据，它会编造内容；没有规则，它会发送你绝不会署名的内容。三项技能负责操作这四个层级。一项负责组装窗口，一项负责基于窗口撰写，另一项在回复回来后对其进行优化。这就是整套技能包，以下是每一项的详细介绍。 ## 技能一，组装：构建足够小的窗口本能反应是把所有东西都交给模型：完整的 CRM 记录、整个知识库、每一封历史邮件，因为感觉多一点更安全。但这也是产生平庸文案最可靠的方法。一个内容过多的窗口会让模型对所有内容取平均值，而你知识库的平均值就是一句通用的句子；而一个内容过少的窗口则会迫使它回到猜测模式。组装会选择足够完成某一步的最低限度内容，并从四个层级将其组合起来： ``` def assemble(step_role, account, signal, record, kit): """构建一个上下文窗口。模型仅接触此内容。""" return { "role": step_role, # 这一步的唯一任务 "case": {"account": account, "signal": signal}, "evidence": { "history": record.get(account, {}), # 我们已知的 + 已说过的 "proof": kit.proof_for(signal.bucket), # 仅限真实的声明 }, "rules": { "voice": kit.voice, # 必须呈现的语气 "format": step_role.output_shape, # 精确的输出格式 "never": kit.hard_bans, # 不报价、不推测、无人工不发 }, } ``` 有趣的部分在于它忽略了什么。里面没有产品说明书，也没有旧邮件的档案，只有那个信号、防止重复的那一段历史，以及适合这类时刻的证明。 ## 技能二，撰写：基于窗口生成一条信息撰写接收一个窗口并返回一行内容。它从不接触你的数据库，只接触组装传给它的窗口，而且只有当某个事实位于证据层中时，它才能使用该事实。整个技能就是一条指令： ``` WRITE = """你从上下文窗口中撰写一行开场白，不写其他内容。输入：role, case (account + signal), evidence (history + allowed proof), rules. 以 CASE 中的信号开头。绝不要模板式的开场。仅当数字出现在 EVIDENCE 中时才使用它作为证明数据。如果没有合适的，就写不带数字的结果。遵守 RULES.voice 中的每一项禁令。三句话，一个微小请求。仅输出 JSON：{"first_line":"","proof_used":"引用自证据或 'none'"}""" ``` 上下文工程的要点在于，这条指令永远不变，但输出结果却在变，因为窗口变了。如果给撰写一个臃肿的窗口，充斥着产品说明书却缺乏信号，它就会推销： > “嗨 Alexis，恭喜履新。我们的平台帮助增长团队以少做多。值得快速聊一聊吗？” 这行文流畅，但很通用，她看完的瞬间就会遗忘。如果给同一条指令换成组装好的窗口（角色设置为针对他们所做的事，案例指明 Alexis 六天前的 Growth Ops 帖子，证据层包含一个适用于招聘时刻的证明点，别无其他），它会返回： > “看到你上任后马上发布了 Growth Ops 的职位。通常这个招来的人在第一个月会忙于处理归因问题的救火工作，而不是搞建设，所以我们为你这种规模的团队分担这一半的工作。值得一看吗，还是太早了？” 除了窗口，什么都没变，但第二条读起来就像是真正有人关注过。 ## 技能三，优化：将上下文写回人们跳过的这项技能，正是让整个系统产生复利效应的关键。优化在一批回复回来后运行，读取发生了什么，并编辑上下文文件，以便下一个窗口更加犀利。这跟循环构建中的每周学习理念一样，只是指向的是窗口而不是评分： ``` REFINE = """你在一批次处理后更新上下文文件，使下一个窗口更犀利。输入：outcomes [{signal_bucket, first_line, result}], result 为 replied|meeting|no_reply|bounced。一个赢得回复的 first_line：将其作为有效模式提升到证明文件中。一个持续赢得 no_reply 或 'not now' 的 signal_bucket：重写其含义，以便稍后读取或丢弃。绝不要添加不真实的证明数据，即使那会有所帮助。仅输出 JSON：{"promote":[""],"reweight":{"bucket":"new meaning"},"note":"one line"}""" ``` 它的输出会直接回到组装在下一次运行时读取的文件中，这样系统无需任何人重新训练任何东西就能变得更好。信息会自动改进，因为它们底层的上下文在改进。 ## 三项技能如何串联成循环在一个完整的外拓循环中，一个夜间任务会依次为每一步组装一个新的窗口： 1. 一步用于从当天的活动中提取真实信号； 2. 一步用于评判谁有资格收到信息以及原因； 3. 一步用于撰写来起草第一行； 4. 还有一步用于在草稿发出之前以怀疑的态度进行检查。优化每周基于结果运行一次。以这种方式构建的循环，其输出是一个带有排名的候选名单，每个名字旁都有一个理由，而且这个理由引用了实际的触发器，因为案例层把它放在了那里，而规则层拒绝让通用的理由通过。 ## 克隆这三项技能组装、撰写和优化都在一个代码库中，构建为三个 Claude Code 技能，以及它们读取的上下文文件。把这个文件夹放入你已经用 Claude Code 打开的项目中，这些技能就会被自动识别。只有一项真正的工作要做：用你的 ICP（理想客户画像）、信号解读、证明和语气填充这四个层级的文件。这些文件自带形状并填充了一个现成的示例，所以你是在编辑，而不是从空白页开始。然后在一个真实的潜在客户身上手动运行这个循环。让 Claude 组装窗口，然后基于窗口撰写，等回复回来后，优化文件。一旦手动生成的消息效果不错，再将其接入你自己的循环中。如果你想在触碰自己的数据之前先看看它的运行效果，它也可以离线运行，无需模型和 API 密钥：它会构建一个窗口并端到端地写出示例消息。评论“CONTEXT”，我会发给你。它不会帮你管理送达率，也不会帮你清理十个混乱的数据源。它足以让你感受到“提示模型”与“工程化模型所见内容”之间的区别。 ## 或者使用完整版这个技能包是手动版本。我们在 Sortlist 构建的智能体 yourmax.ai 会为你组装这些窗口：它学习你最适合的买家，关注信号，起草带有真实理由的信息，并在任何内容发送前等待你的批准。你只需连接你已经在使用的工具，并在聊天中描述日常流程。它现已上线，在 yourmax.ai 提供有限演示。 ## 相关链接 - [Nicolas Finet](https://x.com/nifinet) - [@nifinet](https://x.com/nifinet) - [8.2K](https://x.com/nifinet/status/2076706274226684376/analytics) - [yourmax.ai](http://yourmax.ai/) - [yourmax.ai](http://yourmax.ai/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [12:32 AM · Jul 14, 2026](https://x.com/nifinet/status/2076706274226684376) - [8,238 Views](https://x.com/nifinet/status/2076706274226684376/analytics) --- *导出时间: 2026/7/14 10:10:34*

🔗 相关文档