为了一个中文 hover，我和 AI 绕了一大圈
最近，我在读一个 Python Agent 项目的源码。
鼠标放到 argparse、ArgumentParser 这些名字上，编辑器会弹出一大段英文说明。这个悬停提示通常叫 hover，本来是帮助理解代码的，但对我当时的学习阶段来说，它又增加了一层障碍：我得先理解英文，再理解 API，最后才能回到眼前这段代码。
于是，我问 AI：有没有中文的？能不能让中文放在上面？
我已经装了一个翻译插件。它能翻译，但英文在上面，中文在下面。后来又找到一个接入大模型 API 的插件，调整配置，终于能把中文放在前面。
接着，我发现还有别的问题。
翻译出来的中文，不一定是适合初学者阅读的解释。每次悬停还得等模型返回，阅读经常被打断。打开自动翻译后，连我自己写的 main 都出现了翻译工具栏，原生签名又被复制了一遍。
我又提出：能不能提前把项目用到的这些说明全部翻好，以后直接看？
于是，我们开始研究批量收集、预翻译和缓存。过程中，接口返回了 HTTP 429，批量调用停了下来。这里需要说准确：当时只确认请求受到了限制，没有查清具体原因，不能直接认定是并发上限。
然后，AI 换了个办法：根据已经收集到的标准库原文，直接整理中文说明。
我这才反应过来：
最开始找插件，其实没有错。如果一个成熟工具几分钟就能解决问题，当然值得先试。
问题在于，后面我的需求已经逐渐清楚了，我们却还在沿着最初的工具路线往前走。
我说中文位置不对，就研究排序；我说等待太慢，就研究自动翻译；我说希望提前准备，就研究插件缓存。每一步单独看都有理由，连起来却发现：我们一直在改善一个工具，很晚才重新检查它是不是合适的工具。
我最初交给 AI 的“找一个中文翻译插件”，其实已经包含了我对解决办法的猜测。
而我真正希望得到的结果是：
这句话一明确，办法就多了。
中文说明可以提前生成，不必每次实时请求翻译；内容可以按我的学习阶段编写，不必拘泥于英文文档逐句转换；项目自己定义的代码可以保留原生签名和 docstring，只给外部接口补说明。
“说明怎么写”和“说明怎么显示”，也应该拆开处理。前者可以由 AI 批量完成，后者才是编辑器集成的问题。
但至少，我们终于重新找到了任务的重点。
这让我想起 Anthropic 工程经理 Felix Rieseberg 关于“更有野心地使用 AI”的文章。他把这种野心分为四个方向：速度、高度、深度和广度。原文链接
用它重新看这次经历，会更容易理解：
其中，对我触动最大的是高度。
我原来以为，使用 AI 就是把自己想到的做法交出去，让它更快地执行。后来才意识到，检查这个做法是否值得采用，也可以交给 AI。
这不要求我一开始就知道最优解。我可以先描述自己遇到的障碍、希望得到的变化，再把当前想到的办法作为候选方案。
AI 也应该承担相应的责任。它不能只是顺着上一条方案不断补功能。尤其当我们已经开始为接口、限速、缓存和插件改造投入越来越多时间时，它应该主动重新判断：继续这条路线，还划算吗？
这次绕路，并不能全部归因于“我的提示词不够好”。
深度则让我进一步明确了：我需要的其实不只是中文。
比如，asyncio.create_task(coro) 如果只翻译成“创建异步任务”，对初学者的帮助很有限。我更需要看到这样的解释：
把一个协程交给事件循环调度，并返回一个 Task。当前代码可以继续执行，之后再等待这个 Task、取消它或检查结果。它不会新建线程，也不表示任务已经完成。
这段说明解释了动作、返回值和执行状态，也澄清了一个容易混淆的地方。
如果再结合当前项目，说明为什么这里需要创建任务，就更有用了。
所以，目标逐渐变成：为当前项目实际用到的外部接口，提前准备一套适合我阅读的说明。标准库之外，还有模型 SDK、Pydantic、数据库库、MCP SDK和界面框架。
这里的“全量”，也有清楚的范围：覆盖当前项目实际使用的接口，而不是给整个 Python 生态重新编一本词典。
讨论到这里，我又开始怀疑自己：是不是有点嫌麻烦的完美主义？
想要中文容易理解，想要不用等待，想要不干扰自己的代码，于是一直让 AI 改，一直优化体验。
但仔细分开看，这些要求本身都有实际作用。它们直接影响我能不能顺畅地阅读，并不是为了好看而随意增加的装饰。
如果工具越来越复杂，我却迟迟没有回到源码，这就是一个值得停下来检查的信号。
我曾想用“过犹不及”理解它，但落实到具体任务里，不必上升成“追求完美必然遭到反噬”的规律。更实际的原因是：额外投入带来的收益可能越来越小，制作、维护和注意力成本却仍在增加。
这也解释了为什么四个方向不需要每次都拉满。
多开几个 Agent，可能缩短编写时间，也可能增加协调成本。往更高层次追问目的，可能找到更好的路线，也可能把一个小需求扩大成一套平台。解释得更深，可能帮我理解机制，也可能讲到当前根本用不到的底层细节。
明确要求仍然应该做好。中文准确、容易理解、覆盖约定范围、自定义代码不被干扰，这些都是完成标准。
额外增加更多库、更多语言、更复杂的管理界面，则需要重新判断收益。
我现在更愿意问：
继续聊下去，我发现，四个方向之外当然还能扩展。
价值、可靠性、自主程度、可控性、可复用性、学习收益，都可以成为判断角度。
但我也不想再把它们变成每次必须填满的一张大表。它们各自提醒我注意不同的问题：
价值提醒我，功能做出来之后，究竟改善了什么。
可靠性提醒我，解释顺口不代表机制正确，文件生成也不代表实际悬停已经验收。
自主程度和可控性提醒我，可以把路线探索和普通实施细节交给 AI，但目标、授权和重要决定仍然要有边界。
可复用性和学习收益提醒我，这次投入最好能留下以后继续使用的成果，也能帮助我逐渐形成自己的判断。
对我当前的学习来说，最后一点尤其重要。说明库的作用，是帮助我看懂代码、继续推理。工具准备得再丰富，如果学习一直停在原地，就需要重新检查它的价值。
对当前的学习任务，要尤其看重 价值、可靠性、学习收益：
-
内容再全面，如果长期占用时间却没帮助你继续读源码，价值就有限。 -
解释再顺口，如果机制讲错了，就会形成错误理解。 -
功能再方便，如果只是不断替你给答案，没有帮助你看懂代码，学习收益也需要重新检查。 所以，除了问“还能做得多快、多深、多广”，还可以追问：值得做吗，怎么证明做对了，完成后我留下了什么？
后来，我试着把这次经历整理成一个更简单的提问方式。
我不需要分别填写“具体需求”和“最终目的”，那很容易写成两遍差不多的话。更有用的是分开写：
-
我的需求：当前遇到了什么问题，希望变成什么样。
-
我当前的想法：目前觉得可以怎么解决，没有也可以。
-
必要的边界：时间、成本、必须保留的内容，以及这次只讨论还是可以执行。
然后，把判断路线的工作也交给 AI：
请先区分我要的结果和我提出的做法，不要默认我的做法就是最佳路线。从速度、高度、深度和广度检查有没有更直接、总成本更低的办法。用原始资料核实，用实际结果验收。如果我们持续在给同一条路线打补丁，而目标没有明显推进，请主动重新判断路线。更好的建议仍要遵守我明确的目标和授权。
这段话不能保证 AI 从此不绕路，但它明确了一件事：我需要它参与判断，而不只是执行我眼前想到的步骤。
这次 hover 的折腾，让我重新认识了自己在协作中的长处和需要调整的地方。
我能够通过实际使用发现具体障碍，把“不舒服”逐渐变成清楚的要求。接下来要练习的是，更早地把想要的结果说出来，不把第一版做法当成固定前提。
AI 则应该更早比较路线，识别无效投入，认真区分“准备好了”和“验证完成了”。
我会继续改善阅读体验，也会更留意自己是否真的回到了源码。下一次鼠标停在一个陌生接口上，我希望看到合适的解释，然后把注意力放回那段代码，继续读下去。
下附提示词：
我的需求：
【描述当前场景、遇到的问题，以及希望得到的结果。】
我当前的想法：
【描述目前想到的做法；没有也可以写“暂时没有”。】
补充边界（有就填写）：
【例如时间、预算、必须保留的内容，以及这次是讨论方案还是直接执行。】
请先理解我的需求，把“我要的结果”和“我提出的做法”分开。
不要默认我的做法就是最佳路线，也不要擅自改变我明确的目标。
请从以下四个角度寻找更好的办法：
1. 速度
考虑完成这件事的总时间，包括准备、执行、反复操作和后续维护。
检查能否通过批量处理、提前准备、复用或自动化减少重复劳动。
不要只让原有步骤执行得更快，也要检查哪些步骤可以直接省掉。
2. 高度
检查我是否把某个工具或操作误当成了目标。
结合场景，找出它真正要解决的问题，再判断能否直接实现那个结果。
如果建议改变我明确的目标或验收标准，请单独提出，由我决定。
3. 深度
检查做好这件事需要哪些原始资料、专业方法和验证手段。
找出表面处理容易遗漏的关键机制。
深度体现为理解和可靠性，不是说明更长、术语更多或流程更复杂。
4. 广度
检查其他领域的知识、工具或工作方式，是否能提供更直接的路线。
只引入能改善结果的方法；不要为了显得全面而增加工具、角色或子 Agent。
然后，请直接给我：
- 你对需求的理解，以及当前想法中最关键的假设。
- 推荐做法和选择理由；存在实质不同的路线时，再做简短比较。
- 最小验证办法，以及怎样判断任务已经完成。
四个角度用于帮助判断，不要求每次分别写一大段。
简单任务直接处理，不为套框架增加流程。
能自行查清的事实先查；只有关键歧义才问我。
如果我要求执行，就在已有授权范围内先验证关键效果，再完成必要工作。
如果我只要求讨论，就先给判断和建议。
过程中如果持续在给同一条路线打补丁，而目标没有明显推进，
请主动重新检查路线，不要默认继续投入。