1、AI 越来越强，你的优势到底是什么？
结论：
AI 确实越来越强，很多之前说 AI 做不了的场景现在都做得不错。但 AI 的输出质量直接取决于人的输入质量——定义问题、构建上下文、验证结果、做决策、控成本，这五件事 AI 替代不了我。我的优势不是比 AI 写得好，是让 AI 写得更好。
具体分析：
优势一：问题定义能力
AI 很强，但它需要精确的问题定义。我的优势在于能把模糊的需求拆解成清晰的技术规格——边界条件、异常处理、业务规则，这些 AI 不会主动问你，但不说清楚代码一定写不对
优势二：上下文构建能力
AI 的上限是由你的输入质量决定的，我给 AI 的 Prompt 包含完整的边界条件、相关代码片段和业务规则，而不是一句话就让它写。
优势三：结果验证能力
AI 生成的代码我会重点验证业务语义，不是看能不能跑通，而是看行为是否符合业务意图
优势四：技术决策能力
AI 能帮我分析方案，但最终的选型决策是我做的。因为决策要考虑的不仅是技术因素，还有团队现状、业务阶段、历史教训——这些 AI 不知道，也不应该由 AI 决定
优势五：成本控制能力
同下
五大优势总结
AI 的输出质量取决于我的输入质量——定义问题、构建上下文、验证结果、做决策、控成本，这五件事 AI 替代不了你。
2、AI 编程工具的 Token 成本怎么控制
结论：
五个策略：模型路由（70% 任务用小模型）、上下文管理（只给相关代码）、Prompt 优化（一次说清楚）、缓存复用（维护模板 ）、任务评估（不该用 AI 的就别用）。核心是在成本和质量之间找平衡，不是越便宜越好，也不是越贵越好。
具体分析：
策略一：模型路由——什么活用什么模型
我们团队做了模型路由策略——简单补全用小模型，复杂任务才用大模型。70% 的日常编码任务其实不需要最强模型，这样整体 Token 成本能降 60% 以上（具体落地->走公司网关来平台统一管控）
策略二：上下文管理——别把整个代码库塞进去
我会主动管理上下文，只给 AI 相关的代码片段而不是整个项目。这样做 Token 消耗能降 3-5 倍，而且 AI 生成质量反而更好——因为无关信息少了，模型不容易被干扰。
策略三：Prompt 优化——一次说清楚，别来回改
来回改是最浪费 Token 的，
一个好的prompt要确定好目标，说清楚约束，给清楚上下文，给出示例等。
策略四：评估——哪些任务让 AI 做更贵
不是所有任务都适合让 AI 做。
Q：你负责的项目里，哪些让 AI 写，哪些自己写？
判断标准不是"AI 做得了还是做不了"，而是"这段代码出 bug 的代价有多大"和"让 AI 写和手写哪个综合成本更低"。
代价大、AI 写更贵的：自己写或 AI 写但严格审查。代价小、AI 写更便宜的：让 AI 加速。
Q：你怎么审查 AI 生成的代码？
重点查三样：业务语义（代码行为是否符合业务意图）、安全风险（输入校验、权限控制、敏感数据）、工程性（性能、可维护性、规范一致性）。
特别注意 AI 的"合理但错误"代码——逻辑通顺、能跑通、但语义和业务需求不一致。这种代码最容易漏过 Review。
Q：AI 生成的代码出了线上 bug，你怎么处理？
三步走：先止血，再定因，最后补流程。
止血：回滚或降级，先让线上恢复，不管是不是 AI 写的代码，处理方式一样。
定因：看监控确认影响范围，看日志追踪调用链路，定位到具体的问题代码。如果是 AI 生成的代码，还要想清楚审查的时候为什么没拦住——是安全没审到，还是边界条件没覆盖，还是业务语义理解有偏差。
补流程：补充测试用例、加强审查重点、甚至调整哪些场景允许 AI 生成。
Q：AI 写的代码上线出问题了，让 AI 修，结果 AI 也修不好，你怎么兜底？
这个问题很刁钻，但确实会发生。AI 自己写的代码，自己修不好——可能是因为它对线上环境没有感知，也可能是因为问题根因涉及多个模块的交互，AI 的上下文窗口里装不下全局信息。
兜底的关键是你不能等 AI 来救你，你得自己能接手：
先止血：不管 AI 能不能修，先回滚到上一个稳定版本，线上用户等不了
自己排查：看日志、看监控、看链路追踪，定位根因。这时候你之前审查 AI 代码积累的理解就派上用场了——如果你审查的时候理解了逻辑，排查速度会快很多；如果你审查的时候是"看着没问题就过了"，那排查起来跟看别人的代码没区别
修复上线：自己改代码，走正常的测试和发布流程
复盘：为什么 AI 修不好？是上下文不够，还是问题超出它的能力范围？这次复盘的结论，决定下次类似问题还要不要交给 AI
说到底，AI 修不了的时候，你得能修。这是底线。
Q：你们团队怎么管理 AI 生成的代码？
四件事：代码归属（谁 Accept 谁负责）、审查流程（AI 代码走和人工代码一样的 Review）、监控指标（追踪 AI 代码的 Bug 率和漏洞率）、持续优化（根据数据调整 AI 使用策略）。
Q：如果面试官问：“你怎么用 Vibe Coding？踩过什么坑？”
我刚开始用 Vibe Coding 时，发现最大的问题不是 AI 写不出来，而是恢复点不足。AI 一次改太多文件，如果没有 Git 小步提交，后面出问题很难回退。所以我现在会按模块拆任务，每个功能一个闭环，先让 AI 出计划，再限制改动范围，改完看 diff、验证、提交。
还有一个是文档先行。我现在开发新功能前，会先让 AI 生成技术文档，包括流程设计、接口定义、异常处理。我先审查文档，确认没问题再让 AI 写代码。功能完成后再让 AI 更新文档，记录实际实现。这样切换 AI 工具时，新工具直接读文档就能接手，不用每次都重新理解项目。
