Web后端开发工程师AI协作指南

作为一名初入职场的程序员小白，在工作过程中遇到一些程序问题，应该如何解决，总不能遇到困难拎包跑路吧！

 今天我就教大家：Web后端开发工程师AI协作指南

废话不多说，正文开始 

作为Web后端工程师，向AI高效提问并获得有价值的代码/Git提交审查，关键在于提供清晰、结构化、具体的上下文。以下是如何组织语言的专业话术和模板：

核心原则 (M.E.C.C.A.)：

1. M - Mission (任务目标): 清晰说明你想要实现什么功能或修复什么问题。

2. E - Environment (环境): 提供必要的技术栈、框架、版本、数据库等信息。

3. C - Code/Change (代码/变更): 提供相关代码片段或Git提交的Diff内容。这是核心！

4. C - Context (上下文): 解释代码/变更在整体架构中的位置、相关业务逻辑、依赖关系。

5. A - Ask (明确提问): 清晰列出你具体希望AI检查或回答的问题。

一、 针对代码问题提问的模板

### 任务目标 (Mission)
*   我正在开发/修复 [具体功能模块/API端点/问题描述，例如：用户注册API的密码加密逻辑优化]。
*   预期目标是 [具体目标，例如：使用BCrypt替代MD5，并确保与现有用户密码兼容]。### 环境与上下文 (Environment & Context)
*   **技术栈:** [例如：Java 17 / Spring Boot 3.1.0 / MySQL 8.0]
*   **相关模块:** [例如：`UserService`, `UserRepository`, `PasswordEncoder` 配置]
*   **关键业务逻辑:** [简要说明相关业务规则，例如：新用户注册使用新加密，老用户登录时验证后迁移其密码哈希值]
*   **依赖/约束:** [例如：必须兼容现有`users`表中的`password_hash`字段（目前是MD5）]### 代码/问题 (Code/Change)
*   **相关代码片段 (请只贴关键部分，避免大段无关代码):**```java// UserService.java (片段) - 新用户注册@Servicepublic class UserService {@Autowiredprivate PasswordEncoder passwordEncoder; // 配置为BCryptPasswordEncoder(10)@Autowiredprivate UserRepository userRepository;public User registerUser(UserRegistrationDto dto) {User user = new User();user.setUsername(dto.getUsername());// 👇 这是新写的密码加密代码，重点检查这里user.setPasswordHash(passwordEncoder.encode(dto.getPassword()));// ... 其他设置return userRepository.save(user);}// 👇 老用户登录密码迁移逻辑 (伪代码，请帮我检查逻辑是否合理)public boolean loginAndMigrate(String username, String password) {User user = userRepository.findByUsername(username);if (user == null) return false;// 1. 先用旧MD5方式验证if (md5(password).equals(user.getPasswordHash())) {// 2. 验证通过，用新BCrypt加密密码并更新user.setPasswordHash(passwordEncoder.encode(password));userRepository.save(user);return true;}// 3. 尝试用新BCrypt验证 (可能是已经迁移过的用户)return passwordEncoder.matches(password, user.getPasswordHash());}}```### 具体问题 (Ask)
1.  **逻辑检查：** 我写的 `loginAndMigrate` 方法中的密码迁移逻辑（MD5验证 -> 迁移更新 -> BCrypt验证）是否存在并发问题（比如多次登录导致多次迁移）或逻辑漏洞？是否安全？
2.  **代码优化：** 新用户注册的 `passwordEncoder.encode` 调用位置和方式是否符合 Spring Security 的最佳实践？有没有更优雅的写法？
3.  **兼容性：** 这种双验证+迁移的方式处理新旧密码哈希，在过渡期间是否可靠？需要注意哪些边界情况？
4.  **潜在风险：** 从安全或性能角度看，这种方案有什么潜在风险？

二、 请求AI检查Git提交内容是否符合逻辑的模板 (核心是提供清晰Diff和解释意图)

### 审查请求：Git提交逻辑检查
*   **分支/PR：** [例如：`feature/user-password-migration` 分支的提交]
*   **关联需求/任务：** [例如：JIRA号 ABC-123 或 描述：用户密码存储安全升级]### 提交信息 (Commit Message)
feat(user): migrate password hashing from MD5 to BCryptImplement BCryptPasswordEncoder for new user registration in UserService.Add logic in login to authenticate existing MD5 passwords and transparently migrate them to BCrypt upon successful login.Update PasswordConfig to use BCrypt with strength 10.Add unit tests for migration logic (LoginServiceTest).

举个栗子：

