快速入门学习辅助

Desktop / CLI 高频样例

围绕 Claude Desktop app 和 claude CLI 整理的一组高频提示词、工作流和组合用法。

这页也是补充内容，不是官方原文。目标很简单：把你真正高频会遇到的任务，写成能直接照着试的样例。

下面这些样例默认有一个前提：你不是在“考 Claude”，而是在跟它结对。把任务背景、限制条件、验收标准一起说出来，通常比一句“帮我修一下”有效得多。

1. 刚进一个陌生仓库

先不要改代码。
请先读一遍项目结构，告诉我：
1. 这个项目是干什么的
2. 主入口在哪里
3. 核心业务模块有哪些
4. 我如果要改登录流程，应该先看哪几个文件

如果你在 Desktop 里用，接着可以补一句：

把你认为最关键的 5 个文件加到当前上下文里，并解释为什么。

这是我最常用的一种说法，特别适合复杂修改。

先别动代码。
先探索和分析这个问题的影响范围，给我一个分步骤计划。
计划里请包含：
1. 需要改哪些模块
2. 可能的风险点
3. 我应该重点看哪些测试
4. 你准备怎么验证结果

如果你在 Desktop 里，直接切到 Plan Mode 或权限配置里的计划模式，会更稳。

有个 bug：
用户在登录页输入错误密码后，会短暂闪一下然后回到空白页。

请你：
1. 先定位问题
2. 解释根因
3. 修复它
4. 运行相关测试或给出验证步骤
5. 最后总结修改了哪些文件

这一类请求里，最值钱的不是“修复”，而是你把症状和验收标准说清楚了。

我想重构这个模块，但不改变对外行为。
请先识别重复逻辑和过长函数，再给我一个小步提交式的重构方案。
每一步都尽量可验证、可回退。

如果仓库不小，CLI 里可以配合 worktree：

claude --worktree refactor-auth

这样你可以把重构和主线修改隔开。

请为这次修改补测试。
优先补最能覆盖回归风险的测试，不要机械追求覆盖率。
写完以后请说明：
1. 新增了哪些 case
2. 哪些边界条件还没覆盖
3. 为什么

这类提示会明显减少“表面上写了测试，实际上没挡住风险”的情况。

请 review 我当前分支的改动。
重点看：
1. 明确的逻辑错误
2. 可能的回归
3. 权限或数据安全问题
4. 缺失的测试

不要花太多篇幅讲代码风格。

Desktop 里可以直接结合 diff view 和 Code Review。CLI 里则更适合让它先看 git diff 和测试结果。

这是 Desktop 最舒服的一类场景。

请帮我改这个页面：
1. 保留现有设计语言
2. 提高移动端可读性
3. 把主 CTA 更突出
4. 改完后自己启动预览并检查关键交互

然后你可以继续补：

请再检查一下：
1. 首屏层级是否清楚
2. 表单是否容易出错
3. 按钮文案是否够直接

Desktop 的预览能力在这里非常有价值，因为 Claude 可以一边改一边自查。

CLI 里这类一次性任务特别适合 -p：

claude -p "解释 src/auth/session.ts 这个文件的职责"

或者把日志直接 pipe 给它：

cat app.log | claude -p "帮我总结报错模式，并判断最可能的根因"

这种用法适合：

claude -c

或者：

claude -r auth-refactor

适合这种场景：

如果你只是想“继承思路，但不要污染原会话”，可以配合工作树或 fork / branch 一类能力。

这是最容易被忽略，但提升最大的写法。

请实现这个需求，验收标准是：
1. 表单校验失败时有明确错误提示
2. 现有接口签名不变
3. 相关测试全部通过
4. 不引入新的依赖
5. 最终给我一个简短的变更总结

只要你给了“什么算完成”，Claude 的输出稳定性通常会好很多。

如果你发现自己反复在说这些话：

那就该看记忆机制和最佳实践了，把这些偏好沉到 CLAUDE.md 里。

我会这么分：

不是说只能这样用，而是这个分工最顺手。你真正在用的时候，常常是先在 Desktop 里定位和预览，再在 CLI 里做批量处理，或者反过来。

最后给你一个我觉得最稳的模板，几乎什么任务都能先这么发：

请先理解上下文，再执行。

任务目标：
<你要解决的问题>

限制条件：
<不能改什么 / 需要兼容什么 / 不要引入什么>

验收标准：
1. ...
2. ...
3. ...

执行要求：
1. 先探索并说明方案
2. 再动手修改
3. 修改后自行验证
4. 最后总结改动和风险

这不是“高级提示词技巧”，就是很普通的工程沟通。只是 Claude 对这种清晰沟通的响应，通常比人还稳定。