标签归档:AI编程

AI 编程:程序员变成了程序指导员

去年 Vibe Coding 突飞猛进,AI 编程已经逐渐普及。 很多团队对于写代码这件事的定义开始有一些变化。变化在于产出代码的方式:越来越多的代码来自模型,程序员更多时间花在和模型聊天,把问题说清楚、把边界卡住、把结果验明正身。

我愿意称之为「程序指导员」。写代码仍然在发生,但我们的动作从「逐行敲」转到「聊天与校验」。

1. 程序指导员在做什么

把一段需求交给 AI,得到一段能跑的代码,然后多聊几句,一个功能就完成了。但是这个功能是不是可维护、可上线、可回滚、可观测、可审计,就不太确定了。

程序指导员的核心工作通常包括这几件事:

  1. 把需求翻译成可执行的任务
    需求里混着业务语言、边界条件、历史包袱、隐含约束。模型的信息中这些可能是缺失的。我们要先做一次结构化翻译:输入是什么、输出是什么、失败怎么处理、性能底线是什么、兼容范围是什么。

  2. 把任务拆成模型能稳定完成的块
    一次性让模型写完一个完整功能,也可以,让 CC 多跑一段时间,但成功率不稳定。更稳的方式是拆成小块:数据结构、接口定义、核心逻辑、错误处理、测试、文档、迁移脚本,各自生成、各自验证,然后再组装。这种方式让我们更有掌控力,知道发生了什么,过程可控。

  3. 给足约束,减少「自由发挥」空间
    约束要可检验:必须用现有依赖、必须兼容某版本、必须遵守公司日志规范、必须不新增公网访问、必须在某条 SLA 内、必须覆盖某些用例。

  4. 验收与兜底
    模型会给出看起来合理的实现,也会在边界上“编”。程序指导员要像做 code review + 测试负责人那样工作:读关键代码、跑测试、补测试、压测、看日志、看回归风险、看安全风险。最后要能回答一句话:这段代码出问题,谁来修、怎么定位、怎么回滚。

这套工作方式和当前的 CC 一把梭相比,并不先进,甚至有些落后。

和以前相比,以前也有模板代码、脚手架、复制粘贴、搜索引擎。不同点在于:AI 把「生成」能力推到台前,生成速度极快,错误也更隐蔽,导致「指导与验证」的权重被迫上升。

2. 变了什么

2.1 输入从「代码」变成「任务说明书」

以前的输入主要是我们写的代码和我们改的代码。现在多了一种主要输入:我们写给模型的任务说明书。

这份说明书的质量,直接决定产出质量。写得好,模型像一个执行力强的中级工程师;写得差,模型像一个自信的实习生。

说明书里最重要的内容通常包括:

  • 目标:要解决什么问题,做到什么程度算完成
  • 环境:语言版本、框架版本、已有目录结构、现有依赖、运行方式(一般在规则上下文中给出)
  • 接口:入参、出参、错误码、异常策略、幂等、重试、超时
  • 约束:性能、资源、兼容、安全、合规、日志、监控
  • 验收:必须通过哪些测试,用哪些样例验证,输出应满足哪些断言

把这些写清楚,能把 80% 的返工挡在模型生成之前。

2.2 工作节奏从「连续编码」变成「短回路迭代」

传统编码经常是长回路:写一段、跑一遍、再改。AI 编程的高效来自短回路:AI 生成完成,自动编译构建,自行测试,然后马上验收,发现偏差、立刻补约束再生成。

短回路的关键在于每一轮都要带着明确的失败信息回去:哪条测试挂了、哪个接口不对、哪个边界漏了、哪个依赖版本冲突。模型对这种「可定位的反馈」反应更稳定。

2.3 代码量不再是效率指标

代码生成变快之后,代码量会失真。以前一个人一天写 500 行算多,现在模型十秒能吐 500 行,一天几千行可用的代码随随便便。

更有意义的度量指标会转向:

  • 需求到可用版本的周期
  • 线上缺陷率与回滚率
  • 变更影响范围(改动越小越好)
  • 可维护性(复杂度、重复度、依赖扩散)
  • 测试覆盖与回归效率

如果团队还用「写了多少行」「提了多少 PR」来衡量,会很快走偏:大家都能刷产出,系统质量却下降。

2.4 「看懂代码」变得更重要

