07-Claude Code Prompt 的结构化思维：让 AI 更懂你的需求

颜进强
93 阅读26分钟

Claude Code Prompt 的结构化思维：让 AI 更懂你的需求

上一篇我们聊了「指挥式 Prompt」的实战方式：把 AI 当成执行力很强的工程师，通过清晰的指令拆解，让它完成具体开发任务。

但真正开始使用 Claude Code 后你会发现：同样是发 Prompt，有些任务它能一次做对，有些任务却总是偏离预期。差别往往不在 AI 能力，而在于你是否把 Prompt 写成了一个“可执行的任务说明”。

前言：从“会指挥”到“会描述任务”

指挥式 Prompt 的核心，是让我们从“自己写代码”转向“指挥 AI 完成任务”。

但只会指挥还不够。AI 的判断来自大量训练数据和当前上下文，它会根据你给出的信息，去推断最可能正确的实现方式。

问题在于：如果你的描述不完整，AI 也会基于训练数据做判断，只是这个判断未必符合你的项目。

比如你说“优化一下首页”，Claude Code 可能会联想到性能优化、UI 调整、组件拆分、接口缓存等很多方向。每个方向在通用工程经验里都说得通，但不一定是你真正想要的。

所以，这一篇不继续讲“怎么指挥 AI 做事”，而是进一步讲：如何创建一个高质量 Prompt，让 Claude Code 更准确地理解任务、边界和验收标准。

一、为什么你的 Prompt 有时灵，有时不灵？

很多人第一次用 Claude Code 会觉得“确实快”，但用久了也会遇到另一个问题：明明已经写了 Prompt，Claude Code 做出来的结果却不太对。

同样是让 AI 辅助开发，为什么效果差别这么大？

一个关键原因是：Prompt 的质量，很大程度上决定了输出质量。

Claude Code 很强，但它不是读心术。它能不能准确完成任务，取决于你是否把这些信息讲清楚：

  • 要做什么？
  • 为什么要做？
  • 当前项目是什么情况？
  • 做到什么程度算完成？
  • 哪些事情不能做？

如果这些信息缺失，Claude Code 就只能“猜”。一旦任务需要靠猜，结果就会变得不稳定。

下面我会用一个真实的博客项目作为例子来讲。这个项目是一个 monorepo，包含：

apps/web/                 # 前端博客应用，React + Vite + TypeScript
services/backend/         # 博客业务后端，NestJS，包含文章、分类、用户等模块
services/auth-service/    # 认证服务，包含登录、注册、刷新 token 等能力
services/log-service/     # 日志服务
packages/shared-logging/  # 共享日志能力

用同一个项目举例，更容易看出 Prompt 结构化之后，Claude Code 的执行质量会发生什么变化。

二、一个好 Prompt 的四个核心要素

我把 Claude Code Prompt 拆成四个核心要素：

  1. 目标描述：你要 Claude 做什么？
  2. 上下文信息：Claude 需要知道什么背景？
  3. 质量标准：做到什么程度算完成？
  4. 约束条件：什么不能做？必须遵守什么？

可以简单理解为：

目标描述：做什么？改哪里？
上下文信息：为什么做？现在是什么情况？
质量标准：怎么判断做好了？
约束条件：边界在哪？雷区在哪里？

这四个要素不是为了把 Prompt 写长，而是为了让 Claude Code 少猜、少跑偏、少返工。

三、要素一：目标描述 —— 做什么？改哪里？

目标描述只回答一个问题：你要 Claude Code 做什么。

一个清晰目标通常包含三部分：

  • 动作：新增、修改、修复、重构、优化、删除、迁移等
  • 对象：某个功能、模块、函数、组件、接口、页面等
  • 范围：涉及哪些目录、文件、模块或业务边界

例子 1：前端功能开发

不推荐的写法
把博客首页优化一下。

这个 Prompt 的问题是太模糊了。

Claude Code 会不知道：

  • 优化什么？是 UI、性能、交互，还是接口请求？
  • 是改首页，还是改首页里的文章列表组件？
  • 是只改前端，还是需要后端接口配合？
  • 最终交付是什么？
