开发工作流 on Zampo Blog

给 Cursor 一个小需求，怎样让它先计划、再修改、再验收

Wed, 20 May 2026 10:39:00 +0800

这篇不讲安装，也不讲一堆按钮。

我们只做一件小事：给 Cursor 一个登录页，让它把页面视觉调得更像一个正式产品，但不允许它改业务逻辑。

任务很小，正好适合练手。小到你能看完所有 diff；也真实到足够暴露问题。很多人用 Agent 翻车，不是让它做了多复杂的架构，而是从一句“帮我优化一下页面”开始，最后发现字段、校验、接口路径都被顺手动了。

这一次不追求“让 Cursor 改得多快”。

我们只看一件事：它能不能按你的节奏走，分析、计划、执行、验收。

准备一个小到能验收的项目

我用的是一个最小登录页 demo，只有四个核心文件：

1
2
3
4
5


cursor-agent-demo/
├── index.html
├── style.css
├── login.js
└── tests/login.test.js

页面里有两个字段：邮箱和密码。

表单的业务契约也很明确：

1
2
3
4


<form id="loginForm" action="/api/login" method="post">
 <input id="email" name="email" type="email" required />
 <input id="password" name="password" type="password" required minlength="8" />
</form>

这次需求只允许改视觉层：背景、卡片、阴影、圆角、按钮质感。

不能改这些东西：

表单字段名
form action
请求路径
required
minlength
提交流程

如果你第一次练 Cursor Agent，我建议也从这种项目开始。不要一上来就让它改业务模块、重构页面、接新接口。项目越大，你越容易被一堆看起来很努力的 diff 淹没。

Agent 不是不能做大任务。

但你得先练会怎么管住小任务。

第一步：只分析，不许改

很多人给 Cursor 的第一句话是：

1

帮我优化登录页。

这句话太危险。

“优化”是什么？只改样式，还是改交互？能不能抽组件？能不能动校验？能不能顺手把 HTML 结构也重排？你没说清楚，Agent 就只能猜。

Cursor 真正难的不是安装，是别把 Agent 用成自动补全

Fri, 15 May 2026 18:45:00 +0800

你只是想让 Cursor 改一个登录页。

它很积极。顺手改了组件结构、路由命名、校验逻辑，还帮你重排了几个文件。

diff 很长，像是干了很多活。问题是你不敢合并。

这就是很多人用 Cursor 的真实卡点。不是不会安装，不是不知道 Chat 在哪，也不是模型不够强。

难的是：你得学会管住一个会主动行动的 Agent。

Cursor 的价值不在“让 AI 多写几行代码”。它真正改变的是开发者和代码库之间的关系。过去你是在编辑器里写代码，现在你是在编辑器里指挥一个会读文件、改文件、跑命令、解释 diff 的执行者。

如果还把它当成更聪明的自动补全用，结果通常只有两种：要么大材小用，要么放它乱跑。

低门槛，反而容易误判

Cursor 对 VS Code 用户很友好。

打开项目，侧边栏聊天，选中文件提问，让它解释一段代码，或者直接让它改一个小功能。这些动作都很自然。Cursor 官方文档里也把 Agent 定义得很直接：它可以完成复杂编码任务，可以运行终端命令，也可以编辑代码。

这很方便，但方便会制造一个错觉：装上就会用了。

实际上，装上 Cursor 只是打开了入口。真正决定结果的，是你怎么给它上下文、怎么限制改动范围、怎么验收输出。

很多人第一次用 Cursor，都会写这种 prompt：

1

帮我优化登录页。

这句话看起来没问题，实际问题很大。

“优化”是什么意思？改视觉，还是改交互？能不能动接口请求？能不能改路由？能不能顺手抽组件？改完怎么判断对不对？

你没说，Agent 就只能猜。

Agent 的可怕之处不是它不会做事，而是它太愿意做事。你给一个含糊任务，它会补齐你的空白。补得对，是惊喜；补得错，就是事故。

不要直接让它改，先让它只分析

我做了一个最小实测项目：一个纯 HTML/CSS/JS 登录页。

项目很小，只有这几个文件：

1
2
3
4
5


cursor-agent-demo/
├── index.html
├── style.css
├── login.js
└── tests/login.test.js

任务也很小：只调整登录页的视觉层，不改变字段、表单 action、请求路径和校验逻辑。

别让 Claude Code 一路狂奔：高手都在盯这 5 个地方

Fri, 08 May 2026 11:30:00 +0800

Claude 修一个 bug，顺手改了 12 个文件。

它删了旧组件，换了依赖，重写了一段状态管理。终端里日志飞快滚动，看起来很努力，也很专业。

你隐约觉得不对，但没按 Esc。

十分钟后，测试挂了，页面也挂了。最麻烦的是，你已经看不清它到底从哪一步开始跑偏。

很多人用 Claude Code 的进阶方式，恰好是错的：把权限开大，把确认关掉，把任务丢进去，然后等它“一路跑完”。这不是高手，这是把方向盘交出去。

Claude Code 真正好用的地方，不是它能连续工作，而是你能在它工作时不断校准。

真正的进阶，不是放手，而是会接管。

先理解它为什么会跑偏

Anthropic 的 Cal 在官方最佳实践分享里提到一个很关键的心智模型：Claude Code 很像一个“只用终端的同事”。

它不是靠提前索引整座代码库，然后从向量数据库里召回文件。按照官方分享里的说法，它更像一个新同事进入项目：用搜索、glob、grep、find 之类的方式，一点点探索代码库，看到结果后再决定下一步搜哪里。

这套方式很灵活，但也有代价。

它会不断读文件、跑命令、改代码，上下文越来越长，判断会受当前看到的信息影响。如果你一开始没给规则，中途不看计划，最后也不跑测试，它当然可能越走越偏。

所以 Claude Code 的进阶，不是让它更自由。

而是给它一条轨道。

第一个地方：CLAUDE.md，不是备忘录，是项目规则

很多人知道 /init 可以生成 CLAUDE.md，但写完就放在那里了。

这很浪费。

官方分享里说得很清楚：当你启动 Claude Code 时，如果当前工作目录里有 CLAUDE.md，它会被放进上下文里，作为开发者留给 Claude 的重要指令。

这不是“给 Claude 留一句备注”。

这是你给它的项目规则。

CLAUDE.md 里至少应该有三类信息：

类型	应该写什么	例子
项目结构	模块在哪里，测试在哪里，入口在哪里	`src/app` 是路由，`src/lib` 放业务逻辑
运行方式	怎么启动、测试、构建	`npm test`、`npm run typecheck`、`npm run lint`
工程约束	不能做什么，修改前要注意什么	不要引入新状态库；改 API 前先看兼容层

一个实用模板：