AI 原生架构团队的工作方式

这里是Z哥的个人公众号

每周五11：45 按时送达

当然了，也会时不时加个餐～

我的第「234」篇原创敬上

大家好，我是Z哥。

最近很多团队都在聊 AI 落地，我也分享下我实践下来的一些感受和观点，供大家参考和讨论，欢迎大家在评论区一起交流下经验和心得。

与身边的朋友交流 AI 落地话题的时候，我发现一个很常见的问题是：大家容易把 AI 落地理解成「给团队配工具」。

比如给大家开通一个 AI 编程工具，做几场分享，沉淀一些 Prompt，统计一下使用率。看上去事情做了不少，但过一段时间再看，团队的工作方式并没有发生本质变化。

该串行的还是串行。

该返工的还是返工。

该靠少数人兜底的还是靠少数人兜底。

所以，我现在越来越觉得，AI 原生架构团队的核心，不是「用不用 AI 工具」，而是「工作协议有没有被重写」。

如果只是在旧流程里塞一个 AI 工具，它最多是一个更快的螺丝刀。

但 AI 真正带来的变化，是让很多过去必须顺序推进的事情，可以变成并行推进；让很多过去靠人脑记忆的上下文，可以变成可复用的工作环境；让很多过去只能靠经验兜底的质量问题，可以变成工程化的反馈回路。

这才是架构团队真正应该关心的地方。

AI 原生团队，不是多写几个 Agent，也不是把文档丢给 AI 总结一下。

它应该是一套新的工程生产方式。

/01 AI 落地的第一层误区：把工具当能力/

很多人判断 AI 落地有没有效果，第一反应是看工具。

有没有用 Cursor？

有没有用 Claude Code？

有没有用 Codex？

有没有搭 MCP？

这些当然重要，但它们不是问题的核心。

工具只能提升单点效率，能力系统才能提升团队产能。

一个人用 AI 写代码快了 30%，这叫个人效率提升。

一个团队能把需求拆解、上下文构建、代码生成、测试验证、评审修复、经验沉淀连成闭环，这才叫团队能力提升。

两者不是一个层级。

可以用一个简单公式看：

AI 团队产能 = 模型能力 * 上下文质量 * 流程反馈 * 人的判断密度

很多团队只盯着第一个变量：模型能力。

模型升级了，工具升级了，插件变多了，感觉产能就应该上去。

但实际情况往往不是这样。

如果上下文是乱的，AI 会更快地产出错误结果。

如果流程反馈是断的，AI 会更快地把问题扩散到后面。

如果人的判断密度下降，AI 会更快地制造一种「看起来已经完成」的错觉。

所以，AI 落地不是简单做加法。

不是：

旧流程 + AI 工具 = AI 原生团队

更准确地说，应该是：

新协作协议 + 可复用上下文 + 自动化反馈 + 人的方向判断 = AI 原生团队

架构团队最应该切入的，就是后面这几个变量。

哪些上下文应该被沉淀？哪些约束应该被显式化？哪些失败应该被工程化消除？哪些工作方式应该变成团队默认动作？

这些问题不解决，只换工具，80% 概率会变成一场热闹的效率幻觉。

/02 原来的研发流程为什么不够用了/

传统研发流程里，很多事情是串行的。

产品先想清楚需求，研发再理解需求，技术方案再评审，开发再写代码，测试再验证，最后上线。

这个流程在过去很合理。

因为人的协作成本高，对齐成本高，返工成本也高。大家只能尽量在前面想清楚，然后把事情一棒一棒往后传。

但 AI 进入之后，一个重要变量变了：很多探索动作的成本下降了。

以前一个模糊需求，如果同时让多个人并行分析，成本很高。现在可以让 AI 先做多路探索：

一路拆业务流程。
一路找技术风险。
一路整理历史上下文。
一路生成测试样例。
一路检查类似模块的实现模式。

这些探索结果不一定都对，但它们能更早暴露问题。

这意味着，我们不一定非要等到需求完全清晰，所有角色才开始动作。

更合理的方式是：拿到一个模糊输入之后，相关职能就可以并行启动，但要提高对齐频率。

