Claude Code 深度学习手册

主题

项目五 · 山科 · 学生端 ​

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

6 会话 · 40 条消息 · 驱动 322 次真实调用　|　实质 A=33　放任/操作 B=7　噪声 C=0

会话 1 · 84974ceb（10 轮 · 16 次调用 · 实质 10） ​

1.「现在有make build吗」

  • 你这么说：想知道当前项目有没有现成的 make build 构建入口——属于'探索理解'(摸清现有构建方式)。
  • 问题：只问'有没有make build'，没说为什么问(其实是为了打镜像发布)，也没说目标仓库是学生端。模型只能就字面去查 Makefile，无法顺着真实目标(发布镜像)给出有用路径，导致后面要一条条补。
  • 实际发生：1 次调用（Bash×1）。
  • 大佬怎么用：大佬会把 Claude 当 first stop，先点名让它定位发布相关的入口文件(团队-首站)，而不是孤立问一个命令存不存在。
  • 依据：孤立的碎问句缺少目标语境，模型 infer 不出你的真实意图(具体-1 it can't read your mind)，只能字面应答，后续每条都要再补一次背景，等于反复重建上下文。
  • 该怎么说：把目标一次交底：'我要把学生端前端打成 docker 镜像发给运维。先看 @Makefile @package.json @build.sh，告诉我现在的构建入口(有没有 make build / 现成脚本)，先别执行。'
  • 用前→用后：原话只触发 1 次 Bash 字面查找；带上'发布镜像+学生端'目标后，同一次调用就能让模型沿发布链路返回可用入口，省掉后面 2-3 条碎问。

2.「docker打包镜像现在用的什么」

  • 你这么说：想搞清现在 docker 打包镜像用的是什么方式/配置——'探索理解'。
  • 问题：这条比第1条好：模型自己去 Read 了 Dockerfile、.gitlab-ci.yml 拿到真实配置(3次调用有产出)。缺点仍是没点文件锚点，靠模型自己找'docker用什么'，是它替你猜该读哪些文件。
  • 实际发生：3 次调用（Read×2 Bash×1）。读改文件：Dockerfile、.gitlab-ci.yml。
  • 大佬怎么用：大佬会直接 @Dockerfile @.gitlab-ci.yml 让它读完给现状(具体-3)，而不是用'用的什么'让它自己满仓库找。
  • 依据：用 @ 指名文件能让模型读文件后再回答、少读无关文件(具体-3)；让它自己'找docker用什么'会顺带读一堆无关文件，烧上下文、表现下降(上下文-1)。
  • 该怎么说：'看 @Dockerfile 和 @.gitlab-ci.yml，告诉我现在镜像是怎么 build 的(基础镜像、构建命令、产物目录、tag 规则)，先别改。'
  • 用前→用后：本条已是 3 次有效调用(读到 Dockerfile/.gitlab-ci.yml)；加上 @ 锚点后模型不必先猜该读哪些文件，定位更直、读无关文件更少。

3.「怎么推镜像，然后发给运维同学」

  • 你这么说：想知道怎么把镜像推到仓库、然后怎么交付给运维同学——'探索理解/操作'。
  • 问题：'怎么推镜像，然后发给运维'两件事糊在一句，且没给镜像仓库地址、没说运维要的是镜像名还是文件、没说现有CI是否已自动推。模型缺这些只能泛泛答推送步骤，1次调用难落到你们实际流程。
  • 实际发生：1 次调用（Bash×1）。
  • 大佬怎么用：大佬会把'推哪里'用具体地址/路径点名，而不是'发给运维'这种模糊交付(具体-1、具体-3)。
  • 依据：缺少仓库地址和交付形态，模型无法对齐你们真实流程，只能给通用 docker push 模板(具体-1 不能读心)，你还得再纠偏。
  • 该怎么说：'推送目标仓库是 uhub.service.ucloud.cn/enterprise，运维那边要的是镜像 tag(不是 tar)。给我:1) docker push 的完整命令 2) 怎么生成带时间戳的 tag 3) 发给运维时该附哪些信息。先别执行。'
  • 用前→用后：原话糊成两问只换来 1 次调用、答得通用；拆成带仓库地址+交付形态的清单后，同样调用次数就能给出可直接抄的命令而非模板。

4.「我本地有docker的，我是直接发给运维同学 uhub.service.ucloud.cn/enterprise/qingdian-frontend:20260522133817 . 这样一个东西，你帮我仔细分析我怎么做」

  • 你这么说：交代真实场景(本地有docker、直接把镜像tag发给运维)，让模型帮分析正确做法——'操作/需求'，这条信息量明显补足。
  • 问题：这条是全会话写得最好的一条：补齐了关键事实(本地有docker、交付物是 uhub.service.ucloud.cn/enterprise/qingdian-frontend:20260522133817 这个tag)。若说有缺口，就是没点明这个 qingdian-frontend 是不是学生端仓库——为第9条找错对象埋了伏笔。
  • 实际发生：1 次调用（Bash×1）。
  • 大佬怎么用：大佬给操作任务时正是这样:陈述现状+明确交付物，并指明约束/作用域边界(具体-1 提到 mention constraints)，比如'只产出推送步骤，别动构建配置'。
  • 依据：给了具体 tag 和环境后模型不必再猜交付形态，纠正次数随之下降(具体-2 越精确越少纠偏)。
  • 该怎么说：在原话基础上加锚点和边界:'这个 qingdian-frontend 对应的是学生端仓库吗？先确认仓库再给我:本地 build→tag 成 :20260522133817→push→发运维的完整命令。只产出命令，别改 Dockerfile/CI。'
  • 用前→用后：本条补足现状后理应一击中的，但因没点明'是不是学生端'，到第9条才暴露找错对象——提前加这一句确认，可避免后面 9、10 两条返工。

5.「也不用格式一致，没有文档吗，之前怎么发的呢」

  • 你这么说：想确认有没有发布文档、以前是怎么发的(找历史先例)——'探索理解'。
  • 问题：'也不用格式一致，没有文档吗，之前怎么发的呢'三个半截问句叠在一起，没给应去哪找(README/wiki/CI历史/git log)。模型只能广撒网 Bash×4 去翻，是典型无边界探索。
  • 实际发生：4 次调用（Bash×4）。
  • 大佬怎么用：大佬会把探索范围收窄到具体位置，让 Claude first stop 直接定位文档/历史(团队-首站、具体-3)，而不是'有没有文档'让它满仓库翻。
  • 依据：无边界的'之前怎么发的'会让模型读很多文件去找线索，填满上下文、表现下降(上下文-2 无scope的investigate读上百文件)。
  • 该怎么说：'缩窄找:1) 仓库里有没有 deploy/发布相关 md(看 README、docs/、根目录 *.sh) 2) git log 里上次改 Dockerfile/CI 的 commit 怎么发的。把找到的发布步骤贴给我，没有就说没有。'
  • 用前→用后：原话三连问触发 Bash×4 的广撒网式翻找；给定 README/docs/git log 三个明确落点后，模型直奔目标，不必盲扫一片。

6.「看一下 ./build.sh 这个，是不是我们执行这个就可以」

  • 你这么说：怀疑 ./build.sh 就是发布入口，让模型核对'执行它是不是就行'——'探索理解/操作'，方向对(先看再下结论)。
  • 问题：这条不错:点了具体文件 ./build.sh 让它看(2次调用)。缺口是没说'看完要判断什么'——是判断它能不能直接跑、还是判断它做了哪些事，模型只能笼统读一遍。
  • 实际发生：2 次调用（Bash×2）。
  • 大佬怎么用：大佬会 @build.sh 指名读，并明确要它回答的判定点而非'是不是就行'(具体-3)。
  • 依据：指名文件让模型读后再答(具体-3)；但'是不是就可以'是模糊判定，没给验收点模型只能口头答是/否，缺可核对的依据(验证-2)。
  • 该怎么说：'看 @build.sh，逐行告诉我:它做了哪几步(build/tag/push)？镜像名和 tag 是写死还是传参？我直接执行它能否完成'打包+推送'？缺哪步要我手动补的列出来。'
  • 用前→用后：原话 2 次调用读了脚本但只能给笼统结论；加上'逐行做了什么+缺哪步'的判定清单后，同样的读取能产出可核对的差异列表。

7.「我们只需要执行./build.sh」

  • 你这么说：想确认'我们只需要执行 ./build.sh 就够了'——其实是'确保没问题'式的求确认。
  • 问题：纯陈述句、无任何指令动词，模型不知道要它干什么(核对？执行？),于是 0 调用空转，只能口头回个'是'。这正是形容词式求确认导致的空转。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：大佬要确认某步是否足够时，会让它给可核对的依据而非口头保证(验证-3)，把'是不是只要这一步'变成要它列前置条件。
  • 依据：没有可跑的检查、没有明确动作时，'看起来够了'是唯一信号，你就变成了验证回路本身(验证-2)，模型只能空答。
  • 该怎么说：'核对一下:只执行 ./build.sh 是否覆盖了'登录镜像仓库→build→tag→push'全部环节？逐项给通过/不通过+依据(脚本里第几行)；任何需要我先手动做的(如 docker login)单独列出。'
  • 用前→用后：原话 0 次调用纯空转(模型只能口头答是)；换成带'全环节逐项+依据'的核对指令后，能直接驱动模型回读脚本给出有据结论。

8.「我们只需要执行./build.sh 这个你看看在哪有什么风险不」

  • 你这么说：在'只执行 ./build.sh'前让模型查这么做有什么风险——'确保没问题/审查'。
  • 问题：比第7条好:加了'有什么风险'这个动作，驱动了 1 次调用。但'风险'仍是开放词，没限定看哪类风险(tag冲突？推错仓库？凭证泄露？),模型只能泛泛列。
  • 实际发生：1 次调用（Bash×1）。
  • 大佬怎么用：大佬会把'有什么风险'落成可勾选的检查项要证据(验证-1、验证-3)，而不是开放式问风险。
  • 依据：给模型一个能跑/能核对的检查清单，它才能逐项给证据，而不是凭'看起来'泛答(验证-1、验证-2)。
  • 该怎么说：'执行 ./build.sh 前逐项给风险+依据:1) tag 是否会覆盖线上同名镜像 2) push 目标仓库地址对不对(贴脚本里的地址) 3) 是否需要先 docker login、凭证从哪来 4) 构建是否依赖未提交的本地文件。每项给通过/风险+出处行号。'
  • 用前→用后：原话 1 次调用只能泛列风险；换成 4 项指定风险面+要行号证据后，同样调用能产出可逐条核对的风险清单。

9.「不是这个啊，是我们学生端的吧」

  • 你这么说：纠偏:指出模型看错了对象，目标其实是学生端那个仓库——'排错/纠偏'。
  • 问题：只有一句否定'不是这个啊，是我们学生端的吧'，没给学生端仓库在哪(路径/仓库名)、也没说怎么识别。模型拿不到新线索无从下手，0 调用空转，逼出第10条才补。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：大佬纠偏会在指出错的同时立刻给新定位线索(纠偏-1 一发现跑偏就纠正，但要带具体指向)。
  • 依据：纠偏若只否定不给新锚点，模型没有可执行的下一步，只能停住(具体-1 不能读心)；这正是第9条 0 调用的根因。
  • 该怎么说：'你看错仓库了。学生端是 <仓库路径/目录名，如 ../qingdian-student 或当前 kj-frontend>，对应镜像 qingdian-frontend。去那个仓库看它的 build.sh/Dockerfile，告诉我现状。'
  • 用前→用后：原话 0 次调用空转(纯否定无线索)；补上学生端仓库路径后，模型可立即转向正确目录定位，省掉第10条这次补救。

10.「不是这个啊，是我们学生端的吧，你看看学生端仓库没有吗」

  • 你这么说：在第9条否定后追加'你看看学生端仓库没有吗'，让模型去学生端仓库找——'探索理解/操作'，这次给了动作。
  • 问题：比第9条好:补了明确动作(去学生端仓库找)，驱动 Bash×2+AskUserQuestion×1。缺口是仍没给学生端仓库的确切路径，模型不确定具体位置只能反问(AskUserQuestion)，等于把第9条该给的线索拖到现在还得问。
  • 实际发生：3 次调用（Bash×2 AskUserQuestion×1）。
  • 大佬怎么用：大佬会直接给仓库路径让它读(具体-3)，避免模型反问;探索现状时把它当 first stop 定位文件(团队-首站)。
  • 依据：缺确切路径时模型只能 AskUserQuestion 反问，多一轮往返;给 @路径 可让它读完直接答(具体-3)，省掉反问回合。
  • 该怎么说：'学生端仓库在 <确切路径>。看那里的 build.sh 和 Dockerfile，确认:镜像名是不是 qingdian-frontend、tag 怎么生成、执行哪个脚本能完成打包+推送。先别执行，给我现状。'
  • 用前→用后：原话触发 Bash×2 但还得 AskUserQuestion×1 反问路径;直接给确切仓库路径后可省掉反问那 1 次，模型一轮内读完直答。

本会话小结：本会话是一次'打镜像→推镜像→发给运维'的发布操作摸排。真正空转的是第7条'我们只需要执行./build.sh'(0调用，纯陈述句无指令)和第9条'不是这个啊，是我们学生端的吧'(0调用，只否定没给定位线索)。根因是两句：一是从第1条起就没把关键事实(目标是哪个仓库=学生端、镜像tag uhub.service.ucloud.cn/.../qingdian-frontend、推送方式)一次性交底，让模型从'有没有make build'这种碎问题里反向拼意图；二是第9条发现找错对象时只丢一句否定，逼出第10条补'你看看学生端仓库没有吗'才驱动模型用Bash+AskUserQuestion真正去定位。把目标仓库和镜像tag在第1条就点名，这串问答能从分散摸排压成一两轮。

会话 2 · 49481bf9（3 轮 · 8 次调用 · 实质 3） ​

1.「帮我切换到gitea的private/shanke」

  • 你这么说：想让 Claude 把本地仓库切到 gitea 远程的 private/shanke（操作类）。
  • 问题：缺了关键动词宾语'分支'，'切换到 gitea 的 private/shanke' 既可能是切分支、也可能是切 remote、还可能是 clone/checkout 一个路径；更要命的是没交代 gitea 这个 remote 是否已配置、本地有没有这个分支。信息缺口大到模型无法落地任何一个具体 git 命令，于是 0 次调用空转。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：大佬会用 @文件或点名给全上下文再让它动手（具体-1：can't read your mind，要 reference specific files、mention constraints）。
  • 依据：指令越精确需要的纠正越少（具体-2）；这句省掉的'分支'和 remote 状态正是模型落地命令的必要约束，缺了它模型只能停转或乱猜，反而更费上下文（上下文-1：context 填满则表现下降）。
  • 该怎么说：把本地仓库切到 gitea 这个 remote 的 private/shanke 分支。先 git remote -v 确认 gitea remote 已配（没有就告诉我 URL），再 git fetch gitea 后 git checkout private/shanke，切之前先 git status 确认工作区干净，有未提交改动先停下问我。
  • 用前→用后：原话 0 次调用纯空转；补全'分支'+remote 确认步骤后，模型能直接按 remote -v → fetch → checkout 的清单执行，不用我再补一句才动。

2.「帮我切换到gitea的private/shanke分支」

  • 你这么说：在第 1 句基础上补了'分支'二字，重申让 Claude 切到 gitea 的 private/shanke 分支（操作类）。
  • 问题：只补了'分支'就把空转救活了（5 次调用），说明缺口确实在那个词——这点是好的。但仍没交代 gitea 与 origin 的双仓关系，模型只能就分支论分支地切，为第 3 句的返工埋了雷；中途还触发了 1 次 AskUserQuestion，说明信息仍不足以一次落地。
  • 实际发生：5 次调用（Bash×4 AskUserQuestion×1）。
  • 大佬怎么用：大佬把约束和取舍一次给齐，少来回（具体-2：越精确越少纠正），需要它决策时让它先 interview 而不是边切边问。
  • 依据：AskUserQuestion 出现 1 次 = 模型在执行中途发现信息不够被迫回头问你，每一次往返都在消耗上下文并拉低后续表现（上下文-1）。把仓库拓扑前置能省掉这次打断。
  • 该怎么说：切到 gitea 的 private/shanke 分支。背景：gitea/private/shanke 是开发仓，origin/private/shanke 是线上仓，开发完先推 gitea 再推 origin。这次只做'切到 gitea 开发分支'，别动 origin、别推送，切完贴 git branch -vv 让我确认跟踪关系。
  • 用前→用后：相比第 1 句 0 调用，补'分支'后涨到 5 次调用（Bash×4）能真动手；但因仍漏双仓关系，夹了 1 次 AskUserQuestion 打断——把背景前置可把这次打断也省掉。

3.「你确定是最优方案吗，我们origin的private/shanke是线上的仓库，gitea/private/shanke是我们开发的仓库，正常是gitea/private/shanke开发完之后推送到gitea/private/shanke，然后再推送到们origin的private/shank」

  • 你这么说：质疑前面的切换/推送方案是否最优，并第一次补出 gitea 开发仓→origin 线上仓的双仓推送链路（审查/设计类）。
  • 问题：这句信息其实很关键——把前两轮一直缺的仓库拓扑讲清楚了，方向是对的（先质疑再放行）。缺点是把'确认方案'和'解释背景'混在一句里且无判定标准，模型只能泛泛对比、又触发 1 次 AskUserQuestion，没有一份可勾选的方案让你直接拍板。
  • 实际发生：3 次调用（Bash×2 AskUserQuestion×1）。
  • 大佬怎么用：大佬不让它直接改，而是先要可对比的方案/证据再放行（验证-3：show evidence rather than asserting，把命令和它的输出摆出来）。
  • 依据：没有可勾选的判定项，'看起来是最优'就是唯一信号，你会变成验证回路本身、反复追问（验证-2）；把方案拆成带证据的清单能一次定下来，少耗上下文（上下文-1）。
  • 该怎么说：确认一下推送链路：现在是否会按'gitea/private/shanke 开发 → 推 gitea → 再推 origin/private/shanke 线上'走？给我一份方案：1) 当前在哪个分支、跟踪哪个 remote（贴 git branch -vv）；2) 你计划的推送命令逐条列出；3) 哪一步会碰 origin 线上仓、风险点在哪。我看完再放行，先别推。
  • 用前→用后：这轮 3 次调用（Bash×2）+1 次 AskUserQuestion，仍在边问边核；改成上面的可勾选方案清单，模型可一次性给出 branch -vv + 推送命令 + 风险点，你直接拍板，省掉来回追问。

