主题
逐条处理：每个项目、每个会话、每一条消息
这是案例档案，查档用，不必通读。 773 条逐条点评，适合"想复盘某次具体会话/某句话时来查"。 想学怎么用，别从这里开始——先看 学习路径 和 大佬操作手册，要看自己整体毛病看 改进清单。
配合 全部历史（按项目） 看。那一页是"你原样怎么说的"，这一页是把每一条都按四段式处理：
- ① 你这么说：还原你当时的意图 + 归类
- ② 为什么不好 / 模型为何理解差：这句话给模型造成了什么歧义或信息缺口
- 当时实际发生：从你这条 transcript 里挖出的真实工具调用（读了哪些文件、改了几次、跑了多少命令、第几轮才走对）——把"用前用后"从我的推测变成你真实付出的代价
- 大佬怎么用：同场景下 Anthropic 团队/官方最佳实践实际怎么做（全部引下方「依据库」逐字原文，绝不编造）
- 为什么这么用 · 道理与依据：为什么这样有效——落到模型/上下文的运行机制，并标注依据库代号
- ③ 该怎么说（我审过的、大佬会用的话术，写成可直接抄的句子/代码块）
- ④ 用前 vs 用后：基于上面的真实证据，换了说法能省掉哪几次空转
"实际发生 / 大佬怎么用 / 依据" 是这一版新增的三维（你要的"大佬怎么用、为什么、依据"）。会话 2 是做到极致的完整样板，七维全带；其余会话按此标准推进，纯操作类短句从简。
重复的放任句（「可以/继续」）也逐条写——但会指回它所在会话的"那句真正定方向的话"，让你看清这一句"可以"到底在放行什么。
进度： 全部完成。12 项目 / 104 会话 / 1046 条消息全部逐条处理（实质 773 条走完整七维 + 真实证据，由"干活→监督"团队产出、Linter 0 问题校验）。
全部完成 · 12 项目进度总表
点项目名进各自页（每页：项目→会话→每一条的七维点评 + 每会话/项目小结）。实质 A=完整七维；放行/操作 B=原话+实际发生+一句话；噪声 C=只列。
| 项目 | 会话 | 消息 | 实质A | 0调用空转 | 页面 |
|---|---|---|---|---|---|
| 一 · 清华前端 | 63 | 496 | 362 | 169（34%） | history-p1 |
| 二 · 科技专题（本项目） | 10 | 199 | 153 | 46 | history-p2 |
| 三 · GEO | 10 | 172 | 125 | 56（33%） | history-p3 |
| 四 · 山科 | 1 | 75 | 61 | 40（53%） | history-p4 |
| 五 · 山科学生端 | 6 | 40 | 33 | 8 | history-p5 |
| 六 · 丹小美 | 2 | 24 | 20 | 12 | history-p6 |
| 七 · 清华 | 2 | 17 | 11 | 6 | history-p7 |
| 八 · workspace | 4 | 11 | 4 | 10 | history-p8 |
| 九 · 三只熊组号 | 1 | 6 | 1 | 2 | history-p9 |
| 十 · 顶层 | 3 | 3 | 1 | 1 | history-p10 |
| 十一 · 清华前端(旧) | 1 | 2 | 0 | 2 | history-p11 |
| 十二 · 山科教师端 | 1 | 1 | 1 | 0 | history-p12 |
| 合计 | 104 | 1046 | 773 | 352（33.7%） | — |
跨项目结论（全部基于真实统计，非估算）
把你全部 1046 条手写消息 / 10,278 次真实工具调用汇总，三个铁一般的事实：
- 每 3 条消息就有 1 条是"0 调用空转"——352 条（33.7%）。这些话发出后模型没做任何操作，多是"可以/完成了吗/确定吗"这类（放行类 185 + 追问类 65）。山科项目最极端：75 条里 40 条空转（53%）。
- 改法：放行给"可验证目标让它自停"、追问换"给我可核对的证据/清单"（依据库 验证-1/2/3）。
- 你的纪律在"做"，浪费在"说"：10,278 次调用说明你让模型干了大量实活（TDD、自验证、根因优先都在）；拖慢你的不是能力，是交互信息密度低——形容词、拆条发送、晚纠偏。
- 一句话能放行巨量操作而你看不见：样板会话 2 里一句"我同意"驱动了 151 次调用 / 改 16 文件。大改前先要"改哪些文件"清单或走 plan mode（依据库 计划-1/2）。
详细的类型分布与改进建议见 深度复盘（按类型） 与 我的改进清单；本页下方是项目一会话 1–4 的手工精修样板（七维做到极致的范例），完整 63 会话见 history-p1。
处理标准（定稿 · 以会话 2 为样板）
后面每个会话、每一条都按这个固定格式，会话 2 是做到极致的样板，照它的颗粒度走：
| 维度 | 写什么 | 硬要求 |
|---|---|---|
| ① 你这么说 | 一句话还原你当时的真实意图 + 归类（放任/排错/审查/需求/设计/操作） | 必须引你逐字原话 |
| ② 为什么不好 / 模型为何理解差 | 这句给模型造成的具体歧义或信息缺口；好的地方也照实夸 | 说清"模型会怎么误解"，不空泛 |
| 当时实际发生 | 从该 transcript 挖的真实工具调用数 + 文件名 + 第几轮才走对 | 必须真实可追溯，禁止编造数字 |
| 大佬怎么用 | 同样场景下，Anthropic 团队/官方最佳实践实际怎么做 | 必须引「依据库」里的逐字原文，禁止编造"大佬这么用" |
| 为什么这么用 · 道理与依据 | 为什么这样有效——落到模型/上下文的运行机制+ 对应「依据库」代号 | 解释清原理，不止"因为官方说" |
| ③ 该怎么说 | 我审核过的、大佬会用的可直接抄的话术/代码块 | 必须是验证过的话术，给到能复制粘贴的程度 |
| ④ 用前 vs 用后 | 基于"实际发生"的真实证据，换说法能省掉哪几次空转/调用 | 用前用后都要落到具体数字/行为 |
每个会话末尾一条 本会话小结（有证据）：用真实调用数总结"这会话多少次是可避免的空转、根因是哪 1–2 句话"。
判定一句话好坏的最硬标准（本页通用）：看它驱动了多少 真实操作、其中多少是有效推进vs 空转/改错层。0 调用的反问（"你确定吗""完成了吗"）= 纯空转；放行巨改的"可以/同意"= 高风险盲盒；带真实输出/文件锚点/验收清单的话 = 高效驱动。
依据库（官方原文 · 每条点评的"大佬怎么用 / 依据"都引这里）
下面每条点评里的 大佬怎么用和 依据，都对应这张表里的官方原文，不是我编的。出处：[BP]
code.claude.com/docs/en/best-practices；[团队]claude.com/blog/how-anthropic-teams-use-claude-code；[CW]code.claude.com/docs/en/common-workflows；[子代理]code.claude.com/docs/en/sub-agents。想要成体系地快速学大佬用法（端到端范例 + blade-auth 实战 + 习惯速查），见 大佬操作手册。
| 代号 | 官方/大佬原文（逐字） | 出处 |
|---|---|---|
| 验证-1 | "Give Claude a check it can run: tests, a build, a screenshot to compare. It's the difference between a session you watch and one you walk away from." | [BP] |
| 验证-2 | "Claude stops when the work looks done. Without a check it can run, 'looks done' is the only signal available, and you become the verification loop." | [BP] |
| 验证-3 | "Have Claude show evidence rather than asserting success: the test output, the command it ran and what it returned, or a screenshot." | [BP] |
| 验证-4（反模式） | "The trust-then-verify gap... Fix: Always provide verification (tests, scripts, screenshots). If you can't verify it, don't ship it." | [BP] |
| 计划-1 | "Letting Claude jump straight to coding can produce code that solves the wrong problem. Use plan mode to separate exploration from execution." | [BP] |
| 计划-2 | "Planning is most useful when you're uncertain about the approach, when the change modifies multiple files, or when you're unfamiliar with the code being modified. If you could describe the diff in one sentence, skip the plan." | [BP] |
| 具体-1 | "Claude can infer intent, but it can't read your mind. Reference specific files, mention constraints, and point to example patterns." | [BP] |
| 具体-2 | "The more precise your instructions, the fewer corrections you'll need." | [BP] |
| 具体-3（@文件） | "Reference files with @ instead of describing where code lives. Claude reads the file before responding." | [BP] |
| 症状-1（报 bug 模板） | 反例 "fix the login bug" → 正例 "users report that login fails after session timeout. check the auth flow in src/auth/... write a failing test that reproduces the issue, then fix it" | [BP] |
| 纠偏-1 | "Correct Claude as soon as you notice it going off track. The best results come from tight feedback loops." | [BP] |
| 纠偏-2 | "If you've corrected Claude more than twice on the same issue... Run /clear and start fresh with a more specific prompt." | [BP] |
| 上下文-1 | "Most best practices are based on one constraint: Claude's context window fills up fast, and performance degrades as it fills." | [BP] |
| 上下文-2（无边界探索） | "The infinite exploration. You ask Claude to 'investigate' something without scoping it. Claude reads hundreds of files, filling the context. Fix: Scope investigations narrowly or use subagents." | [BP] |
| 规则-1（CLAUDE.md） | "CLAUDE.md is a special file that Claude reads at the start of every conversation... only include things that apply broadly." | [BP] |
| 采访-1（大需求先成 SPEC） | "For larger features, have Claude interview you first... using the AskUserQuestion tool... write a complete spec to SPEC.md." | [BP] |
| 视觉-1 | "Verify UI changes visually: '[paste screenshot] implement this design. take a screenshot of the result and compare it to the original. list differences and fix them.'" | [BP] |
| 团队-设计 | Product Design 团队："feed Figma design files to Claude Codeand then set up autonomous loops where Claude Code writes the code... runs tests, and iterates continuously." | [团队] |
| 团队-排错 | Security 团队："feed Claude Code stack traces and documentation to trace control flow... Problems that typically take 10-15 minutes of manual scanning now resolve 3x as quickly." | [团队] |
| 团队-TDD | Security 团队从"design doc → janky code → give up on tests"转向"asking Claude for pseudocode, guiding it through test-driven development, and checking in periodically." | [团队] |
| 团队-截图 | Data Infra 团队（K8s 故障）："fed it dashboard screenshots, and Claude guided them menu-by-menuthrough Google Cloud's UI." | [团队] |
| 团队-首站 | Product Eng 团队：Claude 是"first stop"，先帮"identifying which files to examine for bug fixes, features, or analysis." | [团队] |
| 工作流-探索递进 | 理解新代码库："Start with broad questions, then narrow down"（先 overview 再 architecture/auth） | [CW] |
| 工作流-先复现 | 修 bug："Tell Claude the command to reproduce the issue and get a stack trace." | [CW] |
| 工作流-小步重构 | "Do refactoring in small, testable increments"，每步跑测试验证、保持向后兼容 | [CW] |
| 工作流-测试匹配 | "Claude examines your existing test files to match the style, frameworks, and assertion patterns"；让它找你漏的边界 | [CW] |
| 计划-切换 | "press Shift+Tab to toggle into plan mode" 或 claude --permission-mode plan，批准前可改计划 | [CW] |
| 委派-隔离 | "use a subagent to investigate ..."——"reads files in its own context window and reports a summary" | [CW] |
| 委派-限工具 | 子代理 "Enforce constraints by limiting which toolsa subagent can use" | [子代理] |
| 委派-省钱 | "Control costs by routing tasks to faster, cheaper models like Haiku." | [子代理] |
| 续接-会话 | claude --continue / --resume / --from-pr <number> 跨多次接着干，不重述上下文 | [CW] |
| 并行-worktree | claude --worktree feature-auth——独立分支并行，"concurrent edits don't collide" | [CW] |
| 图像-粘贴 | "Drag and drop an image / ctrl+v / Analyze this image: /path"；贴报错/设计/图表截图 | [CW] |
| 自动化-管道 | git log ┃ claude -p "summarize..."——非交互，stdin/stdout 像 Unix 工具 | [CW] |
| 调度-明确成功 | 自治/定时任务："be explicit about what success looks like...can't ask clarifying questions" | [CW] |
项目一 · 清华前端 —— 会话 1–4 手工精修样板
这是你最大的项目（63 会话 / 496 条）。下面只放会话 1–4 作为"七维做到极致"的范例（手工精修，含完整大佬话术与依据）；完整 63 个会话的逐条处理见 history-p1。 它的典型问题：开局抛模糊现象让模型"定位"、用"确保没问题"收尾、修不好就"还是不行"循环。
会话 1 · eef70bc9（10 轮）—— 装插件
这一整会话是装 marketplace 插件 + OAuth 回调，属于操作流水，不是"提需求"。逐条仍写，但重点是告诉你哪几条其实没必要发给模型。
1.「claude plugin marketplace add … plugin install context7/figma/playwright/serena/superpowers…」（粘贴一长串命令）
- ① 你这么说：把要装的插件命令整段贴进来，想让模型帮你装。
- ② 为什么不好：这是你粘贴的命令清单，不是手写请求。直接贴命令但没说"帮我执行"还是"检查这些对不对"，模型得猜你要它做什么——你下一条（第 2 条）才补"你可以直接帮我执行安装吗"，说明第 1 条目的没讲清。
- 当时实际发生：0 次调用——模型只是收下这串命令、没动手，在等你说"要我干嘛"。证实了第 1 条没驱动任何事。
- ③ 该怎么说：把目的和动作一句讲明——
text
帮我执行下面这些 plugin 安装命令，装完逐个确认已生效（claude plugin list 能看到）。
<命令清单>- ④ 用前：模型只能先问"要我做什么"或贸然执行。用后：一次说清"执行 + 装完验证"，省掉第 2 条的来回。
2.「你可以直接帮我执行安装吗」
- ① 你这么说：补上第 1 条缺的动作。
- ② 为什么不好：这本该和命令清单在同一条里。拆成两条 = 多一个往返。
- 当时实际发生：15 次 Bash 调用——补了这句它才真正开跑、把插件一个个装上。也就是说"动作"全靠第 2 条才触发，第 1 条白发了一轮。
- ③ 该怎么说：并入第 1 条（见上）。
- ④ 影响：合并后少一轮。
3.「可以」/ 6.「可以」
- ① 放行模型的下一步动作。
- ② 为什么不好：纯放任。这里风险低（装插件），可接受；但养成"可以"习惯，到了写代码场景就危险（见会话 2 那句 151 次调用的"我同意"）。
- 当时实际发生：第 3 条 Bash×1、第 6 条 ToolSearch×1 + 触发 figma 授权×1——都是小步操作，放行规模小、风险低，和会话 2 的"我同意→151 次"形成鲜明对比。这正说明："可以"本身不坏，坏在你不知道它要放行多大的动作。
- ③ 该怎么说：低风险小步操作"可以"没问题，保持；但凡下一步可能是大改，先问"这一步要动哪些东西"。
- ④ 影响：本会话无害；养成"先看规模再放行"的习惯，到大改场景就能救你。
4.「我重新启动了」/ 5.「我重新启动了，你看看是否安装好了」
- ① 重启客户端后让模型核对插件是否装好。
- ② 第 4 条只陈述事实没给指令，第 5 条才补"看看是否安装好了"——又是拆成两条。
- 当时实际发生：第 4 条 0 次（只是陈述"我重启了"，模型没事可做），第 5 条 Bash×1（补了"看看装好没"它才去查）。又一次"前一条空转、后一条才驱动"。
- ③ 该怎么说：
我重启了，帮我确认这几个插件都已加载：context7 / figma / playwright / serena / superpowers / skill-creator（点名要查的，比"是否安装好了"明确）。 - ④ 用后：模型直接对名单逐个核对，不用反问"你指哪几个"。
7.「可以了吗」/ 9.「还有那几个呢」/ 10.「另外几个安装了吗」
- ① 催进度 / 问剩余项。
- ② 为什么不好：「那几个」「另外几个」是无指代的代词，模型不一定和你脑子里同一份名单对齐。
- 当时实际发生：第 7 条 0 次、第 9 条 0 次、第 10 条 Bash×1。三句催问/问余项，两句完全没驱动操作——因为"那几个"模糊，模型多半在反问或泛泛回答，而不是去查。
- ③ 该怎么说：直接点名——
superpowers 和 skill-creator 这两个装好了吗？ - ④ 用后：避免它答的"那几个"≠你问的"那几个"；一句点名直接驱动它去查、不空转两轮。
8.「http://localhost:56351/callback?code=…」
- ① 粘贴 OAuth 回调 URL 完成授权。
- ② 这是授权流程必需的，没问题，正常操作。
- 当时实际发生：触发
figma complete_authentication×1——精确完成 figma 授权。这条是流程刚需，最优，无需改。 - ③ 保持。
- ④ —
本会话小结（有证据）：10 条里 5 条是 0 次调用的空转（1、4、7、9，还有催问），真正驱动操作的就 5 条。根因还是拆条发送（1+2、4+5：前一条陈述/铺垫=0 调用，后一条才驱动）。养成"目的+动作+验证"写一条，这会话能从 10 轮压到 5 轮。低风险操作"可以"无妨，但记住会话 2 那句"我同意"=151 次——"可以"之前先掂量它要放行多大动作。
会话 2 · 223da62e（23 轮）—— 智能体回答里的"切片 uuid 角标"（重点会话 · 加证据版）
这是典型的功能开发 + 反复审查会话，23 轮。下面每条多一行 当时实际发生——直接从你这条 transcript 里挖出来的真实工具调用（读了哪些文件、改了几次、跑了多少命令），让你看清每一句话真正驱动了什么。
先给你一个全局数字：这 23 轮里你的话一共驱动了约 340 次工具调用，其中一句「我同意」就占了 151 次（你没看计划就放行的巨型改动），后面"确保没问题"那几轮又烧掉 81 次，且大多在改错的层（见第 18 条）。
1.「现在学科知识问答对于智能体回答中的切片id是怎么处理的，帮我看一下」
- ① 你这么说：让模型先摸清现状——"切片 id 现在怎么处理的"。
- ② 这条其实不错：先理解现状再动手，符合 Explore→Plan。唯一缺点是没给文件锚点，模型得自己找"学科知识问答"在哪。
- 当时实际发生：3 次调用（Read
KnowledgeQA.vue+markdown.ts，Bash×1）。很高效——因为页面名好猜。 - 大佬怎么用：同样是"先理解现状"，但大佬直接
@文件而不是让模型自己找——"Reference files with@instead of describing where code lives. Claude reads the file before responding."（依据库 具体-3）。Product Eng 团队也把 Claude 当 "first stop" 先定位文件（团队-首站）。 - 为什么 · 依据：模型"自己找页面"要 grep+读一堆无关文件，每读一个文件都吃你的上下文，上下文越满表现越差（"performance degrades as it fills"，依据库 上下文-1）。
@路径让它一步读到目标、不污染上下文。 - ③ 该怎么说：
先看 src/views/KnowledgeQA.vue 里智能体回答的切片 id 是怎么解析/渲染的，给我现状，先别改。（直接给路径，连这 1 次猜测都省） - ④ 用前：它靠页面名猜中、3 次到位。用后：给路径，0 猜测——本条已经接近最优，保持。
2.「另外三个智能体也需要角标的渲染和交互功能，你先理解我的需求，分析是否可以实现」
- ① 你这么说：把已有的"角标"能力推广到另外三个智能体，并要它先评估可行性。
- ② 这条质量高：先理解需求、先评估、不急着写。可改进点：「另外三个」没点名，「渲染和交互」没说具体交互。
- 当时实际发生：10 次调用（Bash×6 Read×4），它自己摸出了那三个就是
ResearchRadar.vue / ResearchInherit.vue / LectureRecommend.vue。它猜对了，但花了 10 次去确认"哪三个"。 - 大佬怎么用：大佬会点名文件 + 指向已有范例让它照着抄——官方原话 "Reference existing patterns. Point Claude to patterns in your codebase"，例子是 "look at how existing widgets are implemented... HotDogWidget.php is a good example. follow the pattern..."（依据库 具体-1）。
- 为什么 · 依据：你这需求本质是"照着 KnowledgeQA 已有实现复制到另外三页"——给它范例文件，它就有了可对齐的模板，不用靠猜。"it can't read your mind"（依据库 具体-1）：哪三页、抄哪个范例，都得你点明。
- ③ 该怎么说：
把 KnowledgeQA 的切片角标（渲染 + 点击展开来源）复用到 ResearchRadar、ResearchInherit、LectureRecommend 三页。先分析这三页能否套同一套，给方案，先别改。 - ④ 用前：10 次调用里有一半是在确认"是哪三页"。用后：点名三页，省掉这层确认。
3.「给出最优的方案然后修改，改完之后审查一遍」
- ① 放行：出方案→改→自审。
- ② 「最优方案」「审查一遍」都是空标准。什么叫最优？审查查什么？
- 当时实际发生：0 次调用——模型没动手，而是回了一段方案文字等你确认。这一句其实没推动任何事，真正的执行全压到了第 6 条那句"我同意"上（见下）。
- 大佬怎么用：大佬不会把"出方案+改+审"塞进一句话，而是先 plan、再 implement、再 verify 分开走——"Letting Claude jump straight to coding can produce code that solves the wrong problem. Use plan mode to separate exploration from execution"（依据库 计划-1）；且改完要带可运行的验证，而不是"审查一遍"（依据库 验证-1）。
- 为什么 · 依据：你这次涉及 4 个页面、多文件改动，正是官方说的该 plan 的情形——"Planning is most useful... when the change modifies multiple files"（依据库 计划-2）。"审查一遍"没有可运行的判定，模型只能自评，等于没验证（依据库 验证-2）。
- ③ 该怎么说：
给 2 个方案对比（复用现有组件 vs 新抽组件），说清各自改动面和风险，我选一个你再改；改完自己跑 pnpm type-check，并对照这三页逐个确认角标能渲染+能点开。 - ④ 用前：它给一个含糊"最优"方案、把要不要改的判断丢回给你。用后：你拿到可对比的两案 + 明确验收，第 6 条的放行才有依据。
4.&5.「三个智能体的 prompt 会在正文里输出 $[<uuid>]$ 标记，还有什么疑问吗」（连发两条相同）
- ① 你这么说：补关键信息——后端会在正文里吐
$[uuid]$标记。 - ② 这条很有价值（给了数据格式），但你在第 4 轮才给；连发两条相同的是误触/没刷新。
- 当时实际发生：两条都 0 次调用——模型只是接收信息、回了句确认。说明这关键格式来得太晚，前 3 轮的方案都没基于它。
- ③ 该怎么说：把格式样例并进第 2 条的需求里——
后端正文里的切片标记格式是 $[8a4f4def-...]$（贴一段真实输出）。要把它解析成可点击角标。还需要我补什么？ - ④ 用前：格式晚到 4 轮，方案返工。用后：方案第一版就含解析逻辑。
6.「我同意，按照你推荐的」
- ① 放行模型推荐的方案。
- ② 比"可以"好（明确了"按推荐的"），但仍没说推荐的是哪个、你认不认同它的取舍。
- 当时实际发生：151 次调用！（Read×47 / Edit×41 / Bash×40 / Write×4 / TaskCreate×5 / TaskUpdate×13），一口气改了 16 个文件——四个智能体页 +
llm.tsknowledgeQA.tsagent.tscreateTextStreamer.tsmarkdown.ts+ 4 个新增 test。你这一句两个字的"同意"，放行了整个会话最大的一次改动，而你没看过它要改哪 16 个文件。 - 大佬怎么用：多文件大改前，大佬先在 plan mode 看完计划再放行，官方甚至给了快捷键——"Press
Ctrl+Gto open the plan in your text editor for direct editing before Claude proceeds"（依据库 计划-1/计划-2）。 - 为什么 · 依据：151 次操作里一旦有一步跑偏，会顺着错误方向改十几个文件、污染上下文，后面全靠你补救（本会话第 14–16 条的"确保没问题"就是在补这次盲改）。先看计划 = 在 0 成本时拦截方向错误；这正是"modifies multiple files"该 plan 的典型（依据库 计划-2），也避开反模式"trust-then-verify gap"（依据库 验证-4）。
- ③ 该怎么说：放行大改前，先让它把改动面摊开再批——
开始前先列：要改哪些文件、各自改什么、有没有动到公共解析逻辑（markdown.ts 这种）。我看完再说改不改。（或直接进 plan mode，让它先出计划你再 approve） - ④ 用前：151 次盲盒操作一次性砸下来，跑偏了你也是事后才知道（后面 6 轮"确保没问题"就是在补这次盲改的窟窿）。用后：先看 16 文件清单，30 秒就能拦下不该动的，避免后面几十次返工。
7.「Provide a code review for the given pull request…（/code-review 的内置 prompt）」
- ① 这是
/code-review命令展开的模板，不是你手写的。 - ② 无需点评。 Bash×1（命令自身的检查）。 ③ —（保持用
/code-review） ④ —
8.「完成了吗」
- ① 催进度。
- ② 纯催，没说"完成"的标准。
- 当时实际发生：0 次调用——模型只是嘴上答"完成了"。它没做任何实际核对就回了你"是"，这正是没给验收标准的后果：它的"完成"毫无含金量。
- 大佬怎么用：大佬从不问"完成了吗"，而是给一个它能自己跑的检查——"Give Claude a check it can run: tests, a build, a screenshot to compare"，并要它拿证据不要口头保证："Have Claude show evidence rather than asserting success: the test output, the command it ran and what it returned"（依据库 验证-1/验证-3）。
- 为什么 · 依据：模型"stops when the work looks done"——没有可跑的检查，"看起来完成"就是它唯一的信号，于是你变成了验证回路本身（依据库 验证-2）。给它 type-check/测试，它自己就能判停，你不用一遍遍催。
- ③ 该怎么说：
三页的角标都能渲染+点开了吗？type-check 过了吗？把验证结果贴给我。 - ④ 用前：得到一句空头"完成了"，所以你后面又追问了 5 遍。用后：逼它真去验、贴结果，一次踏实。
9.「你看工作区审查就可以了啊」
- ① 纠正模型：看工作区改动审查就行（它想看 PR）。
- ② 有效纠偏，但偏被动——它跑偏到"找 PR"了你才拉回。
- 当时实际发生：10 次调用（Agent×5 = 起了 5 个审查子代理 + Bash×4 + Read×1）。它确实按你说的转向了工作区审查。
- ③ 该怎么说：开局就限定——
审查范围就是当前工作区未提交改动（git diff），不用找 PR。 - ④ 用前：先白跑去找不存在的 PR，你再拉回。用后：5 个审查代理直接对着工作区跑。
10.「我需要你仔细确认，把经过真实论证的真实bug给出来」
- ① 要它别报虚的，只给论证过的真 bug。
- ② 意识很好（防幻觉 bug），但"仔细确认""真实论证"还是形容词。
- 当时实际发生：0 次调用——它没去复跑验证，只是文字上"确认"了一遍。你要的是"论证"，它给的还是嘴上保证。
- 大佬怎么用：大佬让审查者只报影响正确性的、并带证据，且明确告诉它"挑刺会为了挑而挑"——官方原话："Tell the reviewer to flag only gaps that affect correctness or the stated requirements, and treat the rest as optional"（依据库 验证-4 同源 [BP] 审查节）。
- 为什么 · 依据：你已经意识到"幻觉 bug"问题（很好），但"真实论证"是形容词、模型无法据此筛选。把"论证过"定义成"带触发路径+复现方式"，模型才有可执行的筛选标准——否则它只能继续给似是而非的清单（反模式 验证-4trust-then-verify gap）。
- ③ 该怎么说：
每个 bug 给：触发路径 + 你验证它存在的方式（哪行代码/哪次运行）+ 影响。不能复现或只是风格的别报。 - ④ 用前：拿到的是"我确认过了"的空话。用后：每条 bug 带触发路径+证据，假阳性当场露馅。
11.「把真实的问题修复一下吧」
- ① 放行修复。
- ② "真实的问题"指代上一轮那批——可接受，但没说改完怎么验。
- 当时实际发生：8 次调用（Read×4 Edit×2 Bash×2），改了
ResearchRadar.vue。一次小修，规模正常。 - ③ 该怎么说：
修上面确认的那几个，改完每个对应说明怎么验证已修复。 - ④ 用前：修完没验证说明。用后：修完即带验证，不用再开一轮。
12.&13.「科研雷达与查重，uuid 还没处理成角标（和角标动画）。你仔细看一下」
- ① 指出具体哪两页的 uuid 没处理成角标。第 13 条补了"角标动画"。
- ② 比第 8 条好很多（点了具体页、具体现象）。问题还是分两条发、"仔细看一下"软。
- 当时实际发生：第 12 条 0 次（你拆句导致它先等），第 13 条 7 次（Bash×3 Read×1 Edit×3，改
LiveOutputPanel.vue）。拆成两条让第一条空转。 - ③ 该怎么说：
科研雷达、查重两页：正文里 $[uuid]$ 还原样显示、没渲染成角标也没动画。先复现，再对照 KnowledgeQA（已 ok）找差异，给根因再改。 - ④ 用前：第 12 条空转一轮。用后：一条带齐"现象+对照基准"，它直接 diff 出差异。
14.&15.&16.「仔细审查，确保所有的都接好了，边界情况都考虑到了」（连发三条近义）
- ① 反复要它确保"全接好、边界都考虑"。
- ② 你 77 次"仪式化审查"的活标本——三条同义咒语，一次都没给"接好"的判定标准。
- 当时实际发生：第 14 条 0 次，第 15 条 16 次（Read×6 Edit×1，扫了 5 个页面文件），第 16 条 29 次（Read×13 Edit×9，全砸在
LectureRecommend.vue一个文件上反复改）。三句"确保没问题"= 45 次调用，而且在反复折腾 .vue 视图层——可真正的 bug 不在这层（见第 18 条）。 - 大佬怎么用：大佬不会反复说"确保没问题"，而是一次给出可勾选的验收清单 + 让一个 fresh 子代理对照清单审——"Name the work to check, the plan to check it against, and what counts as a finding... Report gaps, not style preferences"（依据库 验证节 [BP]）。Security 团队排错则是喂 stack trace/真实输出去追控制流，快 3 倍（依据库 团队-排错）。
- 为什么 · 依据：连发三遍同义模糊指令 = 让模型在同一层反复空扫（45 次调用全在视图层），因为它没有"查什么"的清单，只能泛泛重扫。可勾选清单把"确保没问题"翻译成可执行的判定，模型逐条验、附证据，一次到位（依据库 验证-2/验证-3）。
- ③ 该怎么说：把"接好了"拆成可勾选清单，一次给——
text
逐项给"通过/不通过 + 证据"，别给风格建议：
1. 四个智能体页都能把 $[uuid]$ 渲染成角标？
2. 角标点击能展开来源、动画都在？
3. uuid 解析对边界不崩：无标记、半个标记 $[、空 uuid、连续多个标记？
4. 这四页用的是同一套解析函数，还是各写各的？- ④ 用前：45 次调用大多在改视图层、没碰到真正的解析层，等于白忙。用后：清单第 3、4 条会直接把它逼向"解析函数"这个真正出 bug 的地方。
17.「Unknown command: /com. Did you mean /copy?」
- ① 误触。 ② 系统报错回显，非请求。 0 次。 ③ — ④ —
18.「我现在看到的科研雷达与查重应该角标没有…（粘贴了一大段真实智能体输出）」
- ① 把页面实际渲染出来的回答整段粘给模型，说明"角标没出来、uuid 还是裸的"。
- ② 粘贴真实现场输出是好做法（给了证据）！但开头半句话没说清，结论和证据混在一坨。
- 当时实际发生：36 次调用（Bash×21 Read×13 Edit×2），这次终于读改到了
markdown.ts/splitMarkdownBlocks.ts/MarkdownBlock.vue——真正的解析层！对比第 15/16 条只在 .vue 视图层打转：直到你贴出真实输出，模型才被导向真正出 bug 的 markdown 解析代码。这条是整会话的转折点。 - 大佬怎么用：贴真实输出/堆栈正是大佬排错的标准动作——Security 团队"feed Claude Code stack traces and documentation to trace control flow"，把 10–15 分钟的人工排查缩短 3 倍（依据库 团队-排错）；官方报 bug 模板也是先给症状再定位（依据库 症状-1）。
- 为什么 · 依据：你前 45 次调用在视图层空转，是因为没有"真实数据"把模型锚到出错的那一层。一段真实输出 = 把抽象的"角标没出来"变成可追踪的具体串（裸 uuid），模型顺着它就能定位到解析层。这就是"describe the symptom + likely location"的威力（依据库 症状-1）。
- ③ 该怎么说：先一句结论再贴证据——
现场输出如下，注意正文里的 [8a4f4def-...] 全是裸 uuid（应该变角标）。先去查 markdown 解析/分块那层（splitMarkdownBlocks/markdown.ts），别只改页面组件：<粘贴> - ④ 用前：前面 45 次"确保没问题"在视图层空转，真相靠你第 18 轮贴真实输出才逼出来。用后：开局就带真实输出 + 指向解析层，这 bug 第 2、3 轮就能定位，省掉中间 80+ 次调用。
19.&20.「你（可以）帮我测试一下吧，确保没有任何问题」（连发两条）
- ① 让模型测试并"确保没问题"。
- ② 又是"确保没问题"。前端角标这种 UI 行为，模型在容器里测不了真实浏览器渲染。
- 当时实际发生：第 19 条 21 次（Bash×18 + Write×1，跑测试、写了个测试文件），第 20 条 3 次（Bash×3 重跑）。它能跑的其实是单测/type-check，浏览器渲染始终没碰。
- 大佬怎么用：UI 类验证大佬用截图对比——"[paste screenshot] implement this design. take a screenshot of the result and compare it to the original"（依据库 视觉-1）；Product Design 团队直接喂 Figma、让它自跑测试迭代（依据库 团队-设计）。逻辑部分则交给单测（依据库 团队-TDD）。
- 为什么 · 依据：容器里的模型碰不到真实浏览器，"确保没问题"逼它跑了一堆 Bash 也验不到角标渲染——这是典型"trust-then-verify gap"（依据库 验证-4）。正确做法是分层：它能验的（解析单测）让它验，它验不了的（UI 渲染）给你列手点清单或用截图对比。
- ③ 该怎么说：分清谁测什么——
你能跑的：type-check + uuid 解析函数单测（覆盖第 16 条那些边界）。浏览器里的角标渲染我自己点，你列一张我要手点的 checklist。 - ④ 用前："确保没问题"逼它跑了一堆 Bash，但 UI 行为根本没验到、给你假安心。用后：单测覆盖解析层（它真能验的），UI 给你手点清单，各管各的。
21.「我给你授权了」
- ① 告知已给权限（放开某操作）。
- ② 看似无害的协作信号，但——
- 当时实际发生：30 次调用（Bash×25 + Edit×3），读的是
rolldown-build-...mjs（构建产物 / node_modules）。它跑去折腾构建/依赖了——离"角标 bug"已经很远。这说明会话到这里已经发散，授权放行的是一串和主线无关的环境操作。 - ③ 该怎么说：授权时顺手收一下缰绳——
授权了。但只处理角标解析这条主线，别去动构建配置/依赖；要装包或改构建先问我。 - ④ 用前：一句"授权了"放它跑了 25 条 Bash 去碰构建，主线 bug 反而搁置。用后：授权同时划边界，算力留在主线上。
22.「没事，不纠结这个了，你确保我们的代码没有任何问题了」/ 23.「你确定代码层面没有任何问题了」
- ① 收尾，再要一次"代码没问题"的保证。
- ② 整会话的缩影：第 14 条到这里你问了不下五遍"确保/确定没问题"。根因是第 3、6 条放行时没立验收标准，所以每轮的"完成"都不可信，你只能反复追问找安全感。
- 当时实际发生：两条都 0 次调用——模型只回了"是的没问题"。第 5、6 遍追问，换来的还是 0 验证的嘴上保证。一个完美的空转闭环。
- 大佬怎么用：大佬遇到"反复纠正/反复追问"会直接止损重开——"If you've corrected Claude more than twice on the same issue... Run
/clearand start fresh with a more specific prompt"（依据库 纠偏-2）；收尾则用一次带证据的成品验收（依据库 验证-3），不靠反复问保证。 - 为什么 · 依据：从第 14 条问到第 23 条，上下文已被一堆"没问题/确定吗"和失败尝试塞满，上下文越脏模型越容易丢指令、越爱给安抚式回答（依据库 上下文-1+ 反模式"correcting over and over"）。所以要么一次成品验收终结、要么
/clear带更尖的 prompt 重来。 - ③ 该怎么说：用一次"成品验收"终结它，而不是反复问保证——
text
最后给我一份交付确认，别再说"没问题"三个字:
- type-check / 单测：贴结果
- 第 16 条 4 项清单：逐条通过/不通过
- 还剩哪些你没法验证、需要我手点的：列出来- ④ 用前：22、23 = 第 5、6 遍要保证、各 0 次调用，纯空转。用后：一次拿到可核对的交付清单，会话第 18 条附近就能收尾。
本会话小结（最值得记住的，全部有证据）：
- 一句 「我同意」放行了 151 次操作 / 16 个文件 ——大改前先要"改哪些文件"清单或走 plan mode。
- 5 次"确保/确定没问题"里，3 次是 0 调用的嘴上保证，2 次共 45 次调用在改错的层（视图层），真正的解析 bug（
markdown.ts）直到第 18 条你贴出真实输出才被定位。- 结论：这一会话约 340 次工具调用里，至少 80+ 次是可避免的空转——根因就一个：放行时不立验收标准 + 报 bug 不带真实输出。把第 6 条改成"先看文件清单"、把第 14 条改成"带真实输出 + 指向解析层"，23 轮能压到 ~10 轮。
会话 3 · ed2ff75c（4 轮）—— 下拉框限高
1.&2.「所有聊天记录的下拉帮我限制高度，显示5长/5行，超出的滚动」
- ① 你这么说：聊天记录下拉框限高，显示约 5 行，超出滚动。第 2 条把"5长"改成"5行"（改错别字）。
- ② 这条需求本身清楚（限高、5 行、滚动），就是没给文件、也没给"一行多高"。模型得猜是哪个下拉、5 行换算成多少 px。
- 当时实际发生：第 1 条（"5长"错别字）0 次——模型大概没看懂"5长"在等你；第 2 条改成"5行"后 7 次（Skill×1 Read×1
ConversationHistoryMenu.vueBash×3 Edit×2），它自己找到了组件并改完。它猜中了文件，但你那个错别字白费了一轮。 - ③ 该怎么说：
src/components/ConversationHistoryMenu.vue 的下拉，max-height 设成约 5 条的高度（一条约 40px 就给 200px），超出 overflow-y:auto。 - ④ 用前：错别字废一轮 + 它花调用去定位组件。用后：给路径+px 数值，一轮改完。
注：你这会话里"5长→5行"是手滑，但它暴露了一个真问题——短句容易带错别字/歧义，模型不会追问就先卡住。短句更要一次写对。
3.「说中文」
- ① 让模型改用中文回复。
- ② 这本该一次性放进项目 CLAUDE.md（"始终中文回复"），而不是每次口头纠正。
- 当时实际发生：0 次调用——纯指令切换，但它占了你一整轮。一年里这种"说中文"你说过不止一次，每次都是一轮纯损耗。
- ③ 该怎么说：在该项目
CLAUDE.md写一行回复用中文，技术词/代码/路径保持原文，以后不用再说。 - ④ 用后：所有会话默认中文，不再浪费一轮。
4.「你确定全部改好了吗」
- ① 又一次"确定改好了吗"。
- ② 同会话 2——没验收标准的追问。这种小改其实你自己刷新页面看一眼最快。
- 当时实际发生：Bash×3——它跑了几条命令想自证改好了，但限高这种 UI 效果命令行根本验不出来，等于又是一轮"假验证"。
- ③ 该怎么说：
改了哪个文件、max-height 设了多少，贴给我，我自己刷新看。 - ④ 用前：它跑 3 条命令假装验证 UI（验不了）。用后：拿到改动点你自己刷新，1 秒确认，比一句"确定吗"有用。
会话 4 · 37b2dfed（7 轮）—— 角标输出变问号 / 没调接口
1.「现在学科知识问答只能返回我们做的角标，为什么输出完之后全部变成问号，为什么没有调接口呢」
- ① 你这么说：报现象——角标输出完变成"？"、而且怀疑没调接口。
- ② 这条信息不错（有现象+你的怀疑点"没调接口"），可惜句子绕（"只能返回我们做的角标"有点难读）。模型要先解析你这句。
- 当时实际发生：40 次调用（Skill×1 Bash×20 Read×19）——读了
KnowledgeQA.vue、各种 use*、连vite.config都翻了。Read 高达 19 次=它在大海捞针，因为你只给了"变问号"这个现象、没指向"接口/解析"哪一层，它只能满仓库摸。 - ③ 该怎么说：现象 / 你的怀疑 / 期望 三段分开——
text
现象：学科问答的角标渲染完之后，内容全变成"？"。
我的怀疑：根本没调到后端接口（拿不到 uuid 对应的来源）。
先抓网络请求确认接口到底有没有发出、返回什么，再判断是前端解析还是后端没返回。- ④ 用前：它先读懂你绕的句子、再盲查。用后：直奔"抓请求"这个最快验证点。
2.&3.「我需要你调用接口我才能知道是前端还是后端的问题，现在直接问号根本没法查看，你先理解我的需求，看看怎么实现」
- ① 你这么说：要它真的把接口调起来，好定位前端还是后端。
- ② 诉求合理（要实证不要猜），但"调用接口"在容器里它未必能调真后端。关键是你已经点出"分前端/后端"——这正是该用抓包/打日志而不是空想的地方。
- 当时实际发生：第 2 条 0 次（你拆句，它先等），第 3 条 65 次（含 ExitPlanMode×1——它这次先进了 plan mode 出计划！TaskCreate×6 TaskUpdate×11 Read×9 Edit×11 Bash×24）。这是你少有的一次"模型自己用了 plan mode"——所以这轮虽然 65 次调用，但有计划、不算瞎跑。可惜是它主动开的，不是你要求的。
- ③ 该怎么说：
在解析 uuid、发请求、收响应三个点各打一行 console.log，我去页面触发一次，把控制台贴回来——我们用真实日志定位是没发请求、还是返回里没数据。 - ④ 用前：第 2 条拆句空转一轮；好在第 3 条它自发 plan。用后：合并成一条、明确"打三处日志我来触发"，连 plan 都省了，直接奔实证。
4.「你确定我们解析的对吗」
- ① 怀疑解析逻辑。
- ② 又是"你确定吗"。其实你已经有更具体的怀疑（解析），直接让它把解析结果摆出来更快。
- 当时实际发生：0 次调用——"你确定吗"又是一句没驱动操作的反问。你心里已经怀疑"解析"，但用问句包了一层，模型只能嘴上回应。
- ③ 该怎么说：见第 5 条（你下一句自己就修正成"打印出来"了，方向对）。
- ④ 用前："你确定吗"空转一轮。用后：直接说"把解析结果打出来"，省掉这轮。
5.&6.&7.「我要你把解析（uuid）的全部打印出来」（连发三条）
- ① 你这么说：要它把解析出来的 uuid 全打印。
- ② 这条方向完全正确——用打印/日志拿实证，正是排错该做的。问题只是连发三条（第 5→6 加了"uuid"、6→7 重复）。
- 当时实际发生：第 5 条 4 次（Edit×2 加了 print），第 6 条 15 次（Read×4 Edit×8 Bash×2），第 7 条 5 次（Edit×3）。三条同义指令分三轮、每轮只加了点 print，本可一轮加全。
- ③ 该怎么说：一条说清——
把解析阶段每一步打印出来：原始正文片段、正则匹配到的标记、提取出的 uuid 列表。我触发一次贴回控制台。 - ④ 用前：连发三条、它每次只补一点 print，分三轮。用后：一次列全要打的三个值，一轮加完、一轮定位。
本会话小结（有证据）：
- 第 1 条模糊开局 → Read 19 次大海捞针；第 4 条"你确定吗" → 0 次空转；第 5/6/7 三条同义"打印" → 分三轮（4+15+5 次）才加全 print。
- 亮点：第 3 条模型自发用了 plan mode（这一年你只有 3 次 plan 相关记录，这是其中之一，还是它替你开的）。说明 plan mode 对你这种排错很有用，值得你主动开，而不是等它开。
- 结论：7 轮里真正干活就 3 轮，其余在"句子绕/你确定吗/拆三条"上空转。开局给"现象+怀疑层+打哪几处日志"，3 轮能搞定。
项目一完整 63 会话（含上面 1–4 的团队版）见 history-p1；其余项目见上方进度总表。