AI 不会取代专业能力，而是放大专业能力

本周最有价值的 AI 讨论，并不是哪一个新模型发布了。真正的问题是：为什么同一个 LLM 给一个人带来有用草稿，给另一个人带来自信的错误，又让第三个人更快生成了仍然无法上线的产品。

Hacker News 上同时升温的几个讨论——“LLMs reward expertise”、cognitive debt、AI Productivity Gap——指向同一个实践结论：AI 让更多人能产出东西，但结果质量仍取决于领域知识、验证能力和对系统的理解。

Prompting 不是魔法短语。专家知道哪一个细节会改变问题，应该使用哪个术语，模型哪里在胡说，什么答案看似合理但不对，以及什么时候该停下。AI 没有取消专业能力，而是放大了专业能力。

新手会受益，但有边界

AI 能帮助新手做原型、写初稿、获得解释和探索方向。但任务一旦离开教程路径，就需要词汇、质量标准、部署经验、安全意识、维护能力和对“完成”的定义。

企业不应该因此禁止 junior 使用 AI，而应该提供脚手架：示例、review checklist、安全环境、领域词汇表、evals 和导师反馈。有反馈时，AI 可以加速学习；没有反馈时，它可能隐藏知识缺口。

Cognitive debt 是真实成本

当 agent 写出很大的 change，而人只是表面 review 后接受，代码可能先于理解出现。Ankur Sethi 建议让 LLM 给出修改建议，再由人手动输入或重写，以保留 mental model。不是每个团队都要照做，但原则重要：理解是交付物的一部分。

高速 agent 模式适合机械、可逆、测试充分的任务。核心业务逻辑、安全流程、billing、migration、架构和学习任务，则需要保留理解的模式。负责人必须能解释 change、tests、failure modes 和它为什么适合系统。

Productivity gap 来自瓶颈

AI 让写代码更快，不等于团队交付产品快几倍。需求、设计、review、测试、CI、部署、协调和产品判断仍然限制吞吐。AI 甚至可能制造更多需要 review 的输出。

所以 lines of code、PR 数和 token 数不是好指标。更好的指标是验证过的结果：解决的客户问题、更短的生产周期、更少缺陷、更快的正确分析和更有用的文档。

旧工程实践变成 AI 实践

Martin Fowler 的 refactoring 案例说明结构仍然重要。一个由 agents 写出的 150,000 行应用中，数据访问层的单个 Rust 文件长到 17,155 行。重构后，代表性修改的 input tokens 从 159,564 降到 27,360，减少 83%。但重构方向仍需要人类指导。

对非技术团队也是一样。没有清晰标准，AI 会放大混乱：销售 follow-up 不一致，法律条款临时拼接，客服政策混合，分析看起来漂亮但判断错误。

实用清单

衡量结果吞吐，而不是输出体积。最终决策必须有人负责。让 change 保持小而可测。把 agents 用在边界清楚、可验证的任务上。把领域假设写进持久文档、测试和示例。扩展 agents 前先建立 evals。追踪 review burden 和 cognitive debt。保护 junior 的学习路径。

AI adoption 已进入 post-demo 阶段。问题不再是模型能不能生产内容；它能。问题是谁能让它在正确上下文里产出正确东西，同时不把债务留给其他人。