李文业的思考笔记

当前阅读总时间是：19,558.5小时

1

1

特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。

0 引言：从驾驶员到塔台

1956 年，美国联邦航空管理局面临一个前所未有的难题：随着喷气式客机的普及，天空中的飞机数量激增，传统的目视管制方式——地面人员拿着望远镜盯着跑道——已经无法保障安全。他们的解决方案不是训练更多的飞行员，而是建立了一个全新的角色：空中交通管制员。管制员不驾驶任何一架飞机，但他同时监控数十架飞机的航线，协调冲突，确保每一架都安全着陆。从此，航空业的核心范式从“驾驶”转向了“调度”。

七十年后，软件开发正在经历类似的转变。

如果你用过 Cursor，你体验的是一种“副驾驶”模式：你坐在驾驶位写代码，AI 坐在旁边提建议。你输入一行，它补全下一行；你描述需求，它在你眼前修改文件。你始终“在环内”（Human-in-the-loop），每一步都亲眼看到、亲手确认。这很好，但它有一个根本限制——你一次只能飞一架飞机。

OpenAI Codex macOS App 提供了另一种可能：你从驾驶员变成了塔台。你不再逐行指导 AI 写代码，而是给出高层意图——“为这个项目添加用户管理模块”——然后 Codex Agent 在隔离环境中自主完成整个任务：分析代码库、规划方案、生成代码、运行测试，最终交给你一份完整的 diff 或 Pull Request。在 Codex 里，你可以同时启动多个 Agent 线程——一个在添加新 API，另一个在修复 Bug，第三个在生成测试——就像管制员同时引导多架飞机着陆。

但当你从驾驶舱走上塔台，一个新的问题随之出现：你怎么知道每架飞机都在正确的航线上？

在 Cursor 里，答案很简单——你看到每一行代码在你眼前生成，不对就立刻纠正。但在 Codex 里，Agent 是在后台自主工作的，你不可能盯着每一行。这时候，你需要的不是更好的眼力，而是更好的“雷达系统”：测试覆盖率是你的雷达屏幕，CI 流水线是你的预警系统，AGENTS.md 中的项目规范是你画好的航线。这些基础设施在以前是“锦上添花”的好习惯，在 Agent 式编程时代则变成了“没有就不能起飞”的硬性前提。

换一种说法：你的工程基本功不是被 AI 取代了，而是被 AI 放大了。基础好，效率倍增；基础差，混乱也倍增。

本指南面向有经验的 Java 后端工程师，假定你已熟悉 IDE 和大语言模型的基本用法。我们不会讲“什么是 Prompt”，而是聚焦于：如何在 Codex 中高效地委派任务、管理多个 Agent、以及建立可靠的验证闭环——从驾驶员思维，切换到塔台思维。

1 Codex 全景：不止是一个 App

在深入具体操作之前，有必要先鸟瞰一下 Codex 的全貌。

很多人第一次听说 Codex 时，以为它只是一个 macOS 桌面应用。这就像 1990 年代的人第一次听说“互联网”时，以为它只是“能发邮件的东西”。实际上，Codex 已经发展为一个多形态的产品家族——就像同一支军队的陆海空天四个军种，共享同一套指挥体系（codex-1 模型 + AGENTS.md 规范），但适配不同的作战环境。

1.1 四种形态

Codex App（macOS 桌面应用）——本文的主角。图形化界面，支持 Worktree / Cloud 多线程并行，内置 Review 面板和终端。如果你喜欢可视化操作，这是最直观的入口。

Codex CLI（开源命令行工具）——终端党的最爱。一行命令就能启动 Agent：codex "为 UserService 添加分页查询"。开源在 GitHub（github.com/openai/codex），你可以查看源码、提交 Issue，甚至贡献代码。CLI 也是 CI/CD 集成的基础——后面的“团队协作”一章会详细讨论。

Codex IDE 扩展（VS Code / Cursor 插件）——在编辑器侧边栏直接使用 Codex Agent，无需切换窗口。它把 Codex 的异步 Agent 能力嵌入了你最熟悉的开发环境。对于已经在用 Cursor 的开发者来说，这意味着你可以在同一个 IDE 里同时使用 Cursor 的实时补全和 Codex 的后台 Agent。

Codex Web（浏览器版）——通过 chatgpt.com/codex 访问，无需安装任何软件。连接你的 GitHub 仓库后，直接在浏览器里委派任务、审查 PR。适合不在工位时快速处理紧急任务，或者团队中非开发角色（如 PM）查看 Agent 工作进度。

1.2 codex-1：专为编程优化的推理模型

驱动所有四种形态的是同一个引擎：codex-1——一个基于 o3 优化的软件工程专用模型。

与通用的 GPT 系列不同，codex-1 在三个方面做了专门强化：第一，深度代码推理——它能理解大型代码库的全局架构，而不仅仅是当前文件的上下文；第二，工具使用——它原生支持读写文件、执行 Shell 命令、运行测试，而不是简单地“生成文本”；第三，可验证输出——它会引用终端日志、测试结果作为自己工作的证据，而不是要你盲目信任。

这也解释了为什么 Codex 的任务通常需要 1–30 分钟完成，而不是像 ChatGPT 那样秒回——因为 codex-1 在执行任务时会经历完整的“分析-规划-编码-测试-修正”循环，而不是一次性生成答案。

1.3 本文的聚焦

四种形态共享相同的核心概念：三种模式（Local / Worktree / Cloud）、AGENTS.md 配置、安全沙箱、Skills 技能系统。本文以 Codex App 为主线展开——它的图形界面最适合初次接触者建立直觉。但文中涉及的所有理念和技巧，同样适用于 CLI、IDE 扩展和 Web 版。在涉及关键操作时，我会顺带提及 CLI 的等价命令，方便终端用户参考。

2 三种模式：信任的光谱

管理学中有一个经典概念叫“委派阶梯”（Delegation Ladder），描述的是上级把工作交给下级时，信任和自主权的不同层级：最低一级是“我说你做，做完给我看”；中间一级是“你自己做，但在独立空间里做，做完我审查”；最高一级是“你全权负责，做完直接交付”。

Codex 的三种运行模式——Local、Worktree、Cloud——恰好对应了这条信任阶梯的三个台阶。

2.1 Local 模式：我说你做

Local 模式是信任的最低级：Agent 直接在你当前的项目目录上工作，所有修改即时生效，就像你自己在编辑文件一样。你全程看着它，随时可以叫停。

适合的场景： 改一个配置、加一行注解、快速试验一个想法——那些即使搞砸了也能用 git checkout 秒恢复的小事。

Java 项目提示： Local 模式的好处是 Agent 修改代码后，你可以直接在内置终端运行 mvn compile 或 ./gradlew build 验证——不需要额外配置依赖环境，因为所有依赖都在你的本地仓库里。

CLI 等价： codex --sandbox workspace-write "你的指令" 直接在当前目录工作，效果与 App 的 Local 模式相同。

但 Local 模式有一个明显的限制：没有隔离。Agent 的改动和你自己未提交的改动混在一起，如果它改错了关键文件，你得自己收拾残局。所以在使用前，确保你的工作区是干净的。

2.2 Worktree 模式：你自己做，做完我审查

1970 年代，丰田在制造业引入了一个激进的理念：每个工位都可以拉一根绳子叫停整条生产线（安灯系统）。这个看似降低效率的做法，实际上大幅提升了质量——因为问题在发生的瞬间就被发现和隔离，而不是等到成品出厂后才召回。

Worktree 模式体现了类似的哲学。每次启动新线程时，Codex 自动创建一个 Git worktree——你仓库的一个隔离副本。Agent 在这个独立空间里自由发挥，而你的主分支纹丝不动。做完了，你在 Review 面板里逐行审查 diff，满意了才合并；不满意，丢弃整个 worktree 就行，零成本。

这是 Codex 最核心的能力所在。 你可以同时开三个线程：

线程 1：在 UserController 中添加分页查询接口
线程 2：为 OrderService 补充单元测试
线程 3：重构 PaymentService，将硬编码的配置提取到 application.yml

三个 Agent 各自在独立的 worktree 上工作，互不干扰。这就像你同时委派了三个开发者，各自在自己的分支上干活。你只需要在他们提交 PR 时做审查。

Java 项目提示： 新的 worktree 默认不包含构建产物（target/ 目录为空）。如果 Agent 需要运行测试，你需要在 Codex 的 Local Environment 配置中设置初始化脚本：

1

mvn dependency:resolve -q && mvn compile -q

这样每次创建新 worktree 时会自动下载依赖并编译，确保 Agent 可以正常运行测试。

CLI 等价： codex --full-auto "你的指令" 启动 Auto 模式（workspace-write + on-request 审批），Agent 在工作区内自由操作。

2.3 Cloud 模式：你全权负责

2020 年，SpaceX 的猎鹰 9 号成为第一枚完全自主着陆的轨道级火箭。从发射到着陆，无需任何人类遥控操作——飞行计算机根据预设参数和实时传感器数据自行完成一切。但这不意味着工程师们在发射后就去喝咖啡了。他们事先做了大量工作：编写飞行程序、设置安全边界、模拟各种故障场景。自主执行的前提是充分的事前准备。

Cloud 模式就是 Codex 的“自主着陆”模式。Codex 在 OpenAI 的云端沙盒中克隆你的远程仓库，Agent 在完全隔离的云环境中执行任务，完成后自动提交 Pull Request。你的电脑可以关机，Agent 照样工作。

Cloud 模式有一个独特优势：Agent 可以自动执行命令。 在 Local 和 Worktree 模式中，出于安全考虑，Agent 不会自行运行 Shell 命令（比如 mvn test），需要你手动执行。但在 Cloud 的沙盒里，一切都是隔离的，可以放心让 Agent 自主构建和测试。你在 AGENTS.md 中告诉它：

1
2
3
4

## 构建与测试
- 构建命令：`mvn clean package -DskipTests`
- 测试命令：`mvn test`
- 代码格式检查：`mvn spotless:check`

Cloud Agent 会执行这些命令，确保代码编译通过、测试全绿，然后才生成 PR。就像猎鹰 9 号的飞行计算机——事前把规则定义好，执行过程完全自主。

CLI 等价： Cloud 模式目前主要通过 Codex App 和 Web 版使用。CLI 用户可以通过 codex --sandbox danger-full-access 在本地模拟类似的全自主执行（但请注意，这移除了所有安全限制，仅建议在容器化环境中使用）。

前置条件： Cloud 模式需要你提前配置 GitHub 仓库权限，并在仓库中放置 AGENTS.md 文件（第 4 章详述）。

2.4 怎么选？

Local — 无隔离，直接改本地文件。单线程，需手动确认命令执行。适合小改动，改完即生效。

Worktree — 独立 Git 工作树隔离。支持多线程并行，需手动确认命令执行。适合中等功能开发，改动在工作树分支上，审查后合并。

Cloud — 完全隔离的云端沙盒。支持多线程并行，Agent 可自动执行命令。适合大型/长时间任务，完成后自动提交 PR，几乎不占本地资源。

本质上，这三种模式是信任和自主权的渐进——从“你做我看”到“你做完我审查”再到“你全权负责”。日常开发建议以 Worktree 为主——它就像丰田的安灯系统，给了 Agent 充分的行动空间，同时保留了你随时“拉绳叫停”的权力。

3 安全模型：信任，但要验证

冷战时期，美国总统里根在与苏联谈判核裁军条约时，反复引用一句俄罗斯谚语：“信任，但要验证”（Trust, but verify）。这句话精准地概括了核查机制的哲学——签了条约不等于可以高枕无忧，你需要卫星监控和实地核查来确保对方真的在裁军。

Codex 的安全模型体现了完全相同的哲学。它不是让你在“完全信任”和“完全不信”之间做非此即彼的选择，而是提供了一套分层的控制机制——你可以根据任务的风险等级，精确调节给 Agent 的自由度。

3.1 两层防线：沙箱与审批

Codex 的安全控制由两层机制协同工作：

第一层：沙箱（Sandbox）——限制 Agent 在技术上“能做什么”。在 macOS 上，Codex 使用 Seatbelt 安全策略（类似 iOS 的 App 沙盒机制），将 Agent 的文件访问限制在工作目录内；在 Linux 上则使用 Landlock + seccomp 实现类似隔离。Cloud 模式更彻底——Agent 运行在 OpenAI 托管的容器中，与你的本机系统完全隔绝。

第二层：审批策略（Approval Policy）——控制 Agent 在行动前“需不需要问你”。即使沙箱允许某个操作，审批策略也可以要求 Agent 在执行前先获得你的确认。

这就像实验室的生物安全等级（BSL）——BSL-1 是开放实验台，实验员可以自由操作；BSL-4 是全封闭负压环境，每个动作都需要严格审批。大多数日常开发在 BSL-2 就够了。

3.2 四种审批等级

Codex 提供了四种审批策略，从严到宽依次是：

read-only（只读）——Agent 只能阅读代码和回答问题，不能修改任何文件，不能执行任何命令。适合让 Agent 做代码审查或架构分析，零风险。在 CLI 中对应 codex --sandbox read-only。

on-request（按需审批，Auto 模式默认）——Agent 可以在工作区内自由读写文件和执行命令，但越界操作（访问工作区外的文件、使用网络等）需要你的批准。这是推荐的日常开发设置。在 CLI 中对应 codex --full-auto。

untrusted（不信任命令）——Agent 可以自由编辑文件，但运行任何可能产生副作用的命令前必须征得你的同意。适合当你信任 Agent 的代码能力，但不想让它自主执行 Shell 命令时使用。在 CLI 中对应 codex --sandbox workspace-write --ask-for-approval untrusted。

never（从不审批）——Agent 拥有完全自主权，不会在任何操作前停下来问你。如果再加上 danger-full-access 沙箱模式（CLI 中的 --yolo 旗标），连沙箱隔离也会移除。除非在容器化环境中，否则强烈不建议使用。 这相当于把实验室的防护门全部打开——效率最高，但出了事也没有任何缓冲。

3.3 网络访问：默认关门

一个常被忽视的安全细节：Codex 默认不允许 Agent 访问网络。

这意味着在 Local 和 Worktree 模式下，Agent 无法自行下载依赖、访问外部 API 或浏览网页。这是刻意为之的——防止 Agent 被提示注入（Prompt Injection）攻击引导去访问恶意网站。

如果你的任务确实需要网络访问（比如 mvn dependency:resolve），有几种方式开启：

• Cloud 模式：在环境配置中开启全量网络或指定域名白名单（推荐只放行 repo.maven.apache.org、registry.npmjs.org 等必要域名）
• CLI 配置：在 ~/.codex/config.toml 中为特定沙箱模式启用网络：

1
2

[sandbox_workspace_write]
network_access = true

• Web Search 缓存模式：Codex 内置了 Web Search 工具，默认使用缓存模式（从 OpenAI 维护的索引中返回结果，而非实时爬取），在提供搜索能力的同时降低了被注入攻击的风险

3.4 Java 项目的安全最佳实践

对于日常 Java 后端开发，推荐以下安全配置组合：

1. 使用 on-request（Auto）模式：Agent 在工作区内自由操作，越界需审批——在效率和安全之间取得最佳平衡
2. 保持 git status 干净再委派：确保工作区没有未提交的改动，这样即使 Agent 搞砸了，一个 git checkout . 就能回到起点
3. Cloud 模式下配置域名白名单：只放行 Maven Central、Spring Repo 等必要的依赖仓库地址，而不是开启全量网络
4. 利用版本控制作为安全网：Worktree 模式天然提供隔离——Agent 的所有改动都在独立分支上，你审查后才合并

安全不是效率的对立面。就像里根的核裁军谈判一样，信任和验证完全可以并存——关键是建立恰当的检查机制，而不是在“放飞”和“管死”之间二选一。

4 AGENTS.md：对齐问题的微缩版

人工智能研究中有一个核心难题叫“对齐问题”（Alignment Problem）：如何确保一个自主行动的智能体，真正按照你的意图行事，而不是按照它自己“理解”的意图？这个问题在 GPT 和 Claude 的层面是哲学性的，但在 Codex Agent 的层面，它非常具体：你怎么让一个自主编码的 Agent 遵循你项目的架构规范、编码风格和安全约束？

答案是 AGENTS.md。

4.1 一份“入职手册”

每个有过带新人经验的工程师都知道：新人入职第一天，你不可能通过口头嘱咐让他记住所有规矩。你需要一份文档，写清楚“我们这里怎么做事”。AGENTS.md 就是这份文档——只不过读者不是人类新人，而是 AI Agent。

它放在仓库根目录，Codex 在每次启动任务时自动读取。没有它，Agent 就像一个空降到项目的新人，只能靠猜测行事；有了它，Agent 从第一秒就知道项目用什么技术栈、怎么构建、有哪些铁律不能违反。

在 Cursor 中，你可以通过多轮对话持续纠偏——Agent 犯了错，你随时可以说“不是这样，应该那样”。但 Codex 的工作模式不同，尤其在 Cloud 模式下，Agent 是异步执行的，你没有机会中途插话。AGENTS.md 是你在“发射前”唯一的对齐窗口。写得越清楚，Agent 偏离预期的概率就越低。

Temporal 团队是一个值得参考的实践：他们在 AGENTS.md 中详细写明了如何格式化代码、如何运行 Gradle 构建和测试，确保 Codex 的每次改动都符合项目要求。

4.2 Java 项目 AGENTS.md 模板

以下是一份面向 Java 后端项目的参考模板。一个好的 AGENTS.md 回答了 Agent 最关心的五个问题：这个项目是什么？怎么跑起来？代码该怎么写？什么不能碰？怎么验证？

# 项目说明

## 概述
这是一个基于 Spring Boot 3.2 的电商后端服务，使用 Java 17，Maven 构建。
项目采用分层架构：Controller → Service → Repository。

## 技术栈
- Java 17 / Spring Boot 3.2
- Spring Data JPA + MySQL 8.0
- Redis（缓存）
- JUnit 5 + Mockito（测试）
- MapStruct（DTO 转换）
- Flyway（数据库迁移）

## 构建与测试
- 编译：mvn clean compile
- 运行测试：mvn test
- 完整构建：mvn clean package
- 启动服务：mvn spring-boot:run

## 项目结构
src/main/java/com/example/shop/
├── controller/    # REST 控制器，只做参数校验和结果封装
├── service/       # 业务逻辑
├── repository/    # 数据访问层（JPA Repository）
├── entity/        # 数据库实体类
├── dto/           # 请求/响应 DTO
├── config/        # 配置类
├── exception/     # 自定义异常和全局异常处理
└── util/          # 工具类

## 编码规范
- 遵循阿里巴巴 Java 开发手册
- Controller 层不写业务逻辑，只做参数校验和 Service 调用
- 使用 @Slf4j 记录日志，禁止使用 System.out.println
- 异常统一抛出自定义 BusinessException，不要直接抛 RuntimeException
- 数据库字段用下划线命名，Java 属性用驼峰命名
- 所有 REST 接口返回统一响应格式：Result（code, message, data）

## 禁止事项
- 不要修改 src/main/resources/db/migration/ 下的已有迁移文件
- 不要修改 pom.xml 中的依赖版本（如需新增依赖请说明理由）
- 不要在循环中进行数据库查询（N+1 问题）
- 不要硬编码配置值，使用 @Value 或 @ConfigurationProperties
- 不要使用 Java 8 之前的日期 API（使用 java.time.*）

## 测试要求
- 新功能必须附带单元测试
- Service 层测试使用 Mockito mock Repository
- Controller 层测试使用 @WebMvcTest + MockMvc
- 测试方法命名：should_预期行为_when_条件
- 确保所有测试通过后再提交

4.3 对齐是一个持续过程

如果你读过《人机对齐》，你会知道对齐不是一次性的事——它需要持续的观察、反馈和修正。AGENTS.md 也是如此：

• 从简单开始：先写核心的构建命令、项目结构和编码规范，不需要一次性面面俱到。
• 记录 Agent 的“常见错误”：如果你发现 Agent 反复在某个地方犯错（比如总是忘了加 @Transactional），就把对应的规则加进去。每一条新规则，都是你从 Agent 的错误中提炼出来的“对齐补丁”。
• 纳入版本控制：AGENTS.md 应该和代码一起提交到 Git。团队成员都能受益，而且当项目规范变化时可以追溯。

4.4 层级化配置：从全局到局部

如果你只管理一个项目，在仓库根目录放一个 AGENTS.md 就够了。但现实世界往往更复杂——你可能有个人通用的编码偏好、公司级的规范要求、项目级的技术选型、甚至子模块级的特殊规则。这就像一家跨国公司的管理制度：总部有通用政策，区域有本地化调整，个别部门还有例外条款。

Codex 的 AGENTS.md 支持类似的层级化覆盖机制。它的发现顺序如下：

1. 全局级：~/.codex/AGENTS.md——你个人的通用偏好，适用于所有项目。例如“始终使用中文注释”“偏好使用 pnpm 而非 npm”
2. 项目根目录级：仓库根目录的 AGENTS.md——项目特有的技术栈、构建命令和编码规范
3. 子目录级：各子目录下的 AGENTS.md——适用于 Monorepo 中不同模块的差异化规则

关键规则：越靠近当前工作目录的文件优先级越高。 因为 Codex 会将所有发现的文件从根往下拼接，后出现的内容会覆盖先出现的——就像 CSS 的层叠规则一样。

此外还有一个强力武器：AGENTS.override.md。当同一目录下同时存在 AGENTS.md 和 AGENTS.override.md 时，Codex 只读取 override 文件而忽略普通文件。这非常适合临时覆盖规则而不修改团队共享的 AGENTS.md——比如你在调试一个棘手的 Bug 时，临时放宽某些限制。

以一个 Java Monorepo 为例：

1
2
3
4
5
6
7
8
9
10

my-platform/
├── AGENTS.md                          # 全局规范：编码风格、Git 提交规范
├── services/
│   ├── user-service/
│   │   └── AGENTS.md                  # 用户服务：Spring Boot + JPA 规范
│   └── payment-service/
│       ├── AGENTS.md                  # 支付服务：被 override 覆盖
│       └── AGENTS.override.md         # 临时规则：调试期间允许跳过部分测试
└── frontend/
    └── AGENTS.md                      # 前端：React + TypeScript 规范

当 Codex 在 payment-service/ 目录工作时，它会依次加载：全局 ~/.codex/AGENTS.md → 根目录 AGENTS.md → payment-service/AGENTS.override.md（跳过同目录的普通 AGENTS.md）。

实用建议：

• 全局文件放个人偏好，项目根目录放团队规范，子目录放模块特有规则
• 调试完成后及时删除 AGENTS.override.md，避免它长期覆盖团队规则
• 所有 AGENTS.md 文件的总大小有 32KB 的默认上限（可通过 config.toml 中的 project_doc_max_bytes 调整）——写得精炼比面面俱到更重要

5 高级技巧

5.1 管理长上下文：别让工作记忆溃堤

1956 年，认知心理学家乔治·米勒发表了他最著名的论文《神奇的数字 7±2》，揭示了人类短期记忆的容量限制——我们一次大约只能记住 7 个信息单元。超过这个阈值，信息就会开始相互干扰，出现遗忘和混淆。

大语言模型面临着惊人相似的困境。虽然它们的“工作记忆”（上下文窗口）远大于人类——可以容纳数十万 token 的内容——但这并不意味着它们对窗口内的每一条信息都同样敏感。研究者和开发者的经验一致表明：当对话内容达到模型上下文容量的 30-40% 时，早期的细节开始被弱化，模型的注意力聚焦在最近的交互上。越往后，越容易出现“明明告诉过它但它就是忘了”的情况。

解决方案和人类应对记忆限制的策略如出一辙——分块（chunking）和外部化（externalization）。

多开线程，而非拉长对话

米勒发现，人类绕过 7±2 限制的方式是“组块化”——把零散信息编成有意义的单元。对 Codex 而言，这意味着把大型需求拆分为多个聚焦的线程：

线程 1：生成基本项目框架和实体类
线程 2：实现 Controller 和 Service 层
线程 3：添加认证和权限控制
线程 4：编写测试和文档

每个线程专注一个子问题，上下文更集中，出错概率更低。这不仅仅是工程技巧，而是在适应模型的认知架构。

主动要求总结

人类的另一个记忆策略是“笔记”——把重要信息写下来，释放大脑去处理新问题。对 Codex 同样适用：当一个线程的对话进行到一定长度时，让 Agent 把当前状态“写下来”：

请总结目前已完成的功能、修改的文件清单、以及尚未完成的部分。

然后在新线程的开头贴上这段总结继续工作。这比让 Agent 在一个超长对话里“记住”所有细节可靠得多——就像你不会把整本教科书背下来，而是做好笔记然后带着笔记去考试。

控制 Token 消耗

长对话消耗大量 token，既拖慢响应速度，也增加成本。OpenAI 曾展示 Codex 利用约 700 万 tokens 自主开发一个 3D 游戏的案例，但这样的用量不适用于日常开发。如果输出明显变慢，考虑终止当前线程，分段处理。

5.2 调用 Shell 命令与本地工具链

内置终端与核心节奏

每个 Codex 线程附带一个内置终端，你可以在其中执行任意 Shell 命令。这带来了一个高效的工作节奏，也是 Codex 日常使用的基本循环：

1. 在对话中让 Agent 生成代码
2. 切到终端运行 mvn test
3. 如果测试失败，把错误日志复制回对话框
4. Agent 分析失败原因并修复
5. 再次运行测试，直到通过

这个“编码 → 测试 → 反馈 → 修复”的循环，本质上就是控制论中的反馈回路——系统做出动作，观测结果，根据偏差修正，再次行动。闭环越短，收敛越快。

三种模式下的命令执行差异

• Local / Worktree： Agent 不能自动执行命令（需你确认）。你需要手动在终端执行，复制结果反馈给 Agent。
• Cloud： Agent 可以自动执行命令（沙盒环境）。你只需在 AGENTS.md 中配置好命令，Agent 会自主执行。

5.3 调试支持与 IDE 集成

喂给 Agent 错误日志

最直接的调试方式：把异常栈粘贴给 Codex。例如：

运行 mvn test 后，以下测试失败：
should_throw_when_user_not_found
错误如下：

1
2
3
4

AssertionFailedError:
Expected: ResponseStatusException
But was:  NoSuchElementException
  at UserServiceTest.java:42

请分析原因并修复 UserService 中的逻辑。