更好的写法
在 apps/web/src/pages/Discover/routes/home/ 下新增「精选文章」模块，并在 apps/web/src/api/article/ 中补充对应接口方法。

功能需求：
- 复用现有 featured-article 组件风格，展示后端返回的 featured article 列表
- Discover 首页需要和现有 top-bar、category-tabs、featured-article 等页面结构保持一致
- 接口由 services/backend/src/article/ 提供，前端 API 方法放在 apps/web/src/api/article/ 下
- 支持加载中、空数据、接口失败等基础展示或兜底处理

质量标准：
- 页面能够正常展示精选文章列表
- 接口方法命名和 apps/web/src/api/ 下已有 API 风格保持一致
- 参照 Discover 首页已有模块的组件结构和代码风格
- 新增模块不影响首页现有文章列表和分类切换能力

约束：
- 不要改 Discover 的路由结构
- 不要重写已有 featured-article 组件
- 不要引入新的状态管理库或请求库

完成后做自查：页面展示是否符合需求 -> 接口调用是否对齐现有风格 -> 加载、空数据、失败场景是否处理。

这个目标就清楚很多：

动作：新增
对象：首页「精选文章」模块 + 前端 article API 方法
范围：apps/web/src/pages/Discover/routes/home/ 和 apps/web/src/api/article/
交付：页面展示精选文章列表，并接入后端接口

Claude Code 拿到这样的目标后，至少知道自己应该从哪里开始、要交付什么。

例子 2：后端 Bug 修复

不推荐的写法
文章详情接口有问题，你查一下。

这句话里面的信息太少。

文章详情有问题可能包括：

  • 接口 500
  • 查不到文章
  • 阅读数没有更新
  • 点赞状态不正确
  • 返回字段缺失
  • 前端路由参数传错

Claude Code 只能大范围排查，效率会很低。

更好的写法
修复 services/backend/src/article/ 下文章详情接口返回字段缺失的问题。

错误信息：ArticleDetail 页面底部操作区展示异常，接口响应中缺少 author、likeCount、isLiked 字段。

症状描述：
- 现象：文章标题和正文能展示，但作者、点赞数、点赞状态展示异常
- 影响范围：apps/web/src/pages/ArticleDetail/ 详情页
- 相关模块：文章详情页组件在 ArticleDetail/components/ 下，后端文章 DTO 在 services/backend/src/article/dto/ 下
- 频率：进入文章详情页时稳定出现

排查方向（供参考，不限于此）：
- 文章详情接口的查询字段是否遗漏 author、likeCount、isLiked
- services/backend/src/article/dto/ 下详情响应 DTO 是否缺少字段定义
- 前端 ArticleDetail 页面类型定义和接口响应字段是否不一致

修复要求：
- 找到根本原因，不只是前端兜底展示
- 文章详情接口返回字段满足 ArticleDetail 页面展示需要
- 字段命名和前端类型定义保持一致
- 不删除或重命名现有字段
- 不影响文章列表接口返回结构
- 不要把鉴权逻辑写进 article 模块，鉴权仍沿用现有服务能力

完成后做自查：字段是否完整返回 -> 详情页展示是否恢复正常 -> 文章列表接口是否未受影响。

这个 Prompt 包含了：

动作：修复
对象：文章详情接口返回字段
范围：services/backend/src/article/，必要时联动 apps/web/src/pages/ArticleDetail/
症状：详情页缺少 author、likeCount、isLiked，导致底部操作区展示异常

目标越明确，Claude Code 越容易进入正确的排查路径。

四、要素二：上下文信息 —— 为什么做？现在什么情况？

上下文是最容易被忽略的部分，也是决定 Claude Code 输出是否“贴合项目”的关键。

没有上下文时，Claude Code 只能按照通用最佳实践来处理。

有上下文时，它才能按照你项目里的真实情况来处理。

例子 3：代码审查

缺少上下文的写法
审查 services/backend/src/article/ 的代码质量。

Claude Code 可能会给你一些通用建议：

  • 命名是否清晰
  • 函数是否太长
  • 注释是否完整
  • 是否有重复逻辑

这些建议可能正确，但不一定有用。