本会话小结：三轮里第 1 句完全空转（0 次调用）：'切换到 gitea 的 private/shanke' 漏了关键词'分支'+没说远程是否已配，模型读不出意图就停在原地；补一个字'分支'后第 2 句立刻驱动 5 次调用。真正的根因是第 1 句把'gitea remote 与 origin remote 的双仓推送关系'这个上下文全憋着没讲——直到第 3 句质疑时才补出来，导致前两轮模型只能在不完整的仓库拓扑上瞎切，第 3 句不得不返工纠偏。一句话把双仓关系和'切分支'前置，前两轮可省掉返工。

会话 3 · 05013480（3 轮 · 22 次调用 · 实质 2） ​

1.「你确定是你真的定位到的问题，有真实论证的」

  • 你这么说：质疑模型前面的定位是否站得住脚、有没有真实论证（审查/确保没问题）。
  • 问题：用"你确定""有真实论证"这种形容词追问，没给可判定的标准：要它拿什么当证据？是日志、报错栈、还是复现命令？模型只能再泛泛复述自己的推理或口头答"确定"，无法自证，于是你只能继续不放心。
  • 实际发生：4 次调用（Bash×4）。
  • 大佬怎么用：大佬不会问"你确定吗"，而是让模型拿出可核对的证据：跑过的命令+返回、复现脚本、截图（验证-3）；定位类问题先写一个能复现的失败测试再下结论（症状-1）。
  • 依据：没有可跑的检查时"看起来对"就是模型唯一的信号，你本人就变成了验证回路（验证-2）；要它show evidence而非assert success，才能跳出反复追问（验证-3）。
  • 该怎么说：别口头答"确定"。把你这次定位问题的依据逐条贴出来：1) 你跑了哪条命令、原始返回是什么；2) 定位到哪个文件的哪一行/哪个字段、它如何对应这个现象；3) 给一段能复现该 bug 的最小步骤或失败用例。我看证据再决定信不信。
  • 用前→用后：原话驱动了 4 次 Bash，但产出的是模型继续自证式排查；换成"逐条贴命令+返回+复现步骤"后，这 4 次调用会直接落成可核对的证据链，你不用再追第二遍。