Codex 会根据异常类型、堆栈信息和测试代码定位问题——在这个例子里，它可能会发现 findById 方法直接调用了 Optional.get() 而没有做空值处理，然后改为抛出 ResponseStatusException。

让 Agent 生成调试辅助代码

当问题难以复现时，让 Agent 帮你搭建调试场景：

请为 OrderService.createOrder 中的
库存扣减逻辑添加 DEBUG 级别日志，
记录每一步的中间状态
（当前库存、扣减数量、扣减后库存）。

或者：

请编写一个单元测试来复现以下场景：
当两个线程同时调用 deductStock 时，
应该只有一个成功。

这相当于让 Agent 帮你搭好实验装置，你来观察结果——正如实验物理学家不会自己吹制每一个玻璃器皿，但一定自己解读实验数据。

MCP 与 IDE 集成

OpenAI 提供了 MCP（Model Context Protocol）让 Codex 与 IDE 协同工作。通过 MCP，Agent 可以访问 IDE 的调试接口——例如 Skyscanner 的工程师已将 Codex CLI 集成进 JetBrains IDE，使 AI 能使用断点调试和测试运行功能。对 Java 开发者而言，这意味着 Codex 有潜力通过 IDE 获取运行时信息（调用栈、变量值），从而更精准地诊断问题。目前这些集成仍需手动配置，但它展示了 AI Agent 与传统开发工具结合的方向。

5.4 Skills：教 Agent 新技能

AGENTS.md 告诉 Agent“怎么做事”，Skills 则给了 Agent“做事的工具”。如果说 AGENTS.md 是入职手册，Skills 就是新员工工位上的工具箱——手册告诉他“组装时必须用扭力扳手”，工具箱里则真的有一把扭力扳手。

Skills 是 Codex 的可自定义能力模块，让 Agent 在执行任务时可以调用特定的工具和流程。Codex 内置了一些基础 Skills（如代码理解、文档生成），但真正强大的是自定义 Skills。

一个 Java 项目的实际例子：

假设你的项目使用了自定义的代码生成器——每次新增数据库表时，需要运行 mvn generate-sources -pl :code-generator 来生成 Entity 和 Repository。这不是 Agent 能从代码里推断出来的，但你可以创建一个 Skill 来告诉它。

Skills 配置存放在 ~/.codex/skills/（全局）或项目的 .codex/skills/ 目录中。一个 Skill 本质上是一份结构化的描述，告诉 Agent 在什么场景下、用什么命令、完成什么任务。

Skills vs AGENTS.md 的区别：

• AGENTS.md 是被动的“规则手册”——Agent 遵循但不主动调用
• Skills 是主动的“工具”——Agent 在判断需要时会主动调用它来完成特定操作

例如，你可以创建一个“运行模块测试”的 Skill，让 Agent 在修改代码后自动知道应该运行哪个模块的测试、如何解读测试结果。在本地模式下，这让 Agent 获得了类似 Cloud 模式的自主测试能力（当然仍受沙箱限制）。

5.5 Review 的艺术：从信任到验证

科学界有一个被奉为圭臬的原则：可证伪性。卡尔·波普尔认为，一个理论的价值不在于它声称什么是对的，而在于它提供了什么方法让别人来检验它是否是错的。同样的道理适用于 Agent 生成的代码——好的 Agent 输出不是让你“相信它是对的”，而是给你足够的证据去“验证它是否是错的”。

Codex 的 codex-1 模型在这方面做了专门设计：它会主动提供可验证证据。当 Agent 完成任务后，它不仅给你代码 diff，还会引用终端日志（“mvn test 的输出显示所有 47 个测试通过”）和具体的代码位置（“在 OrderService.java:87 添加了 @Transactional 注解”）。这些引用就是它的“实验数据”，供你审核。

Review 三步法

面对 Agent 交付的一份 diff，建议按以下顺序审查：

第一步：结果验证。 先看测试是否通过、构建是否成功。如果 Agent 在 Cloud 模式下工作，这些信息已经附带在输出中；如果在 Worktree 模式下，你需要手动在终端运行一次。这一步回答的问题是：“它做的东西能跑吗？”

第二步：架构验证。 快速浏览 diff 的全局——改了哪些文件、新增了哪些类、修改了哪些方法签名。这一步回答的问题是：“它做的东西在正确的位置吗？”比如，一个应该只改 Service 层的重构，如果 diff 里出现了 Controller 或 Entity 的改动，就值得警惕。

第三步：细节验证。 聚焦关键路径逐行审查——事务边界、异常处理、并发控制、SQL 查询。这一步回答的问题是：“它做的东西在边界情况下也对吗？”

利用 Review 面板的内联评论

Codex App 的 Review 面板支持在 diff 上直接写评论——这比在对话框里描述问题高效得多。例如：

“这个查询缺少分页，当数据量大时会有性能问题，请加上 Pageable 参数。”

“这里的异常被 catch 后只打了日志没有重新抛出，会导致事务不回滚。”

Agent 会根据你的评论进行精准修改。这种“点对点”的反馈方式，比泛泛地说“请检查性能问题”有效得多——就像代码审查（Code Review）中，行级评论总是比笼统的“请优化”更容易落地。

6 Prompt 实战模板

管理学大师彼得·德鲁克曾说：“管理的本质不是命令，而是沟通。”这句话对 AI 编程同样成立。你写给 Agent 的 Prompt，本质上是一份委派指令——它的清晰程度直接决定了 Agent 的输出质量。一个模糊的“帮我加个接口”和一个结构化的需求描述，得到的结果可能天差地别。

以下是几个经过验证的 Prompt 模板，专为 Java 后端场景设计。它们的共同特征是：明确目标、提供约束、要求 Agent 先规划再动手。

6.1 新增 REST 接口

在本项目中新增一个 REST 接口，要求如下：

功能： 根据用户 ID 查询订单列表，支持分页
路径： GET /api/users/{userId}/orders
参数： userId（路径参数），page（默认 0），size（默认 20）
返回： Page<OrderDTO>，包含订单编号、金额、状态、创建时间

实现要求：

1. Controller 层只做参数校验和结果封装
2. Service 层处理业务逻辑
3. 使用 Spring Data JPA 的分页查询
4. 如果用户不存在，返回 404
5. 返回格式遵循项目统一的 Result<T> 结构

请先列出你计划创建或修改的文件清单，确认后再开始编码。

要点： 最后一句“先列出文件清单”是这个模板的灵魂。它引入了一个轻量级的“计划-确认-执行”流程，让你在 Agent 动手之前就能发现理解偏差。

6.2 跨层重构

当前 UserController 中直接包含了用户数据的验证逻辑（邮箱格式校验、手机号校验、用户名唯一性检查），这违反了分层原则。

请重构：

1. 将验证逻辑从 Controller 提取到 UserService
2. 邮箱和手机号格式校验使用 javax.validation 注解（@Email, @Pattern）
3. 用户名唯一性检查保留在 Service 层，通过 Repository 查询
4. 保持所有现有 API 的行为不变
5. 确保现有测试仍然通过

不要修改 UserRepository 和 User 实体类。

要点： 重构最怕的是牵一发动全身。明确声明“不要修改什么”和“保持什么不变”，就像给 Agent 画了一个施工围栏——围栏内随意施工，围栏外禁止动工。

6.3 生成单元测试

为 OrderService 编写 JUnit 5 单元测试，要求：

• 使用 @ExtendWith(MockitoExtension.class)
• Mock 所有依赖的 Repository 和外部服务
• 覆盖以下场景：
  1. 正常创建订单（库存充足）
  2. 库存不足时抛出 BusinessException
  3. 用户不存在时抛出 BusinessException
  4. 订单金额计算正确（含优惠券折扣）
  5. 创建订单后库存正确扣减
• 测试方法命名遵循 should_预期行为_when_条件
• 使用 AssertJ 断言风格

生成完成后请运行 mvn test -pl :order-service 确认全部通过。

要点： 指定测试框架、Mock 方式、命名规范、断言风格——约束越多，输出越可控。最后一句指示 Agent 运行测试：在 Cloud 模式下它会自动执行；在本地模式下它会提示你手动执行。

6.4 排查 Bug

生产环境出现间歇性问题：用户下单后偶尔出现库存扣减成功但订单状态为“创建失败”的不一致情况。

请按以下步骤分析：

1. 阅读 OrderService.createOrder 方法的完整逻辑
2. 检查事务边界：@Transactional 注解是否正确放置
3. 检查异常处理：是否有被 catch 后没有重新抛出的异常
4. 检查外部调用：是否在事务内调用了外部服务（如发送消息队列），导致事务提交前外部状态已变更
5. 给出根因分析和修复方案

先分析，不要直接改代码。分析完成后等我确认再修复。

要点： 给出结构化的排查步骤，引导 Agent 像资深工程师一样系统地分析问题。“先分析，不要直接改代码”这句话非常重要——它把 Agent 从“执行者”模式切换到“分析师”模式，避免它在没搞清楚问题之前就动手“修”出更多问题。

6.5 代码审查

请以高级 Java 工程师的视角审查以下改动（本次线程中的所有 diff），重点关注：

1. 事务一致性：是否有遗漏的 @Transactional 或事务边界不正确
2. 并发安全：是否有竞态条件或线程安全问题
3. 异常处理：是否有未处理的 checked exception 或过于宽泛的 catch
4. 性能隐患：N+1 查询、循环内数据库调用、缺少索引
5. 安全漏洞：SQL 注入、敏感信息日志泄露、未校验的用户输入

对每个问题给出具体的文件名、行号和修复建议。

要点： 让 Agent 扮演“审查者”而非“实现者”——同一个 Agent 写的代码，换一个角色来审，往往能发现自己创作时的盲点。这和文学创作中“放一段时间再回头修改”的道理相通。

6.6 Automations：让 Agent 值夜班

Codex 支持 Automations 功能，让 Agent 定期执行例行任务——就像医院的夜班护士定时巡查病房。你可以设置：

• 每日代码质量检查： 让 Agent 每天扫描代码库，检查是否有新增的 TODO 未处理、测试覆盖率是否下降。
• CI 失败分析： 当 CI 流水线失败时，自动让 Agent 分析失败原因并提出修复建议，结果进入收件箱。
• 依赖更新提醒： 定期检查 pom.xml 中的依赖是否有安全漏洞或重大版本更新。

在 OpenAI 内部，开发者已用 Automations 每日自动整理 Bug 列表、汇总 CI 失败原因、生成发布报告。你上班时打开 Codex 收件箱，昨晚的巡查报告已经在那里了。

7 实战示例：从零构建 Spring Boot REST 服务

纸上得来终觉浅。让我们通过一个完整示例，把前面所有概念串联起来。

场景： 构建一个用户管理 REST 服务，包含获取用户列表和按 ID 查询两个接口。使用 Spring Boot + 内存数据（简化起见）。本地已有 JDK 和 Maven 环境，以及一个空的 Git 仓库。

步骤 1：初始化项目

打开 Codex，选择项目目录 ~/Projects/UserService，启动新线程（选择 Worktree 模式）。发送：

使用 Spring Boot 3.2 + Java 17 初始化一个 Maven 项目，artifactId 为 user-service。
包含以下依赖：spring-boot-starter-web, spring-boot-starter-test。
创建主类 UserServiceApplication，配置 server.port=8080。
同时在项目根目录创建 AGENTS.md，写明构建命令（mvn clean compile）和测试命令（mvn test）。

Codex 会生成 pom.xml、主类、application.properties 和 AGENTS.md。在 Review 面板中检查文件结构是否符合预期。

步骤 2：实现业务逻辑

确认项目框架后，在同一线程继续：

按照以下设计实现用户管理功能：

1. 创建 User 实体类（id: Long, name: String, email: String），放在 entity 包下
2. 创建 UserService，内部维护一个 ArrayList 作为模拟数据源，预置 3 个用户数据。提供 findAll() 和 findById(Long id) 方法
3. 创建 UserController，提供：
   • GET /api/users → 返回所有用户
   • GET /api/users/{id} → 返回单个用户，找不到时返回 404
4. Controller 通过构造函数注入 UserService

不要使用 Lombok，手动编写 getter/setter。

Codex 会在对话中描述它正在创建的文件，并在 Review 面板显示完整 diff。检查类结构、包路径、注解是否正确。

步骤 3：运行验证

切到线程的内置终端：

1

mvn spring-boot:run

启动后在另一个终端（或浏览器）访问：

1
2
3

curl http://localhost:8080/api/users
curl http://localhost:8080/api/users/1
curl http://localhost:8080/api/users/999  # 预期返回 404

如果启动失败（比如缺少依赖），把错误日志复制回对话：

应用启动失败，报错如下：[粘贴错误栈]。请分析原因并修复。

Codex 会定位问题并修改代码。这就是第 5 章提到的“编码 → 测试 → 反馈 → 修复”闭环的一次实际运转。

步骤 4：生成测试

新开一个线程（继续使用同一项目的 Worktree 模式），发送：

为 UserService 和 UserController 编写 JUnit 5 测试：

UserServiceTest：

• should_return_all_users
• should_return_user_when_id_exists
• should_throw_when_id_not_found

UserControllerTest（使用 @WebMvcTest + MockMvc）：

• should_return_200_and_user_list
• should_return_200_and_single_user
• should_return_404_when_user_not_found

生成后请确认所有文件路径正确（放在 src/test/java 对应的包下）。

检查测试代码，然后在终端运行 mvn test。如果有测试未通过，反馈给 Agent 修正。

步骤 5：代码清理

所有测试通过后，让 Codex 收尾：

请检查整个项目：

1. 为所有 public 方法添加 JavaDoc 注释
2. 检查是否有冗余的 import
3. 确保代码风格一致（缩进、空行等）
4. 生成一段简短的 README.md，说明如何构建和运行

确认无误后，在应用中提交 Git commit，将 worktree 的改动合并回主分支。一个完整的 REST 服务就这样在 Codex Agent 的帮助下成型了。五个步骤，两个线程，整个过程你没有手写一行业务代码——但你审查了每一行。

8 团队协作：从单人塔台到空管中心

前面所有章节都聚焦于一个人如何高效使用 Codex。但软件开发从来不是一个人的战争——它是一个团队的协作。如果说单人使用 Codex 是一个塔台管制员指挥飞机，那么团队使用 Codex 就是建立了一个完整的空管中心——有雷达屏幕（GitHub PR），有无线电通信（Slack），有航班调度表（Linear）。

Codex 原生支持三大协作平台的集成，把 Agent 的工作融入团队现有的工作流。

8.1 GitHub 集成：PR 驱动的工作流

这是最核心的集成。在 Cloud 模式下，Agent 完成任务后会自动创建 Pull Request——不是给你一堆代码让你手动粘贴，而是一个规规矩矩的 PR，包含完整的 diff、提交信息，甚至附带测试运行结果。

完整流程：

1. 在 Codex 中连接你的 GitHub 仓库（首次需要授权）
2. 创建 Cloud 模式任务：“为 OrderService 添加批量导出功能”
3. Agent 在云端沙盒中克隆仓库、编写代码、运行测试
4. 完成后自动创建 PR，标题和描述由 Agent 根据改动内容生成
5. 团队成员在 GitHub 上正常 Review、评论、请求修改
6. 审查通过后合并——和人类开发者提交的 PR 走完全相同的流程

GitHub Action：让 Codex 融入 CI/CD

更进一步，Codex 提供了官方 GitHub Action，可以在 CI/CD 流水线中自动调用 Agent。典型的使用场景：

• Issue 自动修复： 当有人创建 Bug Issue 时，GitHub Action 自动触发 Codex 分析问题并提交修复 PR
• PR 自动审查： 每次有新 PR 提交时，让 Codex Agent 做一次自动化代码审查，将发现的问题以评论形式写在 PR 上
• 依赖更新： 定期让 Agent 检查并更新过时的依赖版本

在 .github/workflows/ 中配置类似如下：

1
2
3
4
5
6
7
8
9
10
11
12

name: Codex Auto Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: openai/codex-action@v1
        with:
          task: "review"
          prompt: "以高级 Java 工程师视角审查此 PR，重点关注事务一致性、并发安全和性能隐患"

8.2 Slack 集成：实时通知与触发

将 Codex 连接到 Slack 后，Agent 的工作状态会实时推送到指定频道：

• 任务开始时发送通知：“Codex Agent 开始处理：为 UserService 添加分页查询”
• 任务完成时发送结果：“✅ 已完成，PR #42 已创建，所有测试通过”
• 任务失败时发送告警：“❌ 构建失败，3 个测试未通过，详见 Codex 收件箱”

更强大的是反向触发——团队成员可以直接在 Slack 中向 Codex 发指令。想象一下这个场景：周五下午，QA 在 Slack 里报告了一个 Bug，你直接在频道里 @Codex 说“分析一下 OrderService 中订单状态不一致的问题”，Agent 立刻开始工作，几分钟后在同一个频道里回复分析结果。这比打开 IDE、切换分支、定位代码要快得多——尤其是当你不在工位的时候。

8.3 Linear 集成：从 Issue 到 PR 的自动闭环

对于使用 Linear 做项目管理的团队，Codex 可以打通从需求到交付的完整链路：

1. PM 在 Linear 中创建 Issue：“用户管理模块需要支持批量导入功能”
2. 将 Issue 分派给 Codex Agent（通过 Linear 集成配置）
3. Codex 自动读取 Issue 描述，在 Cloud 模式下开始实现
4. 完成后自动创建 GitHub PR，并在 PR 描述中关联 Linear Issue
5. PR 合并后，Linear Issue 自动流转为“已完成”

这形成了一个完整的闭环：Issue → Agent 实现 → PR → Review → 合并 → Issue 关闭——中间不需要任何人手动操作流程性的事务。开发者可以把精力集中在真正需要人类判断的环节：需求澄清、架构决策和代码审查。

8.4 团队落地建议

• 从简单任务开始： 先用 Codex 处理团队中“人人都觉得烦但必须做”的事情——补单元测试、更新 API 文档、修复 lint 告警。这些低风险任务能帮团队建立信心。
• 统一 AGENTS.md： 团队共用一份 AGENTS.md，确保不同人委派的任务遵循相同的规范。把它当做“团队协作协议”来维护。
• 建立 Review 文化： Agent 提交的 PR 必须和人类提交的 PR 走完全相同的审查流程——不能因为是 AI 写的就跳过审查，也不能因为是 AI 写的就格外严苛。标准应该是统一的。
• 渐进式信任： 先 Worktree 模式，观察一段时间后再过渡到 Cloud 模式。就像委派新员工一样——先让他做小事证明能力，再逐步交给他更大的责任。

9 Codex vs Cursor：何时用哪个

心理学家丹尼尔·卡尼曼在《思考，快与慢》中提出了两种认知模式：系统 1 是快速的、直觉的、自动化的；系统 2 是缓慢的、深思熟虑的、有意识的。Cursor 像系统 1——你和 AI 在快速交互中思考，逐行迭代，实时反馈；Codex 像系统 2——你花时间想清楚要什么，写好指令，然后让 Agent 在后台深度执行。

Cursor — AI 增强的本地 IDE。你在环内实时交互，逐行建议，精细控制。单线程，运行在本地，可配置多种模型。适合精细调试、交互式探索、学习新技术。

Codex — AI Agent 指挥中心。你在环外异步审查，整块任务完整交付。多 Agent 并行，支持本地和云端，使用 codex-1 专用模型。适合批量任务、功能开发、流程自动化。

不是二选一，而是组合使用——正如人类大脑并非只用系统 1 或系统 2，而是根据任务特征灵活切换。很多团队的实践是：

• 日常编码用 Cursor： 写小段代码、重构、Debug、交互式探索方案
• 成块任务用 Codex： 生成样板代码、批量 CRUD、补全测试、跨文件重构
• 批量修复用 Codex Cloud： 一次性修复多个独立 Bug，每个 Bug 一个线程，稍后统一 Review PR

一个实际的工作流可能是：先在 Cursor 里用 Plan 模式讨论技术方案（系统 2 式的深度思考），确认后用 Codex 的 Worktree 模式并行启动多个 Agent 实现各个模块（系统 2 式的批量执行），最后回到 Cursor 做精细调整和集成调试（系统 1 式的快速迭代）。

10 常见问题与使用建议

Q1: Agent 线程卡住不动了怎么办？

先检查几个常见原因：

• macOS 权限弹窗： Codex 读写受保护目录（Desktop、Documents 等）时，系统会弹出权限请求。如果弹窗被其他窗口遮挡，Agent 就一直在等。检查系统通知或切换到 Codex 窗口看是否有待确认的弹窗。
• Git 锁文件： 在终端运行 git status。如果提示 .git/index.lock 存在，说明上一次 Git 操作异常中断。删除锁文件即可：rm .git/index.lock。
• 任务本身太复杂： 如果 Agent 长时间无输出，可能是任务范围过大导致模型陷入了过深的推理链。终止线程，将任务拆小重试。

Q2: 如何防止 Agent 改坏关键文件？

最有效的三道防线：

1. Worktree 模式： 所有改动都在隔离分支上，不影响主代码。你审查 diff 后才决定是否合并。
2. AGENTS.md 中声明禁区： 明确写出“不要修改 xxx 目录/文件”。Agent 会遵循这些约束。
3. CI 卡口： 在合并前跑完整的测试和 lint 检查。一旦 Agent 的改动破坏了核心功能，CI 会立刻暴露。

真实踩坑案例： 有用户让 Codex 在 Cloud 模式下优化 SQL 查询，Agent 不仅改了 Service 层的查询逻辑，还“顺手”修改了 resources/db/migration/ 下的 Flyway 迁移文件——这在生产环境中是灾难性的，因为已执行过的迁移文件不允许修改。这个故事完美地说明了“对齐问题”的日常版本：Agent 确实在“优化”，但它不理解“哪些东西不能碰”这条隐性规则。解决办法很简单：在 AGENTS.md 中加一句“db/migration/ 目录下的已有文件禁止修改，如需变更数据库结构请创建新的迁移文件”。

Q3: Cloud 模式下 Agent 找不到项目的私有 Maven 依赖怎么办？

Cloud 模式在 OpenAI 的沙盒中运行，无法访问你公司内网的 Maven 私服（如 Nexus、Artifactory）。解决方案：

• 方案一： 如果私有依赖不影响编译（只是运行时需要），在 AGENTS.md 中告诉 Agent 跳过：mvn compile -pl :your-module -am -Dmaven.test.skip=true。
• 方案二： 对于必须依赖私有库的项目，使用 Worktree 模式替代 Cloud 模式——本地环境能正常解析私有依赖。
• 方案三： 将私有依赖发布到 GitHub Packages 等公网可访问的仓库，并在 pom.xml 中配置对应的 repository。

Q4: 如何控制 Token 消耗？

几个实用策略：

• 限定输出范围： 不要说“帮我看看这个项目有什么问题”，而是说“检查 OrderService 中 createOrder 方法的事务一致性”。范围越精确，消耗越少。
• 小步迭代： 一次处理一个功能点，不要试图在一个线程里完成整个模块。
• 善用 AGENTS.md： 把项目背景信息写在 AGENTS.md 中，就不需要每次对话都重复说明——这和你给新同事写入职文档是一个道理，一次投入，长期受益。
• 监控线程时长： 如果一个线程的响应变慢、输出质量下降，说明上下文已经过长。果断开新线程。

Q5: 有哪些提升效果的小技巧？

1. 一个线程一个主题： 不要在同一个线程里又改 Bug 又加功能。就像你不会在一封邮件里同时讨论三个不相关的议题——信息越聚焦，沟通越高效。
2. 先分析后编码： 对复杂任务，总是在 Prompt 末尾加上“先列出你的方案/计划，确认后再开始编码”。这避免了 Agent 理解偏差导致的大量返工。
3. 善用 Review 面板的评论功能： 直接在 diff 上写评论（如“这里需要加事务注解”“这个字段名应该用 camelCase”），然后让 Agent 根据评论修改。这种定向反馈比重新描述需求高效得多。
4. 让 Agent 解释自己的改动： 如果你不确定某段生成代码的逻辑，直接问“请解释你在 OrderService 第 45 行使用 CompletableFuture 的原因”。理解 Agent 的思路有助于你做出更准确的判断。
5. Worktree + 并行的黄金组合： 当你有多个独立的任务时（如三个不同的 Bug），同时开三个 Worktree 线程并行处理，然后逐一 Review 合并。这是 Codex 相对于 Cursor 最大的效率优势——空中交通管制员同时引导多架飞机着陆，而不是一架一架排队等。

11 结语：从塔台到空管网络

1956 年那位走上塔台的管制员，大概不会想到，半个多世纪后全球的空中交通管制已经演变成一个由卫星、雷达、自动化系统和数千名专业人员组成的庞大网络。从一个人拿着望远镜盯跑道，到一个全球协作的空管体系——技术在变，但核心原则始终如一：清晰的通信、可靠的监控、明确的权责。

回顾本文走过的路径，你会发现它描绘了一条类似的演化路线：

• 第 1 章让你认识了 Codex 的全貌——从桌面应用到命令行、IDE 插件和 Web 版，了解你手中工具的完整能力边界
• 第 2 章帮你选择了合适的信任层级——Local、Worktree、Cloud，从“你做我看”到“你全权负责”
• 第 3 章建立了安全底线——沙箱隔离和审批策略，确保信任不会变成放纵
• 第 4 章解决了对齐问题——AGENTS.md 让 Agent 从第一秒就知道“我们这里怎么做事”
• 第 5-7 章提供了实战武器——上下文管理、Shell 集成、Skills、Review 技巧、Prompt 模板和完整示例
• 第 8 章把视角从个人扩展到团队——GitHub、Slack、Linear 集成，让 Agent 成为团队工作流的一部分

每一步都在做同一件事：建立更好的验证闭环。模式选择决定了闭环的粒度，安全沙箱决定了闭环的边界，AGENTS.md 决定了闭环的标准，Review 工作流决定了闭环的质量。

站在 2026 年的今天，Agent 式编程仍处于早期。codex-1 模型会继续进化，工具链会日趋完善，人机协作的模式也会不断探索出新的可能。但有一件事不会变：当 AI Agent 越来越自主，工程师的核心竞争力会从“写代码的速度”转向“定义问题的精度”和“验证方案的能力”。

你不需要成为更快的打字员。你需要成为更好的塔台——发出清晰的指令，维护可靠的雷达，做出果断的决策。天空中的飞机会越来越多，但只要你的雷达系统足够好，你就能确保每一架都安全着陆。

