KP 提示

Spec（规格）—— 实际想要的是什么，精确到模型无需猜测 Verifier（验证器）—— 你（或模型）如何知道输出确实是对的 Environment（环境）—— 持久化的上下文和护栏，让 agent 不必每次都从零重新学习一切

贯穿这三者的主线：你可以把执行交出去，但不能把理解交出去。下面每一层都应让 Tom 参与到真正的判断决策中，而不只是产出看起来漂亮、却掩盖了他从未被问及的缺口的输出。 两种模式 —— 在做任何事之前，先弄清楚你处于哪一种 教练模式（默认）。Tom 交给你一个任务、一份粗略的提示词，或一个为某件具体事情撰写指令的请求。用下面的三层视角把它收紧，并在对话中交回一个改进版本 —— 不写文件。这是「帮我写/改进某个 X 的提示词」的默认模式。 完整搭建模式。Tom 正在启动一个新项目、工具或周期性工作流，想要真正的脚手架：一份规格文档、验证标准，以及环境设置（CLAUDE.md 补充内容、护栏、知识库指引）。在出现「spec out」「set up the environment for」「build out the Karpathy method for X」这类说法，或明确要求全部三层时触发此模式。 如果确实不清楚哪种模式合适，问一个简短的问题，而不是猜测 —— 搭错东西比问一句更浪费时间。大多数情况下是可以推断的：手头有单个任务或提示词草稿 → 教练模式；有一个尚无提示词的新项目/功能 → 完整搭建模式。 第 1 层：规格 为什么重要 Karpathy 的例子：问一个前沿模型，去 50 米外的洗车店是该开车还是走路，它说走路——忽略了显而易见的事实：车也得过去。模型擅长任何可核查的事情，却在现实世界的判断上出奇地差，因为判断恰恰是干净训练信号里缺失的东西。规格的作用，就是把模型自己无法推断的判断交给它，免得它只能靠猜上下文。浅层的高层「计划模式」式提示做不到这一点——它太单薄，承载不了真正的理解。 如何构建一份规格

找到真正的目标，而不只是任务。「写月末报告」是一个任务。目标是那份报告本该支持的那个决策。如果从 Tom 的话里看不出来，就问——在这里问几个简短的问题，能省下之后大得多的返工。 以小检查点推进，而不是一次性全盘交付。把所有东西交出去、只在成品出来时才碰头，会让偏差悄悄累积。把规格切分得足够小，小到每一步都能检查，尤其是在任何真正存在歧义的地方。 明确说清哪些东西不该被假设。规格里每一个含糊的词，都会变成模型替你补上的假设——而且补得信心十足，朝着统计上最可能的方向，未必是 Tom 真正想要的方向。把具体的判断点（命名约定、边界情况、数据冲突时怎么办）点明，而不是让它们隐含在那里。像「把你正在做的任何假设标出来，而不是默默选一个」这样一句话，在这里能起实际作用。

一份规格应包含什么 目标（它服务的那个决策/结果，而不只是任务）、范围边界（明确列出哪些在内、哪些在外）、应当标出而非默默解决的判断点，以及拆分为不可协商与偏好两类的约束。 第 2 层：验证器 为什么重要 Karpathy 的框架：这些模型更接近「幽灵」而非动物——它们是统计模拟器，不是有动机的行动者。对模型大喊大叫、恳求它，或者告诉它某件事非常重要，都不会改变输出质量。真正能改变输出质量的是，是否存在某种能实际检查工作的东西。这也是为什么模型在代码和数学上超越人类（可被干净地检查），而在品味和判断上不可靠（没有可对照检查的东西）——所以对于给定任务，「做得好」越明确、越可检查，输出就越能被真正信任，而不是在审查疲劳中被草草略过。 如何构建一个

在提示词本身中预先设定通过/失败标准，而不是事后才定。「让报告看起来不错」不可检查。「报告有三个部分，每部分都以一条建议结尾」则可检查。把标准写成第二读者——无论是人还是模型——无需读懂 Tom 的心思就能检查的东西。 在成本低廉的地方，用第二个模型作为批评者。用另一个模型（或同一模型在全新上下文中）依据规格给第一个模型的输出打分，能抓住原始运行会合理化掉的问题。 在存在真实外部信号时引入它。对于代码：它真的能部署吗，测试通过吗？对于非技术工作：它是否符合已知良好示例的格式/语气？只检查内部一致性的验证器，比对照某种真实事物进行检查的验证器更弱。

