Claude Code 深度学习手册

主题

项目七 · 清华 ​

← 返回总览/依据库/标准　|　路径 jiuxinshuzhi-qinghua

2 会话 · 17 条消息 · 驱动 119 次真实调用　|　实质 A=11　放任/操作 B=6　噪声 C=0

会话 1 · 5a9d97e4（12 轮 · 84 次调用 · 实质 8） ​

1.「docs/image.png 截图中，我们的首页和学科知识问答，年限要和后端的保持一致，前端现在显示不准确，应该做限制，不在规定年限不能选择的，因为现在用户选完提示年限不对体验很不好，先理解我的需求」

  • 你这么说：要求前端年限选择器和后端返回的真实年限区间对齐、并做超界禁选，先让模型复述确认需求——属于需求类(带排错动机)。
  • 问题：这条其实开局不错：给了截图docs/image.png、点明问题页面(首页/学科知识问答)、说清痛点(选完才提示年限不对)、还要求'先理解我的需求'。缺口在于没给后端年限的真实取值来源(哪个接口/字段返回year_range)，模型只能自己满仓库找，导致17次调用里有大量Bash探查。
  • 实际发生：17 次调用（Bash×11 Read×5 AskUserQuestion×1）。读改文件：image.png、ParamsBar.vue、knowledge-graph.ts、KnowledgeGraphDashboard.vue。
  • 大佬怎么用：大佬会用@直接指出年限数据来源文件再让它读(具体-3)，并把'先理解需求别改'明确为先定位不动手(团队-首站)。
  • 依据：不给数据锚点时模型要靠Bash/Read大海捞针，读一堆无关文件把上下文填满，越往后表现越降(上下文-1)；@文件让它读完再答，省掉探查回合(具体-3)。
  • 该怎么说：参照 docs/image.png，首页和学科知识问答的年限选择器要和后端 year_range 对齐：后端返回见 @<返回year_range的接口/配置文件>，当前是 [1964, 2026]。需求是超出该区间的年份不可选(禁用而非选完报错)。先读 ParamsBar.vue 和 knowledge-graph.ts 复述你理解的现状，先别改。
  • 用前→用后：原话已较具体但缺数据来源→触发17次调用(Bash×11探查年限来源)；点明 year_range 接口和 [1964,2026] 后，可省去大半 Bash 探查、直接定位 ParamsBar.vue 改限制。