模型写的代码往往「像那么回事」,也可能更长、更绕、更喜欢堆抽象。程序指导员必须能快速识别几类问题:

  • 关键路径上不必要的复杂度
  • 隐性性能问题(多余的拷贝、无界缓存、低效循环)
  • 错误处理缺失(吞异常、错误码混乱、重试风暴)
  • 并发与资源泄漏(锁、连接、文件句柄)
  • 安全问题(注入、越权、敏感信息日志、依赖风险)
  • 与现有系统契约不一致(字段含义、时序、幂等等)

以前也需要这些能力,但当代码产出速度暴涨时,「看懂与筛掉问题」的能力会直接决定我们能不能把速度兑现成质量。

3. 没变什么

变化再大,有些东西一直没变,而且变得更值钱。

3.1 对业务的理解仍然是门槛

模型可以补全语法、补齐样板、生成测试,但它很难替我们承担「业务正确性」。尤其在边界条件、例外流程、历史债务、灰度策略上,错误经常不是编译错误,而是业务事故

谁最懂业务,谁最知道「哪些地方不能动」「哪些数据不能算错」「哪些流程不能重试」,谁就更能驾驭 AI 编程。

换一个大家更常用的词语,就是领域知识要在线,否则错了你也不知道错了。

3.2 系统设计能力仍然决定上限

模型擅长在给定结构里填充实现,不擅长从零做合理设计。系统边界怎么划、数据怎么流、接口怎么稳、状态怎么管理、失败怎么收敛、观测怎么做,这些决定了系统能不能长久演进。

如果把“设计”也交出去,模型会给一个看似完整的方案,但常见问题是:

  • 组件拆得漂亮,运行链路混乱
  • 过度抽象,改一处牵一片
  • 忽略现有基建与规范
  • 缺少可观测与运维视角

当然,这些问题都可以通过提示词来解决,不过对于系统设计的认知还是需要我们来把握,至少我们得知道什么是好什么是坏。

系统设计这件事,仍然需要人来负责,并且要更早介入。

3.3 责任边界没有变化

代码是模型生成的,并不改变责任归属。线上出了事故,审计追责、复盘改进、长期治理,仍然落在团队身上。

在群里看到一个消息,最近有一个团队 AI 生成的导致线上数据全部被覆盖,团队绩效今年基本和他们没有关系了。

所以「让模型写」不是免责理由,反而要求流程更严:评审、测试、灰度、回滚、监控、告警、应急预案,一个都不能少。

4. 程序指导员需要哪些基础认知

4.1 对模型能力边界的认知

模型的强项:

  • 快速生成代码、接口定义、CRUD、数据转换
  • 根据已有代码风格补齐实现
  • 生成测试用例框架、mock、基础断言
  • 把自然语言需求翻译成「看起来像」工程方案

模型的弱项:

  • 对真实业务语义的可靠理解(尤其隐含规则,,因为其没有上下文,甚至有些隐含规则我们自己也没有意识到)
  • 对运行时约束的自发遵守(性能、资源、稳定性)
  • 对项目历史约定、隐性依赖的自动继承
  • 对安全与合规的默认正确
  • 对「细微但关键」的一致性(字段含义、状态机、时序)

程序指导员要把弱项当成默认风险。

4.2 任务拆解能力

拆解不是把大需求拆成很多小需求就结束了,而是拆成“可验证”的单元。

可验证的含义是:
每一块都能用编译、单测、静态检查、契约测试、跑一段 demo 来确认对不对。

拆解时常见的顺序:

  1. 先定接口与数据结构(契约优先)
  2. 再做核心逻辑(关键路径先跑通)
  3. 补错误处理与边界(把失败收敛)
  4. 加测试与观测(让后续修改可控)
  5. 最后做重构与清理(收敛复杂度)

这个顺序能减少返工,也更适合把生成结果分段纳入工程体系。

4.3 约束表达能力

约束要写成「可执行」的规则。

常见可执行约束:

  • 依赖:禁止新增依赖;必须使用项目已有库
  • 版本:必须兼容某版本运行环境
  • 性能:某接口在某数据量下耗时上限
  • 幂等:重复请求的处理方式
  • 日志:必须打哪些字段;禁止打印哪些字段
  • 错误:错误码范围;异常抛出策略;重试策略
  • 兼容:老接口字段不可删;新增字段默认值策略
  • 安全:输入校验、权限校验、敏感信息处理

