Vibe Coding时代的自我鞭策

AI编程时代下你的优势到底是什么

灵魂拷问: 在 vibe coding 盛行以及基模越来越强的当今，你觉得你的优势是什么？

如果你还在说: "AI处理不了复杂的业务逻辑"、"AI写不了安全代码"、"AI处理不了并发" --- 都2026年了，AI这些都做的很好

Claude Code 能写出带完整异常处理的微服务调用、Codex能处理复杂的状态机逻辑、Cursor能一次改十几个文件还不乱。

继续说"AI做不了这个"，面试官只会觉得你脱离实际或者你根本不懂

那么回归正题，在AI编程能力如此强大的当下，我们应该聚焦的实操问题是什么呢？---Token成本怎么控制、AI代码怎么管、效果怎么评估

Vibe Coding 是什么

定义: 不审查、不理解、直接 Accept AI生成的代码

维度	Vibe Coding	AI辅助编程
代码生成	AI生成	AI生成
代码审查	不审查，直接Accept	逐行审查
报错处理	粘贴给AI	分析根音再处理
对代码负责	不负责	完全负责

问你是不是在 Vibe Coding ，其实本质上是在问: 你对Accept的代码负不负责

AI能力越来越强，你的优势是什么

首先我们要承认一个事实，那便是 AI现在确实写的很好

• 复杂业务逻辑？给够上下文，能写出符合公司规则的结算代码
• 安全代码？告诉它要注意什么，能写出带输入校验和权限检查的代码
• 跨模块调用？把接口文档喂给它，它能生成正确的调用链路
• 性能优化？让他关注性能，它能帮你找出各种无效re-render或内存泄漏。

如果还停留在AI做不了什么，那你需要思考一个问题，你给够上下文了吗？

那么我们的优势到底在哪？不是AI做不了什么，而是AI做什么都需要你先做对什么？

问题定义能力

AI能解决你定义好的问题，但定义问题本身就是最难的部分

我知道这里可能有人要喷了，ClaudeCode哪怕你说不清楚也能解决bug，那么我的问题是，你经历了几轮对话、花费了多少Token、浪费了多少时间。。。

PD说在这里加一个"退款按钮" --- 这不是需求，这是一句话。真正的需求定义要回答:

• 部分退款怎么处理？
• 多次退款的幂等怎么保证
• 退款超时如何自动关闭

这些问题的答案，AI不知道，PD也没说清楚。最终是你把一句话变成了可执行的规则，AI才能写出正确的代码

反过来，如果你自己都没想清楚，AI写出来的代码一定是模糊的 --- 你给他一句话，他给你一个"看起来像那么回事"的接口，能跑但逻辑经不起推敲。

AI很强，但它需要精确的问题定义。我们的优势在于能把模糊的需求拆解成清晰的技术规格 --- 边界条件、异常处理、业务规则，这些AI不会主动问你，但不说清楚代码一定写不对。

上下文构建能力

AI的输出质量，直接取决于你给的上下文质量

以升级高德地图SDK为例，两种人用AI

• A说: 将地图SDK升级到2.0 -> AI凭借WebSearch工具检索代码中使用到的地方替换成2.0
• B给了项目完整的使用路径、Api使用文档、升级注意事项 -> 基本能跑

差距在哪？不是AI的能力差异，是喂给AI的上下文质量的差距

• 知道给什么: 哪些东西是AI必须知道的，哪些是噪音
• 知道不给什么: 塞十万行无关代码进上下文，浪费token又干扰模型
• 知道怎么组织: 先给背景再给需求和先给需求再给背景，效果完全不一样

同样使用CC，不同人产出质量差很多。差别在于上下文构建 -- 我给AI的Prompt包含完整的业务规则、相关代码和边界条件，而不是一句话就让他写。AI的上限是由你的输入质量决定的。

结果验证能力

代码跑起来 ≠ 代码对了

很多时候会出现，看着对、跑得通、但语义是错误的。例如:

