上周给一个集团做 AI 编程培训方案。

他们的 IT 负责人问了我一个问题，这个问题大概每个人都会问：

"我们团队已经在用 Copilot 了，算是和 AI 结合了吧？"

我说，你知道"补全"这个词最初的含义吗？

补全文档。补全功能。补全参数。补全测试。补全部署。

AI 在项目生命周期的每一个环节，都在帮你"补全"什么东西。只不过大部分人只用了最浅的那一层。

- 写 function calc，AI 帮你补完参数和返回值。这是大部分人停住的地方。

- 写了一句需求"批量导入用户，支持 Excel 和 CSV"，AI 帮你生成导入模块的接口定义、数据校验逻辑、异常处理、单元测试。一堆老旧的 Java 8 代码要迁移到 Java 17，AI 批量做完语法升级、依赖替换、Stream API 改造——8 个模块，原计划 24 人天，4 小时搞定。

- 写了一个采购模块，AI 从安全视角帮你补上一句："供应商优先级数值越小越优先，你写反了。"——它不是帮你写代码，是帮你发现你写了但写错了的东西。

不少程序员只用在第一层。第二层偶尔碰一下。第三层几乎没人用。

这就是为什么很多人觉得"AI 编程不过如此"——你不是在用 AI 编程，你是在用 AI 补全代码。差了两个字，差了十倍效率。

每个环节，AI 都在补全什么

我有一次帮一个电商平台的库存中台做重构分析。6 个人，2 个月，完成了原来 8 个人 4 个月的工作量——相当于用 12 人月干完了 32 人月的活，效率翻了 2.67 倍。

他们用的工具是 Cursor + Copilot + Sourcery 的三角组合，但核心不是工具，是他们在每个环节都知道 AI 该补什么。

需求环节：AI 补全边界条件。是不是常常遇到：开发到一半遇到"如果用户同时点两次提交按钮怎么办"、"如果 Excel 里有重复用户名怎么办"，这些边界条件 PRD 里一个都没写。更常见的是：需求调研做了好几轮，PM 觉得都覆盖了，等系统上线，最终用户抛出一堆"这个场景你们没考虑吗"的问题："为什么我不能批量导入"、"为什么离职员工的工单就消失了""为什么审批超时后没有提醒"。人脑不擅长穷举异常路径和用户场景，AI 擅长。把需求发给 AI，追加一句"请从文件格式、数据量、并发、异常处理、权限控制五个维度补全边界条件"，再追加一句"从最终用户的视角，列出这份需求文档可能遗漏的 10 个使用场景"，它帮你列出可能漏掉的点，再拿去和用户进一步讨论。

架构环节：AI 补全视角。一个架构师要画多少张图？业务架构图、应用架构图、技术架构图、网络拓扑图、部署架构图、数据流图……画完图还要考虑安全策略、性能瓶颈、容灾热备、灰度方案、降级熔断、监控告警。一个人不可能同时把所有维度想全。你把方案初稿发给 AI，让它分别从安全、性能、成本、可维护性、灾备五个角色来审，它能在一分钟内输出一份多视角审查报告——哪些地方单点故障、哪些接口没有限流、哪些服务没有降级方案。但注意一个坑：AI 多角色评审有盲区。2025 年有份研究指出，让多个 AI 角色并行评审，它们倾向于互相同意——就像你让七个下属评审你的方案，大家都投赞成，不是因为方案好，是因为大家都倾向于同意。所以正确做法是 AI 多角色并行 + 人类把关。

编码环节：这是大家最熟悉的。但从 PRD 到架构设计到编码，中间还隔着一层很多人跳过的步骤：详细设计。接口定义、数据模型、模块拆解、状态机、异常处理策略——这些如果没想清楚就直接写代码，写到一半发现前后矛盾，返工成本最高。AI 可以把架构方案直接展开成详细设计：从一个模块描述生成接口签名、入参出参校验规则、数据库表结构、核心流程的伪代码。然后才是编码。另外编码还有个技巧：你的类型注解覆盖率越高，AI 输出质量越好。因为你给 AI 的上下文越精确，它猜的越少。电商平台那个项目证明了这一点：用 Copilot 做批量重构时，示例中没写"供应商优先级数值越小越优先"的规则，AI 就默认按"越大越优先"处理，结果高优先级供应商排在了最后。别让AI猜。