当我们把这些写清楚,模型就可以更规范的交付了。

4.4 验证习惯与测试能力

验证还是要靠工程化手段。

最低配置的验证链路:

  • 静态检查:lint、类型检查、依赖扫描
  • 单元测试:关键逻辑与边界条件必须有断言
  • 集成测试:接口契约与关键链路
  • 回归策略:哪些模块必须跑全量,哪些可抽样
  • 观测:日志、指标、链路追踪的基本补齐
  • 灰度与回滚:发布策略与开关方案

把这些链路搭好,AI 才能变成稳定的生产力工具。否则它更像一个加速出错的发动机。

5. 小结

程序员变成程序指导员,不是职位变了,是工作重心变了:写代码的时间变少,把问题讲清楚、把系统守住、把风险挡住的时间变多。

最近阿里出来的 P10 毕玄,在其创办的公司贝联珠贯中宣布不再按传统的专业分工,所有的人都叫 Agent 全栈工程师。

我想象中的团队也是这样,通过合并工种,减少沟通,让 AI 发挥出更大的价值。

在做这些之前,我们需要问一下自己三个问题:

  • 我们的验收标准有没有变得更清晰
  • 我们的测试与观测有没有跟上生成速度
  • 我们有没有把隐含知识变成显性规则

答案越清楚,AI 带来的就越接近真实效率。否则只是把编码速度提上去,把返工和事故也一起提上去。

以上。

AI 编程时代,人与人的交流减少了是好事吗?

随着 AI 编程在团队越来越普及,猛然发现一个正在变得「习以为常」的变化:以前遇到问题,第一反应是问同事或 Google;现在第一反应是问 AI。

Anthropic 在 2025 年 8 月对内部 132 名工程师和研究员做了调研(53 次深度访谈 + Claude Code 使用数据分析),把这个变化讲得很具体:Claude 成了“第一站”。有人说自己现在提问更多了,但 80%–90% 的问题都丢给 Claude,只有剩下 Claude 解决不了的才去找同事。

交流减少,到底是不是好事?

答案很难用一句话盖棺定论,但可以把它拆开:减少的是什么交流、增加的是什么交流、谁受益、谁受损、组织会丢掉什么能力。拆开之后,我们聊聊。

1. 交流为什么会减少?

「问同事」换成「问 AI」,最核心的原因不是大家突然不爱社交,而是成本变了

  • 问 AI 不需要等对方空闲
  • 不担心打断别人
  • 不欠人情
  • 不需要把上下文组织成「适合对人讲」的样子(很多时候我们只要把报错、代码片段、目标贴过去)
  • AI 还能陪你迭代:你改一句,它再改一句,来回几十轮也不尴尬

Anthropic 的访谈里,很多人把 Claude 描述成「常驻协作者」。但与此同时,他们也强调:多数工作仍要监督和验证——频繁使用,不等于完全放手。在问卷里,超过一半的人认为自己能「完全委派」的比例只有 0–20%。

交流减少,不代表工作变简单;很多交流只是从「人际通道」搬到了「人机通道」。

2. 交流减少可以带来好处

如果只说交流减少带来「效率提升」,太粗了。

更准确的说法是:很多原本不值得打扰人的问题,现在可以被即时解决,这会直接改变团队的节奏。

Anthropic 的数据里有几个信号很典型:

  • 受访者自报:现在 Claude 参与了他们 约 59%–60% 的工作,平均带来 约 +50% 的生产力提升(相较 12 个月前是 2–3 倍增长)。
  • 他们把生产力的来源描述为:每类任务耗时略降,但产出量显著上升
  • 还有一个容易被忽略的点:受访者估计 27% 的 Claude 辅助工作“本来不会做”,包括一些“nice-to-have”、探索性工作、文档测试、以及小修小补。

交流减少在这里的正面作用是:
很多「本来要去问人」的碎问题,被 AI 吃掉以后,人的协作可以更集中在真正需要对齐的地方。

在 Anthropic 的访谈里,有人说 Claude 形成了一个过滤器:例行问题交给 Claude,同事只处理更复杂、更需要组织上下文或判断力的部分。

