# 《检视AI生成代码》

- Published: 2025-08-29
- Category: AI专题
- Canonical: https://liwenye.cn/%E3%80%8A%E6%A3%80%E8%A7%86AI%E7%94%9F%E6%88%90%E4%BB%A3%E7%A0%81%E3%80%8B/

> 这是公开文章的机器可读副本。引用时请链接上面的 canonical 页面。

---

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

**副标题：为AI生成代码负全责的35条最佳实践**

1983年，美国航空航天局的火星气候探测器在即将进入火星轨道时突然失联。事后调查发现，一个承包商使用英制单位编写了推进器控制软件，而NASA的系统期望的是公制单位。这个价值1.25亿美元的教训告诉我们：代码能运行，不代表它是正确的。

今天，当我们使用Cursor、ChatGPT等AI工具生成代码时，面临着类似的挑战。AI生成的代码往往语法正确、结构工整，但它是否真正理解了我们的业务需求？是否遵循了项目的安全规范？是否覆盖了所有边界情况？

本文整理了35条具体可执行的最佳实践，涵盖开发全过程——从提示编写、代码理解与验证，到调试、测试、重构、部署与维护，特别针对Java Web开发及Web3支付场景。通过这些实践，开发者可以在AI生成方案和代码后真正理解其逻辑，并能够独立评估、验证、调试、改造代码。

---

# 第一部分：清晰输入——掌握问题，控制AI输出方向

## 第1条：明确需求，提供完整上下文

> **核心原则**：在向AI请求代码或方案时，描述越清晰、上下文越完整，AI生成的代码就越可控、越高质量。

1969年阿波罗11号登月时，NASA的任务控制中心有一条铁律：每一条指令都必须包含完整的上下文信息，因为地月通信有3秒延迟，任何误解都可能致命。与AI对话也是如此——AI并不在你的项目现场，它看不到你的数据库表结构，不知道你的团队规范，更不了解支付链路中的安全约束。

AI生成代码的本质是“基于上下文的概率预测”。如果你的提示模糊、缺少背景，AI会自行“脑补”：生成不存在的API、假设你使用了某个你根本没用的框架、忽略关键的安全校验。在支付场景里，这些错误不仅导致bug，还可能直接造成资金风险。

**最佳实践**：
- 在Prompt中提供：业务背景 + 技术上下文 + 输出要求
- 提供现有代码、DTO、数据库表结构作为“范例”
- 明确性能、安全、日志等硬性约束
- 使用`@文件名`引用项目中的代码文件

**一句话记忆**：“不要让AI猜你的需求，要让它知道你的世界。”

---

## 第2条：指定角色和风格，控制AI输出一致性

> **核心原则**：通过在Prompt中明确指定AI的“角色”和“代码风格”，可以大幅提高生成代码的专业性、一致性和可维护性。

如果你雇佣一位新员工，你会给他一份员工手册，告诉他公司的规范和期望。与AI协作也是如此。没有角色设定时，AI倾向生成“最常见”的通用写法，而非你业务所需的专业实现。

不同角色会带来不同的输出倾向：
- “资深Java后端工程师”：更重视事务边界、异常语义与分层设计
- “Web3支付专家”：更关注签名算法、重放防护、回调验签、幂等性与合规
- “代码审查员”：偏向安全与质量清单式检查
- “系统架构师”：更擅长抽象API边界、模块依赖与数据流

**可复用的Prompt模板**：

```
你是一名资深Java后端工程师，熟悉Web3支付、Spring Boot、MyBatis和JJWT。
请严格遵循以下代码规范：
1. 控制器返回统一DTO（与项目现有结构一致）
2. 业务日志使用AuditLogService
3. 异常由GlobalExceptionHandler统一处理
4. Mapper层使用XML，不使用注解SQL
```

**一句话记忆**：“指定角色→输出更专业；约定风格→输出更一致。”

---

## 第3条：拆解任务，分步交付

> **核心原则**：将复杂需求拆解为可控的小任务，让AI在每个步骤专注于单一目标，从而提升输出的准确性和可维护性。

认知心理学家乔治·米勒发现，人类的工作记忆一次只能处理7±2个信息块。AI也有类似的“注意力窗口”——当上下文过长、目标过多时，它会“遗忘”早先的关键信息，导致输出混乱。

在Java + Web3支付开发中，如果一次让AI写太多内容，模型会填补大量“假设”，导致幻觉API、错误设计或忽略边界条件。更好的做法是将复杂需求拆分为多个小步骤：先让AI生成DAO接口，再生成Service实现，最后编写Controller，而非一口气要求“生成整个模块的所有代码”。

**建议的分步思路（以Web3支付接口为例）**：
1. 先生成DTO与请求模型：确保参数命名、类型一致
2. 实现核心加密逻辑：单独让AI生成签名与验签方法
3. 写控制器层：调用Service逻辑并封装返回DTO
4. 写Service层：业务逻辑串联，包括调用KYB、更新数据库、写日志
5. 最后写集成测试：验证整个接口能跑通

**一句话记忆**：“小任务→小上下文→小风险→大可控。”

---

## 第4条：喂给AI示例，让输出对齐风格

> **核心原则**：在Prompt中提供现有项目的示例代码，帮助AI学习并模仿现有风格，从而提升输出的一致性与可维护性。

1906年，巴甫洛夫通过条件反射实验发现，给狗提供正确的“刺激”，就能得到预期的“反应”。与AI协作也遵循类似逻辑——给它正确的示例，它就能模仿出符合你期望的代码。

如果不给AI现有示例，它会按照训练数据中最常见的模式生成代码，这往往与你项目的命名规范、日志格式、异常处理方式不一致。通过提供DTO、Mapper、日志工具类等示例，AI可以“对齐”到你的项目风格，生成的代码能更快落地。

