夜雨聆风这两年用 AI 写代码的人，心态变化挺明显。
一开始大家关心的是：
哪个模型更强？
哪个工具补全更快？
哪段提示词能一次生成完整项目？
Cursor、Claude Code、Codex、Kiro 到底谁更好用？
但真正用久了会发现，问题不在这里。
工具越来越强之后，开发者反而更容易遇到另一个问题：
AI 很会写代码，但你不知道它到底改了什么。
它能一口气生成一大段逻辑，也能顺手改好几个文件。
它可以解释报错，也可以直接帮你重构。
它甚至能读取代码库、编辑文件、运行命令，像 Claude Code 官方描述的那样，把终端、IDE 和代码库任务连接起来。
这当然是好事。
但能力越强，越不能靠“随便问一句”来使用。
真正省时间的人，不是每天收藏一堆神级提示词，而是先建立了一套稳定工作流。
一、以前我们学提示词，现在要学工作流
以前用 AI 编程，很多人是这样问的：
帮我写一个登录功能。
帮我优化一下这个项目。
帮我重构这段代码。
帮我修复这个 bug。
这种问法不是完全不能用，但问题很明显。
AI 会自己补全很多上下文。
它不知道你的项目历史包袱；
不知道哪些接口不能变；
不知道哪些字段兼容老版本；
不知道这段逻辑背后有没有业务规则；
也不知道哪些文件根本不应该随便动。
所以它可能真的“帮你写完了”，但你后面要花更多时间检查。
这就是很多人开了 AI 编程工具之后，效率没有提升的原因。
不是工具不强，而是流程太松。
更稳的方式应该是：
先说清楚需求
再拆成任务
限定修改范围
让 AI 先给方案
确认后再写代码
运行测试
看 diff
最后人工 Review这才是 AI 编程进入真实项目后的基本姿势。
二、一个真实场景：不要让 AI 一上来写代码
假设你要做一个很常见的需求：
登录接口在 Redis 超时时，现在直接返回 500。希望改成明确错误码，方便前端提示用户稍后重试。
很多人的第一反应是，把报错贴给 AI：
这个登录接口报错了，帮我修一下。AI 大概率能给你一个修复方案。
但它也可能顺手做这些事：
改了登录接口返回结构；
加了一个你项目里没有的新依赖；
重构了鉴权模块；
把异常吞掉了；
为了让测试通过，改弱了测试断言。
这就是风险。
更好的问法应该是：
任务：修复登录接口 Redis 超时时返回 500 的问题。
限制：
1. 只允许修改 login.ts 和 redis.ts
2. 不要改变接口路径
3. 不要改变现有 JSON 响应结构
4. Redis 超时时返回 AUTH_CACHE_TIMEOUT
5. 不要新增第三方依赖
6. 修改后请列出变更文件和验证方式
先不要写代码，先给我修改计划。这一句“先不要写代码，先给我修改计划”，很重要。
AI 编程工具最容易失控的地方，不是不会写，而是写太快。
你要先让它慢下来。
三、AI 编程工具应该怎么分工？
现在工具很多，但不要混着用。
我更建议按任务阶段来分。
1. ChatGPT / Claude：适合讨论方案和解释代码
这类通用对话模型适合做：
需求澄清；
技术方案比较；
代码解释；
报错分析；
重构思路；
Review 清单。
比如你可以问：
我现在有一个登录接口 Redis 超时的问题。
请先帮我分析可能原因，并给出 3 种修复方案。
不要写代码，只比较方案优缺点。这一步的价值，是把思路理清楚。
不要一开始就让 AI 冲进项目里改文件。
2. Kiro：适合把需求拆成规格
Kiro 的官方定位更偏向 spec-driven development，也就是把提示词变成可执行 specs，再进入代码实现。官方文档里也提到，Kiro specs 用来把复杂功能拆成详细实现计划，并进行跟踪。
它适合做这些事：
requirements.md；
design.md；
tasks.md；
验收标准；
接口边界；
任务拆分。
比如：
请把“登录接口 Redis 超时处理”拆成：
1. 需求说明
2. 设计方案
3. 任务列表
4. 验收标准
5. 测试点这一步解决的是“我要做什么”。
3. Cursor：适合在 IDE 里结合上下文改代码
Cursor 官方把自己描述为 coding agent，强调可以把想法变成代码，并理解代码库上下文。
它更适合：
读项目结构；
找调用链；
局部修改代码；
根据现有风格实现；
边写边看 diff；
配合 IDE 调试。
比如：
请先阅读当前登录模块相关文件。
告诉我：
1. 登录入口在哪里
2. Redis 调用在哪里
3. 异常是在哪里被抛出的
4. 如果要增加 AUTH_CACHE_TIMEOUT，需要改哪些文件
先不要修改代码。Cursor 的优势不是“凭空写项目”，而是在已有项目上下文里改得更贴近工程实际。
4. Codex / Claude Code：适合边界明确的独立任务
Codex 和 Claude Code 更适合交给它们相对完整、但边界清楚的任务。
比如：
补测试；
修复一个 issue；
更新 README；
重构单个模块；
生成 PR 说明；
跑测试并总结失败原因。
Claude Code 官方介绍里明确提到，它可以读取代码库、编辑文件、运行命令。 这类工具越强，越要限制任务边界。
比较稳的指令是：
请完成一个独立任务：为登录接口 Redis 超时场景补充测试。
限制：
1. 只修改 tests/auth/login.test.ts
2. 不要修改业务代码
3. 不要降低现有断言
4. 测试必须覆盖 AUTH_CACHE_TIMEOUT
5. 最后输出测试命令和结果这才是适合 Agent 的任务。
四、真正省时间的，是固定这 6 步
我现在更推荐把 AI 编程流程固定成 6 步。
第一步：先写任务，不写代码
先把需求写成一句能验收的话：
当 Redis 超时时，登录接口应该返回 AUTH_CACHE_TIMEOUT，而不是 500。这句话越清楚，AI 越不容易乱发挥。
第二步：让 AI 先拆方案
不要直接写代码，先让它给方案：
请给出实现方案，不要写代码。
需要包含：
- 需要修改哪些文件
- 为什么改这些文件
- 是否影响接口兼容
- 需要补哪些测试
- 有哪些风险如果方案都说不清楚，代码大概率也不会稳。
第三步：限定修改范围
告诉 AI 哪些能改，哪些不能改。
允许修改：
- src/auth/login.ts
- src/lib/redis.ts
- tests/auth/login.test.ts
禁止修改：
- package.json
- 数据库迁移
- 鉴权主流程
- CI 配置
- 现有测试断言很多 AI 生成的大 diff，都是因为你没提前划边界。
第四步：再让 AI 写代码
确认方案后再写。
按上面的方案修改代码。
保持现有代码风格。
不要新增依赖。
修改完成后输出 diff 摘要。这一步才是“写代码”。
第五步：运行测试
提前告诉它跑什么命令：
修改后运行：
npm run test:auth
npm run typecheck
如果测试失败，先说明原因，不要直接改测试。注意最后一句：
不要直接改测试。
AI 为了完成任务，有时会把测试改弱。这个一定要防。
第六步：人工 Review 再合并
AI 写完以后，不要只看它的总结。
一定要看：
git diff --stat
git diff重点检查：
有没有改无关文件；
有没有改接口结构；
有没有吞异常；
有没有新增依赖；
有没有改测试断言；
有没有碰权限、支付、鉴权逻辑。
AI 可以帮你写代码，但最后负责合并的人还是你。
五、为什么很多人用了 AI，反而更累？
因为他们把 AI 当成“全自动开发者”。
这会带来三个问题。
1. 生成很多代码，但不好 Review
一个小 bug，AI 改了十几个文件。
看起来很努力，实际上很难合并。
开发里最贵的不是写代码，而是理解代码为什么这样改。
2. 代码能跑，但业务边界变了
AI 不知道你的历史兼容。
它可能觉得返回结构这样更合理，但前端已经依赖老结构；
它可能觉得字段名这样更清晰，但老接口不能改；
它可能觉得重构更优雅，但线上正在用。
这类问题不会马上报错，但会在后面变成事故。
3. 开了工具，却没有固定场景
很多人买了 AI 编程工具，但每天只是零散问问题。
今天问报错，明天问正则，后天让它写脚本。
每次都从零开始，当然很难真正省时间。
真正省时间的人，会把 AI 放进固定场景：
每次接新需求，先让 AI 拆任务；
每次改代码，先让 AI 读上下文；
每次提交前，让 AI 生成 Review 清单；
每次遇到报错，让 AI 先整理排查路径；
每次写完功能，让 AI 补测试点。
这就是工作流。
六、给开发者的一套 AI 编程模板
可以把下面这段保存起来，每次开新任务前用。
你现在是我的代码协作助手。
工作方式：
1. 先读需求，不要急着写代码
2. 先输出修改计划
3. 列出将修改的文件
4. 等我确认后再写代码
5. 不要修改无关文件
6. 不要新增依赖，除非提前说明原因
7. 不要删除或降低测试断言
8. 修改后输出变更说明、测试命令和风险点
当前任务：
【在这里写你的任务】
验收标准：
【在这里写清楚成功条件】
限制范围：
【允许修改哪些文件】
【禁止修改哪些文件】这个模板不复杂，但能减少很多问题。
它的核心不是“提示词多高级”，而是把工作流程写清楚。
七、AI 编程工具不是越多越好
很多人现在同时用：
ChatGPT；
Claude；
Cursor；
Kiro；
Codex；
Claude Code。
工具越多，越容易焦虑。
但真正成熟的用法不是每个都开，而是明确每个工具的位置。
可以这样理解：
ChatGPT / Claude：讨论方案、解释代码、做 Review
Kiro：拆需求、写 specs、生成任务列表
Cursor：在 IDE 里结合上下文改代码
Codex / Claude Code：处理边界明确的工程任务不要让所有工具都做同一件事。
否则你会得到五份不同答案，然后花更多时间比较。
八、会员和订阅只是最后一步
如果你长期使用 ChatGPT Plus、Claude Pro、Cursor、Kiro 这类工具，也可以把 gpt68.com 当作第三方 AI 会员充值平台入口之一去了解。
但要说清楚：
gpt68.com 解决的是订阅充值流程问题，不是 OpenAI、Anthropic、Google、xAI、Cursor、Kiro 的官方网站，也不是这些平台的官方授权合作方。使用前建议看清套餐说明、账号要求、到账说明和售后规则。
真正提升效率的，不是“开了多少会员”。
而是你能不能回答这几个问题：
你每周固定用 AI 解决哪些开发任务？
哪些任务交给 AI，哪些必须人工判断？
AI 能改哪些文件，不能改哪些文件？
测试怎么跑？
diff 谁看？
PR 怎么合并？
出错怎么回滚？
这些问题想清楚，工具才会变成生产力。
想不清楚，工具越多，反而越乱。
九、最后说句实话
AI 编程工具确实越来越强。
Cursor 能在项目里理解上下文，Claude Code 能读代码、改文件、跑命令，Kiro 能把需求拆成 specs，Codex 也越来越像能接任务的 coding agent。
但越到这个阶段，开发者越不能只学“怎么问”。
真正要学的是：
怎么拆任务；
怎么限制范围；
怎么让 AI 先计划；
怎么跑测试；
怎么看 diff；
怎么做 Review；
怎么把 AI 产物安全合并进项目。
以前我们说，会写提示词的人更会用 AI。
现在我更愿意说：
会建立工作流的人，才真正用上了 AI 编程工具。
工具负责提速。
流程负责兜底。
两者都需要，代码才能放心进仓库。