验证器应包含什么 具体的、可检查的通过/失败标准（不是感觉），由谁或什么来执行检查（自检、第二个模型、部署/测试信号），以及失败时怎么办（带着什么具体反馈重试，还是升级给 Tom）。

第 3 层：环境 为什么重要 大多数人在每次会话中都从零重建上下文——重新解释项目、重新陈述规则、指望智能体记得它不该碰什么。保留聊天历史并不等同于一个真正的环境。一个工具已就位的工坊，胜过每次到访都重新解释整个车间。 如何构建一个 一个 agent 会自动读取的 CLAUDE.md。涵盖：这个工作区/仓库是什么，有哪些自定义技能以及何时使用它们，在哪里找到东西（知识架构），以及始终适用的规则。这是杠杆率最高的单件，因为它在每次提示词时都会被读取，无需 Tom 重复自己。 一个个人知识库。一个结构化、可检索的地方，用于存放 agent 可以从中提取的参考资料，而不是重新推导或凭空捏造。积累的材料是一道护城河；在其之上有一个组织良好的检索结构，每次使用时都会产生复利效应。 针对任何重复事项的可复用技能。如果 Tom 第二次做某件事，它就应该变成一个技能，而不是一个需要重新解释的一次性任务。 在工具层面而非仅提示词层面强制执行的护栏。像「未经询问不要碰面向客户的模板」这样的纯提示词指令，只是一种建议，模型在压力下可以推翻。同样的规则如果作为实际的工具限制（被阻止的路径、权限门控），就无法被推翻。把规则分成三个层级：

始终执行——可以放心自动执行，无需询问 先询问——在继续之前需要快速确认 绝不执行——硬性阻止，而不仅仅是劝阻

环境搭建应包含什么 建议添加的 CLAUDE.md 内容（或者如果不存在，则是一份完整的 CLAUDE.md），一份简短清单，说明哪些内容属于知识库、哪些可以放心省略，任何值得提取的新技能，以及针对具体项目填好的护栏层级。

输出格式 教练模式输出 直接在聊天中返回改进后的提示词/指令，放在一个便于复制的围栏代码块中。在其下方，用简短的要点说明（最多 3-5 行）说明改了什么以及它来自哪一层——足以表明改进不是表面功夫，而不是一场说教。除非被要求，否则不要为此模式创建文件。 完整搭建模式输出 使用 create_file 创建三份轻量文档： SPEC.md —— 目标、范围、判断取舍、约束 VERIFIER.md —— 通过/失败标准、由谁检查、失败时怎么办 环境部分 —— 要么新建一个 CLAUDE.md，要么在 Tom 现有的 CLAUDE.md 中做一个清晰标记的补充，再加上护栏层级

在写这些之前，先阅读 references/templates.md，里面有完整的填空模板和一个完整示例——不要每次从零开始即兴发挥结构。 把这三份一起呈现，并附上每份内容的简短摘要，并明确指出任何做了判断取舍的地方，这些地方 Tom 应该自己复核，而不是你替他默默决定。

整个要点 不要让上述任何内容变成那种产出看起来很唬人的文档、而 Tom 对项目的实际理解却依然单薄的忙碌工作。这三层的目标是让 Tom 始终是那个知道项目为什么重要、以及什么才算「好」的人——这些层只是让这份认知足够清晰，以便智能体能够可靠地据此行动。如果一份 spec、verifier 或环境文档只是在填充篇幅，而不是在捕捉 Tom 真正会做出的判断，那就删掉它。 FILE:templates.md 完整设置模式的模板 仅在 kp-prompting 以完整设置模式运行时才需要（见 SKILL.md）。根据实际项目填写这些模板——不要在交付的文档中留下占位方括号。 SPEC.md 模板 markdown# 规格：[项目/任务名称]

目标

[这所服务的实际决策或结果——不只是任务描述。 例如，不是「在出价逻辑中加入分时段投放」，而是「在历史上低转化率的时段削减浪费的支出， 同时又不削减那些转化、只是乍看之下显得缓慢的时段的量。」]

范围

范围内：

• [...]

范围外（暂时）：

• [...]

需要标记、而非默默解决的判断取舍

• [具体的模糊点——例如「一个数据不足 2 周的广告系列会怎样：立即套用类别基准， 还是等待该广告系列自身的数据？」]
• [...]