**示例的类型**：
- DTO与返回结构：统一命名与字段结构
- 异常处理：提供`GlobalExceptionHandler`示例
- 日志格式：给出`AuditLogService`调用方式
- 数据库映射：贴现有MyBatis XML，确保SQL风格一致

**一句话记忆**：“给例子→模仿→风格统一→少返工。”

---

## 第5条：利用Cursor Rules统一AI输出规范

> **核心原则**：通过项目级别的Cursor Rules文件，让AI在每次生成代码时自动遵循团队规范，无需在每次对话中重复说明。

如果每次与AI对话都要重复一遍项目规范，效率会大打折扣。Cursor提供了`.cursor/rules/`目录，你可以在其中创建规则文件，将编码规范、架构模式、领域约定固化下来。这些规则会在每次AI生成代码时自动应用，就像一位时刻在旁提醒的导师。

**适合写入Rules的内容**：
- 架构约定：“Controller只调用Service，不直接访问Repository”
- 命名规范：“Repository接口命名以Repository结尾”
- 安全要求：“所有数据库查询必须使用参数绑定，禁止字符串拼接SQL”
- 日志规范：“敏感字段必须脱敏后才能记录日志”

对于Web3支付项目，可以预设：
```markdown
## 安全规范
- 签名算法必须使用官方SDK
- 回调必须验证签名和时间戳
- 私钥禁止出现在日志中

## 代码规范
- 异常统一使用GlobalExceptionHandler处理
- 所有Controller必须有权限注解
```

将规则文件纳入版本控制，确保所有成员的Cursor都应用相同规则，生成的代码风格就能保持一致。

**一句话记忆**：“规则写一次，团队受益永久。”

---

## 第6条：了解AI的边界，把AI当草稿机

> **核心原则**：AI擅长生成初稿与提供参考，但它并不具备完整的上下文理解与推理能力。将AI的输出视为“可修改的草稿”，而不是“最终答案”，是负责任开发的关键。

2016年，AlphaGo战胜围棋世界冠军李世石时，解说员们惊叹于它的“创造力”。但事后分析表明，AlphaGo并不“理解”围棋——它只是在海量棋谱中学会了模式匹配。今天的代码生成AI也是如此：它能产出看似合理的代码，但不理解你的业务逻辑、安全约束和性能要求。

AI的局限性体现在：
- **不理解代码**：它是基于统计的语言预测器，不具备对业务逻辑的真实理解
- **缺乏项目上下文**：不知道你项目中的特殊规则、内部API和安全约束
- **知识存在滞后性**：训练数据有截止日期，新版框架和SDK可能不熟悉
- **可能生成“幻觉”**：当Prompt不完整时，会编造不存在的API或字段

**AI更适合的任务**：
- 生成初稿：快速搭建DTO、Controller、测试用例等样板代码
- 重构建议：优化可读性、简化逻辑
- 代码讲解：让AI解释复杂逻辑，辅助理解

**需要谨慎的任务**：
- 安全相关实现：如签名算法、权限控制、加密
- 合规逻辑：KYB/KYC、支付审计、回调验证
- 高并发性能优化：AI的建议未必适合你的生产场景

**一句话记忆**：“把AI当草稿机，而不是终稿机；生成交给AI，验证必须靠自己。”

---

# 第二部分：方案设计——先对齐思路，再落地实现

## 第7条：先与AI讨论方案，再让它写实现

> **核心原则**：在让AI写代码之前，先与它讨论设计方案、技术选型和实现思路，确保方向正确，再让AI生成具体实现。

建筑师不会拿起砖头就开始砌墙。他们先画图纸、讨论结构、确认需求，然后才开始施工。软件开发也应如此。

如果直接让AI生成完整实现，它可能默认采用最通用的模式，导致与项目架构或安全要求冲突。更好的做法是采用“两阶段Prompt策略”：

**阶段1：方案讨论**
- 目标：设计系统流程、模块边界、核心接口、异常机制
- 输入：项目上下文、技术栈、日志规范、DTO示例
- 输出：清晰的分层设计和数据流图

**阶段2：实现生成**
- 目标：让AI按方案写实现
- 输入：确认过的方案、接口签名、字段定义、依赖
- 输出：可直接跑通的、符合规范的实现代码

在Cursor中，可以使用**Plan模式**进行方案讨论，确定方案后再切换到**Agent模式**执行具体实现。这种分离让你在关键决策上保持控制权。

**一句话记忆**：“先讨论，再实现；先对齐，再落地。”

---

## 第8条：区分Agent模式与对话模式的使用场景

> **核心原则**：Cursor提供多种交互模式，不同模式适合不同任务。正确选择模式可以提高效率并降低风险。

2010年，心理学家丹尼尔·卡尼曼在《思考，快与慢》中区分了两种思维模式：系统1（快速直觉）和系统2（慢速推理）。与AI的交互也有类似的“快慢”之分。

Cursor提供了几种主要的交互模式：
- **Chat模式**（Cmd+L）：适合开放式讨论，让AI解释代码、规划架构、回答问题，其回复不会自动应用到代码
- **Agent模式**：AI会自主规划并执行多步操作，适合具体的编码任务
- **Plan模式**：只读模式，专门用于设计和讨论，AI不会修改任何文件

在Web3支付开发中的建议：
- 用**Chat模式**讨论签名算法选型、安全策略、架构设计
- 用**Plan模式**让AI帮你梳理复杂功能的实现步骤
- 确认方案后，切换到**Agent模式**让AI执行具体实现
- Agent模式下要更频繁检查生成结果，因为AI会连续执行多步操作

**一句话记忆**：“讨论用Chat，规划用Plan，执行用Agent。”

---