这就是 AI 原生协作和传统协作最大的差别之一。

传统协作强调「先想清楚，再往下走」。

AI 原生协作更强调「先快速展开，再高频校准」。

注意，这不是鼓励瞎干。

恰恰相反，它对人的方向感要求更高。

AI 可以帮我们更快展开可能性，但方向还是要人来把握。否则团队会变成一个高吞吐、低判断的生成机器，做了很多东西，但不知道为什么做，也不知道哪些东西值得做。

所以，架构团队要设计的不是「怎么让 AI 多写代码」，而是「怎么让 AI 参与一条更可靠的工程链路」。

比如：

一个需求进来后，哪些上下文必须先收集？
哪些架构约束必须显式提供给 Agent？
哪些检查必须在代码生成前完成？
哪些结果可以交给 AI 先跑，哪些必须人工判断？
每一轮对齐要看什么证据，而不是只听口头进度？

这些问题，比「选哪个 AI 工具」更接近本质。

/03 文档不再是参考资料，而是 Agent 的世界模型/

过去我们写文档，很多时候是给人看的。

人看文档有一个特点：可以脑补。

文档里漏了一点上下文，他可以问旁边的人；接口说明写得不完整，他可以翻代码；架构约束没有写清楚，他可以凭经验猜。

Agent 不一样。

Agent 理解一个项目世界，主要就靠你给它的上下文。

所以，在 AI 编码场景里，文档的性质变了。

它不再只是「给人看的参考资料」，而是 Agent 认识世界的入口。

换句话说：

文档质量，直接决定 Agent 的工作质量上限。

如果知识库里只有一些泛泛而谈的介绍，比如系统分几层、用了哪些框架、有哪些目录，那它对 Agent 的帮助很有限。

真正有价值的文档，应该包含这些东西：

业务概念的定义。
模块边界和职责。
关键数据流。
架构约束。
常见错误模式。
测试和验收方式。
历史决策原因。
不能改的地方，以及为什么不能改。

尤其是最后两类，很重要。

人类工程师经常依赖「组织记忆」工作。比如某个字段不能随便改，某个接口看起来奇怪但兼容了历史系统，某个表不能直接删，某个流程上线前必须额外确认。

这些信息如果只存在于少数人脑子里，对 AI 来说就是不存在。

于是 Agent 就会很自然地做出「局部正确、全局错误」的修改。

这也是为什么 AI 时代的架构约束不再是大团队才需要的奢侈品。

它变成了 Agent 能否稳定工作的前置条件。

团队要做的知识库，也不应该是「AI 帮我生成一堆文档」。

那样很容易变成另一种垃圾堆，只是看起来更整齐。

真正的知识库建设，本质是把团队的隐性判断显性化，把历史经验结构化，把质量标准上下文化。

一句话：不是为了让文档更多，而是为了让 Agent 和新人都能更少猜。

/04 流程一致性，是 AI 时代的低成本保险/

很多人一听到流程，就会本能反感。

因为在不少团队里，流程经常意味着慢、重、形式主义。

但这里要区分两个东西：流程负担和流程一致性。

流程负担当然应该减少。

但流程一致性不能轻易丢。

尤其到了 AI 时代，代码产出速度变快了，小改动变多了，多分支并行变多了，如果质量反馈跟不上，风险会被更快地放大。

以前一个人一天写 100 行代码，出问题的范围有限。

现在一个人带着 AI 一天可以改多个模块。如果缺少稳定的验证机制，问题不一定更少，可能只是更隐蔽。

所以，AI 原生流程的目标不是把流程做重，而是把关键动作做成低摩擦的默认路径。

比如：

需求进入前，必须有最小上下文。
开发开始前，必须知道验收标准。
TDD 实现阶段，测试和实现要一起推进。
修改完成后，必须跑 lint、typecheck、test、build。
评审时，必须检查是否破坏既有约束。
发现 Bug 后，不只是修代码，还要补 Harness。

这里的 Harness 可以理解成一套防复发机制。

比如一次问题暴露出测试缺口，那就补测试。

一次问题暴露出脚本缺口，那就补脚本。

一次问题暴露出知识库缺口，那就补文档。

