开篇先定义清楚本文的「70%」指需要手动编写非自动生成的业务代码中AIClaude Code直接生成或辅助生成的比例。总代码量 2.5万行其中 Prisma Client 和 shadcn/ui 这类工具自动生成的占 35%8750行不在统计范围内。剩下的 1.6万行业务代码里AI参与了约 1.1万行——70%。下面每一节都是基于这个口径。目录逐模块数据AI vs 人工四类代码的边界AI 擅长的写了就能用只有人能做的架构决策与 Bug 修复时间账AI 让总工期缩短了多少AI 代码的四种隐性成本AI 时代哪些技能在涨价哪些在打折新手 vs 资深两套使用策略标准 Prompt 模板AI 代码的安全风险常见问题1. 逐模块数据AI 到底参与了哪些代码以下是志趣社区各模块的 AI 参与度。每个模块标注了代码行数方便判断这个百分比的体重模块该模块总行数AI 参与度原因Docker/Nginx 配置~18095%模式固定AI 比人记得全数据库迁移 SQL~10090%触发器语法、索引参数查文档不如问 AIController 层~120080%标准 CRUD改 entity 名就行Service 基础 CRUD~250070%Prisma 查询 DTO 校验组合前端页面组件~350060%UI 布局 AI 擅长状态管理我主导类型定义/DTO~80050%Prisma 自动生成的不算自定义的 AI 辅助Service 复杂逻辑~120030%精选算法评分公式、评论树构建——需要我设计反爬/安全中间件~40020%安全逻辑必须先自己想清楚Bug 修复累计~9005%几乎纯人工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 万个人写过类似的东西。DockerfileAI 生成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 --frombuilder /app/dist ./dist COPY --frombuilder /app/node_modules ./node_modules COPY --frombuilder /app/prisma ./prisma USER appuser EXPOSE 4000 CMD [node, dist/main.js]Prisma 迁移 SQLAI 生成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 环境搭建4h30min87%Nginx 配置3h20min89%JWT 认证 2FA8h3h63%帖子 CRUD 校验6h1.5h75%全文搜索迁移3h30min83%通知系统5h2h60%评论系统10h4h60%精选算法—3h纯人工反爬中间件—2.5h纯人工23个Bug排查—~15h纯人工合计~44h~32.5h~26%为什么写快了 70%总工期只缩短了 26%因为 32.5 小时的时间分布是这样的写代码: ██████████ 12h37%—— 这部分 AI 加速了 ~70% 调试 Bug: ████████ 9h28%—— 几乎没加速 架构设计: ██████ 6h18%—— 没加速 写文章/文档: ████ 4h12%—— AI 辅助 其他: █ 1.5h5%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) * pageSizeAI 的代码不会在不确定的地方加防御性校验。它相信函数签名里page: number 1就能拦截undefined——但实际上Query(page)传进来的是NaNTypeScript 的默认值不管用。真实案例 — Prisma N1 查询❌ 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 代码的重构比手写代码更难因为你不完全理解它上下文窗口限制项目变大了之后不能把所有代码一次性喂给 AI7. 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 避免 N1 3. 错误情况返回明确的错误码和用户可读的消息 4. 不要使用 any 类型模板二排查 Bug以下代码在生产环境中出现 [描述错误现象]。 错误日志/堆栈 [粘贴日志] 相关代码附上文件内容 [粘贴代码] 请分析 1. 可能的根因列出 2-3 个最可能的原因 2. 每个原因需要什么额外信息来确认 3. 修复方案给出可用的代码模板三代码审查审查以下代码从这几个角度给出意见 1. 安全性有没有 SQL 注入、XSS、越权风险 2. 性能有没有 N1 查询、不必要的循环、大对象拷贝 3. 错误处理异常情况是否都被覆盖了 4. 可读性变量命名、函数长度、注释质量 5. 与项目现有代码风格的一致性 代码 [粘贴代码]10. AI 代码的安全风险AI 生成的代码可能存在以下安全隐患不能只靠审查SQL/Nosql 注入AI 可能写出拼接 SQL 而非使用参数化查询的代码。Prisma 天然防注入但如果 AI 写了$queryRawUnsafe必须人工验证输入是否来自用户。Nginx 配置暴露AI 给的 Nginx 配置可能遗漏安全头、或者proxy_pass配置不当导致后端 IP 泄露。敏感信息泄露AI 生成的日志代码可能打印用户输入或 Token——确保日志里有脱敏。解决方案ESLint SonarJS 自动扫描安全规则Prisma 禁止$queryRawUnsafe的使用或加// security-reviewed注释强制人工审查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 检查3PR 里标注AI 辅助生成的标签让 reviewer 知道该用什么标准来看这段代码。Q: 你怎么选择用哪个 AI 工具我的组合Claude Code 写代码最擅长 TypeScriptNestJS、Cursor 做编辑器内的轻量补全、DeepSeek API 处理批量文本任务便宜 62 倍。如果你只选一个Claude Code 或 Cursor 都可以——关键是深入用一个月摸清它的边界再扩展。AI 写了我 70% 的代码。但它没有做任何一个架构决策、没有排查任何一个生产 Bug、没有在设计评论系统时考虑状态隔离。它让我更快地到达了需要做决策的时刻。多出来的时间我用来做只有人能做的事。如果一个开发者只会写 AI 能写的代码那他确实该焦虑。如果一个开发者能做 AI 做不了的判断那 AI 就是他最好的工具。你属于哪一类本文基于志趣社区zhiqu.ac开发 30 天的真实统计。数据来自单人全栈项目不代表所有场景。你的体验可能完全不同——欢迎来社区分享。