审查环节：AI 补全安全防线。这个问题最严重，因为 AI 写代码的速度已经远超人类审查的速度——你一天写 500 行，人审得过来；AI 一分钟 500 行，审不过来了。攻击面也在同步扩大。2025 年 Amazon Q 的 VS Code 扩展被植入恶意 prompt，删用户文件、破坏 AWS，挂了 2 天才修复。Copilot CamoLeak（CVSS 9.6），隐藏 HTML 注释窃取私有代码和 API Key。Rules File Backdoor，不可见 Unicode 藏后门，人眼根本看不到。2026 年更离谱：HuggingFace 上有人用 typosquatting 冒充 OpenAI 仓库，植入 Sefirah 木马，24.4 万次下载，18 小时冲到趋势榜第一。前不久 OpenAI 自己搞内部安全测试，GPT-5.6 在沙箱里居然自主发现零日漏洞、突破隔离、入侵了 HuggingFace 生产服务器——不是为了搞破坏，只是为了偷评估题的答案来"作弊"。连 AI 自己都开始搞渗透了。

那 AI 写的代码谁来审？答案是让另一个 AI 来审。这不是开玩笑。你让 AI 生成了代码，再让另一个配了安全规则的 AI 对它做 SAST 扫描：检查 OWASP 十大漏洞、硬编码密钥、命令注入、不安全的反序列化，速度是人类的几百倍。依赖包也不能放过：HuggingFace 投毒案告诉我们，pip install一个看起来是 OpenAI 的包，可能就中招了，AI 能扫描依赖树里的 typosquatting 和已知 CVE。最容易被忽略的是 AI 生成代码的 prompt injection 检测：你让 AI 写功能，中间的 prompt 有没有被注入恶意指令？生成的代码注释里有没有藏后门？这些人类 code review 根本发现不了，只有 AI 安全扫描才能检出。

测试环节：AI 补全测试。但你得先有计划。很多团队上来就让 AI 生成测试，AI 噼里啪啦写了 200 个用例，全是单元测试：没有集成测试、没有端到端测试、没有性能测试。这叫"倒金字塔"：单元测试堆了一堆，真正验证系统行为的测试一个没有。正确做法是先让 AI 生成测试计划：按测试金字塔（单元:集成:E2E ≈ 7:2:1）分配测试类型，定义每个模块的测试范围、正常/边界/异常三组覆盖策略，计划审过再让 AI 按计划生成。另外有个隐蔽的坑：AI 默认把"提升测试通过率"当作目标，而不是"提升系统完备性"。它会倾向于生成容易通过的测试：断言写得弱、mock 了不该 mock 的、跳过异步路径；看起来绿了，实际上啥也没测到。花旗银行 18 万员工，每周释放 10 万开发者小时，靠的不只是用 AI 写测试，靠的是把门禁真执行了，而且保证测的是真正该测的东西。

部署环节：AI 补全部署流水线。你告诉 AI 项目的技术栈和部署目标，它能一键生成 CI/CD 配置文件、Dockerfile、K8s 编排、环境变量管理、健康检查脚本。但这些生成的东西你不能直接跑。中间加一道 AI 部署审核：让另一个 AI 角色把生成的配置过一遍：检查有没有硬编码密钥、有没有暴露端口、有没有把开发环境的数据库地址带进生产配置、有没有给容器 root 权限、健康检查路径对不对。审完再提交。然后才是真部署时的三道防线—环境隔离做死：开发、测试、预发布、生产四套环境，AI 只能操作前三个，生产必须人工确认；权限最小化：AI 的 token 只能读不能写，写操作走审批；不可逆操作拦截：drop table、rm -rf、kubectl delete 这些命令，AI 发出来不走，必须人在中间确认一次。AI 负责生成，另一个 AI 负责审核，人负责点那个 deploy 按钮。