2.「这样的话，我们后面是不是要一直维护年限，还是给个把说明改一下就可以了吧」

  • 你这么说：纠结这套年限对齐方案的长期维护成本——是要一直跟后端维护年限，还是改个说明就够，属于设计/取舍类。
  • 问题：纯开放式自问自答，没下任何指令也没给判断依据(年限多久变一次、说明改了能否解决体验问题),模型无从落地，于是0调用空转。两个方案('一直维护'vs'改说明')的取舍标准完全没给。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：大佬会把取舍问题转成让模型先取证再建议：先确认 year_range 是否随数据增量变化(团队-首站定位数据来源),再给方案对比。
  • 依据：开放式取舍提问没有可执行落点，模型只能口头泛泛回应=0调用空转;给出判定维度(变更频率/维护成本)它才能去读代码取证而非空谈(具体-1：it can't read your mind)。
  • 该怎么说：年限区间会随后端数据增量变化吗?先去 @knowledge-graph.ts / 后端配置 确认 year_range 是动态生成还是写死。如果动态:做成从接口拉取自动同步;如果基本不变:只在说明里标注区间。给我这两个方案的维护成本对比再定。
  • 用前→用后：原话0次调用(纯口头纠结)→给出'去确认year_range是否动态+两方案成本对比'的指令后,可驱动模型读配置取证、给出可拍板的对比。

3.「这样的话，我们后面是不是要一直维护年限，还是把说明改一下就可以了吧」

  • 你这么说：与第2条几乎一字不变地重复同一个维护取舍问题('一直维护年限'vs'改说明')，属于设计/取舍类。
  • 问题：这是第2条的复读(仅'给个把'改成'把'),说明上一轮没拿到满意答复又重问。重复开放式提问不仅同样0调用空转,还把上下文塞进了几乎重复的内容,等于无效占用。纠结点始终没转成可执行验证。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：同一问题没进展时,大佬不会复读而是换成带证据要求的指令,或纠正超2次就/clear带更尖问题重开(纠偏-2)。
  • 依据：同一意图反复追问把上下文搞脏、信息密度被稀释,模型表现随上下文变满而下降(上下文-1);纠正/追问超过两次仍无进展应/clear重来而非继续复读(纠偏-2)。
  • 该怎么说：(别重复上一句)直接给指令:读 @knowledge-graph.ts 看 year_range 是怎么来的,贴给我它是动态还是写死;基于此结论二选一并说明理由——A 接口同步自动维护 / B 仅改说明文案。不要再让我重复问。
  • 用前→用后：和第2条同样0次调用,且复读浪费一轮上下文→改成带证据要求的单一指令,既驱动取证又避免重复占用上下文。

4.「现在后端返回了是吗」

  • 你这么说：确认后端是否已经在返回年限数据(为前端对齐做前置核实)，属于探索/操作核实类。
  • 问题：问得简短但缺主语和锚点:'后端返回了'指哪个接口、在哪验证都没说,模型只能自己猜要去看代理配置还是发请求,4次调用里翻到了vite.config.ts(代理)才间接验证。问句没指明'怎么算返回了'的验证方式。
  • 实际发生：4 次调用（Bash×3 Read×1）。读改文件：vite.config.ts。
  • 大佬怎么用：大佬会@代理/接口配置文件让它直接读(具体-3),或直接给可跑的核实方式(发一次请求看响应)而非让它猜在哪验证(验证-3要证据)。
  • 依据：不指明验证入口时模型要靠Bash探查代理和接口位置;@文件或给出可跑命令能让它直接拿到证据回答,省掉猜测回合(具体-3、验证-3)。
  • 该怎么说：后端那个返回 year_range 的接口现在通了吗?看 @vite.config.ts 的代理配置确认转发地址,然后 curl 一下该接口把响应贴给我,用真实返回确认,别靠猜。
  • 用前→用后：原话4次调用(Bash探查+翻vite.config.ts间接确认)→指明@vite.config.ts并要求curl贴响应后,可一步直达真实证据、省去探查代理位置。

5.「{ "paper_count": 642669, "year_range": [ 1964, 2026 ], "files_loaded": 817, "files_scanned": 817, "files_failed": 0, "duplicate_count": 10134, "build_time": "2026-05-27T10:14:48", "data_dir": "/data/dingkai/hou/tupu/ee_kg/data", "defaults": { "min_keyword_freq": 5, "min_edge_weight": 2, "min_paper_count": 2, "min_collab_weight": 1, "top_n_keywords": 50, "top_n_authors": 30, "top_n_institutions": 30, "top_n_timeline": 20, "top_n_burst": 20, "top_n_teams": 20, …（后略）」

  • 类型：追问确认
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 点评：0 信息追问，模型只能口头答"是"。换成"给我可核对的证据/验收清单"（见话术手册·确保没问题）。

6.「你确定这样是用户体验最优的方案吗」

  • 类型：追问确认
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 点评：0 信息追问，模型只能口头答"是"。换成"给我可核对的证据/验收清单"（见话术手册·确保没问题）。

7.「数字框+实时限制+可见边界提示 是不是更好，因为区间是不是可能划不准」

  • 你这么说：提出一个更优交互方案——用'数字框+实时限制+可见边界提示'替代区间选择,因为担心区间划不准,属于设计/需求类。
  • 问题：这条方案想法其实有价值(指出区间可能划不准),但以反问形式抛出('是不是更好'),没下'就这么改'的指令、也没说边界提示具体长什么样,模型只能口头附和=0调用空转。'实时限制''可见边界提示'的交互细节都没定义。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：大佬会把方案敲定为可执行需求一次给全(输入框范围+超界行为+提示文案),让模型直接动手而非征求同意(具体-2);UI改动要求截图对比验证(视觉-1)。
  • 依据：反问'是不是更好'是征询不是指令,模型只能回答'是'而不会动手=0调用;把交互细节(输入框范围/超界行为/提示文案)写死,它才有可落地的明确目标(具体-2:越精确越少返工)。
  • 该怎么说：改用数字输入框方案,别用区间选择(区间划不准):起止年份各一个输入框,限制只能输 1964–2026;输入超界时实时拦截并在框下显示红字'仅支持 1964–2026'。在 ParamsBar.vue 里改,改完截图给我看效果。
  • 用前→用后：原话0次调用(反问被当成口头征询)→敲定为'数字框+1964-2026限制+超界红字提示'的明确指令后,可直接驱动模型改 ParamsBar.vue 并截图验证。

8.「可以」

  • 类型：放行
  • 实际发生：4 次调用（Bash×3 Skill×1）。
  • 点评：纯放行/推进。低风险可保持；若下一步可能是大改，先问"这一步要动哪些文件"再放行（见话术手册·放行）。

9.「继续吧」

  • 类型：放行
  • 实际发生：21 次调用（Bash×11 Edit×9 Write×1）。读改文件：ParamsBar.test.ts、ParamsBar.vue。
  • 点评：纯放行/推进。低风险可保持；若下一步可能是大改，先问"这一步要动哪些文件"再放行（见话术手册·放行）。

10.「你确定完全处理好，考虑所有的边界情况了」

  • 你这么说：对刚完成的年限限制实现做兜底验收,担心边界情况没覆盖全,属于确保没问题类。
  • 问题：典型形容词验收:'完全处理好''考虑所有边界情况'没有判定标准,模型只能泛泛自查+口头答'是'。这次靠9次调用(改了4处+跑了4次Bash)做了些自查,但用户没指定要查哪些边界(空值/超界/起>止等),验收标准全靠模型自由发挥。
  • 实际发生：9 次调用（Edit×4 Bash×4 Read×1）。读改文件：ParamsBar.test.ts、ParamsBar.vue。
  • 大佬怎么用：大佬会把'考虑所有边界'换成可勾选清单并要每项的通过证据(验证-1),让模型贴测试/命令输出而不是断言'都处理好了'(验证-3)。
  • 依据：没有可跑的检查时,'看起来完成'就是唯一信号,你自己变成验证回路(验证-2);给出明确边界清单+要证据,才能把口头保证变成可核对结果(验证-1)。
  • 该怎么说：逐项给'通过/不通过+证据',别口头说都好了:1)起年=止年时是否正常 2)起>止时是否拦截 3)输入1963或2027是否被实时拒绝 4)非数字/空值输入是否不崩 5)首页和学科知识问答两处行为是否一致。最后贴 ParamsBar.test.ts 的运行结果;你没法自测、要我手点的列出来。
  • 用前→用后：原话9次调用(模型自由发挥式自查)→给出5项边界清单+要测试输出后,自查有了靶子、产出可核对的逐项证据而非'已全部处理'的空话。

