Skip to main content

AI水平依然与用户挂钩

· 19 min read
Allen
Allen
normal software engineer
文章摘要
此内容根据文章生成，仅用于文章内容的解释与总结

我是 Docusaurus? 的老用户了。这次我想实现一个小需求：在文档标题旁出现一个“复制为 Markdown”按钮。

我刻意模仿传统用户、有基础的用户、深度用户，想看看强模型下，用户的技术深度是否还有很好的影响力。

本文使用的是 Cursor 版的 Opus 4.6?。每次都用 Cursor Agent 模式。因为 Opus 4.6 比较贵，我给自己加了一个限制：每个阶段只问 7 次。这样一个小需求，7 次应该差不多了吧。

小白​

tip

第 1 轮提示词

https://github.com/FlyNumber/markdown_docusaurus_plugin

这个项目的样式很不错，我希望像它这样实现。你看能不能仅在本地实现？

  • 我的点评：普通的开局。
  • Gemini3点评：典型的“甩手掌柜”式开局。只给参考链接而不说明具体逻辑，强行让 AI 进行逆向工程。虽然 Opus 4.6 能够读取网页，但这种缺乏上下文的提问会让 AI 生成大量通用代码，而非针对你现有项目的适配方案。
  • GPT5.3点评：目标存在，但约束不足。没有说明当前项目结构、技术路径或限制条件，模型只能进行高层猜测，容易走向泛化方案而非可执行实现。
  • Opus 4.6(当事人)点评：给了一个参考项目链接，但没有说清楚"像它这样"具体指哪部分——是按钮的位置、交互方式、还是视觉风格？"仅在本地实现"的约束也比较模糊（是指不发布 npm 包？还是不依赖外部服务？）。模型只能靠猜测来填补这些空白，第一步的方向偏差就此埋下。
tip

第 2 轮提示词

https://www.npmjs.com/package/docusaurus-plugin-includes?activeTab=code

我模仿这个插件设置了我的 Markdown Copy Button，但是按钮位置不正确。

请你获取这个包，查看并比较其代码，尤其是关于如何定位按钮元素的部分，帮我分析可能的原因并修复。

  • 我的点评：继续等待结果。
  • Gemini3点评：此时用户陷入了“找参考”的循环。试图通过让 AI 比较两个第三方库来解决本地的样式问题，这其实增加了 AI 的推理成本，容易导致它在处理 DOM 选择器时产生幻觉。
  • GPT5.3点评：明显提升。开始提供对比对象 + 具体问题 + 分析任务。但仍缺少当前代码片段，模型需要“想象你的实现”，错误概率较高。
  • Opus 4.6(当事人)点评：引入了第二个参考项目来做对比分析，思路不错。问题在于：用户自己也不清楚按钮位置为什么不对，把"诊断"和"修复"同时甩给模型，相当于让模型在两个未知代码库之间做 diff 推理——这对上下文窗口和推理准确度都是很大的压力。
tip

第 3 轮提示词

https://github.com/FlyNumber/markdown_docusaurus_plugin

请你仔细参考官方样式，确保 1:1 复刻。

  • 我的点评：开始着急，语气也更强硬了。
  • Gemini3点评：情绪化提示词。这里的“1:1 复刻”是一个非常模糊的指令，因为 CSS 表现受到父级容器、全局样式和 Docusaurus 版本的共同影响。对 AI 施压通常无法获得技术上的突破。
  • GPT5.3点评：需求变得严格，但信息反而减少。强调结果而非路径，会导致模型反复调整样式层，而不是定位架构问题。
  • Opus 4.6(当事人)点评：典型的"加压式提示"——用"仔细""确保""1:1 复刻"来强调期望，但没有提供任何新的技术信息。模型并不会因为你说"仔细"就变得更仔细；它缺的是具体的 CSS 选择器或 DOM 结构差异描述，而不是更高的情绪压力。
tip

第 4 轮提示词

