最近新上了 Opus 4.6 ，它又给我们这帮老程序员上了一课。

在一个近一年没有迭代（指没有被封）的程序员群里，有大佬分享了如下的案例：

团队有个复杂遗留系统，典型「多线程 + 历史包袱 + 不敢动」组合。模型先给了一个方案：加锁、等待、条件变量、再加一层保护，几百行代码，逻辑像一团湿毛线。能跑，理论上也对，但你让我把这玩意儿上线？我不敢。

我让它「再想想，能不能避免这些锁和等待」。它又跑了很久，最后给了一个极简方案：之前那些锁啊等待啊都删了，思路干净到让我怀疑它刚才在干嘛。

那一刻我脑子里冒出来的不是「AI 真强」，而是一个更别扭的问题：

我到底起了什么价值？

背景上下文？它从代码库里能 infer 掉绝大多数。设计约束？很多也能从调用关系、线程模型、运行时指标推出来。所谓「design taste」？我甚至可以写成 Markdown 规则让它照做。

过去资深开发的硬价值之一是 reasoning 的过程：拆问题、找不变量、选折中、落地细节。现在模型也能做，还能做得很快。

我绕了一圈，最后落在一个很不体面的结论上：人的价值被压缩到极小概率的「否决权」里。

99% 的时候，我是在给 AI 的解「盖萝卜章」：嗯，看起来没错。
剩下那 1% 的时候，我得站出来说：不行，这条路走不通，换解空间里的另一个点。

这个角色像保险。你买的时候就知道大概率用不上，但真出事的时候要能扛住。更像现在的 L2-L4 自动驾驶：人坐在方向盘前，99.9% 的时间无事可做，为了那 0.1% 的「可能发生也可能不发生」。

问题来了：这 1% 会不会也被另一个 agent 替掉？再给一个「专职 reviewer」去 challenge 写代码的 agent，让它把那 1% 找出来。

那人还剩什么？

以及这会把程序员的岗位推向哪里。

很多讨论卡在「AI 写代码快，所以程序员要失业」这种口号里。工程上更真实的变化是两条曲线的剪刀差：

• 代码生成成本下降得很快：写一段能跑的实现、补齐样板、迁移接口、写单元测试骨架，这些都接近「文本补全」。
• 承担后果的成本上升：上线事故、性能回退、并发死锁、数据一致性破坏、合规风险、供应链安全。AI 让改动频率变高，系统的「变更面」变大，出事概率跟着涨。

我现在看 AI 产出的 patch，经常有一种荒诞感：
改动本身很漂亮，解释也很漂亮，真正要命的点藏在「系统级不变量」里，而那部分恰好最难被 prompt 描述清楚，也最难被静态检查覆盖。

所以讨论「程序员价值」别从「写代码」切入，从「为系统负责」切入。写代码只是责任链条里最便宜的一环。

聊回到前面大佬分享的案例。

为什么模型会先给「复杂加锁方案」，再给「极简方案」

这不是模型「变聪明了」，更像搜索策略切换。

我自己复盘过很多次类似现象，模型第一次给复杂方案，常见原因有几类：

• 目标函数不清：模型默认把「不出错」权重大幅拉高，并发问题里，模型的默认倾向是「保守」：能锁就锁，能等就等。因为它无法确认你的系统允不允许重构线程模型，也不知道你能承受多少延迟和吞吐损失。一句「能不能避免」其实是在改目标函数：把「简单性」和「可维护性」的权重抬起来，把「局部可证明正确」的偏好压下去。

• 它没拿到关键不变量：并发优化的核心不是技巧，是不变量。例如：哪些数据必须线性一致，哪些允许最终一致；哪些操作必须串行化，哪些可以交换；线程间共享状态的「所有权」到底属于谁；是否存在天然的「单 writer」路径。模型第一次通常拿不到这些，它会用锁把未知包起来。你追问一次，相当于逼它去反推不变量，或者提出重构以创造不变量。

• 在「局部最优」里打转：遗留系统经常有局部约束：你动不了某个模块，改不了调用方，不能引入新队列，不能改变线程亲和性。

人的价值最终会被压到 1%

这事已经发生了。

如果把「写实现」交给模型，人还剩什么？

我现在更愿意把角色拆成四层，分别看哪些会被自动化吃掉：

1. 执行层：写 CRUD、搬接口、补样板、按规范改文件结构
   这层基本被吃穿。
2. 局部推理层：读一段代码、定位 bug、做局部重构
   这层大幅被压缩，速度优势在模型。
3. 系统推理层：跨模块不变量、性能上界、故障模式、发布策略、回滚路径
   这层短期很难完全自动化，原因是信息不完备且目标冲突。
4. 责任层：线上事故谁背、合规谁签、业务损失谁扛
   这层本质是组织结构问题，不是智能问题。

很多资深工程师过去主要靠第 2 层吃饭：你会拆、会想、会写出「更优雅」的实现。现在模型把这层的边际价值压得很薄，于是人的价值看起来就剩「在模型犯错时否决」。

这就引出一个很工程的问题：能不能用另一个 agent 把「否决」也自动化？

答案是：能覆盖很大一部分，但永远留洞。洞的大小取决于你怎么搭系统。

那 1% 到底是什么：哪些场景必须有人类 override

我现在把「必须 override」的场景分成几类，每一类都对应一套工程信号。我们可以用这些信号去训练 reviewer agent，也可以用来提醒自己别当「只会点 approve 的人」。

• 需求语义存在空洞，代码再正确也没意义：常见现象： PR 描述是「修复偶现 bug」，但没有可复现条件，没有失败判据；业务方说「按之前逻辑」，但「之前逻辑」存在灰度分支、历史例外。这类问题 AI 很难凭空补齐。它会把空洞当成「默认值」，然后写出一份自洽的实现。你看起来也挑不出毛病，直到线上行为偏了。override 的动作往往不是改代码，而是卡住合并，逼需求补齐验收条件和反例。
• 系统级不变量被破坏，局部看不出，全局会炸：典型不变量：

  • 计费、库存、资金流的幂等与去重
  • 订单状态机的单向性
  • 写路径单 writer，读路径可并发
  • 缓存一致性策略：写穿、失效、双写窗口
  • SLA 约束下的超时与重试预算

