---

开篇先定义清楚：本文的「70%」指需要手动编写（非自动生成）的业务代码中，AI（Claude Code）直接生成或辅助生成的比例。总代码量 2.5万行，其中 Prisma Client 和 shadcn/ui 这类工具自动生成的占 35%（8750行），不在统计范围内。剩下的 1.6万行业务代码里，AI参与了约 1.1万行——70%。下面每一节都是基于这个口径。

目录：

1. 逐模块数据
2. AI vs 人工：四类代码的边界
3. AI 擅长的：写了就能用
4. 只有人能做的：架构决策与 Bug 修复
5. 时间账：AI 让总工期缩短了多少
6. AI 代码的四种隐性成本
7. AI 时代，哪些技能在涨价，哪些在打折
8. 新手 vs 资深：两套使用策略
9. 标准 Prompt 模板
10. AI 代码的安全风险
11. 常见问题

---

1. 逐模块数据：AI 到底参与了哪些代码

以下是志趣社区各模块的 AI 参与度。每个模块标注了代码行数，方便判断这个百分比的"体重"：

模块	该模块总行数	AI 参与度	原因
Docker/Nginx 配置	~180	95%	模式固定，AI 比人记得全
数据库迁移 SQL	~100	90%	触发器语法、索引参数，查文档不如问 AI
Controller 层	~1200	80%	标准 CRUD，改 entity 名就行
Service 基础 CRUD	~2500	70%	Prisma 查询 + DTO 校验组合
前端页面组件	~3500	60%	UI 布局 AI 擅长，状态管理我主导
类型定义/DTO	~800	50%	Prisma 自动生成的不算，自定义的 AI 辅助
Service 复杂逻辑	~1200	30%	精选算法评分公式、评论树构建——需要我设计
反爬/安全中间件	~400	20%	安全逻辑必须先自己想清楚
Bug 修复（累计）	~900	5%	几乎纯人工，AI 只能辅助定位

为什么 Bug 修复 AI 参与度这么低？ 不是 AI 不会修——是 AI 不知道你的系统里哪个文件、哪行代码有问题。你给它一个错误堆栈和上下文，它能给出修复方案。但"从用户反馈到定位根因"这个环节，AI 帮不上忙。

---

2. AI vs 人工：四类代码的边界

这篇说的 70% 只统计了"需要写"的代码。以下是四类代码的定义和实际例子：

类别	例子	算不算"AI写了"	占总量
工具自动生成	npx prisma generate 输出、npx shadcn-ui add 组件	❌ 不算	35%
AI 生成	AI 写了全部逻辑，我只改环境变量	✅ 算	28%
AI 辅助	AI 写骨架，核心逻辑我改	✅ 算	28%
人工编写	完全自己写	❌ 不算	9%

一句话总结：工具自动生成的不算。剩下需要动脑动键盘的代码里，AI 干了 70%。

---

3. AI 擅长的：写了就能用

这些代码的共同特征：有标准答案，全世界有 100 万个人写过类似的东西。

Dockerfile（AI 生成，95% 参与度，~100 行）：

AI 写的多阶段构建 Dockerfile，只改了两个环境变量名：

# AI 生成的 — 我改了两行：端口号 4000 和 appuser uid 1001
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --legacy-peer-deps
COPY . .
RUN npx prisma generate && npm run build

FROM node:20-alpine AS production
RUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001 -G appgroup
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/prisma ./prisma
USER appuser
EXPOSE 4000
CMD ["node", "dist/main.js"]

Prisma 迁移 SQL（AI 生成，90% 参与度，32 行）：

-- AI 写的 searchVector 触发器 + GIN 索引 + 回填，32 行，零修改
CREATE OR REPLACE FUNCTION update_search_vector() RETURNS trigger AS $$
BEGIN
    NEW."searchVector" := to_tsvector('chinese', COALESCE(NEW.title, '') || ' ' || COALESCE(NEW.content, ''));
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_search_vector
    BEFORE INSERT OR UPDATE ON "Post"
    FOR EACH ROW EXECUTE FUNCTION update_search_vector();