2.「可以」

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

3.「现在没有问题了是吧，可以推送到git了吗」

  • 你这么说：确认问题已修复、想放行推送到 git（确保没问题 + 放行操作）。
  • 问题：把"没问题了吧"和"可以推送了吗"绑在一起一句话问，但没给"没问题"的判定口径，模型无法独立断定，只能反过来问你（本轮触发 3 次 AskUserQuestion 往回要信息），推送动作也卡在确认环节空耗。
  • 实际发生：7 次调用（Bash×4 AskUserQuestion×3）。
  • 大佬怎么用：大佬推送前先要一份可核对的收尾证据：type-check/测试结果、改了哪些文件、还有哪些需要人工点（验证-1）；能跑的检查通过了才 ship，验证不了就不推（验证-4）。
  • 依据："没问题了吧"没有可跑的检查，模型只能用"看起来完成"当信号并把判断踢回给你（验证-2）；提供可跑验证、过了才推送，是trust-then-verify gap的标准修法（验证-4）。
  • 该怎么说：推送前先逐项给"通过/不通过+证据"，别再反问我：1) app.tsx/request.ts/index.tsx 的改动各解决了什么、跑没跑通；2) 贴 type-check 和构建/测试结果原文；3) 列出你没法自动验证、需要我手点的项。这三项都通过了再推 git，否则先停。
  • 用前→用后：原话引发 3 次 AskUserQuestion 把决策踢回给你、推送悬空；换成"逐项给通过/不通过+证据，过了再推"后，那 7 次调用会用来产出可核对的收尾清单，一次就能拍板推不推。