模型能理解这些词，但它很难知道「你们公司真实的不变量是什么」。很多不变量写在事故复盘里，写在某个老同事的脑子里，写在那段「不要动」的注释里。

override 的动作通常是把不变量显式化：写进 ADR（架构决策记录）、写进测试、写进发布 checklist。写完再让模型改。

• 代价函数冲突：延迟、吞吐、成本、可维护性互相打架这些对尾延迟很要命。你让它「简单化」以后，它可能会走向另一个极端：过度重构，侵入面太大，风险高得离谱。这类冲突靠 prompt 很难一次调对，得靠基准测试 + 真实流量回放。人类 override 的价值在于：你知道线上哪条曲线最敏感，知道预算是多少，知道哪里可以牺牲。

• 生产环境的「脏现实」：测试覆盖不到 包括但不限于：

• 时钟漂移、时区、闰秒
• 依赖服务的抖动、限流、半开连接
• 数据脏写、历史脏数据格式
• 热点 key、倾斜分片、长尾用户行为
• 灰度期间的双版本共存

AI 可以写出很干净的逻辑，干净得像从未上过线。

人类 override 的价值在于：你知道哪些脏东西真实存在，知道一旦触发会损失多少钱。

• 安全与合规：模型会「帮你越线」

安全问题里最阴的是「看起来像优化」：

• 为了排查问题把敏感字段打进日志
• 为了方便把权限校验挪到上层，结果漏掉某些调用路径
• 为了提高命中率调整缓存 key，结果造成跨租户数据串读

这类问题 reviewer agent 能抓一部分，靠规则匹配和数据流分析。但组织里真正要命的合规约束往往来自外部：合同、监管、审计口径。模型很难内建你们的合同条款。

只留了 1%，那么大公司删人游戏才刚开始，接下来组织会怎么变？有前司裁员了一半。

AI 带来了两件具体的事：

• 单位时间的变更量上升
• 对稳定性与合规的要求不会下降

组织会自然把资源往两端挤压：

• 一端是「产出变更」的能力：更少的人能产出更多 patch
• 另一端是「控制风险」的能力：测试、发布、SRE、安全、平台工程会更吃香

中间那层「靠手写实现体现资深」的位置，会被挤得很难受。我们会看到更多岗位变成：

• 平台/工具链负责人
• 质量与发布工程负责人
• 架构与技术治理（不变量、规范、依赖治理）
• 领域负责人（把业务语义写成可执行的约束）

如果还把价值押在「我写得快、我写得优雅」，会被模型直接碾过去。

那我们该何去何从？

我更建议把自己训练成「系统负责人」，别训练成「提示词手艺人」

很多人看到 AI 就去卷 prompt。prompt 当然有用，但它属于「表达能力」，不属于「护城河」。

我更建议把成长路线拆成三条，按你自己的背景选一条主线，另外两条补短板。

路线 A：系统与可靠性（适合后端、架构、TL） 要能回答这些问题：

• 这个系统的核心不变量是什么？写在哪里？谁维护？
• 出了事故，最可能的故障模式是哪几类？怎么提前打点？
• 一次改动上线，回滚点在哪里？数据怎么保证不被写坏？

这条路线的硬技能是：可观测性、故障注入、容量规划、发布治理、数据一致性策略。
AI 会让这条路线更值钱，因为改动变多，风险更高。

路线 B：平台与工具链（适合喜欢搞基建的人） 把「盖章」自动化掉。

要能把下面这些做成产品：

• 代码生成与改动的规范化输入（任务模板、约束模板）
• 自动化评审（多 agent + 规则 + 静态分析 + 安全扫描）
• 针对你们域的测试体系（尤其是并发、回归、流量回放）
• 一键灰度、一键回滚、发布可视化

这条路线的本质是：把工程经验固化成流水线能力。模型越强，平台越重要。

路线 C：领域语义与业务工程（适合对业务理解深的人） AI 最弱的地方之一是「公司特有的业务语义」。能把语义变成约束，价值就会变硬。

要能做的是：

• 把业务规则写成状态机与不变量
• 把验收条件变成测试与监控
• 把历史例外收敛掉，减少「口口相传」

这条路线听上去不像「技术」，但在 AI 时代，它会决定你是不是不可替代的那批人。

我不押「永远需要人」这种安全说法。我更愿意给一个工程化的判断：

• 在约束清晰、环境封闭、回滚容易的系统里，人类接管的概率会持续下降。很多内部工具、数据管道、非核心链路会率先做到「几乎无人值守」。
• 在约束隐含、环境开放、后果昂贵的系统里，1% 会长期存在。典型是资金、合规、核心交易链路、跨组织协作系统。这里的问题从来不只是智能，还包括责任与审计。

更关键的一点：就算模型能覆盖 99.99%，组织也未必允许完全无人。原因很现实：责任链条需要一个签字的人。

我写到这里，还是没法给一个让人舒服的答案。AI 把很多我们曾经引以为傲的能力变成了廉价品，这是事实。难受也正常。

但工程世界一向认结果。模型写得再快，只要系统一炸，组织就会把注意力拉回到「谁能把它跑住」。把自己训练成能跑住系统的人，价值就不会跟着 token 价格一起下跌。

以上。

去年 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 编程在团队越来越普及，猛然发现一个正在变得「习以为常」的变化：以前遇到问题，第一反应是问同事或 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 正在成为第一入口，很多例行沟通会被替代，协作结构会重排。

真正需要在意的是：

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

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

参考资料

• How AI Is Transforming Work at Anthropic

以上。

身边不少同事和朋友都已经用上了，有人说效率翻倍，有人说就是个高级的代码补全。在网上也看到许多争论，如程序员会不会被 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 成为你的助手，而不是你的拐杖。

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

以上。

在实际开发中，我们经常会碰到这样的场景：产品展示页面的布局已经完成，各个模块都已就位，唯独缺少产品图片。而此时设计团队反馈：「图片素材还在制作中，预计下周交付。」

