为什么你的 Prompt 总是「差点意思」

从一个真实场景说起

很多人会这样写 prompt：

帮我优化一下这个项目的性能

然后得到一堆模棱两可的建议。于是去搜各种「Prompt 工程」技巧，加上角色扮演、few-shot 示例，结果还是差点意思。

我刚开始用 Claude Code 的时候也走过这条弯路。花了不少时间研究怎么写出更「高级」的 prompt，后来才意识到方向搞反了——问题根本不在 prompt 写法上，而在于我自己没想清楚到底要让它做什么。

市面上的教程教你各种花招：角色设定、输出格式约束、思维链引导… 这些技巧确实有用武之地，比如让 Claude 生成特定格式的文档、做翻译润色。但在日常工程开发中，它们的收益远不如另一件事：把需求想明白。

看看这三种 prompt 的对比，你就能感受到差距：

方式	Prompt	效果
[反例] 模糊	”帮我优化性能”	Claude 猜你要什么
[反例] 花哨	”你是一个高级性能优化工程师…”	多了角色设定，核心问题没变
[正例] 清晰	”首页 LCP 从 3.2s 降到 1.5s 以内。先分析 bundle 大小，找出最大的三个包”	Claude 知道具体目标和第一步

第三种 prompt 没有任何花哨的技巧，但它传达了两个关键信息：量化的目标和明确的第一步。这就够了。

与其记各种 prompt 模板，不如养成这三个思考习惯：

首先是明确目标。不说「优化」，而说「LCP 降到 1.5s」。不说「重构」，而说「把单文件组件拆成三个独立模块，对外接口不变」。目标越具体，Claude 的输出越精准。

其次是给出约束。约束听起来像是在限制 Claude，实际上是在帮它。「不改 API 接口，只优化前端」这句话能让 Claude 排除掉一大半不相关的方案，直奔主题。我的经验是，好的约束条件往往比好的 prompt 模板更能提升输出质量。

最后是拆到可执行。「优化性能」不可执行，但「分析 bundle → 找出最大的三个包 → 做代码拆分」每一步都可以直接动手。有一次我让 Claude「重构整个鉴权模块」，它给了我一个面面俱到但哪个也没做好的方案。后来我把任务拆成五个小步骤逐个喂给它，每一步的输出质量都高了一个档次。

说到底，与 Claude Code 协作的效率上限，不取决于你的 prompt 技巧有多花哨，而取决于你对问题的理解有多深。后面两课我们会展开聊任务拆解的具体方法。