Dayward AI
中文
Sign inSign up
Week 1 · D3About 4 hours

Getting Started With Claude Code and Managing Context: Install, Writing CLAUDE.md and "Trim Until You Can't", Permission Modes, Plan Mode's "Explore, Then Plan, Then Write", /clear /compact /rewind, Giving Claude a Verifiable Check

Install Claude Code, write the first CLAUDE.md for your own project, learn Plan Mode's explore-then-plan flow, manage context with /clear /compact /rewind, and give Claude a check it can run on its own.

Today's goals 0/3

Sign in to tick these off and save your progress.

今日目标

  1. 能装好 Claude Code 并说清 CLAUDE.md 该写什么、不该写什么
  2. 能用 Plan Mode 走完「探索、计划、实现」并切换合适的权限模式
  3. 能在会话里用 /clear /compact /rewind 管理上下文，并给 Claude 一个可验证的检查

前两天你在跟搭档「说话」，今天开始它会「动手」：读你的文件、跑你的命令、改你的代码。会动手的搭档更需要交代清楚，也更需要一份入职手册。读完做完实验，回到顶部勾掉三条目标。

小白版讲解

安装与第一次对话：Claude Code 是一个会动手的搭档

聊天窗口里的 Claude 像一个只能隔着玻璃给你出主意的顾问：你把代码贴给它，它把建议贴回来，复制粘贴的活全在你这边。Claude Code 是把这位顾问请进了你的终端——它能自己 ls、自己 cat、自己改文件、自己跑测试、自己看报错再改。你从「复制粘贴的中间人」变成了「交代任务、审核结果的人」。

安装只要一条命令。macOS / Linux / WSL 用官方安装脚本，Windows 用 PowerShell 的对应版本；也可以走 Homebrew 或 npm：

BashBash
# macOS / Linux / WSL（推荐，会自动更新）
curl -fsSL https://claude.ai/install.sh | bash
 
# 或者
brew install --cask claude-code
npm install -g @anthropic-ai/claude-code   # 需要 Node 22+
 
# 验证
claude --version
claude doctor     # 检查安装与配置健康度

然后进到任意一个项目目录敲 claude，第一次会让你登录（需要 Pro / Max / Team 账号，或者设了 ANTHROPIC_API_KEY），之后就进入对话。先别急着让它改东西，问几个你会问新同事的问题：「这个项目的测试怎么跑？」「日志是怎么打的？」「加一个新接口要改哪几个文件？」你会看到它自己去翻文件、读 package.json、grep 关键字，然后给出带文件路径的回答。这就是「会动手」的第一层含义：探索是它自己做的，不用你先喂。

第二层含义要等到它开始改代码——那时候你会立刻面对两个问题：它凭什么知道我们项目的规矩？它每一步都要问我一遍吗？接下来两节分别回答。

CLAUDE.md 是入职手册：写什么、不写什么、删到不能再删

新同事入职第一天，你不会把整个代码库讲一遍，而是给他一页纸：怎么起服务、怎么跑测试、我们不用哪些写法、提交信息用什么格式。这一页纸就是 CLAUDE.md——项目根目录下的一个 Markdown 文件，Claude Code 每次开会话都会先读它。它就是 D1 讲的「名片」在 Claude Code 里的形态，只是发名片的人从「产品」变成了「项目」。

先让 Claude 帮你起个草：在项目里跑 /init，它会扫一遍代码库，生成一份包含构建命令、测试方式、目录约定的初稿。这份初稿是起点，不是终点，因为它会写进很多 Claude 自己读代码就能推出来的东西。接下来才是今天最重要的动作——删到不能再删。对每一行问同一个问题：「删掉这行，Claude 会不会犯错？」不会，就删。判据表：