另一种常见情况是，在调试图片列表的响应式布局时，需要各种尺寸的测试图片。传统做法是通过搜索引擎寻找合适的图片，然后逐一下载、裁剪、调整尺寸。这个过程往往耗时良久，严重影响开发效率。

除了效率问题，版权风险也不容忽视。在项目中使用网络图片时，我们必须考虑：这些图片是否有版权限制？是否适合在商业项目中使用？这些问题如果处理不当，可能会给项目带来法律风险。

还有一些场景，如我们动态生成图片，在图片上显示提示的内容这种相对小众的场景。

本周刚好有一个需求是给飞书捷径做一个小功能用到了图片占位生成。梳理完需求，大概如下：

1. 能指定宽和高
2. 能自定义文字
3. 能指定文本颜色和背景色
4. 能指定图片格式输出，支持 PNG
5. 能指定文本大小
6. 能在飞书中使用

首先我们看一下有哪些在线的图片占位生成器可用的。

我们先让最新的 Claude-4-Opus 大模型给出 10 个地址，如下图：

1. **Placeholder.com【不可用】**
- **URL**: https://via.placeholder.com/
- **使用方法**: `https://via.placeholder.com/300x200`
- **特点**: 简单易用，支持自定义颜色和文字

2. **Lorem Picsum【能用，随机真实图片】**
- **URL**: https://picsum.photos/
- **使用方法**: `https://picsum.photos/200/300`
- **特点**: 提供随机的高质量真实图片

3. **Placehold.it【跳到 Placeholder.com 也不可用了】**
- **URL**: https://placehold.it/
- **使用方法**: `https://placehold.it/350x150`
- **特点**: 经典的占位图服务，支持多种格式

4. **PlaceIMG【不可用】**
- **URL**: https://placeimg.com/
- **使用方法**: `https://placeimg.com/640/480/any`
- **特点**: 可选择不同类别（动物、建筑、自然等）

5. **Dummy Image【可用，不支持中文】**
- **URL**: https://dummyimage.com/
- **使用方法**: `https://dummyimage.com/600x400/000/fff`
- **特点**: 高度可定制，支持自定义背景色和文字颜色

6. **LoremFlickr【可用，不支持自定义内容】**
- **URL**: https://loremflickr.com/
- **使用方法**: `https://loremflickr.com/320/240`
- **特点**: 基于Flickr的真实图片，支持关键词搜索

7. **Placekitten【不可用】**
- **URL**: https://placekitten.com/
- **使用方法**: `https://placekitten.com/200/300`
- **特点**: 提供可爱的猫咪图片作为占位图

8. **Unsplash Source【不可用】**
- **URL**: https://source.unsplash.com/
- **使用方法**: `https://source.unsplash.com/1600x900/?nature`
- **特点**: 使用Unsplash的高质量图片库

9. **PlaceBear【可用，不支持自定义内容】**
- **URL**: https://placebear.com/
- **使用方法**: `https://placebear.com/200/300`
- **特点**: 提供熊的图片作为占位图

10. **FakeIMG.pl【可用，不支持中文】**
- **URL**: https://fakeimg.pl/
- **使用方法**: `https://fakeimg.pl/300x200/ff0000/ffffff?text=Hello`
- **特点**: 支持自定义文字、字体和颜色

以上 10 个站点看下来，就 1 和 5 相对符合需求，但都不支持中文。

AI 不行，搜索来凑，一顿 Goole 下来，又找到以下的几个：

1.http://placehold.co【可用，不支持中文】

示例：https://placehold.co/600×400?text=Hello+World

2.fakeimg.pl

示例：https://fakeimg.pl/300/?text=哈哈&font=noto

fakeimg.pl 在功能上需求都能满足，不管是大小、字体、中文，但是它在飞书中作为附件使用的时候竟然出错了。使用 dummyimage 却没有这个问题。 试了几次发现怎么都绕不过去，只能另想他法。

3.tool.lu

示例：https://iph.href.lu/600×400?text=哈哈哈

tool.lu 的图片占位功能能完全满足需求，但是和 2 一样，在飞书下会报错。

4.devtool.tech

界面最好的一个生成站点，但是格式是 SVG 的

以上只是基本可用的，还不排除那些功能不满足，失效了的，各种，折腾了两个小时，能满足需求的飞书用不了，飞书能用的不支持中文，死循环了。

只能自己撸了。

祭出 AI，花了两小时（代码只花了半小时，还包括框架搭建），本地运行没有问题，把代码部署到线上，能正常显示，但是飞书用不了，一样的报错：

execute error，捷径执行出错：
Error: execute原始执行结果：
捷径返回错误码： FieldCode.Success 
 转换结果：transform cell value fail

这回是自己写的代码，终于可以定位并解决问题了。对比能用的地址和不能用的地址，从头文件中发现了两个字段的差别，一个是跨域：Access-Control-Allow-Origin，一个是返回长度：Content-Length

最终试验发现是：Content-Length

可能飞书在获取图片并上传成附件的时候做了判断或者校验（就是个 BUG）。

这个功能已经作为免费的服务放到了开发哥网站（还记得之前 Vibe Coding 写的那个网站不）：

https://www.kaifage.com/tools/placeholder

以上。

多说一句，即梦 3.0 生图中的汉字越来越精细了。

面对 Copilot/IDE 们日益强大的能力，许多开发者或许感到兴奋，或许也夹杂着一丝焦虑：当 AI 能写代码、能查 Bug 时，我们开发者的核心价值将何去何从？

仅仅将 AI 视为提升编码效率的「高级自动补全」工具，是对这场深刻变革的误读。真正的挑战与机遇并存，它要求我们进行一次根本性的思维转变。如果仍然固守着传统的、以手动实现细节为主的工作模式，我们很可能错失 AI 带来的巨大红利，甚至在未来逐渐失去竞争力。这不再是简单地学习一个新工具，而是需要重塑我们的工作哲学和核心能力。

今天我们将聊一下 4 个关键的思维转变和实践框架

• 「AI 优先」 的工作流整合
• 「指挥官思维」 的战略主导
• 「向 AI 学习」 的持续进化态度
• 构建高效「人机协同」复合框架的必要性