本会话小结：这会话三句都驱动了真实调用（1=4次、2=11次、3=7次），没有纯空转的句子。根因隐患在第1、3条：两条都是"你确定真定位到了吗""现在没问题了吧能推送吗"式的口头追问，没给可勾选的判定标准和证据要求，模型只能靠自评和反问（第3条触发3次AskUserQuestion往回要信息），属于把用户自己变成验证回路。换成带证据清单的说法即可一次收口。

会话 4 · 2da5b60a（6 轮 · 79 次调用 · 实质 5） ​

1.「学生的测试环境是https://test-hb.zhipuai-infra.cn/edu-student-frontend/ 教师端的测试环境是https://test-hb.zhipuai-infra.cn/edu-frontend/ 现在我我发现如果登陆了教师端，我再去访问学生端就回一直反复跳转， 看下是不是加个逻辑，接口401的时候清理下token，跳转登录页重新登录吧。这样是不是可以解决，先定位问题」

  • 你这么说：排错：教师端登录后访问学生端反复跳转，给了两端测试 URL + 自己的怀疑（401 时清 token 跳登录页），要求先定位问题。
  • 问题：这条其实写得相当好：报了具体现象（反复跳转）、给了两个可访问的环境锚点 URL、提了自己的怀疑层（401 处理 token），还明确'先定位问题'而非直接改。唯一小缺口是没指明怀疑落在哪个文件/哪一层（token 存储 vs 拦截器 vs 路由守卫），模型只能自己从 app.tsx 一路读到 token.ts/auth.ts/storage.ts/apiRequest.ts。
  • 实际发生：16 次调用（Read×7 Bash×5 Edit×2 Skill×1 ToolSearch×1）。读改文件：app.tsx、token.ts、auth.ts、storage.ts、apiRequest.ts、appConfig.ts、user.ts。
  • 大佬怎么用：大佬报 bug 会给症状 + likely location + 先复现，如'login fails after session timeout, check the auth flow in src/auth/'（症状-1）；并把 stack trace/真实请求喂进去追控制流（团队-排错）。
  • 依据：给了现象+怀疑层，模型能直接顺着控制流定位，不用满仓库 grep 填满上下文（上下文-2）；环境 URL 让它能实证而非猜（验证-1）。
  • 该怎么说：现象：教师端 edu-frontend 登录后再访问学生端 edu-student-frontend 反复跳转。我怀疑是两端共用了同一份 token 存储、学生端拿到教师端 token 后 401 又没清。先在 apiRequest.ts 的响应拦截器和 token.ts 的存取处打日志，抓一次真实 401 请求确认到底是哪一步没清 token，给我根因再动手，先别改 401 清 token 的逻辑。
  • 用前→用后：本条 16 次调用（Read×7 Bash×5 Edit×2 Skill×1 ToolSearch×1）已能直接命中 token/auth/storage 链路，说明开局给现象+怀疑确实有效；若再补上'怀疑在 apiRequest.ts 拦截器'这一锚点，可省掉前几次 Read 的探路。

2.「继续」

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

3.「Review target: '审查一下，确保本次的是最优方案，没有破坏其他任何正常功能' 'xhigh effort → 5 angles × 8 candidates → 1-vote verify → sweep → ≤15 findings' You are reviewing for recall at extra-high effort: catch every real bug. At this level, catching real bugs matters more than avoiding false positives — a missed bug ships. Err on the side of surfacing. ## Phase 0 — Gather the diff Run 'git diff @{upstream}...HEAD' (or 'git diff main...HEAD' / 'git diff HEAD~1' if there's no upstream) to get the unified diff under review. If there are uncommitted changes, or the range diff is empty, also run 'git diff HEAD' and i …（后略）」

  • 你这么说：确保没问题/审查：要求审查本次改动确保是最优方案、没破坏其他正常功能，并贴了一大段 xhigh-effort 的通用 review 流程指令。
  • 问题：'最优方案''没破坏其他任何正常功能'是形容词验收，没有可勾选标准；加上贴的那段通用 review 模板（5 angles×8 candidates×sweep）是脱离本 bug 的泛化流程，于是模型跑了 5 个 Agent 子任务做大范围扫描，偏离了'反复跳转'这一个具体症状——下一条用户不得不把方向拉回'定位真实问题'。
  • 实际发生：11 次调用（Agent×5 Bash×4 Read×2）。读改文件：SiderFooter.tsx、app.tsx。
  • 大佬怎么用：大佬验收会给可跑的检查而非口头保证（验证-1、验证-3：show evidence——测试输出/命令返回/截图，而不是断言成功）。
  • 依据：没有可跑的检查，'看起来完成'就是唯一信号，你会变成验证回路本身（验证-2）；而抽象的全量审查指令会让它读一片无关代码、把上下文搞脏、表现下降（上下文-1）。
  • 该怎么说：只针对这次跳转修复逐项给'通过/不通过+证据'，别做全仓库泛化审查：1) 教师端登录→访问学生端，401 时是否确实清了 token 并跳登录页（贴抓到的请求）；2) 学生端正常登录流程是否照旧不受影响；3) token.ts/auth.ts 的改动有没有影响教师端自己的 token 读取。最后贴 type-check 结果；你没法在本地复现、需要我去两个环境手点验证的列出来。
  • 用前→用后：本条 11 次调用里 Agent×5 被这段通用 review 指令带去做发散扫描，只 Read×2，没收敛到 bug；换成上面的三点清单+要证据，能让这 5 次 Agent 调用聚焦到'跳转修复是否成立'，避免第4条再返工拉回方向。

4.「我需要你定位到真实的问题，给出最优修复方案」

  • 你这么说：排错：把方向从泛化审查拉回，要求定位到真实问题并给出最优修复方案。
  • 问题：这是对第3条发散的纠偏，方向正确但仍偏笼统——'真实问题''最优修复'没说判定标准也没给怀疑层，模型这轮跑了 8 次 Bash + 2 个 Agent 还得用 AskUserQuestion 反问用户（说明它信息不够、要用户补判定身份的接口），等于把缺的上下文又退回给你。
  • 实际发生：12 次调用（Bash×8 Agent×2 Read×1 AskUserQuestion×1）。读改文件：app.tsx。
  • 大佬怎么用：大佬纠偏会立刻给更尖的线索而不是重复同一句模糊指令；纠正超过两次就 /clear 带更具体的 prompt 重开（纠偏-2）。
  • 依据：重复'定位真实问题'不补线索，模型只能继续 grep/Bash 大海捞针并反问（上下文-2）；给一个怀疑落点能把搜索收敛、减少来回（具体-2：越精确纠正越少）。
  • 该怎么说：真实问题应该是两端身份判定共用了同一 token。请抓 userInfo 接口的返回，确认学生端用教师端 token 调时返回的角色/权限对不上才被踢，定位是哪段路由守卫或权限判断导致循环跳转。把根因（具体到文件+行）给我，再给修复方案，别直接全改。
  • 用前→用后：本条 12 次调用还触发了 AskUserQuestion×1（模型反过来问你判定身份在哪），说明指令缺怀疑落点；按上面把怀疑指向 userInfo 接口+token 共用，可免掉这次反问，直接驱动定位。

