过去一年，在 Agent 管理学论坛 与众多开发者的交流中，我们不断探索、踩坑、复盘，最终形成了一套关于 AI 编程有效方法的阶段性总结。
一、一个翻篇的争论
“AI 写的代码根本不能用。”
这个论调从 ChatGPT 刚问世时就一直存在，并一路延续。在此期间，AI 不断刷新着它所能处理的项目规模，但类似的批评却从未停止。
直到 2025 年底，风向开始转变。
Andrej Karpathy 公开表示 AI 编程将成为软件工程的未来。就连 Linus Torvalds 也开始尝试用 AI 辅助写代码。这些信号似乎表明，即便是最顽固的传统技术圈也开始接受现实。
更令人瞩目的是一些具体案例：
- Anthropic 使用 Claude Code 从零构建了一个 C 编译器，并且成功编译了 Linux 内核。
- 在 FAST 会议上，出现了完全由 AI 编写的可扩展文件系统。
- PingCAP 的 CTO 黄东旭、太极图形的创始人胡渊鸣等知名技术专家，都是 AI Coding 的深度使用者，甚至在其团队内部大规模推广。
于是，一个问题自然而然地浮现出来：
同样的 AI 工具，为什么有些人能用它打造出生产级系统、显著提升团队效率，而有些人用它开发一个简单的 Web 个人项目都漏洞百出？
如果你也曾被这个问题困扰，那么本文正是为你准备的。一言以蔽之：AI Coding 的核心挑战，往往不在于技术，而在于管理。
二、技术先锋的受挫
当 Anthropic 公布完全由 Claude Code 开发的 C 编译器时，除了普遍的惊叹，技术社区的质疑声也同样响亮：宏定义未被使用、路径硬编码、没有处理 x86 16 位实模式启动代码……评论区里，对 AI 能力的嘲笑声此起彼伏，仿佛在说：“看吧，AI 还是不行，我依然不可替代。”
一个有趣的现象是：越是传统意义上的技术高手，在接受和使用 AI 编程时，反而可能越慢。问题或许不在于 AI 本身，而在于他们的管理思维尚未同步更新。
把 AI 当作你的新同事
想象一下，你招聘了一位智商极高、学习能力极强，但却是第一天入职的新员工（管理 AI：你职业生涯中最重要的一次晋升）。你只对他说了一句话：“写一个能编译 Linux 的编译器。”然后呢？
他几乎不可能直接交出一份兼容所有生态的全功能编译器。Hello World 能不能跑？你没说。动态链接库如何处理？你没提。16 位实模式的启动代码是自己实现还是调用现成工具？当你验收时，你可能会觉得他在“瞎搞”。
但问题的根源，其实是你的管理方式出了错。
从你的“常识”出发，一个编译器“理所当然”应该能编译所有合法的 C 代码。然而，在另一些人的“常识”里，一个只实现了基本语法、作为编译原理课程大作业的程序，也可以被称为编译器。
AI 会严格遵循你定义的标准，然后停在那里。如果你的标准模糊不清，它就会停在一个符合它“常识”的地方——无论这个“常识”是否符合你的预期。
这正是技术专家容易产生抗拒心理的原因。他们擅长将清晰的需求转化为完美的代码，但问题恰恰出在需求本身——如何把需求说清楚、把边界定明确、把验收标准量化。专家们嘲笑 Claude Code 编译器的种种不足，却可能忽略了，他们自己曾经写出的优秀软件，很多时候并非仅凭一己之力，而是依赖于清晰的行业标准和完善的产品定义。
一个百年经济学难题的启示
经济学中有一个研究了数十年的经典问题：委托-代理问题。巧合的是，经济学中的“Agent”与我们今天谈论的 AI Agent 是同一个词。当 AI 的能力足够强大时，我们完全有理由将其视为一个经济学意义上的行为主体。
当你把任务委托给一个 Agent，天然会面临三大挑战：
- 信息不对称：你并不完全清楚它在具体执行什么。
- 目标偏差：它的理解和你的意图可能存在出入。
- 验证困难：你很难客观地评判它的工作成果。
管理学给出的答案是建立契约与制度：明确目标定义，设置过程检查点，制定可衡量的验收标准。我们的答案在本质上与此一致。这也是我们将论坛命名为“Agent 管理学”的原因——AI 编程的管理是高效的基石。
三、确定性的边界：三段式管理框架
好的管理者不会，也不可能审查团队的每一行代码，他们充分信任成员的能力。高效的管理不在于追求每一步的完美控制，而在于在关键节点设定清晰的标准，并在过程中留出足够的发挥空间。
我们将这些关键节点称为“确定性的边界”，并将整个 AI Coding 的流程拆分为三个阶段，在每个阶段建立明确的契约。（详细讨论）
3.1 需求端：文档即产物，AI 即编译器
在传统开发中，代码是最终的交付物。但在 AI Coding 时代，这个定义需要被颠覆：文档才是最终产物。
此时，AI 扮演的角色更接近于一个“编译器”——它把你的文档“编译”成可运行的代码。正如编译器的输出质量取决于输入源码的质量，AI 产出的代码质量也直接取决于输入文档的质量。
这意味着你的文档必须足够扎实、精确。一个可行的实践路径是：从产品需求文档（PRD）出发，生成架构设计文档，再细化为详细的执行文档，最后让 AI 严格按照执行文档进行实现。
诸如 Kiro、SpecKit 这类工具确实能在早期帮助你快速搭建文档框架。但若将其奉为最终答案，很多人尝试后会觉得“不过如此”，随即放弃。问题出在哪里？
既然文档成了核心产物，那么文档本身就需要被验收和测试。用一句话生成 Spec，与用一句话生成软件，其本质是一样的——都是把不确定性交给了 AI，最终必然走向失控。
这里存在两个现实难题：第一，AI 生成文档的速度是人类阅读速度的几十倍，你根本看不过来。第二，如果你让另一个 AI 来 Review，它通常会给出“结构清晰，建议补充异常处理”这类正确但无用的反馈，什么问题都解决不了。
问题的症结不在于“Review”这个动作本身，而在于大多数人在拿到一份 Spec 时，根本不知道应该关注什么。
许多技术人员会下意识地去审查架构是否合理、接口命名是否规范、数据模型是否优雅。事实上，AI 在这些技术细节方面往往做得很好，甚至有时“太好”了。
然而，我们要审查的唯一核心部分，是用户故事（User Story）。用户故事描述的是真实用户要使用软件完成的真实任务。例如，“作为一名主播，我需要在直播间内发起投票”——这就是一个清晰的用户故事。它不关心你的架构如何设计、API 如何命名、使用何种数据库。它只关心一件事：用户能否顺利完成他想做的事。
反过来说，如果你的文档能让每一条用户故事从头到尾逻辑自洽地走通——每一步需要调用的接口都有明确定义，参数和返回值都完整，各种异常情况都有覆盖——那么这份文档就是完整的。
这就是我们所说的“文档测试”：用用户故事作为测试用例去“运行”文档，这与主观的“文档评审”截然不同。让 AI 拿着每一条用户故事逐步推演，其结果是确定性的，不依赖于任何人的主观判断。
当然，架构层面的评审仍然必要，只是这部分工作可以交由不同的 AI 模型从多个角度进行交叉验证，这比一个人盯着看效果更好，成本也更低。人负责把控用户故事的价值与合理性，AI 负责验证技术细节的完备性，各司其职，各守其层。
3.2 执行端：注意力的边界
AI 有一个与人类相似的重要特性：注意力有限。当上下文窗口（Context Window）中塞入过多信息时，它的表现会显著下降。
因此，每一次交给 AI 的任务，必须严格控制在它能有效处理的范围内。这可以从两个维度来把控：
- 空间上，要模块化：你必须为它提供完整的输入条件——这个模块要实现什么功能、输入是什么、输出是什么。API 契约（Contract）要写清楚，用测试套件把边界框定好。在这个明确的“围栏”内，AI 可以自由发挥；围栏之外的事情，它无需操心。
- 时间上，要分步推进：即使在同一个模块内，也不能一次性把所有需求丢给它然后祈祷奇迹发生。你需要将任务拆解成小块，每一小块完成后立即验收，然后为下一小块重新整理、提供干净的上下文。你给它的上下文越干净、越聚焦，它的输出质量就越高。
在这两个维度之上，我们还建议引入一个独立的 AI 来 Review 每次的代码提交，确保改动没有超出当前任务的范围。
3.3 验收端：没有清晰标准，就别怪 AI 不行
这是三个阶段中最关键的一环。 大多数人对 AI Coding 的不满，其根源往往在于验收标准模糊不清。（不谈质量控制的 AI Coder 都是菜鸟）
回到编译器的案例：技术社区的许多批评其实没有切中要害，因为项目的验收标准是“编译 Linux 6.9 内核”，而不是“做一个通用的、完美的 C 编译器”。你在契约中没有明确写明的要求，Agent 没有义务去实现。 如果你在意 Hello World 程序能否运行，那就把它明确写进测试套件。
AI 的产出速度是人类的数十甚至上百倍。在这种速度下，一个微小的偏差如果没有被及时发现，几小时后就可能演变成遍布几十个文件的系统性灾难。因此，你必须在每一步完成之后立刻进行验证，确认没有跑偏，再进入下一步。
我们的做法是 将测试基础设施前置（测试：AI Coding 的终极测试手段）。在所有执行文档生成完毕之后、第一行业务代码落地之前，先根据 API 契约搭建完整的测试框架。所有暂时不存在的依赖，全部用 Mock Server 和模拟数据替代，从而构建一个与整个服务解耦的独立测试体系。一旦 AI 的执行偏离了轨道，测试会立刻发出警报。
如果你发现自己写不出测试，那先别急着写代码——写不出测试，恰恰说明你的需求从一开始就是模糊的，你需要回去完善文档。
PS：任何鼓吹 AI 编程却不包含测试与质量管控基建的框架，都可以被统一归为“大忽悠”。
在自动化测试之外，对抗式的代码审查（Adversarial Code Review） 是另一层重要保障。每次 AI 产出代码后，交给另一个 AI（最好是不同的模型）进行审查：代码是否严格遵循了执行文档？测试基建负责验证“结果对不对”，对抗式审查则负责验证“过程有没有越界”。这两层共同构成了验收端的确定性边界。
四、迈向 AI 原生团队
第三章讨论的是如何管理好单个 Agent 完成一项任务。但在实际项目中，你不可能只开启一个会话。根据我们在 Agent 管理学论坛中的观察，成员们在日常开发中同时调度二三十个 Agent 并行工作已是常态。
当进入多 Agent 并行协作阶段时，第三章提到的那些基础设施——API 契约、Mock Server、测试套件——就从“最佳实践”变成了“生存前提”。我们早期曾踩过坑：每个 Agent 的独立产出都能通过测试，但合并在一起就冲突不断，根源在于模块间的契约不够明确。解决方案没有捷径，就是回归基本功，把契约做得足够扎实，让每个 Agent 都能在完全独立、定义清晰的环境里工作。如今，这些实践已被部分整合进主流编程框架，例如通过 git worktree 进行工作区隔离，已成为 Cursor 和 Claude Code 的标准能力。
技术上的协调问题终有解法。但当这个问题被解决后，一个更根本的组织性问题便浮出水面：人该如何组织？
一个人带领三十个 Agent 的产出量，已经超过了传统的五到十人团队。生产力发生了质变，组织方式必然需要随之进化——就像蒸汽机促使手工作坊演变为工厂，并非因为工厂“更好”，而是作坊已无法承载新的产能。传统的一个技术负责人（Tech Lead）带领五六个工程师（IC）的结构，在每个人都能带领三十个 Agent 时，反而会制造出更多的协调开销。
目前，我们观察到两条主要的演进路线：一条是 头狼模式，另一条则是我们论坛正在探索的 Tri-Ownership（三方责任制）模式。
头狼模式的天花板
PingCAP 的 CTO 黄东旭在其 Vibe Engineering 实践中，生动展示了头狼模式的威力：单人驱动大规模 Agent 协作，利用 AI 重写了 TiDB 的 PostgreSQL 兼容层，且代码质量接近生产水平。他使用了一个非常精准的比喻——头狼带领狼群在自己的领地上耕耘。
头狼模式的优势显而易见：决策链条极短，几乎没有沟通损耗，一个人的审美与判断可以贯穿产品的始终。但它也存在两个硬性限制：
- 协作壁垒：同一片“领地”里很难容纳两匹头狼，1+1 可能小于 2。顶尖工程师各自的 Agent 工作流、Prompt 风格、代码习惯都高度个性化。两个顶尖个体很难在同一个模块内高效协作，因为他们各自训练出的 Agent 团队可能“语言不通”。
- 验收瓶颈：黄东旭本人坦言，他 90% 的时间花在了评估 AI 的工作成果上。以他的能力尚可驾驭，但对于大多数人而言，Agent 军团的产出速度是人类的百倍，如果验收能力跟不上，只会导致“屎山”加速堆积。
- 人才稀缺：头狼本身是极度稀缺的资源。能端到端负责一个产品所有环节的人，在任何组织中都凤毛麟角。
头狼模式证明了 AI 原生开发的可行性，但它对个体的综合能力要求极高。
拆解“超级个体”：Tri-Ownership 模式
既然“超级个体”可遇不可求，另一个思路便是：将超级个体所需的能力拆解开来，分配给三个可培养、可协作的角色。 （学习 PingCAP，打造你公司的 AI 原生软件开发团队）
- 产品负责人（Product Owner, PO）：负责决定“做什么”。定义产品愿景、管理用户故事、设定功能优先级。PO 对最终产出的业务价值负责，其最重要的能力之一是敢于果断地说“不做什么”。
- 技术负责人（Tech Owner, TO）：负责决定“怎么做”。带领 Agent 军团完成所有开发工作。其核心工作不再是亲手写代码，而是编排多个 Agent 的工作流、设计模块边界、处理执行过程中出现的各类异常。
- 质量负责人（Quality Owner, QO）：负责判断“做得对不对”。独立于开发流程，全周期管理质量。从用户故事阶段就参与验收标准的定义，到测试框架的搭建，直至最终的端到端验收。
QO 的独立性是整个框架的关键。 这又回到了对抗性的逻辑：由 TO 控制的 Agent 军团所交付的产物，天然需要一个独立的第三方进行验证。NASA 在“挑战者号”航天飞机事故后建立了独立的“验证与确认”项目，其核心原则便是软件的验证必须由独立于开发者的团队执行。我们借鉴的正是同样的思想。
你会注意到，在这个团队结构中，已经没有了传统意义上的“程序员”角色。写代码的是 Agent。人类成员的核心工作转变为定义需求、设定边界、审查产出、协调冲突——这些全部都属于管理工作的范畴。
即使是两人团队也可以基于此模式运转：由 PO 兼任 QO，与 TO 搭档。虽然验收的独立性会有所折扣，但对于较小的项目而言已经足够。
五、展望与结语
需要明确的是，本文讨论的所有实践，主要针对的是超大型、企业级的 AI Coding 项目——例如开发一个需要长期维护的数据库、云端协作工具或商业系统。对于小型或个人项目，你当然不需要如此“重型”的流程。
更令人兴奋的是另一个方向。在一些开放性、探索性的问题上，我们发现如果适当放手，让 Agent 自主规划路径，其效果常常超出预期。你只定义高层次的目标，让它自己去构思方案、制造工具、在循环中迭代优化。AI 在这种自主模式下展现出的“创造力”，时常让我们感到惊讶。
这或许预示着一个趋势：随着模型能力的持续增强，我们需要人为建立的“确定性边界”将会越来越少。 管理的颗粒度会从微观走向宏观，从“定义每一步操作”走向“定义终极目标，然后放手执行”。今天你可能需要撰写详细的执行文档，明年或许只需要提供 PRD，而后年可能仅需描述用户故事即可。确定性的边界不会消失，但它会不断向上抽象，变得更加宏观。
同时，必须认识到 AI 对不同个体的增益效果方差极大：对用得最好的人可能是 10 倍增效，对普通人可能只有 10%。AI 不是一个均匀的效率提升器，它是一个放大器，放大的是你自身的管理能力与系统思维。
程序员们曾引以为傲的“手艺”正在快速贬值。但与此同时，系统设计能力、需求分析能力、对业务本质的深刻理解，反而变得前所未有地重要。 Agent 能写出任何你能够描述清楚的东西，但它无法替你决定“应该写什么”，因为它并非自己成果的真正用户。
如果你从创造和构建中获得成就感，那么当下无疑是一个最好的时代。
你对 Agent 的管理能力，将直接决定你创造力的上限。 在云栈社区的技术论坛中，我们持续探讨着这些前沿实践，与开发者共同成长。
发表于 昨天 08:41
|
查看: 7|
回复: 0