1. AI 优先

AI 优先是重新定义开发工作流的战略基石。

1.1 核心内涵：从默认手动到优先 AI 协作

「AI 优先」并非仅仅倡导使用 AI 工具，而是一种根本性的工作流程哲学和问题解决范式的转变。

其核心在于，当我们启动任何一项开发过程中的任务——无论是需求分析、架构设计、编码实现、代码审查、联调测试、用例生成、文档撰写，还是技术学习与研究——首要的、默认的思维步骤是主动评估：「 AI 在此环节能扮演何种角色？如何利用 AI 来提升任务执行的效率、质量或创新性？」 这与传统模式形成鲜明对比，后者往往默认以纯粹的人力手动操作为起点，仅在遇到特定瓶颈时才考虑引入自动化或辅助工具。AI 优先将 AI 从「备选项」提升到了「首选项」，要求我们在流程伊始就将其视为潜在的核心协作者。

1.2 思维转变的深度体现

• 主动整合  vs. 被动应用 :

  • 深度解析: 这标志着我们与技术生态关系的质变。过去，我们可能在 IDE 中使用代码补全，或在遇到难题时搜索特定库的 AI 辅助工具。这是一种响应式、孤立式的应用。而「AI 优先」要求前瞻性、系统性地思考如何将 AI 能力内嵌到整个开发流程中。我们不再是被动等待工具推送建议，而是主动设计包含 AI 交互点的新型工作流。这需要我们具备流程再造的意识，识别出 AI 最具潜力的介入点，并优化人机交互模式。
  • 战略意义: 将 AI 视为开发环境的一等公民，而非外挂插件。这种主动整合是最大化 AI 价值、构建复合智能开发体系的前提。

• 效率导向 & 认知资源重分配:

  • 深度解析: AI 优先的直接目标是显著提升开发效率，但这并非终点。通过将重复性、模式化、信息密集型的任务（如生成样板代码、查找 API 细节、初步代码审查、基础测试生成）委托给 AI，我们得以将宝贵的认知资源 从繁琐的底层细节中解放出来。这种解放并非为了减少工作量，而是为了战略性地聚焦于更高价值的活动，这与「从细节实现到架构设计与问题分解」的转变一脉相承。
  • 战略意义: 提升的不仅是速度，更是我们价值的跃迁。我们能投入更多精力于理解业务需求、进行复杂的系统设计、处理非结构化问题、进行创新性探索以及做出关键性技术决策，这些是 AI 短期内难以完全替代的核心人类优势。

• 工具熟练度 & 能力边界认知:

  • 深度解析: 实践「AI 优先」绝非盲目依赖。它要求我们不仅熟练掌握各种 AI 开发工具（如 Copilot, ChatGPT, Cursor, 各类 AI 驱动的测试/调试平台等）的具体操作，更要深刻理解其能力边界、适用场景、潜在偏见和局限性。这包括：知道何时 AI 的建议可靠，何时需要批判性审视；理解不同模型在不同任务上的表现差异；掌握有效的提示工程 技巧以引导 AI 产出高质量结果；并了解 AI 输出可能存在的安全风险或合规问题。
  • 战略意义: 熟练度意味着精准驾驭，意味着我们需要成为聪明的「AI 用户」，能够根据任务特性选择最合适的 AI 工具和交互策略，并对结果进行有效验证和整合，确保最终产出的质量和可靠性。这是一种新的核心技能。

1.3 实践示例

「AI 优先」在实践中并非意味着所有步骤都由 AI 完成，而是以 AI 作为起点：

• 用 AI 初始代码框架: 不仅是生成基础结构，更可以利用 AI 快速探索多种实现方案，或根据特定设计模式生成初步代码，极大加速原型构建和技术选型验证。
• 让 AI 解释错误信息或提出修复建议: 超越简单的错误信息查找，可以要求 AI 结合上下文代码分析潜在的根本原因，甚至预测可能相关的其他问题区域，提供更深层次的洞察。
• 使用 AI 生成单元测试: 不仅是覆盖基础路径，可以利用 AI 探索边缘情况和异常输入，提升测试覆盖率和鲁棒性，甚至根据代码变更智能推荐需要更新的测试用例。
• 通过 AI 快速学习一个新的 API 或库的用法: 从简单的用法查询，到要求 AI 提供示例项目、对比相似库、解释设计哲学、甚至模拟一个小型应用场景，实现更高效、更深入的即时学习。
• 在设计阶段，询问 AI 关于不同架构模式的优缺点: 将 AI 作为技术顾问或「虚拟专家」，快速获取关于不同架构选择（如微服务 vs. 单体，不同数据库选型）在特定场景下的利弊分析、潜在挑战、行业最佳实践等信息，辅助决策制定。

「AI 优先」是一种要求我们在思维层面将 AI 视为默认协作者，在实践层面主动将 AI 整合进工作流程，并以提升效率和聚焦高价值活动为导向，同时具备对 AI 工具的深度理解和批判性使用能力的方法论。采纳「AI 优先」意味着我们正从传统的「工匠」角色，向着更具战略眼光的「技术架构师」和「智能系统构建者」进化。

2. 指挥官思维

指挥官思维是驾驭人机协同的战略核心。

2.1 核心内涵：从执行者到战略决策者的角色升维

「指挥官思维」定义了我们在与 AI 深度协作环境下的核心定位与责任模型。

尽管 AI 工具（如大型语言模型、AI 编程器）展现出强大的自动化执行能力，我们并非沦为被动的指令接收者或简单的工具操作员，而是必须承担起战略主导者的角色。

这种思维模式要求我们能够掌握全局，负责设定目标、制定实施策略、进行任务的有效分解与委派、设计并下达高质量、精确的指令（即提示工程）、对 AI 的产出进行严格的审视与评估、基于评估结果做出关键技术决策，并最终对项目或产品的整体质量、安全性、性能及业务价值承担最终责任。

在这个模型中，AI 是能力强大的「智能执行单元」或「高级参谋」，提供信息、生成方案、执行具体任务，但最终的判断权、决策权和方向掌控权牢牢掌握在我们手中。