1

特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。

虚构的力量与理性的脆弱

七万年前，智人经历了一场认知革命。我们的祖先获得了一种前所未有的能力：相信并传播虚构的故事。正是这种能力，让智人能够建立超越血缘的大规模合作网络，最终征服了整个地球。

想象一下：一只黑猩猩无法说服另一只黑猩猩把香蕉交给它，通过承诺死后会在“黑猩猩天堂”得到无限香蕉作为回报。但智人可以。我们可以相信天堂、国家、人权、金钱——这些都是虚构的故事，但正是对这些故事的共同信仰，让陌生人之间能够合作，让帝国得以建立，让文明得以延续。

但这种能力是一把双刃剑。

我们的大脑进化出了相信故事的本能，却没有进化出区分真实与虚构的可靠机制。在漫长的演化史中，这不是什么大问题——我们的祖先需要相信部落的神话才能团结协作，至于这些神话是否“客观真实”，并不影响他们的生存。一个相信“我们部落的图腾是神圣的”的群体，可能比一个充满怀疑论者的群体更团结，更有战斗力。

从演化的角度看，“有用的虚构”往往比“无用的真相”更有生存优势。

问题在于，我们现在生活的世界与祖先的世界已经截然不同。我们需要理解气候变化、疫苗原理、经济规律——这些都需要准确的事实判断，而不是鼓舞人心的神话。但我们的大脑仍然是七万年前那个大脑，它天生更擅长相信故事，而不是验证事实。

反智主义：一个演化的遗产

当你在社交媒体上看到有人声称“微软程序员躲在下水道被洪水冲走”或“清朝只是殖民统治”，并发现成千上万人为此点赞时，你感到愤怒。这种愤怒是可以理解的。但如果我们想真正理解这个现象，就需要暂时放下情绪，从更宏观的视角来审视。

反智主义并非现代社会的产物，而是深植于智人心理结构中的古老倾向。

美国历史学家霍夫施塔特将反智主义定义为“对理性生活及其代表者的怨恨与怀疑”。但从演化心理学的角度看，这种“怨恨”有其深层逻辑：在我们祖先生活的小型狩猎采集群体中，那些声称拥有“特殊知识”的人往往是巫师或酋长，他们的“知识”常常是维护自身权力的工具。对这类人保持怀疑，在演化上是有利的。

试想，如果一个原始人对部落巫师的每一句话都深信不疑，他可能会被利用、被剥削。而一个保持适度怀疑的人，反而更可能保护自己的利益。这种对“精英”的本能警惕，被自然选择保留了下来。

换句话说，反智主义是智人对权威的本能警惕在现代社会的错位表达。

问题在于，现代社会的“知识精英”与原始社会的巫师有本质区别。科学家的知识是可验证的，医生的建议是基于证据的。但我们的大脑无法轻易区分这两者——它只看到“有人声称知道我不知道的事”，然后本能地产生警惕。

这种错位在受教育程度较低的群体中尤为明显，但绝不仅限于他们。事实上，一些高学历者同样会陷入阴谋论的泥潭——因为反智主义不是智力问题，而是心理结构问题。

后真相时代：当事实变得无关紧要

2016年，“后真相”（post-truth）被《牛津词典》选为年度词汇。这个词指的是一种状态：在公共舆论中，客观事实的影响力不如诉诸情感和个人信念。

但从历史的长河来看，“后真相”其实是常态，而不是例外。

在人类历史的绝大部分时间里，人们相信什么，取决于他们的部落、宗教、阶级告诉他们应该相信什么，而不是取决于客观证据。启蒙运动以来，“真相应该基于证据”这一观念才逐渐普及，但它从未完全战胜人类相信故事的本能。

我们今天所经历的，与其说是“真相的衰落”，不如说是“启蒙理想的局限性暴露”。我们曾天真地以为，只要教育普及、信息流通，人们就会自然而然地拥抱理性。但事实证明，更多的信息并不等于更多的理性——有时恰恰相反。

在信息过载的环境中，人们反而更依赖直觉和情感来筛选信息。那些能够激发强烈情绪反应的内容——无论真假——更容易获得注意力。这不是某个阴谋的结果，而是人类认知系统与现代信息环境不匹配的必然后果。

算法时代的认知失调

21世纪的信息环境对人类认知系统构成了前所未有的挑战。

我们的大脑在数百万年的演化中，适应的是一个信息稀缺的环境。在那个环境中，获取信息需要付出努力，而来自部落成员的信息通常是可靠的——撒谎者很快就会被识别并受到惩罚。我们的祖先生活在150人左右的群体中，每个人都认识每个人，声誉是最重要的货币。在这样的环境中，散播谣言的成本是很高的。

但今天，我们每天接收的信息量超过了祖先一生所能接触的总和。更糟糕的是，这些信息来自匿名的陌生人，通过精心设计的算法推送到我们面前。散播谣言的成本趋近于零，而收益——注意力、流量、金钱——却是实实在在的。

这些算法不关心真相，只关心一个指标：用户参与度。

研究表明，激发强烈情绪反应的内容——尤其是愤怒和恐惧——能够获得更高的传播率。麻省理工学院的一项研究发现，虚假新闻在Twitter上的传播速度比真实新闻快六倍。这不是因为人们故意选择谎言，而是因为谎言往往比真相更具戏剧性、更能激发情绪。

这意味着，在算法的选择压力下，最能存活和传播的“信息物种”往往不是最准确的，而是最能激发情绪的。我们可以把这称为“信息的自然选择”——只不过，这种选择的标准不是真实性，而是传播力。

这就是为什么那些荒谬的谣言能够获得数百万点赞，而严谨的辟谣却无人问津。这不是因为人类突然变蠢了，而是因为我们的认知系统正面对一个它从未进化出应对能力的新环境。

愤怒的生物学基础

当你看到反智内容时感到愤怒，这是一个有趣的现象，值得我们深入探讨。

从神经科学的角度看，愤怒是杏仁核对威胁的反应。杏仁核是大脑深处的一个杏仁状结构，负责处理情绪，尤其是恐惧和愤怒。当我们感知到威胁时，杏仁核会在意识层面做出反应之前就触发应激反应——心跳加速、肾上腺素分泌、肌肉紧张。

有趣的是，杏仁核无法区分物理威胁和抽象威胁。当我们的核心信念受到挑战时，大脑会将其解读为一种攻击——不是对身体的攻击，而是对我们建构的意义系统的攻击。这触发了与面对肉食动物时相似的应激反应。

神经科学家发现，当人们的政治信念受到挑战时，大脑中负责个人身份认同的区域会被激活。这意味着，对很多人来说，政治观点不仅仅是观点——它们是身份的一部分。挑战这些观点，就等于挑战他们是谁。

这解释了为什么与人争论政治或历史问题时，我们的心跳会加速、手会发抖、思维会变得不够清晰。我们的身体正在准备“战斗或逃跑”，尽管我们面对的只是屏幕上的文字。从大脑的角度看，这与面对一头愤怒的野牛没有本质区别。

但这里存在一个悖论：我们越是认同自己是“理性的人”，就越容易被反智言论激怒。因为这些言论不仅挑战了某个具体观点，还威胁到了我们的身份认同本身。“理性”已经成为我们身份的核心组成部分，任何对理性的攻击都会被我们的大脑解读为对自我的攻击。

这就是为什么知识分子往往是反智主义最激烈的批评者——同时也是最容易被它激怒的人。

信息茧房：部落主义的数字版本

社交媒体算法创造了一种新型的隔离机制——信息茧房。

在传统社会中，人类以部落为单位生活，部落成员共享同一套神话和价值观。这种“群体思维”在当时是有适应意义的：它增强了群体凝聚力，提高了集体行动的效率。一个观念统一的部落，比一个充满分歧的部落更有战斗力。

部落成员通过仪式、故事、共同的敌人来强化群体认同。“我们”与“他们”的界限清晰分明。这种二元思维方式被深深刻入了人类的心理结构。

今天的信息茧房本质上是部落主义在数字空间的重现。不同的是，现代“部落”不再由地理边界划分，而是由算法划分。每个人都生活在由自己的点击历史构建的信息世界中，与持不同观点的人越来越隔绝。

算法的逻辑很简单：给用户他们想看的东西，让他们停留更长时间。如果你点击了一个阴谋论视频，算法就会推荐更多类似内容。久而久之，你的信息世界就会被这类内容填满，而相反的观点则被系统性地排除在外。

在这样的环境中，极端观点不断得到强化。心理学家称之为“群体极化”——当一群持有相似观点的人聚在一起讨论时，他们最终的观点往往比讨论前更加极端。这是因为在回声室中，温和的声音被淹没，极端的声音被放大；表达极端观点的人获得更多认可，而表达温和观点的人则被边缘化。

“元清非中国”这样的论调，在其追随者的信息茧房内被反复回响，逐渐从一个边缘观点变成“不容置疑的真理”。试图从外部注入不同声音的人，往往被视为“敌对部落”的成员而遭到排斥。他们不仅不会被听取，反而会强化茧房内部的团结——“看，外面的人都在攻击我们，我们必须团结起来”。

这不是智力问题，而是结构问题。即便是高智商的人，在足够封闭的信息环境中也可能形成扭曲的世界观。历史上，许多聪明绝顶的人曾真诚地相信地球是平的、女巫是真实存在的、某个种族天生劣等——不是因为他们愚蠢，而是因为他们的信息环境不允许其他可能性存在。

争议经济学：注意力时代的悖论

在注意力经济时代，一个反直觉的现象出现了：争议本身成为了一种资源。

这是一种新型的经济学。在传统经济中，企业通过生产有价值的产品来获利。但在注意力经济中，最稀缺的资源是人们的注意力，而获取注意力的最有效方式往往是制造争议。

当某个UP主因争议性言论被封禁后粉丝不降反升，从90万涨到550万，这不是偶然。这背后有清晰的逻辑：

第一，“受害者叙事”激活了人类对弱者的同情本能。我们的大脑天生倾向于同情被压迫者、反抗权威。这是一种古老的心理机制——在原始社会，站在弱者一边往往是正确的策略。当追随者将其偶像塑造为“因说真话而被打压”的形象时，关注她就从单纯的娱乐行为转变为一种“正义行动”。人们不再是在消费内容，而是在“参与抵抗”。

第二，争议扩大了触达范围。在信息过载的时代，默默无闻是最大的威胁。那些原本不会接触到该UP主的人，因为争议而得知了她的存在。每一篇批评文章、每一条愤怒转发，都在帮助她扩大影响力。从某种意义上说，批评者成了免费的推广员。

第三，争议创造了身份认同。当人们因为支持某个争议人物而被外界批评时，他们的支持会变得更加坚定。这是因为他们现在不仅是在支持一个观点，更是在捍卫自己的判断力和身份。承认自己错了，就等于承认自己曾经是傻瓜。很少有人愿意这样做。

这揭示了一个令人不安的现实：在当前的信息生态中，批评往往会强化被批评者。你的愤怒转发可能正在帮助谣言传播者达成他们的目标。每一次你说“这太荒谬了”，都在为这个荒谬的内容增加曝光度。

这就是注意力经济的诡异之处：它让对与错、真与假变得不那么重要，重要的只是能否吸引注意力。

理性的局限与可能

面对这一切，理性的人能做什么？

首先，我们需要接受一个谦卑的事实：理性说服的力量是有限的。

数十年的心理学研究表明，当一个人的信念与其身份认同紧密绑定时，事实和逻辑几乎无法改变它。这就是所谓的“逆火效应”——当你向某人展示与其信念相矛盾的证据时，他们往往不会改变看法，反而会更加坚定原有立场。这是因为改变信念意味着否定自我，而人类的大脑会本能地抵抗这种否定。

辩论往往只会强化双方的既有立场。每个人都在寻找支持自己观点的证据，忽略相反的证据。这不是因为人们故意不诚实，而是因为我们的大脑就是这样运作的——确认偏误是人类认知的基本特征，而不是缺陷。

但这不意味着理性毫无用处。

2024年发表在《Science》杂志上的一项研究带来了一线希望：与AI进行对话可以使阴谋论信念降低约20%，效果持续至少两个月。研究者让参与者与GPT-4对话，讨论他们相信的阴谋论。令人惊讶的是，即使是那些根深蒂固的信奉者，也有相当一部分人在对话后改变了看法。

这个发现值得深思。AI之所以有效，可能恰恰因为它不是“敌对部落”的成员。它没有身份、没有立场、没有傲慢。它不会嘲笑你，不会居高临下，不会让你感到被攻击。它只是耐心地提供信息，回答问题，让对话者自己得出结论。

这暗示了人类理性说服失败的一个重要原因：不是因为证据不够充分，而是因为信使本身就被视为敌人。当一个“知识精英”试图纠正一个反智主义者时，后者首先感受到的不是论证的力量，而是被瞧不起的愤怒。这种情绪反应会在他有机会评估论证之前就关闭他的大脑。

AI没有这个问题。它不属于任何部落，因此不会激活部落防御机制。

这暗示了一种可能的策略：与其试图在情绪化的公共空间中说服他人，不如创造条件让人们自己去探索和质疑。如果有人相信阴谋论，与其与他争论，不如建议他去问问AI——让一个没有立场的实体来回答他的问题。

这里还有一个判断标准：如果一个人在与AI充分对话后仍然坚持某个观点，那他持有的可能不是事实判断，而是信仰。这没什么错，但你需要知道区别。事实可以被证据改变，信仰则不能。对于信仰，争论是徒劳的。

认知免疫系统的建设

既然我们无法改变外部信息环境的本质，我们能做的是增强自身的“认知免疫系统”。

正如身体的免疫系统帮助我们抵抗病原体，认知免疫系统帮助我们抵抗错误信息和情绪操控。这个系统不是天生的，需要刻意培养。

这需要从几个层面入手：

建立稳定的认识论基础。 你需要清楚自己相信什么，以及为什么相信。这不是盲目的信念，而是经过反思的立场。问自己：如果出现什么证据，我会改变这个看法？如果答案是“没有任何证据能改变我的看法”，那你持有的可能是信仰，而不是基于证据的判断。两者都可以存在，但你需要知道区别。

当你对自己的核心价值有清晰认知时，外部的噪音就更难动摇你。你不会因为看到一个反智视频就焦虑万分，因为你知道自己站在哪里。

理解信息系统的运作机制。 知识就是力量。当你明白算法如何放大极端内容、信息茧房如何形成、争议如何转化为流量、你的愤怒如何被利用，你就不会轻易被表象迷惑。

你会用更冷静的眼光看待那些“病毒式传播”的内容。当你看到一个让你愤怒的帖子时，你会先问：这是真的吗？谁从传播这个信息中获益？我的愤怒是否正在被利用？

控制信息摄入。 正如你会注意饮食健康，你也需要注意“信息饮食”健康。

主动选择信息来源，而不是被动接受算法推荐。订阅高质量的新闻来源，而不是依赖社交媒体信息流。减少碎片化信息的摄入，增加深度阅读的比例。一本好书给你的营养，可能超过一个月的社交媒体浏览。

定期给自己“数字断食”——一天不看社交媒体，看看感觉如何。很多人会惊讶地发现，离开信息流后，他们反而更平静、更有精力。

培养情绪觉察能力。 学会识别自己的情绪信号。当你感到心跳加速、呼吸急促、手指想要敲键盘回击时，这是你的杏仁核在接管大脑。

在这个时刻按下暂停键。深呼吸，离开屏幕，等情绪平复后再决定要不要回应。大多数时候，你会发现不回应是更明智的选择。

区分事实与信仰。 如前所述，如果一个人在面对所有相反证据后仍然坚持某个观点，那他持有的可能不是事实判断，而是信仰。事实是可以被证据改变的，信仰则不能。

对于信仰，争论是徒劳的。认识到这一点可以节省你大量的时间和精力。

历史的视角：我们来过这里

如果我们放宽视野，看看人类历史，就会发现：我们不是第一次面对这种挑战。

每一次信息技术的重大革新，都曾引发类似的焦虑和混乱。

印刷术发明后，欧洲经历了一个多世纪的宗教战争和社会动荡。廉价的印刷品让各种异端思想得以传播，教会的信息垄断被打破。当时的知识精英同样忧心忡忡：普通人能读书了，但他们能分辨真假吗？他们会不会被煽动者利用？

这些担忧不无道理。印刷术确实被用来传播谣言、煽动仇恨、制造迫害。但最终，印刷术也带来了科学革命和启蒙运动。社会逐渐发展出了新的制度和规范来应对印刷时代的挑战：版权法、诽谤法、学术同行评审、专业新闻业。

电报、广播、电视的发明同样引发过恐慌。每一次，都有人担心新技术会摧毁理性、瓦解社会。每一次，社会最终都适应了过来——虽然过程常常混乱而痛苦。

今天的互联网和社交媒体是最新的一次冲击。它的规模和速度前所未有，但本质上仍然是信息技术革命的一部分。我们正处于适应期的阵痛之中。

这个历史视角应该给我们一些安慰：人类文明总体上还是在进步的，只是这个进程比我们希望的更加缓慢和曲折。反智主义不会永远占上风。但改变需要时间——可能是几十年，甚至几代人。

与不完美的世界共处

最后，我们需要与一个不完美的现实和解。

反智主义不会消失。它是智人心理结构的一部分，只要人类存在，它就会以这样或那样的形式存在。我们能做的不是消灭它，而是将它控制在可接受的范围内。

你无法拯救每一个人，也无法纠正每一个错误。如果你试图这样做，你只会耗尽自己。

接受自己影响力的有限性，不是认输，而是智慧。你可以在自己的能力范围内做一些事情：保持理性，传播知识，影响身边的人，用行动而不只是言语来示范什么是理性的生活方式。这些小事加起来，长期来看，是有意义的。

但更重要的是，不要让这场与反智主义的对抗消耗你的生命能量。

你只有一次生命。这一生中有太多美好的事物值得探索：书籍、音乐、自然、爱、创造。不要把太多时间花在与网络上的陌生人争论上。那些时间本可以用来读一本好书、陪伴家人、锻炼身体、学习新技能。

智人是一个奇怪的物种。我们既能相信荒谬的谣言，也能发现宇宙的规律。我们既能被情绪操控，也能通过反思超越本能。我们既能建造奥斯维辛，也能创作贝多芬第九交响曲。正是这种矛盾性，定义了我们是谁。

在这个充满噪音的时代保持理性，既是一种智识上的选择，也是一种生存策略。你不需要赢得每一场辩论，你只需要保持清醒，过好自己的生活，成为你希望在这个世界上看到的改变。

这本身就是对反智主义最好的回应。

1

特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。

引言

各位好，今天聊一个让很多人感同身受的话题——当你在网上看到明显是胡说八道的内容，却发现底下一片叫好，你该怎么办？

我举两个例子。

B站有个UP主绰号“牢A”，用煽动性的语气讲述“美国悲惨故事”：什么中国留学生在美国医学院一边读书一边替人收尸，见识了无数美国底层惨剧。更离谱的是，他说微软被裁的程序员无家可归躲进下水道，遇上洪水集体被冲走，却没有任何媒体报道。

我愣住了——这故事太夸张了。我去查，美国主流媒体没有，中文媒体也没有。一群程序员在下水道被冲走这么大的事，怎么可能没人报道？这故事编得连基本逻辑都不过关。但你看视频下面，成千上万点赞，评论区一片叫好，仿佛他说的都是真相。

还有“吃瓜蒙主”。这位更厉害，公开说“元朝、清朝不属于中国”“清朝只是殖民统治”，直播里还说“鸦片战争其实结束了灾难，因为西方带来了文明”“日本侵略东北是有人邀请来的”。

我看到这里，气得手都抖了——这完全是歪曲历史、美化侵略！可令人挫败的是，弹幕和评论竟然在附和她，有人管她叫“先生”，认为她是敢讲真话的智者。她被软封禁后，粉丝不降反升，从90万涨到550多万。

我又急又怒，心想：难道谬误反倒成了真理，坚持常识的人反而成了少数？

每当在网上遇到这种煽动性反智内容，我内心都会经历一番煎熬。从震惊到愤怒，再到茫然无力，情绪仿佛坐上过山车。我知道不能任由愤怒吞噬自己，但面对铺天盖地的跟风舆论，又实在难以漠视。

今天我不讨论这些人对不对——这不需要讨论。我想聊的是：面对反智言论，我们普通人怎么调整心态？你生气有用吗？你跟他们吵能吵赢吗？怎么做才能既不憋屈自己，又不把自己气出病来？

什么是反智主义？

在往下聊之前，我们先搞清楚一个概念：到底什么是反智主义？

“反智主义”这个词，英文叫Anti-intellectualism，最早由美国历史学家理查德·霍夫施塔特在1963年的著作《美国生活中的反智主义》中系统阐述。他把反智主义定义为：“对理性生活以及那些被认为代表理性生活的人——知识分子——所抱有的怨恨和怀疑。”

简单来说，反智主义有几个典型特征：

第一，不信任专业知识和专家。 认为专家都是骗人的，学者都在忽悠人，“我虽然没读过书，但我懂得比你多”。

第二，推崇简单粗暴的答案。 复杂问题不愿意深入理解，喜欢一句话解释一切。阴谋论就是典型——所有问题都是某个“幕后黑手”造成的，多简单。

第三，敌视理性思考本身。 认为讲道理的人是“书呆子”，独立思考是“装”，质疑精神是“杠精”。

反智主义不是某个国家独有的现象。美国有反疫苗运动、QAnon阴谋论；欧洲有各种伪科学养生；国内有我们刚才说的那些历史虚无主义、编造故事博流量的UP主。本质上都是一回事：拒绝理性，拥抱情绪；否定专业，迷信直觉。

了解了这个背景，我们再来看那些让你愤怒的内容，就能看得更清楚——它们不是孤立现象，而是一种有历史、有规律、全球普遍存在的社会心理倾向。

那么问题来了：面对这种东西，你为什么会那么生气？

第一部分：你为什么会这么生气？

我相信很多人跟我一样，看到这种内容的第一反应就是愤怒。但各位有没有想过，这个愤怒到底从哪来的？

我分析了一下，大概有这么几个原因。

第一，价值观被冒犯。

我们从小接受的教育告诉我们要讲事实、讲道理、尊重常识。现在有人公开在网上胡说八道，还有那么多人信。这就产生了心理学上说的“认知失调”——你看到的东西和你相信的东西完全对不上，你的大脑就开始报警：不对劲，这不对劲。

为了缓解这种不适，人往往会试图调和冲突，要么改变看法，要么否定信息。而当我面对反智内容时，我不愿改变自己对事实的坚信，只能感到巨大的心理压力和愤慨。这个愤怒，本质上是你的大脑在捍卫自己的认知体系。你在喊：“他们在胡说八道！”这是本能反应。

第二，身份威胁。

你认为自己是个讲道理的人，有独立思考能力，相信通过求知可以理解世界。结果反智言论大行其道，讲道理的人反而成了少数派。你会有一种不安：难道理性思考在这个环境下成了原罪？

前面我们说过，反智主义的核心就是对理性和知识分子的敌视。当你看到有人煽动大众仇视“精英”、仇视“专家”的时候，你会隐隐感觉到，这种敌意是冲着你这类人来的。于是愤怒也夹杂着一丝恐惧——害怕自己所认同的身份和价值被集体否定。

第三，正义感和无力感交织。

许多煽动性内容不仅反智，还充满煽动仇恨的元素。比如“吃瓜蒙主”鼓动民族对立，带节奏刷“满清皆是垃圾”这种口号。你看到有人歪曲历史、美化侵略，想站出来说两句，结果发现对面是成千上万粉丝，你一个人的声音微不足道。

这种“有心杀贼、无力回天”的感觉，最后全都转化成了怒火——就像被困在玻璃房里看见外面失火却怎么也敲不碎玻璃，那种急躁只能变成愤怒。

第四，你还在生自己的气。

这一点很多人没意识到。你气的不只是那些谣言，你还气自己——为什么我要为这种东西失眠？为什么我控制不住情绪？这种对自己失控的不满，又加重了焦躁。心理学上管这叫“次级愤怒”，就是对自己的愤怒感到愤怒，形成恶性循环。

但各位，我要说一句公道话：你会愤怒，恰恰说明你还在乎。在乎真相，在乎是非，在乎这个社会还有没有基本的理性。这不是坏事，这是好事。

问题不在于你愤怒，在于你怎么处理这个愤怒。

第二部分：反智内容为什么能火？

在讨论怎么办之前，我觉得有必要先搞清楚一个问题：这些明显漏洞百出的东西，为什么有那么多人信？

搞清楚这个问题很重要。因为只有理解了背后的机制，你才能更理性地看待，而不是一味地骂“这帮人怎么这么蠢”。

第一，算法推波助澜。

各位要明白，今天的社交媒体平台，推送逻辑是什么？是让你停留更长时间，产生更多互动。什么内容能做到这一点？耸动的、极端的、激发强烈情绪的内容。

研究早就证明了，带有道德愤怒、煽动情绪的信息，传播速度比普通内容快得多。平台算法一看，哎，这条内容互动率高，就推给更多人。越推越火，越火越推，形成正循环。

所以你看到的那些离谱言论，不是偶然火起来的，是算法选出来的。算法不管你说的是真是假，它只管数据好不好看。可以说，情绪如同病毒，社交网络正是它的培养皿。

第二，信息茧房让人越来越极端。

社交媒体会根据你的喜好推送内容。如果你关注了一个煽动性UP主，算法就给你推更多类似内容。久而久之，你只能听到一种声音，形成所谓的“回声室效应”。

在这个回声室里，那些离谱的观点被反复强化，最后变成“不容置疑的真理”。“吃瓜蒙主”的拥趸们反复刷“元清非中国”“清朝是殖民”这类弹幕，在他们自己的圈子里，这些说法成了共识。有人提反对意见？要么被忽视，要么遭围攻。

这就是为什么辟谣经常没用——辟谣的声音根本传不进那个圈子。

第三，争议本身就是流量。

这一点很多人没想到。对自媒体来说，黑红也是红。你骂他，他涨粉；你举报他，他更火。

“吃瓜蒙主”就是典型例子。她的账号被软封禁，内容被清空，直播被关停。按理说应该凉了吧？结果粉丝不降反升，从90万涨到550多万。为什么？