5.「我不记得有判定身份的啊，在哪个接口可能会有curl 'https://test-hb.zhipuai-infra.cn/edu-frontend/edu-api/sys/user/userInfo' \ -H 'Accept: application/json, text/plain, /' \ -H 'Accept-Language: zh-CN,zh;q=0.9' \ -H 'Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJ0ZW5hbnRfaWQiOjExNCwidXNlcl9pZCI6NzYsInVzZXJfbmFtZSI6Im1zaHMiLCJwZXJtaXNzaW9ucyI6IntcInN0dWR5XCI6W1wibGVhcm5pbmdBbmFseXNpc1wiLFwiY291cnNlXCIsXCJteVRhc2tzXCJdfSIsImRhdGFfc2NvcGUiOiJbe1wiZGVwdElkXCI6MjQyLFwiZGVwdE5hbWVQYXRoXCI6XCLlpI3ml6blpKflraYv6K6h566X5py65a2m6ZmiL-i9r-S7tuW3peeoiy8yMDIw57qnL-i9r-S7tuW3peeoi-S6jOePrVwiLFwiZGVwdFBhdGhcIjpcIjAsMTI0LDEyO …（后略）」

  • 你这么说：探索理解/排错：回应模型反问，说自己不记得有身份判定逻辑，问在哪个接口，并贴了一条真实的 userInfo 接口 curl（带 Authorization token）。
  • 问题：好的地方：贴了可直接复跑的真实 curl + token，模型能拿到真实接口数据而非靠猜。缺口：'我不记得有判定身份的'是把记忆缺口抛给模型，没指明让它去哪个文件确认（如哪段读 userInfo 后做角色分流），所以这条只产生 1 次 Bash——基本是模型跑了一下 curl，没驱动深入定位。
  • 实际发生：1 次调用（Bash×1）。
  • 大佬怎么用：大佬把真实请求/输出喂给 Claude 追控制流（团队-排错）；并让 Claude 当 first stop 先点出该看哪个文件（团队-首站）。
  • 依据：贴真实 curl=给可实证的数据，比形容描述强（验证-3）；但只给 curl 不给文件锚点，模型不知道顺着哪段代码查身份判定，容易停在'跑一次接口'（具体-3：用 @文件 直接定位胜过描述位置）。
  • 该怎么说：这是 userInfo 的真实返回（curl 已贴）。我不记得前端哪里用它做身份/角色判定——你去 @src/.../user.ts 和路由守卫里搜一下哪里读了这个 userInfo 的 permissions/data_scope 字段做分流，给我现状先别改，确认是不是它在学生端把教师身份判成无权限才循环跳转。
  • 用前→用后：本条仅 1 次调用（Bash×1），基本是跑了下 curl 就停；补上'去 user.ts/路由守卫搜 userInfo 的 permissions 字段'这个文件锚点，能把这 1 次空跑变成直接定位身份判定代码。

6.「"eyJhbGciOiJIUzUxMiJ9.eyJ0ZW5hbnRfaWQiOjExNCwidXNlcl9pZCI6NzgsInVzZXJfbmFtZSI6ImtpbmciLCJwZXJtaXNzaW9ucyI6IntcImVkdWNhdGlvblwiOltcIlNtYXJ0VGVhY2hpbmdcIixcIlJlc291cmNlQ2VudGVyXCIsXCJNeVdvcmtzcGFjZVwiLFwic3lzOnNraWxscG9pbnQ6bGlzdFwiLFwic2tpbGxwb2ludC5hZGRwcm9mZXNzaW9uYWxcIixcInN5czpza2lsbHBvaW50Omxpc3RcIixcInNraWxscG9pbnQuYWRkZ2VuZXJhbFwiLFwic2tpbGxwb2ludC5lZGl0XCIsXCJza2lsbHBvaW50LmRlbGV0ZVwiLFwicHJvZmVzc2lvbmFsLnBvc3RlZGl0XCIsXCJwcm9mZXNzaW9uYWwucG9zdHNwZWN0cnVtdmlld1wiLFwicHJvZmVzc2lvbmFsLm1hdGVyaWFsZGVsZXRlXCIsXCJwcm9mZXNzaW9uYWwubWF0ZXJpYWx2aWV3XCIsXCJwcm9mZXNzaW9uYWwuc3BlY3RydW12aWV3XCIsXC …（后略）」

  • 你这么说：排错/操作：再贴一条不同用户（king）的 token，让模型对比/验证两端 token 在身份判定上的差异并落地修复。
  • 问题：提供了第二份对照 token（教师端 king）是好的——给了对比样本能验证'同 token 在两端身份判定不同'的假设。缺口是这条只甩了 token、没写要它对比什么、要不要落修复、改完怎么验，模型只能自己理解意图，于是一口气跑了 31 次调用、改了 token.ts/user.ts/auth.ts/app.tsx/SiderFooter.tsx 五个文件——大改但你没设边界也没要证据。
  • 实际发生：31 次调用（Bash×18 Edit×9 Read×3 Skill×1）。读改文件：token.ts、user.ts、auth.ts、app.tsx、SiderFooter.tsx。
  • 大佬怎么用：大佬给对照数据时会说明用它验证什么 + 给可跑的检查（验证-1）；多文件修改前先看计划再放行（计划-2：改动跨多文件时最该规划）。
  • 依据：甩 token 不划边界+不要证据，模型会自行发散改一片，跨 5 文件无验证锚=trust-then-verify gap，一步跑偏顺错方向改一片（验证-4、计划-2）。
  • 该怎么说：这是教师 king 的 token，用它和上一条学生 token 对比 permissions/data_scope 结构差异，确认学生端是按哪个字段判身份才误踢。改之前先列：要改哪几个文件、各自改什么、有没有动 token.ts 这种公共逻辑，我看完再放行。改完贴：两个 token 分别走学生端的预期跳转结果 + type-check。
  • 用前→用后：本条 31 次调用、Edit×9 跨 token.ts/user.ts/auth.ts/app.tsx/SiderFooter.tsx 五个文件无验证锚就大改；换成'先列改动清单等我放行+改完贴两 token 验证结果'，能把这次无边界发散收成可控的看计划→改→验证。

本会话小结：全程 79 次调用里基本都在跑实事，没有明显空转——第1条给了两个测试环境 URL + 现象（教师端登录后访问学生端反复跳转）+ 自己的怀疑层（401 时清 token 跳登录），属于高质量排错开局，16 次调用直接定位到 token/auth/storage 一串文件。真正的弯路在第3条和第6条：第3条用一大段抽象的 review 指令（5 angles×8 candidates 那套）让模型跑了 5 个 Agent 子任务做泛化审查，偏离了具体 bug；导致第4条用户又得把方向拉回'定位真实问题'。根因是第3条'确保最优方案没破坏其他功能'缺少可勾选清单和验证锚——把审查变成了发散，而不是针对'反复跳转'这一个症状收敛。

会话 5 · aac0db2e（11 轮 · 155 次调用 · 实质 7） ​

1.「docs/image.png 这个是批量上传在哪里使用了，我记得有好几处使用了，调用了什么接口」

  • 你这么说：想搞清楚「批量上传题目」这个能力在前端哪几处用到、各自调了什么接口——属于探索/理解现状。
  • 问题：方向是对的（先理解再动手），但只给了一张 docs/image.png 截图 + 「我记得有好几处」这种模糊记忆，没点名哪些页面/组件，模型只能满仓库找入口，所以一上来 Read×7 Bash×6 共 13 次调用大海捞针式定位。
  • 实际发生：13 次调用（Read×7 Bash×6）。读改文件：image.png、ExamEditor.tsx、OnlineAnswerAssignment.tsx、index.ts。
  • 大佬怎么用：大佬会把已知的文件/组件路径用 @ 直接喂给它当 first stop，让它先定位再答（具体-3、团队-首站）。
  • 依据：让自己找文件=要读一堆无关文件才命中入口，上下文窗口很快被填满、表现随之下降（上下文-1）。
  • 该怎么说：把模糊记忆换成锚点：「@docs/image.png 这个批量上传/题目导入能力，先在 src 里搜出所有调用入口（组件名+所在文件），列成表：每处用在哪个页面、调了哪个接口（方法+URL）。先只给现状清单，别改代码。」
  • 用前→用后：原说法 13 次调用里大半花在猜入口（Bash×6 搜+Read×7 翻）；点名 @文件+只要清单后，能省掉搜入口的空读，直接出「页面→接口」对照表。