## 第9条：利用Memories保持跨会话的项目上下文

> **核心原则**：使用Cursor的Memories功能保存重要的项目约定，让AI在后续对话中自动应用这些知识。

人类大脑有短期记忆和长期记忆之分。AI对话默认只有“短期记忆”——每次新对话都从零开始。但Cursor的Memories功能可以帮助AI建立“长期记忆”。

当你在Chat模式中与AI反复讨论某项约定时，Cursor可能会提示提取为Memory。经你确认，这些内容会保存为项目范围的规则，下次开启新对话也能自动应用。你也可以明确要求“请记住XX”，让Cursor主动将其记录。

例如，你曾与AI约定“我们项目使用DDD分层架构，所有数据库操作都通过Repository完成，不在Service编写SQL”。如果将此作为Memory保存，那么以后无论谁请求数据库相关代码，AI都会遵循这一约定。

**使用建议**：
- 谨慎添加记忆——不要把随意的对话内容存为记忆
- 确保记忆条目简洁明确
- 定期Review它们是否仍适用当前项目

**一句话记忆**：“项目约定存Memory，跨会话上下文不丢失。”

---

# 第三部分：审慎验证——让AI产出可被信任

## 第10条：拿到代码先读懂，逐行检查逻辑

> **核心原则**：AI生成的代码不是最终答案。无论代码多么完整、格式多么工整，在使用前必须逐行阅读、理解逻辑，确保它符合你的业务需求和安全要求。

1986年，挑战者号航天飞机在发射后73秒爆炸，造成7名宇航员遇难。事后调查发现，工程师们曾警告低温下O型环可能失效，但管理层忽视了这一警告。这个悲剧提醒我们：对关键系统的任何环节都不能盲目信任。

AI生成的代码可能“看似正确”但逻辑错误。它不会验证业务正确性，不知道你项目的特定约束，在Web3支付场景中，一旦实现不当，可能直接导致资金或数据风险。

**审查代码的四个重点**：
1. **业务正确性**：是否按需求实现了正确的流程
2. **安全性**：是否存在未验证参数、签名漏洞或数据泄露
3. **性能**：是否有低效循环、重复计算或潜在阻塞
4. **一致性**：是否符合团队命名规范、日志规范和异常处理标准

**一句话记忆**：“AI写得快，但责任在你；逐行读懂，掌握主动权。”

---

## 第11条：让AI解释难点，辅助自己掌握

> **核心原则**：当遇到不理解的代码或复杂算法时，让AI充当“代码讲解员”，用自然语言帮你拆解逻辑，但最终理解仍需你自己验证。

费曼学习法的核心是“如果你不能用简单的语言解释一件事，你就没有真正理解它”。AI可以帮你迈出这一步——把复杂的代码转化为易懂的解释。

在Java + Web3支付开发中，业务场景常常涉及签名算法、加密验签、回调处理、异步事务等。如果完全依赖AI生成代码而不理解内部逻辑，一旦出现问题就很难排查。

**常用提问模板**：
- “请逐行解释这段Java代码的逻辑，并指出可能的问题”
- “帮我分析这段签名算法的安全性”
- “这段Controller的异常处理是否符合最佳实践？”
- “这个Web3回调接口的流程是否安全？哪里可能需要验签？”

**提升理解的技巧**：
- 多角度提问：让AI分别用“初学者模式”和“专家模式”解释逻辑
- 结合代码注释：让AI直接生成内嵌注释
- 做小实验验证：根据AI解释，写最小化单元测试验证正确性

**一句话记忆**：“用AI讲解逻辑，用自己验证结论。”

---

## 第12条：手动推演业务流程，确保逻辑闭环

> **核心原则**：无论AI生成的代码多么完善，都需要你手动推演完整的业务流程，验证逻辑是否覆盖所有关键场景。

象棋大师在下棋时，不只看眼前这一步，而是在脑中推演接下来的多步变化。审查AI代码也应如此——不只看单个函数是否正确，而要推演整个业务流程。

AI通常只实现“主干路径”，而很容易忽略异常分支，比如支付失败、签名验证失败、KYB拒绝等。如果某个分支没有收敛到可控状态，比如异常没有回滚、回调未处理幂等性，可能导致数据不一致或资金损失。

**Web3支付场景的推演要点**：
1. 支付链路：创建交易→签名→广播→区块确认
2. 回调验签：是否在回调中校验签名、防止伪造
3. 幂等性处理：相同交易的重复回调是否安全
4. 异常分支：余额不足、签名失败、区块回滚、第三方接口超时
5. 安全边界：是否有重放攻击、API权限控制、私钥泄露风险

**一句话记忆**：“能跑通不等于没问题，手动推演才能掌控全局。”

---

## 第13条：把AI当审查员，进行二次Review

> **核心原则**：不要只让AI生成代码，也要让AI充当“代码审查员”，对生成结果进行多维度的二次检查。

1995年，IBM的深蓝与国际象棋大师卡斯帕罗夫对弈时，开发团队发现了一个有趣的现象：让两个不同版本的程序互相对弈，能发现单个程序无法暴露的漏洞。这就是“对手思维”的价值。

让AI扮演两种不同角色——开发者和审查员——可以换视角发现问题。在生成代码后，用新的Prompt让AI切换到“代码审查员”模式，它会用不同的角度分析实现。

**双轮AI审查策略**：
1. **第一轮：功能正确性**
   - 检查是否实现了需求
   - 确保逻辑完整
   - 验证数据流与接口约定一致
2. **第二轮：安全与性能**
   - 检查签名、私钥、回调逻辑
   - 查找潜在的高耗时查询
   - 确认幂等性、事务一致性