留下删掉
Claude 猜不到的命令（pnpm test:db 要先起 docker）读 package.json 就能看到的脚本名
和默认习惯不同的代码风格（我们不用 default export）语言本身的常规写法
测试怎么跑、跑哪一部分（只跑单文件，别跑全量）逐个文件的功能说明
仓库礼仪（分支命名、提交信息格式）「写干净、可维护的代码」这类废话
项目特有的架构决定与原因经常变的东西（当前 sprint 目标）
环境怪癖（必须设某个环境变量）大段 API 文档（放链接）

为什么要这么苛刻？因为 CLAUDE.md 每次会话都完整进入上下文窗口——它是你每次请求都要付的「固定成本」，而且越长越没用：规则一多，真正重要的那几条就被淹没，官方文档的原话是「臃肿的 CLAUDE.md 会让 Claude 忽略你真正的指令」。经验值是 200 行以内。如果某条规则 Claude 老是不遵守，第一反应不是加粗，而是看文件是不是太长了。

还有几个位置上的细节：项目级放 ./CLAUDE.md 或 ./.claude/CLAUDE.md，跟着 git 走，全组共享；个人偏好放 ~/.claude/CLAUDE.md，对你所有项目生效；只属于你、不想提交的放 ./CLAUDE.local.md 并加进 .gitignore。子目录里的 CLAUDE.md 不会一开始就加载，而是 Claude 读到那个目录的文件时才带进来——大仓库靠这个分层。写完用 /context 看一眼「Memory files」列表，确认文件真的被加载了。

权限模式：从每步都问到放手自动，四档怎么选

搭档要改文件、要跑命令了，你希望它每次都举手问一下，还是放手让它干？Claude Code 把这个选择做成了权限模式，按 Shift+Tab 循环切换，状态栏会显示当前是哪一档：

  • Manual（配置值 default）：改文件、跑命令、调外部工具之前都问你。最安全，也最烦——第十次点「允许」的时候你已经不在审了，只是在点。
  • acceptEdits：改文件不问，跑命令仍然问。适合「我信它写代码，但命令我要看一眼」。
  • plan：只读。它能读文件、跑只读命令、回答问题、写计划，但不能改任何东西。下一节的主角。
  • auto：不问你，改由一个独立的分类器模型审每一步，拦住看起来危险的（范围扩大、碰未知基础设施、被恶意内容驱动的动作），其余放行。Pro / Max / Team 计划的交互式会话默认就是它。

还有两档主要给自动化用：dontAsk（不在白名单里的一律拒绝，适合锁死的 CI）和 bypassPermissions（全部放行，只在隔离的沙箱里用）。这两档 D5 讲进 CI 时再展开。

比「选哪一档」更实用的是两个减少打扰又不放弃控制的工具：用 /permissions 把你信得过的命令加进白名单（比如 pnpm lint、git commit），用 /sandbox 开操作系统级的文件与网络隔离，让 Claude 在围栏里自由跑。白名单的语法值得记住一个例子：Bash(git diff *) 里那个空格很重要，没有空格的 Bash(git diff*) 会把 git diff-index 也放进来。

Plan Mode：先探索再计划再写，用示例任务走一遍

让搭档一上来就写代码，最常见的结果是「代码很漂亮，但解决的是另一个问题」。好的协作是分三步：先看清现状，再商量方案，最后动手。Plan Mode 把这三步做成了一个开关：按 Shift+Tab 切到 plan，或者一开始就 claude --permission-mode plan 启动——在这个模式下 Claude 只能读不能写，你可以放心让它到处翻。

用示例任务走一遍。第一步探索，在 plan 模式下说：

TextText
读一下 src/routes/todos.ts 和 test/ 目录，搞清楚现在 POST /todos 是怎么处理请求体的，
测试用的是什么框架、怎么跑。先别改任何东西。

第二步计划：

TextText
我想给 POST /todos 加输入校验（title 必填 1–200 字，dueAt 可选且必须是 ISO 日期，
不允许客户端传 id 和 done），并补对应的单元测试。要改哪些文件？校验失败的响应格式怎么定？
写一份计划。