提供上下文的写法
对 services/backend/src/article/ 的代码质量进行审查，并输出需要优先修复的问题。

背景：
- 这是博客项目的核心模块，负责文章列表、文章详情、点赞状态、用户文章列表等接口
- 后端使用 NestJS，DTO 集中放在 services/backend/src/article/dto/ 下
- 前端 ArticleDetail、Discover 首页、Search 页面都依赖这些接口返回结构
- 项目里还有 services/auth-service/，鉴权逻辑不要混进 article 模块

审查维度（不限于此，发现其他问题也要报告）：
1. 接口职责：article 模块是否只处理文章业务，是否混入认证等外部职责
2. DTO 边界：请求 DTO、响应 DTO 是否清晰，字段是否和前端依赖一致
3. 错误处理：文章不存在、无权限、参数非法等场景是否处理明确
4. 字段兼容：是否存在会影响 ArticleDetail、Discover、Search 的字段变更风险
5. 代码结构：service、controller、dto 的职责是否清楚，是否有明显重复逻辑

输出要求：
- 每个问题标注严重程度（高危/中危/低危）
- 优先指出会导致线上问题或联调阻塞的风险
- 每个问题给出具体文件、原因和建议修改方向
- 不需要纠结普通格式问题
- 不要直接修改代码，只输出审查报告
- 不要建议把 auth-service 的职责迁移到 article 模块

有了这些上下文，Claude Code 的审查重点会发生变化：

博客核心模块 → 重点关注文章链路是否稳定
NestJS + DTO → 检查 DTO 是否清晰、接口响应是否一致
前端多页面依赖 → 检查字段变更是否会影响 ArticleDetail、Discover、Search
鉴权独立服务 → 避免把 auth-service 的职责塞进 article 模块
审查目标明确 → 优先看职责边界、错误处理、字段兼容，而不是泛泛讲代码风格

同样是“审查代码”，有没有上下文，结果的针对性可能差很多。

例子 4：性能优化

缺少上下文的写法
优化文章列表接口性能。

Claude Code 可能会泛泛地建议：

  • 加缓存
  • 加索引
  • 做分页
  • 减少字段返回
  • 优化 SQL

但它不知道你现在的问题到底在哪里。

提供上下文的写法
优化 services/backend/src/article/ 下文章列表接口的性能。

当前情况：
- 当前问题：文章列表接口会返回正文 content，但 Discover 首页和 Search 页面列表只需要摘要类字段
- 使用场景：前端 Discover 首页和 Search 页面都会调用文章列表接口
- 请求特点：用户快速切换分类时，会触发多次列表请求
- 已有措施：apps/web/src/api/core/ 里已经有 request-cache 和 cancel-manager
- 可排查点：后端已有文章列表 DTO，可以优先检查 DTO 字段和查询字段是否过重

优化方向（供参考）：
- DTO 裁剪：列表接口不再返回前端列表页不需要的大字段 content
- 后端查询优化：只查询 title、summary、cover、author、likeCount、createdAt 等列表展示字段
- 前端请求层优化：复用已有 request-cache 和 cancel-manager，避免重复造缓存机制

要求：
- 对每个优化点给出：当前问题 → 优化方案 → 预期收益
- 列表接口响应字段和前端展示字段保持一致
- Discover 首页和 Search 页面功能保持不变
- 说明最终采用的是前端请求层优化、后端查询优化，还是 DTO 裁剪

约束：
- 不要新建一套请求缓存机制
- 不要影响文章详情接口完整 content 的返回
- 不要删除现有分页、分类筛选和搜索能力
- 不要过度优化，优先解决列表接口返回字段过重的问题

此时 Claude Code 的优化方向会更聚焦：

不用泛泛建议“加缓存”，因为前端已有 request-cache 基础能力
优先检查列表接口是否返回了不必要的 content 大字段
关注 Discover 和 Search 两个页面的重复请求场景
优先优化 DTO 和查询字段，再考虑更重的缓存方案
避免新造一套和 apps/web/src/api/core/ 重复的请求管理逻辑

上下文越具体，优化建议越精准。

五、要素三：质量标准 —— 怎么判断做好了？

很多人写 Prompt 时会忽略质量标准，因为他们默认 Claude Code “应该知道什么算好”。