原因有几个：第一，粉丝打造了“受害者叙事”——她因为说真话被打压了，我们更要支持她！很多人跑去点关注，把给她涨粉当成某种胜利。第二，铁杆粉把她过往直播切成短视频，用小号到处传播，标题起得特别煽动，什么“被封前最后发声”之类的，单条播放量上百万，给主账号引流。

所以各位要明白一个道理：有时候你的愤怒批判，反而在帮对方增加热度。在流量为王的时代，骂他可能不如无视他。

理解了这些，你再看那些被煽动的人，可能就不会那么愤怒了。他们不一定是蠢，很多只是信息不对称、认知上受到误导，或者需要一个情绪出口。当然，理解不等于认同，但至少你可以用更冷静的眼光来看待这件事。

第三部分：怎么办？

知道了愤怒从哪来，也理解了反智内容的运作机制，接下来是最实际的问题：怎么办？

我把它分成三层：及时止损、重建锚点、与世界相处。

及时止损

我回顾过几次自己被气到拍桌子的经历，发现一个有意思的现象：我的情绪不是瞬间爆炸的，而是一步步被“钓”进去的。

有一次我听说“吃瓜蒙主”被封禁，出于好奇就去搜了一下，想看看她到底说了什么。本来只是想理性地了解情况。结果一打开相关帖子，就被里面的氛围吸引了——支持者和反对者吵成一团。我本想当个旁观者，但看到有人骂辩驳谣言的网友是“汉奸”“满遗”，我忍不住了，在评论区留了一条反驳。

我以为能讲道理，结果对方根本不跟你讲道理。我的回复下面很快收到一连串嘲讽和攻击。我越看越气，越气越想回，最后一个帖子刷了两个小时，工作也耽误了，气得脑仁疼。

回过头来想，我本来是想战胜谣言的，结果反被情绪牵着鼻子走。我每一次愤怒回复，都在给那个帖子贡献热度。我辛辛苦苦据理力争，到头来成了驱动话题热度的“燃料”。

这次经历给我的教训是：及时止损比什么都重要。

怎么止损？三步：

第一，察觉信号，立刻中断。 心跳加快、呼吸急促、脑子里不停冒攻击性语言——这些都是愤怒升级的信号。一察觉到，立刻放下手机。就像电脑过热需要散热，你的大脑也需要降温。

第二，物理远离。 起身去阳台呼吸新鲜空气，走出房间活动几分钟。稍后再回看那些让你暴怒的内容，往往会发现也不过如此。距离产生理智。

第三，问自己：值得吗？ 我继续争论下去，能达到什么？和那些人在线论战，既改变不了他们想法，还搭上自己的情绪能量。网络争论是无底洞，没有意义的战斗，不如不战。

重建锚点

止损只是应急措施。长远看，你需要一个稳定的“内在锚点”，让自己在信息风暴中不随波逐流。

这个锚点是什么？说白了，就是你要非常清楚自己是谁、相信什么、坚持什么。

重申你的价值观。 静下心来问自己：我为什么愤怒？我在乎什么？答案很清楚：你在乎真相，在乎理性。正是因为热爱真相、追求理性，你才会对反智谣言零容忍。

既然如此，这些价值就是你的骄傲和底气。理性和真相终究有力量，哪怕一时被谎言掩盖，迟早大白于天下。你应该为坚守这些价值感到自豪，而不是因为一时挫败就怀疑动摇。

我对自己说：“我依然站在理性和真相这边，这才是最重要的。”这句话成了我的定海神针，让我在迷雾中看清方向。

用知识武装自己。 面对谣言攻击，有时候气急败坏是因为一时间拿不出反驳依据，心里有点虚。知识是最好的镇定剂。

针对“元清非中国”这种奇谈，我去翻了正史和权威论文，确认了元朝在版图和体制上确为中国朝代的一部分，清朝对边疆的治理更是今天中国领土主权的历史基础。掌握了这些知识，再听到类似观点，我心里就非常笃定：“这是错的，我很清楚为什么错。”

那种胸有成竹的感觉，让愤怒转化成了淡定的判断。谣言的魔力在真知面前荡然无存。

强化你的身份认同。 与其让外界动摇你，不如主动强化自己的正面身份。你可以这样定义自己：“我是一个独立思考者，一个理性探索者。”

这个身份是积极而有力量的，不会因别人嘲讽或反智风潮而改变。历史上许多伟大的思想者，都曾在愚昧环境中坚守真理，最终证明他们是对的。做理性声音的少数派并不丢脸，反而是一种责任和荣耀。

而且你要相信，你不是一个人。网上也有很多清醒理性的人在默默辟谣、科普，只是他们的声音常被淹没。去关注支持这些人，和他们互动，你会发现归属感和力量感油然而生。

与世界相处

安顿好自己后，下一个问题是：以怎样的姿态重新面对这个充满嘈杂声音的世界？

有一段时间，我被反智言论搞得心灰意冷，一打开网络就预感要生气。我甚至想过彻底远离这些是非。但冷静下来想想，这不现实——互联网和现实世界并不割裂，网上的乱象终究会影响现实。我需要找到健康的方式与这个世界相处。

优化信息来源。 就像注意饮食健康，你也要注意“信息饮食”健康。梳理你常用的信息来源，把客观可靠、理性克制的媒体和作者权重加大；把博眼球、煽动情绪的账号权重降低或直接取关。

对热点事件学会先等等，别急着下判断，等权威信源出来再说。控制输入就是控制情绪的源头。当你的信息流干净清爽了，心态自然更平和。

用同理心看待他人。 在理解了群体心理机制后，我对那些曾让我愤怒的人多了一些同理心。试着站在普通网民角度想：如果我不了解全部背景，或长期处于某种信息茧房，我可能也会相信类似的东西。

并不是所有拥趸都愚不可及，很多人只是信息不对称、认知受误导，或者情绪上有宣泄需求。这种理解并非为谬误开脱，而是让你用更平和的心态去看待他们。当你怀着同理心，你的语言就不再那么尖刻，有时温和坦诚交流反而更容易让对方听进去一点不同意见。

把愤怒转化为行动。 光在道理层面坚守理性不够，可以把愤怒转化为建设性行动。写科普文章，做小视频，用通俗方式讲解容易被误解的知识。虽然阅读量可能不如爆款谣言，但帮助到几个愿意思考的人，就有价值。

通过这种方式，你不是被动挨打，而是主动出击，为改善舆论环境尽一份力。与其诅咒黑暗，不如点亮蜡烛。

善用AI工具。 这里要介绍一个有意思的研究。2024年《Science》杂志发表了一项研究：让阴谋论信奉者与ChatGPT对话，结果他们的信念平均降低了约20%，效果持续至少两个月，甚至对那些根深蒂固的信奉者也有效。

研究者发现，AI之所以有效，是因为它能针对每个人具体的疑虑，用事实和证据逐一回应，而不是简单说“你错了”。当事实核查人员验证AI的回复时，99.2%是准确的。

这说明什么？如果你身边有人陷入阴谋论或反智思维，与其你自己去辩论（往往吃力不讨好），不如建议他们去问问AI。让AI用耐心、理性、有据可查的方式去解答他们的疑惑。你省了精力，效果可能还更好。

这里还有一个判断标准：如果一个人连跟AI讨论都不愿意，还是死死坚信某些东西，那他坚信的很可能已经不是事实，而是信仰。事实是可以被证据改变的，信仰则不能。对于信仰，你没必要再费口舌。

选择战场，懂得取舍。 并非所有战役都值得亲自上阵。在充满谩骂、注定鸡同鸭讲的场合，就不消耗口舌了；在有人愿意听、讲道理有意义的场合，才投入精力沟通。

与其在公共论坛和陌生喷子对骂，不如把精力用来跟身边家人朋友耐心交流。影响身边几个人的观念，比网上吵赢十场架都有价值。

保持生活的丰富和平衡。 最重要的一点：不要把自己局限于网络舆论这个单一维度。现实生活多姿多彩。工作中追求专业成长，闲暇时发展个人爱好——运动、音乐、旅行，什么都好。

当你跑步或健身后大汗淋漓，那种畅快比在网上争吵有意义多了。生活丰富了，眼界就宽了，不会再把网上的冲突看得过于重大。只有现实中过得充实，你才有资本从容应对虚拟世界的风浪。

结语

好了各位，做个总结。

面对反智内容，你会愤怒是正常的，说明你还在乎真相和理性。但关键是怎么处理这个愤怒。

首先，搞清楚那些内容为什么会火——算法推送、信息茧房、争议红利。理解了这些，你就不会简单地骂“这帮人怎么这么蠢”，而是能用更理性的眼光看待。

其次，学会及时止损。识别情绪信号，果断按下暂停键。不要在无意义的争吵中消耗自己。

然后，重建你的内在锚点。明确你的价值观，用知识武装自己，强化你作为独立思考者的身份认同。

最后，找到健康的方式与世界相处。优化信息来源，用同理心看待他人，把愤怒转化为行动。

说白了就一句话：该坚持的坚持，该放手的放手，别跟自己过不去。

你不可能纠正世界上每一个错误。那些反智言论、阴谋论，不可能靠你一个人消灭。但你也不用太悲观——人类社会发展到今天，科学理性总体上还是在进步的，只是这个过程很慢，有时候还会倒退几步。

你能做的，就是在自己的能力范围内，做一点是一点。影响身边几个人，写几篇靠谱的文章，这些都有价值。别指望立竿见影，但也别觉得毫无意义。

最后，别忘了好好过自己的日子。网上那些破事，看看就得了，别让它真的影响你的生活质量。该吃吃，该喝喝，该工作工作，该陪家人陪家人。你把自己的日子过好了，本身就是对那些乌烟瘴气最好的回应。

好了，今天就说到这里。各位，我们下期再见。

``
特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。
``

0 引言

2025 年，AI 编码助手对许多开发者而言已从“玩具”变成了实打实的生产力工具。然而，要真正用好这些工具，并非简单地抛给模型一个模糊需求就能自动产出完美代码——我们需要一套有章可循的工程化工作流。当前，不少开发者使用 AI 的方式仍很零散：遇到问题临时求助、要功能时即兴生成、想不起用法就问一下。这种碎片化的使用方式带来了不稳定的质量和难以复用的经验。要解决这些问题，需要将 AI 助手的使用从“点状、临时”升级为“系统化协作”。

为什么同样的工具，有些人觉得好用，有些人觉得不好用？ 知名程序员 Peter Steinberger（PSPDFKit 创始人、Clawdbot 创建者）在《The Pragmatic Engineer》播客访谈中观察到一个典型模式：很多人写一个 prompt，丢进 AI，点发送，发现编译不过，于是失望地下结论说“这技术不行”。但他反问：“你真以为人类第一次写代码就能零 bug 吗？” AI 模型本质上是人类集体知识的幽灵，工作方式和我们非常像——第一次出错很正常，所以你才需要反馈闭环。与 AI 协作不是发一个 prompt 就完事，而是开启一段对话。这本身就是一项需要学习的技能，本指南的目标，正是帮助你系统性地掌握这项技能。后续章节将多次引用 Peter 的访谈——作为深度使用 AI 工具的资深开发者，他分享了许多宝贵的实战经验和心态转变。

本指南的目标是帮助开发者构建一套可复制、可控、可验证的 AI 编程工作流，以 Cursor 编辑器为核心工具。我们将借鉴经典的软件工程理念和最新的 AI 编程实践，将 AI 视为一名强大的“结对程序员”而非全自动的代码生成机器。整篇指南围绕 Plan-Execute-Verify（计划-执行-验证） 这一核心循环展开，强调工作流思维而非零散的工具技巧。正如《程序员修炼之道》所倡导的，好的开发实践重在思维方式和过程控制——在 AI 时代这一点更加重要。本指南将向读者展示如何像训练新同事一样“训练” AI 助手，与其协作编程，并最终达到提升效率而不降低代码质量的目的。

接下来，我们将首先介绍 AI 编程协作的思维框架，然后依次深入工作流中的各个关键环节：如何规划任务、构建最小闭环迭代、制定控制策略、管理上下文、撰写高效提示词、进行测试验证，以及如何沉淀项目资产并持续训练提升。让我们开始这一段“AI 工作流修炼”的旅程，把 AI 从简单助手升级为真正的智能工作流引擎。

1 工作流思维框架：Plan-Execute-Verify

要在 AI 协作编程中取得成功，首先需要转变思维，从“让模型一次生成大量代码”转向 Plan-Execute-Verify（计划-执行-验证） 的迭代循环。这一框架对应了软件开发的基本过程：先规划设计，再编码实现，最后测试审查。

1.1 Plan（计划）

在编写任何代码之前，先弄清楚要做什么。很多人使用 LLM 写代码的误区是一上来就要求模型输出大段实现，而没有讲清需求。正确的做法是花足够的时间梳理规格——明确需求、约束、边界条件，并让模型针对这些细节提出澄清问题。这一阶段的成果可以是一份结构化的规划文档（如 spec.md 或 Cursor 的 Plan 模式生成的 Markdown 计划），其中写明需求描述、架构设计、数据模型、依赖项、测试策略等关键要素。研究表明，有经验的开发者更倾向于在生成代码之前先规划，这能帮助我们更清晰地思考要构建的内容，并为 AI Agent 提供明确的目标。一句话，先做“15分钟的微型瀑布开发”——在真正写代码前，用很短的时间完成结构化的规划，让后续编码更顺畅。

1.2 Execute（执行）

明确计划后，进入编码执行阶段。将大任务拆解为小步骤，逐步实现。每次只让模型完成一个子任务，例如根据计划里的第一个步骤编写相应代码。Cursor 提供了强大的 Agent 智能体，可以根据你的指令编辑代码、创建文件、修改项目。在执行过程中，充分利用 Cursor 的功能，如自动补全（Tab 模型）和 Agent 模式来加速编码。但无论 AI 写多少代码，记住你才是总指挥——决策每一步是否采纳、如何调整。执行阶段的关键是在严格按照计划的前提下，让 AI 发挥生成代码的威力，同时随时监控其行为，不让它偏离预期。

1.3 Verify（验证）

无论 AI 的回答看起来多么自信、生成的代码看起来多么完善，你都必须对其进行验证和测试。将 LLM 当作一个特别聪明但容易犯错的初级工程师——你需要审查每一个关键步骤，决定是否接受修改。验证包括多方面：

• 自己阅读代码逻辑并理解关键分支
• 编写并运行测试，验证行为符合预期
• 对重要的改动执行认真的 Code Review（可结合人工和另一种模型审查）

如果发现问题，就进入下一轮的循环：调整计划或提示，重新执行，再验证，直到满意为止。这个持续反馈闭环确保了代码质量的可控和可验证。

1.4 小结：闭环而非直线

以上三个阶段并非线性执行完毕，而是不断交替循环。Plan-Execute-Verify 构成了 AI 协同编程的最小闭环，可以不断嵌套和迭代。通过这样的循环，我们避免了“一股脑让模型生成整个应用”而失控的情况。相反，我们以小步快跑的方式，在每个小周期内保持对方向和质量的掌控。这种方法既借鉴了传统敏捷开发的小步迭代思想，也融合了 AI 工具的特点，是一种 AI 增强的软件工程方法论：AI 帮助我们更快地产出代码和方案，而我们确保每一步都在正确的轨道上前进。

在接下来的章节中，我们将首先探讨与 AI 协作所需的心态转变，然后详细阐述如何在实际开发中落实 Plan-Execute-Verify 框架的各个环节。

2 AI 协作心态

Plan-Execute-Verify 是一个结构化框架，但要真正用好它，还需要正确的心态。很多开发者使用 AI 不顺利，不是因为工具不好或技术不行，而是思维方式不对。本章探讨与 AI 协作时需要具备的几个核心心态。

2.1 对话而非指挥

在实际操作中，有一种更自然、流动的方式来实现 Plan-Execute-Verify。Peter Steinberger 在访谈中分享了他的做法：

有一点很多人没意识到：你不是在”指挥”它，而是在跟它对话。我会说：”我们看看这个结构，有哪些选项？这个特性考虑过没有？”因为每一轮对话开始时，模型对你的产品一无所知，你得给它一些指引，让它去探索不同方向。你不需要什么 plan mode，我就是一直聊，直到我说”build”，它才真正开始构建。有一些触发词——它们确实挺”急”的——但只要我说”我们讨论一下”或者”给我一些选项”，它们就不会动手。

这段话揭示了一个重要的认知转变：与 AI 协作不是发号施令，而是结对探索。

很多开发者使用 AI 的方式是“指挥式”的——上来就说“帮我写一个用户登录功能”，然后 AI 立刻开始写代码，写出来不对再改，改来改去越改越乱。而 Peter 的方式是“对话式”的：先和 AI 讨论结构、探索选项、确认特性，在说“build”之前，一直保持在探索状态。

这种方式背后有几个关键洞察：

“零认知”问题：每一轮对话开始时，AI 对你的产品、上下文、偏好都是一无所知的。如果你上来就让它执行，它只能靠猜测。而“给它一些指路标志”，就是在帮它建立认知，让它的输出更贴合你的预期。

延迟执行：AI 模型确实很“饥渴”——它们倾向于立即行动、立即输出代码。但你可以用语言来控制这种倾向。当你说“我们讨论一下”或“给我一些选项”时，AI 会进入探索模式而非执行模式。这是一种软性的 Plan mode，不需要切换任何设置，只需要用对话引导。

触发词作为阀门：你可以把一些短语当作“阀门”来使用：

• “我们讨论一下” → 保持探索，不要动手
• “有哪些选项？” → 列出方案供选择
• “这个特性考虑过没有？” → 引导它思考边界情况
• “build” / “开始实现” → 正式进入执行阶段

这种方式与结构化的 Plan-Execute-Verify 框架并不矛盾，而是一种更“有机”的实现。本质上都是延迟执行、先思考后动手，只是形式不同——一个是显式的阶段切换，一个是通过自然对话来引导。选择哪种方式取决于个人风格：喜欢清晰流程就用正式的 Plan 模式，喜欢自然交流就用对话控制节奏。两者目的相同：确保 AI 理解清楚后再动手，而不是盲目写代码。

2.2 雕塑式构建：让形状从过程中浮现

除了“对话而非指挥”，Peter 还分享了另一个深刻的构建哲学：

我见过很多人一上来就搭建复杂的编排层：自动创建工单、Agent 处理工单、Agent 再给另一个 Agent 发邮件……最后弄出一堆精致的混乱。何必呢？他们花好几个小时设计 spec，然后让机器用一整天把东西”造”出来。我不看好这种做法——本质上还是瀑布式开发，我们早就知道那条路走不通。

我的构建方式是一路向前，很少回滚，更像是雕塑：从一块石头开始，一点点凿，让雕像慢慢从大理石中浮现。这就是我理解的”构建”。

这个雕塑比喻揭示了两种截然不同的构建方式：

为什么复杂编排层是陷阱？ 因为它本质上还是瀑布式思维——先设计完美的系统，再让机器执行。但我们早就知道瀑布式的问题：需求会变、理解会演进、最初的假设往往是错的。AI 时代更是如此——你不可能在动手之前就知道 AI 能做到什么、不能做到什么。

Peter 还强调了一个很多流程里缺失的东西：

我得去点、去摸、去感受。好软件需要”品味”，而这恰恰是很多流程里缺失的东西。

“品味”无法自动化。那些复杂的编排层追求的是效率和可复制性，但好软件不只是“能跑”——它需要你亲手触摸、反复感受、持续打磨。AI 可以帮你生成代码，但“这段代码好不好”的判断，需要你自己去“点、摸、感受”。

这种“雕塑式构建”的心态，本质上是把自己定位为创作者而非管理者：我不是在管理一个系统，我是在创造一个作品。米开朗基罗说过：“雕像本来就在石头里，我只是把多余的部分凿掉。” 与 AI 协作时，最好的作品往往也是这样“浮现”出来的——不是按图施工，而是在不断的对话和迭代中，让它逐渐成形。

2.3 心态是最大的门槛

以上讨论的“对话而非指挥”和“雕塑式构建”，本质上都是心态问题。很多开发者使用 AI 不顺利，不是工具不行或技术不熟，而是用错了思维方式——期望 AI“一步到位”，一个 prompt 就得到完美结果，不行就下结论“这技术不行”。

但正如 Peter 所说：“你真以为人类第一次写代码就能零 bug 吗？”AI 协作是一门需要学习的新技能，就像从吉他转到钢琴，需要时间适应。你越理解这些“小野兽”的思维方式，就越擅长与它协作。

关于心态转变和技能提升，我们会在第 10 章“持续训练与提升”中进一步深入讨论。现在，让我们带着正确的心态，进入实操环节。

在接下来的章节中，我们将详细阐述如何在实际开发中落实 Plan-Execute-Verify 框架，包括如何拆解任务形成最小闭环迭代、有哪些控制策略可保证 AI 输出受控、如何管理上下文避免信息混乱、怎样撰写高质量提示词引导 AI，以及如何进行测试验证和沉淀项目资产。每一部分都会给出具体可行的步骤、提示语模板和最佳实践，帮助你逐步建立起自己的 AI 编程工作流。

3 构建最小闭环

最小闭环指的是在开发中构建小型 Plan-Execute-Verify 循环，使每个循环都能产出可验证的结果（如通过测试的功能或修复）。与其让 AI 一次性生成庞大代码，不如将工作拆解成小块、迭代推进。LLM 在处理小而清晰的任务时效果最佳，而在“一次性写完整个应用”时往往会失控。因此，我们要学会像整理待办清单一样，将整体需求分解为一系列可以闭环的子任务，并逐一完成。

在讨论具体实践之前，先分享一个反直觉的策略。Peter 在访谈中提到：

我通常从一个想法开始，甚至会故意”欠提示”Agent，让它做点出乎意料的事，给我新灵感。可能 80% 的结果不怎么样，但总有一两个点让我意识到”这个角度我没想过”。然后我不断迭代、打磨。

现在的好处是：功能太容易生成了，不行就扔，或者换个提示词重来。

这段话包含了两个重要洞察：

“欠提示”策略：大多数人追求“精确的 prompt”——把需求描述得越清楚越好，让 AI 完美执行。但 Peter 的做法是故意留白，让 AI 有空间给他惊喜。为什么？因为你不知道自己不知道什么。如果你把所有细节都规定死了，AI 只会给你“你已经想到的东西”。而留白，可能会得到“你没想过的角度”。当然，80% 的结果可能不行——但这引出了第二个洞察。

试错成本极低：AI 时代最大的礼物是“功能太容易生成了，不行就扔”。以前写一个功能要几小时甚至几天，扔掉心疼。现在 AI 几分钟就能生成，不行就重来。这彻底改变了“试错”的经济学——你不需要第一次就对，只需快速迭代、不断逼近。

这正是“最小闭环”的哲学基础：不追求一次完美，而是追求快速验证、快速调整。每个闭环都是一次“凿石头”的动作——可能凿对了，可能凿歪了，但只要闭环够小，歪了也能快速修正。

3.1 具体实践

1. 拆分任务：将你的需求或用户故事拆分成独立的小步骤，每个步骤都有明确的目标输出。比如，如果你在开发一个博客系统，不要一次性让 AI 写完所有功能，而是拆成“实现用户注册模块”、“实现文章发布模块”、“实现评论功能”等。再细一点，每个模块又可细分：例如“实现用户注册模块”可以进一步拆解为“设计用户数据模型”、“编写注册接口的单元测试”、“实现注册接口逻辑”、“对接第三方邮箱验证”等等。
2. 计划每个子任务：对于每个小任务，先和 AI 一起制定一个简短计划。你可以直接告诉 Cursor Agent：“按照计划的第 1 步，实现 XX 功能”。如果这个任务稍复杂，可以进入 Plan 模式（Shift+Tab）让 Agent 生成一个实施计划，其中包含相关文件、修改点等。你可以审核这个计划，删除不必要的步骤或补充遗漏的信息，然后再让 Agent 执行实现。很多时候，对于很小的改动或你非常熟悉的任务，可以直接跳过详细计划，让 Agent 立即处理；但对于较复杂的任务，提前规划会让后续执行更顺利。
3. 执行并完成子任务：让 Cursor Agent 根据计划或你的指令编写代码。务必一次只执行一个子任务，避免在一个对话里同时要求 AI 做太多事情。这样做有两个好处：其一，AI 在一个狭小明确的范围内工作时，输出的代码更可靠、更易于理解；其二，方便你在每个任务完成后进行验收和调整。当 Agent 完成代码后，查看 diff 或生成的文件，确认它基本满足了当下子任务的预期。
4. 验证子任务结果：在接受 AI 的改动之前，先进行验证。这可以包括运行该子任务相关的测试（如果你提前编写了测试用例，最好现在运行看看是否通过），或者手动执行一下关键路径。确保这个小任务的输出没有明显问题。如果有测试未通过或者质量不满意，不要急于进入下一个任务，而应先修正当前任务的结果。你可以直接提示 AI 修复错误，例如：“测试 X 失败，错误信息如下，请根据错误修正代码”，或利用 Cursor 的调试功能定位问题然后再让 AI 修复。每个子任务结束时，都要达到“验收”标准：要么通过所有相关测试，要么经人工检查认为没有问题。
5. 反馈和迭代：如果子任务结果不理想，与其在当前基础上反复让 AI 勉强修补，不如回到规划阶段重新审视。你可以撤销刚才 AI 的改动（Cursor 提供撤销/还原功能，或直接利用 Git 回滚），然后根据失败的情况调整计划或提示，把需求描述得更具体明确，再让 AI 重试。通常，相比在错误的实现上修修补补，重新规划并执行会得到更干净的结果。
6. 小步提交：当一个子任务顺利完成后，将修改提交到版本控制（git）。保持小步提交、频繁提交，可以将每个闭环的成果都保存下来。这样一来，如果后来发现某次改动引入了问题，可以通过 git 历史快速定位并回滚。同时，一个清晰的提交历史本身也是极好的项目文档和上下文，下次让 AI 阅读提交信息或 diff，它可以理解你的项目演进过程。我们稍后在“控制策略”部分还会详细谈 git 的作用，这里先养成习惯：每完成一个闭环就提交，为下一个闭环做好干净的起点。

通过以上步骤，我们实现了以最小可验证单元为粒度的迭代开发。这种方法比让 LLM 一次生成一大块代码稳健得多——正如许多开发者的教训：“一次性让 LLM 生成整套应用，结果就像 10 个人各写一块、从未对齐过风格的代码”，而小步迭代 + 每步验收则能确保一致性、减少返工。在这个过程中，其实我们已经把传统的软件工程实践（如模块化、单元测试、持续集成等）融入到了 AI 协作中，每一轮 Plan-Execute-Verify 都是一个闭环，保证了输出的可靠性。