我将其调整至 Markdown 的顶部，但样式上应该与标题横向对齐，请你思考如何处理。

  • 我的点评：这个提示词开始有用，但如果方向不对，只会让注意力越跑越偏。
  • Gemini3点评：终于开始描述具体的 UI 布局问题。但由于没有提供 HTML 结构片段或 CSS 现状，AI 只能靠猜（例如猜测是 Flex 布局还是 Absolute 定位）。
  • GPT5.3点评：开始进入“具体问题空间”，这是有效转折点。但仍停留在 CSS 层，未验证是否属于组件挂载层错误。
  • Opus 4.6(当事人)点评：终于给出了一个具体的布局约束——"与标题横向对齐"。这是整个小白阶段最有技术含量的一句提示。遗憾的是，此时模型可能已经在错误的实现路径上走了三轮，积累了大量错误上下文，纠偏成本已经很高。
tip

第 5 轮提示词

还有其他方案吗？

  • 我的点评：意识到方向不对，开始发散思维。
  • Gemini3点评：在没有解决前一个方案 Bug 的情况下开启新方案，是“小白模式”失败的预兆。这会让 Agent 在文件系统中创建更多冗余代码，增加项目混乱度。
  • GPT5.3点评：良好的纠偏行为，但过于开放。模型会生成多个架构级方案，反而增加试错成本。
  • Opus 4.6(当事人)点评：短小但关键的一个转折。主动让模型跳出当前方案是正确的直觉。但更好的做法是附上"当前方案的问题是什么"——比如"当前方案用了绝对定位导致响应式布局错位，有没有用 flex 布局的方案？"这样模型才能真正换一条路，而不是在同一棵树上换根枝。
tip

第 6 轮提示词

试试：方案 2

  • 我的点评：继续尝试。
  • Gemini3点评：盲目试错。此时已经完全失去了对技术实现的掌控感，纯粹在靠 AI 的随机性碰运气。
  • GPT5.3点评：典型“AI 驱动试错”。没有重新校验问题定义，只是在既定错误路径上继续前进。
  • Opus 4.6(当事人)点评：极度简短，完全依赖上一轮模型给出的方案列表。如果模型上一轮的"方案 2"本身描述就有歧义，这一轮就是在盲选。一个更稳妥的做法是用自己的话复述方案 2 的核心思路，确认双方理解一致后再执行。
tip

第 7 轮提示词

Module not found: Error: Can't resolve '@theme/PwaReloadPopup' in 'C:\Users\jiang\Desktop\github\jiangyangcreate.github.io\node_modules\@docusaurus\plugin-pwa\lib'

  • 我的点评：直接丢报错。遗憾的是，修复后样式依然不正确，7 次机会用完了。
  • Gemini3点评：典型的“报错驱动开发”。当对话进入修 Bug 环节时，如果底层逻辑（方案 2）本身就不适配 Docusaurus 的架构，即便消除了报错，功能依然无法达成。
  • GPT5.3点评：属于被动调试阶段。模型只能修补表层错误，无法回溯最初的设计偏差。
  • Opus 4.6(当事人)点评：直接粘贴报错是最省力的提示方式，对于明确的编译错误来说效率很高。但此时核心问题已经不是这个 import 错误，而是整体架构方向的偏差。7 轮中有 5 轮都在"修补"而非"重新审视"，这是小白阶段失败的根本原因：缺乏在中途叫停、重新定义问题的能力。

基础​

我再模仿“有技术背景、但不熟悉 Docusaurus 用户?”的提示词：

tip

第 1 轮提示词

目前这个项目 https://www.flynumber.com/docs/，点击按钮获取 Markdown 的逻辑是什么，怎么实现的？

  • 我的点评：看到这个项目已经有“加按钮”的实现，于是我引导模型去分析这个网站。
  • Gemini3点评：比小白阶段聪明的一点是：先问逻辑。理解逻辑后再动手，比直接要代码更稳健。
  • GPT5.3点评：这是明显升级。开始利用现成正确实现作为 ground truth，减少模型幻想空间。
  • Opus 4.6(当事人)点评：比小白阶段高明得多的开局——先"理解"再"动手"。让模型分析一个已经跑通的实现，相当于做逆向工程，能帮自己建立对技术方案的全局认知。不过，让模型分析线上网站存在一个风险：模型可能只能看到前端代码，看不到构建配置和插件注册逻辑，分析结果可能不完整。