2.「批量上传倒入题目，你确定只有两处用了吗」

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

3.「之前的接口调用错了，我们需要根据 @2026-05-26-题库导入前端对接文档.md 更正一下。你先仔细分析现在的代码和接口文档，看看如何更正，有任何疑问直接问我，完全清楚之后再开始改代码」

  • 你这么说：发现之前接口对接错了，要求依据 @2026-05-26-题库导入前端对接文档.md 先分析现状与文档差异、有疑问先问、完全清楚再改——属于需求/设计（带纠错）。
  • 问题：这条写得相当好：给了权威依据文件(@对接文档)、明确「先分析再改」「有疑问直接问我」「清楚之后再开始」，等于手动开了 plan+采访的节奏，所以 40 次调用里出现了 AskUserQuestion×1（它真去问了），Edit×10 是确认后才动的手，没盲改。
  • 实际发生：40 次调用（Read×16 Bash×12 Edit×10 AskUserQuestion×1 Write×1）。读改文件：2026-05-26-题库导入前端对接文档.md、index.ts、index.tsx、ExamEditor.tsx、PracticeImportModal.tsx。
  • 大佬怎么用：大佬正是这么做：多文件改动先分离探索与执行，让 Claude 先看计划/提问、确认后再写代码（计划-1、采访-1）。
  • 依据：改动跨多文件且涉及不熟的接口契约时，先理解再执行能避免「解决错问题」；让它先提问把边界前置，比看它一路改完再返工省上下文（计划-2、采访-1）。
  • 该怎么说：已经很好，保持。可再加一条收口标准：「分析完先给我一份对照表：每个接口『文档要求 vs 现状代码』差在哪、要改哪个文件哪一行；这表我确认后你再开始改，改完贴 type-check 结果。」
  • 用前→用后：这条的「先分析+有疑问就问」直接换来了 AskUserQuestion×1 的真实提问和 Edit×10 的确认后修改，是本会话最健康的一条——对照盲放式的「直接改」，它没跑偏成一片错改。

4.「最优的方案是什么呢，你确定是按照接口文件对接的是吧」

  • 类型：追问确认
  • 实际发生：36 次调用（Bash×11 Edit×11 Read×9 Write×3 AskUserQuestion×2）。读改文件：app.tsx、ExamEditor.tsx、question.ts、OnlineAnswerAssignment.tsx、index.tsx、index.ts、b4t6tp2kw.output、prefers-optimal-over-minimal.md、MEMORY.md。
  • 点评：0 信息追问，模型只能口头答"是"。换成"给我可核对的证据/验收清单"（见话术手册·确保没问题）。

5.「帮我再完整审查一遍整体流程。确保没有任何问题，没有破坏其他任何正常功能」

  • 你这么说：要求完整复查整体流程，确保没问题、没破坏其他正常功能——属于确保没问题（验收）。
  • 问题：「确保没有任何问题」「没破坏其他功能」是形容词验收，没有判定标准和清单，模型只能泛泛自评。这次它靠自觉起了 Agent×1 帮审，但 15 次调用里没有可跑的检查结果作为硬证据，「没破坏其他功能」实际无从验证。
  • 实际发生：15 次调用（Bash×6 Read×4 Edit×4 Agent×1）。读改文件：OnlineAnswerAssignment.tsx、index.tsx、ExamEditor.tsx。
  • 大佬怎么用：大佬会给一个能跑的检查（测试/build/截图）+ 让它逐项摆证据而不是断言成功（验证-1、验证-3）。
  • 依据：没有可跑的检查，「看起来完成」就是模型唯一的信号，你自己就变成了验证回路；只口头确保不给证据 = trust-then-verify gap（验证-2、验证-4）。
  • 该怎么说：换成可勾选清单+要证据：「逐项给『通过/不通过+证据』，别给评价：1) 题库导入主流程端到端是否走通；2) 边界：空文件/格式错/重复题是否不崩；3) 本次改动的几个组件是否复用同一套导入逻辑、有无不一致。最后贴 pnpm tsc / lint 输出；你没法自动验证、需要我手点的页面列出来。」
  • 用前→用后：原说法 15 次调用产出的是「我已检查、没问题」式自评；给清单+要 type-check 输出后，同样的调用会换成逐项通过/不通过的硬证据，「没破坏其他功能」从口头变可核对。

6.「教师端是不是也帮我增加一下刚刚学生端加的来回跳的处理，需要吗」

  • 你这么说：问教师端要不要也加上刚给学生端做的「来回跳转」处理，并让 Claude 判断需不需要——属于需求（带决策征询）。
  • 问题：「刚刚学生端加的来回跳的处理」靠的是上文记忆指代，没点明那是哪个文件/哪段逻辑（本轮实际触及 app.tsx/User.tsx/token.ts/auth.ts 的鉴权跳转）；「需要吗」把判断也交给模型。它得先重新定位那段改动，所以 Read×6 找+Edit×10 改，共 23 次调用。
  • 实际发生：23 次调用（Edit×10 Bash×6 Read×6 AskUserQuestion×1）。读改文件：app.tsx、User.tsx、token.ts、auth.ts。
  • 大佬怎么用：大佬会把「刚加的那段」用 @文件+函数名点名，并让它先给『教师端是否存在同样问题』的判定再决定改不改（具体-3、团队-首站）。
  • 依据：用「刚刚那个」做指代，模型要回溯上下文重新找代码，等于二次发散读文件、烧上下文（上下文-1）；先判定再动手能避免无谓修改。
  • 该怎么说：点名+先判定后动手：「学生端来回跳的处理改在 app.tsx 的鉴权重定向逻辑（token.ts/auth.ts 那套）。先只回答：教师端 app.tsx 是否有同样的循环跳转风险？给『有/无+证据(贴对应代码)』。确认有，再改，并告诉我改哪几个文件。」
  • 用前→用后：原说法因指代模糊，23 次调用里 Read×6 先花在重新定位那段改动；点名文件+先判定后，能跳过这段回溯，把动作收敛到教师端对应文件。

7.「Continue from where you left off.」

  • 你这么说：想让 Claude 接着上次中断处继续干——属于放行/操作（断点续传）。
  • 问题：「Continue from where you left off.」没说续到哪一步、下一步该改哪个文件，模型缺少任何可执行落点，所以 0 次调用纯空转。这是本会话两处空转之一。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：大佬交接续传会点名下一步动作和目标文件，而不是靠模型自己回忆进度（具体-1）。
  • 依据：「继续」本身不含指令，模型只能复述上文或停下；上下文越长它越难自动定位「上次到哪」，「看起来该继续」不是可执行信号（具体-1、上下文-1）。
  • 该怎么说：把『继续』换成明确落点：「接着改：下一步是把 教师端 ExamEditor.tsx 的导入接口按对接文档更正（上一步刚改完学生端 index.tsx）。先列这一步要动的文件清单给我，再开始。」
  • 用前→用后：原说法 0 次调用空转；补上「下一步改哪个文件+刚做完什么」后，模型能直接接力动手而不是停在原地等指令。