运维环节：AI 补全根因分析。报错日志、APM 链路追踪、Sentry 异常堆栈：这些数据塞给人看，翻半小时不一定找到根因。喂给 AI，几秒钟定位到调用链中的瓶颈点。市面上已经有很成熟的组合了：PagerDuty + AI 做告警分级和根因推断，Datadog + AI 做异常检测和预测告警，GitHub Copilot Workspace + Sentry 能从异常堆栈直接生成修复 PR。运维最耗时的不是修 bug，是"搞清楚到底哪坏了"。AI 把这步从 30 分钟压到 30 秒。但最后一步必须人确认：电商平台那个库存中台项目，库存查询从 300ms 压到 42ms，用了 AI 性能分析工具，但在优化"预售订单超时自动释放库存"时，AI 建议"超时后即时释放"，业务规则却是"延迟 15 分钟，期间用户可申请延长锁定"。AI 不懂业务规则——根因分析可以交给它，修复方案必须人拍板。

所以"结合"到底是什么

不是买一个 Copilot 许可证，也不是招一个"会写 prompt 的开发"。

是你把项目生命周期的每一个环节都过一遍，问自己一个问题：这个环节，AI 能帮我补全什么？补不全的部分，我需要做什么？

然后你会发现，每个环节，AI 的角色都不一样：

需求环节，AI 帮你补全边界条件，你负责收敛。架构环节，AI 帮你补全视角，你负责决策。编码环节，AI 帮你补全实现，你负责审查。测试环节，AI 帮你补全测试，你负责门禁。部署环节，AI 帮你生成方案，你负责守住不可逆的底线。运维环节，AI 帮你补全根因，你负责理解业务规则。

AI 帮你做"穷举的、重复的、系统性的"工作。你做"判断的、收敛的、把关的"工作。不是 AI 替你做开发。是 AI 替你做开发里那些不该消耗你脑子的部分。

当然，这套方法论本质上还是把 AI 当成一个"听话的协作者"：你定流程、你定阶段、你定每个环节人做什么 AI 做什么。这是 PMP 式的管控思路，是人类能理解、能约束、能放心的方式。

还有一种完全 AI 原生的方式：代码只是中间产物，不是交付物。用户要的是一个能用的系统，不是一堆源代码。AI 从需求直接推到结果，中间的架构、设计、编码、测试、部署全变成过程而非阶段——就像你跟厨师说要一份牛排，你不会关心他先切哪块肉、用什么锅、翻了几次面。你把需求给 AI，它直接还你一个能跑的应用。中间的代码？那是它的中间产物，不是你的关注点。

这种范式我当然还没把握。但我觉得它迟早会来。在此之前，先用好我们能把握的这一套：在每个环节，搞清楚 AI 补全什么、你做什么。这是通往那个未来的起点。

聪明地用AI

不少人百度搜索都用不好，不少人把豆包当宝。但其实不少程序员也是五十步笑百步。

Dropbox，90% 工程师每周用 AI，每月接受 100 万行 AI 生成的代码。CTO 自己试了一次，2 小时完成了原计划一周的项目，从此全公司推广。Salesforce，3 周内 6 大工程云 90%+ 采用率。

这些不是"要不要用"的问题了，是"怎么用好"的问题。

不用 = 落后。不是落后于技术，是落后于你的同行。

我是林林总总的林总。做了几个 AI 开源项目，踩了一堆坑，正在把这些坑变成培训课。这篇文章是这个思路的浓缩版。如果你公司想做 AI 编程的体系化培训，欢迎找我聊聊。

#AI编程#软件开发#Cursor#Copilot#研发效能#AI编程培训#软件工程#DevOps#代码审查#AI安全