这对很多团队来说,会带来几类直接收益:

  1. 减少同步阻塞:你不用等某个专家上线回复,很多事可以自己推进。
  2. 减少社交摩擦:不必反复确认「我现在打扰你是否合适」。
  3. 让“冷启动”更容易:对新人或跨领域的人,AI 能补齐工具链、代码风格、惯例解释。
  4. 让协作更聚焦:把人从「答疑机器人」解放出来,去做判断、方案权衡、目标对齐。

从组织角度讲,这确实是好事:同事的时间更像「稀缺资源」,而 AI 的时间不是

3. 交流减少是有代价的

交流减少的问题在于:人与人的交流减少,减少的往往不是闲聊,而是一些「看起来低效、但在组织里非常有价值」的过程。

3.1 指导与传承会变弱(尤其对新人)

Anthropic 有个很直接的反馈:一位资深工程师说,难过的是初级员工不像以前那样常来问问题了——虽然他们确实更快得到答案、学得也更快,但连接少了。

这类“连接”不是情绪价值这么简单,它对应的是:

  • 代码审美与工程判断的口口相传
  • 对系统边界、坑位、历史遗留的理解
  • 「为什么我们不这么做」的经验
  • 出问题时应该找谁、怎么升级、什么时候停手

AI 能解释代码、给建议,但它替代不了一个组织里那些隐性的「运行规则」和「风险嗅觉」。或者我们可以称它为「潜规则」

3.2 越依赖 AI,越需要高手,但高手可能变少

Anthropic 提到一个很关键的矛盾:监督 Claude 需要技能,而过度使用 AI 又可能让技能变少。有人担心的不是自己会不会写代码,而是「监督与安全使用」的能力会不会退化。

访谈里还有个安全相关的例子很典型:Claude 提出一种「很聪明但很危险」的方案,像「非常有才但缺经验的初级工程师」会提的那种。能识别这种危险,需要经验和判断力。

当团队把大量交流(包括讨论、复盘、推演)替换为「我和 AI 私下迭代」,长期会出现一种风险:
团队表面产出更快,但「集体判断力」的增长变慢。

3.3 协作方式会变

Anthropic 的访谈呈现出分化:

  • 约一部分人认为协作没变:会照开、方向照讨论,只是执行方式变成「你对着很多个 Claude 工作」。
  • 也有人明显感到:自己和 Claude 的协作远多于和同事的协作。
  • 有人喜欢这种变化,因为“不用麻烦别人”;也有人抵触,因为“更喜欢和人一起工作”。

这说明:交流减少不是单向度的,它改变的是交流的结构——从“随手问”转向“更重的对齐”。
而一旦对齐变重,团队如果没有刻意经营,很容易出现:

  • 每个人都在本地把东西做很快,但最终合并、上线、验收时冲突变多
  • 设计决策被“私下定稿”,缺少充分挑战
  • 标准不一致:测试、可维护性、可观测性被忽略(尤其在产出量暴涨时)

当「实现」和「规划」都更多交给 AI,人类之间如果还沿用旧的协作节奏,很容易失配。

3.4 意义感

写代码的「手感」和「心流」正在消失,甚至影响职业满足感。
从个人体感上来说也是,已经没有心流和手感的状态了,只不停的输入提示词和等待。 当然,你的脑海里还是会有一个架构图,一个方向。 如果这个都没有了,那你存在和不存在已经没有意义了。

也有人发现自己真正喜欢的是「写完之后带来的结果」,而不是「写的过程」。

这会影响一个很现实的问题:当我们减少了与同事的交流,同时也减少了自己动手的比例,我们每天工作的乐趣来源会改变。如果团队不谈这个问题,人的流失会以更隐蔽的方式发生。

4. 所以,交流减少是不是好事?

看你减少的是哪一种

把「交流」粗暴地当成一个东西,会得出很混乱的结论。更可操作的拆分方式是:你减少的是下面哪一种?

4.1 如果减少的是“低价值同步”,通常是好事

比如:

  • 解释某个报错怎么修
  • 查一个命令怎么用
  • 复制粘贴式的示例代码
  • “我现在卡住了,给我一个思路”这种轻量提示

这些问题交给 AI,整体是正收益:快、便宜、不打扰人。

4.2 如果减少的是「决策对齐」和「经验传承」,长期不是好事

比如:

  • 为什么我们要这么设计?约束是什么?边界是什么?
  • 这个改动会不会引入安全/合规风险?
  • 出现事故时如何复盘、如何改流程?
  • 新人如何在真实项目里形成判断力?
  • 谁对什么负责?升级路径是什么?