**常用审查Prompt**：
- “请检查这段代码是否符合我们现有的异常处理规范。”
- “帮我找出下面代码中的潜在安全隐患，尤其是Web3验签逻辑。”
- “请检查这段Mapper是否存在N+1问题或性能瓶颈。”

**一句话记忆**：“第一次生成，第二次审查；双轮交互，降低风险。”

---

## 第14条：拆解大段代码，逐模块验证

> **核心原则**：当AI一次性生成“大块实现”时，先把代码按职责切分为若干小模块，分别校验与落盘，通过“小步可控”的方式获得对整体逻辑的真正掌控。

乐高积木的魅力在于：每一块积木都很简单，但组合起来可以构建复杂的作品。软件架构也应如此——把大块代码拆成职责单一的小模块。

在Java + Web3支付场景里，AI常会一次生成包含控制器、业务逻辑、签名验签、数据库访问、回调处理在内的“巨型代码块”。直接使用风险极高：难以阅读、难以定位问题、缺少清晰边界。

**建议的拆分维度**：
- 表层交互：Controller（鉴权、请求校验、DTO编解码、统一返回）
- 领域服务：Service（业务编排、事务边界、错误语义）
- 资源访问：Repository/Mapper（仅做数据读写）
- 加密与验签：CryptoService（私钥管理、签名算法、防重放）
- 回调与幂等：CallbackHandler（验签、去重、重试、补偿）
- DTO/Assembler：对象转换、字段校验

**一句话记忆**：“先切块，再验证；先定边界，再谈优化。”

---

## 第15条：对照官方文档和SDK，防止AI“幻觉”

> **核心原则**：AI生成的代码并不保证正确性。在涉及第三方API、SDK、框架方法时，必须对照官方文档进行验证。

1999年，当年的互联网新贵们相信“如果网上找不到，就不存在”。但今天我们知道，网上的信息未必准确——AI也是如此。它可能凭借统计规律“编造”方法、类、字段，尤其是在Web3 SDK或支付网关的API中。

**Web3支付中常见的AI“幻觉”场景**：
- 签名与验签方法名错误：AI常生成`signTransaction()`或`verifySignature()`等方法，但不同Web3 SDK的签名API完全不同
- 交易回调字段缺失：某些支付回调返回`status`和`txHash`，AI可能假设存在`isPaid`字段
- Spring Boot注解失效：AI可能生成旧版本的配置方式

**高效交叉验证的技巧**：
- 在Cursor中，让AI直接生成所需API的官方文档链接
- 让AI帮你总结官方文档的关键字段和约束条件
- 如果API复杂，让AI生成最小可运行Demo来测试验证
- 对于Web3支付SDK，直接下载源码，用IDE定位核心方法

**一句话记忆**：“AI能写，但文档能证；先查官方，再信AI。”

---

## 第16条：利用AI自动审查PR，建立持续防御

> **核心原则**：将AI代码审查集成到开发流程中，通过Bugbot等工具自动分析PR，在代码合并前发现潜在问题。

2009年，Netflix开创了“混沌工程”——故意在生产环境中注入故障，以发现系统弱点。AI代码审查是类似的理念：主动寻找问题，而不是等问题暴露。

Cursor的Bugbot可以自动分析代码差异，指出其中的bug、潜在安全问题和代码风格问题，并直接在PR上留下评论。它不仅检查语法错误，还关注安全和质量方面，例如未处理的异常、资源泄漏等。

**配置方法**：
1. 创建`.cursor/BUGBOT.md`文件
2. 写入项目特有的检查规则，例如：
   - “确保所有数据库查询使用参数化”
   - “回调处理必须包含签名验证”
   - “禁止在日志中打印私钥或签名原文”

对于个人开发者，也可以在重要改动时主动让AI过一遍：将代码变更贴给Chat，请它以审查员身份挑错。

**一句话记忆**：“AI审查自动化，问题发现在上线前。”

---

# 第四部分：调试排查——用科学方法定位问题

## 第17条：构造最小可重现场景

> **核心原则**：当AI生成的代码出现异常时，第一步不是盲目调试，而是先构造“最小可重现场景”，用最少的代码重现问题。

爱因斯坦曾说：“一切应该尽可能简单，但不能过于简单。”调试也是如此。在复杂的支付链路中直接调试，日志量大、调用链长，很容易被无关信息掩盖。

**构造最小可重现场景的三步法**：
1. **抽离核心逻辑**：从大模块中剥离关键代码，比如验签、交易提交、回调解析
2. **创建最小输入**：只保留最少的字段、最短的交易数据
3. **运行与验证**：在本地或沙箱中运行，确保问题稳定复现

**Web3支付场景示例**：
- 问题：交易回调偶尔验签失败
- 最小可重现场景：
  - 独立提取签名算法与验签逻辑
  - 固定输入回调数据包与签名
  - 本地运行对比AI生成的验签逻辑与官方SDK方法

**一句话记忆**：“先缩小，再排查；小场景，大洞察。”

---

## 第18条：用IDE断点调试，掌握真实运行逻辑

> **核心原则**：AI生成的代码看起来正确并不代表它实际能正确运行。通过在IDE中使用断点调试，跟踪真实的变量状态和方法调用链，才能彻底掌握代码的行为。

纸上得来终觉浅，绝知此事要躬行。阅读代码是一回事，看它实际运行是另一回事。即使AI生成的代码在语法层面正确，实际执行时也可能因为上下文、依赖、SDK版本等导致不同的结果。

**Web3支付中的断点调试场景**：
- 交易签名：断点验证私钥生成签名是否与SDK一致
- 回调验签：断点观察回调Payload、签名字段、nonce
- 幂等控制：调试重复回调时的行为
- 多线程并发：跟踪异步回调、事件监听和并发事务