11.「继续吧，我刚刚好像不小心删了，需要加回来」

  • 你这么说：让模型继续,同时报告自己误删了内容需要补回,属于操作/修复类(放行+排错混合)。
  • 问题：'好像不小心删了'信息缺口很大:删了哪个文件、哪段内容、什么时候删的都没说,模型只能自己比对仓库猜哪里少了东西,导致28次调用(Bash×12+Read×5)大量在恢复定位上空耗,还动到了 markdown.ts、bvrgp4ygy.output 等本不相关文件。
  • 实际发生：28 次调用（Bash×12 Edit×9 Read×5 Write×1 ToolSearch×1）。读改文件：ParamsBar.vue、ParamsBar.test.ts、markdown.ts、bvrgp4ygy.output。
  • 大佬怎么用：大佬遇到误删会给精确坐标(哪个文件哪段)而非让它猜(具体-3),或直接用 git diff/恢复手段定位被删内容再让它补。
  • 依据：无边界的'好像删了'等于让模型在整个仓库做无边界investigate,会读大量文件填满上下文(上下文-2);给出文件名和被删内容范围能把恢复收敛到一处(具体-3)。
  • 该怎么说：继续。另外我误删了 ParamsBar.vue 里 <具体是哪段,如年份校验函数/某个 watch> 这段,先 git diff ParamsBar.vue 看我删掉了什么,把那段原样加回来,只动这一个文件,别碰 markdown.ts 这些无关文件。
  • 用前→用后：原话28次调用(Bash×12+Read×5在全仓恢复定位,误触 markdown.ts/bvrgp4ygy.output)→指明被删文件+用 git diff 定位+'只动这一个文件'后,可把恢复收敛到 ParamsBar.vue 一处、省去发散。