### 关键变更 (Changes - 请提供 `git diff` 或 描述关键改动)
*   **文件: `src/main/java/com/example/service/UserService.java`**```diff+    public boolean loginAndMigrate(String username, String password) {+        User user = userRepository.findByUsername(username);+        if (user == null) return false;++        // Check using old MD5+        if (md5(password).equals(user.getPasswordHash())) {+            // Migrate to BCrypt+            user.setPasswordHash(passwordEncoder.encode(password));+            userRepository.save(user);+            return true;+        }++        // Check using BCrypt (for migrated users)+        return passwordEncoder.matches(password, user.getPasswordHash());+    }```*(说明：新增了登录迁移方法)**   **文件: `src/main/java/com/example/config/PasswordConfig.java`**```diff@Beanpublic PasswordEncoder passwordEncoder() {-    return NoOpPasswordEncoder.getInstance(); // 👈 旧的不安全方式+    return new BCryptPasswordEncoder(10); // 👈 新的BCrypt方式}```*   **文件: `src/test/java/com/example/service/LoginServiceTest.java`***(说明：新增了测试迁移逻辑的测试用例)*### 提交意图与上下文 (Context)
*   本次提交的主要目的是将用户密码哈希算法从不安全的MD5迁移到BCrypt。
*   **核心策略：** 新用户直接用BCrypt；老用户在**成功登录时**，如果其密码还是MD5，则验证通过后**立即将其密码更新为BCrypt哈希**。之后该用户登录就使用BCrypt验证。这称为“惰性迁移”。
*   选择这个策略是为了避免一次性迁移所有用户密码带来的性能和操作风险。### 请求AI检查的重点 (Ask)
1.  **逻辑一致性：** 提交的代码变更是否完整实现了提交信息中描述的“惰性迁移”策略？逻辑流程（MD5验证 -> 迁移更新 -> BCrypt验证）是否清晰正确？
2.  **原子性与完整性：** 这个提交是否是一个逻辑上完整的变更单元？提交信息是否准确概括了所有重要改动？（例如，配置更改、服务层逻辑、测试是否都包含且匹配？）
3.  **潜在问题：***   **并发问题：** `loginAndMigrate` 方法在高并发登录时，对同一个用户进行多次迁移更新是否安全？会不会导致数据竞争或覆盖？(考虑数据库行锁或乐观锁)*   **错误处理：** 在 `userRepository.save(user)` 更新密码哈希时如果失败（如数据库异常），用户是否会被错误地标记为登录成功？如何处理这种失败？*   **测试覆盖：** 新增的单元测试是否充分覆盖了迁移场景（MD5登录成功迁移、BCrypt登录、错误密码、用户不存在）？*   **安全考虑：** 在迁移过程中（MD5验证成功但BCrypt保存前），密码明文短暂存在于服务端内存，是否有风险？`md5(password)` 的实现是否安全（避免null、异常）？*   **性能影响：** BCrypt计算和额外的数据库更新 (`save`) 对登录性能的影响是否可接受？尤其是在迁移高峰期。
4.  **最佳实践：** 这个实现方案是否符合Web安全和服务端开发的最佳实践？是否有更优或更常见的处理密码迁移的模式？
5.  **提交信息质量：** 提交信息是否符合规范（如Conventional Commits）？是否清晰、简洁、说明了*为什么*要这样改（提升安全性）？

关键提示：

1. 精简代码： 永远只提供与问题直接相关的、最小化的代码片段。 删除无关的import、getter/setter、日志等。AI处理冗长代码效率低。

2. 精准描述： 使用准确的类名、方法名、变量名。避免“那个函数”、“某个地方”等模糊表述。

3. 提供Diff： 对于Git审查，git diff 是最直接的方式。如果平台限制，清晰描述修改了哪些文件、哪些行、做了什么改动。

4. 明确提问点： 不要只说“帮我看看有没有问题”。明确指出你担心的方面（逻辑、性能、安全、并发、测试、规范）。

5. 版本信息很重要： 框架、库、数据库的版本差异可能导致解决方案不同。

6. 业务背景： 解释代码背后的业务规则，这直接影响逻辑是否正确。

7. 安全敏感信息： 绝对不要提交真实API密钥、密码、数据库连接字符串等敏感信息！用占位符 ******** 或 your_api_key_here 代替。

8. 预期输出： 可以说明你希望AI以什么形式回答（如：列出潜在风险点、给出优化建议、直接指出代码错误）。

专业沟通话术要点：

• 礼貌但直接： “请帮忙检查...”, “麻烦分析一下...”, “请问这个实现是否存在...风险？”

• 聚焦技术： 避免情绪化语言（如“这个破bug搞死我了”），专注于技术细节。

• 使用术语： 正确使用后端开发术语（如并发、事务、依赖注入、ORM、RESTful、哈希、加盐等）。

• 结构化表达： 像写代码注释或技术文档一样组织你的问题。使用标题、列表、代码块分隔符。