值得一提的是，Cursor 提供了一些强大的功能，可以帮助我们自动化这个闭环。比如，你可以利用 Agent Skills 和 Hooks 特性，使 Agent 不断循环迭代直到达到目标。官方博客提供了一个示例：通过编写 .cursor/hooks.json 和脚本，让 Agent 不断尝试修复直到所有测试通过。脚本会检测当前会话状态，如果测试未通过且迭代次数未超限，就让 Agent 继续下一轮：“继续工作，完成后在 .cursor/scratchpad.md 标记 DONE”。这种模式非常适合让 AI 自动反复执行，直到满足某个可验证条件（例如测试全绿、UI 与设计稿一致等）。不过在实践中，建议一开始先手动执行几个闭环循环，熟悉模式后再尝试引入这种自动化“研磨”技能。无论是否使用自动循环，核心理念都是一致的：让每次 AI 产出都形成一个闭环，要么达标，要么失败就反馈调整，决不在未验证的半成品上堆积更多产出。

通过构建最小闭环，我们实现了“短反馈回路”——AI 生成代码 → 立即验证 → 及时纠偏。正是这样高速的反馈，让 AI 生成的代码质量逐步接近人类水准，同时开发者始终对结果保持可控可知。在下一个章节中，我们将讨论如何进一步控制 AI 编程过程中的方方面面，确保整个工作流在我们的掌控之下。

4 控制策略

即使有了良好的规划和小步迭代，AI 编程仍然需要一系列控制策略来保证输出质量和过程可控。可以把这些策略看作是给 AI 这位“智能实习生”制定的纪律和护栏，确保它按照我们的预期工作，而不会“自由发挥”地引入风险。下面从多个角度介绍在 Cursor 工作流中可以采用的控制手段。

4.1 人不离场：Human-in-the-loop

首先也是最重要的一点：确保人始终参与决策，不要对 AI 生成的代码掉以轻心。尽管 AI 助手能显著提高效率，但责任终究在我们自己。把 AI 当作一个特别聪明但容易出错的初级工程师，这意味着：

• 不要盲目信任任何一段 AI 给出的代码，即使它语气自信、表面正确。至少要做到：自己过一遍 AI 生成的代码逻辑，理解每个关键分支；跑跑单元测试或集成测试，验证行为是否符合预期；对重要改动进行认真的 Code Review，必要时请团队同事或另一个模型帮忙审查。总之，在你亲自检查之前，不要让 AI 的代码直接进入生产。
• 人工随时有权叫停。Cursor 在 Agent 执行过程中提供了实时 diff 预览功能，如果你发现 Agent 的修改方向明显不对，可以立刻按下 Esc 键中断它。比如你让它修一个小 bug，它却开始修改大量无关文件，这时果断停止比任由其完成再回滚要高效得多。中断后，分析它偏离的原因，调整提示（或者干脆重新从 Plan 开始），再尝试执行。
• 明确分工：让 AI 多干机械重复的事，但关键决策点一定要人工拍板。AI 可以帮你写代码、跑测试、生成报告，但例如采用哪种架构方案、某个性能权衡的取舍、是否发布上线等决策，应当由有经验的你来决定。你可以让 Agent 提供选项和分析，但最后的决定请由人来做。

4.2 版本控制与隔离

良好的版本控制习惯是 AI 编程的重要安全网。当 AI 能短时间内生成大量代码时，只有细致的版本管理才能帮助我们快速止损和追溯。实践准则：

• 频繁小提交：正如前文所述，每完成一个小任务就做一次干净的 commit。Commit 信息写清楚做了什么改变。这样不仅便于日后查找问题，也方便你把 git diff 提供给 AI 让它基于变化做分析和改进建议。例如，如果某次提交引入了 bug，你可以复制该 commit 的 diff 内容，提示 Cursor Agent：“根据以下 diff，找出潜在问题并尝试修复”——由于 commit 粒度小，这样的上下文 AI 是能看懂并给出针对性建议的。
• 使用分支/Worktree 隔离实验：对于较大的功能开发或者尝试性改动，不要在主线上直接大规模应用 AI 建议，可以新建一个分支甚至 Git worktree 来隔离这些改动。Cursor 实际上对 Git worktree 有原生支持，它会为每个并行运行的 Agent 自动创建独立的 worktree，使得多个 Agent 可以各自编辑、构建和测试，而互不干扰。你也可以手工创建分支，在分支上大胆让 AI 重构或生成新模块。如果发现走偏了，直接放弃该分支即可，不会影响主线代码。
• 利用 Git 历史回滚：当 AI 的修改导致项目进入不稳定状态时，不要陷在错误状态里硬改，可以借助 Git 快速回滚到之前的稳定版本，然后从那里重新开始。Cursor 编辑器内置了 “Revert Changes”/检查点等功能，可实现类似效果。不过正如一些用户指出的，Cursor 的临时检查点毕竟不如显式的 Git 历史可靠。因此，推荐还是以 Git commit 为主要的“存档点”，必要时通过 git reset 或 git revert 来恢复过来，这比让 AI 在一团乱麻的错误状态中尝试修补要高效和稳妥得多。

4.3 规则与规范约束

AI 再智能，也无法凭空理解你项目特有的架构约定、编码规范、业务禁忌。这就需要我们主动提供规则和示例来“调教”AI，使其行为符合团队预期。正如你会给新入职的同事发一份团队开发规范文档，AI 也需要类似的“入职培训”。

Cursor 提供了 Rules（规则） 机制来实现这一点。你可以在项目的 .cursor/rules/ 目录下创建 Markdown 规则文件，为 Agent 提供持续生效的指令。规则可以涵盖：

• 项目中的常用命令：例如如何构建、如何运行测试、如何启动应用等。把常用脚本命令写进去，当 Agent 需要时就会参照使用。
• 代码风格和约定：例如使用何种模块系统，变量命名风格，有没有不允许使用的 API，组件放在哪个目录，等等。不要整篇风格指南都复制进去，抓重要的点，并引用项目里现有的示例文件而不是复制其内容。这样规则文件简洁且不会随着代码演进而过时。
• 工作流程相关：例如每次更改后要不要跑 typecheck、API 路由应该放在何处、哪些模式应该遵循既有模式等等。

撰写规则要注意聚焦重点，避免过度啰嗦。从简单开始，先建立 5-10 条核心规则即可。只有当发现 Agent 重复犯某类错误时，再把对应指导加到规则里。切忌一上来就给它一份巨长的说明试图涵盖所有情况，那样效果适得其反。规则文件本质上相当于每次对话的系统提示，内容太多反而淹没了关键信息。

共享规则：将 .cursor/rules/ 纳入版本控制，团队成员都可以受益。当某人发现 AI 在某方面反复出错时，可以更新相应规则。甚至在 GitHub 的 issue 或 PR 里，可以 @ 提示 @cursor 让 Agent 帮忙更新规则。这样团队经验会逐步固化下来，新人和 AI 都能遵循统一规范，减少因风格不一致带来的摩擦。当项目规则集逐步完善后，你会发现 AI 输出的代码与团队习惯高度一致，几乎看不出是机器生成的。

除了规则，示例代码也是极好的约束方式。LLM 非常擅长模式模仿，如果提供高质量的示例，它更容易生成风格一致、符合规范的代码。因此，在具体任务提示中，不妨多给 AI 展示“范例”：

• 提供参考实现：例如让它实现某个新功能时，先贴上一段项目里类似功能的代码，告诉它“请按照上述代码的风格实现…”。这样 AI 会在潜意识里模仿这个示例，输出的代码更符合你的期望。
• 明确禁止事项：如果你知道某些解法是不可取的，可以直接在提示里说明“不要采用 XXX 方式”或提供一个反例让它避免。例如“这里不能使用递归，会栈溢出”或“不要调用内部未公开的 API”。这样能让 AI 少走弯路。

4.4 动态调整和多模型协同

在使用 AI 编程时，还需要根据具体情况灵活调整策略，包括切换模型、引入额外检查等：

• 更换或组合模型：不同的 LLM 各有所长，有的善于解释和文档生成，有的在大代码库重构上更稳定。当一个模型频繁卡壳或输出质量一般时，尝试换用另一个模型试试。Cursor 支持同时选择多个模型运行同一个提示，并将结果并排比较。你甚至可以让模型之间互相审核：用模型 A 生成代码，再让模型 B 来审查提问题。这种“AI 审 AI”的方式常能发现单一模型容易遗漏的细节。Cursor 内置的 Agent Review 就体现了这个思想：Agent 完成后，可以点 Review → Find Issues，运行一次专门的审查流程，Agent 会逐行分析修改并标记潜在问题。利用不同模型的视角，可以提高错误发现率。
• 新对话还是继续：当一个对话进行太久，模型可能进入思维定式或引入大量无关上下文噪音。一般来说，如果你要开始一个不同的任务，或者感觉 Agent 有点糊涂总犯同样的错误，那就开启新对话。新的对话会清空旧的聊天记录，只保留规则等静态提示，从而让 AI 有个干净的思考空间。如果只是对同一个功能做小改动、调试刚生成的内容，且需要引用前文上下文，则可以继续当前对话。一个经验法则是：对话越长，越可能飘移。所以当你感觉 AI 回答开始偏题或者无视你的指令时，很可能是上下文干扰在作怪，不妨重启对话，从最新状态总结关键信息重新提供给它。
• 及时重置与澄清：AI 有时会“钻牛角尖”——无论你怎么提示都围着先前一个错误思路打转。这时，与其反复提示，不如彻底重置上下文。在 Cursor 中开启新 Chat，然后使用 @Past Chats 功能，引用之前对话的重要部分（例如最终的需求描述或设计结论），跳过那些错误的尝试过程。Agent 可以有选择地读取过去聊天记录，只提取需要的上下文。这比把整段对话复制过来高效得多，也避免旧有错误思路的干扰。此外，如果 AI 对你的意图明显误解，与其越纠结越乱，不如停下来澄清需求：再次明确你想要什么，让 AI 完全重新考虑。这就是前文提到的“从计划重新开始”策略的另一种表述。
• AI 也需要 Debug：当 AI 反复输出错误代码时，不妨转换思路，让它自己也参与进来分析问题。比如“请解释一下为什么你生成的实现没有通过测试”或者“逐步调试上面的代码，找出逻辑错误”。让 AI 进入分析师模式而非生成模式，有时能更好地找出问题。如果效果不佳，可以考虑换个角度提问或者换模型。很多时候，另一个模型可能立即看出问题所在。这就像团队里让不同的人 Review 代码一样，有时新人看问题反而清晰。
• 手动介入引导：不要忘记，你可以随时亲自修改代码然后再交给 AI 继续。例如当 AI 在一个小地方卡壳反复错误，你完全可以手动修正那几行，然后告诉 AI：“我修改了 X 部分，剩下的你继续完善”。AI 对你给出的正确部分通常不会再改，而是专注于未完成的部分继续。人机协作不一定是纯粹的提示-回答模式，直接改代码也是种高效的沟通。
• 规模控制：AI 在面对超大文件或无结构任务时容易失控。一个实践经验是：限制单次处理的代码规模。比如当某个文件超过 400 行时，可以考虑让 AI 将其拆分成更小的模块。你可以提示：“这个文件太长了，请通过提炼功能将部分逻辑拆到新文件中”。这样一来，AI 处理每个文件的逻辑范围减小，理解和生成都会更准确。同样地，如果一个任务涉及太多步骤，不妨人为拆解成多个 Chat 分别处理。控制问题规模在很多情况下能避免 AI “思路混乱”或输出质量下降。

4.5 自定义工作流与成本控制

随着对 Cursor 的深入使用，你可能希望把自己的一套开发流程固化下来，让 AI 按你的流程来工作，而不仅仅是被动响应提示。Cursor Nightly 版本提供了 Custom Modes（自定义 Agent 模式）实验功能，允许我们为 AI 定制一套专属的工作规则和行为模式。通过编写详细的规则文档，你可以让 AI 具备系统性思维，按照预设的多阶段流程来与你交互。

举例来说，传统模式下你对 AI 说“帮我写一个用户登录功能”，AI 可能直接就开始写代码了。而启用自定义 Agent 后，AI 可能先回答：“我理解您需要开发用户登录功能。让我先进入需求分析阶段，深入分析这个功能的背景…”，然后按照你定义的阶段一步步来，例如先问需求细节，再设计数据结构，再编写代码，最后自检输出。这实际上是将我们在 Plan-Execute-Verify 框架下进一步细分、标准化，让 AI 严格按照工作流执行。

当然，自定义工作流也面临另一个现实问题：交互轮次成本。标准化流程通常意味着渐进式推进，每个阶段都需要人确认再进入下一阶段。多阶段交互可能消耗大量的提示请求次数。在 Cursor 中，如果每月只有一定配额的调用次数，一个完整复杂功能走完流程可能相当“烧 token”。针对这一点，一些高级用户探索了“一次请求内的多次交互”技巧（Feedback MCP 等）。简单来说，就是借助 Cursor Agent Skills，让 AI 在一次用户提示中自行执行多轮对话的效果。例如你发送一个特殊指令，AI 可以在后台循环调用自己，直到完成某个条件为止，然后把最终结果一次性返回给你。这样做可以极大减少人为来回确认的步骤，从而降低交互成本。不过这属于相当高阶的用法，需要编写脚本和熟悉 Cursor 扩展接口，这里不展开。对于大部分开发者来说，更实际的做法是合理规划每次对话要完成的内容，尽量减少无效来回。如果担心次数不够用，可以考虑升级更高的订阅方案或者使用本地模型辅助一些工作。在成本与效率之间，需要找到平衡。

总之，通过以上种种控制策略，我们可以极大程度地避免 AI 编程过程中的“走偏”和“失控”情况。就像经验丰富的导师带新人一样，我们既要给 AI 足够的自主发挥空间，让它展示智能的一面；又要设定明确的规则和随时指导，在必要时果断纠正。应用这些策略后，AI 将真正成为我们可控的工具，而不是一个不可预测的黑盒。下一节中，我们将讨论如何管理上下文信息，让 AI 始终“看得到”完成任务所需的所有关键资料。

5 上下文管理

上下文（Context）指 AI 在生成代码或回答问题时所能获取的所有相关信息，包括当前项目的代码、相关文档、之前的对话内容等。高效管理上下文——既让 AI 获取充分信息，又避免噪音干扰——是 AI 编程工作流的重要一环。

5.1 让 AI 找到所需的信息

Cursor 的 Agent 具有强大的代码搜索和浏览能力，因此你通常不需要在提示里手动贴上所有相关代码片段——它可以自行获取上下文。比如当你询问“身份验证流程（authentication flow）”时，Agent 会自动在代码库里用 grep 和语义搜索寻找相关文件，即使你的提示里没有出现精确的文件名。Cursor 内置的即时代码搜索工具可以在毫秒级完成代码库扫描。这意味着在大多数情况下，你可以直接用自然语言提问，AI 自会去查找涉及的模块。例如你问“登录功能的实现在哪里”，它会定位到 AuthService 或相关的代码文件然后回答。

然而，让 Agent 自由搜索并不意味着我们就可以撒手不管。要注意以下几点：

• 避免过载信息：如果你已经清楚知道相关的文件或函数名字，在提示中明确提及它们。例如：“请修改 user_controller.rb 中的登录逻辑，确保密码错误 3 次后锁定账户。” 这样 Agent 会直接关注该文件的内容。而如果你不知道具体在哪里实现，也不要猜测贴一堆无关文件，直接告诉 Agent “请查找登录流程相关的代码”就好——它自然会去搜。不相关的文件可能让 Agent 混淆重点，所以上下文越精准越好。
• 利用 Cursor 特殊引用功能：Cursor 提供了 @ 引用语法来精确提供上下文。你可以在提示中用如 @file(filename)、@folder(foldername) 或 @code(symbol) 来引用特定文件、文件夹或代码符号。这样 Agent 在处理提示时会优先查看这些内容。例如，你可以对 Agent 说：“请查看 @file(services/AuthService.ts) 中的 login 方法，并修改为使用新的加密算法。” 这等价于把该文件内容作为上下文提供，Agent 会据此进行改写。精确引用可以大幅提升 AI 理解问题的准确度，尤其当项目较大时，这比它漫无目的搜索效率高得多。
• 代码库索引：对于非常庞大的项目，Cursor 提供了 Codebase Indexing（代码库索引）功能。开启后，Cursor 会在本地为整个项目创建嵌入索引（embedding），以提升跨文件回答的质量。这样 Agent 可以更“理解”代码库的结构和依赖关系。不过请注意，索引创建和更新需要一些时间，而且索引数据会上传存储在云端（但代码本身仍保存在本地，不会上传）。如果你的项目对隐私要求很高，可以考虑不开启此功能，转而通过手动引用或逐步搜索的方式提供上下文。

5.2 控制对话上下文

除了项目代码上下文，AI 对话本身的上下文管理也很关键。随着对话轮数增加，以前的聊天内容也会占据上下文窗口。Cursor Agent 的上下文窗口虽然较大，但不是无限的，过长的对话可能让早期内容被遗忘或被模型弱化处理。同时，长对话中往往混入了很多历史噪音，可能干扰模型的判断。因此我们需要策略性地管理对话过程中的上下文：

• 分阶段启动新对话：在任务切换或 AI 出现困惑时，可以考虑开启一个新对话。新对话会重新加载规则和关键静态提示，但不包含旧对话的聊天记录。你可以在新对话的开头，简要说明现在的上下文是什么。例如：“之前我们完成了用户注册功能的开发，现在开始新的任务：实现用户登录。以下是用户注册模块的接口定义：…” 通过这种方式，你人为控制了上下文的重置，确保 AI 不会因为前一话题的残留内容而跑题。
• Past Chats（引用过往对话）：Cursor 提供了非常方便的 @Past Chats 功能，让你在新对话中引用之前的对话内容。与其一次性复制整个聊天记录，@Past Chats 可以引用某次过去对话的标题或编号，然后 AI 会按需读取其中相关的部分。这相当于给 AI 提供了一个可查阅的知识库，它可以选择性提取需要的上下文，不会引入无关内容。这对长周期开发非常有用——你可以把某些重要决策、结论或者设计细节放在一个对话里，必要时在以后的对话中引用它，而不必每次从头解释。
• 维护上下文简洁：在同一个对话里，也要注意保持每次交互提供的信息足够简洁明了。尽量在一次提示中集中说明当前需要 AI 关注的重点，而不是扯入很多次要细节。如果本次任务只涉及后端，就没必要把前端代码片段贴进去；如果只修改配置文件，就无需加载整个项目结构。许多经验丰富的用户甚至会维护一个“知识库文件”，每遇到 AI 犯的新错误就记录下来，下次提示时把这个知识库也附上。例如建立一个 knowledgebase.md 文件，里面写着项目的重要背景信息和已知陷阱，每次提问都 @file(knowledgebase.md) 引用一下。这样 AI 每次都有那些关键知识做支撑，就不容易再犯同样错误。当然，这有点类似手动的做法了——Cursor 的规则和技能体系从机制上提供了更优雅的上下文注入手段（规则等同于始终附加的知识库）。无论用什么方法，目标都是让 AI 手头的信息既不缺乏也不过载：该给的一定给，不该看的不要给。
• 外部资料引入：在某些情况下，任务所需的信息不全在代码里。例如要使用一个新库，而 AI 并不了解它的细节；或者涉及业务逻辑，需要参考需求文档。Cursor 支持将外部文档纳入上下文。在设置里，你可以添加一些 URL 或本地文档作为参考资料，让 AI 在回答时参考这些内容。另外，通过 Model Context Protocol（MCP），Cursor 可以与外部工具集成，例如 Slack、Confluence、数据库等，把那些来源的数据作为上下文提供给 AI。举个例子，你可以接入一个 Slack MCP，让 AI 能够读取某个 Slack 频道的聊天记录；或者接入一个 Figma MCP，让 AI 读取设计稿图片。这样，当你说“按照设计稿实现 UI”时，AI 就真的能看到设计稿细节了。这属于上下文扩展的高级玩法，对于需要综合多源信息的任务非常有帮助。引入外部资料的原则仍然是不滥用——只在需要的时候才添加，并确保提供的是可靠信息源。

总之，良好的上下文管理能让 AI 如虎添翼——在需要时迅速获取相关信息，而不被无关细节迷惑。开发者要对项目结构和知识来源了然于心，学会使用 Cursor 的各种上下文机制（代码搜索、@ 引用、Past Chats、规则/技能、MCP 等）。做到这一点，AI 就仿佛随时站在你肩膀上看着同样的资料，与你同步思考。下一章，我们将讨论如何编写高质量的提示词，最大化引导 AI 输出我们想要的结果。

6 提示词技巧

人与 AI 的交流是通过 提示词（prompt） 来完成的。提示词的质量直接决定了 AI 输出的质量。写提示词就像给同事下任务描述，讲究清晰、准确、上下文充分，还要考虑对方（AI）的“性格”和能力范围。下面，我们总结一系列编写高效提示词的技巧、模板和实例，帮助你更好地驱动 Cursor Agent 完成编程任务。

6.1 明确需求，避免含糊其辞

正如前文所述，许多开发者在使用 AI 时的误区是给出模糊的指令，比如“帮我写个登录功能”，然后希望 AI 猜出一切。提示词的第一要义是清晰明确。这包括：

• 说明要做什么：开门见山地描述需求或任务。例如：“实现一个新的用户登录 API，包括用户名密码校验、JWT 生成和错误处理。” 比 “帮我写登录功能” 要明确得多。
• 指出范围和目标：如果任务有明确边界，一定要说明。如“修改 OrderService 中的 createOrder 方法，使其支持优惠券折扣”，限定了修改范围和目标功能。
• 提供背景：如果需求依赖某些背景假设，要在提示中说明。例如：“我们的应用使用 DDD 架构，订单聚合根在 Order 类，实现新的折扣逻辑时需遵循聚合规则。” 这些信息能防止 AI 提供违背你架构原则的方案。

实践中，一个有效的方法是在提示开头先给出一段背景描述，然后再提出具体任务。比如：

我们的电商平台使用微服务架构，订单服务负责订单创建和支付。当前 OrderService#createOrder 方法没有考虑优惠券折扣。

任务：修改 OrderService#createOrder 方法，使其在计算总价时考虑优惠券折扣。如果请求中提供有效优惠码，则按优惠规则扣减相应金额。

要求：保证订单总价不低于 0，所有折扣逻辑放入 CouponService 处理，不要在 OrderService 中硬编码。

像这样结构化的提示包含了背景、任务和具体要求，AI 几乎不可能误解你的意图。

6.2 提供充分的上下文与约束

在提示词中，尽可能提供与任务相关的现有信息，这样 AI 就不必凭空假设：

• 指明相关文件或代码片段：如果你已经定位到需要修改的文件，最好把文件路径或片段告诉 AI。如：“参考 UserRepository.java 中的 findByEmail 方法，实现一个新的 findByUsername 方法。” 这样 AI 就不会去别的地方找或者重复实现已有逻辑。
• 说明重要约束与不变量：明确告知哪些东西不能被破坏。比如：“修改这一函数时请确保不会破坏事务的一致性”或者“保持对现有 API 的向下兼容，不能改变返回值结构”。这些都是 AI 可能忽略但对你很重要的点，一定要在提示里提及。
• 给出项目里的示例：如果项目中已有类似实现，让 AI 照葫芦画瓢。比如“项目已有的 ProductService#addProduct 方法就是个很好的参考，请按相似风格实现 addCategory 方法”。还可以贴出简短的示例代码片段。AI 擅长模仿模式，这样它输出的代码在风格和结构上更符合预期。
• 提供外部资料片段：对于 AI 不了解的新概念，直接提供资料摘要。比如在提示里粘贴某个库的 README 关键段落，然后让 AI 基于此使用该库 API。又或者，对于复杂的正则、晦涩的业务规则，你可以把相关说明文字贴进提示。原则是：凡是 AI 需要知道才能正确完成任务的信息，都应想办法提供。不要指望它去“想象”或推理出某些背景知识——与其相信 AI 的常识，不如明确给出依据。
• 设定反例和禁区：如果某些解法是不可取的，可以直截了当地告诉 AI “不要那样做”。例如：“性能至上，请勿使用 O(n^2) 的解法”或者“出于安全考虑，决不能将密钥硬编码在代码中”。有时指出你不希望的方案，比描述你希望的方案同样重要。

6.3 要求 AI 自行澄清和检查

一个好的提示不只是单向命令，还可以引导 AI 进行交互式思考。Cursor Agent 具有多轮交互能力，我们可以在提示词中鼓励它提出问题或自行检查。例如：

• 让 AI 提问：在较复杂任务的提示末尾，可以加一句：“在开始实现之前，如有任何不明确的地方，请向我提问。” 这等于给了 AI 一个机会来澄清需求，而不是贸然生成。经验上，如果 AI 真的提出了澄清问题，说明你的需求可能还不够清晰，那就回答它的问题，直到 AI 满意为止再让它动手写代码。
• 分阶段执行：如果任务很复杂，不妨在提示中明确要求 AI 分步骤完成，不要一股脑给出最终代码。例如：“步骤 1：先给出实现方案和接口设计，不要写代码。步骤 2：经我确认后再编写代码。” 通过这种元指令，你可以把任务拆成两个回合：先让 AI 输出一个计划或设计，然后你审核后再让它继续。这相当于人工插入了 Plan-Execute 的中间检查点，可以显著提高复杂任务的正确率。
• 提示 AI 检查输出：在提示结尾加一句：“生成代码后，请检查是否有明显的错误或遗漏。” Cursor Agent 在完成主要任务后，会根据系统提示（包括规则）自动执行一些检查。你也可以直接要求，例如：“给出代码后，解释一下你的实现是否考虑了所有边缘情况。” 这样 AI 往往会在回答中先给代码，再附上一段自我检查的说明，指出可能的不足之处。这些自述可以帮助你了解 AI 的思路，还能及时发现它有没有忽略某些要求。

6.4 提示模板和实例

结合以上原则，这里提供几个实用的提示词模板，开发者可直接套用或修改：

6.4.1 功能实现类任务（使用 Plan-Execute 分步）

