模型是支点，
harness 才是杠杆
Claude Code 把 agent 主循环替你写好了，循环之外那一圈得你自己搭。同一个 Claude，这一圈搭得好不好，决定它是只能改几行的工具，还是能扛 70 万行遗留系统的开发者。
同一个模型，
环境决定它的上限
把 Claude 当一名新入职开发者认真接入，原本搁置的工作会重新推进；而模型本身的能力又确实是天花板。两面合起来：harness 是可调的杠杆，模型是固定的支点。支点换不了，能动手的只有杠杆。
一条贯穿全文的纪律：harness 会随时间失效。模型一升级，此前搭的脚手架可能反成负担。所以下文每介绍一层，都要同时想它的退役时机，这点留到结语。
这篇只讲「配 Claude Code」
Claude Code 提供的是 Anthropic 已实现好的主循环，无需自己编写 agent 主循环。本文只讨论一件事：这个现成框架该怎么配。三类东西不要混：①模型给的（改不了，第〇层）、②你配的（本文主体）、③你从零建的（不在本文范围）。
底座选型、上下文管理、知识与工具的搭建顺序、用 subagent 与 Workflow 编排、把验证独立出来。全是在 Claude Code 里只配不建的东西。
另有 ①模型能力：给定项，改不了只能绕，是 harness 的地基（第〇层）。
prompt caching 设计规则、MCP server 实现、面向 agent 的命令行、单 loop 与多 agent 架构取舍、把产物改造成可验证接口。这些是用 API/SDK 从零搭 agent 才会碰到的。
遇到此类内容本文只点到为止、标明「不在本文范围」，不展开。
五层，自下而上盖
第〇层：你绕不开的地基
这层不是搭出来的，是给定的。但要先认清它，因为它决定了 harness 能精简到什么程度。
窗口是 100 万 token（系统提示词 + 完整对话 + 所有工具输出 + 已读文件），但窗口大不等于可以随意填。
实用 tip：给状态栏装个 context 进度条。不用反复敲 /context 打断手感，剩多少窗口一眼可见：
/compact 或开 subagent，不用再敲 /context 打断手感。当前最强的编码模型是 Opus 5，2026 年 7 月 24 日发布，也是 Claude Max 的默认模型。但型号会继续更新，比版本号更重要的，仍是几条不会随换代失效的原则。
high，高要求编码适合使用 xhigh。在 Claude Code 里，所有支持 effort 的模型都默认使用 high，唯一例外是 Opus 4.7，它默认使用 xhigh。Opus 5 的五档设置齐全，官方建议先从 high 起步，再按照自家评测向两个方向调整。只要评测显示质量没有下降，就该优先用 low 和 medium，官方把它们定位成控制 token 成本与响应时间的主要开关；高要求的编码与 agentic 工作则适合调到 xhigh。max 只适合确实值得无约束消耗 token 的任务，因为它仍有收益递减和容易过度思考的问题。从上一代沿用的设置也不能直接照搬，官方要求在自家评测上重新跑一次 effort 扫描。（Claude Code 在 Opus 4.7 那代把默认 effort 设为 xhigh，到 Opus 4.8 又回调为 high，这次来回本身就是下面 C 点的例子。）| 这一代变了什么 | 具体 | 你要做的 |
|---|---|---|
| 默认 effort 变了 | 4.7 时 Claude Code 默认 xhigh，4.8 改回 high | 编码手动设回 xhigh |
| 长上下文检索回退（4.7 那代） | 多针检索 MRCR：256k 91.9%→59.2%、1M 78.3%→32.2%；连带重度联网研究 BrowseComp 约 −4.4pp | RAG / 长文 / 纯联网调研，升级前按场景 A/B，别只看版本号 |
4.8 这一代幻觉显著下降，直接改变你要在验证上花多少力气。同一套 fact-check 流程核 11 篇报告（独立 subagent 在干净上下文逐条比对原文、有问题就改、换新 subagent 复核到零问题），切到 Opus 4.8 那天是一道清晰的分水岭：
但别误读成「4.8 之后不用验证了」。变薄的是返工次数，不是验证本身。生成不等于评估、由独立 agent 验收而非执行者自评，这套分工制衡删不掉（详见第四层）。
prompt caching 是一层「不可见但花钱」的机制：前缀逐字节匹配，任何位置变一字节、其后缓存全失效。cache miss 让每轮全价重算、成本翻倍，进而把订阅计划的 rate limit 砍半，命中率直接决定 Pro/Max 给你多少配额。顺着它来即可：
caching 另有 5 条面向「从零搭 agent」的设计准则（tools 不中途增删、defer_loading、不跨模型、消息传递更新而非改 system prompt、compaction 伪装成父对话延续），不在本文范围，不展开。
上下文：你唯一真正在管的资源
loop 是现成的，你管的是输入什么、何时清。几乎所有使用差异都源于对窗口的管理。Claude 每完成一步，你都站在一个分支点上，5 个选择，4 个是为了管上下文质量：
compaction 是有损压缩：接近上限时把整段对话总结成摘要，模型在全新窗口里基于摘要继续。问题出在自动触发的时机，它恰好落在模型最弱的时刻：
场景：读了 5 个文件、试方案 A 失败、要换 B。
失败连同纠正都留着
「那个不行，试试 B」，失败的方案 + 你的纠正全留在上下文里，继续增加噪音、干扰判断。
回到岔路口，干净换路
退到「读完 5 文件、还没试 A」的点，再说「别用 A，foo 没暴露那接口，直接用 B」。留下文件读取，丢掉失败尝试。
配套 "Summarize from here"：让 Claude 把所学写成一条交接消息，相当于未来的 Claude 给过去的自己写信（「我试了 A，因……行不通」），避免后续会话重蹈覆辙。
/compact 与 /clear 都清上下文，区别在谁决定保留什么：
| 维度 | /compact | /clear |
|---|---|---|
| 工作量 | 低，Claude 自动总结 | 高，你手动提炼 |
| 控制精度 | Claude 决定保留什么 | 你决定携带什么 |
| Context Rot | 部分缓解 | 完全消除 |
| 适用 | 任务中途清冗余 | 开始全新任务 |
| 场景 | 推荐 | 原因 |
|---|---|---|
| 同任务，上下文仍相关 | Continue | 窗口内容都还在起作用 |
| Claude 走错了路 | Rewind | 留文件读取、丢失败尝试 |
| 会话堆满过时调试信息 | /compact + 指令 | 省力，你引导方向 |
| 开始全新任务 | /clear | 零 rot，你完全控制 |
| 下一步大量只需结论的输出 | Subagent | 中间噪音留子上下文 |
新任务 = 新会话。关联任务权衡：高度相关就继续（省去重读），否则 /clear。subagent 的心智测试，「我要的是工具输出本身，还是只要结论？」只需结论就派出去，更多用法见第三层。
知识与工具：7 层施工图
这层是全文核心框架。一个常被忽略的前提：harness 的重要性等于甚至超过模型本身。先说底层机制，Claude 找代码用的是 agentic search，不是 RAG：
| 维度 | RAG 工具 | Claude Code · agentic search |
|---|---|---|
| 索引维护 | 需 embedding pipeline | 不需要 |
| 时效性 | 滞后（小时/天/周） | 实时操作 live codebase |
| 失败模式 | 返回已删/改名的函数，无提示 | 无此问题 |
| 扩展性 | 数千人并发提交时跟不上 | 每个实例独立运行 |
代价：它需要足够起始上下文知道「从哪开始找」，导航质量取决于 setup 质量。结论:投入 codebase setup 的团队拿到更好的结果。
| 层 | 最常见的错误用法 |
|---|---|
| L1 CLAUDE.md | 塞可复用专业知识（该进 skill） |
| L2 Hooks | 用 prompt 实现本该自动跑的 |
| L3 Skills | 全塞 CLAUDE.md |
| L4 Plugins | 让好配置停在个人手里 |
| L5 LSP | 以为是自动的（要装 plugin 加 language server） |
| L6 MCP | 基础没搞好就先建 |
| L7 Subagents | 同一 session 同时探索与编辑 |
permissions.deny 提交进版本控制、全团队共享。很多人以为 Skill 就是一个 SKILL.md。其实它是一个文件夹，SKILL.md 只是入口，旁边还能挂脚本、参考资料、模板、甚至自己的 hooks，这正是它比一段提示词强的地方。
SKILL.md 给方法，scripts/ 给手脚，references/ 按需加载省上下文。机制上，每个 skill 的名字和描述是挂在系统提示里的，这正是它们能当触发开关的原因：Claude 扫一遍这些条目、决定用哪个，就发一次普通的 Bash 调用把对应的 SKILL.md cat 出来读进上下文，正文这才进来；里面引用的 references/api.md 之类，同样等真用到了才再 cat 一次。整条加载链都是 Claude 用通用工具按需拉取，不是框架预先塞好。
官方把 Skills 的常见用途归成九类，从查文档一路覆盖到运维：
来自 Anthropic 内部上百个 Skills 的九条最佳实践：
把 skill 写对
- 不讲废话：聚焦能把 Claude 推出默认思维的信息（例：叮嘱避免 Inter 字体和紫色渐变）
- 建 Gotchas 章节：最值钱的内容，逐条记录失败点并持续更新
- 文件系统做渐进式揭露：细节拆进
references/api.md，要用才读 - 避免过度约束，极重要领域除外；Description 是触发条件，不是摘要
让 skill 持久好用
- 存脚本让 Claude 组合，而非重建重复模板
- 按需 Hooks：
/careful拦rm -rf、DROP TABLE - 持久化用
CLAUDE_PLUGIN_DATA（skill 目录升级会被删） - 用户配置用
config.json，没设就让 agent 用 AskUserQuestion 问
分享：小团队签入 .claude/skills，规模化走 plugin marketplace（需筛选避免烂 skill）。用 PreToolUse hook 记调用量看哪些受欢迎。一条经验：好 skill 多从几行字开始、随踩坑完善。
MCP 把外部数据源和系统接入会话。本文只讲怎么接进来用，怎么设计一个 MCP server 不在本文范围。接入侧有两个降本开关，都是客户端能力，不是 server 设计：
MCP 与 Skills 互补：MCP 给工具和数据，Skills 给操作知识，最强的 agent 两者兼用。（MCP server 五大设计模式不在本文范围。）
早在 2024 年末，Claude 3.5 Sonnet 仅用 Bash 和 Text Editor 两个通用工具就拿下 49% 的 SWE-bench Verified，当时的 SOTA。Claude Code 的架构基础至今仍是这两个通用工具，Skills、Memory 都是它们的组合。
2.2 给的是施工顺序，回答「按什么次序把哪些能力搭起来」。这里换一个正交的视角：当手里已经有一条具体指令，它该放进哪种载体？官方把可用载体归为七种，区分它们的不是功能，而是四个轴：何时加载、压缩后是否还在、上下文成本、强制力。前面几节没单独提过的有三件，最要紧的是一个独立的约束载体 Rules（放在 .claude/rules/，加一个 paths: 字段限定作用域，只在 Claude 读到匹配路径的文件时才加载）。它和 CLAUDE.md 的分工是：不加路径范围就等同写进 root CLAUDE.md、全程常驻照样烧 token，价值全在 paths 上；某个目录的约定用嵌套 CLAUDE.md，散落在多个目录的跨切面硬约束（如「所有 handler 先校验输入」）用 path-scoped rule 更贴。
--- paths: - "src/api/**" - "**/*.handler.ts" --- All API handlers must validate input with Zod before processing.
src/api/** → 在只改文档的会话里它完全不进入上下文，只有 Claude 读到匹配路径的文件时才加载。这就是 Rules 区别于 root CLAUDE.md 的全部价值所在。| 载体 | 何时加载 | 压缩后还在？ | 上下文成本 | 适合承载 |
|---|---|---|---|---|
| CLAUDE.md · 根 | 会话开始，全程常驻 | 在，会被重读 | 高，每行都占 | 构建命令、代码库特有的坑、团队约定 |
| CLAUDE.md · 子目录 | 读到该目录文件时 | 目录不再被碰就丢 | 低 | 某目录的局部约定 |
| Rules | 碰到匹配 paths 时 | 重新注入 | 中（不限范围则常驻） | 跨多目录的局部硬约束 |
| Skills | 名字常驻，正文调用时加载 | 按共享预算重注入，最旧先丢 | 低 | 过程性工作流 |
| Subagents | 名字常驻，正文仅被调用时 | 只有结论回主会话 | 主上下文近乎零 | 该隔离、只取结论的旁支 |
| Hooks | 生命周期事件触发 | 完全绕过压缩 | 低，配置在上下文外 | 必须确定性发生的动作 |
| Output styles | 会话开始，注入系统提示 | 永不压缩 | 高，且覆盖默认系统提示 | 角色级改变（慎用） |
| Append-system-prompt | CLI flag，仅本次调用 | 永不压缩 | 中，首次后缓存 | 语气、长度、格式偏好 |
绿色那列「压缩后还在？」是此前没系统讲过的轴：放进会被压缩丢掉的载体，长会话到后半程它可能就不在了。子目录 CLAUDE.md 在那个目录不再被碰时会丢，这点尤其容易踩。
真正决定哪些 CLAUDE.md 启动即加载的，是会话从哪个目录起：从 ~/.claude/ 到启动目录这条祖先链上的每个 CLAUDE.md / CLAUDE.local.md 都在开始时一起进上下文，只有启动目录以下的子目录才按需。在子目录里起会话，会把整条链的约定一并预载，这既是想要局部上下文时的用法，也是上下文悄悄变重的来源。
写进 CLAUDE.md、Rules、Skills 的都是指令，而指令是请求，不是保证。长会话、模糊情境、或读到一份带 prompt 注入的文件时，模型就可能漏掉。所以「绝不能发生」的事，删库、改生产、碰禁区，靠写一句「不要这样做」不够，只有 hook 和权限能做确定性拦截。
Hook 能在整条 agentic loop 上触发，从 SessionStart 到 SessionEnd 一路埋着事件；每轮工具调用都会重走 PreToolUse → 工具执行 → PostToolUse 这段循环。Hook 的配置活在主上下文之外，不随 compaction 被压缩；其中 PreToolUse 是唯一的确定性阻断闸门，hook 以 exit code 2 退出就能拦下这次调用。右侧虚线簇是离主干的旁路/异步事件，独立于主流程触发。
最后两种载体多数情况别碰。Output styles 会覆盖默认系统提示，把「你是软件工程助手」连同安全与验证习惯一起抹掉，除非设 keep-coding-instructions: true，想改风格先看内置的 Proactive / Explanatory / Learning。Append-system-prompt 只对本次调用生效、纯叠加不改角色，但指令堆越多遵从越差。
收尾给一张「症状 → 换载体」速查。前面的决策表是「给定载体看属性」，这张反过来：发现自己正在 CLAUDE.md 里写某类东西，往往就是该把它挪个地方的信号。
| 你正在 CLAUDE.md 里写… | 它其实该放 | 为什么 |
|---|---|---|
| 「每次 X 都要做 Y」（每次编辑后跑 prettier、完成时发 Slack） | settings.json 里的 hook | 模型「选择」去跑 formatter，和 formatter「自动」跑，是两回事；要它可靠发生就交给 harness，别指望模型每次都记得 |
| 一段三十行的操作流程（部署 runbook、发布或审查清单） | .claude/skills/ 里的 skill | CLAUDE.md 放「始终为真」的事实（构建命令、代码库特有的坑、团队约定）；流程正文只在被调用时加载，常驻只会白白消耗 token |
| 个人偏好（如「commit 一律用 semantic message」） | 用户级文件（~/.claude/ 或 CLAUDE.local.md） | 所有基于文件的载体都有一份用户级副本、跨 repo 全程加载；个人口味放用户级，项目级文件只留「团队共享但只对这个库成立」的约定 |
还有两种症状本节前面已讲过，不再展开：写「绝不能发生 X」要靠 hook 加权限、组织级靠 managed settings（见上面强制力那段）；一条只对 src/api/** 生效的约束不写 paths:，机制上就等于塞进了 CLAUDE.md（见 Rules 那段）。
2026 年 7 月 24 日，Anthropic 随 Claude Opus 5 发布了 Thariq Shihipar 撰写的官方博客。2.6 节埋下的 less is more 暗线，在这里被展开成一份明确、可执行的清单：面向 Opus 5 与 Fable 5，Anthropic 删掉了系统提示词中 80% 以上的内容，而自家编码评测没有出现可测量的下滑。作者把根因说得很直接：“Overall, we found that we were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills.” 问题不只是提示词太长，也在于旧指令彼此冲突。2.6 讲的是指令挤占推理空间的容量成本；这里则是模型动手前必须先消解矛盾，所以花掉的是注意力。
| 旧做法 | 新做法 | 变了什么 |
|---|---|---|
| 给规则 | 让模型判断 | 从禁写注释，改为匹配代码库自身的注释密度与惯例 |
| 给示例 | 设计接口 | 示例会锁定探索空间，参数与枚举应直接表达用法 |
| 全部前置 | 按需加载 | 渐进式揭露前文已讲，这里只补内建工具的延迟加载 |
| 重复提醒 | 简化工具描述 | 去重前文已讲，这里只补把用法收进工具描述 |
| 手动写入记忆 | 自动记忆 | 不再靠 # 热键写入，改由系统保存相关记忆 |
| 简单规格 | 丰富引用 | 代码、测试、现有实现或评分标准都可以承载规格 |
高亮的四行是本文此前没有的。另外两行的主体在 2.1、2.4、2.6、2.7 已经讲过，下面只补它们新增的部分。
渐进式揭露不只用于 skill，也用于工具。Claude Code 的部分工具采用 deferred loading，agent 必须先用 ToolSearch 找到完整定义才能调用，官方点名的例子是自家的 Task tools。所以系统可以挂载更多工具，而这些定义在实际用到之前不会占用上下文。2.5 节讲的是 MCP 客户端侧如何为外部接进来的工具降本，这里讲的则是 Claude Code 内建工具对同一机制的另一半。早期模型有时需要重复提醒，也更偏向听上下文末尾的指令，所以系统提示词会复述一遍工具说明；现在重复内容可以删掉，用法直接留在工具描述里。
记忆机制也变了：过去用 # 热键把内容写进 CLAUDE.md 充当记忆，现在 Claude 会自动保存与工作和用户相关的记忆。rich references 则有四种形态：artifacts 功能生成的 HTML artifact、一套详细的测试套件、另一个代码库里待移植的函数，以及一份 rubric（评分标准，借 dynamic workflows 拉起 verifier agent，去核对某个领域里什么算做得好，官方举的例子是什么算好的 API 设计）。作者给出的排序是代码优先于文字描述和图片：“For example, a HTML mockup of a design will generally produce better results than a description of the design or a screenshot.” 七种载体的分类来自另一篇官方文章《Steering Claude Code》，这次没有修改分类，只是把 references 这一类实践讲得更透。
官方也把这套检查做成了命令 claude doctor：在 Claude Code 里执行 /doctor，它会把 skills 和 CLAUDE.md 调回合适的体量。后文结语讲的删减动作，到这一代有了官方给的自动入口。
编排：计划该交给谁
问题变成：一个任务，让 Claude 自行逐回合承载整个计划，还是把计划交由他处持有。原则：小任务不拆分，大任务不让模型在上下文中独自记忆整个计划。
它是什么
- 三特性：全新起点（不继承历史）、并行、权限隔离（研究只读 / 实现可编辑）
- 可嵌套：subagent 还能再往下派 subagent，最多五层，这正是动态编排把一个任务摊到成百上千个 agent 的结构基础
- General-purpose：全工具，复杂多步
- Plan Agent：只读，研究加规划
- Explore Agent：只读，快速搜索
什么时候派出
- 研究密集（读几十个文件）
- 多个独立任务（并行）
- 需要全新视角（不继承假设/偏见）
- 提交前验证（独立检查）
- 流水线工作流（明确阶段/交接）
成熟度路径一句话：先对话，后自动化。先用自然语言，观察哪些反复出现，再固化：
.claude/agents/，description 写触发条件该用的姿势
- 先研究再实现（从摘要谈起，而非 20 个原始文件）
- 并行批量改（独立文件套同一模式）
- 独立代码审查（全新视角更客观）
- 流水线（设计/实现/测试，用文件交接）
别这么用
- 顺序依赖：单会话顺着做更干净
- 同文件编辑：并行改同一文件会冲突
- 小任务：委派有开销，直接做
- 专家 agent 过多：降低自动委派可靠性
- 需 agent 间协调：彼此不能通信，该用 Agent Teams
区分三者的不是规模，而是一个问题：那枚标着 PLAN 的方块在谁手里。Subagent/Skill 时由 Claude 逐回合持有、中间结果落进上下文；Workflow 让脚本持有，Claude 只看最终答案。
| Subagents | Skills | Workflows | |
|---|---|---|---|
| 谁决定下一步 | Claude，逐回合 | Claude，跟 prompt | 脚本 |
| 中间结果存哪 | Claude 的上下文 | Claude 的上下文 | 脚本变量 |
| 可复现什么 | worker 定义 | 指令 | 编排本身 |
| 规模 | 每回合几个 | 同 subagent | 每 run 几十到几百 |
| 中断时 | 重启该回合 | 重启该回合 | 同会话内可 resume |
Workflow 不是 Skill 的替代，两者正交：Skill 改变「模型知道什么」，Workflow 改变「如何确定性地编排」。一个 workflow 里 fan-out 的 agent 完全可以先挂 skill 再干活。
/workflows 选满意的 run，按 s 存成 command。收敛是退出条件而非固定轮数。触发：prompt 写 workflow / /effort ultracode / 跑已存 command；自带 /deep-research。可用性 Max/Team/API 默认开、Pro 需 /config、Enterprise 默认关。token 消耗远高于普通会话，先在小任务试手，大 run 前看 /model 把不需最强模型的阶段路由到小模型。
用 workflow 把 Bun 从 Zig 移到 Rust：约 75 万行、11 天、测试通过率 99.8%，四个串联 workflow（① 映射 Rust lifetime ② 逐文件翻译，数百 agent 并行、每文件两个 reviewer ③ 驱动 build/测试到双绿 ④ 夜间优化、每处单独 PR 等人审）。但前提极其特殊，不可理解为「任意迁移都能 11 天」：
- strangler-fig 渐进替换，不是推倒重建，Zig 与 Rust 全程链入同一 binary、按类逐个开关切换
- 每次切换都过 tests + shadow-diff + 不超过 2% 性能门禁，是验证驱动收敛而非「完成即信任」
- 极高既有测试覆盖（99.8% 的前提是套件够强）、单作者主导、尚未投入生产（99.8% 终究不是 100%）
正确读法：在有强测试与强验证门禁的高价值模块上，确定性脚本 + build/test 修复循环，能把按季度估的工程压到天级。先挑这样一块试点，而非照搬时间承诺。
默认 harness 把规划与执行挤在同一上下文，碰上长时间跑、大规模并行、对抗性任务就会塌，塌法有三种，这正是要把计划搬进脚本的原因：
偷懒
50 项审查做到 35 项就宣布「搞定」。
自我偏袒
评判自己刚做的东西时倾向回护。
目标漂移
多回合后忠实度流失，compaction 丢掉「别做 X」。
Workflow 从结构上治这三样：偷懒，脚本持有完整清单、循环不到末尾不算完；自我偏袒，验证交给另一个独立 agent；目标漂移，目标写在脚本里、不随 compaction 流失。
Classify-and-act
分类器判断任务属哪类，路由到不同 agent。给流水线装个分诊台。
Fan-out-and-synthesize
拆成多步各一 agent，合成是 barrier：唯一要等齐的。
Adversarial verification
每个干活 agent 配一个专门 agent 拿 rubric 对抗式验证，治自我偏袒。
Generate-and-filter
先发散一堆想法，按 rubric 筛、去重，只留最优几个。
Tournament
N 个 agent 各用不同打法做同题，两两比较直到分出胜者。
Loop until done
任务量未知时不设固定轮数，循环到停止条件成立。
成对比较（comparative judgment）比绝对打分更可靠，排序类任务尤其如此。
反直觉的是，它在非技术工作上常更有用。官方点名的九个用例，过半与写代码无关：
读取不可信公开内容的 agent 不得执行高权限动作，高权限动作交给另一批专责执行的 agent。读取与执行分离，这是防 prompt injection 的结构性手段。
什么时候别用：workflow 能在很多场景做出超常结果，但并非每个任务都需要、且烧多得多的 token。先问「这真需要更多算力吗」。多数传统编程任务并不需要一个五人评审团。窍门：详细 prompt 最关键；小任务可开 quick workflow；配 /loop /goal；写 use 10k tokens 封顶；按 s 存进 ~/.claude/workflows 或纳入 skill。把它当探索新用法的起点，不是终点。
验证：执行者不应评判自己的产出
代码编写成本已经很低，瓶颈后移到验证。核心一句：生成不等于评估，二者必须分离。让干活的 agent 评自己的产出，它几乎总自信地给好评，如同让开发者审自己的代码。一个工程现实：把独立 Evaluator 调严，比让 Generator 学会自我批评容易得多。
用独立 review subagent，或 Workflow 的对抗式验证 pattern，让验收与执行不是同一个、也不共享上下文。纯 Claude Code 用法，不写一行额外代码。
把产物改造成 agent 可读可验的接口（data-verify-* 契约、window.__verify API、.verify.ts）。核心论点是「经济学翻转」：agent 把验证的边际成本压到趋零，contract testing 才第一次在前端规模化可行。这是改造自有产品才会做的事。
70 万行遗留代码库的接入
把四层组合用在开篇提到的 Skyline 上。核心方法论：把 Claude 当新员工 onboard，像带实习生一样，解释足够背景让它完成一个有限项目，并为下一轮产出更好的 context。这是个五步闭环，每轮起点更高：
pwiz-ai，而非代码仓库，否则会被分支隔离，每个分支上的 Claude 成了「不同的人」。团队当正式工程产物维护、打版本。四条启示：scope 隔离是前提（大屎山不能一把梭，切片喂、逐步扩展）· debugging skill 必须硬约束（70 万行盲改一行可能连锁爆炸）· context 必须独立于代码分支 · MCP 打通测试基础设施。一个诚实的前提：这不是装上就能用的银弹，需要有人维护 context 层、渐进推进。但它在「最不适合 AI 的场景」里跑通了。
边搭边砍：harness 的半衰期
harness 不是一次搭就一劳永逸，它有半衰期。每个组件都编码了一个对模型能力的假设，而假设会过期。能删多少，取决于模型多强。
真实案例：Sonnet 4.5 近上限时会「上下文焦虑」提前结束任务，团队加了段 context reset 补偿；Opus 4.5 上线、这行为消失后，那段代码就成了纯负担。同理，一个为强制走 Perforce p4 edit 而拦截写文件的 hook,在原生支持后也变多余。正确心态不是「怎么让 Claude 更强」,而是「我能停止做什么」。
但有些东西删不掉。Planner 与 Evaluator 这类分工制衡保留了下来：没有 Planner，Generator 会 under-scope；没有 Evaluator，边界任务的 bug 会遗漏。可删减的(脚手架)与不可删减的(上下文纪律、分工验证)要分清。建议每 3 到 6 个月审计一次 harness，先跑 /doctor 检查 skills 和 CLAUDE.md 的体量。Anthropic 此轮删掉 80% 以上的系统提示词，可作为收缩幅度的参照，但不是固定指标。