**在Cursor和IDEA中的结合**：
- Cursor：让AI帮忙定位可疑逻辑，标出建议断点位置
- IDEA：配合断点查看调用栈、变量值、网络请求
- 双向反馈：将断点观察到的异常状态反馈给AI，获得优化建议

**一句话记忆**：“用AI生成，用断点求证；真实状态，尽在掌控。”

---

## 第19条：批量插入日志，跟踪数据流

> **核心原则**：在AI生成的代码中，通过批量插入高价值日志，构建可追踪的数据流视图，帮助你快速定位问题。

飞机的黑匣子记录了飞行中的每一个关键数据点，当事故发生时，这些记录就是还原真相的唯一依据。在软件系统中，日志扮演着类似的角色。

AI生成的代码逻辑可能看似正确，但数据在方法、线程、异步回调之间传递时，状态可能早已被篡改或丢失。日志是定位数据错乱、签名失败、交易丢失等问题的唯一全局手段。

**Web3支付场景的日志重点**：
1. 交易创建：记录请求参数、交易Hash、预期Gas
2. 签名计算：只记录算法版本与结果摘要，避免暴露私钥
3. 回调处理：记录回调Payload、验签结果、幂等锁状态
4. 异常分支：交易失败、签名不匹配、接口超时要有明确的错误码

**日志策略的进阶优化**：
- TraceID/RequestID：给每个交易打上唯一ID，支持跨模块追踪
- 统一日志规范：固定日志字段，如`[traceId] [merchantId] [txHash] [status]`
- 敏感信息脱敏：私钥、签名原文必须脱敏后才能记录

**一句话记忆**：“日志是运行时的证据；好日志，让问题无处隐藏。”

---

## 第20条：用假设验证法缩小问题范围

> **核心原则**：当AI生成的代码报错时，不要盲目大范围调试，而是先提出具体假设，再逐步验证，通过“缩小问题空间”快速定位根因。

1905年，爱因斯坦在研究光电效应时，并没有漫无目的地做实验。他先提出假设——光具有粒子性——然后设计实验验证。科学方法的核心就是“假设-验证”循环。

在复杂支付链路中，全量排查等于“大海捞针”。没有假设直接改代码，很容易在无关模块反复消耗时间。

**Web3支付的假设验证示例**：
- 问题：交易回调验签失败
- 可能假设：
  1. 签名算法不一致：AI生成的签名方法与SDK不兼容
  2. 回调Payload缺字段：回调数据少了`nonce`或`timestamp`
  3. 测试网私钥错误：签名私钥与发起交易的账户不一致
- 验证策略：
  - 单独提取签名方法，对比AI代码与官方SDK结果
  - 打印完整回调Payload，确认字段是否缺失
  - 固定私钥重新签名，验证计算结果

**一句话记忆**：“不猜测，不乱试；先假设，再验证。”

---

## 第21条：结合单元测试与AI生成用例，锁定问题边界

> **核心原则**：通过结合手写关键单元测试与AI自动生成测试用例，构建足够覆盖的验证体系，确保AI生成代码的行为符合预期。

1996年，阿丽亚娜5号火箭在发射37秒后爆炸。原因是一段从阿丽亚娜4号复用的代码——它在新火箭更快的飞行速度下产生了整数溢出。这段代码从未被充分测试。

AI生成的逻辑往往涉及签名、验签、回调、数据库更新等多模块交互。单靠阅读或断点调试很难覆盖所有场景，而结合单元测试与AI生成测试用例，可以系统性验证每条路径的正确性。

**Web3支付场景下的测试重点**：
1. 签名与验签：验证生成的签名与官方SDK一致
2. 回调处理：模拟回调Payload、时间戳、nonce，确保幂等性正确
3. 交易状态更新：测试成功与失败的事务一致性
4. 安全性断言：验证日志中是否脱敏敏感字段

**在AI中生成测试用例**：
```
根据以下签名算法代码，生成JUnit单元测试，覆盖正常、签名失败和异常Payload三种情况。
```

**一句话记忆**：“AI写实现，测试定边界；用例越全，Bug越少。”

---

## 第22条：让AI分析日志与调用栈，加速故障定位

> **核心原则**：当遇到复杂错误日志或长调用栈时，让AI帮忙解析日志结构、提取关键信息、缩小问题范围。

福尔摩斯之所以能破案，不是因为他看到了别人看不到的线索，而是因为他能从海量信息中筛选出关键证据。AI可以扮演类似的角色——从长长的日志中帮你找到问题根源。

当错误日志成百上千行时，让AI帮你提取关键异常与上下文，避免逐行手工分析。AI能从调用栈中梳理出最重要的触发路径，快速锁定问题模块。

**AI辅助日志分析的常用Prompt**：
- “这是交易回调失败的日志，请提取导致验签失败的原因。”
- “帮我从这段日志中找到第一个抛出异常的方法和模块。”
- “请分析这段调用栈，按执行顺序列出关键方法。”

**提高日志分析效率的技巧**：
- 当日志过长时，先让AI总结日志结构，再深入分析关键段落
- 将日志关键字段（traceId、txHash、merchantId）放入Prompt，帮助AI精准分析
- 不要直接把数千行日志一次性喂给AI，分段处理效果更好

**一句话记忆**：“AI扫雷找关键，你验证定根因。”

---

## 第23条：利用AI辅助生成调试脚本，快速验证假设

> **核心原则**：当AI生成的代码存在Bug或不确定性时，让AI帮忙生成最小化的调试脚本，通过快速复现场景、验证假设和定位问题。

科学实验的精髓在于“可重复性”——如果一个现象无法被重复观察，就无法被研究。调试脚本就是帮你创造可重复的实验环境。

传统调试依赖全链路环境，效率低且易被噪音干扰。让AI帮你生成最小可运行调试脚本，可以更高效地验证单点问题。