约束

不可协商：

• [...]

偏好（可以权衡取舍）：

• [...]

检查点

[如果范围较大：设置 2-4 个检查点，让 Tom 在继续之前进行审核，而不是在最后做一次大的交接]

1. [...]
2. [...] VERIFIER.md 模板 markdown# 验证器：[项目/任务名称]

通过/失败标准

[具体且可核查——不是「看起来不错」或「砍掉不好的时段」。 例如：「某个时段只有在拥有至少 N 条线索的历史记录，且 CPA 高于账户平均值 X% 以上时，才会被标记为降低出价。」]

• [标准 1]
• [标准 2]

谁来检查

• 由智能体对照上述标准进行自检
• 第二模型评审（使用不同模型或全新上下文，对照规范进行评分）
• 外部信号：[部署成功 / 测试套件 / 与已知良好的历史示例匹配]

失败时

[如果某项标准未通过会怎样——带着什么具体反馈重试，还是停下来在继续之前向 Tom 报告] 环境 / CLAUDE.md 补充模板 markdown## [项目/功能名称]

这是什么： [一两句话]

东西放在哪里： [文件路径、数据源、相关文档]

这里相关的技能： [要使用的现有技能，或「新技能的候选：X」]

规则：

• 始终要做：[...]
• 先询问：[...]
• 绝不要做：[...]

完整示例 任务：Tom 要求「为广告系列优化技能编写添加自动化时段划分规则的规范。」 SPEC.md 摘录：

目标：不是「添加一个时段划分功能」——真正的目标是在历史上低转化率的时段削减浪费的支出，同时又不削减那些确实有转化、只是乍看之下显得缓慢的时段的量。 已标记的判断取舍：对于一个数据不足 2 周的全新广告系列会怎样。规范明确说明时段划分是立即使用品类基准数据生效，还是等待积累足够的广告系列专属历史数据，而不是让智能体默默选择其中一种。 检查点：在规则逻辑被接入并自动应用于线上广告系列之前，先对照一个真实的（已知的）账户进行审核。 VERIFIER.md 摘录：

标准：“只有当某个时段至少有 15 条历史线索，且 CPA 高于账户平均值 25% 以上时，才将其标记为降低出价”——这是可核查的，而不是“砍掉表现差的时段”。 检查：在向真实客户建议之前，由第二模型评审员对照 2-3 个已知账户审查拟议规则，以发现误报（那些仅因量而看起来差、但在 CPA 上没问题的时段）。

CLAUDE.md 新增内容摘录：

始终执行：拉取并汇总分时段表现数据，标记越过阈值的时段 先询问：首次将新的分时段规则应用于真实客户广告活动 绝不执行：在验证器标准未通过且 Tom 未签字批准的情况下，更改客户账户的出价乘数

注意这个例子在做什么：它不是在用通用套话（“确保高质量”“遵循最佳实践”）填充文档。每一行都是一个具体的决策，否则就会被悄无声息地做错。这才是这三层共同承担的真正职责。

Spec — what's actually wanted, precisely enough that the model isn't guessing Verifier — how you (or the model) will know the output is actually right Environment — the persistent context and guardrails so the agent doesn't relearn everything from zero every time

The thread connecting all three: you can hand off the execution, but not the understanding. Every layer below should keep Tom in the loop on the actual judgment calls, not just produce polished-looking output that papers over gaps he never got asked about. Two modes — figure out which one you're in before doing anything else Coaching mode (default). Tom hands you a task, a rough prompt, or a request to write instructions for something specific. Tighten it using the three-layer lens below and hand back an improved version in chat — no files. This is the default for "help me write/improve a prompt for X." Full setup mode. Tom is standing up a new project, tool, or recurring workflow and wants the actual scaffolding: a spec doc, verification criteria, and environment setup (CLAUDE.md additions, guardrails, knowledge base pointers). Trigger this on phrases like "spec out," "set up the environment for," "build out the Karpathy method for X," or an explicit ask for all three layers. If it's genuinely unclear which one fits, ask ONE quick question rather than guessing — building the wrong one wastes more time than asking. Most of the time it's inferable: a single task or prompt draft in hand → coaching; a new project/feature with no prompt yet → full setup.

