降低 AI 辅助开发摩擦的五种模式

当我与同事结对编程时，一些协作惯例会很自然地形成。让他们真正开始贡献代码之前，我会先带他们熟悉代码库；开始实现之前，我们会先在白板上画出思路；我会解释团队的约定、限制条件，以及过去某些技术决策背后的原因；最终，我们也会按照团队标准来审查产出。

但在使用 AI 编码助手时，我注意到，大多数开发者——包括最初的我自己——往往会跳过这些步骤。我们输入提示词，期待得到符合预期的输出，然后又困惑于为什么结果总是不太对。

AI 辅助开发的前景确实令人兴奋：开发速度显著提升，代码可以即时生成，还有一个随时在线的“结对程序员”。它们的普及程度也相当惊人——从不少行业观察来看，如今许多专业开发者已经在日常工作中使用海外某些公司推出的 AI 编码工具。

然而，一种持续性的挫败感也正在浮现。AI 生成代码所节省的时间，常常又会被后续修正代码所消耗。我亲身经历过，也听很多人描述过一种我称为“挫败循环”的模式：生成代码，审查代码，发现它不符合当前代码库，再重新生成并修正，再次审查，最后要么接受一个已经被大幅修改过的结果，要么彻底放弃这次尝试。

这种模式太常见了，值得我们认真研究。我认为，问题并不在于 AI 能力不足——现代语言模型已经相当强大。真正的问题在于：我们还没有学会如何与这些系统有效协作。

AI 编码助手的挫败循环

典型的交互模式大致如下：

开发者要求 AI 创建一个服务。AI 很快给出响应，生成了一段语法正确、也符合训练数据中常见模式的代码。但项目实际使用的是某个轻量级 Web 框架，它却用了另一套更常见的服务框架；团队约定是将文件放在 lib/services/<file>，它却放进了 utils/<file>；代码库已经采用函数式风格，它却生成了一套基于类的实现。

每一次修正都需要额外的生成轮次。随着轮次增加，AI 辅助开发带来的速度优势也逐渐消失。

生成 → 审查 → “不太对” → 重新生成 → 审查 → “还是不对” → 放弃

这种循环之所以会持续出现，是因为 AI 助手默认会从训练数据中提取模式，而这些训练数据汇总了数百万个代码仓库中的写法。它生成的往往是某种“互联网平均值”，而不是符合某个特定团队架构和规范的代码。

常见症状包括：

• AI 生成的方案与现有架构不匹配。
• 开发者需要花大量时间做后期编辑。
• 对话初期建立的上下文会随着会话变长而逐渐丢失。
• 输出质量会因不同团队成员的提问方式而波动。

AI 辅助开发中的速度衡量陷阱

问题的一部分在于，我们衡量这些工具成功与否的方式并不准确。团队通常会追踪诸如“首次输出时间”或“生成代码行数”之类的指标。这些指标很容易获得，也能立刻体现出某种“效率”，但它们掩盖了真正的成本。

如果 AI 能在几秒钟内生成 200 行代码，但开发者需要花 30 分钟去审查、调试和重构，才能让它符合团队模式，那么所谓的生产力提升就值得怀疑。工作重心只是从“编写代码”转移到了“修复代码”，总工作量未必真的减少。

当我与人类同事结对编程时，我不会用他们的打字速度来衡量成功。我更关心的是：他们的贡献是否符合代码库的要求？是否解决了正确的问题？是否经得起代码审查？

同样的原则也应该适用于 AI 协作。

更有价值的指标应聚焦于我所说的“协作质量”：

误导性指标	更有价值的替代指标
首次输出时间	首次通过率
生成代码行数	每个任务的迭代轮次
已完成任务数	合并后的返工量
生成速度	相比手写代码增加的审查负担

对于追踪研发效能指标的团队来说，首次验收率可以作为变更失败率的领先指标。如果一段代码必须经过大量修正才能投入使用，说明它在方向上已经存在偏差；而带着这种偏差发布的代码，最终往往会演变为技术债务。

从 AI 工具到 AI 队友