**AI生成调试脚本的Prompt示例**：
- “请基于以下签名逻辑，生成一个最小可运行的Java调试脚本，打印签名计算结果并与官方SDK比对。”
- “根据下面的回调处理代码，生成本地调试脚本，固定回调Payload和签名。”
- “请帮我写一个Mock Web3节点的调试脚本，用于本地重现回调异常场景。”

**提升验证效率的技巧**：
- 逐步扩展：先验证核心算法，再扩展到完整业务链路
- 结合AI分析：把脚本运行日志交给AI，让它帮忙解析中间值与异常原因
- 自动生成更多场景：让AI基于脚本生成多组不同输入的验证用例

**一句话记忆**：“调试靠最小化，验证靠自动化。”

---

## 第24条：在沙箱环境模拟全链路，确保上线安全

> **核心原则**：在上线前，利用沙箱环境完整模拟支付全链路，提前发现潜在问题，避免在生产环境中暴露风险。

航空业有一条铁律：任何新机型在载客飞行前，必须经过成千上万小时的模拟和测试飞行。软件上线也应如此——尤其是涉及资金的支付系统。

AI生成的代码即使局部可运行，也不能直接推到生产环境。通过在沙箱中模拟全链路，可以暴露缺陷、验证安全策略、确认外部依赖是否正常。

**Web3支付沙箱测试策略**：
1. 签名与广播：生成Mock私钥与交易Payload，验证签名与SDK一致性
2. 回调验签：模拟回调请求，测试验签逻辑与防重放机制
3. 异常路径验证：交易失败、回调超时、区块回滚等场景必须覆盖
4. 幂等与一致性：模拟重复回调与网络抖动，验证幂等锁和数据库状态
5. 日志与审计：检查AuditLog是否记录所有关键操作并脱敏敏感数据

**一句话记忆**：“沙箱先演练，线上才安全。”

---

# 第五部分：安全防御——避免AI生成隐性漏洞

## 第25条：结合AI与安全审计，强化支付链路防御

> **核心原则**：AI生成的代码能跑，但不代表安全。通过结合AI分析、人工安全审计和官方文档交叉验证，对Web3支付链路进行全方位的安全检查。

2014年，黑客利用Heartbleed漏洞窃取了数百万用户的敏感数据。这个漏洞存在于被广泛使用的OpenSSL库中，代码看起来完全正常，但隐藏着致命的安全缺陷。

AI只会生成“最常见”的实现，但支付逻辑往往有独特的安全要求。它容易忽略异常回调、重复调用、非法Payload等安全边界条件。

**Web3支付安全审计重点**：
1. **签名与验签**：验签逻辑必须使用官方SDK或权威算法，签名计算必须严格固定字段顺序
2. **防重放与幂等性**：检查回调Payload中的`timestamp`和`nonce`，在数据库或Redis中存储签名ID
3. **权限与认证**：校验回调来源IP、域名与签名一致性
4. **敏感数据保护**：所有私钥、签名值、JWT Token必须加密存储，日志必须脱敏

**一句话记忆**：“AI能写代码，人要保安全。”

---

## 第26条：统一异常处理与错误码，让AI输出可控

> **核心原则**：在使用AI生成代码时，必须先制定统一的异常处理与错误码策略，并让AI严格遵循。

1999年，Y2K问题让全世界紧张了一整年。问题的根源很简单：程序员们用两位数字表示年份，没有统一的标准。统一规范的重要性由此可见一斑。

如果AI生成的代码没有统一的异常处理策略，可能导致错误信息不可追踪、回调异常无法区分、数据库状态不一致、上游系统收到模糊的返回状态。

**Web3支付中的异常策略重点**：
- 签名与验签异常：`SIGN_001`（签名失败）、`SIGN_002`（验签失败）
- 回调处理异常：`CALLBACK_001`（Payload缺失）、`CALLBACK_002`（回调重复）
- 幂等与事务异常：`IDEMPOTENT_001`（幂等锁失效）、`TX_001`（事务回滚）
- 第三方依赖异常：`BLOCKCHAIN_001`（区块链节点超时）

**在Prompt中给AI提供异常体系**：
```
根据以下GlobalExceptionHandler代码，帮我在新生成的回调处理逻辑中统一接入异常策略。
```

**一句话记忆**：“异常有规范，错误可追踪；AI按规写，系统更可控。”

---

## 第27条：用AI生成安全基线检查，防止隐性漏洞

> **核心原则**：借助AI生成安全基线检查清单和自动化测试脚本，确保整个支付链路具备足够的防御能力。

军事上有“纵深防御”的概念——不依赖单一防线，而是建立多层防护。支付安全也应如此：签名验证是一道防线，幂等控制是一道防线，权限校验又是一道防线。

**Web3支付安全基线检查重点**：
1. **签名与验签**：检查签名算法是否符合官方SDK标准，验证签名字段顺序
2. **防重放攻击**：检查`nonce`、`timestamp`是否严格校验，在幂等锁中记录唯一请求ID
3. **回调幂等性**：验证回调请求重复到达时状态是否被正确拦截
4. **敏感信息保护**：所有私钥、JWT必须加密存储，审计日志只记录摘要

**AI辅助安全基线的Prompt示例**：
- “请根据以下代码生成一份安全检查清单，重点检查签名、回调、幂等、权限控制。”
- “帮我分析这段支付回调逻辑，找出缺失的安全校验点，并生成Mock攻击用例。”

**一句话记忆**：“AI扫风险，人来兜底；安全基线先固化。”

---

## 第28条：让AI生成数据库一致性检查与修复脚本

> **核心原则**：借助AI自动生成一致性检查与修复脚本，提前发现数据错乱、幂等失效、回调丢失等问题，避免影响资金结算。