但问题是：Claude Code 知道的是通用意义上的“好”，不一定是你当前项目需要的“好”。

质量标准的作用，就是把“好”变成可验证的完成条件。

例子 5：写测试

没有质量标准的写法
给底部导航组件写测试。

Claude Code 可能会写几个基础用例，比如：

  • 能正常渲染
  • 点击菜单触发回调
  • active 状态正确

能用，但可能远远不够。

明确质量标准的写法
给 apps/web/src/pages/Discover/components/bottom-nav/ 写单元测试。

测试范围：
- 底部导航正常渲染：覆盖首页、探索、收藏、个人中心等 tab 展示
- 当前选中 tab 高亮：覆盖 active 状态展示是否正确
- 点击不同 tab：覆盖路由跳转或回调是否被触发
- 无效 tab key：覆盖兜底行为，避免组件异常崩溃

质量标准：
- 参照现有 index.test.tsx 和 __tests__/BottomNav.test.tsx 的测试风格
- 每个关键行为至少有一个独立用例覆盖
- 只测试用户可感知行为，不测试组件内部实现细节
- 测试能够防止后续重构破坏导航行为

约束：
- 不要大范围重写已有测试
- 不要为了测试修改组件对外 API
- 不要引入新的测试库
- 测试之间不能互相依赖，每个用例独立运行

这样 Claude Code 就不需要猜：

  • 要测哪个组件？
  • 要按哪种测试风格写？
  • 要覆盖哪些行为？
  • 是测试实现细节，还是测试用户行为？

例子 6：接口文档生成

没有质量标准的写法
给文章模块写个 API 文档。

Claude Code 可能会生成一个格式正确但不贴合项目的文档。

明确质量标准的写法
为 services/backend/src/article/ 模块生成 API 文档。

文档要求：
- Markdown 格式，参照 docs/ 目录下已有文档的结构和详细程度
- 覆盖文章列表、文章详情、精选文章、点赞状态、切换点赞、用户文章列表接口
- 每个接口包含：
    - 接口路径和请求方法
    - 功能简介
    - 请求参数（参数名、类型、是否必填、说明、示例值）
    - 响应字段（字段名、类型、说明）
    - 成功示例和失败示例
    - 前端调用方说明

质量标准：
- 响应字段必须和 services/backend/src/article/dto/ 下的 DTO 保持一致
- 说明 ArticleDetail、Discover 首页、Search 页面分别依赖哪些接口
- 参数示例值贴近博客业务，不要使用 foo/bar/test 这类占位值
- 文档主要服务前后端联调，不写成外部开放平台风格

约束：
- 只写文档，不要修改任何代码
- 不要编造不存在的接口
- 不要把 auth-service 的登录注册接口写进 article 模块文档

这里有一个非常实用的技巧：

质量标准里最好用的一句话是：“参照 [现有文件] 的格式和详细程度”。

让 Claude Code 直接参考项目里的好例子，通常比你用文字描述格式更高效。

六、要素四：约束条件 —— 边界在哪？雷区在哪里？

约束条件的作用，是防止 Claude Code 做多余的事、错误的事，或者技术上正确但业务上不合适的事。

很多时候 Claude Code 给出的方案“看起来没问题”，但不是你想要的，原因就是边界没有讲清楚。

例子 7：后端字段变更

没有约束的写法
给文章表加一个 summary 字段。

Claude Code 可能直接去改数据库 schema，甚至顺手调整多个接口返回结构。

开发环境看起来没问题，但如果前端已有多个页面依赖文章列表和详情字段，随意调整会引发兼容问题。

明确约束的写法
对文章数据进行以下变更：新增 summary 摘要字段，并让文章列表接口返回该字段。

变更详情：
- 文章数据新增 summary 字段，用于列表页展示摘要
- 文章列表接口返回 summary 字段
- Discover 首页和 Search 结果列表优先展示 summary
- ArticleDetail 详情页仍然使用完整 content

要求：
- 如果涉及数据库 schema 或 Prisma model，需要说明 migration 影响
- 同步更新 services/backend/src/article/ 相关 DTO 和查询逻辑
- 文章列表接口返回 summary 字段
- 文章详情接口仍保留完整 content