这些不是「知识问答」,而是组织的运行方式。AI 可以参与,但不能替代团队成员之间的共识建立。

4.3 如果减少的是「互相看见」

我们会失去韧性

很多团队扛过线上事故、跨部门冲突、方向摇摆,靠的不是某个代码技巧,而是:

  • 彼此信任
  • 知道对方擅长什么、在意什么、底线是什么
  • 关键时刻愿意帮、愿意兜

当日常交流下降到只剩「正式会议」,这类韧性会下降。平时看不出来,出事时就会很明显。

5. 把「人际交流」从随缘变成机制

如果我们是负责人,最重要的不是号召大家「多交流」,而是把交流做成机制,让它在 AI 加速的节奏下仍然成立。

5.1 明确:哪些事必须找人,哪些事默认找 AI

给团队一个简单的「分流规则」,避免两种极端:

  • 极端 A:什么都问人,人被打爆
  • 极端 B:什么都不问人,最后在合并时爆炸

可以直接定几条硬规则(按团队情况调整):

  • 涉及架构边界、接口契约、数据一致性、安全权限:必须找人评审/同步
  • 影响线上、影响成本、影响合规:必须找人
  • 只是工具用法、报错排查、脚手架生成:默认问 AI
  • 不确定是否该找人:先写清楚问题和已尝试的路径,再找人(减少沟通成本)

5.2 给资深工程师留出“可见的指导时间”

Anthropic 的访谈里已经出现了「新人不来问了」的信号。很多团队会误判:新人不问 = 新人更强。短期可能是,长期不一定。

更稳的做法是:

  • 每周固定一个短时段做 office hours(公开问答,不私聊)
  • 重要模块设定 design review/ADR(哪怕轻量)
  • 对“AI 生成的关键代码”设立更严格的 review 标准(不是反 AI,而是防止组织能力流失)

核心目标是:让“提问—讨论—形成共识”这条链继续存在,只是把低价值部分交给 AI。

5.3 把「AI 使用痕迹」纳入协作,而不是藏起来

现在很多人会私下反复与 AI 迭代,最后只给团队一个结果。协作成本反而上升,因为别人看不见过程,也不知道你为什么这么做。

我们可以要求(或鼓励)大家在 PR/设计文档里补两类信息:

  • 关键决策的备选方案与取舍(哪怕两三条)
  • 风险点和验证方式(你如何确认它是对的)

这会让交流更少但更高质量。

5.4 允许「必要的慢」

关键能力要刻意练

团队层面可以做这些:

  • 对核心链路、核心组件:要求成员能解释清楚,而不是「AI 说的」
  • 对新人:阶段性要求手写/手推一些关键部分,确保他们能监督 AI,而不是被 AI 带着跑
  • 对事故复盘:强调人对系统的理解沉淀,而不是贴一段 AI 总结

目标不是回到过去,而是让团队保持「监督能力」。

6. 我们能做点什么

如果我是工程师,交流减少对我最直接的影响通常是两点:我变快了,但我更孤立了。要避免后者,方法也不复杂。

6.1 让 AI 解决「问题」,让人参与「判断」

我们可以默认把下面这些交给 AI:

  • 解释陌生代码
  • 查资料、列步骤
  • 生成脚手架
  • 写测试样例的初稿
  • 重复性重构

但遇到这些场景,建议尽量把人拉进来:

  • 需要在多个方案之间做取舍
  • 觉得“有点不对劲但说不上来”
  • 要改动一个并不拥有的模块
  • 担心引入隐性风险(安全、性能、成本、可维护性)

AI 很会「给你一个能跑的答案」,但很多线上事故的起点就是“能跑”。

6.2 主动经营「被看见的贡献」

当大家都在本地和 AI 加速时,团队很容易只看到结果,看不到难度。我们需要更明确地让别人理解我们的贡献是什么,尤其在:

  • 做的是“减少未来成本”的事(可观测性、稳定性、性能、可维护性)
  • 修的是“papercuts”(Anthropic 也提到 Claude Code 里 8.6% 的任务属于这类小修小补)

这些工作如果不被看见,组织很容易把它们当作「AI 随手做的」,从而压缩这类投入,最后反噬效率。

6.3 保留与同事的「低成本连接」

