AI 辅助开发的工程化边界: 哪些交出去, 哪些必须自己来

2025 年起主力用 AI 辅助开发,工具栈从 GitHub Copilot 到 Cursor,大模型从 GPT 到 GLM、DeepSeek。这篇不讲”AI 多神奇”,讲在工程链路里怎么把 AI 用到位,以及它的真实边界——哪些活交出去更高效,哪些必须自己来。

一、工具栈分工: 各家定位不同

不是”用一个 AI 干所有事”,不同工具擅长不同:

• GitHub Copilot:行内补全最强,写样板代码时挂着就行
• Cursor:多文件 edit + 全项目 context,重构和跨文件改动主力
• GPT:开放性提问、方案设计、调试思路,适合”我不知道怎么搞”的探索
• GLM / DeepSeek:中文场景、代码 + 中文混合任务,响应快成本低

日常链路:Copilot 补全 + Cursor 重构 + GPT/GLM 探索方案。不是替代关系,是分工——每个工具用它最擅长的环节,链路串起来才提效。

二、AI 在工程链路里的三个嵌点

1. 重构: AI 提案 + 人审

重构最适合交 AI。把一段函数丢给 Cursor,让它给重构方案。但关键是”提案 + 人审”——AI 给的方案常常对一半,边界条件、命名、性能要人审。

Prompt 要点:说清意图,不说步骤。说”把这个 300 行的渲染函数拆成职责单一的子函数,保持行为不变”,不说”先提取变量再…”。意图对,AI 自己拆;步骤错了,反而把它带偏。

2. 测试: AI 生成用例 + 人补边界

AI 生成测试用例很快,但边界常常漏。它生成的 happy path 多,边界(空值 / 并发 / 超时 / 错误传参)少。

实践:让 AI 生成基础用例,人补边界和业务特定异常。AI 写”这个函数正常返回”,人加”并发两次会怎样""传 null 呢""业务上限超了怎么走”。AI 给的是骨架,边界靠人补。

3. 文档: AI 起草 + 人校准

文档起草交 AI 最省时间。但 AI 写的文档常常”对但虚”——每句都对,合起来没信息量。

实践:AI 起草框架和初稿,人校准加业务上下文和取舍说明。API 文档 AI 能写八成,架构决策文档 AI 只能写骨架,取舍理由必须人写——因为 AI 不知道你为什么这么选。

三、边界: 哪些必须自己来

AI 强在”已知的重复”,弱在”未知的判断”:

• 架构决策:用哪个状态管理、要不要抽组件库、性能和可维护性怎么权衡——AI 给建议,但决策和后果是你的
• 业务逻辑:业务规则的边界、特殊 case,AI 不知道业务,写出来像对但跑挂
• 性能权衡:AI 给的方案常常不是最优,它倾向”能跑”的通用解,性能瓶颈要人 profile 后定位
• Code Review 校验:AI 产出要像 review 人代码一样 review,不是直接 accept

铁律:AI 产出是”草稿”,不是”答案”。任何 AI 写的代码上线前,要像 review 初级同事代码一样 review——能跑不代表对,对不代表符合业务和性能要求。

四、Prompt 工程的几个实操点

• Context 要给够:Cursor 的 @file @symbol 把相关文件喂全,否则它瞎猜
• 意图 > 步骤:说清要什么效果,不教 AI 怎么做,它自己拆步骤
• 小步迭代:不一次性要大改,分小步每步验证,错了立刻回退
• 反例驱动:让 AI 列”这个方案哪里可能出问题”,它能找出自己方案的盲点

五、反思: AI 替代不了什么

用了一年多,AI 把我的样板代码时间砍掉大半,测试和文档起草也快很多。但它替代不了两件事:

1. 知道要做什么:AI 写得好,前提是你知道要什么。问不出好问题,AI 给不出好答案
2. 知道什么对:AI 产出多,哪个对、哪个符合业务、哪个性能好,判断在人

工程师的价值在从”知道怎么写”上移到”知道写什么、知道什么对”。AI 时代不是不需要工程师,是不需要”只会写、不会判断”的工程师。

小结

AI 辅助开发的工程化,不是”用上 AI”,是”把 AI 嵌进链路 + 守住边界”。重构 / 测试 / 文档交 AI 提效,架构决策 / 业务逻辑 / 性能权衡 / Review 校验自己来。工具分工而非替代,产出当草稿而非答案。这是 2026 年一个工程师的 AI 工作流——也是这个博客本身就在用 AI 辅助维护的原因。