AI Coding

AI 编程工具已经成为 AI 应用工程师的基础装备。会用 AI 写代码，不等于让 AI 替你乱改项目，而是把它当成一个能阅读上下文、生成方案、执行重复工作、辅助测试的工程搭档。

AI 编程的正确心态

AI 编程不是把判断权全部交出去，而是提高你阅读、修改和验证代码的速度。你仍然要负责目标、边界、取舍和最终质量。

可以把 AI 当成：

• 快速阅读代码库的助手。
• 生成样板代码的助手。
• 提供方案对比的助手。
• 写测试和文档的助手。
• 排查错误日志的助手。

不要把 AI 当成无需 review 的自动提交机器。

常见工具类型

推荐工作流

• 先让 AI 阅读项目结构。
• 描述目标，不要只说“帮我优化一下”。
• 要求 AI 先找相关文件。
• 小步修改，每次只改一个明确问题。
• 跑测试或最小验证。
• 让 AI 总结改了什么、风险是什么。

一个更完整的任务流程

明确目标
  -> 找相关文件
  -> 理解现有模式
  -> 制定小范围修改
  -> 实施
  -> 运行测试或手动验证
  -> Review diff
  -> 记录结果

AI 最容易出错的地方是没有理解现有模式就开始写代码。所以在修改前，让它先读代码，比直接让它生成代码更重要。

好任务和坏任务

坏任务：

帮我把这个项目变好。

好任务：

请帮我给 RAG 问答接口增加引用来源字段。要求：
- 不改变现有请求格式
- 响应中新增 sources 数组
- 每个 source 包含 title、url、chunk_id
- 补一个单元测试

怎么写高质量任务描述

好的任务描述通常包含：

• 背景：为什么要改。
• 目标：改完后用户能做什么。
• 范围：哪些文件或模块可以改。
• 约束：不能破坏哪些行为。
• 验证：需要跑什么测试或怎样手动检查。
• 输出：希望 AI 最后总结什么。

示例：

请给知识库问答接口增加引用来源。范围只限后端 response 组装和相关测试。
不要改变请求参数。返回 sources 数组，每个元素包含 title、chunk_id、score。
完成后运行现有测试，并说明是否有兼容性风险。

AI 编程的风险

• 看起来能跑，但边界条件错了
• 引入不必要依赖
• 改动范围过大
• 测试只是为了通过当前样例
• 没理解现有架构就重写
• 泄露密钥或敏感数据

Review AI 生成代码时看什么

重点看：

• 是否改动了任务之外的文件。
• 是否引入不必要依赖。
• 是否破坏现有接口兼容性。
• 是否处理错误和边界情况。
• 是否有测试覆盖核心路径。
• 是否有安全风险，例如日志泄露 token。
• 是否符合项目已有风格。

不要只看“能不能跑”。能跑只是第一层，长期可维护才是关键。

适合交给 AI 的任务

• 生成样板代码
• 写单元测试
• 解释陌生代码
• 批量修改文档
• 查找 bug 可能位置
• 根据错误日志定位问题
• 生成迁移脚本初稿

不适合完全交给 AI 的任务

• 生产高风险变更
• 安全策略设计
• 数据库破坏性迁移
• 财务、医疗、法律等高风险判断
• 没有测试保护的大规模重构

个人 AI 编程习惯

• 每次改动前看 git status
• 让 AI 说明会改哪些文件
• 保持任务小而清晰
• 重要逻辑自己 review
• 让测试和 lint 成为最终裁判
• 不把 .env、token、cookie 发给任何模型

适合练习的场景

• 让 AI 给一个陌生函数写解释，并验证它是否正确。
• 让 AI 为已有函数补单元测试。
• 让 AI 根据错误日志定位可能原因。
• 让 AI 把重复代码抽成小函数。
• 让 AI 给项目 README 增加使用说明。

这些任务风险低、反馈快，很适合训练 AI 协作能力。

团队协作规范

团队使用 AI 编程时，建议明确：

• 哪些代码可以交给 AI 辅助。
• 哪些数据不能提供给模型。
• 是否允许使用生产日志。
• AI 生成代码是否必须人工 review。
• Prompt、工具和模型调用是否要记录。
• 安全相关代码是否需要额外审批。

AI 编程越深入团队流程，越需要清晰边界。