• 升级高德地图SDK后，定位回调函数签名变了，AI用旧签名写的代码能编译通过，但运行时拿到的经纬度永远是0
• 新版SDK废弃了 AMapLocationClient.setLocationOption()，AI自动替换成了 setLocationParams()，方法存在且不报错，但少传了一个精度参数，导致定位精度从10米退化到500米
• SDK升级后坐标系从 GCJ-02 默认变成了 WGS-84，AI生成的代码没做坐标转换，地图上标点全部偏移了几百米，功能正常、地图正常渲染，但位置全是错的

这些问题跑测试不一定能发现，因为测试是按照你的预期写的，而你的预期和业务需求有偏差

验证能力不是"跑一下是否报错"，而是

• 业务语义验证: 这段代码的行为是否符合业务意图
• 边界验证: 极端情况下的行为是否符合预期
• 回归验证: 这次改动有没有影响其他功能

特别要注意AI的"合理但错误"代码 --- 逻辑通顺、能跑通，但语义和业务需求不一致。这种代码最容易通过cr，因为看起来真像回事。

技术决策能力

AI能列出方案A、B的pros/cons，但拍板选哪个是你决定的

技术决策包括:

• 选型决策: 用 redux还是zustand？用 react-query 还是 useRequest？AI能分析，但你的业务场景只有你知道
• 架构决策: 拆微应用还是模块联邦？同步还是异步？短期交付还是长期运维？
• 成本决策: 花 3 天重构还是花3个月重构？模型选择贵的还是便宜的？

AI的建议是通用的，你的决策是具体的。通用建议和具体场景之间，永远需要人来判断

举个例子: 你问AI"React项目用什么状态管理库"，AI大概率推荐 Zustand 或 Redux Toolkit，给你列一堆优缺点对比。但它不知道的是：你做的是一个多人协同编辑的B端表单系统，状态需要跨 Tab 同步、支持撤销重做、还要和后端 WebSocket 实时对账。这个场景下真正该用的可能是 XState 状态机 + CRDT，而不是任何一个"通用状态管理库"。AI的推荐在技术社区是对的，但放到你的业务里是错的。

AI能帮我分析方案，但最终的选型决策是我做的。因为决策要考虑的不仅是技术因素，还有团队现状、业务阶段、历史教训等等 -- 这些AI不知道，也不应该由AI来决定。

成本控制能力

AI编程不是免费的

一次CC的交互，可能消耗 几万甚至几十万 Token，一个项目跑下来甚至比工程师工资还高。。。

成本控制能力包括:

• Token成本控制知道什么时候用大模型，什么时候用小模型
• 知道怎么组织上下文才省Token
• 知道怎么写Prompt才能减少来回次数
• 知道哪些任务让AI做更贵，自己做更便宜

五大优势总结

AI的输出质量取决于你的输入质量--定义问题、构建上下文、验证结果、做决策、控成本，这五件事AI代替不了你

不是AI做不了，是AI做什么都需要你先做对！

• AI做不了的潜台词是: 等AI能做了，你就没优势了
• AI需要你的潜台词是: 只要AI还需要人来驱动，你的优势就在

前者是防守型思路，越守越窄；后者是驱动型思路，越用越强

graph LR A["模糊需求\n一句话描述"] --> B["问题定义\n拆解边界和规则"] B --> C["上下文构建\n给对信息,不给噪音"] C --> D["AI 生成"] E["成本控制\n省Token,更高效"] -.-> D D --> F["结果验证\n跑通 ≠ 对了"] D -.-> G["技术决策\n你拍板,AI执行"] G -.-> F F --> H["高质量代码\n业务语义正确"] style A fill:#ffe0e0,stroke:#ff6b6b style B fill:#e0e8ff,stroke:#6b8cff style C fill:#e0e8ff,stroke:#6b8cff style D fill:#3b5998,color:#fff,stroke:#3b5998 style E fill:#ffe0f0,stroke:#ff6bb5 style F fill:#e0ffe0,stroke:#4caf50 style G fill:#fff3e0,stroke:#ff9800 style H fill:#e0ffe0,stroke:#4caf50

