如果你最近在认真使用 AI 写代码，大概率会陷入一种微妙的焦虑：工具确实能快速产出大量代码，但你已经说不清自己是在编程，还是在给 AI 当打字员。网上流传的各种 AI 编程演示视频看起来很爽——用人话描述需求，代码就像瀑布一样流出来，屏幕上光标自动跳动，好像什么都快起来了。可一旦需求变复杂、线上出问题、或者需要 review 别人的代码，那种“看似变强、实则失控”的感受就会立刻暴露出来。
这篇文章想讨论的不是“要不要用 AI 编程”，而是一个更实际的问题：如何设计一套让 AI 产出可审查、可解释、可维护代码的工作流。我的核心判断是：AI 编程的真正分水岭不在工具，而在工作流。只要把规则（Rules）、提示（Prompt）、审查（Review）三个环节补上，你就能从“被 AI 牵着走”回到“你牵着 AI 走”。
读完这篇文章，你会得到一套可以直接落地的规则文件写法、Prompt 模板、代码审查清单和一个完整的实战流程。它适合正在用或准备用 AI 编程助手的开发者，也适合需要在团队里推动 AI 协作规范的工程师。
1. 这篇文章真正要解决的问题
先看一个真实场景。你接到一个需求：给系统增加一个“用户注册”接口。你很自然地打开 AI 编程工具，输入一句话：“帮我写一个用户注册功能。”AI 在几秒内返回了 Controller、Service、Mapper 三层代码，看起来滴水不漏。你复制、运行、注册成功，感觉效率翻倍。
问题在两周后出现。用户注册的手机号没有做格式校验，某个国家区号的号码被误判成非法格式；异常处理只捕获了通用Exception，数据库唯一约束冲突直接变成了 500 错误；密码加密用的是不推荐的老算法。此时你再回头看那堆 AI 生成的代码，发现自己根本没有认真读过它们。
这就是“氛围编码”的典型后遗症。Vibe Coding 这个词最初指开发者借助 AI 不断试错、快速构建原型，强调那种“凭氛围写代码”的沉浸体验。但在大量工程实践中，它逐渐变成了一个贬义词：开发者对 AI 生成的代码没有理解、没有掌控、没有责任感。代码能跑，不代表代码应该被合并；能出结果，不代表你能解释它为什么这么写。
这篇文章想解决的核心问题就是：怎么既不放弃 AI 的效率，又不会失去对代码的掌控力。答案不是回到手写一切，而是建立一套**“规则约束 + 提示设计 + 人工审查”**的闭环。只有当你能够审查 AI 生成的每一段代码，并且有能力修正它时，AI 编程才从“玩具”变成“杠杆”。
2. 真编码与氛围编码：两条路线，三种关键差异
先给出两个定义。
氛围编码（Vibe Coding）：开发者用自然语言描述意图，AI 自动生成大量代码，开发者只看运行结果是否“像对了”，几乎不深入理解生成逻辑。它的核心体验是“快速看到东西跑起来”。
真编码（Real Coding / Deliberate Coding）：开发者把 AI 当成一个需要管理的外部协作者，先规定规则，再设计提示，最后对 AI 输出的代码做完整审查。开发者可以解释每一行被合并进主干的代码为什么存在，以及它可能带来什么副作用。
两者的差异主要体现在三个维度。
第一，控制权不同。氛围编码过程中，控制权在 AI 手里。它选择实现方案、决定异常处理方式、猜测业务规则。开发者唯一能做的是“不满意就让它重写”。真编码过程中，控制权始终在开发者手里。AI 只是提出方案，是否采纳、如何调整，完全由人决定。
第二，错误定位成本不同。氛围编码里，一旦生产环境出现故障，开发者面对的可能是一段自己从没认真读过的代码。你不知道它的边界条件是什么，也没法快速判断是业务逻辑错了，还是 AI 生成的框架代码踩了坑。真编码则要求你在合并之前就做过审查和验证，问题往往能收敛到很小的范围。
第三，长期维护价值不同。代码的阅读次数远多于书写次数。氛围编码产出的代码即便能跑，也常常留下“只有 AI 懂”的尴尬局面。真编码产出的代码，因为经过人审、有过修改，维护者心里清楚哪些地方是刻意设计，哪些地方是折中方案。
用一个表格来对比，会更清楚：
| 对比维度 | 氛围编码（Vibe Coding） | 真编码（Deliberate Coding） |
|---|---|---|
| 谁做核心决策 | AI 模型 | 开发者 |
| 对生成的代码理解 | 停留在“大概能跑” | 能解释每一段关键逻辑 |
| 错误定位效率 | 低，可能完全失控 | 高，问题可追溯 |
| 适用阶段 | 一次性原型、Demo、试验 | 生产代码、长期维护、团队协作 |
| 代码审查成本 | 返工成本高 | 合并前成本高，但可控 |
| 长期维护性 | 差 | 好 |
需要强调的是，这两个概念不是道德上的好与坏。氛围编码非常适合探索型任务：验证技术可行性、写一次性脚本、生成测试数据。真正的错误是把氛围编码的结果直接当作真编码的交付物。很多开发者以为自己在用 AI 提效，实际上只是用 AI 制造了大量自己无法消化的技术债。
所以更准确的表述是：你可以先用氛围编码的方式快速生成一个草稿，但必须用真编码的流程去转换它。草稿是输入，真编码才是输出。
3. AI 编程工具与运行环境准备
既然要落地工作流，先解决工具和环境问题。AI 编程工具的形态大致有三类，你可以按习惯选择，核心思路是相通的。
第一类是IDE 插件，代表产品有 GitHub Copilot、通义灵码、JetBrains AI Assistant。这类工具嵌入现有开发环境，在补全代码、生成单测、解释代码片段方面体验顺滑，学习成本最低，很适合作为进入 AI 编程工作流的第一步。
第二类是独立 AI 编辑器，代表产品有 Cursor、Windsurf 等。它们把对话、代码生成、项目上下文整合在一起，能对整个仓库做全局理解和编辑。如果你经常做跨文件重构或在一个新项目里快速搭建骨架，这类工具会更顺手。
第三类是终端 Agent 工具，代表产品有 Claude Code、Codex CLI 等。它们直接跑在命令行里，可以读取文件、执行命令、批量修改代码，适合自动化任务和复杂重构脚本。门控更高，但可控性也更强。
还有一些团队会通过 API 网关或内部平台接入模型，让 AI 能力变成团队统一服务。这个方案适合对数据隐私和成本控制有要求的企业，这里不展开。
环境准备方面，常见的共性是：需要安装 Git，保证命令行可用；需要配置好对应编程语言的运行时，比如 Node.js、Python、JDK 等，不同项目要求不同，具体版本以你实际使用的项目为准；插件类工具通常需要在 IDE 插件市场安装并登录账号，Agent 类工具一般需要准备模型 API Key 或订阅凭据。
这里有一个容易被忽略的准备工作：模型的上下文窗口是有限的。AI 并不会自动知道你整个项目的全部细节，它只能读取你主动打开的文件、当前编辑区的上下文，以及项目中的规则文件。也就是说，AI 编程工具的效果，很大程度上取决于你“喂”给它什么。这正好引出下一个环节。
4. 规则先行：把项目约束提前告诉 AI
很多开发者抱怨“AI 生成的代码和我项目风格完全不一样”，根源通常不是模型能力差，而是你根本没告诉模型项目风格是什么。模型训练时见过各种代码风格，默认输出往往是最常见的中间风格。你的项目用了Lombok、自定义异常父类、统一返回体，AI 完全不知道。
解决这个问题，要靠规则文件。规则文件是放在仓库里的文本约定，AI 工具在回答时会自动读取并作为上下文约束。主流工具已经支持这类约定：仓库根目录的AGENTS.md、CLAUDE.md，Cursor 的.cursor/rules目录，以及其他项目级指令文件。落到实处，你在项目根目录建一个规则文件，把项目的事实和约束写清楚，就能显著提升 AI 输出的“贴合度”。
一个规则文件应该包含哪些内容？我建议覆盖六个维度：
- 技术栈与目录结构：项目用什么语言、框架、构建工具，关键代码放在哪些目录。
- 编码规范：命名习惯、是否使用
final、是否强制不可变对象、异常处理方式。 - 禁止事项：禁止引入额外依赖、禁止修改公共配置、禁止使用某类已废弃 API。
- 安全与性能约束：必须做输入校验、禁止拼接 SQL、注意资源释放。
- 测试要求：生成代码必须附带单元测试，测试要覆盖边界条件。
- 完成定义（Definition of Done）：一段代码满足什么条件才算完成，比如通过格式化、通过静态检查、已有测试覆盖。
我给你一个规则文件的示例，可以直接参考落地。注意，规则文件本身就是工程资产，需要加入版本控制，像代码一样被 review 和维护：
# AGENTS.md ## 项目概览 - 项目名：user-service - 语言：Java 17 - 框架：Spring Boot 3.x - 构建工具：Maven - 目录结构： - src/main/java/com/example/user 下按 controller、service、repository 分包 - 所有对外响应统一使用 Result<T> 包装 ## 编码规范 - 类名、方法名使用驼峰，常量使用大写加下划线 - Service 层接口必须有实现类，禁止直接用 Controller 操作 Repository - 所有入参必须使用 @Validated 校验，禁止在 Controller 中手写 if 判断格式 - 异常统一抛出 BizException，由全局异常处理器翻译成错误码 - 禁止在代码中打印完整堆栈，日志必须带 traceId ## 禁止事项 - 禁止新增第三方依赖，除非经过架构评审 - 禁止修改全局配置类 - 禁止在循环中调用远程服务 ## 安全与性能 - 所有对外接口必须做参数校验 - 禁止手动拼接 SQL，必须使用 MyBatis 参数绑定或 JPA - 涉及批量操作必须考虑分批执行 ## 测试要求 - 新增或修改业务代码时，必须补充单元测试，核心分支覆盖率不低于 80% - 测试禁止依赖真实数据库，使用 H2 或 Mock ## 完成定义 - 代码通过 mvn -q compile - 代码通过 mvn test - 代码通过 spotless 格式化 - 通过本地 Code Review，且 review 人对每个改动点都理解看到这里你可能已经理解：规则文件的价值不只是约束 AI，它其实是把团队里的隐性知识显性化。以前这些约定散落在老同事的 review 意见里，现在它们变成了机器可读的项目上下文。即便不使用 AI，规则文件对新人入职熟悉代码库同样有帮助。
5. 提示设计：让 AI 输出可审查的代码
有了规则文件，下一步就是写 Prompt。大多数开发者用 AI 编程时，提示往往停留在“帮我写个用户注册接口”的层度。这种一句话提示的问题在于：它没有告诉 AI 业务边界、验收标准、异常路径和接口约束，于是 AI 只能按自己脑补的“平均水平”生成代码。结果十次有八次需要返工。
有效的提示不是一个祈使句，而是一个结构化需求描述。我常用的是一个六段式公式：
角色 + 任务 + 背景 + 约束 + 输出格式 + 验收标准
- 角色：让 AI 站在合适的位置上，例如“你是一名熟悉 Spring Boot 的资深后端工程师”。
- 任务：用一句话描述要做什么。
- 背景：把和任务相关的项目事实放进来，比如用的框架、已有的工具类、统一返回结构。
- 约束：从规则文件里挑出本次任务必须遵守的条目。
- 输出格式：要求 AI 先给方案再给代码，或者按指定结构返回。
- 验收标准：明确什么算完成，避免 AI 给出半成品后停下。
下面是一段可以直接套用的 Prompt 模板：
你是一名资深后端工程师，正在维护 user-service 项目。 任务：实现一个用户注册接口。 业务背景： - 用户通过手机号和密码注册。 - 手机号必须是 11 位中国大陆手机号。 - 密码要求长度为 8 到 20 位，至少包含字母和数字。 - 手机号已存在时，返回业务错误码 PHONE_EXIST。 技术背景： - Spring Boot 3 + MyBatis。 - 对外统一返回 Result<T>。 - 异常使用 BizException 配合全局异常处理器。 - 入参校验使用 jakarta.validation 注解。 约束： - 不得新增依赖。 - Controller 不允许直接操作 Repository。 - Service 层必须处理业务逻辑。 - 密码必须使用 BCrypt 加密后入库。 输出格式： 1. 先用 5 条以内的要点给出实现方案，等待我确认。 2. 我确认后，再输出 Controller、Service、Service 实现、Repository、实体类完整代码。 3. 最后输出 3 个关键单元测试用例的名称和断言点，不用写完整测试代码。 验收标准： - 代码注释精简，只在关键业务点写注释。 - 所有类名、方法名符合项目规范。 - 不需要额外写 README。这段 Prompt 看起来很长，但它一次就把项目背景、安全约束和交付节奏说清楚了。实际使用中，你可以把重复的“技术背景”和“约束”部分抽成模板片段，作为自己常用指令库的一部分。每到一个项目，只改业务背景和任务描述就可以了。
还有一点很重要：让 AI 先给方案再写代码。如果你它直接输出完整代码，它会默认把方案和实现揉在一起，一旦方案不合适，返工成本很高。先确认方案，再让它生成代码，相当于在人与 AI 之间增加了一个“设计评审”环节。这是避免被 AI 牵着走的一个关键习惯。
6. 审查工作流：真编码的核心环节
如果说规则是约束，提示是输入，那么审查就是整个工作流的“安全闸门”。 AI 生成的代码即使完全符合提示要求，仍然可能出现三类问题：业务理解偏差、边界条件遗漏、安全缺陷。因此，审查不是走形式，而是真编码和氛围编码最本质的区别。
审查分两层。第一层是人审：开发者逐行阅读生成代码，对照需求确认逻辑。第二层是AI 辅助自审：把代码片段再喂给模型，让它找出潜在缺陷，这个过程可以快速抓住一些低级问题，但不能替代人审。最终合并权利必须由人掌握。
为了说明审查应该看什么，我构造一个典型的 AI 生成代码示例。假设 AI 在没有任何约束提示下写了如下用户注册代码：
// 文件路径：src/main/java/com/example/user/controller/UserController.java @RestController @RequestMapping("/user") public class UserController { @Autowired private UserService userService; @PostMapping("/register") public Result register(@RequestBody User user) { userService.register(user); return Result.success(); } }// 文件路径：src/main/java/com/example/user/service/UserServiceImpl.java @Service public class UserServiceImpl implements UserService { @Autowired private UserMapper userMapper; @Override public void register(User user) { if (userMapper.findByPhone(user.getPhone()) != null) { throw new RuntimeException("手机号已注册"); } String encryptedPassword = DigestUtils.md5Hex(user.getPassword()); user.setPassword(encryptedPassword); userMapper.insert(user); } }这段代码能跑吗？大概率能跑。但它至少有下面这些审查问题：
- 校验缺失：手机号格式、密码长度都没有校验，非法数据会直接落库。
- 异常使用不当：业务错误竟然抛
RuntimeException，最终反馈给用户的是 500 服务器错误，而不是可读的业务错误码。 - 加密算法错误：用户密码使用 MD5 加密，且没有加盐，这在现代系统中是明确的安全禁忌。
- 字段缺失：没有设置创建时间等通用字段，很多场景下会影响下游数据使用。
- 接口返回结构不清晰：Controller 返回
Result但没有指定泛型，代码交付后调用方很难对接。
对照规则文件，这些问题会更一目了然。下面的修改版本体现了一次完整的审查修正：
// 文件路径：src/main/java/com/example/user/service/UserServiceImpl.java @Service public class UserServiceImpl implements UserService { @Autowired private UserMapper userMapper; @Autowired private PasswordEncoder passwordEncoder; @Override @Transactional(rollbackFor = Exception.class) public void register(User user) { if (userMapper.findByPhone(user.getPhone()) != null) { throw new BizException(ErrorCode.PHONE_EXIST); } user.setPassword(passwordEncoder.encode(user.getPassword())); user.setCreatedAt(LocalDateTime.now()); userMapper.insert(user); } }审查修正后的代码，每一处改动都要能说出理由：校验和业务错误码配合，保证用户能收到明确提示；使用PasswordEncoder而非自己算哈希，保证密码加密算法符合安全基线；加@Transactional保证写库原子性；补充createdAt保证基础字段完整。
审查过程中，可以给自己准备一份简单的检查清单，逐项确认：
| 检查项 | 说明 |
|---|---|
| 输入校验 | 参数格式、长度、枚举值是否受限 |
| 错误处理 | 异常类型是否合理，是否暴露敏感信息 |
| 数据安全 | 密码、Token 等敏感数据是否采用安全算法 |
| 副作用 | 是否会造成重复插入、幂等问题 |
| 并发安全 | 是否存在跨线程共享可变状态 |
| 资源释放 | IO、数据库连接是否关闭，是否使用 try-with-resources |
| 可测试性 | 是否存在直接 new、静态方法导致无法 mock |
| 可读性 | 命名是否表意，注释是否解释“为什么”而非“是什么” |
在真实项目里，不建议一次性让 AI 生成几百行代码再开始审查，那样人的注意力很难覆盖全部路径。更合适的方式是小步生成、小步审查、小步提交：一段代码，审查通过后再进入下一段。
7. 完整工作流实例：从需求到合并
把上面的规则、提示、审查串起来，我给你一个从需求到合并的完整工作流示例。
场景：在 Spring Boot 项目中增加“用户注册”接口。假定你只是普通开发者，不是架构师，但你需要对这个功能负责到上线。
第一步，确认规则文件。打开项目根目录的AGENTS.md，确认它包含 Spring Boot 技术栈、返回结构Result<T>、必须使用BizException、密码加安全哈希等约束。如果没有，先补上。
第二步，写结构化 Prompt。使用第 5 节的模板，把业务背景改成“手机号 + 密码注册”，约束改成“必须使用 BCrypt 加密”。先让 AI 输出方案，确认后继续。
第三步，生成代码。请 AI 输出 Controller、Service、Service 实现、Repository 和实体类完整代码。当前主流模型通常可以分文件输出，得到代码后放入对应目录。
第四步，审查与修正。对照第 6 节清单，逐项检查。尤其关注：手机号校验是否使用注解完成、重复注册有没有返回业务错误码、密码加密是否使用PasswordEncoder、事务是否正确、返回结构是否携带泛型。发现问题后，直接手动修改，不理解时再让 AI 解释，而不是让它无脑重写。
第五步，本地验证。执行编译和测试：
mvn -q compile mvn test如果项目配有静态检查或格式化插件，也需要一并运行：
mvn spotless:check mvn spotless:apply验证通过后，再用真实接口做一次冒烟测试。这里给出一个最简单的 curl 示例：
# 正常注册 curl -X POST http://localhost:8080/user/register \ -H "Content-Type: application/json" \ -d '{"phone":"13800138000","password":"pass1234"}' # 重复注册，预期返回业务错误码 PHONE_EXIST curl -X POST http://localhost:8080/user/register \ -H "Content-Type: application/json" \ -d '{"phone":"13800138000","password":"pass1234"}'第六步，提交合并请求。提交信息要写清“新增用户注册接口，包含手机号校验与密码 BCrypt 加密”。不要把 AI 生成的无关文件一起提交。
第七步，让同事或至少一个其他人帮忙 review。AI 编程项目中，第二个人的眼睛非常重要，因为你自己可能已经被 AI 的服务态度带偏了。Review 关注点至少包括：这次改动是否局限于需求范围、是否引入安全风险、测试是否覆盖了关键分支。
这套工作流跑一圈，你应该强烈感受到：真正花时间的不是让 AI 生成代码，而是和 AI 生成的代码互相磨合。但正因为你在磨合期投入了注意力，后续维护阶段的坑才会少很多。
8. 常见问题与排查思路
任何人进入 AI 编程工作流都会遇到一些问题，下面是几个高频问题及排查思路：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| AI 生成的代码和项目风格不一致 | 没有规则文件或规则文件未生效 | 确认规则文件是否在项目根目录，并检查 AI 工具的规则读取说明 | 建立AGENTS.md等项目级规则文件，并提示 AI 在每轮回复前先读取 |
| 代码能跑，但业务逻辑明显不对 | 提示中缺少业务背景和约束 | 检查 Prompt 是否只写了一句话需求 | 使用结构化 Prompt，先出方案后出代码，明确异常路径和完成定义 |
| 连续对话后越改越乱 | 上下文窗口被污染，早期错误被带到后面 | 查看当前会话是否太长，上下文是否包含无关文件 | 开新会话，把必要的背景沉淀到规则文件中，从新会话重新开始 |
| AI 修改了与需求无关的代码 | 工具默认按全局语义分析，扩大了改动范围 | 查看 diff 中是否有无关文件 | 在 Prompt 中明确“只修改指定文件”，并启用工具的项目文件白名单能力 |
| AI 生成的代码存在安全漏洞 | 模型缺少安全上下文，默认补全偏好 | 使用安全审查清单逐项排查，使用静态扫描工具 | 在规则文件中写入安全禁止项，要求 AI 列出每个安全决策 |
| 单元测试覆盖很浅，全是主路径 | Prompt 没有强调边界测试 | 检查测试代码的断言覆盖 | 在提示中明确要求“覆盖异常路径和边界输入”，人工补充关键测试用例 |
这六个问题基本覆盖了大部分开发者转向 AI 编程时的主要挫败点。你会发现，它们的根因都不是模型能力不行，而是工作流缺失。规则文件补上项目约束，结构化 Prompt 补上需求约束，审查清单补上人的注意力，问题就自然消解了。
9. 最佳实践与工程建议
工作流搭起来之后，再给你一些让它在团队和长期项目中真正持续有效的建议。
第一，把 AI 编程工具当成结对程序员，而不是自动代码生成器。好的结对程序员会先问需求，再给建议，最后等待确认，而不是把所有代码一次写完。实际使用 AI 时，先让它讨论方案、提问边界条件、指出潜在风险，再让它动手。这个顺序会明显提高代码质量。
第二，个人开发者也要走版本管理。即使你一个人开发，也应该为 AI 生成的代码建立明确的提交记录。提交的信息可以标记 [AI 生成]，后续如果出问题，能快速定位哪些代码是在什么提示下生成的。这不是为了甩锅，而是为了让问题可追踪。
第三，代码审查一定要看完整 Diff。有些开发者图省事，让 AI 直接“把改动应用到文件”后不去看 Diff。这是最危险的操作。任何 AI 工具的改动都只是一份建议，真正决定代码能不能进入主干的，只有你合上 Diff 后的判断。建议在 IDE 里养成每次改动都先git diff的习惯。
第四，让规则文件和提示模板成为团队资产。把AGENTS.md放在仓库根目录，把 Prompt 模板放在团队 Wiki 或文档库里，新人加入时统一学习。AI 编程协作的效率，本质上取决于团队有多少共识被写成了机器可读的文本。没有写下来的约定，再好的工具也帮不了你。
第五，不要盲目追求生成速度，要追求返工率。评估 AI 编程效果时，不只是看生成多少行代码，还要看“生成后被丢弃、重写、线上修复的比例”。如果你的 AI 代码经常被返工，问题可能出在上下文准备不足，而不是模型需要换。在换工具之前，先优化 Prompt 和规则。
第六，定期做一次“无 AI 重构”练习。我会建议你每隔一段时间，手动重构一段之前由 AI 生成的代码，重新编写一遍核心逻辑。这个过程不是浪费时间，而是保持“真编码”手感最直接的训练方式。 AI 编程最大的隐性风险是长期不写代码导致代码手感钝化，定期手写代码能抵御这种钝化。
安全方面有一个原则：AI 生成的代码不应默认拥有权限提升、外部网络调用、文件系统写操作的合法资格。凡是涉及生产环境改动、数据操作、密钥读取的代码，必须由人逐行确认，并遵循最小权限原则。在测试环境中先验证、备份可回滚方案，永远是合理的底线。
10. 总结与后续学习方向
回到最初的问题：如何告别被 AI 牵着走？答案是建立你自己的工作流，而不是依赖工具的默认行为。规则文件解决“AI 不知道项目约束”的问题，结构化提示解决“需求表达过于模糊”的问题，审查清单解决“人没有认真看代码”的问题。这三步合起来，就是一套不依赖具体工具的 AI 编程方法论。
下一步你可以从两个方向继续深入。一是把 AI 引入代码审查环节：让 AI 对每次提交的 Diff 做一次潜在缺陷扫描，再由人确认，形成“AI 预审 + 人审”的完整链路。二是探索 Agent 模式下的多文件重构：现在的工具已经能跨多个文件修改、运行测试、根据报错迭代，但你要为这类操作设计更严格的验证门槛，比如自动构建、自动测试、代码覆盖率门禁。
最后留给你一条可以执行的建议：找一个最近维护的老项目，先写一个最小AGENTS.md文件，然后用结构化 Prompt 让 AI 增加一个小小的接口，再按审查清单走一遍。你会发现，真正让你感到踏实的，不是 AI 生成代码的速度，而是你能看懂它在做什么、能指出它哪里不对、能亲手把它修正到你满意的状态。这才是 AI 时代“真编码”的意义。
