AI辅助开发

更新: 2026/4/24 字数: 0 字 时长: 0 分钟

这页用于规范团队在日常研发中如何使用 AI 辅助工具。重点不是“能不能用”，而是“如何安全、有效、可控地用”。

AI 在研发中的定位

AI 适合作为以下角色：

• 助手：帮你补全代码、生成草稿、整理方案、总结问题。
• 加速器：减少样板代码、重复劳动、检索成本和文档编写时间。
• 陪练对象：用于学习新技术、推演边界情况、检查思路是否完整。

AI 不应替代以下责任：

• 业务判断
• 架构设计拍板
• 安全与合规审核
• 最终代码质量背书

一句话：AI 可以提高交付速度，但开发者始终对结果负责。

基本原则

1. 安全优先

• 不向未授权平台输入源码、数据库结构、密钥、令牌、客户数据、内部地址等敏感信息。
• 对外部 AI 工具默认采用“最小暴露”原则，只提供完成任务所必需的上下文。
• 涉及生产事故、漏洞修复、客户数据分析时，优先使用公司允许的工具和隔离环境。

2. 理解优先于复制

• 不直接提交未经验证的 AI 输出。
• 在采纳前必须理解核心逻辑、输入输出、异常路径和边界条件。
• 对不理解的代码，宁可重写，也不要“先合进去再说”。

3. 质量不打折

• AI 生成的代码与人工编写的代码遵循同样的测试、审查和发布标准。
• 重点检查错误处理、性能、并发、权限、资源释放、日志与可观测性。

4. 过程可追踪

• 重要设计、关键 Prompt、方案取舍、验证结论应有记录。
• 在 PR 中标明 AI 参与的范围，便于评审者聚焦高风险部分。

推荐使用场景

AI 最适合承担“高频、规则相对明确、可快速验证”的工作：

• 生成样板代码、类型定义、表单逻辑、接口封装
• 辅助编写测试用例、Mock 数据、脚本工具
• 总结报错信息、分析日志、排查常见问题
• 草拟技术方案、接口文档、变更说明、复盘记录
• 对陌生代码做结构化解释，帮助快速上手
• 批量做命名建议、重构建议、代码注释和文案润色

慎用或禁用场景

以下场景需要谨慎，必要时应禁止直接依赖 AI 输出：

场景	风险	建议
核心交易、权限、风控、安全逻辑	错误代价高	由资深开发主导设计与实现
含敏感数据的排障与分析	可能泄露隐私或内部信息	使用脱敏数据或隔离环境
底层框架、基础库、公共组件	一处错误影响面大	严格评审并补齐测试
法务、版权、协议相关内容	合规风险高	交由人工确认来源与条款
完全未知的技术方案	AI 容易“编得像真的”	以官方文档和实验验证为准

推荐工作流

把 AI 当作协作者时，建议至少遵循下面三步。

一、提问前：先把问题定义清楚

在把问题交给 AI 前，先自己补齐这几个要素：

• 目标是什么
• 当前上下文是什么
• 成功标准是什么
• 有哪些限制条件
• 你希望 AI 产出什么格式

一个好问题，通常会包含：

目标：
背景：
技术栈：
输入输出：
限制条件：
希望产出：

二、生成中：让 AI 逐步工作

相比“一次性生成完整系统”，更推荐分阶段提问：

1. 先让 AI 帮你拆解问题。
2. 再让 AI 只处理其中一个子问题。
3. 对关键实现要求它说明思路、边界条件和权衡。
4. 最后要求输出可验证的结果，例如测试样例、检查清单、伪代码或命令步骤。

这样做的好处是：

• 更容易发现 AI 的误解
• 更容易控制输出范围
• 更方便人工校验

三、采用后：必须人工复核

采纳 AI 输出前，至少检查：

• 是否满足原始需求
• 是否引入了隐藏依赖
• 是否处理异常、空值和边界场景
• 是否与现有代码风格、目录结构一致
• 是否需要补测试、补注释、补文档

推荐 Prompt 模板

代码实现类

你是资深工程师，请基于以下信息完成任务：

- 目标：
- 当前文件/模块职责：
- 技术栈：
- 约束条件：
- 需要保留的现有行为：
- 希望输出：

请先给出实现思路，再给出代码，并说明风险点与测试建议。

排障分析类

请帮我分析以下问题：

- 现象：
- 复现步骤：
- 相关日志/报错：
- 最近变更：
- 我的初步判断：

请按“可能原因 -> 验证方法 -> 修复建议”的格式回答。

文档整理类

请把下面内容整理成团队文档，要求：

- 面向对象：
- 使用场景：
- 风格要求：
- 是否保留示例：
- 输出结构：

代码审查检查清单

凡是 AI 参与生成的实现，Code Review 时建议重点看下面几项：

• 是否真正理解了业务约束，而不是只“看起来能跑”
• 是否存在重复封装、过度设计、命名空泛等问题
• 是否遗漏错误处理、状态回收、权限校验、空态兜底
• 是否偷偷引入了不必要依赖
• 是否存在伪 API、伪配置、伪类型定义
• 是否补充了足够的测试或验证步骤

工具选择建议

与其追逐“最新最强工具”，不如先按任务类型选工具：

工具类型	适合任务	注意事项
IDE 补全类	实时补全、局部重构、样板代码	上下文短，适合小步修改
对话问答类	方案讨论、报错分析、文档整理	要注意幻觉和过时信息
Agent/CLI 类	多文件改动、脚本执行、自动化操作	必须控制权限和执行范围
本地模型/私有部署	敏感项目、内网环境	需要额外维护成本

团队协作建议

• 在 PR 描述中写明 AI 参与范围，例如“测试脚本草稿由 AI 生成，已人工调整”。
• 建立内部 Prompt 模板库，沉淀高质量用法。
• 定期复盘哪些场景真正节省了时间，哪些场景反而增加返工。
• 对高风险模块设立额外校验门槛，例如双人评审、补充回归测试。

常见误区

误区 1：AI 写得快，所以一定更省时间

不一定。如果问题定义不清，后续返工会更大。

误区 2：AI 输出很多，说明它懂得很多

不一定。长答案不等于正确答案，仍需基于官方文档、日志和实验验证。

误区 3：有了 AI，就不需要基本功

恰恰相反。越懂业务、架构和代码质量，越能把 AI 用好。

一句话总结

把 AI 当作“高效副驾”，不要把它当作“自动驾驶”。好的 AI 协作方式，应该让团队更快、更稳，而不是更依赖运气。