银行每天晚上都要进行“轧账”——核对当天的所有交易记录，确保账实相符。支付系统也需要类似的机制。

当AI生成的逻辑上线后，最常见的隐患是：回调未写库导致状态缺失、交易重复回调导致状态异常、多次更新覆盖真实状态、账实不符导致资金风险。

**Web3支付一致性巡检重点**：
1. 回调状态检查：检查已上链交易是否有缺失回调，检查重复回调是否被幂等锁正确处理
2. 交易状态对账：数据库中的交易状态 vs 链上区块确认状态
3. 幂等锁验证：检查重复请求是否产生多条相同交易记录
4. 资金对账：商户余额、链上金额、日志流水三者是否一致

**AI辅助生成检查脚本的Prompt示例**：
- “根据以下表结构，生成检测交易表`t_tx_record`中重复交易的SQL。”
- “请生成对账脚本，校验交易表中的回调状态与审计日志是否一致。”

**一句话记忆**：“先检查，再修复；用AI生成SQL，让一致性可控。”

---

# 第六部分：性能优化与可维护性

## 第29条：基于AI生成代码进行可控重构

> **核心原则**：AI生成的代码通常能跑，但未必可维护。在投入生产前，应结合AI辅助与人工审查，对代码进行可控重构。

1972年，大卫·帕纳斯发表了著名的论文《论模块分解的标准》，奠定了软件工程中“模块化”思想的基础。AI生成的代码往往缺乏这种设计感——它可能一次性生成巨型方法或控制器，重构后按职责拆分，后续修改才更安全。

**Web3支付代码重构重点**：
1. **签名与验签逻辑**：单独抽离`CryptoService`，避免在控制器或Service中散落加密实现
2. **回调与幂等性控制**：将回调逻辑封装在`CallbackHandler`中，集中管理重放保护与幂等锁
3. **事务与一致性**：在Service层内实现事务边界，不让控制器直接操作数据库
4. **日志与审计**：用统一的`AuditLogService`，避免散落的`System.out.println`

**AI辅助重构的策略**：
- 提示AI识别问题：“请找出这段代码中可重构的地方，并列出优先级最高的三个点。”
- 让AI生成重构方案：“帮我把签名逻辑抽取到独立的CryptoService，保持原有方法签名不变。”
- 分阶段验证：重构一部分→跑单测→提交→再重构下一部分

**一句话记忆**：“先锁定行为，再小步重构；让AI出方案，由你定取舍。”

---

## 第30条：让AI辅助识别性能瓶颈并优化关键路径

> **核心原则**：利用AI快速分析日志、调用链和SQL执行情况，找出性能瓶颈所在的关键路径。

1995年，亚马逊发现页面加载时间每增加100毫秒，销售额就会下降1%。性能问题从来不是小事。

AI生成的代码未必高效，尤其是Web3支付链路涉及签名计算、链上交互、回调处理、多线程并发，稍有不慎就会出现性能瓶颈。

**Web3支付链路中常见性能瓶颈**：
1. 签名/验签耗时：检查是否使用了低效算法或未启用本地缓存
2. 链上交易广播慢：可能因区块链节点配置不当或Gas估算错误
3. 回调处理阻塞：如果回调接口同步写数据库，可能导致接口超时
4. 数据库锁竞争：幂等锁、事务冲突导致高并发下性能骤降
5. 不必要的串行：缺乏异步化设计，支付状态轮询与回调写数据库串行执行

**AI辅助性能优化的示例Prompt**：
- “请帮我分析这段JProfiler调用链，找出最耗时的三个方法。”
- “根据下面的SQL日志，优化慢查询并推荐合适的索引。”

**一句话记忆**：“AI找瓶颈，数据定结论，优化靠验证。”

---

## 第31条：用AI生成架构图与数据流图，提升全局可控性

> **核心原则**：通过让AI生成可编辑的架构图、时序图、数据流图，帮助你理解代码之间的依赖关系和业务链路。

地图的价值不在于它有多精确，而在于它能帮你看清全局。在复杂的支付系统中，架构图和数据流图就是你的“地图”。

如果没有一份可视化的架构图，很容易陷入“只懂一小块”的状态，导致无法发现逻辑缺口或潜在安全风险。

**Web3支付架构图示例**：
1. **高层架构图**：Controller→Service→CryptoService→BlockchainSDK→CallbackHandler，标出安全检查点、事务边界和幂等锁
2. **数据流图**：显示交易数据从请求到区块链再到回调的全链路
3. **时序图**：展示支付请求、签名、广播、回调、幂等验证的时间顺序

**AI生成可视化图表的Prompt示例**：
- “根据以下服务和方法结构，帮我生成一个Mermaid架构图。”
- “请根据以下Web3支付链路，生成数据流图。”
- “根据回调逻辑，画出时序图，标出幂等锁的生效时机与回滚条件。”

**一句话记忆**：“先画图，再优化；先全局，再局部。”

---

## 第32条：利用AI生成代码审查清单，建立可维护性保障

> **核心原则**：通过让AI自动生成高价值的代码审查清单，结合人工检查，确保每一行代码都达到上线要求。

医生在手术前会核对检查清单：患者身份、手术部位、过敏史……这个简单的做法将手术事故率降低了三分之一。代码审查清单也有类似的效果。

AI生成的实现可能可用，但经常存在命名风格不一致、缺少边界条件处理、重复逻辑和长方法、潜在性能瓶颈等问题。

**Web3支付场景的审查重点**：
1. **安全性**：验签算法是否符合官方SDK标准，回调幂等锁是否正确使用，日志是否脱敏敏感字段
2. **性能**：检查高并发场景下锁竞争是否合理，慢SQL、无必要的全量遍历
3. **可维护性**：控制器是否过重，是否存在重复逻辑
4. **一致性**：错误码、DTO、日志格式是否遵循统一规范