它会给出一份带文件清单和步骤的计划。这时按 Ctrl+G 可以在你的编辑器里直接改这份计划——多数时候你会删掉一两步、改一个命名。第三步实现：退出 plan 模式（批准计划或再按 Shift+Tab），然后：

TextText
按你的计划实现。先写失败的测试，再实现校验，跑 pnpm test 直到全部通过。

第四步提交：「用一句描述性的提交信息提交」。四步走完，一个 PR 就出来了。Claude 最终产出的核心改动，两种技术栈大致是这个样子：

src/routes/todos.ts
import { Router } from 'express'
import { z } from 'zod'
 
// 只声明客户端可以传的字段；id 与 done 不在 schema 里，传了也会被丢掉
const CreateTodo = z
  .object({
    title: z.string().trim().min(1).max(200),
    dueAt: z.string().datetime().optional(),
  })
  .strict() // 多余字段直接判 400，而不是静默忽略
 
export const router = Router()
 
router.post('/todos', (req, res) => {
  const parsed = CreateTodo.safeParse(req.body)
  if (!parsed.success) {
    // 结构化的 issues 让前端能逐字段提示，也让测试能精确断言
    return res.status(400).json({
      error: 'invalid body',
      issues: parsed.error.issues.map((i) => ({ path: i.path, message: i.message })),
    })
  }
  const todo = { id: crypto.randomUUID(), done: false, ...parsed.data }
  store.push(todo)
  res.status(201).json(todo)
})

什么时候不要用 Plan Mode？改个拼写、加一行日志、重命名一个变量——这种「一句话就能描述 diff」的活，直接让它做，计划反而是负担。判据很简单：你不确定方案、要改多个文件、或者你不熟这块代码，就先 plan；否则直接上。

上下文是最稀缺的资源：/clear /compact /rewind 各管一件事

D2 说过上下文窗口是最稀缺的资源，在 Claude Code 里这句话会变成每天的切身感受：它读的每个文件、跑的每条命令的输出、你们的每一轮对话，全都堆在同一个窗口里。一次调试可能就消耗几万 token，窗口越满，它越容易「忘掉」早先的指令、越容易出错。官方 best practices 页几乎所有建议都是从这一条约束推出来的。

所以要主动管。三个命令各管一件事，别混用：

  • /clear——任务之间清零。 做完一件不相关的事就清，让下一件事从干净的窗口开始。最常见的失败模式叫「大杂烩会话」：修完 A 顺手问了 B，又回头改 A，窗口里全是互不相关的东西。另一条经验：同一个问题纠正它两次还不对，就 /clear，用一条吸收了教训的更好的提示词重开——失败的尝试留在窗口里只会继续污染。
  • /compact——任务中途压缩。 一件事做了很久、窗口快满但还没做完，用 /compact 让它把历史总结成一段摘要，腾出空间。可以带指令：/compact 保留 API 改动和测试命令。窗口接近上限时它也会自动压缩，但你主动压能控制留什么。
  • /rewind（或连按两次 Esc）——回到某个检查点。 每一条你发出的提示都会自动建一个检查点，文件改动前也会快照。走错了方向，打开 rewind 菜单，可以只恢复对话、只恢复代码，或两个都恢复；还可以从某个点开始「向后总结」——只压缩那一段而保留其余。这让「让它大胆试一个方案，不行就退回来」成为一种正常的工作方式。注意它只追踪 Claude 用编辑工具做的改动，Bash 命令改的文件不在其中——它不是 git 的替代品。

三个之外还有两个省窗口的小工具：/btw 问一个不想留在历史里的旁枝问题，答案不进入上下文；查资料的活交给 subagent，让它在自己的窗口里翻文件、只把结论带回来——这个 D4 展开。

How the context window gets filled up1/5
Used 20 / 100 tokens
system persona20 tok
The context window is the model's desk — a fixed size. The system persona goes on first, and it usually has to stay there the whole time.