一个有用的认知转变是：不要再把 AI 仅仅视为工具，而应开始把它视为队友。这个区别听起来像是语义上的变化，但实际上会带来非常具体的实践影响。

AI 助手就像一个精力无限、但缺乏上下文知识的初级开发者。它们比任何人都快，永不疲倦，也从不抱怨。但它们并不了解某个特定项目的约定、限制或历史。如果没有获得团队通常会提供给人类协作者的指导，它们只能依赖那些未必适用的通用模式。

想想我们是如何与新团队成员合作的。我们不会指望他们第一天就写出高质量、符合架构的代码，更不会指望他们在缺乏背景信息的情况下做到这一点。我们会帮助他们入职，带他们熟悉代码库，解释架构决策背后的模式和逻辑，和他们一起完成最初的任务，并按照团队标准审查他们的成果。

这与 AI 协作之间的相似性很有启发：

人类结对编程中的做法	AI 协作中的等价做法
“我先带你看一下这些文件。”	在请求代码之前，先提供架构背景
“我们先在白板上画一下。”	实现前进行结构化设计讨论
“这里的评论机制是这样工作的。”	将团队标准编码为可复用的提示词或命令
“我把这个决策更新到文档里。”	保留决策，使其跨越会话边界仍然可用
“这次我们学到了什么？”	系统记录哪些做法有效、哪些无效

AI 的速度很快——快得惊人。但它也需要和人类搭档一样的协作条件：

• 入职培训：在贡献代码之前，需要先了解代码库背景。
• 白板讨论：在实现之前，需要先进行结构化设计。
• 护栏机制：需要持续、稳定地应用标准和质量检查。

AI 协作的五种模式

我提出的框架由五种互补模式组成。每一种模式都对应 AI 协作中的一种典型失败模式，同时也映射到一种已经被证明能提升人类协作质量的实践。

1. 知识启动：让 AI 理解项目上下文

人类类比：新员工入职培训

在让 AI 生成代码之前，先提供经过整理的项目上下文：技术栈及其版本、目录结构、命名规范，以及现有模式的示例。这本质上是一种手动的检索增强生成：用高价值、项目特定的信息填充上下文窗口，从而覆盖通用训练数据带来的默认倾向。

就像我会在要求新团队成员贡献代码之前，先带他们熟悉代码库一样，我也会先给 AI 提供它生成正确输出所需要的上下文。

解决的失败模式： AI 缺乏项目特定上下文，因此默认采用通用模式。

2. 设计优先协作：先明确方案，再生成代码

人类类比：编码前的白板讨论

与其要求 AI 立即生成代码，不如先循序渐进地完成设计：明确功能，再拆解组件、交互和契约，最后才进入实现。这类似于高效的人类协作中，写代码之前先做白板讨论的过程。

当我和同事合作开发复杂功能时，我们不会一上来就敲代码。我们会先画出草图，统一实现思路，并在误解演变成 bug 之前及时发现问题。同样的原则也适用于 AI 开发。

解决的失败模式： AI 在真正理解需求之前就直接进入实现，最终生成了技术上可行、但解决了错误问题的代码。

3. 编码化团队标准：减少 AI 生成代码的返工

人类类比：资深开发者的工程直觉

每个团队里通常都有一些资深开发者，他们能凭直觉判断代码是否“对味”——他们可以发现其他人容易忽略的架构偏差、安全隐患和规范违规。这种直觉非常宝贵，但如果只存在于少数人的脑海中，就很难扩展。

解决方法是将隐性知识显性化。就像我会向新成员解释团队惯例一样，我也会把这些默认规则写下来，让它们能够被共享，并能用于 AI 协作。当团队标准以具体文本存在，而不是只依赖个人直觉时，无论是谁在提示 AI，这些标准都能更稳定地发挥作用。

解决的失败模式： AI 生成了技术上正确、但违反团队预期的代码，导致大量返工。

4. 上下文锚定：避免 AI 在长对话中遗忘决策

人类类比：用文档记录决策

维护一份动态文档，用来记录功能开发过程中的决策、限制条件和当前状态。这份文档相当于外部记忆，能够锚定那些可能随着对话变长或会话结束而丢失的上下文。