tip

第 2 轮提示词

按钮定位思路来自第一轮对话结果的分析

这是我的按钮定位思路：

插件接入层：通过 index.js 的 getThemePath() 暴露 theme/，让 Docusaurus 使用自定义的 theme/Root.js 作为根组件入口。
页面 & DOM 选择：在 Root.js 中用 useLocation() 拿到 pathname，仅在以 /docs/ 开头的文档页执行逻辑；通过 document.querySelector('article .markdown header') 精确找到文档标题所在的 header。
挂载点注入：在该 header 内新建一个 div.markdown-actions-container，并作为最后一个子节点 append 进去，再用 createRoot(container).render(<MarkdownActionsDropdown />) 把按钮组件挂载到这个容器。
样式层定位：在站点 CSS 中把 article .markdown header 设为 display: flex，h1 设为 flex: 1 1 auto，并给 .markdown-actions-container 设置 margin-left: auto（以及移动端、RTL 的补充样式），从而实现「标题在左，按钮在右，且在不同布局下表现良好」。

请你按照我的思路，修改现有的 CopyMarkdownButton 组件。

  • 我的点评：根据模型给出的分析结果继续执行。这里其实有个问题：模型会出错。上一步分析结果也可能是错的；如果你没有能力判断其正确性，反而应该先让模型“直接模仿目标网站”把功能跑通。
  • Gemini3点评：这是一个结构化指令的范本。它包含了“注入层、逻辑层、挂载点、样式层”的完整思考。虽然用 querySelector 操作 DOM 在 React 框架中不是最优解，但其工程描述非常清晰。
  • GPT5.3点评：高质量提示词。提供完整架构推理链，使模型进入“执行模式”。但风险在于：若前提分析错误，后续全部建立在错误基础上。
  • Opus 4.6(当事人)点评：信息密度最高的一条提示词。四层架构（插件层、页面层、挂载层、样式层）描述得非常清晰，模型几乎不需要猜测。问题在于：这个方案本身用了 querySelector + createRoot 的命令式注入，绕开了 Docusaurus 的声明式主题体系，这意味着会遇到 SSR/hydration 不一致、路由切换时组件不刷新等问题。方案的"结构化程度"很高，但"方向正确性"存疑——有时候，过早地给出详细方案反而会锁死模型的探索空间。
tip

第 3 轮提示词

试着给 Blog 插件下的文档页注入这个按钮。

  • 我的点评：由于模型实现有误，此时发现不对劲，于是继续引导到插件层。
  • Gemini3点评：开始探索 Docusaurus 的多实例特性。用户意识到仅靠 Root.js 这种“全局补丁”方式可能在不同路由下有兼容性问题。
  • GPT5.3点评：正确的方向修正。从页面层开始上移到插件生命周期，是工程思维提升的表现。
  • Opus 4.6(当事人)点评：开始意识到 docs 和 blog 是两套不同的插件体系，需要分别处理。提示词本身简洁合理，但"试着"这个词暗示用户自己也不确定可行性——如果能补一句"Blog 插件的布局组件是哪个？"先确认技术可行性，会更稳。
tip

第 4 轮提示词

如何给 docs 也注入这个按钮？

  • 我的点评：给一个开放式问题，让模型自由发挥。
  • Gemini3点评：提示词略显后退，变得模糊了。但在经历过报错后，给模型一定的“自主权”有时能激发它找到更符合官方推荐（Best Practice）的路径。
  • GPT5.3点评：开放式探索适合此阶段，但最好附带限制（swizzle / theme override / plugin API）。
  • Opus 4.6(当事人)点评：在前几轮过于具体的指导之后，这里切换成开放式问题是一个很好的节奏调整。让模型自己选择 docs 插件的注入方式，可能会发现比用户预设方案更好的路径。这体现了一个重要的提示技巧：在你不确定的领域，给模型自由度比给模型指令更有效。