2.2 思维转变的深度体现

• 战略高度 vs. 细节沉溺:

  • 深度解析: 这与我们从「关注具体代码行实现」向「聚焦架构设计与复杂问题分解」的核心转变完美契合。「指挥官」的首要职责是理解并服务于业务目标 和系统级的非功能性需求（如可扩展性、可靠性、安全性、可维护性）。他们关注的是「战役」的胜利（例如，交付具有市场竞争力的产品、构建高可用的系统等等），而不是纠结于每一行代码的具体写法（这是可以有效利用 AI 的地方）。这意味着我们需要具备更强的系统思维 能力，能够从宏观层面规划技术蓝图、识别关键风险、权衡不同的架构选项。
  • 战略意义: 这种视角的提升使得我们能够利用 AI 处理大量的实现细节，从而将精力集中在设计决策、技术选型、风险管理和确保长期价值等更具战略意义的工作上，这些是决定项目成败的关键因素。

• 结果导向与批判性思维 vs. 盲目信任:

  • 深度解析: 「指挥官」的核心职责是确保任务目标的达成，并保证最终成果符合预定的质量标准。这直接对应了我们从「从零构建」到「侧重验证、调试与优化」的转变。鉴于当前 AI（尤其是生成式 AI）输出的非确定性 和潜在的「幻觉」、偏见、安全漏洞或性能陷阱，我们必须运用高度的批判性思维 和怀疑精神。对 AI 生成的代码、设计建议、测试用例等「战果」，需要进行多维度、深层次的审视：不仅要验证其功能正确性，还要评估其代码质量、可读性、效率、安全性、是否符合项目规范和最佳实践。
  • 战略意义: 这是确保 AI 协作安全、有效的关键保障。缺乏批判性思维的盲目采纳可能导致技术债、安全风险甚至项目失败。「指挥官」必须扮演好质量守门人 的角色，利用自己的专业知识和经验对 AI 的贡献进行筛选、修正和确认。

• 有效沟通（提示工程） vs. 模糊指令:

  • 深度解析: 「指挥官」向 AI 下达指令的过程，本质上是一种高精度的人机交互和知识传递。高质量的 Prompt 不仅仅是提出问题，而是需要精确定义任务目标、明确上下文信息、设定约束条件、提供示例、甚至指定输出格式。这要求我们具备优秀的需求分析和表达能力，能够将复杂的意图转化为 AI 可理解、可执行的清晰指令。这门新兴的技能——提示工程——正成为「指挥官思维」下的一项核心技术能力。
  • 战略意义: 指令的质量直接决定了 AI 输出的质量和效率。有效的沟通能够最大限度地发挥 AI 的潜力，减少反复试错和无效输出，从而显著提升协作效率。精通 Prompt Engineering 能够更精准地「指挥」AI，达成预期目标。

2.3 实践示例

「指挥官思维」在实践中转化为一系列具体的行动要求：

• 清晰地定义 AI 任务目标与约束条件: 不仅是「写一个登录函数」，而是「使用 OAuth 2.0 协议，实现一个安全的、支持多种第三方登录（Google, GitHub）、并符合公司现有 Python 代码规范和日志标准的登录模块」。明确的边界和要求是高质量输出的前提。
• 将复杂问题分解为 AI 可处理的子任务: 识别出大型任务中适合 AI 处理的模块化部分（如数据解析、API 调用封装、特定算法实现），设计清晰的接口，然后分别委派给 AI，最后由我们进行整合。这体现了模块化设计和任务管理能力。
• 提出精确、有效的 Prompt: 运用结构化 Prompt、提供背景知识、明确角色扮演（如「假设你是一位资深安全专家…」）、要求解释推理过程等高级技巧，引导 AI 产出更符合需求的、更高质量的内容。
• 批判性地审查 AI 的输出，识别潜在问题: 进行代码走查 (code review)、静态分析、动态测试、安全扫描，并结合自身领域知识判断方案的合理性、潜在风险和长期影响。绝不直接复制粘贴未经验证的代码。
• 整合 AI 的贡献，并做出最终的技术决策: 将 AI 生成的部分与人工编写的代码或其他系统组件有机结合，解决集成中可能出现的问题。基于对整体架构、业务需求和团队能力的综合考量，做出最终的技术选型、设计方案和实现路径的决策。我们始终是技术路线的最终拍板者和负责人。

「指挥官思维」是我们在 AI 时代保持主导地位和核心价值的关键。它要求我们超越纯粹的技术执行，提升到战略规划、任务设计、质量控制和决策制定的高度。通过有效地设定目标、分解任务、精准沟通（Prompting）、严格评估和最终决策，我们能够驾驭强大的 AI 能力，将其作为实现更宏大目标、创造更高价值的有力工具，从而在人机协同的新范式中扮演不可或缺的领导角色。

3. 向 AI 学习

向 AI 学习是构建人机协同的认知增强回路

3.1 核心内涵：从工具利用到知识伙伴的认知定位转变

「向 AI 学习」代表了一种深刻的认识论转变，它要求我们将 AI 从单纯的任务执行工具 提升为动态的知识伙伴 和个性化的学习资源。

其核心在于，我们在与 AI 交互的每一个环节——无论是获取代码建议、调试错误、探索设计方案，还是理解复杂概念——都保持一种主动的学习姿态。这意味着不仅要利用 AI 的输出来完成当前任务，更要有意识地从交互过程、AI 生成的内容及其背后的逻辑解释中提取、内化新的知识、技能、方法论或甚至不同的思维视角。这是一种将日常开发工作转化为持续学习和认知增强机会的态度。

3.2 思维转变的深度体现

• 持续学习与适应性的加速器:

  • 在技术栈日新月异、知识半衰期急剧缩短的当下，我们面临着前所未有的学习压力。传统的学习模式（如阅读文档、参加课程）往往存在时滞性或不够个性化。「向 AI 学习」直接关联并赋能了「从掌握特定语言/框架到理解核心概念与快速学习」这一关键转变。AI 可以作为一个即时响应、情境感知的学习引擎，根据我们当前遇到的具体问题或技术挑战，提供精准、个性化的知识输入。它能迅速填补知识空白，加速对新技术的理解和掌握，从而极大地提升我们的**适应性商数 (AQ)**。

  • 将学习过程无缝融入日常工作流，变被动追赶为主动适应，使我们能够更敏捷地跟上技术前沿，保持长期的专业竞争力。