**一句话记忆**：“AI先审查，人工再把关；清单先固化，未来更高效。”

---

## 第33条：利用AI自动生成集成测试，验证跨模块行为

> **核心原则**：在AI生成的代码上线前，必须通过端到端集成测试验证跨模块行为。

1962年，水手1号探测器在发射84秒后被引爆。原因是一行Fortran代码中的一个标点符号错误。单元测试无法发现这个问题，因为错误发生在模块交互时。

AI生成的代码局部可用，但可能遗漏幂等性校验、回调签名验证等全局约束。集成测试能在沙箱中验证区块链SDK、Web3网关、支付回调接口等外部依赖。

**Web3支付集成测试的关键场景**：
1. 签名一致性验证：验证AI生成的签名计算与官方SDK输出是否一致
2. 回调幂等控制：模拟重复回调，检查幂等锁是否正确拦截
3. 交易状态一致性：模拟链上广播成功和失败两种情况
4. 异常场景覆盖：模拟回调Payload缺失字段、签名过期、区块链超时

**一句话记忆**：“AI写代码，集成测闭环；模拟真实链路，确保系统可控。”

---

# 第七部分：持续演进——构建AI+人工的闭环体系

## 第34条：关注AI生成代码的合规与知识产权

> **核心原则**：在使用AI生成代码时，需要关注合规与知识产权问题，确保生成的代码可以安全地用于商业项目。

2023年，多起关于AI生成内容版权的诉讼引发了广泛讨论。虽然法律尚未完全明确，但作为负责任的开发者，我们应该提前考虑这些问题。

**需要关注的问题**：
- **隐私模式**：开启隐私模式，确保敏感代码不被远端存储
- **代码相似性**：对AI生成的关键算法，验证是否与开源项目高度相似
- **审计依据**：在涉及支付合规的场景，保留AI交互记录作为审计依据
- **团队规范**：建立AI代码使用的内部规范

**最佳实践**：
- 对于核心业务逻辑，人工审查后再使用
- 保留AI对话记录，作为代码来源的追溯依据
- 对于开源项目，确保AI生成的代码符合许可证要求

**一句话记忆**：“用AI要合规，代码来源要可溯。”

---

## 第35条：建立AI+人工的持续改进闭环，让方案可演进

> **核心原则**：AI生成的方案和代码只是起点，最终落地需要“AI生成→人工验证→数据反馈→Prompt优化→再次生成”的持续改进闭环。

1950年，戴明博士提出了著名的PDCA循环（计划-执行-检查-行动），成为质量管理的基石。AI协作也需要类似的循环：生成是计划，验证是执行，反馈是检查，优化是行动。

没有反馈的AI会在每次生成中重复相同的问题。把人工审查与沙箱测试的结论反哺到Prompt中，下一次生成的代码会更贴近你的要求。

**持续改进的四个步骤**：
1. **AI驱动**：初版方案和代码交给AI快速产出
2. **人工验证**：结合单测、集成测试、沙箱链路和安全审计验证
3. **数据反馈**：把问题点、改进点、失败案例输入AI，优化Prompt
4. **持续演进**：新Prompt + 新上下文→更高质量的输出→逐步积累项目知识库

**提升闭环效率的技巧**：
- Prompt模板化：固定AI生成方案的结构：背景→约束条件→成果要求→输出格式
- 知识库沉淀：把验证过的有效逻辑整理到Wiki或文档
- 团队共享经验：定期同步AI使用方法、最佳Prompt、已解决问题案例

**一句话记忆**：“AI产出，人工验证；数据反馈，持续进化。”

---

# 总结：让AI生成的代码真正“可控、可懂、可负责”

回到本文开头的火星气候探测器故事。那次事故的教训不是“不要用计算机”，而是“要确保人类理解并验证计算机的输出”。今天，当我们使用AI生成代码时，这个教训同样适用。

AI时代，代码的生产方式正在发生根本性变化。我们不再是“独立写代码的人”，而是与AI共同设计、共同实现的协作者。然而，AI生成的方案和代码只是“起点”，而不是“答案”。如果我们想真正为AI生成的代码负全责，就必须从五个维度构建完整的实践方法论：

**一、清晰输入**：掌握问题，控制AI输出方向（第1-6条）
好的输出，始于好的输入。你不是在“提问”，而是在“设计AI的工作流”。

**二、方案设计**：先对齐思路，再落地实现（第7-9条）
设计在前，生成在后；先和AI对齐方案，再进入实现，能避免大规模返工。

**三、审慎验证**：让AI产出可被信任（第10-16条）
不要盲目信任AI，把它当“初稿助手”，用多重验证手段重建信任。

**四、调试排查**：用科学方法定位问题（第17-24条）
调试是一门科学，需要假设、验证、最小化重现，AI是你的助手而非替代者。

**五、安全防御**：避免AI生成隐性漏洞（第25-28条）
AI能写代码，但安全需要我们兜底；AI能扫描风险，但安全闭环要靠人机协作。

**六、性能与可维护性**：让代码可演进（第29-33条）
性能分析要数据驱动，可维护性要架构保障，AI给线索，人来验证。

**七、持续演进**：构建AI+人工的闭环体系（第34-35条）
AI是“副驾驶”，不是“自动驾驶”。闭环优化，才能让系统长期健康演进。

---

如果说AI让我们写代码的效率提升了10倍，那么这35条方法的目标，是确保**“高效”不以“失控”为代价**，让我们既能快，又能对每一行代码、每一次上线、每一次链路安全**负全责**。

> **一句话总结**：  
> “AI写得快，人要看得透；建立可控的闭环，让速度与安全并存，让效率与责任共生。”