12.「先不管，只看我们本次修改的内容，是否满足需求了」

  • 你这么说：收尾时聚焦验收,要求只看本次修改是否满足需求、忽略其他问题,属于确保没问题类。
  • 问题：方向收得好('只看本次修改'划定了范围),但'是否满足需求'仍是无标准验收,模型只用1次Bash就草草回应,没有逐项对照最初需求(年限对齐+超界禁选+两页一致)给结论。范围圈对了但缺验收清单。
  • 实际发生：1 次调用（Bash×1）。
  • 大佬怎么用：大佬会拿最初需求当验收清单逐条核对,并要每条的证据而非整体一句'满足了'(验证-1、验证-3)。
  • 依据：即使范围收窄,没有逐条验收点模型仍只能泛答'满足',你还是验证回路本身(验证-2);把需求拆成勾选项+要证据,1次自查才能变成可信结论(验证-1)。
  • 该怎么说：只看本次改动,对照最初需求逐条判通过/不通过+证据:1)年限选项已和后端 year_range[1964,2026]对齐 2)超界年份不可选/被实时拦截 3)首页与学科知识问答两处行为一致。每条贴出对应代码或测试结果,别给一句'满足了'。
  • 用前→用后：原话1次调用(草草回应)→给出对照最初需求的3项验收清单后,1次自查升级为逐条带证据的结论,真正确认需求是否达成。

本会话小结：本会话真正驱动改动的是第1条(17次)、第9条(21次)、第11条(28次)；空转重灾区是第2、3、7条——三条都在'要不要维护年限/区间准不准/数字框是不是更好'里自言自语地纠结方案，0调用，因为只抛了开放式疑问没下指令。根因就是第2/3条这对几乎一字不差的重复提问，把方案讨论停在口头层面，没有让模型去读后端返回或改代码验证。第10条'确定都考虑边界了'是典型形容词验收(9次自查)，第12条'只看本次修改是否满足需求'收尾得当但缺验收清单。

会话 2 · c9e7368b（5 轮 · 35 次调用 · 实质 3） ​

1.「“首页”，点击“时间演化”标签页，鼠标选停在曲线图上，显示的提示内容显示【object】这个可以定位到问题吗」

  • 你这么说：报一个前端 tooltip 显示 [object] 的现象，问模型『这个能不能定位到问题』——属于排错，但用疑问句代替了指令。
  • 问题：整句是封闭式疑问（『可以定位到问题吗』），模型读完只会回答『能/我看看』而不知道你要它现在就动手；现象只给了『提示内容显示【object】』，没给复现路径之外的怀疑层（是数据没序列化？还是 tooltip formatter 写错？），更没说『可以改代码吗』，于是模型保守地0次调用空转。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：大佬报 bug 会给症状+likely location+先写失败测试复现（症状-1），而不是抛个现象问『能定位吗』。
  • 依据：没有可执行的动作指令时，『看起来该回答你』就是模型唯一的信号，它停在口头回应而非动手（验证-2）；疑问句也没有把怀疑层喂进去，模型无从缩小范围（具体-1：it can't read your mind）。
  • 该怎么说：现象：首页『时间演化』标签页，鼠标悬停曲线，tooltip 显示 [object] 而不是数值。我的怀疑：tooltip formatter 直接 toString 了对象 / 或数据点是对象没取字段。先复现确认，定位到具体是哪个文件哪行的 formatter，给我根因，先别改代码。
  • 用前→用后：原话疑问句式 → 0 次调用空转；下一轮几乎同样的描述只加了一句『先完全确认真实问题，不要改代码』就驱动了 8 次调用（Bash×4 Skill×2 Read×2）并读到 KgExtendedModulePane.vue。