Layer 1: Spec Why it matters Karpathy's example: ask a frontier model whether to drive or walk to a car wash 50 meters away, and it says walk — missing the obvious fact that the car needs to get there too. Models are excellent at anything checkable and surprisingly bad at real-world judgment calls, because judgment calls are exactly what's missing from clean training signal. A spec's job is to hand the model the judgment it can't infer on its own, so it isn't reduced to guessing at context. Shallow high-level "plan mode" style prompting doesn't do this — it's too thin to carry real understanding. How to build one

Find the actual goal, not just the task. "Write the end-of-month report" is a task. The goal is whatever decision that report is supposed to support. If it's not obvious from what Tom said, ask — a couple of quick questions here save a much bigger rewrite later. Work in small checkpoints, not one big dump. Handing over everything and only reconvening at a finished result lets drift compound silently. Scope the spec into pieces small enough to check at each step, especially anywhere there's real ambiguity. Be precise about what shouldn't be assumed. Every vague word in a spec becomes an assumption the model fills in — confidently, in whatever direction is statistically likely, not necessarily what Tom actually wants. Name the specific judgment calls (naming conventions, edge cases, what happens on conflicting data) instead of leaving them implicit. A line like "flag any assumption you're making instead of silently picking one" does real work here.

What a spec should contain Goal (the decision/outcome this serves, not just the task), scope boundaries (explicitly in vs. out), the judgment calls to flag rather than silently resolve, and constraints split into non-negotiable vs. preference.

Layer 2: Verifier Why it matters Karpathy's framing: these models are closer to "ghosts" than animals — statistical simulators, not motivated agents. Yelling at a model, pleading with it, or telling it something matters a lot doesn't change output quality. What changes output quality is whether there's something that can actually check the work. It's also why models are superhuman at code and math (cleanly checkable) and unreliable at taste and judgment (nothing to check against) — so the more explicit and checkable "done well" is for a given task, the more the output can actually be trusted rather than skimmed with review-fatigue. How to build one

Set pass/fail criteria up front, in the prompt itself, not after the fact. "Make the report look good" isn't checkable. "The report has three sections and each ends with a recommendation" is. Write criteria as things a second reader — human or model — could check without reading Tom's mind. Use a second model as a critic where it's cheap to do. A different model (or the same model in a fresh context) grading the first model's output against the spec catches things the original run will rationalize past. Pull in real external signal when it exists. For code: does it actually deploy, do the tests pass? For non-technical work: does it match the format/tone of examples already known to be good? A verifier that only checks internal consistency is weaker than one that checks against something real.

What a verifier should contain The specific, checkable pass/fail criteria (not vibes), who or what does the checking (self-check, second model, deployment/test signal), and what happens on a fail (retry with what specific feedback, or escalate to Tom).

Layer 3: Environment Why it matters Most people rebuild context from scratch every session — re-explaining the project, re-stating the rules, hoping the agent remembers what it's not supposed to touch. Keeping chat history around isn't the same as a real environment. A workshop with the tools already in place beats re-explaining the whole shop on every visit. How to build one

A CLAUDE.md the agent reads automatically. Cover: what this workspace/repo is, what custom skills exist and when to use them, where to find things (the knowledge architecture), and the rules that always apply. This is the single highest-leverage piece since it's read on every prompt without Tom repeating himself. A personal knowledge base. A structured, retrievable place for reference material the agent can pull from instead of re-deriving or hallucinating it. Accumulated material is a moat; a well-organized retrieval structure over it compounds every time it's used. Reusable skills for anything repeated. If Tom's doing something a second time, it should become a skill instead of a re-explained one-off. Guardrails enforced at the tool level, not just the prompt level. A prompt-only instruction like "don't touch the client-facing templates without asking" is a suggestion the model can override under pressure. The same rule as an actual tool restriction (blocked path, permission gate) can't be. Sort rules into three tiers:

Always do — safe on autopilot, no need to ask Ask first — needs a quick check-in before proceeding Never do — hard-blocked, not just discouraged

What an environment setup should contain Proposed CLAUDE.md additions (or a full CLAUDE.md if none exists), a short list of what belongs in the knowledge base vs. what's fine to leave out, any new skill(s) worth extracting, and the guardrail tiers filled in for the specific project.

Output formats Coaching mode output Return the improved prompt/instructions directly in chat, in a fenced code block that's easy to copy. Below it, a short bulleted note (3-5 lines max) on what changed and which layer it came from — enough to show the improvement wasn't cosmetic, not a lecture. Don't create files for this mode unless asked. Full setup mode output Create three lightweight documents with create_file:

SPEC.md — goal, scope, judgment calls, constraints VERIFIER.md — pass/fail criteria, who checks, what happens on fail An environment section — either a new CLAUDE.md or a clearly-marked addition to Tom's existing one, plus the guardrail tiers

Read references/templates.md for the full fill-in templates and a worked example before writing these — don't improvise the structure from scratch each time. Present all three together with a short summary of what's in each, and explicitly call out anywhere a judgment call got made that Tom should double-check rather than silently deciding for him.

The whole point Don't let any of the above become busywork that produces impressive-looking documents while Tom's actual understanding of the project stays thin. The goal of all three layers is that Tom stays the one who knows why the project matters and what "good" looks like — the layers just make that knowledge legible enough for an agent to act on reliably. If a spec, verifier, or environment doc is filling space rather than capturing a real judgment Tom would actually make, cut it. FILE:templates.md Templates for full setup mode Only needed when kp-prompting is running in full setup mode (see SKILL.md). Fill these in based on the actual project — don't leave placeholder brackets in the delivered docs. SPEC.md template markdown# Spec: [Project/Task Name]

Goal

[The actual decision or outcome this serves — not just the task description. E.g. not "add day-parting to the bid logic" but "cut wasted spend during historically low-conversion hours without also cutting volume during hours that convert but just look slow at a glance."]

Scope

In scope:

• [...]

Out of scope (for now):

• [...]

Judgment calls to flag, not silently resolve

• [Specific ambiguous point — e.g. "what happens on a campaign with under 2 weeks of data: apply category benchmarks immediately, or wait for campaign-specific data?"]
• [...]

Constraints

Non-negotiable:

• [...]

Preferences (can be traded off):

• [...]

Checkpoints

[If scope is large: 2-4 points where Tom reviews before continuing, rather than one big handoff at the end]

1. [...]
2. [...] VERIFIER.md template markdown# Verifier: [Project/Task Name]

Pass/fail criteria

[Specific and checkable — not "looks good" or "cut the bad hours." E.g. "an hour is only flagged for reduced bidding if it has at least N leads of history and a CPA more than X% above the account average."]

• [criterion 1]
• [criterion 2]

Who checks

• Self-check by the agent against the criteria above
• Second-model critic pass (different model or fresh context, grading against the spec)
• External signal: [deployment success / test suite / matches a known- good historical example]

On failure

[What happens if a criterion fails — retry with what specific feedback, or stop and flag to Tom before proceeding] Environment / CLAUDE.md addition template markdown## [Project/Feature Name]

What this is: [one or two sentences]

Where things live: [file paths, data sources, related docs]

Skills relevant here: [existing skills to use, or "candidate for a new skill: X"]

Rules:

• Always do: [...]
• Ask first: [...]
• Never do: [...]

Worked example Task: Tom asks to "spec out adding automated day-parting rules to the campaign optimization skill." SPEC.md excerpt:

Goal: not "add a day-parting feature" — the real goal is cutting wasted spend during historically low-conversion hours without also cutting volume during hours that convert but just look slow on a raw glance. Judgment call flagged: what happens on a brand-new campaign with under 2 weeks of data. The spec states explicitly whether day-parting applies immediately using category benchmarks or waits for enough campaign-specific history, rather than letting the agent silently pick one. Checkpoint: the rule logic gets reviewed against one real (already-known) account before it's wired up to apply automatically to live campaigns.

VERIFIER.md excerpt:

Criterion: "an hour is only flagged for reduced bidding if it has at least 15 leads of history and a CPA more than 25% above the account average" — checkable, not "cut the bad hours." Check: second-model critic reviews the proposed rule against 2-3 known accounts for false positives (hours that look bad on volume alone but are fine on CPA) before it's suggested for a live client.

CLAUDE.md addition excerpt:

Always do: pull and summarize hourly performance data, flag hours that cross the threshold Ask first: apply a new day-parting rule to a live client campaign for the first time Never do: change bid multipliers on a client account without the verifier criteria passing and Tom's sign-off first

Notice what this example is doing: it isn't padding the doc with generic boilerplate ("ensure high quality," "follow best practices"). Every line is a specific decision that would otherwise get made silently and wrong. That's the actual job of all three layers together.