CREATE INDEX idx_post_search ON "Post" USING GIN ("searchVector");

-- 回填历史数据
UPDATE "Post" SET "searchVector" = to_tsvector('chinese', COALESCE(title, '') || ' ' || COALESCE(content, ''));

---

4. 只有人能做的：架构决策与 Bug 修复

案例一：评论系统重构（人工，~200 行）

根因：CommentTree 组件里所有评论共享 replyText 和 submitting 状态。评论 A 的回复会污染评论 B 的表单。

❌ AI 写的 v1 架构：
CommentTree（全局状态 replyText, replying, submitting）
  ├── render(c1)  → 使用全局 replyText
  ├── render(c2)  → 使用全局 replyText ← 同一个变量！
  └── render(c3)  → 使用全局 replyText

✅ 我改的 v3 架构：
CommentTree（无回复状态）
  ├── CommentItem c1 → 自己管自己的 replyText, submitting
  ├── CommentItem c2 → 自己管自己的 replyText, submitting
  └── CommentItem c3 → 自己管自己的 replyText, submitting

这个重构的核心是架构决策——“状态应该隔离到每个评论组件”，不是代码量。AI 可以写出 CommentItem 组件，但判断"什么时候该拆"是我做的。

Claude Opus 这类复杂推理模型可以参与简单架构梳理，比如「这个文件有哪些可以拆分的职责」，但最终决策——拆不拆、怎么拆、会不会引入新问题——需要开发者自己权衡。

案例二：HTTP 异常过滤器崩溃（Bug 修复，3 行代码，30 分钟排查）

排查路径（人做）：
错误日志 "ERR_HTTP_HEADERS_SENT" 
  → NestJS 什么情况下会重复发响应？ 
  → 翻 interceptors 和 filters 的执行顺序
  → 发现 ScrapingDetection 返回 429 后，HttpExceptionFilter 又尝试 response.json()
  → headersSent 已经是 true → 抛未捕获异常 → Node.js 进程崩溃

修复（AI 辅助）：
if (response.headersSent) return; // 就这一行

AI 在这里帮了什么？我给它看了错误堆栈和 ScrapingDetection 代码，它帮我确认了"拦截器在过滤器之前执行"。但它不可能自己发现这个 Bug，因为它不知道 ScrapingDetection 和 HttpExceptionFilter 之间的调用顺序冲突。

---

5. 时间账：AI 让总工期缩短了多少

功能	手写预估	AI 辅助实际	节省
Docker 环境搭建	4h	30min	87%
Nginx 配置	3h	20min	89%
JWT 认证 + 2FA	8h	3h	63%
帖子 CRUD + 校验	6h	1.5h	75%
全文搜索迁移	3h	30min	83%
通知系统	5h	2h	60%
评论系统	10h	4h	60%
精选算法	—	3h	纯人工
反爬中间件	—	2.5h	纯人工
23个Bug排查	—	~15h	纯人工
合计	~44h	~32.5h	~26%

为什么"写"快了 70%，总工期只缩短了 26%？

因为 32.5 小时的时间分布是这样的：

写代码:        ██████████ 12h（37%）—— 这部分 AI 加速了 ~70%
调试 Bug:      ████████    9h（28%）—— 几乎没加速
架构设计:      ██████      6h（18%）—— 没加速
写文章/文档:   ████        4h（12%）—— AI 辅助
其他:          █           1.5h（5%）

AI 加速了 37% 的工作，但这部分工作的速度提升没法等比转化为总工期缩短。

以上时间数据来自单人项目，不代表团队协作或多模块项目的效果。

---

6. AI 代码的四种隐性成本

成本一：审查时间

AI 生成 100 行，我需要 2-3 分钟审查。1.1 万行 AI 代码，审查花了约 3.5 小时。这个时间会计入 AI 的总成本，而不是节省。

成本二：过度自信的 Bug

真实案例 — 分页 NaN Bug：

❌ AI 写的：
skip: (page - 1) * pageSize
// 当前端没传 page 参数时：page = undefined
// (undefined - 1) * 50 = NaN → Prisma 抛 500