给 Claude 一个可验证的检查：测试通过才算完成

今天最后一节，也是这五天里最重要的一个观念。搭档说「做完了」的时候，你怎么知道它真做完了？如果唯一的判断方式是你自己去看，那你就是它的测试套件，每一个错误都要等到你注意到才会被发现——你在场，它是生产力工具；你不在场，它是风险。

解法是给它一个能自己跑的检查：一套测试、一条构建命令、一个 lint、一个把输出和固定文件比对的脚本、一张对照设计稿的截图。有了这个检查，循环就闭合了：它做、它跑、它读结果、它改，直到检查通过。你从「验证的一环」退到「审核证据的人」——看它贴出来的测试输出，比自己重跑一遍快得多。

写提示词时的差别就一句话。「给 POST /todos 加校验」是没有检查的版本；「给 POST /todos 加校验，测试用例：空 title 返回 400、超长 title 返回 400、合法请求返回 201，实现后跑 pnpm test 直到全过」才是有检查的版本。同样的道理放进 CLAUDE.md 就是那段「完成的判据」：哪条命令通过才算做完。

想让检查更「硬」一点，还有三个阶梯：把它写进 /goal，一个独立的评估器会在每一轮之后重新核对，直到目标达成；写成一条 Stop hook，测试不过就不允许这一轮结束——这是确定性的门禁，D4 的主题；或者让另一个 subagent 用全新的上下文来复核结论，做的人和判的人不是同一个——D5 的对抗式审查。今天先把「有检查」这件事做到，剩下的三天都是在把这个检查越做越硬。

还有一个反直觉的提醒：要让它展示证据而不是宣布成功——贴测试输出、贴跑过的命令和返回值、贴截图。你审的是证据，不是它的自信。

源码导读

动手实验

🧪 D3 实验：给自己的项目写的第一份 CLAUDE.md（Markdown）

Code location: labs/claude-mastery/day-03-first-claude-md

验收标准：

  1. CLAUDE.md 不超过 60 行，四段齐全：命令、风格、规矩、完成的判据。
  2. 逐行自检「删掉会不会让 Claude 犯错」，每一行都能说出「会犯什么错」；说不出的已经删掉。
  3. 全文没有「写干净的代码」「遵循最佳实践」这类模型本来就会做的话，也没有 package.json 里能直接看到的脚本说明。
  4. 在项目里跑 /context，Memory files 列表里能看到这份 CLAUDE.md。
  5. 用示例任务在 Plan Mode 下跑一遍，Claude 的计划里体现了 CLAUDE.md 写的至少两条规矩（比如用了你指定的测试命令、没动你禁止的目录）。

这是一个文档型实验，产出是一份 CLAUDE.md。最好用你自己正在写的项目做——课程的 TODO API 只是范例；没有合适的项目就用 D4 实验目录里那个演示用的 TODO API。starter/ 里的模板留了空位并附了提示问句，solution/ 是给 TODO API 写好的示范，以及一份「删掉了什么、为什么」的对照记录。

  1. 装好 Claude Code，进到项目目录跑 claude，先问三个「新同事会问的问题」，看它怎么自己翻文件回答。
  2. 跑 /init 生成初稿，通读一遍，用 starter 里的自检表逐行标注「留 / 删 / 改」。
  3. 按四段结构重写：命令、风格、规矩、完成的判据；写完数行数，超过 60 行继续删。
  4. 跑 /context 确认 Memory files 里有它；切到 Plan Mode，用示例任务的提示词让 Claude 出一份计划。
  5. 对照计划检查 CLAUDE.md 的规矩是否被遵守；没被遵守的那条，先怀疑写得含糊或文件太长，改完再试一次。

面试题

今天 3 道题在下方题库区，侧重 CLAUDE.md 与 skill 的分工、上下文窗口为什么要主动管、可验证检查为什么是分水岭。展开后先看「分析过程」再看要点——照着推导练，比背要点管用。标注「国内高频 / 海外高频」方便按目标市场取舍。