AI编程工具的Token成本怎么节省

这个问题越来越被关注，这也是团队用AI编程最实际的问题

不控制成本，一个月账单可能比工程师工资还高。控制的太狠，AI产出质量又下降。关键在于成本和质量之间找到平衡点

策略一: 模型路由 -- 什么活用什么模型

不是什么活都需要用最强的模型来处理，根据任务复杂度拆分到不同模型。

任务类型	推荐模型级别	原因
代码补全、简单修改	小模型	速度快、成本低、够用
函数实现、Bug修复	中模型	平衡成本和质量
完整功能实现	大模型	模型质量高、速度慢
架构设计、复杂重构、代码审查	大模型	需要深度推理
代码解释、文档生成	小模型	不需要强推理

成本差距有多大？ 大模型的输出价格是小模型的近 20 倍。如果一个 70% 的任务能用小模型解决，整体成本能降 60% 以上。

graph LR A["代码补全"] --> D["模型路由"] B["函数实现 / Bug修复"] --> D C["架构设计 / 复杂重构"] --> D E["文档生成"] --> D D --> F["小模型<br/>快 / 便宜 / 够用<br/>输出价格: 1x"] D --> G["中模型<br/>平衡成本和质量<br/>输出价格: ~4x"] D --> H["大模型<br/>强推理 / 贵<br/>输出价格: ~20x"] style A fill:#f0f0f0,stroke:#999 style B fill:#f0f0f0,stroke:#999 style C fill:#f0f0f0,stroke:#999 style E fill:#f0f0f0,stroke:#999 style D fill:#1a4a9e,color:#fff,stroke:#1a4a9e style F fill:#e0ffe0,stroke:#4caf50 style G fill:#e0e8ff,stroke:#6b8cff style H fill:#ffe0e0,stroke:#ff6b6b

总结: 做了模型路由策略 -- 简单补全用小模型，复杂任务采用大模型。70%的日常编码任务其实不需要最强模型，这样整体Token成本可以降低50%以上。

策略二: 上下文管理 -- 别把整个代码仓库丢进去

上下文窗口是Token消耗的大头

在使用CC的时候，很多人很习惯性把整个项目目录打开，让它自己找文件。结果每次交互，模型都要读取大量无关代码，Token消耗直接翻几倍。

正确做法是:

• 只给相关的代码: 修改快筛模块，就不要把详情模块的代码也塞进来
• 用摘要代替全文: 不要把500行配置文件全给AI，只给关键部分即可
• 按需加载: 先让AI看接口定义，需要实现细节时再给具体代码
• 定期清理上下文: 长时间对话会积累大量历史Token，该开新会话就开新会话

实际效果: 只给相关代码 vs 整个项目，Token消耗可能差 3～5 倍

还有一个重要的点: AI读到的无关代码越多，生成质量反而越差。因为无关信息会干扰模型的注意力，让它关注不该关注的地方。所以上下文管理不只是省钱，也是在提升质量。

graph TB subgraph bad["❌ 不推荐: 整个项目塞进去"] B1["支付模块"] B2["订单模块"] B3["库存模块"] B4["消息模块"] B5["日志模块"] B6["配置文件"] B7["用户模块 ✅"] B8["监控模块"] end subgraph good["✅ 推荐: 只给相关代码"] G1["用户模块代码"] G2["用户依赖的接口"] G3["相关数据库表结构"] end bad -.-|"VS"| good bad --- R1["Token 消耗高 + 生成质量差<br/>无关代码干扰模型注意力"] good --- R2["Token 消耗低 + 生成质量高<br/>精准信息让模型聚焦正确"] style bad fill:#ffe0e0,stroke:#ff6b6b style good fill:#e0e8ff,stroke:#6b8cff style B1 fill:#ff9999,stroke:#ff6666,color:#fff style B2 fill:#ff9999,stroke:#ff6666,color:#fff style B3 fill:#ff9999,stroke:#ff6666,color:#fff style B4 fill:#ff9999,stroke:#ff6666,color:#fff style B5 fill:#ff9999,stroke:#ff6666,color:#fff style B6 fill:#ff9999,stroke:#ff6666,color:#fff style B7 fill:#ff9999,stroke:#ff6666,color:#fff style B8 fill:#ff9999,stroke:#ff6666,color:#fff style G1 fill:#dde8ff,stroke:#6b8cff style G2 fill:#dde8ff,stroke:#6b8cff style G3 fill:#dde8ff,stroke:#6b8cff style R1 fill:#fff0f0,stroke:#ff6b6b style R2 fill:#f0f0ff,stroke:#6b8cff

