> For the complete documentation index, see [llms.txt](https://zhouhao4221.gitbook.io/haiqing-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhouhao4221.gitbook.io/haiqing-docs/01-thinking/passionate-coding-warning.md).

# 激情开发陷阱

## 问题

AI 让写代码变得极其容易。这本身不是坏事，但它放大了一种古老的失败模式：**激情开发**——被兴奋感驱动，跳过思考直接行动，用代码量代替进展的错觉。

在手写代码的年代，激情开发顶多让你多删几百行。在 AI 辅助开发的今天，十分钟就能生成几千行代码，方向跑偏的成本以同样的倍数放大。

***

## 什么是激情开发状态

以下信号同时出现三个以上，说明你已经进入激情开发状态：

* 连续向 AI 提交了超过 3 轮提示，没有停下来检查方向
* 说不清楚"完成"的验收标准是什么
* 知道代码在增长，但不知道它是否在解决正确的问题
* 跳过了约束确认，直接进入实现细节
* 遇到 AI 的错误输出时，第一反应是"再提示一次修"而不是"停下来想为什么"
* 感觉进展很快，但没有可以演示给别人看的东西

核心特征：**行动的速度远超理解的速度**。

***

## 为什么 AI 会让这种状态更危险

手写代码有自然的摩擦力：打字慢、环境配置麻烦、编译需要时间。这些摩擦虽然烦人，但会迫使你在遇到阻力时停下来思考。

AI 消除了这种摩擦。你的任何想法都能立刻变成代码，失败了再改，再改，再改。每一轮修改都带来"进展感"，而这种感觉本身会让人继续提示下去，即使整体方向已经错了。

**AI 不会质疑你的目标，只会执行你的指令。**

这意味着激情开发状态下的每一次提示，都是在用更快的速度走向错误的终点。

***

## 激情开发的触发条件

了解触发条件是为了提前识别，而不是回避兴奋感本身——兴奋感是能量，问题是它有时候会绕过判断。

**场景一：想法刚出来的时候** 新想法总是感觉很好。大脑在补全细节，填充空白，让它看起来比实际上更完整。这时候最想做的事是"先跑起来看看"，而不是"先想清楚"。

**场景二：卡住之后突然想通** 卡了很久，突然有了思路。解脱感和兴奋感叠加，大脑会想立刻行动，来不及验证这个"想通"是否真的正确。

**场景三：deadline 临近** 时间压力让人倾向于用行动代替思考，觉得"先写着"比"先想"节省时间。通常结果相反。

**场景四：AI 给出了一个看起来很好的方案** AI 生成的代码结构清晰、注释完整，很容易让人觉得它已经"搞定了"。这时候很难对着一个漂亮的输出说"等一下，这对吗"。

***

## 熔断规则

当以下任一条件触发时，停止提示，先回答后面的问题：

**条件 1**：连续提示超过 3 轮，没有执行或测试任何输出。

问：这 3 轮提示是在解决同一个问题，还是问题本身一直在变？

**条件 2**：你正在修复 AI 刚刚生成的代码里的 bug。

问：这个 bug 是边界情况，还是说明最初的方案方向就有问题？

**条件 3**：你不确定下一步该做什么，所以让 AI 来决定。

问：如果没有 AI，你会怎么分解这个问题？

**条件 4**：距上一次检验"这件事值得做"已经超过 30 分钟。

问：现在正在做的事，是最高优先级的事吗？

***

## 判断标准

不是所有快速行动都是激情开发。区别在于：

|        | 有节奏的快    | 激情开发           |
| ------ | -------- | -------------- |
| 方向     | 明确，不怀疑   | 模糊，靠做来验证       |
| 停下来的时机 | 主动，在交接点  | 被迫，被错误打断       |
| AI 的角色 | 执行已确认的方案 | 帮你想清楚你还没想清楚的问题 |
| 完成感来自  | 验收标准被满足  | 代码量在增长         |

激情开发不是努力，是用速度掩盖不确定性。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zhouhao4221.gitbook.io/haiqing-docs/01-thinking/passionate-coding-warning.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.