一次问题暴露出 Prompt 或工作流缺口，那就改工作流。

否则每次都只是修当下的 bug，团队永远在同一个坑附近反复摔。

AI 时代尤其不能这样。

因为 Agent 最大的特点之一，就是它会非常认真地复用你给它的错误上下文。

如果 Harness 没修好，同类问题就会换一种形式回来。

所以，流程一致性不是为了显得专业，而是一种便宜保险。

好的流程不应该因为需求小就被跳过。需求足够小时，流程本身也会自然变轻。一个 6 行代码的小改动，完整流程可能几分钟就跑完。

真正危险的是「这次很小，就算了」。

企业级系统里，很多大事故都不是从大改动开始的，而是从一次看起来很安全的小改动开始的。

/05 架构团队的价值，要从评审方案变成设计生产线/

过去很多团队对架构工作的理解，容易停留在几个动作上。

比如方案评审、技术选型、规范制定、疑难问题处理。

这些事情当然还重要。

但 AI 时代，一个变化是：很多具体执行动作会变便宜，很多局部方案的生成成本也会下降。

写一段样板代码，生成一个接口，补一个测试，查一段资料，甚至先生成一版技术方案，这些事情的边际成本都会下降。

如果架构团队的价值主要体现在「我比别人更懂，所以我来评审你」，这个优势会被逐渐稀释。

更高层的价值，应该是设计一条更好的工程生产线。

这里的生产线不是流水线工厂，而是一个稳定产生高质量交付的系统。

它至少包括四类资产。

第一类，工作流资产。

比如从需求输入到设计、TDD 实现、评审、发布、复盘的 Agentic Coding 流程。每个阶段有哪些输入、输出、检查点和失败处理方式，都应该变成可执行的规范。

第二类，上下文资产。

比如知识库、架构约束、模块说明、接口契约、历史决策、常见坑位。这些决定 Agent 能不能理解项目。

第三类，质量资产。

比如 lint、typecheck、test、build、E2E、代码扫描、评审清单、验收脚本。这些决定 AI 产出的东西能不能进入主干。

第四类，评测资产。

比如 AI Coding 测评任务集、典型业务任务、复杂度分层、上下文缺失场景、反模式样例。这些决定团队能不能客观判断 AI 工作流有没有变好。

如果这四类资产能逐步成型，架构团队就不只是一个「方案评审团队」。

它会变成组织里的工程能力放大器。

/06 一个小例子：把真实需求变成 AI 工作流资产/

这里举一个脱敏后的例子。

假设团队接到一个看起来很小的需求：在某个业务页面上增加一个状态展示，同时后端接口需要补充一个字段，前端要根据状态做不同展示。

如果按传统方式做，这可能就是一个普通小需求。

开发看一下代码，改接口，改页面，跑一下测试，然后提 PR。

如果改动很小，很多团队甚至会觉得：不用搞那么复杂吧？

但如果我们用 AI 原生方式处理，它就不只是一个小需求，而是一次工作流校准机会。

第一步，不是直接让 Agent 改代码，而是先补上下文。

比如让它先回答几个问题：

这个状态字段来自哪里？
是否已有类似字段？
前端是否已有相同展示模式？
这个接口是否被其他页面复用？
测试里有没有覆盖这个状态？
如果字段为空或异常，页面应该怎么展示？

这一步的目标，不是让 AI 给最终答案，而是暴露上下文缺口。

第二步，把需求拆成一个小任务包。

任务包里至少包含：

背景说明。
涉及模块。
预期行为。
不允许破坏的兼容行为。
需要新增或修改的测试。
验收命令。

第三步，让 Agent 按 TDD 方式实现。

不是先写完代码再补测试，而是先根据预期行为补测试，再实现逻辑，再跑验证。

如果测试写不出来，通常说明需求或上下文还没讲清楚。

第四步，跑统一 Gate。

比如 lint、typecheck、unit test、必要的 E2E 或页面检查。这里不要靠「我看着没问题」，而是尽量让验证动作可重复。

第五步，复盘这次小需求。

重点不是复盘「这个字段加得怎么样」，而是复盘：