8.「继续吧」

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

9.「Review target: '审查工作区代码，确保我们本次工作区修改的全部代码都是最优方案，质量都是最好的，考虑了所有的边界情况' 'xhigh effort → 5 angles × 8 candidates → 1-vote verify → sweep → ≤15 findings' You are reviewing for recall at extra-high effort: catch every real bug. At this level, catching real bugs matters more than avoiding false positives — a missed bug ships. Err on the side of surfacing. ## Phase 0 — Gather the diff Run 'git diff @{upstream}...HEAD' (or 'git diff main...HEAD' / 'git diff HEAD~1' if there's no upstream) to get the unified diff under review. If there are uncommitted changes, or the range diff is empty, also run …（后略）」

  • 你这么说：贴入一段结构化的 xhigh-effort 代码审查指令（5 角度×8 候选、≤15 findings），要求审查工作区本次改动是否最优、是否覆盖边界——属于审查（确保没问题的强化版）。
  • 问题：这条很好：不再是形容词「确保没问题」，而是给了可执行的审查协议（先 git diff 取改动范围、按角度扫、限定 findings 数、用子 agent），所以 18 次调用里 Agent×6 真的并行去审了，没空转。唯一可加强的是没指定「发现后是否就地改」的边界。
  • 实际发生：18 次调用（Agent×6 Edit×5 Read×4 Bash×3）。读改文件：index.tsx。
  • 大佬怎么用：大佬正是用子 agent 范围化审查（而非让主线无边界 investigate），并要每条 finding 摆证据（上下文-2、验证-3）。
  • 依据：给了明确范围(git diff)和角度，审查不会变成读上百文件的无边界 investigate；用 subagent 分担还能省主线上下文（上下文-2）。
  • 该怎么说：已经很好，保持。补一句收口：「每条 finding 给『文件:行 + 为什么是真问题 + 修法』，并标注严重级；先只输出清单别动代码，我挑完你再改。」（控制它别审完顺手大改）
  • 用前→用后：对照纯形容词审查会 0 调用空转，这条结构化协议直接驱动 Agent×6 并行审 + Edit×5 落地修复，是高效审查的范例。

10.「你确定这些都是真实必须修复的吗」

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

11.「可以，要没有任何风险，因为我要推送git了」

  • 你这么说：在审查后放行修复、明确「要没有任何风险，因为我要推送 git 了」——属于放行（高风险节点前的最终确认）。
  • 问题：「要没有任何风险」是形容词放行，没给可勾选的上线前清单；推 git 是高风险节点，但只口头要求「没风险」，模型只能凭感觉收尾。这次落地较小（Edit×2 Bash×2 共 4 次），但「无风险」无证据支撑。
  • 实际发生：4 次调用（Edit×2 Bash×2）。读改文件：index.tsx。
  • 大佬怎么用：大佬在 ship 前会让它跑能跑的检查并摆证据，而不是接受口头「没风险」（验证-1、验证-4）。
  • 依据：没有可跑的上线前检查，「看起来没问题」就是唯一信号，推上去的风险全压在你身上（验证-2、验证-4）。
  • 该怎么说：把『要没有任何风险』换成上线前清单：「推 git 前给我：1) pnpm tsc 与 lint 全绿的输出；2) 本次改动文件清单 + 各自一句话改了什么；3) 还有哪些没法自动验证、需我手点确认的点。全绿且我确认后再让我推。」
  • 用前→用后：原说法 4 次调用基本是收尾小改，「无风险」无证据；换成要 tsc/lint 输出+改动清单后，推送前能有可核对的绿色证据而非口头保证。

本会话小结：这会真正空转的是第7条「Continue from where you left off」和第10条「你确定这些都是真实必须修复的吗」——各 0 次调用，纯口头交接/口头质疑，没驱动任何操作。根因是两类话：一是断点续传式的「继续」没带「续到哪、下一步改哪个文件」，模型只能复述；二是审查后用「你确定吗」这种形容词追问，没要可勾选证据，模型只能口头答「是」。相比之下第1/3/5/6/9/11 条都给了文件锚点(@文档)或可执行审查指令，调用数 4~40 不等，方向对、能驱动落地。

会话 6 · 15033840（7 轮 · 42 次调用 · 实质 6） ​

1.「POST /student/wrong_book/lecture_tasks Content-Type: application/json { "knowledgePointIds": [ "2041409940630798336", "2058735126958833664" ], "forceGenerate": true } 这个接口在点击重新生成被调用时，需要加上 "forceGenerate": true参数 POST /edu-ai-platform/student/wrong_book/lecture_tasks 请求体加： { "knowledgePointIds": [ "2041409940630798336", "2058735126958833664" ], "forceGenerate": true } 重点是 forceGenerate: true，必须放在 JSON body 里，不是 query 参数。这个接口看一下哪里调用了，可以修改吗，有没有什么风险」

  • 你这么说：要求给 forceGenerate:true 接口（POST /student/wrong_book/lecture_tasks）的调用点加上该参数并放进 JSON body，同时排查调用处、评估可改性与风险。归类：需求 + 探索。
  • 问题：这条其实写得相当好：给了完整接口路径、字段名、字段值、明确约束（必须在 body 不是 query），还点名了诉求（看哪里调用、能否改、有何风险）。模型不需要猜意图。唯一可再加锚的是没点出文件路径，但接口名已足够定位。
  • 实际发生：8 次调用（Bash×4 Read×4）。读改文件：index.ts、wrongQuestionBook.ts、index.tsx。
  • 大佬怎么用：大佬同样会把约束写死并要求先定位再改（具体-1：reference specific files, mention constraints；团队-首站：Claude 先 identify which files to examine）。
  • 依据：把字段、值、放置位置（body 非 query）一次性钉死，模型一次就能命中正确改法，减少来回纠正（具体-2：越精确越少纠正）；先问「哪里调用、有何风险」相当于先定位再动手，避免盲改（团队-首站）。
  • 该怎么说：已经够好，保持即可。若再优化可补文件锚：先看 @src 下封装 lecture_tasks 的 request 函数和触发「重新生成」的按钮组件，给我现状（哪几处调用、参数现在怎么传），确认后再在 body 加 forceGenerate:true，列出受影响文件和风险，先别动公共封装。
  • 用前→用后：本条本身就有效：8次调用（Bash×4 Read×4）直接读改了 index.ts、wrongQuestionBook.ts、index.tsx，没有空转——是本会话三条有效输入之一。

2.「这个是后端告诉我的，有疑问吗还」

  • 你这么说：回应模型对后端改法的质疑，强调「这是后端给的，照做即可」，催促落实改动。归类：操作/放行（确认按既定方案执行）。
  • 问题：「有疑问吗还」是反问句、没给任何新约束或验收口径，把方向判断完全压给模型。它无法知道你要的是「停止质疑直接改」还是「解释为何照做」，只能凭语气推断。好在第1条约束足够清晰，模型仍能继续推进。
  • 实际发生：11 次调用（Edit×5 Bash×4 ScheduleWakeup×1 ToolSearch×1）。读改文件：index.ts、wrongQuestionBook.ts、index.tsx。
  • 大佬怎么用：大佬放行照做时会同时划清边界（具体-1：reference specific files, mention constraints）：明确只动接口参数那一处、别顺手碰公共封装。
  • 依据：无边界的「照做」会让模型自行扩散改动面，把上下文越填越满、表现下降（上下文-1：context window fills up fast, performance degrades）；给一句「只改这一处、别动封装」能锁定动作面。
  • 该怎么说：对，就是后端确认过的，照这个改。只在调用 lecture_tasks 的那一处 body 里加 forceGenerate:true，不要改 request 公共封装、不要顺手动其它接口；改完把 diff 贴给我。
  • 用前→用后：本条驱动了11次调用（Edit×5 Bash×4 等），完成了 index.ts/wrongQuestionBook.ts/index.tsx 的改动，没有空转；若当时加了边界，可避免后续第6/7条对「有没有多改」的反复追问。