Token 消耗差 3-5 倍，生成质量反而更好

策略三: Prompt优化 -- 一次说清楚避免来回扯皮

来回改是最浪费Token的

模糊的Prompt -> AI生成不符合预期 -> 再改Prompt -> 再生成 -> 还是不对 -> 再改 ...

一次说清楚，直接省掉 3-4 轮交互。

怎么写好Prompt呢？

• 说清楚目标: 不是"写个接口"，而是写一个REST接口，接受XXX，参数包括XXX，需要进行幂等校验。
• 说清楚约束: 性能要求、安全校验、代码规范
• 说清楚上下文: 相关的数据库表结构、上下游接口
• 给示例: 一个具体的输入输出示例，比100字描述更有效

策略四: 缓存复用

相似的问题，不要让AI从零生成

• Prompt缓存: 相同的Prompt前缀，API层面可以缓存，省掉重复计算的Token。Anthropic的api已经原生支持了Prompt Caching，相同前缀的输入可以打到90%的缓存命中率。
• 代码模版: 常见的 CRUD 接口、表单校验，维护一套模版，AI只需要填写差异部分。
• 会话复用: 同一类的CC会话，可以服用之前的上下文，不用每次从零开始

策略五: 评估哪些任务用AI做更贵

不是所有的任务都适合用AI做

• 适合AI做的

  • 重复性高、模式固定的代码（CRUD、样板代码）
  • 你知道要什么但手写太慢的代码
  • 需要快速探索多种方案的场景
  • 不熟悉的语言或框架的入门代码

• 不适合AI做的

  • 改一行配置就能解决的小修改
  • 你已经非常熟悉的代码区域，手写比解释更快
  • 需要深度理解业务上下文的决策型代码
  • 已经有精确模版、复制黏贴比生成更快的情况

Token成本控制总结

策略	核心思路	预期效果
模型路由	简单任务用小模型	成本降 60%+
上下文管理	只给相关代码 消耗降 3-5 倍
Prompt 优化	一次说清楚	往返次数降 3-4 倍
缓存复用	不从零开始	消耗降 50%+
任务评估	不该用 AI 的就别用	视场景

高频题汇总

场景类

Q: AI越来越强，你的优势是什么

差的回答: AI做不了复杂业务逻辑和安全代码

好的回答: AI 确实越来越强，很多之前说 AI 做不了的场景现在都做得不错。但 AI 的输出质量直接取决于人的输入质量------定义问题、构建上下文、验证结果、做决策、控成本，这五件事 AI 替代不了我。我的优势不是比 AI 写得好，是让 AI 写得更好。

Q: 你负责的项目里，哪些让AI写，哪些自己写

判断标准不是 "AI做的了还是做不了"，而是 "这段代码出 bug 的代价有多大"和"让 AI 写和手写哪个综合成本更低"

• 代价大，AI写更贵: 自己写 或 AI写但严格审查
• 代价小，AI写更便宜: 用AI提速

Q: AI生成的代码出了线上故障

三步走: 先止血、再定因、最后补流程

• 止血: 回滚或降级，先让线上恢复，不管是不是AI写的，处理方式一样
• 定因: 看监控确认影响范围，看日志追踪调用链路，定位到具体问题代码。如果是AI生成的代码，还要想清楚为什么审查的时候没有拦住 --- 是安全没审核到还是边界条件没处理，还是语义理解有偏差。
• 补流程: 补充测试用例、加强审查重点、甚至调整哪些场景允许AI生成。一个bug不可怕，同类bug再出一次才可怕。