不需要刻意社交,也不用强迫自己多聊。最实用的是维持低成本连接,比如:

  • 每周一次简短同步:在做什么、接下来风险是什么、需要谁拍板
  • 关键节点提前说:我准备这么改,谁最该看一眼
  • 把求助写成可复用的文本:背景、现象、试过什么、倾向的方案

这样不会回到「到处问人」,但也不会变成“「独自和 AI 闭门造车」。

7. 小结

交流减少本身不是问题,但当交流减少以失去组织能力时这会是一个问题,而且还是一个大的问题。

「人与人的交流减少」这件事,短期几乎一定会发生,因为它符合成本与效率逻辑。Anthropic 的内部研究把这种变化讲得很直白:AI 正在成为第一入口,很多例行沟通会被替代,协作结构会重排。

真正需要在意的是:

  • 我们减少的是不是那些本来就该被自动化吞掉的交流
  • 我们有没有保留决策对齐、经验传承、风险评审这些「组织能力」的通道
  • 当每个人都能更快产出时,我们的团队是否还能形成一致的标准与判断

如果这些做到了,交流少一点通常是好事:更少打扰、更少等待、更高产出。
如果这些没做到,交流少一点会变成隐性负债:新人长得快但根不稳,系统跑得快但风险更高,团队看起来忙但共识更薄。

参考资料

以上。

AI 编程的真相:一个老程序员的冷静观察

如果你是一名程序员,最近一两年肯定被各种 AI 编程工具刷屏了。从 GitHub Copilot 到 Cursor,到今年国内出的 Trae,以及最近发布的为提升 AI 编程效率而生的 Claude Code,还有国内的通义灵码等等,简直让人眼花缭乱。

身边不少同事和朋友都已经用上了,有人说效率翻倍,有人说就是个高级的代码补全。在网上也看到许多争论,如程序员会不会被 AI 取代等等话题。

作为一个在一线写了十多年代码的人,我想聊聊自己的观察和思考。这篇文章不是要唱衰 AI,也不是要贩卖焦虑,而是想分析一下当前 AI 编程的真实情况。

今天主要聊两块:LLM 的固有局限、这些局限在编程领域的具体表现,应对策略我们下一篇文章再聊。

1. LLM 的天生缺陷

要理解 AI 编程的问题,得先搞清楚底层的大语言模型(LLM)有哪些局限。这些局限不是某个产品的 bug,而是当前技术架构的固有特性。

1.1 概率预测的本质

LLM 说到底是个概率模型。它的工作原理是根据上下文,预测下一个最可能出现的词。注意,是「最可能」,不是「最正确」。

这就像一个特别会察言观色的人,能根据前面的对话猜出你想听什么,但他并不真正理解你们在聊什么。大部分时候猜得挺准,偶尔也会离谱到家。

在写作、聊天这种场景下,这种「猜测」问题不大,甚至还能带来一些创意。但在编程这种需要 100% 精确的领域,问题就来了,这就是我们所说的 LLM 的幻觉。

以编程为例,AI 可能会「发明」一个当前环境中并不存在的库函数,或者一本正经地告诉你某个框架有某种你从未听说过的特性。例如,你让它用一个小型库 mini-lib 写个功能,它可能会自信地写下 mini-lib.complex_function(),而这个函数实际上只存在于它通过模式匹配「幻想」出的世界里。这种随机性在创意写作中是火花,但在编程中就是地雷。一个分号、一个等号、一个大于号的随机错误,都可能导致程序编译失败、运行崩溃或产生灾难性的计算错误。

LLM 的本质是一个概率预测引擎,而不是一个事实检索数据库。它的核心任务是基于海量训练数据,「猜」下一个 token 是什么最合理,而不是「下一个 token 是什么最真实」。它的训练数据中包含了海量的代码和文档,当它发现很多库都有 .complex_function() 这种模式时,它就会推断 mini-lib 可能也有,从而生成一个语法通顺但功能无效的代码。它追求的是「看起来对」,而不是「真的对」。

1.2 知识的时间窗口

训练一个大模型需要几个月时间和巨额成本,所以模型的知识总是滞后的。比如 Claude 的知识截止到 2025 年 1 月,那么 2 月份发布的新框架、新 API,它就完全不知道。

对于技术更新速度极快的编程领域,这是个大问题。React 19 出了新特性,Node.js 又发布了新版本,某个常用库爆出了安全漏洞……这些信息,AI 都无法及时获取。