约束：
- 只改 services/backend/src/article/ 相关逻辑，不要改 auth-service 和 log-service
- 不删除或重命名现有 title、content、cover、createdAt 字段
- 不要把详情页正文展示改成 summary
- 不要影响 ArticleDetail 和 Discover 页面已有字段依赖

完成后做自查：列表接口是否返回 summary -> 详情接口是否仍返回完整 content -> 现有字段是否保持兼容。

约束把“能做但不该做”的事情堵住了。

你不说“不要改详情接口”，Claude Code 可能会为了统一结构，把详情接口也改掉。

你不说“不要删除 content”，它可能会觉得列表有 summary 就不需要 content，从而影响已有页面。

例子 8：前端代码重构

没有约束的写法
把 Discover 首页代码重构一下，太乱了。

Claude Code 可能大刀阔斧地重构：

  • 拆组件
  • 改路由结构
  • 改 hooks 命名
  • 顺手调整 API 层
  • 把多个页面的公共逻辑抽出来

结果改动范围变大，回归成本也变高。

明确约束的写法
重构 apps/web/src/pages/Discover/routes/home/，改善首页代码组织。

当前问题：
- 首页入口文件堆积了较多展示逻辑和数据处理逻辑
- 页面包含顶部栏、分类 tab、精选文章、文章列表等多个区域，组件职责不够清晰
- 页面路由和主布局由 Discover 的 MainLayout 承担，重构时需要避免误改
- 底部导航在 apps/web/src/pages/Discover/components/bottom-nav/，已有测试覆盖，不属于本次重构范围

重构目标：
- 重构后页面视觉和交互保持不变
- 按职责拆分首页区域，让组件边界更清晰
- 首页入口文件不再堆积过多展示和数据处理逻辑
- 如需新增 hooks，放在当前页面 hooks/ 目录下

约束（重构的铁律）：
- 不修改 Discover 的路由结构和 MainLayout
- 不改 apps/web/src/pages/Discover/components/bottom-nav/
- 不改后端接口，只调整前端组件拆分和数据处理
- 不把页面私有逻辑抽到全局 hooks
- 不做大范围快照重写

执行方法：
- 先给出重构方案（怎么拆、拆成几个、每个职责），我确认后再动手
- 分步执行，每一步验证页面行为不变后再进行下一步

完成后自查：页面视觉和交互是否无变化 -> 路由和接口契约是否无变化 -> 组件职责是否更清晰。

重构场景的核心约束永远是：不要破坏现有行为。

具体到代码里，就是：

  • 路由结构不能随意变
  • 组件对外行为不能变
  • 已有测试覆盖的公共组件不要无关改动
  • 接口契约不能变
  • 改动范围要控制在目标模块内

七、综合实战：把四个要素串起来

单独看四个要素还不够，真正使用 Claude Code 时，最好把它们组合起来。

实战 1：紧急 Bug 修复

紧急场景下，上下文权重最高。Claude Code 需要快速理解“案发现场”，才能高效定位问题。

不推荐的写法
登录状态有 bug，赶紧修一下。
推荐写法
修复博客前端刷新页面后登录状态丢失的问题。

错误信息：用户登录成功后可以进入个人页，但刷新页面后又变成未登录状态。

症状描述：
- 现象：登录后页面内跳转正常，刷新页面后登录态丢失
- 影响范围：apps/web/ 前端登录态恢复逻辑，个人页受影响
- 出现时机：用户登录成功后刷新页面
- 频率：刷新后稳定出现

排查方向（供参考，不限于此）：
- apps/web/src/hooks/usePersistentUser.ts 是否正确恢复本地用户信息
- apps/web/src/api/user/ 下 token refresh 接口是否被调用
- services/auth-service/src/auth/ 返回结构是否和前端预期一致
- token 过期、refresh 失败、用户信息恢复失败等分支是否处理正确