2.「“首页”，点击“时间演化”标签页，鼠标选停在曲线图上，显示的提示内容显示【object】这个可以定位到问题吗，先完全确认真实问题，不要改代码」

  • 你这么说：重复第1句的现象，并补上『先完全确认真实问题，不要改代码』——排错，且这次给对了边界。
  • 问题：这条写得明显更好：『先完全确认真实问题』给了动作（先定位），『不要改代码』划了边界（只调查不动手），所以模型敢去 Bash+Read 实证而不必担心越权改代码。仍可更好的一点是没点出怀疑层（是 formatter 还是数据本身），定位范围仍偏宽。
  • 实际发生：8 次调用（Bash×4 Skill×2 Read×2）。读改文件：KgExtendedModulePane.vue。
  • 大佬怎么用：大佬调查时会显式划范围+先实证，团队喂 stack trace/真实输出追控制流，比满仓库找快约3倍（团队-排错）。
  • 依据：『不要改代码』把任务限定在调查阶段，避免一上来就改错地方（计划-1：直接跳去写代码会解错问题）；明确的『先确认真实问题』给了停下来给根因的检查点，模型不会停在『看起来定位了』（验证-2）。
  • 该怎么说：已经不错，可再补一句怀疑层收窄范围：现象同上。我怀疑是 tooltip 的 formatter 把整个对象 toString 成了 [object Object]。先在 KgExtendedModulePane.vue 的图表配置里找 formatter，确认真实根因再来汇报，先别改。
  • 用前→用后：相比第1句的0次调用，这条精准驱动了 8 次调用（Bash×4 Skill×2 Read×2）并锁定 KgExtendedModulePane.vue——证明差别就在补的那句动作+边界。

3.「你确定定位到了真实问题吗」

  • 类型：追问确认
  • 实际发生：3 次调用（Bash×2 Read×1）。读改文件：KgExtendedModulePane.vue。
  • 点评：0 信息追问，模型只能口头答"是"。换成"给我可核对的证据/验收清单"（见话术手册·确保没问题）。

4.「你复现截图放到docs里面我看看」

  • 你这么说：要模型把复现截图放进 docs 给你看——属于操作/验证请求，本质是要可视化证据确认 bug 真实存在。
  • 问题：方向很对（要证据而非口头保证），但指令偏笼统：没说截图放 docs 下哪个具体路径/文件名、要截哪个状态（出问题的 [object] 还是修好后的对比），模型只能自己挑落点和内容，4 次 Bash 里有猜测成分。
  • 实际发生：4 次调用（Bash×4）。
  • 大佬怎么用：大佬验证 UI 会产出截图并和原图对比、列出差异再修（视觉-1）；截图也是带模型一步步走通界面问题的有效抓手（团队-截图）。
  • 依据：让模型『show evidence rather than asserting success』（验证-3）正是把口头『定位到了』变成可核对的产物；但落点不指定会让它多花调用试探目录，给出确切路径能减少来回纠正（具体-2：越精确越少纠正）。
  • 该怎么说：把复现截图存到 docs/ 下，命名 docs/bug-tooltip-object复现.png，截图要清楚显示曲线 tooltip 里的 [object] 这个错误状态；存好后把文件路径贴给我。
  • 用前→用后：本条 4 次调用全是 Bash（截图+存盘），方向正确；若一开始就给定 docs 下的具体文件名和要截的状态，可省掉模型自行决定落点的试探，调用更直达目标。

5.「修改一下吧」

  • 类型：放行
  • 实际发生：20 次调用（Bash×12 Read×5 Write×2 Edit×1）。读改文件：KgExtendedModulePane.vue、knowledge-graph.ts、setup.ts、KgExtendedModulePane.regression-1.test.ts。
  • 点评：纯放行/推进。低风险可保持；若下一步可能是大改，先问"这一步要动哪些文件"再放行（见话术手册·放行）。

本会话小结：本会话三句实质消息里，真正空转的是第1句：同样的现象描述，第1句0次调用（光问『这个可以定位到问题吗』模型只能口头回应），到第2句几乎一字不差但补了『先完全确认真实问题，不要改代码』后立刻驱动8次调用定位。根因就在第1句缺了『先做什么』的指令动作——把疑问句改成『先复现确认再给根因』就能省掉这一轮空转。