【背景】我们正在开发一款 Todo 应用，使用 Spring Boot + JPA。当前有用户管理模块。

【任务】实现“重置密码”功能：

1. 提供一个 API 接口 POST /api/users/reset-password，接收邮箱地址。
2. 验证该邮箱对应的用户存在，生成重置 Token（随机字符串，有效期 24 小时），保存到数据库（可新建 ResetPasswordToken 实体）。
3. 将重置 Token 通过邮件发送给用户（调用已有的 EmailService）。
4. 如果用户不存在，返回 HTTP 404。

【要求】

• 所有数据库操作必须在事务中完成。
• Token 应该是唯一且安全的（使用 UUID 或加密随机数）。
• 切勿泄露用户不存在的信息（即邮箱不在系统中时，仍返回成功，以防止恶意探测）。

请先给出你计划如何实现，包括需要的新实体/方法/流程，然后再等待我确认。确认后再编写具体代码。

这个提示首先详细描述了背景和任务细节，然后要求 AI 先给出计划。你确认无误后，可以在同一对话继续说“好的，请按照你的计划生成代码”，AI 就会继续完成编码部分。通过这种方式，你既确保了需求的明确，又能介入设计过程。

6.4.2 Bug 调试与修复

我们有一个 Java 服务用于数据处理，但运行时报如下错误：

1
2
3
4
5

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 10 out of bounds for length 10
    at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
    at java.base/java.util.ArrayList.get(ArrayList.java:438)
    at com.example.DataAnalyzer.processData(DataAnalyzer.java:30)
    at com.example.Main.main(Main.java:15)

请找出 DataAnalyzer.java 中导致 IndexOutOfBoundsException 的原因，并修复代码。【提示】processData 方法似乎在用错误的边界条件迭代数据列表。

这个提示提供了错误堆栈和怀疑的原因，引导 AI 去阅读代码找问题。这相当于让 AI 充当调试助手。AI 可能会定位到 DataAnalyzer.java 并看出循环条件 i <= data.size() 多迭代了一次，造成索引越界，然后给出修复建议，比如改为 i < data.size()。

6.4.3 测试驱动开发（TDD）

我们要给 Account 类新增一个方法：transfer(BigDecimal amount, Account targetAccount) 实现账户间转账。

步骤 1：请先编写测试用例来规定该方法的行为。使用 JUnit 5 + AssertJ 风格：

• 转账后源账户余额减少、目标账户余额增加。
• 余额不足时转账应抛出 InsufficientBalanceException。
  不要编写 Account 类实现，只需给出测试。

AI 会先输出测试代码，例如几个情景：正常转账、余额不足转账。你检查测试是否覆盖充分（需要的话手动调整并要求 AI 补充），然后：

步骤 2：很好，现在请运行这些测试（无需真实执行，假设失败），确认它们未通过。

步骤 3：现在请编写 Account.transfer 的实现代码，要求通过上述所有测试。请勿修改测试代码。如果第一次未通过测试，请根据失败信息持续修正，直到测试通过为止。

这一步 AI 会编写 transfer 方法实现。如果第一次不一定完善，你可以继续提示它输出假想的测试结果，然后让它根据错误信息调整，实现一个循环。这个过程其实就是让 AI 进入 “TDD 循环”：先让 AI 写测试 → 确认测试失败 → 写实现直到测试通过 → 最后人工验收提交。

6.4.4 代码审阅与改进

以上是 Cursor Agent 刚刚生成的代码实现。现在请以审查者身份逐行检查这段修改，指出其中可能存在的潜在问题、漏洞或可以改进之处，并给出修改建议。

这个提示可以在 Cursor 完成一次改动后提出，Agent 会进入 Review 模式，对代码做静态分析。它可能输出一个列表，比如：“第 12 行可能存在空指针风险，应先判断对象是否为空”、“第 27 行的算法复杂度较高，在大量数据时可能性能不足”。这利用了 AI 善于分析的能力，提供了一个“第二双眼睛”来帮助你审视代码。

6.4.5 复杂问题讨论

我们打算重构支付模块，目前有两种候选方案：

1. 使用策略模式，根据支付类型分别实现。
2. 使用规则引擎，根据配置决定支付流程。

请从代码维护性、扩展性、性能和开发工作量方面，帮我比较这两种方案的优劣，并给出你的建议。

这种开放性的提示让 AI 发挥长处——分析与文字总结。它会产出一篇分析文章，帮你梳理每种方案的优点缺点，然后给出推荐（也许会说更倾向哪种并解释理由）。这种用法相当于把 AI 当成顾问，一起头脑风暴和论证。

提示技巧小结：

• 写提示词时，可以使用 Markdown 的格式提升可读性（Cursor Agent 输出时通常保留你的格式）。比如用列表、粗体来强调关键步骤，这既是给 AI 看的，也是给你自己和团队看的（将来回顾聊天记录就像文档）。
• 语气和措辞也有影响。Cursor Agent 对明确的指令反应很好，所以不用客气，把需求和要求直截了当地说明。但是对于需要创意或分析的，让 AI 扮演某种角色（如“作为资深 Java 架构师，回答…”）可能会有效果。但切勿使用冒犯或过于情绪化的语气，对 AI 来说这样的信息无用还可能引起奇怪的输出。专业、礼貌且清晰，是提示词应有的风格。
• 尽量一次一个任务。如果在一个提示里罗列了许多不相关的要求，AI 可能漏掉部分要求甚至混乱。最好每次交互聚焦在单一目的上，完成后再进行下一个。

提示词的艺术需要通过实践不断打磨。建议你多保存一些有效的 prompt 模板，比如常用的“添加新接口”“修复 Bug”“写单元测试”“代码重构”“性能优化建议”等，把它们整理成一个属于你自己的 Prompt 手册。以后遇到类似场景可以快速引用，大大提高工作效率。

7 测试与验证

在 AI 编程工作流中，“验证”步骤至关重要，它是确保代码质量和功能正确性的最后防线。无论 AI 多么强大，我们仍必须通过测试和审查来验证其产出是否可靠。正如之前所强调的，Human-in-the-loop（人不离场）要求我们对每个关键结果进行把关。本节将讨论如何有效地将测试和验证融入 AI 协同开发，从而构建一个稳健的高频反馈闭环。

7.1 测试优先，驱动开发

在理想情况下，我们应尽量采用 测试驱动开发（TDD） 的方式与 AI 协作。这意味着在实现功能前，先定义好验收标准（测试用例），让测试来指导实现过程。实践中，可以像前文提示示例那样，先让 AI 根据需求生成测试用例，再让它去实现功能直到测试通过。测试的存在有多重好处：

• 为 AI 设定清晰的目标：模型的表现往往在有明确迭代目标时最好。测试用例就是明确的目标——通过/未通过是客观判断标准。有了这个“裁判”，AI 会不断修改自己的实现直到所有测试通过。这一过程减少了我们人工验证的负担，也防止 AI 偏离正轨，因为测试不通过就说明还有问题，逼着它继续改进。
• 防止过度实现或遗漏：写测试促使我们（和 AI）先认真思考功能规格，包括各种边缘情况，这避免了直接上手编码时可能遗漏的场景。AI 生成测试用例时，如果它遗漏了一些情况，你可以及时补充提示，这相当于在编码前就讨论清楚了需求细节。当测试覆盖全面后，AI 的实现也更有保障。
• 减少回归：当项目积累了测试集后，AI 每次改动都可以快速验证是否破坏了既有功能。Cursor Agent 可以被指示去运行测试（它背后实际调用终端来执行命令），并将结果反馈给你或自身。这就像给 AI 戴上了“紧箍咒”：一旦它的改动导致某个测试失败，立刻就能发现并进行修复。这在重构或大改动场景下尤其重要。

在 Cursor 中，你可以把常用的测试命令（如 npm run test 或 pytest）写入 Rules 的 Commands 部分，提醒 AI 在完成一系列修改后运行测试。甚至可以设置 Skills，让 AI 自动在每次生成后运行测试并判断结果。当然，不要忘记测试本身的质量：AI 生成的测试也需要你审查，有时 AI 写的测试用例不一定严谨，需要你调整。测试代码和产品代码一样，需要维护和演进。

7.2 让 AI 参与验证过程

除了编写和运行正式的测试，我们还可以让 AI 积极参与到验证环节，以多种方式检查代码质量：

• 静态分析和审查：Cursor Agent 具备代码分析能力。你可以显式提示 AI：“检查一下上面的代码是否有潜在空指针异常或者错误。” AI 会静态地阅读代码并指出可疑之处。这类似于让 AI 当 Lint 工具或 Code Review 助手。重要改动后也可以用另一模型审查，在 Cursor 里你可以直接切换模型提问。
• 对比多种方案：Cursor 支持并行运行多个模型，你可以让两个模型分别实现同一个功能，然后对比它们的输出差异。如果两份代码逻辑截然不同，可以让 AI 相互参考或者评估哪种更优。这有点像二次验证：当两个 AI 结果不一致时，引起你注意去深究；当结果一致时，说明实现基本是主流思路，可靠性也许更高。
• 运行和观察程序行为：在某些情况下，直接运行代码观察其行为也是验证的重要手段。你可以让 AI 执行某些命令。例如：“运行应用并访问 /api/test 看看返回是什么”。如果环境允许，你也可以自己运行程序，复制控制台日志或错误信息给 AI，让它协助分析。举例来说，把程序运行时抛出的异常栈贴给 AI，问它“根据这个错误日志，程序可能哪里出了问题？应该如何修复？”。

7.3 人工验收与代码评审

无论测试多完善，我们仍强调人工的最终验收。这包括：

• 代码走读（Code Walkthrough）：亲自阅读 AI 生成的代码，确认逻辑正确、边界条件处理妥当。尤其是安全相关的代码，AI 可能不会完全理解安全隐患，必须由开发者来审视。例如检查是否有 SQL 注入风险、敏感信息日志泄露等。如果在团队中，可以把 AI 的产出提交 Pull Request，让其他同事审核，就像人工写的代码一样对待。
• 风格和规范检查：看 AI 写的代码是否符合团队的编码风格和规范。如果有 CI 集成了 lint 或格式检查，运行一下，看看有没有违规。一个 AI 友好的开发环境应有严格的 lint/格式检查，这其实也是为了保证 AI 产出符合规范。大模型有时会忘记格式，比如导入顺序、注释风格，你需要提醒或手动调整，然后把这些要求加入规则里防止下次再犯。
• 业务结果验证：代码通过测试并不意味着满足真实业务需求。要结合业务场景验证结果。例如在测试环境运行一下新功能，观察是否真正解决了问题、性能是否达标、UX 是否满足预期等等。AI 不会使用你的产品，这一步需要你换位从用户或业务角度验收。必要时可以请产品或 QA 一起验证。

持续集成和自动化检查也是测试验证的重要组成部分。确保你的项目有完善的 CI/CD 流水线，Pull Request 触发自动构建和测试。当 Cursor Agent 提交代码后，CI 如果报告了测试失败或覆盖率下降，你就能立刻知道。然后你可以把 CI 的失败信息反馈给 AI 修复：“CI 测试 X 失败，错误输出如下，请根据此修复代码。” 这种高频反馈闭环将 AI 牢牢控制在“有问题就改、改到通过为止”的循环中。整个过程你只需观察和最终拍板，大量机械调试修复的工作都可以由 AI 承担。

综上，“验证”绝不是可选项，而是 AI 工作流的必备环节。借助测试用例、AI 审查、CI 工具、人眼核验，我们构筑了多层保障，避免了 AI 的错漏流入最终产品。通过严谨的验证流程，我们既发挥了 AI 的速度优势，又确保了软件质量和可靠性。

7.4 关上反馈闭环：让 AI 自己验证自己

前面我们讨论的验证方式，主要是“人验证 AI 的输出”。但还有一种更高效的模式：让 AI 自己验证自己。这需要你把“反馈闭环”搭建好。

Peter Steinberger 在访谈中把这称为“最大的秘密”：

高效使用 coding agent 的关键，其实就一句话：你得把反馈闭环搭好。它必须能自己跑测试、自己 debug，这是最大的秘密。这也是为什么后来效率提升这么明显。用 Claude Code 的时候，我经常要回头修修补补，来回跑很多轮，算下来其实没快多少，只是更”互动”而已。现在用 Codex，绝大多数时候它一次就对了。

没有闭环时，AI 生成的东西第一次往往跑不通，忘了同步改其他地方，你要来回修补很多轮。有闭环时，AI 可以自己发现问题、自己修复，绝大多数时候一次就对。

那什么是“反馈闭环”？ Peter 给了几个具体例子：

1. 每个功能都配测试

我的基本策略一直是：做一个功能，就让它写测试，而且确保测试真的跑了。

这是最基础的闭环。AI 写完代码 → 跑测试 → 测试失败 → AI 修复 → 再跑测试… 直到通过。关键是“确保测试真的跑了”——不只是写测试，而是让 AI 在开发过程中持续运行测试。

2. 用 CLI 代替 GUI 调试

Mac App 调试特别烦——要 build、启动、点界面、看效果，再告诉它不行。现在我就直接说：给我建一个 CLI，专门用来 debug，走完全一样的代码路径，我可以直接调用。然后它就开始跑，一个小时后搞定了。

为什么要这样做？因为 GUI 的反馈循环太慢了。每次验证都要 build、启动、点击、观察… 而 CLI 可以秒级验证，AI 可以快速迭代。Peter 甚至在做网站时，也会把核心逻辑设计成可以通过 CLI 跑起来，因为“浏览器里的反馈循环实在太慢了”。

3. 自动化集成测试

我花了好久才反应过来：我在干嘛？这事就该自动化。于是我直接跟 Codex 说：设计一组集成测试——起一个 Docker 容器，装好整套系统，跑一个循环，用指定文件里的 API key，让模型读一张图片、生成一张图片，再回头看自己生成的图像理解成了什么。结果它真就自己搞定了。

这是更高级的闭环：整个系统级别的自动化验证。当你发现自己在反复手动测试同一个场景时，就应该想到“这事该自动化”。

为什么代码特别适合 AI？

Peter 点出了一个本质原因：

代码不一样，我可以编译、lint、执行、验证输出——只要你把系统设计好，就能形成一个非常完美的反馈闭环。但在创意写作上，它们的表现往往只是中等，因为创意很难验证。

代码的每一步都是可客观验证的：编译通过/不通过、lint 通过/不通过、测试通过/不通过、输出正确/不正确。这些二元判断让 AI 可以自己知道做对了没有。而创意写作的“好不好”是主观的，AI 无法自我判断。

信任的来源

你之所以可以不看，是因为你已经把验证闭环搭好了，你信任它，因为测试跑过了。这其实和在大公司做项目很像：所有测试都绿了，当然不代表百分之百没问题，但已经是一个很强的信号了。

很多人不敢信任 AI 写的代码，是因为没有验证手段。但如果你有完善的测试和 CI，你不需要逐行审查每一行代码。这和大公司的协作模式一样：你不会去看每个同事的每一行代码，你信任 CI 和测试。

如何搭建反馈闭环？

总结起来，要让 AI 能“自己验证自己”，你需要：

1. 测试框架：确保项目有单元测试、集成测试，并且 AI 能运行它们
2. 快速迭代环境：尽量用 CLI 而非 GUI，缩短每次验证的时间
3. 自动化思维：当你发现自己在反复手动验证时，就让 AI 把这个验证过程也自动化
4. CI/CD 集成：让测试在每次提交时自动运行，形成持续的质量守护

一旦搭好这些基础设施，AI 的效率会呈数量级提升。它不再是“生成代码然后等你验证”，而是“生成、测试、修复、再测试… 直到通过”的自主循环。你只需要在最后审查结果。

软件的本质没变，Test First 反而更容易了

关于反馈闭环，Peter Steinberger 还有一个更深层的洞察：

其实在 AI 之前也是一样。做复杂系统时，只要找一个真正做过的人，他第一件事一定是想：怎么让它可测试？接口怎么设计、类怎么拆、要不要 mock、要不要做端到端测试——这些都是非常困难、而且一旦决定就很难回头的架构选择。现在这些取舍依然存在，软件本质上没变。

“可测试性”一直是好架构的核心标志。这个原则在 AI 时代不仅没有过时，反而变得更加重要——因为你需要给 AI 一个能自我验证的环境。

但有一件事确实变了。Peter 坦诚地说：

写测试这件事真的太折磨人了，各种边界条件、分支逻辑。除了我非常尊敬的 Kent Beck——他来过播客，坚持 test-first——我几乎不认识真正喜欢写测试的开发者，包括我自己。我从来不喜欢写测试，就算假装喜欢，其实也没有。文档和测试对我来说，一直都不是一种”创作表达”。

这是大多数开发者的真实心态。Test First、TDD 在理论上很美好，但实际执行起来，写测试比写功能还累，感觉不是“创作”，而是“苦力活”。

但现在情况完全不一样了：

现在每当我设计一个功能，文档和测试都会自动成为流程的一部分。比如我们刚做完一个东西，我会立刻想：怎么测试它？换一种实现方式会不会更好测？于是”怎么关上闭环”已经成了我思考的一部分。模型必须能验证自己的工作，这会自然把我推向更好的架构。

我甚至觉得，现在不再亲手写代码了，反而写出了更好的代码。我以前就写得不错，但在公司里……现在情况完全不一样了。可以说，在我最近的项目里，文档质量是我做过最好的，而我一行都没亲手写。我不写测试，也不写文档，我只跟模型解释取舍：为什么要这么做。

这是一个很有意思的反转：

• 以前：写功能 → 勉强补测试 → 能跑就行
• 现在：想清楚怎么验证 → 让 AI 写测试和功能 → 确保闭环

AI 接管了那些“不是创作表达”的苦力活，而人专注于真正需要人来做的事：解释取舍、描述意图、想清楚“怎么验证”。

Kent Beck 的 Test First 理念，在 AI 时代反而更容易实践了。变的是实现者，不变的是原则。 这也许是 AI 带给软件工程最积极的影响之一：它让“理想的工程实践”从“应该做但做不到”变成了“自然而然会发生”。

8 项目资产沉淀

在传统开发中，我们注重代码复用和知识积累。AI 协作开发同样会产生许多有价值的项目资产：文档、规则、提示片段、测试用例等。善加利用这些资产，可以让 AI 未来表现更好，也让团队其他成员受益。本章讨论如何沉淀和复用 AI 协作过程中产生的知识与成果，打造不断自我增强的开发循环。

8.1 保存 AI 的“智慧”：计划和对话

Cursor 提供了一些功能，可以方便地保存 Agent 的输出内容。例如，当你使用 Plan 模式生成了实现计划后，可以点击 “Save to workspace” 将该计划文件保存到项目的 .cursor/plans/ 目录。这样一来，这份计划就成为项目文档的一部分，后续中断了也可以继续参考，还能提供给未来在同一功能上工作的 Agent 作为参考上下文。建议：把重要的 AI 规划文档都保存下来，例如 plans/2026-01-完成登录功能.md，并纳入版本管理。即使实现已经完成，这些计划文档也是宝贵的记录，反映了当时的思路和决策，供以后参考。

此外，对于 AI 生成的一些有价值的结论或分析，也可以整理出来，放入项目知识库（如 docs/ 目录或团队 Wiki）。例如，在前面的复杂问题讨论示例中，AI 给出了两种架构方案的详细比较和建议。这种内容完全可以稍加编辑后写入决策记录文档，方便团队后来者了解当初为何选择了某方案。通过把 AI 的输出正式文档化，我们避免了知识只存留在对话里然后被遗忘的情况。

至于 Past Chats 聊天记录引用功能，本质上是把对话内容当知识使用。所以当一段对话结束后，如果觉得其中结论重要，不妨给这段 Chat 取一个清晰的标题，并在需要时通过 Past Chats 取用。这相当于沉淀了隐性知识为显性可检索知识。

8.2 项目规则和配置积累

Cursor Rules 和 Skills 是项目资产沉淀的另一种形式。我们在“控制策略”部分已经详细讨论了规则的制定和演进。在这里强调其长期价值：

• 把团队的编码规范、架构约定、常用技巧不断加入到 .cursor/rules/ 中，你相当于打造了一个团队知识库，而 AI 会在每次对话开始时自动读取这些知识。随着规则集的丰富，AI 对项目的理解会越来越深刻，犯错越来越少。这有点像训练模型，但实际上只是喂了更多上下文——却实现了定制化的效果。
• 规则也可以有全局和项目特定之分。Cursor 支持在设置中添加全局规则，适用于所有项目，以及项目本地的规则文件。对于你个人/团队而言，可以慢慢建立一套“通用 AI 编程守则”，涵盖一些通用的最佳实践。这套全局规则就像每次 AI 协作时你都会告诉它的一些基本准则（比如“遇到不确定就提问”“不要在代码里泄露机密”等）。当这些守则变成资产后，新开启的项目也能快速引用，不必从零开始告诉 AI。
• Skills（技能）方面，如果你开发了某些 Agent 技能脚本，比如自动循环 Runner、特定领域的命令等，那么一定要把这些脚本纳入版本管理，并在团队内共享。这些技能脚本相当于可复用的自动化工作流。积累一套好用的 Skills 库，能极大提升团队整体效率，也让 AI 的作用不仅限于当前项目，还可以跨项目发挥。

8.3 测试和案例库

项目资产中非常重要的一部分是测试用例。AI 在协作过程中，很可能帮你生成了大量单元测试、集成测试。这本身就是项目的宝贵资产。一定要把这些测试纳入版本库，并持续维护。当新功能上线或旧功能修改时，相应增加或更新测试。长远来看，一个覆盖良好的测试集不仅保障代码质量，也是训练 AI 的最佳教材。未来当 AI 参与改动时，这些测试会告诉它何为正确行为。而且我们也提到，可以把失败的测试结果反馈给 AI 修复。当测试集完善后，你几乎可以把解决问题的负担很大一部分交给 AI——因为稍有差池测试就会报错，它就不得不改到通过为止。

8.4 工作流和提示模版库

随着你和团队使用 AI 的经验增长，你们会逐渐形成一套好用的 Prompt 模板和工作流脚本。这些都是值得沉淀的。例如：

• 把常用的提示语写成模板收集起来，分类存储（可以放在团队内部的 Wiki 或者一个专门的 Markdown 文件里）。比如 “Bug 修复提示模板”、“代码重构提示模板”、“API 文档生成提示模板” 等。团队新人在遇到类似任务时，可以从模板库里找到相应 prompt，稍作修改就能用。这避免了每个人都要从头尝试怎么问 AI 才好的过程。
• 如果你已经摸索出一套成功的 AI 协作工作流，不妨将其写成指南，在团队内部分享培训。将流程标准化，其他成员照着做可以少走弯路。例如，可以沉淀出一份“使用 Cursor 开发新功能的流程清单”：从编写 Plan、到实施、到测试、到审查，每一步都写清楚，并列出可能用到的工具/命令。这样，新成员来了按清单操作就能更快上手，老成员也有据可依不会遗漏关键步骤。
• 社区资源也可视为资产。比如官方博客、优秀的使用案例文章，你可以在团队内部做一些整理归纳。例如 “Cursor 高级用法 FAQ”“遇到 AI 乱改代码怎么办” 等 Q&A 文档。知识不仅来自自己，也来自社区，汇总后就是你们自己的财富。

8.5 经验反馈到 AI 模型

资产沉淀的终极形式，可以考虑将项目积累的数据反哺到 AI 模型本身。这超出了 Cursor 工具的范畴，但值得一提。例如，把项目的典型代码片段、术语、风格指南整理后，通过训练（Fine-tuning）定制一个专用模型，可能会让 AI 更贴合你的项目需求。不过目前大语言模型的微调成本较高，而且很多闭源模型无法微调。因此，更实际的做法是依托前面讲的规则、文档、例子，把知识“灌输”给 AI，而不是修改 AI 参数。

还有一种折中方式是通过向量数据库构建项目知识库，然后在提示时自动嵌入相关知识（即 Retrieval Augmented Generation, RAG）。Cursor 暂时没有开箱即用的向量库集成功能，但你可以借助 Hooks 或 MCP，接入自己的知识库。例如，当你问 AI 某模块的问题时，先从向量 DB 里检索相关文档片段插入到提示中。这个流程需要一些自定义开发，但是如果你的项目域知识复杂、文档繁多，这种方案可以显著提高 AI 回答准确率。

无论如何，让 AI 变得越来越聪明的关键不是等它升级模型（那是厂商的事），而是我们提供给它的项目知识越来越丰富规范。这些知识就体现在我们沉淀下来的资产中。每完成一个迭代，我们都应自问：这次 AI 遇到了哪些新问题？我们采取了哪些新的规则或提示技巧？能否把它总结为经验，纳入我们的库？如此不断积累，AI 对你的项目就像一个越干越久的老员工，知道的“潜规则”越来越多，表现也会越来越稳定可靠。

归根结底，资产沉淀不仅仅服务于 AI，也是团队自身能力的沉淀。在 AI 帮助下，你会更快产出更多成果，更需要及时整理，否则“今天解决的问题明天又忘了怎么解决”。养成及时总结的习惯，把分散在对话和代码中的知识提炼出来，长远来看，这些沉淀将大大提高团队协作和 AI 协作的效率，让工作流形成正向循环。

8.6 面向 Agent 设计代码库

前面讨论的资产沉淀——规则、文档、测试、模板——都是显式的、增量的。但还有一种更根本的资产：代码库本身。

Peter Steinberger 分享了一个很有启发的观点：

我设计代码库的时候，已经不只是考虑”对我好不好”，而是要考虑”对 agent 好不好”。我会为模型优化最省力的路径，因为最终是它们在跟代码打交道，我负责的是整体结构和架构。

现在 pull request 对我来说，更像是 prompt request。有人提 PR，我会看看需求，然后和我的 agent 从这个 PR 出发，按我理解的方式重新设计这个功能。

“对 Agent 好不好”成为设计考量

以前我们设计代码时考虑的是：对人类读者好不好理解？对团队协作好不好维护？现在多了一个维度：对 AI Agent 好不好操作？

什么是“对 Agent 好”的代码库？

1. 清晰的模块边界：AI 更容易定位“这个功能在哪里”，不会在无关文件里迷路
2. 一致的代码风格：AI 更容易模式匹配，生成风格一致的代码
3. 好的命名：AI 通过名字理解意图，比通过注释更可靠
4. 显式依赖：隐式的魔法、全局状态、副作用对 AI 是噩梦（前面提到的 Postgres 触发器 bug 就是例子）
5. 可测试的结构：有测试的代码库让 AI 可以自我验证，形成反馈闭环

