Claude Code 子代理上线前 20 项质检清单与成本策略
用 5 个 Opus 子代理并行巡检上线前 20 项设计与体验问题并一次修复,附 Opus 5.5 成本与 effort 分级策略。
原始内容
Claude Code tip: before you ship a vibe-coded site, have Opus 5.5 send out 𝟱 𝘀𝘂𝗯𝗮𝗴𝗲𝗻𝘁𝘀 to check 𝘁𝗵𝗲𝘀𝗲 𝟮𝟬 𝘁𝗵𝗶𝗻𝗴𝘀, then fix them all in one pass: Consistent design → Write a DESIGN.md first, and make every color, font size, spacing and corner radius follow it → Keep the palette restrained and the type hierarchy clear → Make every button, card and input of the same kind look alike → Too flat? Add emphasis. Too crowded? Cut → Keep text readable on both dark and light backgrounds On mobile → No sideways scrolling, and nothing spilling off the screen → Add a mobile menu → Make buttons big enough to tap → Keep the layout intact when the text is enlarged Every state → Give loading, empty and error states a proper screen → Give every button feedback, with its own hover, pressed and disabled look → Show form errors right where they happen, plus submitting, success and failure messages → Add transitions to modals, dropdowns and tab switches Use it like a real user → Click through the core flows, like sign-up and checkout, from start to finish → Find buttons that do nothing and links that are broken → Make sure the whole thing works with just a keyboard Before launch → Say what you do in one line on the home page → Give each page one main button you want people to click → Give every page a title, a description and a favicon → Delete all placeholder text For effort, follow Anthropic's cost guide from yesterday: medium is for well-scoped daily work. The default medium is enough for these 20 fixes; raise it for the harder ones. Thariq tested it: turning effort up mostly buys more verification and edge-case testing. Send this whole post to Claude Code. If you need to, add this line at the end 👇 "Send one subagent per group to check it without editing anything. Then fix everything yourself from their lists, so no two agents edit the same file. If a group is more complex, raise that subagent's effort. Show me the list of issues first, don't change anything until I confirm, and when you're done, give me before-and-after screenshots."
Anthropic just published its 𝗳𝘂𝗹𝗹 𝗰𝗼𝘀𝘁 𝗴𝘂𝗶𝗱𝗲 for Opus 5.5. You can ask Opus 5.5 to use it to review your Claude Code setup. At the same effort level, Opus 5.5 thinks more per turn than Opus 5, most of all at xhigh and max. Thinking is billed as output, and an output token costs 𝟭𝟬𝟬 𝘁𝗶𝗺𝗲𝘀 𝗮 𝗰𝗮𝗰𝗵𝗲 𝗿𝗲𝗮𝗱. So don't carry over the level you set for Opus 5. Start at medium, and save xhigh and max for work where you've measured a gain. Send this prompt to Opus 5.5 👇 "Read this guide: https://t.co/8RHkfmiKjM Then review my Claude Code setup against it: my user and project settings, the subagents in ~/.claude/agents and .claude/agents, CLAUDE.md, and the MCP servers I have connected. Find three kinds of problems: 1. A default effort that doesn't fit the work. Use the guide's ladder: low for mechanical edits, medium for well-scoped daily work, high when medium stalls, and xhigh or max only for work where a gain was measured. Flag a default of xhigh or max, or a level I picked for Opus 5. Then look at this project's code and recent commits and tell me which kinds of work here fit which level. 2. Subagents that only search, read logs or run tests but set no model, so they run on my main model. 3. Setup that makes every turn cost more: MCP servers I don't use, or a CLAUDE.md well over 200 lines. For each issue, quote the setting or line, explain what it costs, and suggest the smallest change. Also tell me which three things to check in /usage at the end of a task. Show me the recommendations first. Don't change anything yet."
中文译文
机器翻译,保留原文供核对。
Claude Code 提示:在发布一个用 vibe coding 做出来的网站之前,让 Opus 5.5 派出 5 个子代理检查以下 20 件事,然后一次性全部修好: 一致的设计 → 先写一个 DESIGN.md,让每种颜色、字号、间距和圆角都遵循它 → 保持配色克制,层级清晰 → 让同类按钮、卡片和输入框看起来一致 → 太扁平?增加强调。太拥挤?删减 → 确保文字在深色和浅色背景上都清晰可读 移动端 → 不要横向滚动,也不要让内容溢出屏幕 → 添加移动端菜单 → 让按钮足够大,方便点击 → 放大文字时保持布局不变 各种状态 → 为加载、空和错误状态提供合适的界面 → 给每个按钮反馈,并让每个按钮都有自己的悬停、按下和禁用外观 → 在表单错误发生的位置就地显示错误,并显示提交中、成功和失败消息 → 为模态框、下拉菜单和标签页切换添加过渡动画 像真实用户一样使用 → 从头到尾点通核心流程,比如注册和结账 → 找出点了没反应的按钮和坏掉的链接 → 确保仅用键盘也能完整操作 发布前 → 在首页用一句话说明你是做什么的 → 给每个页面设置一个你希望人们点击的主要按钮 → 给每个页面一个标题、描述和 favicon → 删除所有占位文本 关于 effort,请遵循 Anthropic 昨天发布的成本指南:medium 适合范围明确的日常工作。默认的 medium 足以完成这 20 项修复;更难的项目再调高。Thariq 测试过:调高 effort 主要换来更多验证和边界情况测试。 把整篇帖子发给 Claude Code。如果需要,在末尾加上这一行 👇 “每组派一个子代理检查,不要编辑任何东西。然后你根据它们的清单自己修复所有问题,这样就不会有两个代理编辑同一个文件。如果某一组更复杂,就调高该子代理的 effort。先给我问题清单,在我确认前不要改任何东西;完成后,给我前后对比截图。”
Anthropic 刚发布了 Opus 5.5 的完整成本指南。你可以让 Opus 5.5 用它来审查你的 Claude Code 配置。 在相同 effort 级别下,Opus 5.5 每轮思考得比 Opus 5 更多,在 xhigh 和 max 下尤其明显。思考按输出计费,而一个输出 token 的成本是一次缓存读取的 100 倍。所以不要沿用你为 Opus 5 设置的级别。从 medium 开始,把 xhigh 和 max 留给你已实测有收益的工作。 把这段提示词发给 Opus 5.5 👇 “阅读这份指南:https://t.co/8RHkfmiKjM 然后对照它审查我的 Claude Code 配置:我的用户级和项目级设置、~/.claude/agents 和 .claude/agents 中的子代理、CLAUDE.md,以及我已连接的 MCP 服务器。找出三类问题: 1. 默认 effort 与工作不匹配。使用指南中的阶梯:low 用于机械性修改,medium 用于范围明确的日常工作,high 用于 medium 卡住时,xhigh 或 max 只用于已实测有收益的工作。标出默认设为 xhigh 或 max,或沿用了我为 Opus 5 所选级别的情况。然后查看本项目的代码和近期提交,告诉我这里哪些类型的工作适合哪个级别。 2. 只负责搜索、读日志或运行测试,但没有设置模型的子代理——它们会运行在我的主模型上。 3. 让每一轮都更贵的配置:我没有在用的 MCP 服务器,或远超 200 行的 CLAUDE.md。 对每个问题,引用相关设置或行,解释它的成本,并建议最小的改动。最后再告诉我任务结束时该在 /usage 里检查哪三件事。 先给我看建议。暂时不要改任何东西。”
深度解析
是什么:一条 Claude Code 实战技巧推文串:上线“氛围编码”出的网站前,让 Opus 5.5 派出 5 个子代理,按 20 项清单(视觉一致性、移动端、状态覆盖、真实用户走查、上线检查)分组只读巡检,再由主代理汇总清单、经确认后一次性修复,避免多代理改同一文件,并要求输出前后截图验收。
核心方法:把 QA 按领域拆成互不重叠的分组,用“读改分离”编排消除写冲突,是典型的多代理并行工程模式。被引用的成本线程与 claude.dev 官方文章给出理论支撑:任务成本由轮数、缓存读、输出 token 和模型共同决定;每轮会重发全部上下文,思考按输出计费,而输出价是缓存读的 100 倍,所以 effort 是最贵的旋钮。Opus 5.5 默认 medium 足以覆盖这 20 项修复,更高档位主要换来更多验证与边界测试。
设计维度:清单前四组实质是一份 UI/UX 质量标准——先写 DESIGN.md 约束颜色、字号、间距与圆角,统一同类组件,覆盖 loading/empty/error 与 hover/pressed/disabled 状态,保证无横向滚动、足够触控面积、文字放大后布局不破及全键盘可用。
边界与风险:清单偏表层质检,不能替代真实可用性测试;成本数字来自官方示例,需用 /usage 实测校准;先读后改的流程会拉长反馈周期,小改动未必划算。
精选追评与案例
补充了键盘焦点回归这一截图看不出的关键检查。
@Voxyz_ai For the keyboard check, open a modal, tab through every control, press Escape, then check focus returns to the opener. Before/after screenshots can look identical while keyboard users lose their place.
中文译文 · 机器翻译
对于键盘检查,打开一个模态框,用 Tab 键遍历每个控件,按 Escape,然后检查焦点是否回到打开它的元素上。前后截图可能看起来一模一样,但键盘用户会丢失位置。
指出“像真实用户一样使用”依赖浏览器驱动能力,避免假检查。
@Voxyz_ai The "use it like a real user" group only works if that subagent can actually drive a browser. Without one it reads the sign-up handler, decides the flow works, and reports it as checked.
中文译文 · 机器翻译
“像真实用户一样使用”这一组只有在那个子代理真的能驱动浏览器时才有效。没有浏览器时,它会读一遍注册处理逻辑,认定流程能跑通,然后报告说已检查。
补上原清单缺失的越权访问检查,属于重要安全边界。
@Voxyz_ai solid list, but 20 checks and not one asks who can see what. I'd trade one design check for: make a second account and try to open the first account's stuff. which of the 20 would you drop for it?
中文译文 · 机器翻译
清单很扎实,但 20 项检查里没有一项问谁能看到什么。我愿意用一项设计检查换这个:注册第二个账号,试着打开第一个账号的东西。你会为它删掉 20 项里的哪一项?
给出多宽度截图定位间距问题的可复用实操方法。
@Voxyz_ai the DESIGN.md check is huge. i’d also have one subagent run the site at 3 widths and dump only broken screenshots. caught a bunch of spacing bugs faster than reading the css.
中文译文 · 机器翻译
DESIGN.md 这项检查很重要。我还会让一个子代理用 3 种宽度运行网站,只导出坏掉的截图。这比读 CSS 更快地抓到一堆间距问题。
补充本地化表单测试,覆盖长文案与重音字符的保存。
@Voxyz_ai Test forms with a long translated label and a name with accents, then check the saved record. This adds a localization check to the visual pass: the field should stay usable and preserve what the person typed.
中文译文 · 机器翻译
用很长的翻译标签和带重音符号的姓名测试表单,然后检查保存下来的记录。这会给视觉检查加一层本地化检查:字段应保持可用,并保留用户输入的内容。