• 拓展认知边界与激发创新思维:

  • 我们的知识和经验往往受限于个人背景、项目经历和信息接触范围。而 AI，特别是基于大型模型的 AI，其训练数据涵盖了极其广泛和多样化的知识语料库。当我们就某一问题向 AI 寻求解决方案时，AI 可能提供多种不同的实现路径、引入我们不熟悉的库或框架、或者应用某种新颖的设计模式。这种接触异质性信息 的过程，本身就能有效打破思维定势，拓展我们的技术视野。
  • AI 成为了一个创新的催化剂。通过展示不同的可能性，即使 AI 的某些建议并非最优或完全适用，也能激发我们产生新的想法，促进“创造力与创新思维”的发展，从而在解决问题时拥有更丰富的策略储备。

• 深化原理理解与构建心智模型:

  • 仅仅复制代码或接受建议而不求甚解，无法带来真正的能力提升。「向 AI 学习」强调要利用 AI 的解释能力。当 AI 生成一段代码、推荐一个架构或诊断一个错误时，主动追问「为什么」——「这段代码的底层逻辑是什么？」、「推荐这个库基于哪些权衡考量？」、「这个错误发生的根本原因是什么？」。通过引导 AI 进行逐步推理 或概念阐释，我们可以更深入地理解技术背后的原理、设计哲学和最佳实践，从而构建更准确、稳固的心智模型。
  • 从「知其然」到「知其所以然」的转变，是区分普通开发和资深专家的关键。通过 AI 辅助深化理解，我们能够更快地掌握技术的精髓，提升独立解决复杂问题的能力，并做出更明智的技术决策。

3.3 实践示例

将「向 AI 学习」融入实践，意味着采取一系列主动的认知行为：

• 将 AI 作为首要信息源: 在遇到不熟悉的技术术语、API 用法或编程范式时，优先向 AI 发起探询式提问，利用其快速响应和整合信息的能力。
• 利用 AI 进行方案比较分析: 要求 AI 对同一问题提供多种解决方案（例如，使用不同的算法、库或设计模式实现同一功能），并明确要求其分析各自的优缺点、适用场景和性能权衡，以此培养自身的评估能力和决策水平。
• 代码考古与模式识别: 仔细研究 AI 生成的代码，特别是其中包含自己不熟悉或感觉「新颖」的语法、库调用或设计结构的部分。将其视为学习地道用法 或高级技巧 的机会。
• 追问「为什么」——寻求解释与论证: 不满足于 AI 给出的答案，持续追问其生成逻辑、推荐依据或诊断原理。例如，「请解释你为什么选择在这里使用异步处理？」或「这个错误信息背后可能涉及哪些系统组件的交互？」
• 利用 AI 进行知识重构与整合: 在学习一个新领域后，可以要求 AI 帮助梳理知识体系、生成概念图、总结关键要点或创建速查表，利用 AI 的结构化能力巩固和组织所学知识。

「向 AI 学习」是一种将人机交互从单纯的任务执行提升为持续认知增强过程的关键思维模式。它要求开发者以主动、探究、批判的态度，将 AI 视为一个永不疲倦、知识渊博的学习伙伴。

通过有意识地利用 AI 的信息整合、多样化方案生成和解释能力，我们可以显著加速学习进程、拓宽技术视野、深化原理理解，最终在快速变化的技术环境中保持领先地位，实现个人能力的持续进化和增值。这不仅关乎技能提升，更关乎构建一种面向未来的、与智能共生的学习生态。

4. 构建「人机协同」的复合思维框架

构建「人机协同」的复合思维框架是驾驭复杂性的智能协作新范式。

4.1 核心内涵：超越工具使用，构建结构化的智能协作体系

构建「人机协同」的复合思维框架，并非简单地倡导与 AI 工具互动，而是旨在建立一套系统化、结构化、且动态适应的思维与行动模式，以应对日益复杂的开发任务和决策场景。

其核心前提是深刻认识到当前 AI（尤其是大型模型）与人类智能的互补性：AI 在处理大规模数据、识别模式、执行标准化、高通量任务方面展现出超凡能力；而人类则在理解模糊性、进行深度推理、运用常识与领域知识、把握上下文、进行价值判断、承担伦理责任以及处理非结构化、创新性问题方面拥有不可替代的优势。

因此，该框架的目标是设计并实践一种能够最大化人机双方优势、规避各自短板的协同工作体系，确保在 AI 深度参与的背景下，依然能高效、高质量、负责任地达成目标。

4.2 框架三大支柱

4.2.1 问题拆解能力

问题拆解能力是指将模糊意图转化为可执行智能任务。

这是人机高效协同的关键起点与接口。面对诸如「优化用户体验」或「构建一个新的推荐系统」这类高层次、往往带有歧义的业务需求时，我们必须运用深刻的领域理解、系统分析能力和逻辑思维，将其层层剖析、具体化，转化为一系列边界清晰、输入输出明确、AI 模型能够理解并着手处理的子任务。这个过程不仅是对复杂性的管理，更是将我们的抽象智慧「编译」成机器可执行指令的关键步骤。

这一能力的意义在于有效弥合人机之间的认知鸿沟。精确的子任务定义能够显著提升 AI 工具的应用效率和产出质量，避免因指令模糊导致的无效计算或结果偏差。同时，良好的问题拆解使得大型复杂项目变得可管理、可追踪、可并行化，开发者可以策略性地将某些定义良好的子任务（如数据清洗、特定算法实现、API 接口生成）委托给 AI，从而将自身精力聚焦于更高层次的架构设计、核心逻辑创新和跨模块集成上，实现整体研发效能的倍增。