虽然可以通过 RAG/Agent 等技术缓解,但这更像是在给一个旧大脑外挂一个「实时信息提示器」,而非大脑本身的更新。

对于技术迭代比翻书还快的软件开发领域,依赖一个「活在过去」的工具,无异于拿着旧地图在新世界航行。更危险的是,它可能会自信地推荐一个已经停止维护、或者已知存在 CVE 的第三方依赖库,从而出现安全隐患。

1.3 上下文窗口限制

这个问题就像人的短期记忆一样。当我们和 AI 聊天聊久了,它会忘记开头说了什么。目前最好的模型,上下文窗口能达到百万级 token,能解决部分问题,但是也不够用。

对于动辄几十万、上百万行代码的现代开发项目,AI 就像一个只能通过门缝看房间的访客。它能看到门缝里的景象,但对整个房间的布局、风格和功能一无所知。开发者们常常抱怨 AI 编程工具「用着用着就变笨了」,根本原因就在于此。

1.4 缺乏真正的理解

这是最根本的问题。LLM 不理解代码的含义,它只是在模式匹配。

举个例子,当我们让 AI 写一个排序算法,它能写出完美的快排代码。但这不是因为它理解了「分治」的思想,而是因为训练数据里有大量类似的代码,它学会了这个模式。

一旦遇到需要真正理解业务逻辑、需要创新思维的场景,AI 就可能搞不定了。

2. 编程领域的具体挑战

上面这些通用局限,在编程领域会被急剧放大,产生一些特有的问题。

2.1 错误的放大效应

我们知道人是有容错能力的,如这张图,汉字顺序错了,我们也能读懂。

写文章错个字,读者能看懂。但代码里少个分号、多个逗号,程序直接跑不起来。更要命的是逻辑错误,比如边界条件判断错了,可能测试都能通过,上线后才爆雷。

我见过 AI 生成的代码,把 < 写成 <=,导致数组越界。还有在金融计算中使用浮点数,精度问题累积后造成账目对不上。这些都是看起来微小,实际后果严重的错误。

2.2 安全漏洞

这个问题相当严重。研究显示,AI 生成的代码中,包含安全漏洞的比例明显高于人工编写的代码。

原因很简单:

  • 训练数据本身就包含大量有漏洞的代码
  • AI 不理解什么是「安全」,只知道完成功能
  • 很多老旧的、不安全的编码模式被 AI 学习并复现

最常见的问题包括 SQL 注入、XSS、路径遍历等。AI 可能会直接把用户输入拼接到 SQL 语句里,或者在处理文件上传时不做任何验证。除非特别要求。

我们在实际写代码过程中,正向逻辑往往并不是花时间最多的,最复杂的就是边界,异常和特殊情况

2.3 项目上下文的缺失

真实的项目开发不是写独立的函数,而是在一个复杂的系统中工作。每个项目都有自己的:

  • 代码规范和风格
  • 架构设计和模式
  • 业务领域知识
  • 自定义的工具类和框架

AI 看不到这些全貌,经常会:

  • 重复造轮子(明明有现成的工具类不用)
  • 违背架构原则(在该用依赖注入的地方直接 new 对象)
  • 误用内部 API(不理解接口的设计意图)

2.4 代码质量和可维护性

AI 生成的代码往往追求「能跑就行」,但忽略了可读性和可维护性。常见问题包括:

  • 过度复杂的嵌套和链式调用
  • 缺乏有意义的变量名和注释
  • 不符合团队的编码规范
  • 没有考虑扩展性和重用性

当我们习惯了 AI 写代码,可能会不想去看代码(自信点,就是不想看),如果这样过度依赖 AI,可能会失去对代码的深度理解。当需要调试或优化时,面对一堆自己没真正理解的代码,问题就会比较大,甚至出了问题还需要现场看代码来定位问题。

小结

写了这么多,核心观点其实很简单 :AI 编程工具是很强大,但也有明显的局限性。我们需要清醒地认识这些局限,合理地使用工具,同时不断提升自己的核心能力。

代码是我们与机器对话的语言,但写代码的意义,永远是为了解决人的问题。无论工具如何进化,这一点不会变。

所以,继续写代码吧,带着思考去写,带着责任去写。让 AI 成为你的助手,而不是你的拐杖。

毕竟,最好的代码,永远是有灵魂的代码,在写代码中注入心流。

以上。