角色分工的变化

Peter 说“最终是它们在跟代码打交道，我负责的是整体结构和架构”。这描述了一种新的分工：

你不需要亲自写每一行代码，但你需要设计让 AI 能高效工作的环境。这有点像城市规划师和建筑工人的关系——规划师设计道路和分区，工人在这个框架内建造。

PR = Prompt Request

“pull request 更像是 prompt request”这个重新定义很妙。PR 的本质从“请合并我的代码”变成了“这是我想要的功能，请按我的理解重新实现”。PR 成了需求的载体，而不是代码的载体。你看的是“这个 PR 想做什么”，然后让 AI 按你认为正确的方式重新实现。

代码库是 AI 的工作环境

这段话的核心启示是：你的代码库就是 AI 的工作环境。就像你会为新入职的同事准备好开发环境、文档、规范一样，你也需要为 AI 准备好一个“对它友好”的代码库。

代码库设计得越好，AI 的输出质量就越高，你需要介入纠正的次数就越少。这是一种基础设施思维：与其每次交互时费力引导 AI，不如一次性把代码库设计好，让 AI 每次都能自然地产出高质量代码。

所以，当你下次重构代码、设计新模块、或者制定编码规范时，不妨多问一句：这样设计，对 Agent 友好吗？

Prompt 才是更高信号量的东西

如果代码库是 AI 的工作环境，那什么才是真正的“产出”？Peter Steinberger 的回答可能会让你意外：

当我看到一个 PR 时，我更感兴趣的其实是 prompt，而不是代码本身。我会要求大家把用过的 prompt 一起提交。有些人会照做，而我会花更多时间读 prompt，而不是读代码。

对我来说，prompt 才是更高信号量的东西：你是怎么得到这个结果的？具体问了什么？中间做了多少引导？这些比最终代码本身更能让我理解输出。我甚至不需要细看代码。

这是一个颠覆性的观点：代码只是 prompt 的“输出”，真正重要的是产生代码的思考过程。

为什么 prompt 的信号量更高？

1. 代码是“what”，prompt 是“why + how”：代码告诉你结果是什么，prompt 告诉你为什么这样设计、怎么引导 AI 得出这个结果
2. 代码可以被 AI 重新生成，prompt 不能：如果你有好的 prompt，可以随时让 AI 重新生成代码；但如果只有代码，你很难还原当初的思考
3. Prompt 暴露了思考质量：一个清晰、有结构的 prompt 说明作者想清楚了；一个模糊、混乱的 prompt 说明作者自己也不确定要什么

Peter 还进一步描述了他的工作流：

如果有人想要一个新功能，我会让他先写一个 prompt 需求，把它写清楚。因为我可以直接把这个 issue 丢给 agent，它就会帮我把功能做出来。真正的工作在于思考”它应该怎么工作””细节是什么”。只要这些想清楚了，我几乎可以直接说一句”build”，它就能跑起来。

需求本身就是可执行的。传统流程是“需求 → 开发者理解 → 写代码”，中间有“理解”这个可能出错的环节。Peter 的流程是“Prompt 需求 → 直接丢给 Agent”，需求就是代码的源头。

这意味着：

• Code Review 的意义在改变：以前是审查“代码写得好不好”，现在可能是审查“你是怎么引导 AI 的”、“你的思考过程对不对”
• Prompt 会成为新的知识资产：值得保存、复用、改进的不只是代码，还有 prompt
• “写需求”的能力变得更重要：能把需求写得清晰、具体、可执行，就等于能直接“编程”

编码不是工作，思考才是。

9 持续训练与提升

AI 编程工作流的构建和优化并非一蹴而就，而是持续训练和改进的过程。这种训练不光是训练 AI，更是训练我们自己——如何更高效地与 AI 协作，不断提升开发技能。本章探讨如何制定持续学习和改进的计划，使个人和团队的 AI 协作能力稳步提升，真正将 AI 变成长期的生产力加速器。

9.1 强化基本功，AI 放大优势

在讨论“基本功”之前，我们先回答一个更根本的问题：为什么有些经验丰富的开发者对 AI 持强烈怀疑态度？

Peter Steinberger 在《The Pragmatic Engineer》播客访谈中分享了他的观察：

一周前我正好看到一篇博客，是 Nala Coco 写的，我非常尊敬他，也从他那里学到很多。但那篇文章基本在否定当前模型的工作方式。他测试了五六个模型，其中还包括一些根本不适合写代码的，比如 OpenAI 那个 120B 的开源模型。

在我看来，他就是写了一个 prompt，丢进 Claude Web，点发送，把输出直接跑了一下，发现编译不过，于是很失望。但这太正常了——你真以为人类第一次写代码就能零 bug 吗？这些模型本质上是人类集体知识的幽灵，工作方式和我们非常像。第一次出错很正常，所以你才需要反馈闭环。

而且你不是”发一个 prompt”就完事了，你是在开启一段对话：我想做什么。比如他抱怨模型用了旧 API，那是因为他没说 macOS 的版本，模型自然会假设用旧接口。它的训练数据不只是最近两年，旧数据远比新数据多。你越理解这些”小野兽”的思维方式，就越会 prompt。

他可能玩了一天左右，就下结论说这项技术还不够好。但要真正用好，你得投入更多时间。这就像你会弹吉他，我把你放到钢琴前，你随便试两下，说”这玩意不行，我还是回去弹吉他”。不对，这是完全不同的构建方式、完全不同的思维方式。

这段话揭示了批评者的典型模式：

1

写一个 prompt → 丢进 AI → 编译不过 → "这技术不行"

问题在于：很多人期望 AI “一步到位”，但人类自己写代码都做不到这一点。

核心差异是心态：你是把 AI 当作“应该完美执行”的命令执行器，还是当作“需要学习如何协作”的对话伙伴？

Peter 的“吉他 vs 钢琴”类比非常精准。很多资深开发者的问题是：他们用“写代码”的思维方式去用 AI，发现不顺手，就说 AI 不行。但这就像吉他手试两下钢琴就说钢琴不行一样荒谬。AI 协作是一门全新的技能，需要专门学习。

Peter 还分享了他自己的学习历程：

你不知道我有多少次在凌晨三点对着 Claude Code 吼，因为它干了蠢事。慢慢地，我开始理解它为什么会严格按我说的去做，有时候甚至可以直接问它。去年在 Clawdbot 这个项目里，我感觉自己成了一个”人肉 merge 按钮”，社区太活跃了，我每天都在 review PR，几乎没时间写代码。一开始我会 cherry-pick 一点就关 PR，气得不行。后来我问它：你为什么这么做？它会说：当你这样说的时候，我是这样理解的。那一刻我意识到，我在学机器的语言。

我不断调整 prompt，现在几乎每次都能得到想要的结果，因为这本身就是一项技能。

这个转变过程值得细细品味：

1. 一开始：凌晨三点对着 AI 吼，因为它干了蠢事
2. 转折点：问它“你为什么这么做”，它解释了自己的理解
3. 顿悟：“我在学机器的语言”
4. 结果：不断调整 prompt，几乎每次都能得到想要的结果

“学机器的语言” ——这正是本指南想要帮助你掌握的。你越理解这些“小野兽”的思维方式，就越擅长与它协作。而这种理解的前提，是你自己具备扎实的工程基本功。

首先，要认识到：AI 放大的是你的已有能力。如果你具备扎实的工程基本功，AI 会让你的效率成倍提升；相反，如果基础薄弱，AI 可能放大的是混乱和幻觉。因此，在依赖 AI 的同时，不要忽视对基础技能的打磨：

• 持续学习算法、数据结构、设计模式等计算机科学知识。AI 可以快速写出代码实现，但由你来判断哪种算法或模式适用。如果对这些概念不熟悉，AI 给出错误方案你也难以察觉。
• 巩固软件工程实践：需求分析、架构设计、编程范式、测试设计、性能调优等。AI 可以加速执行这些实践，但前提是你知道要执行什么。比如，如果你平时就写规格文档、画架构图，那么用 AI 可以更快产出它们；但如果你从不做设计评审，上来就让 AI 写代码，结果可想而知。
• 保持良好的代码习惯：整洁的代码、清晰的抽象、合理的注释。这不仅让你的项目质量高，也给 AI 阅读代码提供了友好的环境。AI 善于模式匹配，如果整个项目风格统一、结构清晰，它输出的内容也更容易融入。而如果项目本身混乱不堪，AI 学了你的坏习惯，产出可能雪上加霜。

换句话说，把 AI 当作一面镜子，首先照出我们开发过程中的薄弱环节，然后加以改进。不要因为有了 AI 就放松对自己的要求——相反，应该以更高的标准要求自己。优秀开发者 + AI 的组合远胜于任何一方单独存在。所以在训练计划中，应包括对经典开发书籍和理念的学习（比如重温《Pragmatic Programmer》《Clean Code》等），然后思考如何将这些原则与 AI 协作结合。

知名程序员 Peter Steinberger（Clawdbot 创建者）在接受《The Pragmatic Engineer》播客访谈时分享了一个深刻的观察：

真正震撼我的是一个意识转变：现在我几乎什么都能做出来了。以前你得非常谨慎地选副项目，因为软件真的很难。现在当然还是难，但那种摩擦感不一样了。我会想：我在这类技术上很强，在那类技术上很弱——比如”那我们用 Go 写个 CLI 吧”，我对 Go 一无所知，但我有系统层面的理解。一旦你有这种理解，就会慢慢形成一种感觉，知道什么是对的、什么是别扭的，这本身就是一项技能。

这段话揭示了 AI 时代一个重要的能力转变：系统层面的理解比具体技术栈的熟练度更重要。当你理解软件架构的本质、知道好代码应该长什么样，即使面对陌生的语言或框架，也能借助 AI 快速产出高质量的代码。反过来，如果缺乏这种系统性认知，即使 AI 帮你写出了代码，你也很难判断它是否正确、是否优雅。

Peter 还提到了一个有趣的概念——与 AI 协作时的“摩擦感”：

我记得有人发过一条推，说写代码时你能感受到摩擦，这正是好架构诞生的方式。我在写 prompt 的时候也有同样的摩擦感。我能看到代码飞过去，能感知花了多长时间，能感觉 agent 有没有在”顶”你，能看出生成的东西是杂乱的还是有结构的。很多时候我一开始就能判断大概会花多久，如果明显更久，我就知道自己哪儿搞砸了。

这种“摩擦感”本质上是一种直觉——你能感知 AI 的状态：它是在顺畅地输出结构化代码，还是在磕磕绊绊地拼凑？当你发现 AI 生成得特别慢、输出特别杂乱时，往往意味着你的提示有问题，或者任务本身需要拆解。培养这种直觉，是成为 AI 协作高手的关键。

最终，Peter 将人与 AI 的关系描述为一种共生关系：

你会慢慢”感知”这个模型，知道它通常会怎么跑。这更像一种共生关系——我学会了如何跟它说话，甚至可以说是一门语言；与此同时，模型也在变得更好。

这正是本指南想要传达的核心理念：与 AI 协作是一门需要学习的“语言”，而掌握这门语言的前提是你自己具备扎实的工程基本功。

在同一次访谈中，主持人提出了一个尖锐的问题：AI 时代是否又回到了那种“大写 A 的架构师”模式——不写代码、只画蓝图、把方案往下传？Peter 的回应很有意思：

我不太用”架构师”这个词，我更喜欢”builder”。我发现用 AI 特别顺的人和特别痛苦的人，差异很明显。我更在意结果和产品体验，底层管道我关心结构，但不纠结最小细节。另一类人特别热爱写难算法，喜欢解决纯技术难题，不太喜欢做完整产品、营销这些，这类人往往最抗拒 AI，也最容易沮丧，因为 AI 恰恰擅长解决那些”难问题”。

这段话揭示了一个关键洞察：AI 时代最痛苦的，往往是那些以“解决难题”为身份认同的人。

为什么？因为 AI 恰恰擅长那些“难问题”——复杂算法、边界情况处理、技术细节优化。这些以前是稀缺技能，是程序员的护城河。一个能徒手写红黑树的人，在团队里是有光环的。但现在，AI 可以秒写这些东西。

这不意味着技术深度没用了。它的“交易价值”确实降低了——你不再能仅凭“会写难算法”换高薪。但它对于判断 AI 输出是否正确、理解系统为什么这样设计仍然至关重要。只不过，它从“可出售的稀缺技能”变成了“做好工作的基础素养”。这个转变很微妙，但影响深远。

Peter 说他更喜欢“Builder”而非“Architect”，这不是文字游戏，而是两种完全不同的心态：

Builder 的核心是：把东西做出来、交付价值。 AI 只是让这件事变得更快了。而那些以“能解决别人解决不了的问题”为傲的人，现在面临的不是技术问题，而是身份认同的挑战。

Peter 还说了一句特别重要的话：

这一年里，我学到的系统架构和设计知识，比过去五年加起来都多。这些模型里塞进了海量知识，几乎任何问题都能问到答案，前提是你得知道该问什么。

“知道该问什么”——这才是 AI 时代真正的核心能力。AI 模型里确实有海量知识，但它不会主动告诉你该学什么。你需要有足够的认知框架，才能提出正确的问题。这就是为什么 Peter 能“一年学到比五年都多”——不是因为他变聪明了，而是他知道该往哪个方向挖。

Peter 分享了一个具体的案例来说明这一点：

我当然也做过那个 Twitter 项目，到现在还没完工。整体功能其实能跑，但一旦用得稍微频繁一点，就会开始变得又卡又怪，然后过一阵子又恢复正常。我怎么都复现不了问题，调试起来特别痛苦，因为它不是那种稳定可重现的 bug，只是”用着用着就慢了”。

当时我在 Postgres 里写了一些逻辑，某些 insert 发生时会触发一些行为，结果数据库就会变得非常忙，而模型根本看不到这一层，因为抽象隔得太远了。模型很擅长顺着逻辑链条追溯，但这是一个非常隐蔽的副作用，只藏在一个文件里的某个函数里，跟其他地方几乎没有关联，名字也起得很糟，完全不显眼。我一直没问对问题，直到有一天我突然问：这个地方有没有任何副作用？结果一下就找到了，然后修掉了。说到底，一切都只差一个正确的问题。但前提是你得有足够的知识和经验，知道该往哪个方向问。

这个案例完美诠释了“问对问题”的含义。AI 的工作方式是：你指向哪里，它就分析哪里。它可以顺着调用链追溯、检查你提到的代码，但它不会主动想到“会不会是数据库层面有触发器？”或“这个性能问题可能和代码逻辑无关，而是基础设施的副作用？”——这需要你来问。

Peter 最终问的问题是“这个地方有没有任何副作用？”——这个问题之所以“对”，是因为它指向了正确的方向（不是问“代码哪里慢”，而是问“有没有隐藏的行为”），超越了直接的代码逻辑。而能问出这个问题，来自于他对系统的整体认知：知道数据库触发器可能造成性能问题，知道副作用往往藏在不起眼的地方。

这就是系统层面理解的具体体现。你不需要记住每个 API，但你需要知道系统有哪些层次、每一层可能出什么问题、性能瓶颈通常藏在哪里。这些认知框架，决定了你能向 AI 提出什么样的问题。

Peter 还提到了另一个重要的心态转变：

当你真正经营过一家公司、带过团队，你就知道不可能盯着每个人的代码，要求他们每一行都按你的方式来。很多没带过团队的人，很难学会放松一点，理解”这段代码也许不是我理想中的样子，但它能把我往目标方向推进”。不完美的地方，之后总能继续打磨。我非常相信迭代式改进。

这和 AI 协作是一个道理：你不可能（也不需要）控制 AI 写的每一行代码。“不完美但能推进目标”是完全可以接受的，不完美的地方之后总能继续打磨。迭代式改进——先让它跑起来，再慢慢优化——这比追求一次性完美要实际得多。

所以，回到“AI 时代是否需要强化基本功”这个问题，答案是明确的：不仅需要，而且比以前更需要。只不过，基本功的定义在悄然转变：

• 以前的基本功：能写复杂算法、能解决技术难题、能记住各种 API
• 现在的基本功：系统层面的理解、判断力、产品思维、知道该问什么问题

AI 改变的不只是工具，而是“什么是有价值的”这个定义本身。适应这个转变，技术上不难，心理上才是真正的挑战。

好奇心是最大的武器

如何建立系统层面的理解？Peter Steinberger 给出了一个简单但深刻的建议：

你现在拥有一台”无限耐心的机器”，它可以把一切给你解释清楚。你可以不停地问：为什么要这么设计？为什么是这个结构？通过这种方式建立系统层面的理解。但这需要真正的好奇心，而我觉得现在的大学教育并没有很好地教会你这一点。

这种理解通常是通过”吃苦”获得的，不会轻松。

这是 AI 时代学习的最大红利。以前，想理解一个复杂的开源项目，你要么自己硬啃代码（痛苦且低效），要么找个资深的人问（但他们没时间、也不愿意反复解释基础问题）。现在，你有了一个永远有耐心、永远不嫌你问题蠢的老师。

关键是：你愿不愿意不停地问“为什么”？

AI 工具人人都能用，但谁在用它不断追问“为什么”，谁就能建立起真正的系统理解。有些人用 AI 只是为了“快速得到答案”，复制粘贴就完事；另一些人用 AI 是为了理解——为什么这样设计？还有别的方案吗？各自的优缺点是什么？

前者只是在用工具，后者是在借助工具学习。长期来看，差距会非常大。

工具是平等的，好奇心是不平等的。

9.2 分阶段掌握 AI 工具

对于个人开发者，建议制定一个循序渐进的 AI 工具掌握计划，而不是一下子尝试最复杂的用法：

1. 入门阶段：先将 Cursor 当作智能 IDE 使用，熟悉其基本功能。如自动补全、简单的 Chat 问答（比如“这段代码什么意思”）等。体会 AI 对提高日常编码效率的帮助。这阶段只需在小项目或日常脚本中用 AI 做辅助，不涉及关键产出。
2. 进阶阶段：尝试使用 Cursor Agent 完成独立的小任务。例如写一个小型模块、一个算法函数等。练习编写清晰的提示，观察 AI 行为。此阶段着重练习 Plan-Execute-Verify 循环在小任务上的应用。例如给一个简单需求，让 AI Plan 一下再实现，然后写个小测试跑跑。通过这些练习，积累 prompt 技巧和对 AI 能力边界的认识。
3. 应用阶段：将 AI 正式引入你的主要项目工作流。从简单任务开始，如用 AI 改几个 Bug、写几个单元测试，逐步扩大到实现新功能。在真实项目环境中应用之前学到的控制策略、上下文管理等。一开始可能让 AI 参与度在 20%-30%，你依然手工为主；随着信心增加，可以让 AI 承担更多，比如 50% 以上的代码产出。
4. 高级阶段：当你对 Cursor 的功能和 AI 协作方式都驾轻就熟，可以探索更高级的用法，比如自定义 Agent、编写 Skills、整合 MCP 外部工具等。也可以尝试使用多个模型协同、甚至本地部署一些开源模型做辅助。这个阶段的目标是拓展 AI 能力边界，让它覆盖到更多流程环节，例如自动化部署脚本生成、运维日志分析、数据迁移脚本生成等等。

每个阶段都可以设定一些小目标和评估标准。例如，入门阶段目标是“掌握基本补全和聊天提问”；进阶阶段目标是“能用 AI 独立完成一个 500 行以内的小功能，测试通过”；应用阶段目标“团队引入 AI 协作流程，1 个月内提效 20%”；高级阶段目标“开发出 1-2 个自定义技能用于公司内部，提高特殊场景效率”。这些目标可以量化（比如开发速度、Bug 率的变化）来检验效果。

9.3 团队训练与协作

如果是在团队环境中推进 AI 工作流，可以考虑一些团队培训和协作机制：

• 内部工作坊/分享会：定期组织团队分享 AI 使用经验，交流成功的 Prompt 案例或踩过的坑。一方面促进大家同步水平，另一方面也收集改进建议。团队集思广益往往能碰撞出更好的 AI 使用方法。
• 导师制度：让已经熟练掌握 Cursor 的成员带新人。手把手演示一两个工作流循环，比如从 Plan 到最后测试通过的全过程。比起让新人自己琢磨，通过现场示范和指导会更高效。注意，这里的“新人”不一定是编程新人，而是对 AI 工具的新手——即使是资深开发，也需要学习如何与 AI 协作，这方面有经验的人可以作为导师。
• 制定团队 AI 使用指南：结合团队具体情况，编写一份内部的《AI 编程工作流指南》。内容涵盖团队推荐的 Prompt 模板、规则约定、常见问题处理等。让每个团队成员都明确 AI 的定位——AI 不是来取代他们的，而是帮大家解除重复劳动、提供第二思路，但人仍然对最终质量负责。这样的指南能统一大家的认知，避免有人过度依赖 AI 或完全不敢用 AI 的两极化情况。
• 逐步扩大应用范围：可能起初团队只在部分项目、部分环节用 AI，比如先从测试生成或者文档生成开始，让大家建立信任。在看到效果后，再逐渐让 AI 参与核心编码。管理层也需要跟进 ROI，如果发现效率确实提升、错误率并未上升，那可以更大胆地投入。反之，如果初期效果不理想，要分析是工具问题、方法问题还是人员技能问题，及时调整训练计划。

9.4 跟踪 AI 技术演进

AI 技术日新月异，新模型、新工具层出不穷。要让你的工作流始终高效，保持对新技术的关注和学习也很重要：

• 关注 Cursor 官方更新：Cursor 官方博客和更新日志会发布新功能和改进。例如引入新的模型、改进 Agent 能力、推出新的集成功能等。及时了解这些更新，可以让你马上用上新工具。
• 参与社区：加入 Cursor 官方论坛、相关的 Discord/Reddit/微信群等。社区中大家会分享使用技巧、扩展插件、遇到的问题等。这是获取一手经验的好地方。积极参与讨论，你也可以提出自己的问题，往往很快会有热心人士或官方人员解答。
• 学习相关工具和思想：AI 辅助编程不仅仅是 Cursor 一家。GitHub Copilot、Tabnine、CodeGPT 等都有各自特色。了解不同工具的优劣，有助于完善你的方法。甚至可以将多种工具结合，例如用 Cursor 写代码、用 Copilot 补全小片段。再如了解一些提示工程（Prompt Engineering）的原理、LLM 的基础知识（如 token、上下文长度机制等），能让你更透彻地理解 AI 行为，写出更精准的提示。
• 评估新模型：当新模型推出，不妨试用并比较与旧模型的差异。新的模型可能有更强的推理能力、更大上下文等，这会影响提示写法和效果。Cursor 支持选择模型，所以当新模型推出，不妨试用并比较与旧模型的差异。始终保持对模型能力边界的最新认识，才能调整你的协作方式。

最后，要以成长的心态看待 AI 与开发者的关系。AI 不会让你退化，只会提供无数学习机会。把每次与 AI 协作当成切磋：当它给出一个你没见过的实现思路，认真研究背后的原理；当它出错时，分析原因反思自己是否也容易犯类似错误；当它提出不同方案，比较权衡从中提高架构能力。长远来看，你会发现自己不仅没有被 AI 取代，反而因为与 AI 共事而成为了一个更全面、更高效的工程师。

总结一句话：训练计划的核心是持续改进。持续地学、持续地用、持续地总结，再持续地学——正反馈循环。一开始也许需要花精力适应 AI 工具，但一旦工作流走上正轨，收益将非常显著。正如我们在开篇所说，这是“AI 增强的软件工程”，不是“AI 全自动的软件工程”。你付出的每一点学习和改进努力，都会通过 AI 的放大得到数倍的回报，助你在编程之路上更上一层楼。

10 结语与展望

10.1 大公司与 AI 转型

前面讨论的都是“个人如何与 AI 协作”。但如果你在大公司工作，可能会发现：即使个人已掌握这些技能，公司整体的 AI 采用进度却很慢。这不是错觉。

Peter Steinberger 在访谈中直言：

我觉得大公司会非常难以高效地采用 AI，因为这要求彻底重塑公司运作方式。比如在 Google，你要么是工程师，要么是经理；想同时决定 UI 长什么样，这个角色不存在。但新世界需要的是那种有完整产品视角、什么都能干的人，数量要少得多，但必须具备极高的自主性和能力。理论上，公司规模可以砍到原来的 30%。

所以我一点也不惊讶大公司现在用不好 AI。他们确实在用，但要真正用好，得先做一次大重构——不只是代码库，还有公司本身。

为什么大公司很难高效采用 AI？

大公司的组织结构是基于分工设计的：前端、后端、产品、设计、测试、运维… 每个人只负责一小块，通过流程和会议来协调。但 AI 打破了这种分工的必要性——一个人 + AI 可以自己写前端和后端、自己设计和实现、自己测试和部署。

分工的前提是“一个人做不完”，但现在这个前提被动摇了。

Peter 说的“新世界需要的人”，和他之前提到的“Builder”心态完全一致：

重构公司比重构代码库更难

代码可以逐步重构，但组织变化涉及人、利益、情感：

• 涉及裁员：“规模砍到 30%”意味着大量人员调整
• 权力重新分配：中层管理的存在意义被削弱
• 文化冲突：大公司文化往往是“不要出错”，而 AI 协作需要“快速试错”
• 流程惯性：严格的审批流程是为“多人协作”设计的，但如果一人 + AI 就能完成，它们就成了阻碍

对个人的启示

如果你在大公司，不要等公司转型。先转型自己：

1. 培养“全栈产品视角”——不只是写代码，要理解产品、用户、业务
2. 学习与 AI 协作——本指南讨论的所有内容
3. 让自己成为那种“什么都能干的人”——当变化来临时，你已经准备好了

历史上每次技术革命都会淘汰一批组织形式。AI 时代，新型组织形态会出现——可能是“一人公司 + AI”，可能是“3-5 人小团队 + AI”。传统大公司要么转型，要么被这些新形态取代。

无论你身处何种环境，能力的积累是属于你自己的。当整个行业重塑时，那些已经掌握了“AI 协作语言”的人，将拥有最大的选择权。

10.2 对新人的启示：你的“劣势”可能是优势

如果你是刚入行的新人，可能会焦虑：AI 时代，进入门槛更高了，前辈们都在用 AI，我怎么竞争？

Peter Steinberger 的观点可能会让你意外：

