AI 原住民开发者：当编程遇上大模型

一个全栈工程师的 AI 辅助开发实践：工作流、边界、思考，以及为什么 Prompt Engineering 是新时代的必修课。

开场：一个普通工作日的变化

两年前，我遇到一个不熟悉的 API 报错，第一反应是打开 Google，翻 Stack Overflow，看文档。

现在，我直接把错误信息丢给 Claude，附上相关代码上下文，30 秒内拿到可能的原因和修复方案。

这不是什么革命性的宣言，只是一个事实：开发者的信息获取方式，已经从”搜索-筛选-拼接”变成了”描述问题-获得方案-验证执行”。

我的 slogan 是 “I ship code that thinks”。不是说代码会思考，而是在写代码的每一步，都有一个能思考的 AI 在旁边。这篇文章记录的，是我作为一个 AI 原住民开发者的真实工作方式。

一、工作方式的根本转变

从搜索到对话

传统开发流程中，“查资料”占据了大量时间。你需要：

把问题抽象成关键词
在搜索结果中筛选有效信息
从多个来源拼接出解决方案
适配到自己的代码上下文

现在这个过程被压缩了。你可以直接用自然语言描述问题，附上代码片段，AI 会基于你的具体上下文给出建议。

// 以前：Google "typescript generic constraint conditional type"
// 现在：直接问

Prompt: "我有一个泛型函数，需要根据传入类型是否包含 `id` 字段
来决定返回类型。怎么用 conditional type 实现？"

关键区别：搜索引擎不知道你的上下文，AI 知道。

从写代码到审代码

另一个显著变化：我写的”原始代码”变少了，但我审的代码变多了。

AI 生成代码的速度远超人类手写，但它生成的代码需要被审查。这意味着开发者的核心能力从”写出正确的代码”转向了**“判断代码是否正确”**。

这其实要求更高——你得理解代码应该怎么写，才能判断 AI 写的对不对。

二、实际工作流：我用 AI 做什么

1. 代码生成：脚手架和样板代码

最直接的场景。重复性高、模式明确的代码交给 AI：

// Prompt: "生成一个 Express middleware，
// 验证 JWT token，失败返回 401，
// 成功把 decoded user 挂到 req.user 上"

// AI 生成：
import { Request, Response, NextFunction } from "express";
import jwt from "jsonwebtoken";

interface AuthRequest extends Request {
  user?: jwt.JwtPayload;
}

export function authMiddleware(
  req: AuthRequest,
  res: Response,
  next: NextFunction
) {
  const token = req.headers.authorization?.replace("Bearer ", "");

  if (!token) {
    return res.status(401).json({ error: "Token required" });
  }

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET!);
    req.user = decoded as jwt.JwtPayload;
    next();
  } catch {
    return res.status(401).json({ error: "Invalid token" });
  }
}

这类代码我几乎不需要修改就能用。省下的时间花在业务逻辑上。

2. 调试：从症状到根因

AI 在调试场景的价值被严重低估。特别是那种”看起来应该没问题但就是不对”的 bug：

Prompt: "这段代码在并发场景下偶尔会返回错误结果。
同一个用户连续发两个请求，第二个请求有时候拿到的是第一个请求的数据。
代码如下..."

AI 通常能很快定位到 race condition 或者闭包引用问题。人眼看代码容易忽略时序问题，AI 不会。

3. Code Review：多一双眼睛

我会把 diff 丢给 AI 做第一轮 review：

Prompt: "Review 这个 PR diff，关注：
1. 是否有潜在的性能问题
2. 错误处理是否完整
3. 是否有安全风险
4. 代码风格是否一致"

AI 不会漏掉明显的问题（未处理的 null、缺失的 error boundary、硬编码的密钥），这些都是人在快速 review 时容易忽略的。

4. 文档：把代码意图翻译成人话

写文档是大部分开发者的痛点。AI 在这方面极其好用：

给函数生成 JSDoc
把代码逻辑翻译成 README
生成 API 文档
写 commit message（虽然简单，但每天省的时间加起来可观）

5. 架构设计：白板上的对话伙伴

这是我觉得最有价值但最容易被忽视的场景。

设计一个新系统时，我会把需求描述给 AI，让它列出可能的方案和 trade-off：

Prompt: "我需要设计一个消息队列消费者，要求：
- 支持重试，最多 3 次
- 失败消息进死信队列
- 消费幂等
- 单个 consumer 处理多种消息类型

给我 2-3 种设计方案，分析各自的 trade-off。"

AI 不会替你做决策，但它能快速展开选项空间，让你在更完整的信息下做判断。