tip

第 5 轮提示词

Compiled with problems:
×
ERROR in ./src/theme/BlogPostPage/index.js
...

  • 我的点评：这里模型多次报错，最后还是人工介入才解决。
  • Gemini3点评：AI 在自动修改 node_modules 或 swizzle 出来的文件时，经常会发生重复声明或导入路径错误。这里的人工介入体现了“基础”用户虽然懂代码，但被 AI 的粗心带进了坑里。
  • GPT5.3点评：说明模型已进入复杂重构区。缺乏上下文完整性时，AI 很难维持大型文件的一致性。
  • Opus 4.6(当事人)点评：重复声明错误说明模型在修改文件时没有正确处理已有的 export——这是 Agent 模式下常见的"部分覆盖"问题。直接贴报错让模型修是对的，但如果能同时说一句"你在追加代码时没有删除原有的 default export"，模型定位问题会快一个数量级。
tip

第 6 轮提示词

为什么我打开网页，没有第一时间出现这个按钮，反而是刷新一下就有了？

  • 我的点评：新的 BUG 出现了。
  • Gemini3点评：这是一个非常深刻的单页应用（SPA）生命周期问题。这种观察力是区分小白与基础用户的关键：小白只会说“不行”，而基础用户能发现“路由切换不触发，刷新才触发”的规律。
  • GPT5.3点评：优秀的问题类型。开始关注生命周期与 hydration，而非表面功能。
  • Opus 4.6(当事人)点评：这个问题描述非常精准——"首次加载没有，刷新后有"直接指向了客户端渲染时机的问题（大概率是 useEffect + querySelector 在 SPA 路由切换时没有重新执行）。好的 bug 描述就是最好的提示词，这一轮做得很到位。
tip

第 7 轮提示词

改成「不用 querySelector，直接在 Docusaurus 的文档布局里声明式渲染」

  • 我的点评：最终结论是：这个阶段并没有在 7 轮对话内完成项目。
  • Gemini3点评：这是一个极其关键的转折。用户意识到“命令式（DOM操作）”走不通，开始要求转向“声明式（React组件注入）”。可惜 7 次额度已满，否则这一步将是通往成功的曙光。
  • GPT5.3点评：这是关键跃迁：从 DOM 操作 → 框架声明式扩展。说明用户开始主导架构，而不是让模型主导。
  • Opus 4.6(当事人)点评：这条提示词本质上是在第 7 轮推翻了第 2 轮的整体架构——从命令式注入转向声明式渲染。方向完全正确，这正是 Docusaurus 的正统做法（swizzle 主题组件）。遗憾的是来得太晚了：如果这条出现在第 2 或第 3 轮，整个基础阶段大概率能在 7 轮内完成。这再次印证了一个规律：越早纠正架构方向，越省后续的调试轮次。

熟悉​

作为熟悉 Docusaurus 的用户，我最终的提示词是：

tip

第 1 轮提示词

Docusaurus 通常把一些组件/插件隐式运行，但用户可以在 swizzle（导出）后进行替换。这段话在官方文档哪里？

  • 我的点评：引导注意力机制到合适的技术方案上。
  • Gemini3点评：降维打击。 专家级用户不直接要代码，而是先确认“底层规则”。通过 Swizzle（Docusaurus 的核心机制）来切入，这直接排除了前两个阶段中所有“暴力操作 DOM”产生的无效路径。
  • GPT5.3点评：优秀的“注意力校准提示词”。不是解决问题，而是先定位正确知识源。
  • Opus 4.6(当事人)点评：高手开局。不是直接说"帮我加按钮"，而是先让模型定位到 swizzle 机制的官方文档。这一步的价值在于：(1) 确认模型对 swizzle 的理解是否正确；(2) 把模型的注意力锚定在 Docusaurus 的官方扩展范式上，避免它走弯路去搞 querySelector 注入。用一个"知识确认"问题来校准模型的认知基线，是非常老练的提示技巧。