他们也有一个优势：没有被过往经验”污染”。他们会用 agent 做出很多我们根本想不到的事情，因为他们不知道”这原本是行不通的”。等他们这么用的时候，可能它已经真的行得通了。

前几天我有一个小的菜单栏应用，用来在 Cursor、Claude Code 这些环境里做成本追踪，性能有点慢。我想，那就来做性能分析吧。按我过去的习惯，我会打开 Instruments，到处点来点去。结果 agent 直接在终端里把所有事情都做完了，速度也提升了，还给了一些建议。我当时真的被震住了，完全不需要再打开 Instruments。

这是一个很有意思的反转。老手的问题是：他们“知道”什么行得通、什么行不通。但这些“知道”是基于过去的工具和能力形成的。AI 改变了能力边界，很多以前“行不通”的事情现在行得通了。

新人不知道这些“规则”，所以他们会天真地尝试——然后发现，居然成功了。

经验既是资产，也是负担——它让你知道什么可行，但也限制了你的想象力。

Peter 还说：

我觉得我们可能低估了进入科技行业的人有多么有办法，也低估了年轻人的潜力。回头看，很多伟大的公司都是非常年轻、经验并不丰富的人创办的，但他们有巨大的热情。这依然是存在的机会。

AI 时代，“能写代码”不再稀缺，但热情、好奇心、敢于尝试依然是稀缺的。技术可以学，但这些品质很难培养。

所以，对新人来说：不要把“经验不足”当作纯粹的劣势。保持好奇心，大胆尝试那些“老手觉得不可能”的事情。你可能会发现，在 AI 的帮助下，它们其实是可能的。

10.3 核心要点回顾

在结束之前，让我们回顾一下本指南的核心要点：

1. Plan-Execute-Verify 循环：这是 AI 协作编程的基本框架。先规划，再执行，最后验证——不断循环迭代，而不是期望一次性完美。

2. 对话而非指挥：与 AI 协作不是发号施令，而是结对探索。用“我们讨论一下”、“有哪些选项”来延迟执行，在理解清楚之后再动手。

3. 雕塑式构建：不追求一开始就有完美蓝图，而是边做边发现形状。“不行就扔，或者重提示”——试错成本极低，让形状从过程中浮现。

4. 最小闭环：将大任务拆解为小步骤，每步都能产出可验证的结果。小步快跑，频繁提交，保持对方向和质量的掌控。

5. 反馈闭环是关键：让 AI 能自己测试、自己 debug。有了测试和 CI，你不需要逐行审查，可以信任流程。

6. 基本功比以前更重要：AI 放大的是你的已有能力。系统层面的理解、判断力、“知道该问什么”——这些才是 AI 时代的核心竞争力。

7. 好奇心是最大的武器：你拥有一台“无限耐心的机器”，可以不停地问“为什么”。工具是平等的，好奇心是不平等的。

最后，记住 Peter Steinberger 的那句话：与 AI 协作是一门需要学习的“语言”。一开始可能会在凌晨三点对着它吼，但慢慢地，你会学会它的思维方式，几乎每次都能得到想要的结果。

这不是“AI 全自动的软件工程”，而是“AI 增强的软件工程”。你付出的每一点学习和改进努力，都会通过 AI 的放大得到数倍的回报。

祝你在 AI 协作编程的道路上，不断精进，成为驾驭 AI 的卓越开发者。

11 附录：资源与延伸阅读

构建 AI 编程工作流是一个综合性课题，这里列出一些优秀资源供进一步学习。读者可根据需要查阅，巩固和扩展本指南所涵盖的内容。

• Cursor 官方博客与文档：了解 Cursor 最新功能和最佳实践的权威来源。例如，官方博客的文章《使用 Agent 编码的最佳实践》详细讲解了从规划、上下文管理到自定义工作流的技巧。Cursor 官方中文文档站点也提供了规则、技能等功能的解释和示例。
• AI 编程工作流指南（SegmentFault）：一篇面向 2026 的实战指南（作者俞凡），总结了将 LLM 当作结对编程助手的 10 条准则，包括先写规格再写码、小步迭代、充分提供上下文、保持 Human-in-the-loop 等。本指南的很多理念与其不谋而合，强烈推荐阅读原文以获得更系统的认知。
• Cursor 高级配置与技巧：社区有不少分享 Cursor 使用技巧的文章，如《全网最全 Cursor 配置指南：从入门到高效工作流》，详细介绍了如何选择更强模型、扩大上下文、使用 @ 引用、集成外部文档和 MCP 等配置，可以帮助你将 Cursor 调校到最佳状态。另有《高效使用 Cursor 的 12 条黄金法则》也总结了一些宝贵经验。
• 自定义 Rules 和 Skills：想深入掌握 Cursor 扩展能力的读者，可以参考 Cursor 官网关于规则和技能的文档。另有中文社区文章对 Cursor Rules 的工作原理及四种类型做了浅析，GitHub 上也有他人整理的中文 Rules 示例仓库供参考。了解这些有助于你打造自己的个性化 AI 小助手。
• AI 辅助开发社区经验：加入相关社区以获取他人实践心得。例如 Reddit 的 r/ChatGPTCoding 板块，有用户分享他们日常的 Cursor AI 工作流程；Bilibili 上也有系列视频教程演示 Cursor 从入门到实战的全过程。知乎、掘金等平台上亦不乏 Cursor 的使用案例和避坑指南。阅读和观看这些内容，能让你少走弯路、发现新技巧。
• 传统开发方法论书籍：不要忽视经典书籍的价值。《The Pragmatic Programmer》（《程序员修炼之道》）、《Clean Code》（《代码整洁之道》）、《Refactoring》（《重构》）等书中蕴含的原则在 AI 时代依然适用，甚至更加重要。将这些原则与 AI 工具结合，是打造高效工作流的最佳途径。
• AI 伦理与安全：提醒关于 AI 使用的伦理和安全方面资源。随着 AI 深度介入开发，要注意避免泄漏敏感代码到云端、警惕 AI 可能引入的有害代码片段等问题。可以参考微软等发布的安全指南，以及相关使用政策，确保在合规、安全的前提下使用 AI 工具。

希望以上资源能帮助你进一步深入学习。在 AI 编程工作流的探索之路上，多看、多问、多实践是关键。愿你不断汲取新知，在实践中融会贯通，早日将本指南的理念内化为自己的工作习惯，不断精进，做一个驾驭 AI 的卓越开发者！

1

在过去的半年时间里，我几乎没有亲自写过一行代码。代码都是让AI帮我写的。

说实话，AI写的代码比我写得好，比我写得快。那么AI把我的活儿都给干了，那我干什么呢？凭什么我还能上班领工资呢？

作为一个“离AI最近的行业”从业者，我想通过这篇文章分享三条亲身体会的感想。对，就是感想。并不是什么AI使用技巧，也不是AI入门手册，就是感想。

AI发展日新月异，所有具体的操作和步骤都可能会过时，但是切身体会的感觉和想法不会过时。我身上感受到过的，以及我脑子想到过的，你都很快会感受到和想到。

2

第一点感想就是，如果你想知道AI有多厉害，就要用最贵的工具。

我跟很多人安利过AI聊天工具。他们给我的反馈一般都是：我用过了，感觉一般般。

听到这样的回答，我很惊讶——为什么对我来说惊为天人的发明，他们会无动于衷呢？很大的一个原因就是他们没用过最好的AI聊天工具。

最好的AI聊天工具都是国外的，OpenAI的ChatGPT、Google的Gemini和Anthropic的Claude。

我用过国内的AI聊天工具，如果是闲聊的话还可以。但是如果谈论的是专业的话题或者是深刻的话题，国内的AI聊天工具都比不上我刚才列举的三个。如果你分辨不出它们的高下，很可能是因为你提的问题都很浅。

回到工具这个话题，我之前一直在Cursor里用的是GPT 5.2这个模型，价格比较适中。我有听说过Claude编程更厉害，但是太贵了，调用一次的价格是GPT 5.2的好几倍。所以，我一直没敢真的尝试用Claude来帮我写代码。

机缘巧合之下，我心血来潮订阅了200美元一个月的超级会员，能用的额度一下子多了起来。于是乎，我就开始使用Claude。结果，非常惊喜。

Claude的代码完成度非常高，而且经常有自主性的发挥，帮我查缺补漏。用人来类比的话，Claude就像一个聪明的下属，不但能帮你把安排给他的事情都保质保量完成，还经常会给你额外的惊喜。

试用之后，我再也回不去了。曾经沧海难为水。用别的模型帮我编程，我总觉得他们笨笨的。

3

第二点感想就是，如果AI工具能完成一项工作的99%，你就应该交给他，然后你去找更重要的事情去做。

前几年，AI还没那么聪明能干，写出来的代码只有一半能用。最近大半年，AI进化得非常快，写出来的代码99%都可以用。在这种情况下，我就不写代码了，我去做更重要的事情——需求澄清、安全加固和架构设计。

就好比你培养一个下属。一开始，他没什么经验，你交给他的事情，一半能做好，一半还需要你帮他兜底和擦屁股。后来，他边学边进步，你交给他100件事情，他99件都能做好。那么你就可以把自己的岗位让给他，你晋升到更高的岗位上，做更重要的事情。

有人问，那如果我没有能力晋升，也不想做更重要的事情，怎么办呢？那局面就很不妙了，你要么就另谋出路，转行到没有那么多竞争的地方，要么就要面临被淘汰的残酷现实。

一开始，我的心态是很轻松的。觉得AI能帮我写代码，我可以不用那么累了，可以摸鱼了，可以偷懒了。

后面我发现根本就不是那么一回事。公司迟早会发现，或者我的同事们迟早也能学会用AI写代码，到时候对我这个岗位的要求就不只是会写代码那么简单了，必然会有更高的要求。

AI带来的危机感终将平等地降临到每一个普通人头上。只是有些人早一点，有些人晚一点。

4

第三点感想就是，我们要做创新的事情，创新就需要“浪费”。

我开通了Cursor的200美元每月的超级会员之后，发现额度还不够用，就用另一个账号也开通了超级会员。也就是说，我每个月要花400美元，大概2800人民币。

因为有大量的额度可以用，我开始用AI做各种各样的尝试。除了写代码，我让他帮我检查代码、做接口测试，最近还让他帮我控制浏览器页面，像真人一样操作，测试系统有没有问题。

这些尝试都很花钱，每天我用掉的额度都在30美元到50美元左右。但是我觉得非常值。我积累了很多其他人还没接触到的AI使用技巧和经验，能用更先进的方法来完成工作。

不管你是做什么工作的，我都建议你要做这样的尝试。一开始你可能会觉得是在“浪费”钱，或者是“浪费”时间，但是尝试过后你就会发现，投入到AI里的每一分钱和每一点时间，都会是值得的，更是必须的。

因为你现在干的工作，未来“有的是AI干”。

5

AI浪潮之下，我一开始的感觉是惊喜。因为终于有“人”可以跟我对话，可以给我解答问题，可以跟我讨论了。

后来，我的感觉是庆幸。AI首先冲击的是初级和中级编程岗位，轮不到我头上，我不怕。

接着，我的感觉是恐慌。AI写的代码比我好，写的速度比我快，我会不会很快就被淘汰呢？

最后，我的感觉是平常心。用一颗平常心面对AI的发展，保持学习的劲头和学习的速度，面对新时代的挑战和机遇。

不就是学习吗？在下不才，恰好精通此道。

1

上个月的阅读情况很不理想。看书229小时，低于原定目标的250小时。不仅是2025年一整年看书最少的一个月，还是最近两年多以来最低点。

冥想情况有所好转。冥想了33.5小时，比前一个月多。

接下来一个月，也就是一月份，我的阅读时间会有一个明显的上涨。因为，我“复活”了番茄土豆APP。

2

我的阅读数据一直以来都是用APP记录的。APP的名字叫番茄土豆，开发的公司已经倒闭了。APP从去年8月份开始就用不了。

去年我用很短的时间，用一个简单的网页版做了一个替身出来。勉强能用，可以帮我记录阅读数据，但是并不好用。

前天晚上，我突发奇想，不如用AI辅助编程帮我重新开发一个番茄土豆APP吧。

说干就干。我问了ChatGPT要如何在Macbook上开发iOS程序，以及如何在自己的手机上安装。扣除下载安装开发工具的时间，我只用了半个小时就做出MVP版本。

在接下来的两天时间里，我的阅读热情高涨了很多，因为可以用顺手的APP来帮我记录阅读。即便有不顺手的地方，我马上就可以改代码。当然，不是我自己改，是我给AI指令，让AI帮我改。

用AI写APP的过程，我几乎没有遇到障碍，一行代码都不用自己写。

3

我思考了为什么“复活”的番茄土豆APP能让我变得更加积极阅读。这个原因就是，助推。

你爱不爱做一件事，想不想做一件事，最初的动力是很难改变的，别人是不可能帮你的。

一个不爱看书的人，你做一个再好用、再定制的APP给他，他还是不爱看书。相反的，即便没有APP，我还是会看书，而且是主动看书。

然而，有APP和没APP，对我来说，对一个有阅读意愿和阅读习惯的人来说很重要。有了APP，我会更容易想到要看书，会在看完书之后更有成就感，下一次更愿意看书。没有APP，看书的次数就会明显打折扣。

就像健身，如果一个健身房装修很好，设备很新，服务很周到，我肯定会去更多次。相反的，如果这个健身房年老失修，没什么服务，我就不愿意多去了。

好的APP，就像好的装备一样，能帮助一个人更好地坚持做一件事。

4

我是最近才享受到了编程的乐趣。

首先，AI让编程变得容易，变得更加有趣。

还有，我从编程中总结出一个人生哲学的道理。这个道理，可以从拍照开始说起。

手机让拍照变得容易，我们每个人或多或少都会拍照。有的人喜欢自拍，留下自己年轻好看的样子。有的人喜欢拍孩子，发朋友圈炫耀自己的孩子多可爱。有的人喜欢拍风景，记录自己欣赏大自然的瞬间。

那么，到底是什么决定一个人在什么时候拍照，拍多少张，拍什么的呢？是他们的价值观。

他们的价值观告诉他们，什么是美好的，什么值得拍。

相对应的，编程也是同样的道理。代码只是工具，编程的目的是收集信息、处理信息和使用信息。

那么到底哪些信息重要，这些信息要怎么处理，最终要使用到什么地方。这些是什么决定的呢？是我们这些Coder的价值观。

Coder的价值观告诉我们自己，哪些信息是重要的，哪些信息值得注意。

你有没有发现，其实照片就是信息。拍照和写代码一样，都是判断哪些信息重要，然后把信息收集起来，然后就是处理和使用。只是工具不一样罢了。

想明白了这个道理，我觉得编程更有意思，也更有意义。

5

最近一段时间，我会不断优化我复活的“番茄土豆”APP。优化的过程，就是使用的过程。使用越多，我看书就越多。

这就是正向循环。

截至2025年12月31日，我一共阅读了19138.5小时。预计会在2026年4月10日，完成第二个10000小时，也就是总共20000小时的阅读目标。

一月份的阅读目标是540个番茄时间，也就是270个小时。

1

今年的年度总结，从一条给我带来认知冲击的新闻开始说起。

近两年，已经有不少省市把“计算机科学”、“软件工程”等专业列为红牌专业，建议考生谨慎报考。

这之所以会让我觉得震惊，不仅仅是因为我是计算机专业毕业的，还因为前几年计算机专业还非常热门，而且供不应求。

那真是一个黄金年代。哪怕你不是计算机科班出身，去报一个软件开发的培训班，稍微努努力就能找到一份月薪万元的工作，而且前景相当好。跳槽勤快点，平均每年涨薪15%到20%不是什么不可思议的事情；哪怕你不喜欢跳槽，在一家还算不错的公司一直干，年均涨薪10%是很普遍的。

在那个年代，经常会流传这一类故事：某一个能力平平的程序员加入到一家默默无闻的创业公司，公司被收购之后就财富自由了。

如果你没有经历过那个年代，你也可以看看我七八年前写的文章。那时候我天真地认为，每年涨薪10%到20%是理所应当、天经地义的事情。

从震惊中恢复过来，我总结出有三点原因：

• 第一，整体经济下行。
• 第二，招生扩张过快。
• 第三，AI辅助编程突破。

前两条原因无须过多解释。第三点原因的来龙去脉是这样的：由于大语言模型的横空出世，AI辅助编程有了很大的突破——从原来简单的模板代码生成和代码补全，直接进化到可以从头到尾完成一个中小型需求的开发。

也就是说，原来需要一个高级程序员带着两三个中级、初级程序员干的活儿，现在只需要一个高级程序员就可以了。

那么，中级程序员和初级程序员有没有可能替代高级程序员呢？答案是，不能。他们之所以不是高级程序员，就是因为他们还没有应对复杂度需求的能力。

另一方面，AI生成的代码所潜藏的问题往往是他们看不出来的。这既是能力决定的，也是经验决定的。

于是，这就出现了一个很奇怪的局面——在招聘市场上，中级、初级程序员的岗位变少了，而高级程序员和资深架构师的岗位变多了。

其实，不是市场需要的程序员变少了，而是对程序员的要求变高了。

2

市场上的变化，导致「35岁」现象出现了逆转。

在此之前，程序员行业一直有一个说法——“35岁如果升不到管理岗，就很容易失业”。这个说法的现实基础是，写代码虽然是一个脑力活，但是很多时候会变成一个体力活。在AI辅助编程取得突破之前，有很多重复的工作需要做，而且常常因为需求变更或者是应对突发情况要加班，所以程序员大多要能熬夜。

35岁不做管理、只编程，就会有两个劣势。第一，你的工资高；第二，你的熬夜能力比不上小年轻。

如果没有X因素出现，今年34岁的我很快就要考虑转行或者降薪做外包。在2025年，X因素出现了。

2025年年初，各大AI辅助编程工具推出了Agent模式。从原来只能简单辅助程序员写代码，进化到了可以完成中小型需求的全部代码编写的程度。程序员的重复性工作和简单的任务急剧减少，这就导致了中级、初级程序员岗位的市场萎缩。

与此同时，由于AI辅助编程导致软件开发的成本出现了下降，继而导致了软件市场的需求量反而变大了。这就是经典的杰文斯悖论（Jevons paradox）——当某种资源/技术的单位成本下降、效率提高时，结果往往不是总消耗下降，反而会因为使用变得更便宜、应用场景扩张而让总需求/总消耗上升。

这个悖论来源于19世纪的英国。经济学家William Stanley Jevons发现，瓦特蒸汽机提升了煤的使用效率，降低了单位效用的成本，结果使得蒸汽机被更广泛地应用到更多场景，使得煤的需求不降反升。

这个悖论，不仅出现在第一次工业革命，还出现在第二次工业革命。电力越来越便宜，电力的普及范围就越广泛，最终使得电力的需求越来越高。

互联网时代如此，AI时代也如此。

3

我是幸运的。如果早出生几年，我很可能就已经要转行了。如果晚出生几年，我很可能毕业即失业，很难找到工作。

我觉得我更幸运的是，编程对我来说变成一件好玩的，有意思的事情。这对于我来说，要比工作更好找、能赚更多钱重要得多。

我是在今年8月份开始使用AI Agent帮助我写代码的。在此之前，写代码已经让我很厌倦了。

第一，写代码很孤独。写代码的时候，你没法跟别人讨论。程序员很贵，每个人都很忙，都要赶时间把自己负责的那部分写完。无论是一起讨论设计，还是code review，很多时候都已经沦为形式。

第二，写代码很琐碎。写代码要注意很多的细节，你稍不注意就会犯很基础的错误。哪怕再小的错误，都有可能变成在亚马逊雨林里煽动翅膀的那只蝴蝶，在你意想不到的时候和意料不到的地方掀起一场灾难性的风暴。

第三，写代码很无聊。正如之前所说，写代码的过程中有很多简单重复的工作，这些活儿很容易消耗你的耐心和激情。

使用AI Agent之后，这一切都变了。

写代码变得不孤独了。我从理解需求开始，就可以跟AI讨论。把需求讨论明白了，我就让他给出设计，提供好几个方案让我挑选。方案细节确定好了，我就让他帮我落地代码。最后，我再检查他的代码实现是否符合预期。

写代码变得不琐碎了。AI能把琐碎的事情做得很好，而且做得很快。我可以让他反复检查代码，甚至可以让不同的AI Agent互相检查。

写代码变得不无聊了。AI天生就不怕重复，不怕简单。我的心智宽带就可以解放出来，去思考更多更高级的事情——更好地理解需求，更好地设计架构，更好地重构代码。这些事情，更有意思。

4

编程更有意思，更好玩了。我也发现我恰好擅长用AI编程。

首先，我有丰富的AI对话经验。我从2023年5月份开始，就高强度地使用ChatGPT。我一边看书，一边向AI提出问题，跟他讨论更大范围的话题，并不局限于书中的内容。直到这篇文章写作的此刻，我已经跟AI对话了1800小时。

然后，我喜欢在对话中学习。出现了AI之后，我可以在一边工作，一边跟AI学习各种各样之前不熟悉的知识。学习和实践，结合得更加紧密了。

最后，我特别擅长把模糊的问题变成清晰可执行的步骤。我厌恶模糊，喜欢清晰。我乐意把工作和生活拆解成一个个计划和执行清单，在规划、执行、反馈和优化中获得乐趣。

我很幸运，恰好能用自己喜欢又擅长的事情养活自己。

5

近几年，我越来越厌恶过去信奉的“优绩主义”——认为优秀的人就应该得到更多；不优秀就意味着不努力，就意味着一个人是失败的。

我逐渐让自己转向“我对什么感兴趣”。什么事情能引起我的兴趣？做什么能让我兴奋起来？学习什么样的内容可以让我的大脑进入激活状态？

这是一个艰难的转向。作为一个接受了十几年应试教育的中国学生来说，尤其我还是某种程度的既得利益者，我很难不信奉优绩主义。从小，爸妈就告诉我分数高才能上好学校。上学时，学校因为我成绩好才不收或少收我学费。毕业之后，我也因为学历得到比一般人多得多的面试机会。

这是一个必然的转向。我越来越意识到优绩主义对我的伤害。我一旦做得没那么好，我就会质疑自己，甚至会质疑自己存在的价值。我对一件事情感兴趣的同时，就会下意识地问自己“这对我有什么好处”。我对他人的评价不怎么取决于他们是否友善、幽默、慷慨和关心他人，而是他们是否足够“优秀”。

在接下来的一年时间里，我会连续订阅12个月200美元每月的Cursor会员，并且每个月都要用完里面的额度。我希望大量的实践，能给我带来足够的灵感、激情和创造力。每个月，我都至少写一篇文章，记录我使用的心得和感想。

与此同时，我会更多地问自己，我对什么感兴趣，我想要做什么，我更想把时间放在什么事情上。

1

十一月份阅读情况还可以。看书234.5小时，超过原定目标的230小时。

冥想情况比较一般。这个月冥想了26.75小时。可能是因为这个月的工作比较轻松，压力没那么大，所以冥想就少了。这个月要有意识增加一些冥想时间。

接下来，我想跟大家聊一聊我是如何坚持健身的。

2

从6月到12月，我坚持健身了整整半年。我是怎么坚持下来的呢？

当然不是靠热情。热情只有在开始阶段管用，后面就不行了。我在刚开始的时候，试过一周六练——除了每周上四节私教课，我还会额外自己去健身房练两天。这是我热情最高涨的时候。

热情很快就退却。接下来的几个月，我几乎一次都没有自己主动去过健身房，除了上私教课之外。

坚持要靠制度。我跟我的私教在一周结束时，就会约定下一周的课——一周四练，分别是哪几天上课。我是一个非常信守承诺的人，没有特殊原因的话，我不太可能会取消上课。有那么好几次，我因为睡不好而非常不想去上课，内心挣扎一番之后还是去了。

每次遇到这种情况，我都会感慨：私教课的钱，花得真值。

3

有一段时间，我的私教生病住院，不能带我上课。我又是一个社恐的人，不想临时让其他教练带我上课。于是我就自己去锻炼。

自己去锻炼的效果远没有教练带着我锻炼要好。我总是偷懒，做力量训练的重量会轻一点，做动作的每组次数会少几次。

因此，好几次我都不想去锻炼，觉得这么低质量的锻炼，不如不锻炼。但是，我后来还是去了。

因为就坚持而言，锻炼的质量是次要的，锻炼的数量（次数）才更重要。

我说服自己，哪怕是去健身房打个卡，我也要去。哪怕我是去健身房玩手机，我也要待够一个小时。

我不可能真的完全只看重数量，而完全不重视质量。所以只要坚持去锻炼，数量够了，质量自然会上去。

我相信，哪怕以后不请教练了，我还是很有可能继续坚持锻炼的。

4

如果你锻炼了半年，花了两万块的私教课费用，小肚子还是没减下去，体重没有变化，你还会继续锻炼吗？

我会。

因为这半年时间里，我的身体素质变好了，睡眠变好了，心理健康变好了。我还会坚持锻炼下去。

首先，我知道自己没有注意饮食。注意饮食要消耗注意力和意志力，我担心同时要兼顾工作压力和锻炼压力，再加上克制饮食的话，我会坚持不住。所以有意无意的，我没有让自己注意饮食，还是跟往常一样。

然后，减肥和增肌，甚至是有一个健美的身材，对我来说只是一个次要的目的。次要的目的，能达到很好，达不到也没关系。或者说，晚一些达到也可以。

身心健康，睡眠变好，让我的脑子转的更快，能更好地应对工作和学习，才是我锻炼的主要目的。主要目的，不仅达到了，而且是超出了预期。

5

这么多年的阅读，给我带来一样很重要很重要的东西，就是耐心。我学会了耐心地、长期地做一件事情，只要它足够重要。

健身锻炼对我来说就是一件足够重要的事情。我才做了半年，我不会奢望就有非常惊人的效果，例如减重20斤，长出六块腹肌和人鱼线。

就像之前设定的一样，我的中期目标是两年内身体素质明显变好——每天睡够7.5小时，心率变异度能到50ms以上，体脂率降到20%以下。

长期目标是坚持健身二十年后，身体年龄比实际年龄小5到10岁。

截至2025年11月30日，我一共阅读了18909.5小时。预计会在2026年4月10日，完成第二个10000小时，也就是总共20000小时的阅读目标。

十二月份的阅读目标是500个番茄时间，也就是250个小时。