3.「# Autonomous loop check You're being invoked on a timer while the user is away or occupied. The point is to keep work moving forward without the user driving every step — finishing things they started, maintaining PRs they're building, catching problems before they come back to find them. You're a steward, not an initiator. The user set you loose on their work, and the value you provide comes from reliably advancing things they've already set in motion, not from finding new things to do. The key tension to navigate: the user trusts you enough to run autonomously, but that trust is easily los …（后略）」

  • 你这么说：并非用户真实意图——这是误粘进会话的 autonomous-loop 系统提示词（定时自动巡检的角色说明），与本接口任务无关。归类：噪声/误投放。
  • 问题：整段是给「定时自动跑」agent 的角色设定，没有任何针对本仓库的可执行指令，也没有要改的目标。模型无从落到任何动作，自然0调用。它和当前接口改动任务完全无关，纯属污染上下文。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：大佬发现粘错/跑偏会立刻清场重来，而不是让无关长文留在上下文里（纠偏-2：纠偏超两次就 /clear 带更具体的 prompt 重开）。
  • 依据：无关长文本一旦进上下文就持续占用窗口、稀释有效信息，导致后续表现下降（上下文-1：context fills up fast, performance degrades）；及时 /clear 能把窗口让给真正的任务。
  • 该怎么说：（这段粘错了，忽略。）继续上面的接口改动：把 forceGenerate:true 加进 lecture_tasks 调用的 body，改完贴 diff。若误投内容已污染上下文，直接 /clear 后用一句话重述本任务重开。
  • 用前→用后：原本0次调用纯空转（且占用上下文）；识别为误投并 /clear 重述后，上下文回到只含接口任务，模型能继续驱动改动而不被无关角色设定干扰。

4.「确定没有任何问题是吗」

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

5.「再帮我仔细审查一下，是否完全处理好了」

  • 你这么说：要求再次仔细审查改动是否「完全处理好了」。归类：审查/确保没问题。
  • 问题：「仔细审查」「完全处理好了」是形容词式验收，没给判定标准——审什么点、什么算「处理好」都没说。模型只能泛泛自查，靠运气覆盖到你担心的点。本条好在它触发了实证（读 index.tsx、utils.ts），但下一句「完全」「没破坏」之类的追问就退化成口头答「是」了。
  • 实际发生：8 次调用（Bash×6 Read×2）。读改文件：index.tsx、utils.ts。
  • 大佬怎么用：大佬会给可跑的检查并要证据，而不是要一句「审查过了」（验证-1：give Claude a check it can run；验证-3：show evidence rather than asserting success）。
  • 依据：没有可跑的检查时，「看起来处理好了」就是模型唯一能用的信号，你会被迫亲自当验证回路（验证-2：you become the verification loop）；改成清单+证据能把判断权交回客观结果。
  • 该怎么说：逐项给「通过/不通过 + 证据」，别给总体结论：1. forceGenerate 是否确实进了 body（贴该处代码片段）；2. query 参数里有没有残留 forceGenerate；3. 改动是否复用同一 request 封装、有无重复实现；4. 跑一次 type-check / 构建贴结果。你没法验证、需要我手点页面触发「重新生成」的，列出来。
  • 用前→用后：本条8次调用（Bash×6 Read×2）读改了 index.tsx、utils.ts，是一次有效审查；但因为没要清单+证据，紧接的第6、7条退化成0调用口头确认——若本条就用清单口径，可一次性收口，避免后两条空转。

6.「是完全按照后端发的改动的是吧，没有破坏其他任何正常功能是吗」

  • 你这么说：要确认改动「完全按后端发的改、没破坏其它正常功能」。归类：确保没问题/追问确认。
  • 问题：典型形容词验收：「完全按」「没破坏任何正常功能」都没有可勾选项——哪些功能算「其它正常功能」、用什么验证「没破坏」全无定义。模型给不出客观判定，只能口头答「是」，于是出现0调用空转。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：大佬不接受口头保证，要可跑的回归检查与证据（验证-4：always provide verification, if you can't verify it don't ship；验证-3：show the test output / command it ran）。
  • 依据：没有可运行的检查，模型只会用「看起来没坏」回应，真正的回归风险无人验证，你重复追问也只会把上下文搞脏、表现更差（验证-2 + 上下文-1）。
  • 该怎么说：别只回答「是」，给证据：1. 把这次改动的完整 diff 贴出来，逐行说明只动了 lecture_tasks 调用的 body；2. 列出所有 import/调用 wrongQuestionBook 这个 request 的页面，说明它们参数未变；3. 跑 type-check / 构建贴结果；4. 我无法静态验证的「重新生成」实际行为，告诉我去点哪个按钮、看哪个网络请求来确认。
  • 用前→用后：原来0次调用（纯口头「是」空转）；换成「贴 diff + 列调用方 + 跑构建」能直接驱动 Bash/Read 给出客观证据，把空转变成可验证结论。

7.「我们只按照刚刚我发你的改，不要多加任何东西，是这样的处理的吗」

  • 你这么说：再次确认「只按刚发的改、没多加任何东西」。归类：确保没问题/追问确认。
  • 问题：与第6条几乎同义的重复追问，仍是无标准的形容词确认。「没多加任何东西」没法被模型客观判定，它只能再答一次「是」，0调用空转，且重复追问进一步堆积无效上下文。
  • 实际发生：0 次调用——这条没驱动任何操作（空转）。
  • 大佬怎么用：大佬同一问题不会追问第三次——要么要 diff 证据，要么 /clear 重开（纠偏-2：同一问题纠偏超两次就 /clear 重来；验证-3：要 diff/命令输出而非断言）。
  • 依据：形容词追问拿不到新信息，反复问只把上下文越填越满、模型表现持续下降（上下文-1）；用 diff 自证「增量只有这一处」才是唯一能让模型停下口头保证的客观依据（验证-4）。
  • 该怎么说：用 git diff 自证，别再口头答：贴 git diff 全文，确认改动只有「lecture_tasks 调用 body 加 forceGenerate:true」一处，没有新增文件、没有改公共封装、没有顺手格式化其它行。如果 diff 里有任何无关改动，回滚掉只留这一处。
  • 用前→用后：原来0次调用（与第6条重复的口头「是」空转）；改成要 git diff 自证后，可直接驱动一次 Bash 给出增量全貌，第6、7两条本可合并为一次带证据的收口，省掉两轮空转。

本会话小结：本会话真正驱动活的是第1、2、5条（定位到 index.ts/wrongQuestionBook.ts/index.tsx/utils.ts 并完成改动），第4条也驱动了 15 次调用但因开放式追问而发散；第3、6、7三条全是0调用空转。空转/发散根因集中在追问句式：第4条「确定没有任何问题是吗」、第6条「是完全按照后端发的改动…没有破坏其他任何正常功能是吗」、第7条「只按照刚刚发你的改，不要多加任何东西，是这样处理的吗」——都是无判定口径的形容词式追问，要么让模型口头答「是」（0调用），要么让它无 scope 地放大排查面（第4条15调用）。第3条则是误粘进来的 autonomous-loop 系统提示词，与本任务无关，纯噪声。