修复要求：
- 找到根本原因，说明是前端持久化问题、token 刷新问题，还是接口返回结构问题
- 修复后刷新页面仍能保持登录态
- token 过期时应走 refresh 流程，refresh 失败时才退出登录
- 补充必要测试或至少说明验证步骤
- 不要把认证逻辑写死在页面组件里，优先复用 usePersistentUser 和 api/user
- 不要改 services/backend/ 的文章接口，这次只处理登录状态
- 不要把 refresh token 暴露到日志或页面输出里
- 不要为了修复问题删除现有错误处理逻辑

完成后做自查：是否解决登录态丢失根因 -> token refresh 分支是否正确 -> 是否没有泄露敏感 token 信息。

这个 Prompt 里，上下文写得最多，因为 Bug 修复的效率取决于 Claude Code 多快理解现场。

实战 2：从零开发新功能

新功能开发没有现成路径，所以质量标准和约束非常重要。

不推荐的写法
给博客加一个收藏功能。
推荐写法
在博客系统中新增文章收藏功能，支持用户收藏文章、取消收藏、查看我的收藏列表。

功能需求：
- 用户可以在文章详情页收藏文章和取消收藏
- 用户可以查看我的收藏列表
- 文章详情页需要展示当前文章已收藏/未收藏状态
- 未登录用户点击收藏时走现有登录引导逻辑，不允许直接收藏
- 接口错误时前端有明确反馈，不出现静默失败

相关上下文：
- 前端在 apps/web/，文章详情页在 apps/web/src/pages/ArticleDetail/
- 现有文章操作区在 apps/web/src/pages/ArticleDetail/components/ArticleActions/
- 后端博客业务在 services/backend/，文章模块在 services/backend/src/article/
- 后端已有点赞相关 DTO，例如 toggle-like、check-like-status，可以参考其接口风格
- 登录鉴权由 services/auth-service/ 负责，不要在文章模块里重新实现登录逻辑

质量标准：
- 后端提供：收藏/取消收藏接口、查询收藏状态接口、我的收藏列表接口
- DTO 命名和目录结构参照 services/backend/src/article/dto/like/ 下的点赞接口
- 前端 ArticleDetail 操作区展示收藏按钮，并能根据接口返回状态展示已收藏/未收藏
- Profile 或 Saved 页面能展示我的收藏文章列表
- 补充关键测试或提供清晰的手动验证步骤

约束：
- 使用项目现有技术栈和依赖，不引入新的状态管理库
- 不要把收藏功能和点赞功能合并成一个字段，二者业务含义不同
- 不要改现有点赞接口的请求和响应结构
- 文件结构保持和现有 article 模块一致，避免新建一套完全不同的目录风格

完成后做自查：功能是否逐条满足需求 -> 未登录和接口失败等边界情况是否处理 -> 是否没有破坏现有点赞功能。

这个 Prompt 的好处是：

  • 目标清楚：知道要做文章收藏功能
  • 上下文充分：知道前端页面、后端模块、可参考的点赞接口
  • 标准明确：知道接口、页面、状态展示和验证要求
  • 边界清晰：不引入新状态库，不破坏点赞接口，不混淆收藏和点赞

Claude Code 不需要猜产品范围，也不容易做过度设计。

八、万能模板：复制、填空、发送

不管是 Bug 修复、新功能开发、代码审查、性能优化，Prompt 的结构都可以复用。

你可以直接复制下面这个模板：

[动作][范围/模块]中的[对象/问题/功能]。

当前情况：
- [现象或背景，如 当前页面加载慢、接口字段缺失、模块职责混杂]
- [相关代码/模块，如 src/modules/article/、apps/web/src/pages/ArticleDetail/]
- [业务影响，如 影响文章详情页展示、影响前后端联调]
- [已知线索，如 最近一次发版后出现、某个接口返回结构变化]

需求/要求：
- [需求1，如 新增收藏/取消收藏能力]
- [需求2，如 查询当前文章是否已收藏]
- [需求3，如 我的收藏列表支持分页]
- [验收标准，如 刷新后登录态仍然保持]

质量标准：
- 参照 [已有文件/模块] 的结构和代码风格
- 覆盖正常流程和关键异常场景
- 输出或实现结果需要和现有接口、类型、页面展示保持一致
- [测试或验证要求，如 补充单元测试 / 提供手动验证步骤]