实践中，这意味着我们需要像一位经验丰富的项目经理或系统架构师那样思考。例如，将「构建推荐系统”」解为：用户行为数据收集与清洗（可部分利用 AI）、特征工程（人机结合，AI 提取初步特征，人筛选优化）、候选集生成（利用 AI 实现多种召回策略，如协同过滤、内容相似度）、排序模型训练（利用 AI 平台进行模型选择与调优，人设定评估指标与业务目标）、A/B 测试框架搭建（AI 生成基础代码，人设计实验方案）以及最终效果评估与迭代（人主导分析，AI 辅助数据可视化）。每一步都明确了目标、输入、预期输出及人机角色，构成了协同的基础。

4.2.2 批判性验证意识

批判性验证意识是确保人机协同成果安全、可靠、负责任的核心保障。

鉴于当前 AI（尤其是生成式模型）固有的「幻觉」、潜在偏见、知识局限性以及对上下文理解的不完美性，其输出的内容——无论是代码片段、设计文档、测试用例还是分析报告——都绝不能被视为绝对真理而直接采纳。我们必须内化一种 「默认不信任，必须验证」的专业态度，将自己定位为 AI 产出的最终质量守门人。

这种意识要求我们运用自身的专业知识、逻辑推理能力、测试技能和行业最佳实践，对 AI 的「贡献」进行全面、深入、多维度的审视。这不仅包括检查功能是否正确、代码是否高效，更要评估其安全性（是否存在漏洞）、可维护性（是否易于理解和修改）、合规性（是否符合规范标准）、鲁棒性（边界情况处理如何）以及是否存在潜在的伦理风险或偏见。缺乏严格验证的盲目依赖，可能引入难以察觉的技术债、安全后门，甚至导致系统性失败，其后果远超 AI 带来的效率提升。

在实践层面，这意味着一套系统化的验证流程。例如，对 AI 生成的代码，需进行严格的 Code Review、单元测试、集成测试、静态代码分析、安全扫描和性能基准测试；对 AI 提供的技术方案，要评估其长期影响、可扩展性及与现有系统的兼容性；对 AI 生成的分析报告，需核查数据来源、验证关键论断、审视逻辑链条的完整性与合理性。这种批判性验证不仅是技术行为，更是我们专业精神和责任担当的体现，是构建可信赖 AI 应用的基石。

4.2.3 动态协作模式

动态协作模式强调人机协同并非固定模板，而是一种需要根据具体情境灵活调整的交互策略。

我们需要具备敏锐的情境感知能力和判断力，根据任务的性质（如标准化 vs. 创新性）、复杂度、风险等级、所需创造力程度、可用 AI 工具的能力边界以及时间限制等因素，动态地选择最合适的人机角色分配和互动方式。这要求我们对自身优势和 AI 能力有清晰认知，知道何时应该由人主导，何时可以放手让 AI 发挥，何时需要紧密的人机迭代。

这种动态调整的战略价值在于实现整体效能与质量的最优平衡。在处理常规、重复性高的任务时，可以采用「AI 辅助执行」模式，最大化效率；在面对需要深度分析和复杂决策的问题时，则切换到「AI 辅助决策」模式，利用 AI 的信息处理能力辅助人类判断；对于需要高度创新和战略规划的任务，则采用「人类主导 + AI 执行」或「探索性伙伴关系」模式，确保人类的创造力和智慧在关键环节发挥主导作用，同时利用 AI 加速探索和实现过程。这种灵活性使得团队能够更有效地配置资源，更好地管理风险，并更具弹性地应对各种挑战。

实践中，我们需要掌握一个协作模式，并学会在其间自如切换。例如，编写单元测试，可能初期让 AI 大量生成（AI 辅助执行），然后由人进行细致审查和补充边缘案例（批判性验证）；设计新功能架构时，可能先由人提出核心思路和约束，然后让 AI 提供几种备选方案及其优劣分析（AI 辅助决策），最终由人拍板并指导 AI 生成部分实现代码（人类主导 + AI 执行）；探索一个全新的技术领域时，则可能与 AI 进行反复对话、头脑风暴，共同迭代想法（探索性伙伴关系）。熟练掌握并运用这些动态模式，是我们从「AI 使用者」进化为「AI 协奏者」的关键标志。

构建「人机协同」的复合思维框架，是我们在 AI 时代实现能力跃迁和价值重塑的关键。它要求我们超越简单的工具使用者角色，成为一个能够战略性地分解问题、批判性地验证结果、并动态地调整协作模式的智能系统指挥者和设计者。

掌握这一框架，意味着能够有效地驾驭 AI 的力量，将其融入到创造性的、高质量的、负责任的价值创造过程中，从而在人机共生的未来中占据核心地位。这不仅是一种方法论，更是一种面向未来的核心素养和战略智慧。

AI 编程时代并非要取代程序员，而是要求程序员进化。我们需要从纯粹的代码编写者，转变为更高级的思考者、设计者、协作者、验证者和创新者。思维层面需要变得更宏观、更具批判性、更灵活、更关注价值创造，并始终保持学习和适应的心态。

以上。

最近一直在深度使用 AI 编程，从完全无代码的开发哥网站，到 AI 生成后台代码；从 Cursor 到 Trae AI，能明显感受到 AI 可以帮我写大量代码。最多的时候，5 个小时写了超过 2000 行可以运行的代码。但一个奇怪的感受是，尽管 AI 让代码生产更快了，软件开发的复杂度却没有降低，项目的构建需要的心力依然和以前一样。

这让我不禁思考：AI 真的在降低软件开发的复杂度吗？还是说，复杂度只是被转移了？

1. AI 编程 ≠ 复杂度消失，而是复杂度转移

在《人月神话》中，布鲁克斯提出了软件开发的四大本质复杂度：复杂度、一致性、可变性、不可见性。即使 AI 能够自动生成代码，这些复杂性依旧存在。

• 业务复杂性：AI 可以帮我们写代码，但它无法自动理解业务规则的变化。例如，一个 AI 生成的电商促销规则，可能在逻辑漏洞下导致「满 100 减 200」这样的错误，造成严重损失。
• 技术复杂性：AI 可以优化 SQL 查询、生成索引，但 AI 生成的代码仍然可能隐藏性能瓶颈，甚至带来更高的架构耦合度。
• 治理复杂性：AI 代码的可维护性、可解释性，仍然是一个巨大的挑战。AI 生成的代码往往不是“最优解”，而是“看起来能跑”的解。