在人类协作中，我会随着决策的产生自然地更新共享文档。同样的做法也能防止 AI 在后续对话中自相矛盾，或忘记之前已经达成的结论。在实际团队中，这类文档可以沉淀在 PingCode 的 Wiki 中，让需求背景、技术决策、评审结论和复盘经验在研发流程中持续流转，而不是散落在一次次临时对话里。

解决的失败模式： AI 在长时间对话中忘记先前决策，导致输出前后矛盾、不一致。

5. 反馈飞轮：持续提升 AI 协作质量

人类类比：复盘与持续学习

系统性地从 AI 交互中汲取经验，并用这些经验改进前面四种模式。当某个提示词特别有效时，把它记录下来；当 AI 持续误解某类问题时，把相关说明加入启动上下文；当出现新的失败模式时，为它补充防护措施。

就像团队会通过复盘会议不断学习并改善协作方式一样，我们也应该积累关于“如何与 AI 高效协作”的组织知识。如果团队已经使用 PingCode 这类智能化研发管理工具，也可以把需求、任务、测试、发布和知识沉淀串联起来，让 AI 协作中的经验不只停留在个人层面，而是逐渐转化为团队可复用的研发资产。

解决的失败模式： 团队反复犯同样的错误，却没有沉淀出关于有效 AI 协作的组织经验。

构建人与 AI 的共享心智模型

这些模式共同作用，在人类与 AI 之间构建出一种共享心智模型。

当双方使用相同的词汇体系（通过知识启动）、相同的架构愿景（通过设计优先的讨论）、相同的质量标准（通过编码化的规范），以及相同的决策历史（通过上下文锚定）时，AI 辅助开发中的翻译摩擦就会显著减少。

认知负荷也会随之转移：开发者不再需要持续保持警惕、不断纠正 AI 的偏差，而是可以更专注于表达意图和完善结果。这就是“与工具搏斗”和“与能干的伙伴协作”之间的区别。

我的假设是，如果这些模式能够被持续、一致地应用，就会带来显著改进：

• 更高的首次通过率，减少“生成—修复—重新生成”的循环。
• 每个任务所需的迭代轮次更少。
• 合并后的返工量更低。

这些结论尚未经过充分验证——目前它们仍是一个基于摩擦来源及其可能解决方式推导出来的框架。我的早期实验结果令人鼓舞，但仍需要更多实践和观察。

权衡与局限

这种方法并非没有成本。创建和维护启动文档需要投入精力；先进行设计讨论，再要求 AI 编码，也比直接让它生成代码更耗时；而且，要持续坚持这些模式，本身也需要纪律。

对于简单、一次性的任务，额外开销可能并不值得。一个简单的工具函数或直接的重构任务，未必需要完整的设计讨论。真正能体现投入回报的，通常是更复杂的工作，尤其是那些跨越多个会话、涉及多人协作，或需要与既有架构深度融合的任务。

此外，这种方法也存在学习曲线。习惯于把 AI 当作搜索引擎或自动补全工具的团队，可能会觉得结构化协作的方式并不自然。这个转变需要有意识地练习。

接下来会怎样？

本文概述了 AI 辅助开发中的摩擦问题，并提出了一个应对框架。五种模式都值得进一步深入探讨：

• 知识启动：应该包含哪些内容、如何组织，以及如何保持更新。
• 设计优先协作：如何分层设计，以及如何应对 AI 想跳过设计直接实现的倾向。
• 编码化团队标准：如何将隐性知识显性化，并把资深成员的工程直觉扩展到整个团队。
• 上下文锚定：如何管理长时间对话，以及如何处理会话边界。
• 反馈飞轮：如何系统性改进，并衡量真正重要的指标。

后续文章将逐一深入讨论这些模式。

根本洞察其实很简单：AI 助手能力强大，但缺乏上下文感知。那些让人类协作变得高效的做法——入职引导、结构化讨论、共享标准、决策记录和持续学习——同样适用于 AI 协作。

我相信，能够内化这种协作方式的开发者，会把 AI 从一种阻力变成真正的研发效能倍增器。