三、边界和局限：AI 做不了什么

用了两年 AI 辅助开发，我对它的边界有比较清晰的认识。

幻觉（Hallucination）

这是最大的问题。AI 会非常自信地给出错误答案。

典型场景：

编造不存在的 API 或库
给出过时的用法（因为训练数据截止时间）
在复杂逻辑中悄悄引入 off-by-one 错误

应对方式：永远验证。AI 的输出是”建议”，不是”答案”。特别是涉及第三方库的 API，一定要对照官方文档。

上下文窗口

即使是最先进的模型，上下文窗口也是有限的。当你的项目有几十个文件相互依赖时，AI 无法同时理解所有代码的关系。

应对方式：

提供精确的上下文，而不是把整个项目丢进去
把大问题分解成小问题
用 AI 处理局部问题，用人脑把握全局架构

安全审计

AI 可以发现明显的安全问题（SQL 注入、XSS、硬编码密钥），但它无法替代专业的安全审计。

原因：

安全问题往往需要理解完整的攻击链
业务逻辑层面的权限漏洞，AI 很难判断
对抗性思维需要”想象攻击者会怎么做”，这需要经验

系统设计中的权衡

AI 能列出选项，但做不了最终决策。因为决策需要理解：

团队技术栈和熟悉度
业务优先级和时间约束
历史债务和迁移成本
组织架构对技术选型的影响

这些都是 AI 没有的上下文。

四、Prompt Engineering：开发者的新必修课

很多人觉得 Prompt Engineering 是玄学，是”和 AI 聊天的技巧”。

不是。它本质上是精确表达需求的能力。

好 Prompt 的特征

// 差的 Prompt
"帮我写个排序"

// 好的 Prompt
"实现一个针对大数据量（100万+条记录）的排序函数：
- 输入：对象数组，按指定字段排序
- 要求：支持多字段排序，支持升降序
- 约束：内存敏感，不能一次性加载所有数据
- 语言：TypeScript，需要类型安全
- 测试：给出边界 case 的测试用例"

你看，好的 Prompt 其实就是好的需求文档。而写好需求文档，本来就是工程师应该具备的能力。

Prompt 即接口

换个角度看：Prompt 就是你和 AI 之间的接口（interface）。

接口设计的原则在这里同样适用：

明确输入输出：告诉 AI 输入什么格式，期望什么格式的输出
约束边界：明确告诉 AI 不要做什么
提供示例：few-shot learning 本质上就是给 AI 看接口的 test case
错误处理：告诉 AI 遇到不确定的情况应该怎么做（比如”如果不确定，标注出来让我判断”）

System Prompt 是架构设计

如果你在搭建 AI 辅助工作流（比如用 Claude Code），System Prompt 的设计就是架构设计：

定义 AI 的角色和能力边界
设定输出格式和质量标准
配置错误处理策略
管理上下文优先级

这跟设计一个微服务的接口契约没有本质区别。

五、实践建议：如何开始

如果你还没有把 AI 融入日常开发，以下是我的建议：

从低风险场景开始

写单元测试
生成样板代码
重构已有代码（有测试保护的情况下）
写文档和注释

建立验证习惯

AI 生成的代码必须过脑子
涉及数据库操作、支付、权限的代码，逐行审查
跑测试，不要相信”看起来对”

投资你的 Prompt

记录有效的 Prompt 模板
迭代优化：同样的需求，试不同的表达方式
建立项目级的 AI 配置（比如 CLAUDE.md）

保持独立思考

AI 说的不一定对，你的直觉可能是对的
遇到 AI 给不了好答案的问题，说明这个问题本身有价值
不要让 AI 替你思考，让它替你执行

六、展望：不是取代，是进化

“AI 会取代程序员”这个说法，和”Excel 会取代会计”一样不准确。

更准确的表述是：会用 AI 的开发者，会取代不用 AI 的开发者。

原因很简单：效率差距会越来越大。

一个用 AI 的开发者，能做到：

更快的原型验证
更全面的 Code Review
更低的上手新技术成本
更多的时间花在真正需要创造力的地方

而”真正需要创造力的地方”才是开发者不可替代的价值：

理解业务需求背后的真正问题
在多个可行方案中做出最优权衡
设计能演进的系统架构
跨团队协作和沟通

最后

编程这件事，正在从”用代码实现需求”变成”用代码+AI 实现需求”。

工具在变，但核心能力没变：理解问题、设计方案、做出判断。

AI 是有史以来最强大的编程工具。和任何工具一样，关键不在于工具本身，而在于使用它的人。

I ship code that thinks. 你呢？