哪些上下文一开始没有给够？
Agent 哪一步最容易跑偏？
哪个测试提前拦住了问题？
哪条文档应该回写？
这个需求能不能沉淀成测评任务？

你会发现，一个小需求如果这样跑完，它的价值就不只是交付了一个字段。

它还沉淀了上下文模板、TDD 样例、验证命令、失败模式和测评任务。

这就是 AI 原生工作方式和普通 AI 辅助写代码的区别。

前者在交付需求的同时积累系统能力。

后者只是把这一次代码写快一点。

/07 一个最小可行的 AI 原生闭环/

原因清楚了，具体可以怎么做呢？

我认为可以先从一个最小闭环开始，不要一上来做大而全的平台。

第一，选一个真实业务需求作为战场。

不要只做 demo。

demo 太容易成功，也太容易骗自己。真正有价值的是拿一个有历史包袱、有协作依赖、有测试要求的真实需求，看看 AI 工作流能不能跑通。

第二，为这个需求构建最小上下文包。

上下文包至少包含：

业务背景。
模块边界。
关键接口。
数据流。
约束和风险。
验收标准。
相关历史决策。

这个上下文包不是一次性文档，而是后续知识库的样板。

第三，把流程拆成稳定阶段。

比如：

需求理解（含上下文补全） -> 技术方案 -> 任务拆分 -> TDD实现 -> 评审 -> Gate -> 复盘

每个阶段都要定义输入、输出和失败处理方式。

第四，把质量检查脚本化。

能脚本化的就不要靠口头提醒。

lint、typecheck、test、build、关键 E2E、基础安全检查，这些都应该尽量变成默认路径。

第五，建立 AI Coding 测评任务集。

把真实需求里的典型任务抽出来，沉淀成可重复运行的测评任务。

不同任务可以按复杂度和上下文完整度分层：

简单单模块任务。
多模块联动任务。
跨服务或跨系统任务。
文档充分的任务。
文档缺失或过时的任务。

这样才能判断工作流是不是在变好，而不是只凭感觉说「这次还不错」。

第六，每次失败都修 Harness。

失败不可怕。

可怕的是失败没有留下资产。

一次失败之后，至少要问：

是上下文缺失吗？
是约束没写清楚吗？
是测试没覆盖吗？
是评审清单漏了？
是 Agent 指令不够明确？
是人没有做关键判断？

问完之后，必须回写到文档、脚本、测试、模板或流程里。

/08 最后，AI 原生不是让人退场/

很多人聊 AI，最后都会落到一个问题：人还重要吗？

我的判断是，人会更重要，但重要的方式变了。

过去人的重要性，更多体现在执行。

谁写代码快，谁经验多，谁能救火，谁就重要。

AI 时代，这些能力仍然有价值，但人的核心价值会越来越偏向判断：

判断什么问题值得做。
判断什么上下文必须补。
判断什么约束不能破。
判断 AI 的结果能不能信。
判断一次失败应该沉淀成什么机制。
判断团队能力应该往哪里演进。

所以，AI 原生不是让技术人退场。

恰恰相反，它要求技术人更像技术人。

少做一次性的救火，多做可复用的系统。

少做口头经验传递，多做显性化的工作协议。

少做工具推广，多做能力建设。

少做个人兜底，多做组织放大。

好了，总结一下。

我对 AI 原生架构团队的理解，可以压成几句话：

AI 原生团队不是用 AI 工具，而是重写协作协议。
文档不是人的参考资料，而是 Agent 的世界模型。
流程一致性不是形式主义，而是 AI 时代的低成本保险。
架构团队的价值不只是评审方案，而是设计工程生产线。
人的核心价值没有消失，只是从执行更多转向判断。

这件事不会一蹴而就。

但如果一个架构团队能围绕真实业务需求，把上下文、流程、质量、评测一点点沉淀出来，它就不只是跟上了 AI 时代。

它是在为组织打造一套新的工程能力底座。

这可能才是 AI 时代架构团队最值得争取的位置。

原创文章，转载请注明本文链接: https://zacharyfan.com/archives/1626.html

关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描二维码~
定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。
如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。

如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。

Related posts:

发表评论 取消回复

发表评论取消回复