约束：
- 使用项目现有技术栈和依赖，不引入新的库
- 不影响 [不能动的模块/接口/页面]
- 不删除或重命名现有字段、方法、导出
- [其他边界，如 先给出方案，我确认后再执行]

完成后做自查：需求是否逐条满足 -> 边界情况是否处理 -> 是否没有引入回归。

需要注意的是：不是每次都要把四个部分写得很长。

简单任务可以只写目标和一两个约束。

但如果 Claude Code 没做对，回头检查一下，通常是某个要素没有写清楚。

九、不同任务类型的要素侧重

不同任务，四个要素的权重不一样。

任务类型重点要素博客项目里的典型例子
Bug 修复上下文刷新后登录态丢失、文章详情字段缺失
新功能开发质量标准 + 约束新增文章收藏、评论、消息通知
代码重构约束重构 Discover 首页、ArticleDetail 操作区
性能优化上下文优化文章列表接口、减少列表页大字段返回
代码审查上下文审查 article 模块、auth-service token 流程
写测试质量标准bottom-nav、ErrorFallback、文章操作区测试
数据结构变更约束新增 summary、收藏表、用户扩展字段
文档生成质量标准生成 article API 文档、前后端联调说明

简单总结：

Bug 修复：多写上下文，例如现象、影响页面、相关接口
新功能开发：多写质量标准和约束，例如接口范围、页面表现、不能破坏什么
代码重构：多写约束，例如路由不变、接口不变、视觉不变
性能优化：多写现状数据，例如哪个页面慢、哪个字段重、是否已有缓存
代码审查：多写背景和审查重点，例如模块职责、前端依赖、鉴权边界
写测试：多写覆盖范围，例如正常态、异常态、用户交互、已有测试风格
数据结构变更：多写风险边界，例如字段兼容、migration、历史数据
文档生成：多写参考样例和受众，例如给前后端联调看还是给外部用户看

十、进阶技巧：让 Claude Code 帮你补全 Prompt

有时候，你自己也不确定应该写哪些约束，也不确定上下文够不够。

这时可以先发一个初版 Prompt，然后加上一句话：

在开始实现之前，先列出你的执行计划、会涉及哪些文件，
以及你认为我还没说明但需要确认的问题。

Claude Code 会先输出：

  • 准备怎么做
  • 可能涉及哪些文件
  • 存在哪些风险
  • 需要你确认哪些问题

比如你只说：

给博客加一个收藏功能。

当前情况：
- 当前只确定要做文章收藏
- 页面入口、接口范围和数据结构还没有明确
- 还不确定收藏列表放在 Saved 页面还是 Profile 页面

需求/要求：
- 在开始实现之前，先列出你的执行计划
- 列出可能会涉及哪些文件和模块
- 列出你认为我还没说明但需要确认的问题

约束：
- 先不要写代码
- 先帮我补全需求问题清单
- 不要默认选择实现方案，未确认的问题先提出来

Claude Code 很可能会反问：

- 收藏是否需要登录？未登录点击如何处理？
- 收藏列表放在 Saved 页面还是 Profile 页面？
- 后端是否已经有收藏表，还是需要新增数据结构？
- 收藏按钮是否要和点赞按钮共用 ArticleActions？
- 是否需要支持取消收藏后的列表实时移除？

你看完后，再补充缺失信息。

这不是回到“手把手操作模式”，而是在正式开工前做一次“剧本围读”。

对于复杂任务，这一步往往能避免大量返工。

十一、总结

Claude Code 的能力很强，但前提是你要给它足够清晰的输入。

一个高质量 Prompt，通常包含四个要素：

目标描述：做什么？改哪里？
上下文信息：为什么做？现在是什么情况？
质量标准：怎么判断做好了？
约束条件：边界在哪？雷区在哪里？

再压缩成一句话：

目标让 Claude Code 知道方向，上下文让它理解现场，质量标准让它知道终点，约束条件让它避开雷区。

写 Prompt 的本质，不是把需求说得更长，而是把关键信息放到正确的位置。

当你的 Prompt 越结构化，Claude Code 就越像一个真正懂项目的工程师，而不是一个只会执行零散指令的工具。

avatar
文章
阅读
粉丝