✅ 修复后：
const safePage = Math.max(1, Number(page) || 1);
skip: (safePage - 1) * pageSize

AI 的代码不会在不确定的地方加防御性校验。它相信函数签名里 page: number = 1 就能拦截 undefined——但实际上 @Query('page') 传进来的是 NaN，TypeScript 的默认值不管用。

真实案例 — Prisma N+1 查询：

❌ AI 写的：
const posts = await prisma.post.findMany();
for (const p of posts) {
  p.author = await prisma.user.findUnique({ where: { id: p.authorId } });
}
// 100 篇帖子 = 101 次数据库查询

✅ 人工优化：
const posts = await prisma.post.findMany({ include: { author: true } });
// 100 篇帖子 = 1 次数据库查询

AI 不会自动帮你做 include 优化，因为它"看"不到数据库查询次数。

成本三：理解断层

AI 帮你写完了代码，跑通了。三天后改逻辑，盯着屏幕 20 分钟不知道从哪下手。AI 替你做了理解工作，但理解没有被转移到你的脑子里。

成本四：代码风格不统一

一个 AI 写的异常过滤器用 try-catch，另一个 AI 写的拦截器用 .pipe()。30 天后的代码库像 3 个人写的。解法：每次 AI 生成后用统一指令重写——“用跟 comments.service.ts 一样的错误处理方式重写这个”。

额外成本（未在本文时间统计中计入）：

• AI API 调用费用（本项目约 $35/月）
• AI 生成的代码在后续迭代中的重构成本（当需求变化时，AI 代码的重构比手写代码更难，因为你不完全理解它）
• 上下文窗口限制（项目变大了之后，不能把所有代码一次性喂给 AI）

---

7. AI 时代，哪些技能在涨价，哪些在打折

在涨价（更需要了）：

技能	涨幅	为什么
代码审查	↑↑↑	你现在每天审查的代码量是以前的 3-5 倍
需求拆解	↑↑↑	能把模糊需求翻译成 AI 能执行的精确指令
调试能力	↑↑	AI 写 Bug 的方式跟人不一样，更难排查
技术写作	↑↑	文档和注释现在比代码本身更重要

在打折（AI 能替代大部分）：

技能	折扣	为什么
记忆 API 语法	↓↓	AI 比你记得全
写标准 CRUD	↓↓↓	AI 比你快 10 倍
写配置文件	↓↓↓	Docker/Nginx/K8s config AI 不会忘
写 SQL 迁移	↓↓	触发器语法、索引参数，AI 比人熟

以上变化幅度仅基于后端开发视角。前端、测试、运维等岗位的技能变化可能有不同的侧重点。

---

8. 新手 vs 资深：两套使用策略

新手（1-3 年经验）：

不要照搬"让 AI 写 70% 代码"的策略。

新手最大风险：AI 写出了能跑的代码 → 你以为懂了 → 实际没懂 → Bug 炸了不知道怎么排查。

建议策略：

• AI 参与度控制在 30-40%
• 让 AI 写配置文件、数据迁移、测试用例——这些适合新人理解
• 核心业务逻辑必须自己写，至少要自己设计架构
• 每个 AI 写的模块，花 20 分钟读相关文档（不是 10 分钟）
• 先学会不用 AI 排查 Bug，再用 AI 辅助排查

资深（4 年+）：

可以像本文一样把 AI 参与度提到 70%。但注意：

• 审查时间不会减少——你还是需要逐行看 AI 的代码
• 你省的是"写"的时间，不是"想"的时间
• 架构决策权永远在自己手里

---

9. 标准 Prompt 模板

以下是我摸索出来的三个高频场景 Prompt 模板：

模板一：写新功能

你是一个 NestJS + Prisma 后端开发者。项目使用 TypeScript 严格模式。

现有代码的风格参考（附上类似功能的文件路径）：
- Controller 用 @Controller 装饰器，返回 { code, message, data } 格式
- Service 用 @Injectable()，错误处理与 comments.service.ts 一致
- DTO 用 class-validator 装饰器