检查清单与明日预告

  • 能装好 Claude Code 并说清 CLAUDE.md 该写什么、不该写什么
  • 能用 Plan Mode 走完「探索、计划、实现」并切换合适的权限模式
  • 能在会话里用 /clear /compact /rewind 管理上下文，并给 Claude 一个可验证的检查
  • 能说出五种常见失败模式里的至少三种，以及各自的解法
  • 实验的 5 条验收标准全部通过
  • 3 道面试题不看要点也能答出至少 2 道

明天（D4）我们回答今天留下的一个问题：CLAUDE.md 说「提交前要跑测试」，Claude 大多数时候会听，但「大多数」不是「一定」。要把「一定」做出来，得用 hooks——它是门禁，不是建议。同时你会学会用 skill 装可复用的流程、用 subagent 把查资料的活派出去、把别人做好的 MCP server 和 CLI 工具接进来。先学会给搭档写手册，再学会给它装门禁，是因为你得先知道哪些规则它「有时不听」，才知道哪些值得做成硬约束。

Interview questions

  • How do CLAUDE.md and skills divide responsibilities, what goes where, and what goes wrong when CLAUDE.md grows to 500 lines?CLAUDE.md 和 skill 的分工是什么？什么内容该放哪边？一份 CLAUDE.md 写到 500 行会出什么问题？
    Common in ChinaCommon overseasBasic#claude-md#skills#context

    How to reason about it · think before answering

    1. This tests context-cost awareness. 'CLAUDE.md holds rules, skills hold procedures' is the conclusion; derive it from how each is loaded.
    2. Start from load timing: CLAUDE.md enters context in full every session — a fixed cost; a skill keeps only its one-line description resident and loads its body on invocation — a variable cost. Hence short facts that always apply go in CLAUDE.md, occasional multi-step procedures go in skills.
    3. Give the table: commands, non-default style, repo etiquette, environment quirks, and the definition of done belong in CLAUDE.md; deployment runbooks, issue-fixing steps, document generators belong in skills. Multi-step procedures in CLAUDE.md or always-on rules inside a skill are both misplacements.
    4. At 500 lines the failure is dilution, not capacity: important rules drown, adherence drops, and every turn pays for the bloat. Fixes: prune ruthlessly (would removing this cause a mistake?), move occasional content to skills, split path-scoped rules into .claude/rules/ so they load only when matching files are touched.
    5. Follow-ups: a rule that keeps being ignored — prune, then disambiguate, then emphasize; anything that must run every time should be a hook, not a sentence.

    分析过程 · 先想清楚再作答

    1. 这题考的是「上下文成本意识」。答成「CLAUDE.md 放规则、skill 放流程」只是结论，面试官想听你从加载方式推出这个结论。
    2. 拆法从加载时机入手：CLAUDE.md 每次会话整份进入上下文，是固定成本；skill 只有描述那一行常驻，正文在被触发（模型判断相关或用户输入 /name）时才加载，是按需成本。所以「每次都成立的短事实」放 CLAUDE.md，「偶尔才用、一用就是多步」的流程放 skill。
    3. 给判据表：命令、风格差异、仓库礼仪、环境怪癖、完成的判据进 CLAUDE.md；部署流程、修 issue 的固定步骤、某类文档的生成方法进 skill。反过来，CLAUDE.md 里出现了多步流程，或 skill 里放了「每次都要遵守」的规则，都是放错了。
    4. 500 行的问题不是「太长跑不动」，而是稀释：重要规则被淹没，模型的遵守度反而下降，还白白吃掉每轮的窗口。对策是「删到不能再删」（删掉会不会让它犯错？不会就删）、把偶尔用的挪进 skill、按路径拆进 .claude/rules/ 只在碰到匹配文件时加载。
    5. 可预期的追问：「规则它老是不听怎么办」——先删再改再强调；「必须每次执行」的动作根本不该靠 CLAUDE.md，要改成 hook。

    Key points

    • CLAUDE.md loads in full every session — fixed cost; a skill keeps one line resident and loads on demand
    • CLAUDE.md: short always-true facts — commands, style deltas, etiquette, definition of done; skills: occasional multi-step procedures
    • Bloat dilutes: key rules drown, adherence drops, every turn pays
    • Fixes: prune, move occasional content to skills, split path-scoped rules; must-run actions become hooks

    答题要点

    • CLAUDE.md 每次会话整份加载，是固定成本；skill 只常驻一行描述，正文按需加载
    • CLAUDE.md 放每次都成立的短事实：命令、风格差异、规矩、完成判据；skill 放偶尔用的多步流程
    • 写长的后果是稀释：重要规则被淹没、遵守度下降、每轮白付窗口
    • 对策：删到不能再删、偶尔用的进 skill、按路径拆进 rules；必须每次做的改成 hook
  • Why does the context window need active management in Claude Code, and when do you use /clear, /compact, and /rewind respectively?在 Claude Code 里为什么上下文窗口需要主动管理？/clear、/compact、/rewind 分别在什么时候用？
    Common in ChinaCommon overseasIntermediate#context-window#claude-code

    How to reason about it · think before answering

    1. The keyword is active. Waiting for auto-compaction works, but the interviewer wants to hear that performance degrades before the window is full.
    2. Why: every file read, command output, and turn lands in one window; a single debugging pass can be tens of thousands of tokens; as it fills the model forgets earlier instructions and errs more, so the discipline is controlling what enters from the start.
    3. Then the three commands, keyed on whether the history is still useful: switching tasks with useless history — /clear; mid-task with useful history but a filling window — /compact, optionally with instructions on what to keep; wrong direction — /rewind (Esc Esc) to restore conversation or code to a checkpoint, or summarize just one span.
    4. Two rules of thumb: after two failed corrections, /clear and rewrite the prompt — failed attempts keep polluting; use /btw for side questions that shouldn't enter history; delegate research to a subagent with its own window.
    5. Follow-ups: when should context accumulate? While deep in one problem where history is still referenced. Limits of rewind: it tracks only edits made through Claude's editing tools, not Bash-driven changes, and is no substitute for git.

    分析过程 · 先想清楚再作答

    1. 题眼是「主动」。被动等自动压缩也能用，面试官想知道你是否理解「窗口填满之前性能就已经在下降」。
    2. 先说为什么：Claude Code 读的每个文件、跑的每条命令输出、每轮对话都进同一个窗口，一次调试就是几万 token；窗口越满模型越容易忘掉早先的指令、越容易出错，所以不是满了才处理，而是从一开始就控制进什么。
    3. 再分三个命令，判据是「这段历史还有没有用」：任务切换且历史无用——/clear 清零；任务未完但窗口快满、历史有用——/compact 压缩成摘要，可带指令指定保留什么；走错了方向、想回到某个点——/rewind（Esc Esc）恢复对话或代码到检查点，也能只对某一段做摘要。
    4. 补两条经验规则：同一问题纠正两次还不对就 /clear 重开，失败的尝试留在窗口里只会继续污染；旁枝问题用 /btw，答案不进历史；查资料派给 subagent，让它在自己的窗口里翻。
    5. 可预期的追问：什么时候应该让上下文积累？深挖一个复杂问题、历史仍在被引用时；判据是下一步还会不会用到这段历史。再追问 rewind 的边界：只追踪 Claude 用编辑工具做的改动，Bash 改的文件不在其中，不替代 git。

    Key points

    • Every read, output, and turn shares one window; fullness degrades adherence, so control inputs from the start
    • /clear between unrelated tasks or after two failed corrections
    • /compact mid-task when history matters but space runs low; pass instructions on what to keep
    • /rewind to a checkpoint for conversation or code, or summarize a span; not a git replacement

    答题要点

    • 所有文件读取、命令输出、对话都进同一窗口；越满越容易忘指令、出错，要从一开始控制
    • /clear：切换任务、历史无用时清零；两次纠正无效也清
    • /compact：任务未完、历史有用但窗口快满；可带指令指定保留内容
    • /rewind：回到检查点恢复对话或代码，或只对一段做摘要；不替代 git
  • Why is 'give Claude a check it can run' the dividing line for using agents well, and what levels of enforcement can that check have?为什么说「给 Claude 一个可验证的检查」是用好 Agent 的分水岭？检查可以有哪几档硬度？
    Common in ChinaCommon overseasIntermediate#verification#agent-loop

    How to reason about it · think before answering

    1. This tests understanding of the agent loop. 'Tests matter' is common sense; explain where the loop closes without a check.
    2. Chain: an agent works in a do–observe–adjust loop and stops on 'looks done'. Without a runnable check, 'looks done' is the only signal and the verification step falls on you — every mistake waits to be noticed; present, it is a tool, absent, it is a risk. With a check (tests, build exit code, lint, diff-against-fixture, screenshot compare) the loop closes inside the machine: it works, runs, reads, and iterates to green while you review evidence.
    3. Four levels: in the prompt ('run the tests until they pass') — usable today; as a /goal — an independent evaluator re-checks every turn; as a Stop hook — the turn cannot end until the check passes, deterministic; as a reviewer subagent — the one who did the work is not the one grading it. Each step trades setup for attention.
    4. Production nuance: demand evidence, not claims — test output, commands and return values, screenshots; reviewing evidence beats re-running.
    5. Follow-up: can the check itself be gamed? Yes — the model might edit tests to pass. Counter with a deny rule on the test directory or a reviewer specifically checking for test tampering.

    分析过程 · 先想清楚再作答

    1. 这题考对 Agent 循环的理解。答成「测试很重要」是常识；要说清没有检查时循环在谁那里闭合。
    2. 推导：Agent 在「做、看结果、改」的循环里工作，停下来的信号是「看起来做完了」。没有可运行的检查，「看起来做完了」是唯一信号，验证环落在人身上——每个错误都要等你注意到，你在场它是工具，你不在场它是风险。有了检查（测试、构建退出码、lint、比对脚本、截图对照），循环在机器里闭合：它做、它跑、它读结果、它改到通过，你只审证据。
    3. 硬度分四档：写进提示词（「实现后跑 pnpm test 直到全过」）——今天就能用；设为 /goal——独立评估器每轮复核直到达成；写成 Stop hook——测试不过不允许结束，确定性门禁；交给另一个 subagent 复核——做的人和判的人分开。每升一档多一点配置，换来少一点盯着。
    4. 生产视角：要求展示证据而不是宣布成功——贴测试输出、贴命令与返回值、贴截图；审证据比自己重跑快。
    5. 可预期的追问：检查本身会不会被绕过？会——模型可能改测试让它过。对策是把测试目录放进禁改清单，或让 reviewer subagent 专门核对「有没有为了过而改测试」。

    Key points

    • Without a check the loop closes on you; with one it closes inside the machine
    • A check is anything with a pass/fail signal: tests, build, lint, fixture diff, screenshot compare
    • Four levels: prompt instruction, /goal re-evaluation, Stop hook gate, independent reviewer subagent
    • Demand evidence over claims; guard against test tampering with deny rules or a dedicated reviewer

    答题要点

    • 没有检查时循环在人身上闭合，每个错误都等你发现；有检查时循环在机器里闭合
    • 检查可以是测试、构建、lint、比对脚本、截图对照，任何能产生通过/失败信号的东西
    • 四档硬度：提示词里要求、/goal 每轮复核、Stop hook 确定性门禁、subagent 独立复核
    • 要证据不要宣言；防止改测试作弊要靠禁改清单或专门的复核

Comments

Sign in to join the discussion

No comments yet — be the first.