Claude Code的秘密生活：首次Prompt
Source: Dev.to
请提供您希望翻译的正文内容，我将按照要求保留原始链接、格式和代码块，仅翻译文本部分。
为什么你的提示质量实际上就是你的思考质量
Margaret 是一名资深软件工程师。Timothy 是她的初级同事。他们在伦敦的一座宏伟的维多利亚风格图书馆工作——在那里，精确受到重视，含糊会被温和地纠正。Timothy 带着一个真实的问题和一个他相当自豪的提示来到这里。
第 3 集：首次提示的工艺
Timothy 带来的内容
他到达时笔记本已经打开，玛格丽特把这当作一个好兆头。这意味着他在走进门前已经在思考。
“我今天有一个真实的案例，”他说，坐到椅子上。“不是玩具示例。是代码库中的实际问题。”
“好，”玛格丽特说。“把你写的给我看看。”
他把笔记本转向她。屏幕上显示着他准备的提示：
“修复我的数据处理管道中的性能问题。”
玛格丽特读了它。随后她戴着眼镜，用那种她只在需要耐心的时刻才会露出的表情看着他。
“Timothy，”她说，“这个提示有什么问题吗？”
他稍微动了动。“我觉得已经相当清楚了。”
“一点也不清楚，”她说，语气并不刻薄。“这是一位知道自己想要什么，但还没有把它描述清楚的人所写的提示。”
The Interrogation
她把笔记本电脑转回给他，双手交叉放在膝上。
“告诉我关于这条管道的情况。它是干什么的？”
“它处理客户交易记录。从数据库读取数据，应用一些业务逻辑，然后把结果写入报告表。”
“有多少条记录？”
“小批量时几千条。月度批处理时大约四百万条。”
“性能问题呢？到底发生了什么？”
“月度批处理超时了。以前大约四十分钟能完成，现在要三个多小时，而且中途会失败。”
“什么时候出现这种变化的？”
Timothy 停顿了一下。“大约三周前。”
“三周前到底改了什么？”
又是一段更长的停顿。“我们新增了一个验证步骤，用于合规监管。”
Margaret 稳稳地盯着他。“而且你给 Claude Code 的提示是：fix the performance issue in my data processing pipeline.”
他有点尴尬地笑了笑。“你这么说——”
“我这么说是因为那正是你写的。”她拿起笔。“Claude Code 不是读心术。它并不知道你的四百万条记录、你的合规验证、你的三小时超时，或者这件事是三周前才开始的。你把一个没有上下文、没有约束、也没有成功标准的問題交给它。你想它会产出什么？”
“会是一些通用的东西，”他承认。
“通用的东西，”她确认道。“可能听起来貌似合理，却完全不符合你的具体情况。而你还得花一个小时去发现这一点，本来只要在一开始花五分钟仔细思考就能完全避免。”
四个问题
她在记事本上画了一个小网格——四个格子。
“在你为真实的工程问题写任何提示之前，”她说，“先回答四个问题。不一定要在提示本身写出来——先在你自己的脑子里回答，然后在写作时体现出来。”
-
上下文是什么？
我们在什么系统中工作，它的功能是什么，它的约束条件有哪些？Claude Code 需要了解问题所在的世界。 -
具体问题是什么？
不是“性能问题”。管道每月处理四百万条记录，最近在三小时后超时，之前在四十分钟内完成，超时的变化恰好伴随添加了一个验证步骤。 -
你已经尝试或考虑过什么？
如果你已经排除了一些方法，请说明。如果你有理论，请分享。你不是让 Claude Code 从零开始思考——而是让它与你一起思考。 -
好的解决方案是什么样的？
约束条件是什么？必须在特定时间内完成吗？必须不改变输出格式吗？是否有代码库的部分不能触碰？在开始之前定义成功，否则你在看到时也认不出来。
她放下笔。“现在重新写你的提示。”
Source: …
重写
Timothy 静默了几分钟。Margaret 喝着茶，没有催促他。好的想法不能仓促而来，她早已明白沉默往往比帮助更有成效。
他把笔记本电脑转向她。
“我有一个用 Python 编写的数据处理流水线，它从 PostgreSQL 数据库读取客户交易记录，进行业务逻辑校验，然后将结果写入报告表。在每月约四百万条记录的批处理运行中，流水线最近在三小时后超时——之前只需四十分钟就能完成。这个变化恰好与三周前新增的监管校验步骤同步。我怀疑校验逻辑可能在循环中执行了数据库查询，但尚未确认。解决方案不能更改输出格式或表结构。你能帮我找出可能的瓶颈并提出修复思路吗？”
Margaret 仔细阅读了整段文字，两遍。
“更好，”她说。“好很多。”
“只是更好？”
“显著更好，”她补充道。“你已经提供了背景、具体问题、时间线、假设以及约束。Claude Code 现在可以真正有用地处理这个请求了。”她停顿了一下。“我建议再加一点——先说明你想要的结果，而不是把它放在最后。”
“这是什么意思？”
“你把实际请求埋在了最后一句话里。先把你想要的结果说出来，然后再提供背景。比如：我需要诊断并修复 Python 数据流水线中的性能回退——其余内容随后补充。”
有什么变化
Timothy 做了调整。提示现在以明确的意图陈述开头，随后是他已经写好的全部内容。
“那里，” Margaret 说。“现在你有一个值得发送的提示。”
“我可以问点什么吗？”
Timothy 说。“第二个提示要长得多。更长就一定更好吗？”
“不，” Margaret 立刻回答。“长度不是美德。精准才是美德。你的第二个提示更长是因为你的第一个提示缺少了必要的信息。如果你的第一个提示足够精准且完整，它的长度就恰到好处。”
她稳稳地看着他。
“要问的问题不是 我写得够了吗？ 而是 这是否包含了 Claude Code 帮助我所需的全部信息？ 有时这只需要两句话，有时需要一段文字。问题决定长度，而不是相反。”
Timothy 缓慢地点了点头。
“所以提示其实就是……把清晰的思考写下来。”
“正是如此，” Margaret 说。“这一直都是如此。那些在使用 Claude Code 时感到困难的开发者，往往并不是在与工具斗争——而是与本应在使用工具之前进行的思考斗争。提示揭示了你理解的质量。如果你的理解模糊，提示也会模糊，输出也会模糊。”
“如果我的理解很清晰——”
“提示就会清晰，Claude Code 也会完成出色的工作。”
她合上记事本。
“这就是我在第一次对话中说的，工具会放大你带给它的东西。没有哪里比提示更能体现这一点了。”
值得分享的假设
“你提到一个假设，”玛格丽特说。“验证逻辑可能在循环中执行数据库查询。你真的相信吗？”
“这最有可能，”蒂莫西回答。“验证步骤会把每笔交易与参考表逐条比对。如果它是一条记录一条记录地处理，而不是批量处理——”
“那就是 N+1 查询问题，”玛格丽特说。“四百万次单独的数据库调用，而不是少量高效的批量查询。”
“这就能解释一切。”
“确实能解释很多，”她看着他。“当你有假设时，要把它分享出来。不是因为 Claude Code 需要你的许可才能思考——而是因为你的假设本身就是信息。它告诉工具先去哪里查、哪些方法值得探索、哪些可能是死胡同。共享的假设 不是约束，而是礼物。”
蒂莫西看着屏幕上修改后的提示。
“我已经把礼物送出。”
“是的，你做到了。”玛格丽特露出淡淡的笑容。“如果你的假设错误，Claude Code 很可能会告诉你原因——这同样有用。分享你的思考并不会让你失去任何东西，只会让你收获更多。
在他发送之前
还有件事，玛格丽特说，就在蒂莫西正要按 Enter 键时。“大声朗读它。”
他抬起头。“请您再说一遍？”
“大声朗读提示。在你发送之前。”
他照做了——有点不自然，但很彻底。读到一半时，他停了下来。
“我说了两次 最近，”他说。
“你说了。”
“而且我从未指定结果写入哪个表。”
“没有。”
他在没有人要求的情况下自行完成了这两处更正。玛格丽特没有说话；她不需要说。
当他发送时，提示 简洁、精准、完整。Claude Code 的回复返回 详细、具体、直接有用——指出了可能的 N+1 模式，建议使用批量查询方法，并标记了另外两个值得调查的领域。
蒂莫西带着专注的表情阅读这些内容，仿佛完全理解了自己在看什么。
“它正好知道该去哪里查，”他低声说。
“因为你准确地告诉它该去哪里查，”玛格丽特回答。“这就是合作。你提供上下文和思考，它提供广度和速度。单靠任何一方都不够。”
她抬起茶杯。
“第一次提示并不是工作的开始，蒂莫西。它是 思考的结束。先把思考做好，后续的一切都会因此而更好。”
在外面，伦敦的下午照常进行。图书馆里，一位开发者刚刚学到一种能伴随他整个职业生涯的东西——不是技巧，也不是捷径，而是一种纪律。
在提问之前，先进行清晰思考的纪律。
下一集：玛格丽特和蒂莫西探讨 Claude Code 出错时的情形——自信、说服力十足且完全错误。如何捕捉看似答案的错误。
《Claude Code 的秘密生活》每隔一天在 tech-reader.blog 发布。
如果本系列对你有帮助，请分享给需要听到它的开发者。
Aaron Rose 是一名软件工程师兼技术作者，供稿于 tech-reader.blog。想观看解释视频和收听播客，请前往 Tech‑Reader YouTube 频道。