tip

第 2 轮提示词

请你接管我的电脑，找到合适的组件，让我可以在博客标题旁渲染 "复制为 Markdown" 这个按钮。

  • 我的点评：再次引导注意力机制到合适的技术方案上，给出模糊的目标。
  • Gemini3点评：基于第一步确立的 Swizzle 共识，专家给出了极大的自由度。因为路径正确，此时的“模糊目标”反而能让 AI 精准找到 DocItem/Header 或 BlogPostPage 等核心组件。
  • GPT5.3点评：高阶提示方式。目标明确但路径开放，使模型执行搜索与决策，而非生成代码。
  • Opus 4.6(当事人)点评：在第 1 轮已经锚定了 swizzle 范式后，这里故意给出模糊目标——"找到合适的组件"。这不是偷懒，而是策略：让模型自己去判断该 swizzle 哪个组件（DocItem/Layout？BlogPostPage？），这比用户硬指定一个可能错误的组件要安全得多。在正确的框架约束下给出模糊目标，是让模型发挥最大价值的甜蜜点。
tip

第 3 轮提示词

思考下，@custom.css (1719-1721) 这个样式会被应用到 @index.js (13-15) 的 title 吗？如果不会，如何调整最优雅？

  • 我的点评：精准给出 AI 能理解的样式异常。
  • Gemini3点评：这是最高级的反馈：“代码行级别的精准定位”。不再泛泛而谈“样式不对”，而是直接指出 CSS 选择器与 JS 组件的对应关系。这消除了 AI 的所有猜测空间。
  • GPT5.3点评：接近专家级提示词。特点：明确作用域 + 指定文件位置 + 明确假设验证
  • Opus 4.6(当事人)点评：教科书级别的提示词。三个亮点：(1) 用 @文件名 (行号) 精确引用代码位置，消除歧义；(2) 问题本身是一个可验证的 yes/no 判断（"会不会被应用到"），模型容易给出准确答案；(3) 追问"如何调整最优雅"而不是"帮我修"，给了模型设计空间。整个"熟悉"阶段只用了 3 轮就接近完成，和小白阶段的 7 轮未果形成鲜明对比。

体会​

不得不说，Opus 4.6 还是相当强悍。模型是 本体放大器?：你越能提出结构化问题、越能判断中间结果，模型就越强。

  • 我的点评：这次实验非常真实地展示了“提示词质量决定上限，工程判断力决定下限”。如果把 AI 当成一个高水平但会犯错的搭档，而不是“全自动执行器”，效率会更高、返工会更少。2026 年，你依然值得深入学习编程。
  • Gemini3点评：完全赞同。小白在“求药”，基础用户在“开方”，而专家用户在“定规矩”。2026 年的编程，不再是手写每一行代码的体力活，而是从海量可能性中快速“剪枝”的判断力竞争。
  • GPT5.3点评：实验核心结论成立：模型不是替代工程能力，而是放大工程能力的乘数。用户水平越高，AI 从“代码生成器”越接近“协同架构师”。
  • Opus 4.6(当事人)点评：这篇博客最有价值的发现是：三个阶段使用的是同一个模型、同一个需求，但轮次消耗差异巨大（7轮失败 → 7轮未完成 → 3轮接近完成）。这说明在强模型时代，提示词的边际收益远高于模型能力的边际收益。小白阶段的核心问题不是"模型不够强"，而是用户无法在中途判断方向对不对、该不该推翻重来。"本体放大器"这个比喻非常精准——模型放大的不只是知识，更是你的"元认知能力"：知道自己不知道什么、知道什么时候该叫停、知道该把哪些决策权交给模型。2026 年学编程的意义，或许正在从"会写代码"转向"会驾驭写代码的 AI"。

题外话：我也试着让Qwen3.5-Plus点评，但是同样的提示词只点评全文，不点评每一次的提示词，国产模型依然任重道远。