请实现以下功能：
[描述功能]

要求：
1. 所有参数加校验（class-validator）
2. 数据库查询用 include 避免 N+1
3. 错误情况返回明确的错误码和用户可读的消息
4. 不要使用 any 类型

模板二：排查 Bug

以下代码在生产环境中出现 [描述错误现象]。

错误日志/堆栈：
[粘贴日志]

相关代码（附上文件内容）：
[粘贴代码]

请分析：
1. 可能的根因（列出 2-3 个最可能的原因）
2. 每个原因需要什么额外信息来确认
3. 修复方案（给出可用的代码）

模板三：代码审查

审查以下代码，从这几个角度给出意见：
1. 安全性：有没有 SQL 注入、XSS、越权风险
2. 性能：有没有 N+1 查询、不必要的循环、大对象拷贝
3. 错误处理：异常情况是否都被覆盖了
4. 可读性：变量命名、函数长度、注释质量
5. 与项目现有代码风格的一致性

代码：
[粘贴代码]

---

10. AI 代码的安全风险

AI 生成的代码可能存在以下安全隐患，不能只靠"审查"：

SQL/Nosql 注入：AI 可能写出拼接 SQL 而非使用参数化查询的代码。Prisma 天然防注入，但如果 AI 写了 $queryRawUnsafe，必须人工验证输入是否来自用户。

Nginx 配置暴露：AI 给的 Nginx 配置可能遗漏安全头、或者 proxy_pass 配置不当导致后端 IP 泄露。

敏感信息泄露：AI 生成的日志代码可能打印用户输入或 Token——确保日志里有脱敏。

解决方案：

1. ESLint + SonarJS 自动扫描安全规则
2. Prisma 禁止 $queryRawUnsafe 的使用（或加 // security-reviewed 注释强制人工审查）
3. CI 中跑 npm audit 和 Snyk 安全扫描

---

11. 常见问题

Q: AI 能帮我做架构设计吗？

部分能。如果你给 Claude Opus 或 GPT-5 看你的项目结构和需求，它能给出合理的架构建议（如"这个模块应该拆分成两个 Service"）。但它不知道你的团队能力、历史债务、以及哪些设计限制是"故意的"而非"疏忽"。所以最终决策还是你做。

Q: AI 写的代码有版权问题吗？

目前法律灰色地带。GitHub Copilot 曾被起诉使用 GPL 代码训练模型。如果你用 AI 生成的代码部署到商业产品，建议：1）不要让 AI 逐行复制已知开源项目的代码；2）关键的差异化逻辑自己写；3）关注你使用的 AI 工具的服务条款中对"生成代码所有权"的声明。

Q: 团队协作中怎么用 AI？

团队引入 AI 辅助开发时，关键是统一三个东西：1）统一的 Prompt 模板，保证代码风格一致；2）统一审查标准——AI 写的代码必须通过和人类代码一样的 CI 检查；3）PR 里标注"AI 辅助生成"的标签，让 reviewer 知道该用什么标准来看这段代码。

Q: 你怎么选择用哪个 AI 工具？

我的组合：Claude Code 写代码（最擅长 TypeScript+NestJS）、Cursor 做编辑器内的轻量补全、DeepSeek API 处理批量文本任务（便宜 62 倍）。如果你只选一个，Claude Code 或 Cursor 都可以——关键是深入用一个月，摸清它的边界再扩展。

---

AI 写了我 70% 的代码。但它没有做任何一个架构决策、没有排查任何一个生产 Bug、没有在设计评论系统时考虑"状态隔离"。

它让我更快地到达了"需要做决策"的时刻。多出来的时间，我用来做只有人能做的事。

如果一个开发者只会写 AI 能写的代码，那他确实该焦虑。如果一个开发者能做 AI 做不了的判断，那 AI 就是他最好的工具。

你属于哪一类？

---

本文基于志趣社区（zhiqu.ac）开发 30 天的真实统计。数据来自单人全栈项目，不代表所有场景。你的体验可能完全不同——欢迎来社区分享。