先说一个我们团队亲身经历，尤其是新项目启动，大家兴致勃勃的时候。
一打开 AI 编程工具，描述了需求，几分钟后几百行代码就跑出来了，而且效果还不错。第一天，进度惊人；不到一周，功能基本就齐了，然后事情开始不对劲。
第二周，AI 改一个功能，顺手把另一个改坏了，没人发现。第三周，同一份数据在两个地方各存了一份，改了一边忘了另一边，线上出了诡异的问题。到第二个月，团队里最常听到的对话变成了：
"这段逻辑是谁写的？"
"不知道，AI 写的。"
"那这块现在能不能动？"
"最好别动。"
代码量翻了几倍，对系统的掌控感却没了。
后来复盘，问题不在 AI 写代码的能力。恰恰相反，它写得太快太顺，快到那些原本用来"慢下来想清楚"的环节——讨论方向、对齐方案、审查计划——全被绕过去了。
速度放大了效率，也放大了混乱。
过去大半年，我们围绕"人和 AI 怎么协作开发"做了大量尝试，踩了不少坑，沉淀出一套方法。这篇不讲工具技巧，讲的是更底层的问题：AI 把"写代码"这件事变得极其廉价之后，一个开发团队里最值钱的工作到底是什么。
一共 6 条，全都是真金白银换来的。
一、方向没定，写得越快偏得越远
第一个坑：方向还没聊清楚，就让 AI 动手。
一次功能改造，需求讨论会上大家说了句"这个应该不难"，散会后有人直接让 AI 开写。代码很快出来了，评审才发现：目标用户理解错了，核心流程走偏了，还顺手引入了一个团队从没用过的新框架。返工花的时间比从头做还多。
从那以后我们立了条规矩：复杂项目必须先回答清楚核心问题，才允许讨论技术方案。
-
目标用户是谁？
-
核心要解决什么问题？
-
做到什么程度算成功？
-
还有同样重要的：明确不做什么。
听起来是常识，但 AI 时代它们格外关键。过去"想清楚"和"动手做"之间隔着高昂的开发成本，不想清楚不行。现在动手成本趋近于零，"先做了再说"成了最自然的冲动。
而方向错误的高速执行，比不执行更糟。它不只浪费投入，还留下一堆要人来收拾的代码。
我们现在的做法：任何新项目或重大改造，先形成一份简短的方向共识，写清楚用户、核心流程、成功标准、不做的范围、约束条件。已有共识直接复用。这份东西不用长，但必须存在，还方便复盘。
先明确做什么、为什么做，再讨论系统怎么承载。顺序不能反。
二、计划不等于授权
第二条，花的代价最大。
AI 很会做计划。给个任务，它能输出一份看起来相当完整的实施方案：步骤清晰，模块分明，连测试都安排好了。第一次看到时我们的反应是："挺好，就这么干。"
然后，我们学会了后悔。
计划里藏着错误的前提：它以为某个老模块能复用，其实不行；它漏掉了数据迁移的风险；它规划的一步改动，实际会冲破两个模块之间约定好的边界。这些问题等代码写完才暴露，代价就大了。
现在团队有条铁律：AI 输出的第一版计划，只是讨论稿，不是施工许可。
计划出来，流程先停。人核对一遍：这计划解决的真是我们要的问题吗？目标、范围、那些不可逆的选择，对吗？再来一轮系统性的拷问，从用户价值、能否复用现有能力、有没有引入多余的东西、每一步怎么验证、失败了怎么回滚，逐条过。
有个细节值得说。如果审查发现计划有大问题，我们让 AI 生成一份完整的替代计划，而不是在旧计划后面打补丁。补丁摞补丁的计划，执行到一半一定乱。
目标、范围、依赖、风险、回滚、验证方式，都没有阻断性问题，计划才被授权实施。
多这一步，看着慢，但我们算过账：审查一份计划半小时，返工一次要三天。
三、系统里每样东西，都得有唯一的"主人"
第三条关于架构，尽量用大白话说清楚。
AI 有个倾向：为了让眼前这步走得通，它会就地取材。这里加张表，那里存份状态，临时开个接口。单看每步都合理，累积起来就是灾难：同一份数据存了两个地方，同一个逻辑有两条路径，出了问题没人说得清该信哪个。
我们管这叫"事实源失控"。
对应的规矩：数据、状态、权限、重试机制、对外副作用，每一样都必须有唯一的责任归属。
功能该进哪个模块、数据存哪、出问题谁兜底，动手前就得有答案。AI 的方案里一旦出现"第二个事实源"或"临时兼容路径"，必须给出充分理由和退出条件，否则打回。
配套原则：优先复用成熟能力。动手前先问，现有模块能不能满足？团队已接受的技术栈里有没有现成方案？想引入新框架、新数据库、新队列，先证明现有能力确实不够，再说清楚将来怎么退出。
说到底，架构纪律保护的是团队自己对系统的理解力。系统里每一处"例外"，都是未来某个深夜的一次加班排查。
四、把"任务清单"换成"验收节点"
第四条，怎么管进度。
传统拆法是这样的："完善认证模块""优化数据层""接入第三方服务"。这种拆法在 AI 时代特别危险，因为 AI 会非常高效地把这些模糊任务逐项"完成"，打满勾，然后你得到一个看似做了很多事、实际无法验证的系统。
我们的替代做法：把工作拆成"验收节点"。
验收节点，就是一个有明确结果、拿得出验收证据的交付阶段。判断标准很简单：它描述的是可观察的结果，还是一组动作？
"用户能够登录并恢复会话"，是验收节点。
"完善认证模块"，不是。
每个验收节点写清四件事：
-
交付什么可观察的结果
-
允许改动哪些范围
-
依赖什么前置条件
-
怎么验证
一次只做当前这个节点，做完、验证完、集成完，再推下一个。
最大变化是汇报方式。我们不再接受"完成了 70%""改了 15 个文件"这种说法。能力状态只有一种表达：哪些验收场景真实通过了，证据是什么。
任务数、文件数、百分比，都不是进度，通过的验收才是。
五、人和 AI 之间，划一条决策边界
第五条，对带团队的人可能最有用：分工的边界画在哪？
我们按"可逆性"划线。
AI 默认负责的：
-
读仓库、读文档、补齐事实
-
比较技术方案并给出明确推荐——是给推荐，而不是把一堆没背景的选项扔回来让人挑
-
决定局部的、可逆的实现细节
-
设计测试、回滚和恢复方法
-
对错误或低质量的方案提出反对（一个只会服从的 AI，不是好同事）
必须人来确认的：
-
产品目标、目标用户、业务优先级
-
不可逆或高成本的技术路线变化
-
生产数据变更、对外发布、付费资源
-
权限扩大、安全例外、风险接受
-
多个方案存在真实产品取舍时的最终拍板
一句话：AI 对事实证据、技术判断和实施质量负责；人只在需要产品判断、或要承担不可逆后果时做决定。
两个极端都要避免。一个是让 AI 全权决定，出了不可逆的问题才发现没人把关。另一个是每个技术细节都交还给人："用 A 库还是 B 库？""加不加这个参数？"这是让没有上下文的人替 AI 做技术判断，低效又容易错。可逆的技术选择，AI 调研完直接给推荐，这是它的本分。
高质量的协作，不是 AI 一味服从，也不是人全程微管理。
六、别信"已完成"
最后一条，也是最短的一条：别信"已完成"。
AI 说"做完了"，这句话本身不构成任何信息。我们要求每次交付必须附带证据：实际跑了哪些命令，结果是什么，哪些检查通过，哪些失败，哪些没验证，还剩什么风险。失败项和未验证项必须如实报告，不许含糊带过。
验证也有章法。小步修改，每完成一个有效增量，先跑最近的、成本最低的检查：改了一个模块，先跑这个模块的测试。全部完成后再跑完整回归和实际运行验证。模块测试和集成测试都要留着，前者证明零件是好的，后者证明装在一起能转。
这套要求有个意外收获。"如实报告失败"成了规范之后，AI 的交付质量反而明显提升。它知道含糊过不了关，就会在交付前自己把验证做扎实。
写在最后
回头看这大半年，最大的体会是：AI 把写代码的成本降到接近零，其他环节的价值全被相对放大了。想清楚方向、审查计划、守住架构边界、明确分工、严格验证，这些过去被开发成本"顺带保护"的东西，现在得靠纪律维持。
如果你的团队也在用 AI 开发，可以从三件最小的事开始：
-
下个功能动手前，花二十分钟把"目标用户、成功标准、不做什么"写下来，和 AI 对齐。
-
AI 给的第一份实施方案，无论多完整，先当讨论稿，逐条拷问之后再授权。
-
从今天开始，不接受任何没有验证证据的"已完成"。
工具会继续进化，模型会越来越强，但这套协作的底层逻辑，先想清楚，再做扎实，大概不会过时。
因为真正稀缺的从来不是产出代码的能力，而是对结果负责的能力。
你们团队用 AI 协作开发时，踩过最深的坑是什么？留言区聊聊。如果身边有正在被 AI"提速"折磨的同事，可以把这篇转给他。