Q: AI 写的代码上线出问题了，让 AI 修，结果 AI 也修不好，你怎么兜底？

这个问题很刁钻，但确实会发生。AI自己写的代码，自己修不好 --- 可能是它对线上环境没有感知，也可能是因为问题根因涉及多个模块的交互，AI的上下文窗口装不下那么多信息。

兜底的关键在于: 你不能等着AI来救你，你得自己能接手

• 先止血: 不管AI能不能修，出了线上问题第一时间回滚到稳定版本，线上用户等不了
• 自己排查: 看日志、看监控、看链路追踪、定位根因。这个时候你之前审查AI代码的理解就有用了
• 修复上线: 自己改代码，走正常测试和发布流程
• 复盘: 为什么AI修不好？是上下文不够，还是问题超出他的能力范围？这次复盘的结果决定下次类似问题还要不要交给AI。

说到底，AI修不了的时候，你得能修。这是底线！！！

工程落地类

Q: AI编程工具的Token怎么控制

五个策略: 模型路由（70%任务用小模型）、上下文管理（只给相关代码）、Prompt优化（一次说清楚）、缓存复用（维护模版 + Prompt Caching）、任务评估（不该用AI的时候就别用）。

核心在成本和质量直接找平衡，不是越便宜越好，也不是越贵越好。

Q: 团队管理AI生成的代码

• 任务归属: 谁Accept的谁负责
• 审查流程: AI代码走和人工代码一样的 CR
• 监控指标: 追踪AI代码的Bug率和漏洞率
• 持续优化: 根据数据调整AI使用策略

Q: 用AI写代码，怎么保证不泄露公司代码

事实上很多公司都没有私有化agent，那么业务开发就面临代码安全问题。

AI编程工具都有代码上传的能力 -- 你的代码会被发送到模型的服务端做推理。虽然厂商说不会拿来训练，但合规部门不一定会买账。

• 敏感代码不上传: 核心算法、密钥管理、交易策略这些不要在AI工具里打开，更不要让AI生成。
• 用企业版: 企业版有数据隔离协议，代码不会拿去训练，合规风险小很多
• 配置 gitignore 和 claudeignore: 把敏感目录和文件排除在AI的访问范围之外，防止工具自动读取不该读的代码
• 团队统一规范: 哪些项目可以用AI，哪些不能，写进开发规范。

总结

回到最初的灵魂拷问: 在 vibe coding 盛行以及基模越来越强的当今，你觉得你的优势是什么

AI做什么事都需要你先做对 --- 定义问题、构建上下文、验证结果、作出决策、控制成本

不是AI做不了，是AI需要你

AI做不了是防守心态，越守越窄

AI需要你是驱动，越用越强

graph LR Q(("AI越来越强<br/>你的优势在哪?")) Q --> A1["AI 做不了<br/>复杂业务逻辑"] A1 --> A2["AI 也能做了"] A2 --> A3["又做得了"] A3 --> A4["优势越来越窄"] Q --> B1["AI 需要你<br/>定义问题"] B1 --> B2["构建上下文"] B1 --> B3["做决策"] B2 --> B4["验证结果"] B3 --> B5["控成本"] B4 --> B6["优势越来越强"] B5 --> B6 style Q fill:#1a6dcc,color:#fff,stroke:#1a6dcc style A1 fill:#cce0ff,stroke:#6baed6 style A2 fill:#cce0ff,stroke:#6baed6 style A3 fill:#cce0ff,stroke:#6baed6 style A4 fill:#cce0ff,stroke:#6baed6 style B1 fill:#d4edda,stroke:#4caf50 style B2 fill:#d4edda,stroke:#4caf50 style B3 fill:#d4edda,stroke:#4caf50 style B4 fill:#d4edda,stroke:#4caf50 style B5 fill:#d4edda,stroke:#4caf50 style B6 fill:#1a6d5a,color:#fff,stroke:#1a6d5a

防守越守越窄，驱动越用越强

你的优势不是比AI写得好，而是让AI写的更好