11 · 误区与常见反对意见
把社区里反复出现的话术拆开。目标不是赢辩论，而是 避免用错隐含假设。
误区 1：「AI 会取代程序员，再学也没用」
常听到
反正以后不用人写代码了，转行吧。
更准确
AI 取代的是 大量编程劳动，不是 对软件结果负责的角色。
需求、约束、验证、上线、事故、合规，仍然落在人身上——只是实现密度变了。
可操作回应
- 把时间从「背 API」挪到「规格、验证、系统责任」
- 用 AI 放大交付，而不是等待被取代的叙事
误区 2：「会提示词 = 会 AI Coding」
常听到
我提示写得很花，所以我已经很强了。
更准确
提示是输入带宽；真正拉开差距的是：
- 问题是否定义清楚
- 上下文是否喂对
- 有没有可执行验收
- 出错时能否发现并收束
文采好的提示 + 零测试仓库 = 流畅地生产垃圾。
可操作回应
练「完成标准」和「对抗审 diff」，比收集提示词模板更值钱。
误区 3：「测试绿了 = 可以合并」
常听到
CI 全绿，AI 写的应该没问题。
更准确
测试可能：
- 断言错对象
- 只覆盖快乐路径
- 被实现带跑偏
- 根本不跑关键集成路径
CI 绿是 必要非充分。
可操作回应
- 关键改动：人走主路径 + 一个失败路径
- 问：我删掉这行业务逻辑，测试会红吗？
- 权限/钱/删除类：额外清单，不交给「绿」单独决定
误区 4：「用了 AI 产出就该翻倍，否则工具不行」
常听到
我们全员开了 Copilot/Cursor，为什么交付没变？
更准确
常见卡点在流程，不在模型：
- 需求依然模糊
- 评审仍是行级洁癖或完全摆烂
- 无测试、无权限、无仓库说明
- 指标还在数 commit
工具放大的是 已有系统的斜率，不是自动给正斜率。
可操作回应
先改：意图模板、PR 证据、红线、一个仓库的上下文文档。
再谈换更贵的模型。
详见：06 · 组织与流程
误区 5：「资深工程师不需要 AI」 / 「用 AI 的都是初级」
两边都错
- 拒绝工具的资深：在可压缩劳动上浪费杠杆
- 只会生成的初级：在不可压缩判断上裸奔
更准确
资深的正确用法是：
- 把经验写成约束与否决标准
- 让 AI 执行搜索与机械改造
- 自己守架构与风险
初级的正确用法是：
- 用 AI 加速样板
- 强制自己解释每一处关键 diff
- 找人教验证，而不是只教提问
误区 6：「Vibe coding 就是未来，规范都是旧时代包袱」
常听到
感觉对了就行，船到桥头自然直。
更准确
Vibe coding 在：
- 个人玩具、一次性脚本、探索原型
往往高效。
在：
- 多人协作、长期产品、钱与安全、合规
会变成 高利息贷款。
可操作回应
按风险分层：低风险可以 vibe，高风险必须规格与门禁。
不是道德问题，是爆炸半径问题。
详见：04 · 风险分级
误区 7：「模型越强，人越可以少懂代码」
常听到
以后只要会说话就行。
更准确
模型越强，抽象泄漏时的坑越深。
你不懂下层时：
- 看不出优雅的错
- 调不了性能与并发
- 事故时只能重启会话求饶
「少敲代码」≠「少懂系统」。
可操作回应
保持对核心路径的解释能力；定期无 AI 做小规模调试。
误区 8：「开源/便宜模型不够好，必须上最贵」
常听到
不用最强模型就是不认真。
更准确
大量任务是：
- 样板、格式、本地化重构、测例草稿
用中低价模型 + 好上下文，性价比更高。
最贵模型留给：硬推理、长程 agent、复杂设计权衡。
可操作回应
建简单路由：风险 × 难度 → 模型档。
量成本/任务，不量「我是否用了最新」。
误区 9：「标注 AI 生成没有意义」 / 「必须逐行标注」
两个极端
- 完全不标注：事故时无法改进提示与门禁
- 强迫每行标签：形式主义，没人维护
更准确
PR 级说明即可：
- 参与程度（探索 / 主要实现 / 仅辅助）
- 如何验证
- 已知不确定点
目的是 责任与学习，不是羞辱使用者。
误区 10：「安全问题是模型厂商的事」
常听到
我们又没训练模型，出了注入/泄密怪供应商。
更准确
你控制：
- 什么数据进提示
- agent 有什么权限
- 依赖变更谁审
- 生产操作谁批准
厂商负责底座；集成与授权是你的攻击面。
可操作回应
最小权限、密钥扫描、生产数据默认隔离、高危动作人工门。
常见反对意见（FAQ 体）
Q1：我们业务太特殊，AI 用不起来？
特殊通常意味着 上下文没写下来。
先把：模块图、禁忌、领域名词表、典型事故，写成人和模型可读的文档。
仍难的部分，让 AI 做周边（测试、迁移脚本、文档），人守核心。
Q2：代码不能出内网，怎么办？
- 走企业网关 / 私有化 / 数据驻留合同
- 本地/开源模型处理敏感段
- 严格分类：哪些仓库永不上第三方
「一刀切禁止」常导致影子账号；「分级 + 网关」更可持续。
Q3：领导只想看「提效 30%」怎么说？
不要承诺万能百分比。改用：
- 某类任务 lead time（如 CRUD、测试补全）
- 逃逸缺陷是否上升
- 评审等待与返工
给 4–6 周小范围试点基线，再谈推广。
Q4：初级还怎么培养？
培养目标改成：
- 会写验收与复现
- 会审 AI diff
- 能解释合并进主干的代码
- 在有人带的情况下端到端交付小功能
减少「纯抄教程搬砖」岗位预期，增加「带验证的学徒」设计。
Q5：AI 写的代码风格乱，团队受不了？
- 强制 formatter/linter（别让人审格式）
- 仓库说明写清错误处理与目录约定
- 要求 AI「先读邻接文件再模仿」
- 评审拒绝第二套并行抽象
风格是工程问题，不是玄学。
Q6：老是会话越聊越蠢？
正常。上下文污染 + 目标漂移。
- 一个会话一个主目标
- 阶段结束开新会话，带上结论摘要
- 大任务用计划文件/issue 做外部记忆
Q7：要不要 all-in 某一个 daily driver？
个人可以有默认工具；组织应：
- 保留多模型路由能力
- 关键资产（规范、评测、权限）不绑死一家
- 用自家仓库任务做选型，而不是 X 热帖
详见：09 · 热度参考
Q8：怎样判断自己「用得还行」？
粗指标：
- 你能稳定说出每个合并 diff 的意图与风险
- 返工主要来自需求变化，而不是幻觉与误解
- 你有可复用的仓库约束，而不仅是个人手感
- 出问题能复盘到具体闸门，而不是「模型不好」
一句话
最贵的误区，是把流畅当成正确，把工具当成责任，把热度当成方法。