全世界都在探索 AI 如何落地
这几年间，无数人、组织都在问同一个问题：AI 到底怎么落地？但是似乎无论是什么场景和项目，所谓落地，都会落到技术负责人头上。怎么回事儿？离了程序员，我还吃不上肉了？我现在就让 AI 自己写程序让自己落地！
无论是投资人、老板还是管理层，最终都会到一个是或者类似技术负责人的角色这里，他就是地。但问题并不是到他这里就结束了，问题又变成该买哪个模型、装哪个编码助手、接哪个知识库、搭几个 Agent。会开了一轮又一轮，演示做得一个比一个漂亮。一个需求丢进对话框，几分钟后，代码、测试、文档一应俱全。屏幕上一片绿色，提交记录飞快增长，月报里终于有了结果：赋能、提效。
然后系统上线了。
难堪的事情通常不会在演示当天出现。它可能是两周后的一次重复消费，也可能是三个月后没人敢动的抽象层；可能是流量上涨时突然耗尽的连接池，也可能是一次看似无害的超时重试压垮了下游。还有些故障更离谱：一项配置变更绕过了本就不严密的人工检查，最后让整个服务不可用。
事故群里不会有人再讨论提示词写得漂不漂亮。大家只会追问：影响范围多大？数据有没有错？能不能回滚？为什么监控没报？谁审的？
到这一步，AI 会迅速从会议室里的「先进生产力」，变回一个很普通的软件组件。它不承担值班，不解释损失，不面对客户，也不会因为自己写的代码让服务挂了而留下来陪你对账。最后登录机器、翻日志、做数据修复、写复盘的人，还是那批本来就忙不过来的工程师。
在《AI 带来的变革：能力变便宜之后，什么会变得更贵？》里写过一句话：代码产量不等于软件产量，软件产量更不等于用户价值。那篇文章谈的是能力变便宜以后，验证、选择、整合和责任会怎样变贵。这次不谈那么远，只看软件工程中：AI 进入需求、设计、编码、审查和上线流程以后，事情为什么远没有对话框里那么顺。
这篇文章的目的不是赞美、吹捧 AI，市面上已经有足够多的人展示它能做什么，工程团队更应该看看那些不太体面的地方：它经常在哪里失了分寸，怎样把成本藏到后面，又怎样给人一种并不可靠的安全感。尤其是一个原本就勉强运转的团队，引入 AI 后究竟会被推向哪里。
全世界确实都在探索 AI 如何落地。可很多人琢磨的只是怎样让模型再多干一点，而不是怎样搭起一套出了问题有人负责的生产系统。两种思路看似接近，做出来的东西可能完全不同。
一、软件工程思维
软件工程不是会写代码
一个模型可以很快写出一个 HTTP 接口。路由、参数校验、数据库查询、JSON 返回，甚至测试都像模像样。如果题目的边界足够清楚，这种任务确实容易得到一个能运行的结果。
可软件工程从来不只是让这一段代码运行。麻烦都藏在题目没有写出来的地方：
- 这个接口的超时预算是多少？
- 客户端断开后，后端任务是否还要继续？
- 写数据库成功、发消息失败时，系统留下什么状态？
- 请求重试是否会重复扣款、重复发货或重复创建资源？
- 一次查询返回十条数据和十万条数据时，内存行为是否相同？
- 这个抽象是为了隔离变化，还是为了把三行代码拆进六个文件？
- 两年后接手的人，能不能沿着一条清楚的路径找到业务规则？
这些问题没有统一答案。设计者得知道业务后果、运行环境、团队能力和历史包袱，再在一组相互冲突的目标中做取舍。模型能复述很多正确原则，却很难一直拿捏好最重要的东西：度。
度是软件工程里最难教、也最难写进提示词的部分。
异步能削峰，但也会引入排队、重复、乱序、补偿和观测成本；抽象能隔离变化，但也会增加跳转、接口和认知负担；缓存能降低延迟，但会带来失效与一致性问题；重试能遮住瞬时故障，也可能制造流量放大；拆服务能隔离部署，也可能把一个本地事务撕成一场跨团队协调。
模型知道这些词不难，难的是判断你的系统应该做到哪一步、又该在哪里停手。
异步设计最容易暴露「只懂形状，不懂后果」
异步设计是一个很典型的试纸。
假设有一条创建订单的链路。同步实现里，接口完成订单写入、库存预留和通知触发后再返回。延迟不算漂亮，但状态简单，失败也相对集中。现在有人提出「优化响应速度」，AI 很容易给出一个教科书式方案：订单先落库，后续工作投递消息队列，由消费者异步完成。
架构图立刻变得现代，接口耗时也可能下降。可被挪到队列后面的不只是几行代码，还有一组原本由同步调用提供的保证：
- 调用是否执行过，原本可以通过函数返回值判断，现在却要分别判断消息是否写入、是否投递、是否被消费。
- 执行顺序原本由调用栈约束，现在要处理分区、并发消费和乱序。
- 失败原本可以在请求内返回，现在要定义重试、死信、补偿和人工介入。
- 用户原本看到一个完成态，现在可能看到创建中、部分成功、等待重试和最终失败。
- 排错原本沿一条 Trace 进行，现在还要关联消息 ID、业务 ID、重试次数和消费者版本。
如果业务允许这些中间状态，团队也有能力处理，当然可以考虑异步。麻烦在于，AI 经常把「可以异步」直接推成「应该异步」。它认得这种方案长什么样，却不用承担方案留下的后果。
再看一段 Go 代码。为了让一个批处理「更快」，模型常会自然地生成 goroutine：
for _, item := range items {
go func() {
process(ctx, item)
}()
}它编译，甚至在少量测试数据下运行得很好。但它没有回答：并发上限在哪里？错误去哪了？调用结束后这些 goroutine 是否仍在运行？ctx 什么时候取消？下游连接池能承受多少并发？进程退出时要不要等待？某个任务失败是否影响整批结果？
把它换成 errgroup.Group 也不代表问题解决了。限制并发数需要依据资源预算；取消其他任务是否符合业务语义；某些任务已经产生副作用时能否安全重跑；错误是遇到第一个就停，还是汇总后处理。这些才是设计。使用哪个并发库，只是实现细节。
AI 生成的并发代码经常像装修样板间：照片里没有一根杂乱电线，真正住进去才发现插座、承重和排水都没算。并发的架子搭起来了，任务生命周期却经常没人管。
抽象的毛病，往往是用错地方
谈 AI 生成代码，很多人会抱怨「抽象太多」。这只说对了一半，它也会把所有逻辑塞进一个函数，也会复制粘贴相似分支，也会为了快速通过测试绕开既有接口。症结不在于它永远过度抽象或永远缺少抽象，而在于抽象经常与系统实际的变化方向错位。
一个常见场景是给现有业务增加第二种通知渠道。代码库本来只有邮件发送，需求新增短信。模型看到两个实现，很容易立刻生成 NotificationStrategyFactory、NotificationProviderRegistry、NotificationCommandHandler 和一组配置驱动的装配逻辑。理论上，每个名字都讲得通；现实中，团队未来两年也许只会维护邮件和短信，变化频繁的却是模板、限流和不同国家的合规规则。
结果是，抽象保护了一个不怎么变化的渠道创建过程，却把经常变化的规则散落在多个层次里。
另一种情况正好相反。代码库已有清楚的领域边界，模型为了完成眼前任务，直接从订单模块查询用户模块的表，再顺手复用库存模块的内部类型。功能跑通了，测试也可能通过，但模块边界被开了三个洞。每个洞都很小，小到审查者容易把它当作「先这样」。等十个功能都这么写，边界已经只剩目录名。
好的抽象往往来自对变化的长期观察：哪些规则总是一起改，哪些数据必须保持一致，哪些依赖可能被替换，哪些接口不能轻易动，哪些麻烦应该关在模块内部。模型看到的通常只有当前上下文和训练中学到的模式。即使上下文窗口装得下整个仓库，它也没跟着这个系统熬过过去几次需求转向，更不知道团队下一季度到底要交付什么。
所以它特别容易做两件事：根据常见模式预支未来，或者为了当前任务透支未来。
前者制造过度设计，后者制造隐性耦合。两者表面相反，本质相同：都没有把握住时间尺度。
代码组织看似整齐，维护路径却可能断掉
AI 很容易把局部收拾得工工整整：文件名统一，接口齐全，注释完整，测试目录也摆得像那么回事。可代码组织得好不好，不能只看目录树漂不漂亮。更要看改一个需求得穿过多少层、依赖方向清不清楚、出问题时能不能找到业务规则藏在哪里。
最折磨维护者的代码，未必丑。它可能极其整齐：
- 每一层都有自己的 DTO，字段在六次映射中来回复制；
- 每一个动作都有接口，即使整个系统只有一个实现；
- 每一个错误都包了一层，却在最外层统一变成
500； - 每一个模块都有
service、repository、manager和handler，但业务规则随处可见； - 每一个函数都短小，理解一个请求却要在二十个文件之间跳转；
- 每一个测试都通过，因为测试只是重复实现里的分支，没有验证业务不变量。
这种代码特别容易骗过走马观花的审查。它没有明显的坏味道，没有一眼可见的巨型函数，静态检查也不报错。可每次改动都得多读几个文件，久而久之，再也没人能痛快地回答「改这里会影响哪里」。
《译：简单性》里反复强调，复杂性很少来自某次明显荒唐的设计。通常是每一处局部都说得过去，拼到一起以后才逐渐失控。AI 恰好加快了这个过程。过去一个开发者一周写出的抽象，团队还有机会在会议和 Review 中慢慢消化；现在同样的结构一天就能铺满几个模块。复杂性没变高明，只是来得更快。
怎么证明可维护性
测试通过证明的是代码在当前测试覆盖的输入下满足了当前断言。编译通过证明的是类型和语法在当前工具链下成立。功能验收通过证明的是某些可见场景能走通。
它们都不能直接证明可维护性，可维护性只会在未来结算：
- 第二个相似需求进来时，能否在原有结构上自然扩展；
- 线上发生故障时，能否从指标和日志快速缩小范围；
- 依赖升级时，影响是否被隔离在少数位置；
- 原作者不在时，其他人能否理解关键不变量；
- 某个方案不再合适时，能否低成本删除，而不是牵一发动全身。
模型生成代码时不用承担这些延期结算的成本。它只需要完成眼前任务，人却要照看这个系统往后的日子。双方关心的事情本来就不一样。
更棘手的是，人也容易被即时反馈收买。一个原本要写两天的功能半小时跑通，带来的满足感非常真实。至于三个月后的修改成本，没有仪表盘会立即把它显示成红色。于是团队会自然奖励速度，把可维护性当成以后再说的问题。
而「以后」通常是某次线上事故。
二、经典 Trade-off 一个都没有消失
延迟、可用性和一致性不会因为模型参与而让路
软件系统的基本矛盾没有因为代码由谁生成而改变。
用户希望接口更快，你可以加缓存、并发和异步；缓存会引入陈旧数据，并发会争用资源，异步会暴露中间状态。业务希望永远可用，你可以做冗余、降级和多活；冗余带来复制，一旦跨越网络，一致性、冲突和故障切换就会变成必须处理的问题。产品希望功能马上上线，你可以减少设计和迁移准备；省下的时间往往会在回滚、兼容和后续返工里补回来。
麻烦并不在于 AI 完全不知道这些 Trade-off，而在于它能把每个方向都说得头头是道。
你让它降低延迟，它会建议缓存、批处理、索引、并发和预计算；你让它提高一致性，它会建议事务、锁、版本号和幂等；你让它提高可用性，它会建议重试、熔断、冗余和最终一致。每一份答案单独看都像一场合格的技术分享，问题在于生产系统不能同时把所有旋钮拧到最大。
架构判断的要害，是明确什么必须保、什么可以丢、失败时先牺牲谁。
例如，一个余额查询接口可以允许几秒延迟吗？一个库存数字能否短暂超卖？一次支付确认在网络分区时应该直接失败，还是先接受再对账？同城双活带来的恢复能力，值不值得多付一套基础设施和长期演练的成本？这些问题不由技术名词决定，而由业务损失、监管要求、用户预期和团队运行能力共同决定。
模型可以提供候选方案，却不能替组织承担损失。
研发成本和运行成本只是换了位置
很多 AI 方案的展示只计算生成成本：写了多少代码、花了多少 token、节省了多少开发时间。运行成本却被藏到部署以后。
一段自动生成的缓存逻辑，可能让接口在基准测试中快 30%，却引入缓存击穿、热 Key、双写不一致和额外监控；拆出一个微服务，看似让某个团队能够独立开发，背后却多了服务发现、鉴权、超时、重试、链路追踪、发布编排和数据迁移；一个通用工作流引擎可以让当前三个流程复用配置，团队却要长期维护 DSL、状态机版本和失败恢复。
并不是说缓存、微服务或工作流引擎都不该用，而是每个多一个功能、特性、中间件，都有人要长期为此买单。
AI 能很快生成服务骨架、容器配置和客户端代码，却不会顺手消灭分布式事务、尾延迟、数据所有权和夜间值班。偏偏这些「看得见的结构」越来越容易生成，团队也就更容易在理由还不充分时，提前背上一笔长期维护费。也就没人会在意 《微服务还是单体：别急着拆，先把边界想明白》 的内容了。
过去，复杂方案至少还受开发工时约束。你提出拆十个服务，项目经理会先问人从哪里来；现在模型两天就能把十套目录和部署文件铺出来，这道天然的刹车失灵了。骨架一搭好，管理者很容易误以为大头已经做完。其实骨架最便宜，以后的联调、发布、排错和升级才是一笔笔分期付款。
人的架构判断力反而更重要
有人会问：既然模型以后还会进步，现在这些问题是不是暂时的？也许下一代模型就能更好地设计异步、更稳地拆模块、更准确地审查代码。
这个问题容易把架构判断误解成一道等待更高分模型解答的题。
架构不是从需求推导出唯一答案。它是在约束不完整、目标冲突、未来未知的情况下做出可承担的选择。同一套业务，十人的创业团队和千人的平台团队应该有不同方案；同样的可用性目标，内部报表和资金系统应该付出不同成本；同样的流量规模，能否接受人工补偿会改变整个一致性设计。
模型给出的方案越多，人越要知道哪些方案根本不值得讨论。代码越容易写，就更缺少那些能删掉大量代码的人；工具跑得越快，就更缺少敢说「不做」的人。
人的架构判断力不是 AI 能力不足时的临时补丁。工程责任最后还得落在人身上。 Trade-off 的末尾，算的从来不只是吞吐、延迟和成本，还有组织愿意承担什么后果。这个答案只能由组织里的人给出。
三、落地路径为什么如此不稳定
你今天辛苦建设的护栏，明天可能变成遗迹
传统工程也会受版本变化影响，但多数基础抽象相对稳定。HTTP 的语义不会每个月重写一次，数据库事务不会因为供应商发布新版本就突然换一套基本定义。团队围绕这些能力建立规范，通常可以使用很多年。
AI 工程化不是这样。
模型能力、上下文规模、工具调用方式、推理行为、价格和产品入口都在快速变化。今天为了避免它漏读仓库规范，你设计一套复杂的上下文拼接；明天产品原生支持仓库级索引，这套拼接可能只剩维护成本。
今天你写几十条提示词，约束它先计划、再编码、再自检；明天模型默认就能完成其中一半步骤，旧提示反而可能和新行为冲突。今天某个模型擅长长上下文，团队围绕它建设工作流；下一次版本更新后，输出风格、工具选择和错误分布又变了。
这不是普通依赖升级。普通依赖至少有 API、版本号和变更日志。模型提供的是一种统计行为。接口可能一个字段没变，系统的实际表现已经变化。
于是，团队精心建设的 AI 流程很容易陷入一种尴尬：接入代码照常运行，模型的表现却和验收时不一样了。没有编译错误，也没有明确的兼容性异常，它只是悄悄变得更啰嗦、更冒进、更爱改无关文件，或者更容易漏掉某一类检查。
《AI 模型的选择与应用：谁干杂活，谁啃硬骨头》里写过怎样按任务风险选择模型，以及怎样把模型接进需求、编码、审查和测试流程。那套做法有一个前提：团队已经有相对清楚的流程。
模型路由可以调整，审查角色也可以增加；但模型变了以后没人重新评估，门禁只是一段提示词，流程走到哪里全看模型临场发挥，那么所谓分层不过是把几个黑盒摆得整齐一点。
你若把关键流程绑定在这种黑盒能力上，就必须接受持续重评，而不是一次验收。
提示词不是稳定的业务规则载体
不少团队落地 AI 的第一反应，是把经验写进系统提示：必须先读文档，必须遵循目录规范，必须补测试，禁止修改某些文件，遇到不确定要提问，输出必须符合某种格式。
这些约束并非没用，但很像写给一个记忆力差、理解还会漂移的外包人员的长邮件。规则越多，越难发现彼此冲突；上下文越长，也越难判断究竟哪一条起了作用。模型升级以后，同一句话的效果可能就变了。任务一长，它还可能前半段照做，后半段逐渐忘掉。
硬约束不能只存在于提示词里。
- 不允许跨模块依赖，要由静态检查或构建边界阻止；
- 不允许越权访问，要由服务端鉴权保证；
- 数据迁移必须可回滚，要由迁移框架和发布流程约束；
- 生产变更必须审批，要由权限系统和流水线门禁控制；
- API 必须兼容，要由契约测试和版本策略验证。
提示词可以提醒，不能执法。把制度写进一段自然语言，然后祈祷每次推理都严格执行，不叫工程化，叫许愿。
这正是 AI 落地最不稳定的地方。很多早期方案以为只要「说清楚」就能管住模型，却没有分清哪些只是提醒，哪些必须强制执行。提示词一旦失效，流程也就没了保证。
系统依赖的是能力，不是接口
传统软件依赖一个库，依赖的通常是公开接口和明确行为。AI 系统依赖模型，看中的却是「它大概能理解什么」「通常会漏掉什么」「任务拉多长以后还记不记得目标」这类说不太准的能力。
这种依赖很难写进类型系统，也很难用几百个固定测试完全覆盖。
例如，一个代码代理的外部接口始终是读取文件、修改文件、执行命令。但从模型 A 换到模型 B，或者从同一模型的一个版本换到另一个版本，可能发生这些变化：
- 它更愿意先重构再实现，导致改动范围扩大；
- 它更少提问，遇到缺失信息时直接猜测；
- 它更频繁执行测试，却忽略某类失败输出；
- 它更擅长局部编码，却更容易破坏跨模块约束；
- 它生成的解释更有说服力，让审查者反而降低警惕。
麻烦不在于新模型一定更差，而在于它犯错的地方变了。团队刚熟悉旧模型的毛病，也打上了一些补丁；新模型修掉旧错，又可能在别处开洞。评测总分更高，不代表生产风险只会往下降。
所以，AI 工程化不能只看「接入成功」和「调用失败」。团队得留一批固定的真实任务，模型升级前重新跑一遍；还要记录它改了多大范围、一次通过多少、人工修了多久、漏掉了什么、调用过哪些工具，以及成本和长尾延迟。否则所谓升级，只是把生产系统交给一个看起来更聪明、脾气却还没摸清的新同事，而且他上班第一天就拿到了整个仓库的写权限。
四、复杂项目卡住的，是流程控制
能连续工作，不等于流程可控
现在的编码工具越来越像一个可以自己行动的参与者：它能搜索仓库、读取文档、修改文件、执行测试，失败后继续修正。有些工具还会列出任务清单，保留上下文，连续运行很长时间。
这些能力很容易给人一种错觉：既然模型已经能连续做几十步，它应该已经解决了复杂项目里的工作流问题。
其实，「能够继续」和「按正确流程继续」是两回事。
复杂项目不是把一串操作按顺序跑完。它有不同状态，有角色分工，也有批准条件、证据要求和停止规则。需求还没确认，设计就不该冻结；数据迁移没有回滚方案，发布就不该开始；测试失败，要分清是实现、测试还是环境出了问题；接口行为改变，要通知调用方并检查兼容性；风险级别提高时，自动流程应该停下来找人，而不是一遍遍继续尝试。
一套可控的研发流程，至少要回答这些问题：
- 当前处于什么状态，谁有权把它推进到下一状态？
- 进入下一阶段必须具备哪些证据？
- 哪些失败可以自动重试，哪些失败必须停下？
- 中间产物由谁确认，确认的是格式还是语义？
- 流程中途需求变化，哪些决定要作废并重新评审？
- 自动执行越过了边界，怎样追溯它为何这么做？
模型列出来的任务清单通常只是它对当前问题的临时理解，不是组织认可的状态机。它可以把某一步标记为完成，却无法证明完成标准已经满足；它可以更新计划，却可能在没有显式说明时改掉原有目标；它可以遇到错误继续绕路，但绕路本身也许已经违反了架构约束。
比停住更危险的，是它一直能往下走。停住至少会暴露问题。一路往下做，却可能把一个错误前提包装成越来越完整的实现。早期设计里弄错了一个字段含义，数据库 schema、接口、前端表单、测试和文档跟着层层复制，最后大家完全一致，流水线也是绿的，只是整套系统一起做错了。
工作流固化不是多写一个 Agent
很多团队发现单个对话不够稳定后，会开始拆角色：需求 Agent、架构 Agent、编码 Agent、测试 Agent、审查 Agent。每个角色拿一段提示词，再由一个编排器把结果传下去。看上去像把真实团队搬进了软件。
问题是，角色数量不等于流程成熟。
需求的完成标准不清楚，需求 Agent 只会写出一份更长的含糊文档。架构决策没有留下约束和淘汰其他方案的理由，架构 Agent 给出的也只是一份术语齐全的方案。测试若只根据实现生成，很可能把实现里的误解写进断言。至于审查 Agent，在不了解业务风险时，往往忙着挑命名、异常处理和空指针，却放过最要命的状态错误。
多 Agent 还有一个不太显眼的问题：每交接一次，原意就可能丢掉一点。
人类团队的交接已经很容易丢信息。产品说「用户取消后尽快退款」，研发要继续追问尽快是五分钟还是三个工作日，部分退款怎么算，支付通道失败怎么办，已经发货能不能取消。换成 Agent 后，上一阶段往往输出一份看似完整的文档，下一阶段便把它当作确定事实继续推导。流畅的文本掩盖了没有被确认的假设。
到头来，所谓工作流自动化，可能只是把误解传得更快。
要把工作流固定下来，关键状态和门禁就得放在模型之外：需求项有唯一标识，验收标准能对应到测试，架构决策有记录，高风险变更需要审批，构建产物能追溯到提交，部署以后也有明确的回滚办法。模型可以参与某一步，但不能靠下一段提示词来证明上一步已经完成。
这听起来一点都不酷。它更像传统的软件工程治理：Issue、文档、ADR (Architecture Decision Record)、CI、权限、审计和发布门禁。没错，AI 落地最后绕回来的，恰恰是这些过去被嫌麻烦的东西。
文档驱动开发仍然没有被解决
不少人把自然语言当作 AI 时代的新源代码，仿佛需求写清楚后，模型就可以机械地生成系统。这个方向忽略了一个老问题：自然语言擅长表达意图，不擅长自动消除歧义。
「订单关闭后释放库存」看起来很清楚，但至少缺少下面的信息：
- 哪些关闭原因需要释放，风控关闭和超时关闭是否相同？
- 已部分发货的订单释放多少？
- 释放失败后订单保持关闭，还是回到处理中？
- 重复收到关闭事件时如何保证幂等？
- 库存服务暂时不可用，最长允许延迟多久？
- 运营手工恢复订单后，库存是否重新预留？
- 历史订单是否遵循新规则？
文档驱动开发难就难在，组织是否愿意把这些含糊之处逐一说清，并长期维护文档和实现之间的对应关系。找个工具把文档写长，并不解决问题。
AI 能很快列出一批问题，也能把回答整理得像份正式文档。但业务负责人愿意接受哪种后果，它没法替人确认。人不回答，模型往往就按常见做法自行补齐。补完的文档比原始需求更像那么回事，反而更加危险，因为原本的猜测已经没有问号了。
文档与代码的一致性同样没有自动解决。需求变了，谁判断哪些设计、测试和迁移说明需要更新？实现为了线上限制做了偏离，谁把真实行为写回文档？模型可以扫描差异，但「这是遗漏，还是有意取舍」仍然需要上下文。没有稳定的文档责任人，再先进的生成能力也只会让过期文档变得更多。
文档驱动看重的从来不是文档数量，而是每项决策都有来路可查。AI 可以写文档，却不能替组织作出决定。
五、Plan 与 Code 之间，有一个审查死局
同一个模型 Review，容易看见自己想看见的东西
把任务交给 AI 时，常见做法是先让它写 Plan，人确认后再进入 Code，最后让它 Review 自己的实现。步骤看起来很完整：先设计，再实现，再审查，和正规的研发过程一模一样。
可如果三个阶段由同一个模型、同一段上下文完成，它很容易产生严重的思维惯性。
Plan 阶段一旦把问题定义错了，Code 阶段会忠实实现错误定义，Review 阶段又会检查代码是否符合原 Plan。三个环节彼此一致，却没有任何一个环节回头质疑最初的框架。
例如，需求只是给一个低频后台任务增加失败重试。Plan 先入为主地认为需要通用任务编排，于是设计状态表、执行器、重试策略接口和恢复扫描器。Code 按计划实现。Review 检查并发安全、错误处理和测试覆盖，最后给出「实现与设计一致」。
从内部一致性看，它也许真没错。真正应该问的问题是：为什么不在现有任务上增加一个有上限的重试？
同一个模型到了最后一步，很难主动推翻自己刚刚用大量上下文搭起来的思路。人有确认偏误，模型也不会因为没有情绪就自动避开这个坑。它会沿着前文继续往下推，之前得出的结论，本身就成了后面最强的暗示。
让它「请以批判视角重新审查」会有帮助，但不能消除结构性盲区。因为审查者仍然继承了相同的问题表述、相同的材料选择和相同的遗漏。如果关键事实从未进入上下文，换一种口吻也看不见。
换一个模型互审，又可能进入无限修改
于是第二种方案出现了：用不同模型互相 Review。模型 A 写 Plan，模型 B 挑问题；模型 A 修改后，模型 C 审代码；再让模型 B 复核修订。
这样能打破一部分思维惯性，也会掉进另一个坑：没有共同而明确的验收边界，不同模型总能继续找到可以改的地方。
一个模型偏爱显式接口，嫌当前实现耦合太重；另一个模型追求简单，又嫌接口过多。一个要求细分错误类型，另一个担心公开这些类型会扩大 API。一个建议增加并发提高吞吐，另一个马上指出并发会增加复杂性。单看每条意见都有道理，代码却被它们拉得左右摇摆。
更常见的是滚雪球。审查者为了解决一个潜在风险，引入新的抽象；新抽象又产生新的边界条件；下一轮审查继续要求配置、监控、降级和扩展点。原本三百行能完成的功能，经过几轮「高质量 Review」，变成三千行、十几个接口和一份未来路线图。
谁都没有犯明显错误。每一轮修改也都改善了一点东西，可最后拼出来的却是个过度设计的怪物。
这和架构会议里的争论很像，只是模型不会开累，也不怕得罪人。只要让它继续，它总能再给出一种意见。人类开会至少会被午饭、排期或预算打断；模型互审若没有停止规则，能把一个简单功能改到完全失去分寸。
Review 的目标不是把所有意见都实现
这个死局和模型够不够强关系不大。团队若把 Review 理解成「继续寻找可以改进的地方」，那它永远不会结束。任何像样的系统都还有改进余地，审查必须围绕明确的风险和验收标准收敛。
决定采纳一条审查意见之前，至少要回答：
- 它指出的是确定缺陷、需求偏差，还是一种风格偏好？
- 不修改会造成什么可观察后果？
- 这个后果发生的概率和影响是否值得当前成本？
- 修改会引入哪些新的状态、接口和维护负担？
- 它属于本次需求，还是应该单独记录、以后处理？
不问这些问题，AI Review 很容易沦为建议生成器。建议越多，看着越负责；作者为了清空评论，只能逐条照改。结果风险没有降低，反而被额外改动遮住了。
《代码审查指北》提到审查要抓大放小，机器管语法，人管语义。加入 AI 之后，还需要增加一句：模型可以找线索，人必须决定什么时候停止修改。
审查 Plan 和 Code 时，没必要追求几个模型意见一致，先把审查范围管住更实际：
- Plan 先审问题定义、不可逆决策和主要 Trade-off，不在此时预演所有未来扩展；
- Code 先审是否满足已确认的验收标准，再看安全、数据、一致性和运行风险；
- 建议必须标注证据、严重程度和不修改的后果；
- 同一意见来回超过两轮，转人工同步，不让模型继续写论文；
- 非阻塞改进进入单独任务，不借当前 PR 顺手重构世界；
- 最终由对系统负责的人收敛，不以「所有模型都同意」作为合并条件。
这套办法并不完美，但至少承认审查时间有限。它的任务不是找到理论上的最优解，而是把风险降到团队能够接受的程度。没有这条边界，Review 自己也会变成工程风险。
六、所谓效率提升，很多时候只是成本转移
复杂需求很难用自然语言说清楚
「自然语言编程」描绘的场面很诱人：人说出想法，AI 把它变成软件。可复杂需求之所以复杂，并不是过去缺少一个能听懂人话的编译器，而是提出需求的人自己也没完全想清楚。
业务方说要「灵活配置」，可能是不知道下个月会改什么；说要「实时」，可能只是不能接受隔天；说要「智能推荐」，可能连成功指标都没有；说要「兼容历史逻辑」，可能没人知道历史逻辑到底包含多少例外。
这些模糊不是措辞没写漂亮，而是有些决定根本还没做。换成自然语言输入，也不会自动把空白补齐。
为了让 AI 稳稳当当地实现一个中等复杂度功能，团队往往得准备一大包上下文：业务目标、非目标、用户流程、状态转换、接口契约、数据模型、错误处理、权限边界、兼容要求、性能预算、上线策略和验收用例。接着还要和模型聊上几轮，把计划细化到模块、文件，甚至具体函数。
做到这一步，输出通常会稳很多。但先别急着欢呼。请把准备过程也计入成本。
产品、架构师和资深开发花了大量时间，把散落在各自脑子里的经验写成准确的文字。他们得提前列出异常路径，避免模型理解错；还得交代仓库历史和技术债，免得改动范围失控。模型给出计划后，人继续逐段修正，到最后几乎只剩照单执行。
这不是成本消失了，而是开发成本被前置成了问题定义和审查成本。
把任务拆到模块级，已经完成了最难的一部分
如果一份任务已经清楚到下面这个程度：
- 修改哪个模块，不允许触碰哪些边界；
- 新增哪些接口，输入输出和错误语义是什么；
- 数据如何迁移，旧版本如何兼容；
- 并发与事务边界在哪里；
- 要补哪些测试，验收条件是什么；
- 失败如何回滚，发布如何观测。
那么困难的部分已经完成了大半。
剩下的实现当然还有技术含量，但已经像是在铺好的路基上铺轨。换成一个训练合格、愿意遵守规范的 P5 级别初级开发，也完全可能交付得很好，还能在过程中熟悉系统、提出问题、积累经验。AI 在这里主要省的是人天：不用排期，机械实现做得快，测试和样板代码也能一起生成。
它没有凭空解决架构难题。架构难题已经被前面的高质量 PRD、技术设计和任务拆分解决了。
这一区分很要紧。否则管理层很容易得出一个危险结论：既然 AI 能写实现，只要留下少数负责定义问题的资深人员，再给他们配上一堆模型，就能替代原来的研发团队。短期看，提交速度确实会上升；时间一长，上下文补充、计划校正、代码审查和上线责任却全压在少数人身上。他们既要设计系统，又要给每个任务喂上下文，还要验收代码、处理异常和承担上线结果。
组织省下的是实现者的人天，消耗的是稀缺专家的注意力。
注意力比普通工时更难扩容。一天仍然只有那么多小时，一个资深开发也不可能同时在十个复杂模块里保持完整心智模型。AI 可以并发开十个任务，却不能把同一个人的判断力复制十份。
心智成本不会出现在 token 账单里
AI 工具很容易统计调用量、订阅费、生成代码量和任务耗时。至于使用者为了拿到可靠结果费了多少脑子，报表里通常没有这一栏。
你需要不断判断：上下文够不够？它是不是误解了？这次修改为什么扩大范围？测试通过是否只是测试写错了？某个建议是通用最佳实践，还是适合当前系统？它自信地说完成时，真的覆盖了所有验收项吗？
这绝不是坐在旁边等结果那么轻松。它更像同时带着几个手很快、嘴也很利索，却会突然失忆的新成员。你得不停切换上下文，还不能因为对方说得流畅就少看两眼。
时间一长，人会累得很别扭：代码不是自己逐行写出来的，脑子里没有自然形成实现过程；可轮到审查，又得在很短时间内把这条路重新走一遍。手写代码时一点点积累起来的理解没有了，最后的责任却一点没少。
于是出现一个看似矛盾的现象：一天合并了更多功能，人却比以前更累，对系统反而更陌生。
如果团队只按交付数量统计效率，这部分成本会完全隐形。直到核心成员开始回避复杂 Review，或者线上问题越来越依赖少数人救火，组织才会发现所谓提效只是把账记到了别的科目。
「节省人天」不是一句贬义，但要说实话
省人天当然有商业价值。边界明确、容易验证的任务能更快做完，对团队也有意义。怕的是把省工时说成解决了所有工程难题。
如果 AI 只是把已经拆清楚的任务更快写完，那就看实现环节省了多少时间。想证明它减少了架构返工，就统计设计缺陷和长期修改成本；想证明交付更快，就看从需求确认到稳定运行的完整周期；想证明人员成本下降，就把平台维护、模型费用、资深人员审查和事故恢复一起算进去。
不能只选最绿的那一段数据。
一家公司原本十天交付一个功能，现在三天写完代码，第十天仍然在等需求确认、联调、合规和上线窗口。这里优化的是编码阶段，不是交付周期。另一个团队一天生成十个 PR，但审查队列积压一周，也不能说吞吐提升了十倍。生产链的瓶颈不会因为上游加速就自动消失，它只会移动到下一个环节。
而在 AI 编码里，下一个环节通常就是 Review。
七、最大的雷区：代码有人写，没人审得过来
资深开发搭配 AI，一样会翻车
行业里有一种很顽固的想象：AI 生成的代码会出问题，是因为使用者水平不够。只要换成足够资深的开发，前面把需求写清楚，后面把测试补齐，大部分风险都能避开。
这句话只对了一小截。资深开发确实更容易发现问题，也更知道该提供哪些上下文。但资深不代表拥有无限注意力，更不代表能够在产出速度成倍增加后，仍然保持原来的审查深度。
中等规模项目尤其容易暴雷。
小脚本上下文短，失败了容易重来；超大型核心系统通常会让整个组织绷紧神经，权限、评审和发布也相对谨慎。夹在中间的项目反而最危险：数据库、并发任务、外部依赖、权限和线上流量一样不少，却没有重要到每次变更都拉上一群人评审。团队觉得业务熟、测试也不少，于是很自然地扩大 AI 的使用范围。
前期往往很顺。资深开发搭好骨架，让 AI 填充实现；遇到问题就改提示、补规范、加测试。两三个人做完过去五六个人的活，管理层看到的数字非常漂亮。
然后故障开始陆陆续续出现。
这些故障未必来自算法写反之类的低级错误，更多是运行一段时间后才会暴露的组合问题：
- 后台任务在超时后仍然继续，调用方重试又启动一份，最终重复处理；
- 新增缓存没有随旧写路径失效，少量用户长期读到陈旧权限；
- 消费者遇到毒消息无限重试，占满分区，后续正常消息全部堵住；
- 批量接口把单次查询放进循环，小数据测试通过，上生产后拖垮数据库；
- 重试策略看似「更稳妥」，却没有总的次数和时间上限，下游一出故障，请求就层层放大；
- 配置默认值在测试环境存在，生产环境缺失后走到零值分支，服务启动成功却无法处理请求；
- 健康检查只验证进程存活，核心依赖已经不可用，流量仍然持续打进来。
任何一个问题拿出来，事后都不神秘。复盘会上甚至会让人产生羞耻感：「这么明显，怎么会没人看到？」
答案通常也不神秘。团队里不缺资深开发，他们只是已经审不过来了。
代码生成的速度，超过了人的理解速度
人写代码时，理解和生产通常同步发生。你设计一个结构，写下实现，编译失败，修正假设，再补测试。这个过程不保证质量，但至少作者的脑子里形成了一条连续路径。
AI 生成代码时，生产与理解被拆开了。几分钟内出现上千行改动，使用者先看到结果，再倒推它为什么这么写。
读懂代码本来就比扫一遍慢。认真审查不仅要看每行是否合理，还要还原控制流、数据流和失败路径，弄清它与旧代码有什么关系。一个 PR 改了五十个文件，即使每个文件都写得规整，人也很难在一次审查中把全貌装进脑子。
更何况，AI 生成的代码往往长得很正常。明显的语法错误反而好办，编译器会拦。危险的是另一类代码：命名合理、注释完整、分支齐全，却在某个没有写明的前提上出了错。审查者读得越快，越容易被表面的顺畅骗过去。
过去团队会要求 PR 保持小而聚焦，因为人的审查能力有物理上限。AI 没有改变这个上限，只改变了超过上限有多容易。《代码审查指北》中提到巨型 PR 会造成审查疲劳，这在 AI 生成代码面前不是旧时代的小讲究，而是安全边界。
当一天产生的代码量翻倍，团队只有四种选择：
- 增加同等比例的审查时间；
- 降低每行代码的审查深度；
- 缩小变更范围，限制生成吞吐；
- 把更多判断交给自动化测试和工具。
现实里，第一种通常做不到，第三种又与「提效」的考核冲突，于是团队会同时选择第二种和第四种：少看一点，相信测试。
事故的土壤就准备好了。
绿色测试通道不是质量证明
测试很重要，但它只能检查已经写出来的预期。需求里漏掉的场景、设计者没想到的风险、环境差异和长期运行才会出现的问题，不会因为流水线是绿色就自动消失。
AI 同时生成实现和测试时，还有一个额外风险：它们可能共享同一个误解。
需求说「关闭订单释放库存」，模型把所有关闭状态都理解成释放。实现按这个规则写，测试也对每种关闭状态断言库存已释放。覆盖率很好，分支全绿，真实业务却规定风控冻结的订单不能释放。测试没有发现错误，因为它不是独立证据，只是把实现的假设再写了一遍。
即使换一轮对话生成测试，也可能被现有代码牵着走。模型先看到函数怎么实现，往往会顺着当前行为补例子，而不是从业务不变量重新推导。Mock 再多一些，测试甚至只检查调用了哪个方法，不再关心最后的业务状态对不对。
另外一些问题本来就很难在普通 CI 中暴露：
- 竞态只在特定时序下出现；
- 连接泄漏需要持续运行才能积累；
- 慢查询依赖真实数据分布；
- 消息乱序和重复依赖故障注入；
- 配置错误只会在生产环境使用的那套组合中出现；
- 灰度版本与旧版本并存时才发生协议不兼容；
- 下游超时、限流和部分成功需要真实的降级演练。
测试通过的正确解读应该是：「目前这些已知检查没有发现问题。」它不是「代码安全，可以上线」的同义词。
可人一旦审累了，绿色通道很容易变成一张免责卡。大家终于有了一个停止追问的理由。
砍掉 QA，会让灾难来得更快
如果企业把 AI 理解成单纯的降本工具，很自然会继续追问：代码都能自动生成了，测试是不是也能自动生成？既然测试能自动生成，QA 岗位是不是可以削减？
这个推理忽略了开发测试和质量保障的视角差异。
开发做测试，容易从「我实现了什么」出发；QA 更关心「用户会怎么把它弄坏」「系统到了什么边界会失控」。好的 QA 不只是照着用例点按钮。他们会质疑需求、补充场景、判断风险、观察异常，还会在发布压力下坚持做完那些不能省的验证。
AI 可以批量生成测试用例，但生成数量不等于发现未知风险。它读到的需求若缺少异常规则，生成的用例同样缺少；它不了解一次历史事故为何让团队特别警惕某个边界，也不知道客户真实使用方式与产品文档之间的偏差。
把 QA 全部砍掉，再要求开发者自己审 AI 生成的实现和测试，相当于让同一拨人既负责生产，又负责挑错，还负责最后放行。上线日期一压过来，三个角色很快就会说出同一句话：「主流程能跑，先上再说。」
QA 过去做的工作，并非每一项都必须保留。机械回归、重复操作和用例初稿都可以自动化。可独立的质量视角不能顺手删掉。这个角色可以由 QA、测试开发、可靠性工程师或没有参与实现的开发者承担，但团队里必须有人专门站在挑错的一边。
如果企业只保留生成代码的人和工具，却删掉负责质疑结果的人，灾难只会来得更快。代码产出越快，错误排队进入生产的时间也越短。
事故链通常长这样
把这些因素串起来，一个典型事故并不需要模型产生惊世骇俗的错误：
需求边界含糊
↓
AI 补齐一个看似合理的假设
↓
Plan、实现与测试共享这个假设
↓
PR 体量过大，人工审查只看主要路径
↓
自动化测试通过，团队获得安全感
↓
快速合并并上线，QA 或灰度验证不足
↓
生产环境的边界条件触发
↓
监控只覆盖技术错误，没有覆盖业务错误
↓
问题持续扩大，最终由用户或对账发现这条链上，没有一步非得表现成「AI 在胡说八道」。单看每一步都说得过去。事故往往就是这样来的：几个小缺口连在一起，AI 又把代码从产生到上线的时间压得很短，问题还没来得及被人发现，就已经到了生产环境。
所以，把根因写成「AI 生成的代码不可靠」太轻松，也没什么用。换个模型，组织还会用同样的姿势再摔一次。更准确的说法是：代码产出的速度超过了验证能力，组织却拿测试通过掩盖欠下的审查。
八、第一年的顺利，往往最危险
快速产出会制造麻痹期
引入 AI 的前几个月，收益最容易被看见，代价最不容易结算。
积压很久的旧需求很快补上了，过去没人愿意写的内部工具也陆续上线，文档、测试和重构数量都在增加。团队每天都觉得做了不少事，管理层每周也能看到好看的数字。
可维护成本来得慢。抽象合不合适，要等第二、第三个需求来了才知道；数据一致性有问题，往往要碰上异常时序才会暴露；原作者一走、模型会话一丢，知识有没有留下才看得出来；流量、数据量和服务数量涨上去，运行成本才开始疼；安全边界是否可靠，平时更难看清。
这种时间差会带来一段蜜月期。团队慢慢习惯了：AI 生成的测试大多能跑过，小功能也基本能用，AI Review 还会列出不少问题。每一次顺利合并都让人更放心，可「一直没出事」未必说明风险已经受控，也可能只是还没撞上那些少见的边界条件。
等使用范围从少数人试点扩大到全团队，情况就不一样了。起初是熟悉系统的人用 AI 加快实现，后来，不熟悉模块的人也开始依赖它跨边界修改。起初，每个 AI PR 都有人特别留意；看得多了，审查者也不再区别对待。任务则从低风险一路扩到高风险，理由无非是前面一直没出事。
事故很少发生在第一次试用。它更常发生在大家已经不把它当回事的时候。
仔细 Review 每一个 PR 终将沦为理想主义
很多团队的 AI 使用规范最后都会写上一句：所有生成代码必须由开发者仔细审查，确认理解后才能合并。
这句话当然正确，但几乎没有约束力。
如果一天只有两个小 PR，当然可以仔细审。可一个人同时开着几个任务，团队每天冒出几十个变更，再加上会议、故障、需求讨论和线上支持，「仔细」究竟要花多少分钟、检查哪些风险、由谁负责，很快就没人说得清了。
制度不能建立在每个人永远高度自律、永远精力充沛的假设上。流程设计要考虑周五晚上、版本延期、人员请假、告警不断和业务催上线时会发生什么。
一旦没有明确的变更规模限制、风险分级和审查容量，所谓「每个 PR 都认真看」会慢慢退化：
- 开始是逐文件阅读；
- 后来只看 diff 中的关键函数；
- 再后来先读 AI 摘要，有问题才展开；
- 最后看到流水线全绿、机器人无阻塞意见，直接批准。
每一次退化都能找到现实理由。没有人故意破坏质量，大家只是想把工作做完。
因此，控制 AI 代码风险不能靠道德号召。人的审查精力有限，流程就得照着这个上限来设计：限制单个 PR 的规模，限制并行任务数，高风险目录指定负责人，关键变更要求独立的测试证据；一旦审不过来，就延后合并。宁可让生成出来的代码排队，也不要让没人读懂的代码进入生产。
这句话可能让人不舒服，因为它直接削弱了 AI 最显眼的速度。但生产系统不为演示速度负责。
最终瓶颈还是人，而且会表现成「人祸」
事故复盘里，「人祸」是个危险的词，很容易被拿来把系统问题推给某个操作失误的人。我在这里提它，不是为了找人背锅，而是想说明：AI 没有消除人的极限，反倒可能把组织对人的依赖藏得更深。
最后仍然需要人完成这些动作：
- 判断需求是否值得做；
- 决定架构 Trade-off；
- 确认模型没有误解业务；
- 审查无法自动验证的风险；
- 决定是否上线和何时回滚；
- 处理生产异常并向用户负责；
- 在事故后修改流程，而不是只换提示词。
组织一边扩大 AI 产出，一边压缩这些人的时间、人数和话语权。等事故发生，原因又会被写成「人没看仔细」「操作不规范」「经验不足」。可这套系统原本就在要求人面对根本审不过来的代码，还要始终保持完美注意力。
这才是 AI 工程化里最常见的「人祸」：组织设计了一套必然让人顾不过来的流程，出事后却责怪某个人没有像机器一样永远准确。
九、管理不是盯人，AI 更不会替你带团队
管理的本质是什么
不少管理者对 AI 的期待很朴素：以前要盯开发进度、催文档、催测试、催 Review，以后让工具自动拆任务、检查代码、汇总周报，管理成本自然会下降。
如果管理只是不断问「做完了吗」，AI 确实能更快给出一份回答。但管理从来不只是盯着人干活。管理者应该维护一套工作方式，让工作更容易推进，让错误尽早暴露。
这套系统包括目标、角色、边界、反馈和资源：
- 团队知道为什么做，而不只是接到一串任务；
- 决策权与责任匹配，不让无权的人承担结果；
- 每项工作都有清晰的入口、状态和完成标准；
- 风险能在小范围暴露，而不是上线后一次结算；
- 信息被记录和共享，不依赖某个人一直在线；
- 交付速度与审查、测试、运维能力保持平衡。
如果一个团队非得靠负责人每天追问、逐项批准、亲自救火才能运转，管理就已经失败了。把 AI 加进去，只会让负责人收到更多产物和提醒，也多出更多需要拍板的事。原来的瓶颈是开发写得慢，新的瓶颈是负责人看不过来。
AI 不能替团队建立信任，不能分配责任，也不能在两个团队目标冲突时承担取舍。它可以整理会议纪要，却不能让一个没人认领的决定自动找到负责人；它可以生成任务看板，却不能让随口定下的截止日期变得可信；它也可以统计代码贡献，却不能靠提交数量判断一个人在团队里的价值。
管理问题套上自动化的壳，里面还是管理问题。
团队成员需要学习驾驭 AI，而不是依赖 AI
要让 AI 进入研发流程，团队培养不能只教几个提示词模板。提示词很快会过时，需要建立的是一组更基础的能力：
- 能把模糊需求追问成可验证目标；
- 能识别哪些信息是事实、假设和待确认项；
- 能阅读模型没有展示的代码路径；
- 能判断一个抽象是否匹配真实变化；
- 能设计独立于实现的测试；
- 能根据风险限制权限、改动范围和自动化程度；
- 能在模型输出流畅时仍然要求证据；
- 能在结果不可靠时自己接管，而不是继续换一种问法。
这些都不是「会不会用工具」的问题，而是工程基本功。
对初级开发尤其要小心。AI 可以让他迅速交付一个过去写不出的模块，但如果团队只评价结果，不要求他解释设计、追踪故障和承担后续维护，他获得的可能是产出能力，不是工程能力。半年后，仓库里有大量他提交却并不真正理解的代码；一旦模型给出错误方向，他也缺少独立纠偏的基础。
培养人时，得有意保留思考环节。先让成员说清问题和约束，再看模型方案；要求他解释为什么接受某个设计；Review 时追问失败路径，不要只改格式；还要让提交者参与上线、值班和复盘，亲眼看看代码在生产环境里怎样付账。
会使用 AI 的人很多，能在它加速时仍然保持系统感的人很少。团队要培养的是后者。
负责人不能变成全队的人工上下文服务器
AI 普及后还有一种常见组织形态：每个人都能快速写代码，但只有一两个资深人员理解全局。于是所有任务在开始前找他们补上下文，生成后找他们审查，出问题再找他们救火。
表面看，团队人均产出上升了；实际上，所有工作最后都堵在少数人这里。
这些负责人每天在订单、权限、结算、基础设施之间来回切换，向不同模型重复解释同一段历史，再审阅大批并非自己写出的代码。他们通常会先放弃深入 Review，再放弃文档，最后只处理最着急的问题。组织看到的仍然是功能不断上线，却看不到核心人员对系统的完整理解正在一点点散掉。
这和技术 Leader 个人能力无关，纯粹是容量规划荒唐。AI 可以同时启动十个任务，一个人却不可能同时承担十个任务的架构责任。
如果团队想扩大 AI 产出，就必须同步扩大决策和验证能力：把领域知识分散到稳定的模块负责人，缩小服务和代码所有权范围，建立可执行边界，让常见判断不必每次请求专家。否则所谓「一人公司」和「超级个体」，在生产系统里一般翻译为「单点故障」。
十、没有流程的公司，会被 AI 降维打击
AI 不会修复混乱，只会把混乱执行得更快
有些小团队听到「要先把流程理顺」，第一反应是大公司病。我们人少，坐在一起喊一声就能改，为什么要原型、文档、UML、运行图和正式评审？过去这么多年，不也把业务做起来了吗？
这类团队确实可能很灵活。老板坐在产品旁边，产品转头找开发，需求十分钟说完，下午就能看到页面。需求改来改去，大家靠共同记忆维持着对业务的理解。没人说得清完整流程，但几个关键成员都知道「大概怎么回事」。
这种组织不是没有系统，只是系统运行在人的脑子、群聊和默契里。
纯人工开发时，丢掉的信息还有机会靠交流补回来。开发写到一半觉得不对，站起来问一句；测试发现和印象不符，把产品拉过来确认；上线前负责人扫一眼，想起某个老客户还有特殊规则。流程虽然不正规，但人始终在场，模糊之处经常会在开发过程中被重新问出来。
AI 加入后，这些隐形修正点很容易消失。
口头需求被直接丢进模型，模型不会闻到办公室里那句「这个地方以前出过事」；没有原型，它会自行选择交互；没有状态图，它会根据常见模式补状态；没有运行图，它不知道请求经过哪些历史服务；没有文档，它只能从代码反推意图，而代码里恰好还留着三代互相矛盾的实现。
更麻烦的是，它不会像熟悉业务的老员工那样，凭经验觉得某个地方「不对劲」。它会把没说清楚的地方一一补上，交出一份完整方案，然后迅速开始实现。
原来一次含糊传达只影响一个开发者，他会在几天实现里逐渐暴露问题；现在同一份含糊传达可以同时生成后端、前端、测试和文档。误解的复制成本降到接近零，纠正成本却随着产物数量增长。
这就是 AI 对无流程公司的降维打击：它不会让混乱的公司突然变规范，只会用工业化的速度复制手工作坊里的误差。
没有原型，AI 会替你决定产品
原型的价值不是画得好看，而是让团队在写代码前看到用户如何行动。一个按钮放在哪里，弹窗何时出现，错误后保留哪些输入，返回列表后筛选条件是否还在，这些细节共同定义了产品行为。
没有原型时，人类开发也会猜。但人通常会因为实现成本而只猜一套，并在联调时被产品纠正。AI 能在短时间内生成一套看似完整的界面，产品反而容易在现成结果上做零碎修改：这里加一个按钮，那里换个弹窗，列表再多一列。
代码跟着零碎意见不断变形，背后的用户流程却从未整体确认。最后页面能点，流程也能走，只是状态之间充满例外。这些例外又一路传到后端 API、权限和测试里。
所谓「先让 AI 做出来再看」并没有免除设计，只是把设计活动推迟到代码已经存在之后。此时每个产品决定都带着沉没成本，团队更不愿意推倒错误方向。
没有文档，模型只能把历史偶然当成规则
老系统里经常有一些奇怪代码。也许是五年前的临时兼容，也许为了处理一次数据事故，也许对应已经下线的客户。人看到后会去问，或者从提交历史和 Issue 中追查。
模型看到的只是代码形状。没有文档说明时，它可能把一个偶然分支抽象成通用能力，也可能认为它是冗余代码顺手删除。两种做法都有充分的表面理由。
团队如果连自己都不知道哪些行为是契约，就无法要求 AI 正确保留。把整个仓库塞进上下文，不等于补齐历史。代码记录了最后怎么做，未必记录为什么做，更不会记录当时放弃了什么方案。
因此，缺文档不只是让 AI 的回答差一点，而是让它分不清业务规则、技术债和历史遗迹。每次修改都像在没有地籍图的老城区施工：一堵墙看着碍事，可谁也不知道它是不是承重墙。
没有 UML 和运行图，边界就只存在于想象中
不是每个小项目都需要厚重的 UML 文档，也不需要为了形式画一堆永远不更新的图。但复杂状态、跨服务时序和关键运行链路，必须有某种让人能共同检查的表达。
一张状态图能逼大家说清哪些转换合法，一张时序图能画出超时后谁还在继续，一张运行图能说明流量会经过哪些网关、队列、缓存和数据库。画图不是为了显得专业，而是让大家面对同一套系统说话。
没有这些东西，AI 做架构分析时只能从局部文件和配置猜全局。它可能看见服务 A 调用 B，却看不见生产上还有网关重试；看见消费者幂等，却不知道消息平台会重放多久；看见数据库事务，却不知道旁边还有 CDC 同步。
只要漏掉一个关键节点，一份看似完整的方案就可能埋下事故。
东改西改，会把模型变成技术债加速器
无流程团队还有一种熟悉的节奏：上午改目标，下午加范围，第二天老板看到竞品又换一套。人工开发比较慢，过去多少还有一点天然缓冲。需求变得比实现快，很多念头还没来得及写进代码就已经被放弃。
AI 把这层缓冲拿掉。每个临时想法都能迅速变成真实代码、配置、表字段和测试。第二天方向变化，模型又在昨天的实现上继续调整。它很少把已经没用的结构清理干净，更常见的做法是继续兼容、继续扩展、继续加分支。
一个月后，产品只剩一套当前行为，代码里却保存了过去十次摇摆的化石。没人能说清哪个分支还有用，因为每次修改都太快，没有人真正拥有完整历史。
灵活本来是能够低成本改变方向，到这里却成了低成本往代码里塞东西。两者差得很远。
十一、流程要理顺，也别把小团队拖死
为什么正确建议经常没人愿意执行
面对前面的混乱，答案似乎很简单：先补流程。需求写 PRD，交互出原型，复杂逻辑画图，技术方案评审，任务拆分，代码审查，测试验收，灰度发布，事后复盘。
可小团队之所以能活下来，往往正因为没有背上一整套流程成本。三个人共享大量上下文，一个人身兼产品、开发和运维，很多事当面几句话就能定。把大公司的流程原样搬进来，可能让原本一天能定的事开上三天会。
所以，「先规范再上 AI」不能简单理解成多加表格、审批和会议。流程是为了少丢信息、早点拦住错误，不是为了留下更多文件。每增加一个环节，都要说清它在防什么；说不清，就该删掉。
小团队需要的是最小但坚硬的流程，而不是完整但没人遵守的制度。
例如，一项普通功能未必需要十页 PRD，但至少要有目标、非目标、关键状态和验收条件；一个进程内的小改动不必开架构委员会，但跨数据边界、权限边界和外部 API 时必须留下决定记录；低风险后台页面可以快速发布，支付和账户变更则不能沿用同一通道。
流程应该随风险变化，而不是随公司人数一刀切。
流程一旦变清楚，权力关系也藏不住
理顺流程还有一个不太被技术文章提及的问题：它会重新分配权力。
以前老板在群里说一句就能改需求，现在得写清目标和验收；以前资深开发凭经验定架构，现在得解释为什么这么选；以前上线出问题大家一拥而上，现在要明确谁批准、谁值班；以前测试最后背锅，现在产品和研发也得为上游没说清楚的地方负责。
很多团队抗拒流程，不是因为不会用工具，而是流程让原本模糊的责任变得可见。
AI 恰好会加剧这种冲突。管理层希望它减少沟通，工程团队却发现要让它可靠工作，必须把过去没说清的事情全部说清；管理层希望更快，流程建设却要求在前期多花时间；管理层希望减少人员，落地初期却需要更多评估、治理和培训。
所以，AI 工程化往往不只是买个工具。它会碰到决策方式、绩效指标、团队边界和责任分配，和做一场组织手术差不多。如果公司不愿意碰这些，只想给开发装个插件，最后得到的无非是更快的代码输入法。
保护灵活，不能保护随意
小团队当然应该保护灵活。客户需求变化快、资源有限，流程太重会直接拖死业务。但灵活必须建立在清楚边界上：哪些可以口头决定，哪些必须记录；哪些能先上线再修，哪些一旦错就无法补偿；哪些模块允许快速试验，哪些核心数据必须谨慎。
灵活，是知道哪里可以弯；随意，是根本不知道哪里会断。
一个可行的做法，是把流程压缩成少数不可省略的交付物：
- 一页以内的问题说明，写清目标、非目标和验收；
- 对复杂状态或跨服务调用画一张能被更新的图；
- 高风险改动留下简短 ADR，说明约束、选择和回退条件；
- PR 保持可审查，自动测试不能由实现逻辑自证；
- 发布前明确观测指标、灰度范围和回滚动作；
- 事故后修硬约束，不只提醒大家下次小心。
这些东西不需要庞大的平台。一个 Markdown 文件、一张 Mermaid 图、几条 CI 规则就能开始。形式并不重要，重要的是这些东西真能卡住流程，而不是写完就放在那里吃灰。
十二、如果非要落地，先承认速度不是第一目标
写了这么多问题，并不是要得出禁止使用 AI 这种结论。一刀切地禁用解决不了现实，毫无节制地铺开也一样。务实的起点，是别再把「多生成代码」当成目标，先保证交付过程没有新增一堆管不住的风险。
下面几条原则不新鲜，也不漂亮，但至少能落地。
第一，按失败后果决定自动化程度
不要先按模型能力分类，先按失败后果分类。
内部一次性脚本、可丢弃原型和格式转换，失败容易发现，也容易重来，可以允许工具自动执行更多步骤。涉及资金、权限、身份、数据迁移、公共 API、核心并发和生产基础设施的变更，则默认收紧自动化范围，增加独立验证和人工门禁。
同一个模型，不应该因为它很强就不限制权限。读仓库、写分支、创建 PR、合并、发布和修改生产配置，是完全不同的能力。权限要按任务逐级给，不要把操作方便当成设计理由。
第二，限制同时推进数，而不是催人看快一点
AI 让同时开工变得太容易。一个开发者可以让多个任务并行生成，但团队的审查、测试和发布容量没有同步增长。
所以要限制 WIP：一个人最多同时推进多少个 AI 任务，一个模块最多容纳多少项未合并变更，审查队列积到多长就暂停生成。看起来是在主动减速，其实是在保护整体吞吐。队列里的半成品越多，上下文切换、代码冲突和返工就越严重。
工厂不会因为上游机器更快，就允许半成品堵满每条通道，软件团队也不该。
第三，让测试独立于实现意图
能从需求和不变量生成的测试，不要只从现有代码生成。关键场景要由不同角色定义，至少让测试提出的问题与实现者不同源。
重要链路不能只测正常返回，还要覆盖重复、乱序、超时、部分成功、依赖不可用、旧版本共存和数据恢复。并发与长期运行的问题，则需要竞态检测、压力测试、故障注入和资源观测。测试不是为了把 CI 变绿，而是让问题尽早暴露。
第四，给 Review 设置预算和停止规则
给审查设预算，要同时管住两头：一个 PR 不能大到让人看不懂，审查过程也不能没完没了地追求完美。
先根据风险确定必须回答的问题。阻塞意见需要证据和后果，风格问题交给确定性工具，超出本次范围的优化单独记录。模型互审可以用来寻找盲区，但不能拿最终决定权。争议来回两轮仍未收敛，就让负责这个系统的人面对面做取舍。
审查结束不是因为所有人和所有模型都无话可说，而是已知风险已经降到团队愿意承担的水平。
第五，评价从生成阶段走到生产阶段
不要拿代码行数、提交数、PR 数和模型调用量证明提效。它们最多说明生产动作变多。
更值得看的指标是：需求到稳定上线的周期、返工比例、变更失败率、故障恢复时间、缺陷逃逸、人工审查时间、回滚次数，以及上线后维护同类需求的成本。还要观察分布，不只看平均数。十个小功能快一倍，抵不过一次核心故障让全团队停工两天。
如果一个 AI 工作流让编码更快，却让 Review 排队更久、线上缺陷更多、资深开发更疲惫，它不叫提效。至少不能只用一个平均工时把问题盖住。
第六，保留随时降级和退出的能力
模型、供应商和工具链变化太快，团队不该把核心流程焊死在某个黑盒上。重要规则要落实到测试、策略和权限里；模型调用要留下记录；升级前重新跑自己的评估集；新版本先小范围试用；行为异常时能够退回人工或旧流程。
还要定期问一个没人喜欢的问题：这套 AI 流程还值得维护吗？
有些自动化在模型进步后变得多余，有些在业务变化后不再划算，有些从来没有改善最终交付。能够下线无效系统，也是工程能力。别因为团队已经投入半年，就继续为一条漂亮但无用的流水线续费。
十三、结语：代码落了地，责任不能悬空
全世界都在探索 AI 如何落地。有人研究模型，有人搭 Agent，有人接知识库和工作流。每条路都能做出演示，也都能在短时间里弄出不少东西。
可软件一旦进了生产，大家面对的还是那些老问题：需求说清楚没有，边界划得对不对，数据会不会乱，失败以后怎么恢复，代码以后谁敢改，变更有没有人认真审，半夜出事又由谁接手。
AI 没有让这些问题过时，反而让人更容易跳过它们。异步、抽象和代码组织一旦出现大的失误，问题就注定会被隐藏，在很久之后才会暴露；工作流依赖模型临场发挥，今天验证过的行为明天就可能变；同模型做审查，容易沿着原来的错误思路一直走，换几个模型互审，又可能把一件小事越改越大。实现看起来便宜了，PRD、计划、上下文准备和人工审查却越来越重。
刚接入的时候尤其容易放松，功能出得快，流水线一直绿，大家自然会觉得方法已经跑通。等到全团队铺开，逐个 PR 仔细审查变成口号，QA 又被当作成本削掉，服务完全不可用这种原本听起来离谱的故障，也就没那么离谱了。
复盘报告最后常写着「人员疏忽」「评审不足」「流程执行不到位」。这几句话未必错，只是没写完：组织接入了一个需要大量验证的系统，又让代码产出超过人的承受能力，最后还假设每个人都能永远仔细。
管理者该修的是这套工作方式，而不是盯着某个人反复强调「下次小心」。限制变更规模，明确责任边界，保留独立的质量视角，用硬门禁挡住高风险动作，再把事故教训落实到规则里。团队成员也得学会理解和管住工具，不能只学会让它多写几行。
那些没有原型、没有文档、没有图，靠口头传需求、靠关键员工记历史的公司，更不能指望 AI 救命。它会把组织里的含糊迅速翻译成代码，也会把每天的摇摆一层层积成技术债。要用它，得先收拾开发流程；可流程一动，又会碰到小团队看似灵活、实际相当脆弱的组织结构。这才是落地最麻烦、也最少有人愿意谈的地方。
想让 AI 落地，该问问自己：谁确认需求没有被猜错？谁知道这个抽象为什么存在？谁能证明测试没有和实现一起误解？谁有时间逐行理解改动？谁决定现在可以停止优化？上线后哪里会坏？坏了谁能看见？谁有权回滚？半年后模型换了、原作者走了，剩下的人还敢不敢改？
如果这些问题没有答案，所谓落地，不过是代码已经落进仓库，风险还悬在半空。生产事故不是信仰之跃，而是自由落体。