AI 并没有消除软件开发的复杂度，而是将其转移到了其它的层面：

2. AI 让开发更快，但项目建设更复杂

布鲁克斯认为，软件开发的困难分为根本困难（Essential Complexity）和次要困难（Accidental Complexity）：

• 根本困难：软件本身的固有复杂性，不会因技术进步而消失。
• 次要困难：开发过程中人为引入的复杂性，如编程语言、工具、调试方式等，可以通过技术优化。

AI 编程 主要解决的是「次要困难」，但无法消除「根本困难」。让我们来看看布鲁克斯提出的软件开发四大根本困难，以及 AI 编程是否真的能克服它们。

2.1 复杂度（Complexity）

布鲁克斯认为，软件的复杂度源自以下几个因素：

• 组件交互的指数级增长（比如微服务架构）。
• 代码状态的激增（如并发编程）。
• 业务逻辑的无限变化（如金融风控规则）。
• 缺乏对整个系统的全局掌控能力。

AI 确实能快速生成代码，但它无法减少软件的业务复杂性。 例如：

• AI 可以帮你写一个支付系统的 API，但它无法理解跨境支付的法律法规，仍然需要人类去设计合规架构。
• AI 生成的代码可能没有考虑到以前没有见过异常情况，导致后期维护困难。

结论：AI 不会减少软件的复杂度，只是让代码生产更快，但架构和业务逻辑的复杂性依然存在。

2.2 一致性（Consistency）

软件必须兼容历史系统、旧数据、第三方 API 和用户习惯，这导致：

• 新系统必须适配旧架构。
• 代码风格和 API 设计必须保持一致。
• 数据格式、协议、接口规范不能随意更改。

AI 可能会破坏一致性，而不是增强一致性。

• AI 生成的代码风格可能不统一，团队成员需要额外时间进行重构。
• AI 可能会引入隐性的兼容性问题，导致老系统无法正常运行。

结论：AI 不能自动保证代码和系统的一致性，反而可能引入新的不兼容问题。

2.3 可变性（Changeability）

软件必须不断适应需求变化：

• 政策法规变化（如 GDPR 隐私保护要求）。
• 新业务功能增加（比如直播带货）。
• 技术栈升级或迁移（比如从 MySQL 迁移到 PostgreSQL 等）。

AI 确实可以加速代码变更，但它无法理解业务变更的深层逻辑：

• AI 可能会机械地替换代码，但不会思考整体架构是否需要调整。
• AI 可能会优化单个函数，但不会考虑整个系统的长期演进。

结论：AI 可以加速代码变更，但无法主动适应业务变化，反而可能增加技术债务。

2.4 不可见性（Invisibility）

软件不像建筑或者机械产品那样，可以从物理空间上直观理解。软件的结构是逻辑性的，导致：

• 沟通困难：不同开发者对系统的理解可能不同。
• 调试困难：AI 生成的代码可能变成「黑盒」，难以分析问题。
• 架构复杂化：AI 生成代码可能会引入隐形的设计缺陷。

结论：AI 代码的「黑盒性」可能让软件的可见性更差，导致调试和维护的挑战更大。

3. AI 编程的真正价值：降低「次要困难」

虽然 AI 无法消除软件的根本复杂度，但它确实在减少次要复杂度（Accidental Complexity），包括： ✔ 代码生成：AI 可以帮你写 CRUD、API、测试代码，提高开发效率。
✔ 调试辅助：AI 可以自动分析日志、找出潜在 Bug。
✔ 文档生成：AI 可以自动补充代码注释，提升可读性。
✔ 代码优化：AI 可以推荐更优的算法或 SQL 查询，提高性能。

但与此同时，AI 也引入了新的复杂度： ❌ Prompt 设计复杂度：如何写出好的 Prompt，才能让 AI 生成高质量代码？AI 代码质量很大程度上依赖于输入的提示（Prompt），这意味着开发者需要掌握新的技能，比如如何编写高质量的 Prompt。 ❌ AI 代码治理：如何审查 AI 生成的代码，防止安全漏洞？
❌ 技术债务：AI 可能会生成「能跑但难维护」的代码，如何管理长远的架构演进？ AI 可以帮助我们快速生成大量代码，但如何组织这些代码、保证架构的可维护性，仍然是开发者的责任。

4. 未来开发者的核心竞争力：驾驭 AI，而不是被 AI 取代

AI 编程时代，开发者的角色正在改变：

• 过去，开发者的价值在于写代码。
• 未来，开发者的价值在于驾驭代码复杂度，利用 AI 高效开发。

开发者的三大新技能

✅ 语义工程：如何用精准的 Prompt 让 AI 生成高质量代码？

• AI 代码质量的高低，取决于开发者如何设计 Prompt。
• 但 AI 无法判断哪种方案最适合当前业务场景，这仍然需要开发者的经验与判断。

✅ AI 代码治理：如何审核 AI 代码，防止技术债务？

• AI 代码可能会引入新的技术债务，比如：

  • 代码结构混乱，缺乏一致性
  • 逻辑错误难以发现
  • AI 生成的代码难以调试
• 未来，AI 代码审查（AI Code Review）可能会成为开发流程的新标准。

✅ 架构思维：如何让 AI 代码符合长期可维护的架构设计？

• 未来的开发者，需要具备更强的系统思维：

  • 如何拆解业务需求？
  • 如何设计可扩展的架构？
  • 如何管理 AI 代码的质量？
• 开发者需要从「被动写代码」转变为「主动设计系统」。

5. 结尾

AI 让代码生成变得简单，但软件架构仍然需要人类设计。

未来，AI 编程会让开发变得更加高效，但开发者的核心竞争力将不再是写代码，而是驾驭复杂度。

未来，AI 可能会替代低端的代码搬运工，但无法替代深刻理解复杂度的架构师。

「AI 不会取代开发者，但懂得驾驭 AI 的开发者，将取代那些不懂 AI 的人。」

以上。