AI 研发共生架构：别再问 AI 会不会替代程序员啦！

AI 研发要按认知复杂度分工：高认知放大判断，低认知扩展吞吐。
原文链接：AI 小老六

这几年只要聊到 AI Coding，十有八九会绕回那个老问题：AI 会不会替代研发。听多了以后，我反而觉得这个问题有点耽误事。它太大，也太像一个茶水间话题，落不到每天怎么写代码、怎么交付需求、怎么推工具的具体选择上。

真正把团队卡住的，通常不是 AI 会不会写代码。它当然会写，问题是哪些活应该让它写，哪些活只能让它帮你想。

架构取舍、方向判断、探索性验证，这类任务人不能退到后面；配置变更、模板代码、规范化文档，如果还让人一行行盯着，又是在浪费 AI 最擅长的吞吐能力。

认知复杂度分层：先判断任务该由谁掌舵

AI 与研发组织的关系，不是简单的“工具”或“替代”。更准确的说法是 人机共生，但这种共生至少有两种形态。

分工维度	AI 助手模式	AI 虚拟外包团队模式
适合任务	架构设计、技术探索、核心算法、安全决策、产品创新	CRUD、配置变更、模板化代码、文档生成、明确需求交付
人的职责	定方向、做判断、给约束、审关键路径	设验收标准、看关键节点、处理异常
AI 的职责	扩展思路、补齐上下文、加速验证	执行任务、循环自检、批量交付
能力要求	推理强、上下文理解深、能跟上人的思考节奏	稳定、可控、成本合理、失败可恢复
评价标准	探索周期是否缩短，方案质量是否提升	吞吐量、覆盖率、交付速度和良品率
主要风险	AI 推理跟不上，反而拖慢心流	任务边界不清，产线批量制造坏结果

这张表背后的矛盾很朴素：掌控感和规模速度很难同时拿满。需要创造性判断的任务，过早交给 AI 主导，人的审核会变成补锅；本来可以标准化的任务，硬让人一行行盯着，又会把 AI 的吞吐优势锁死。

图：高认知任务保留人的判断，低认知任务释放 AI 的吞吐

Code Completion 到 Agent：控制粒度一路上移

AI Coding 最早的形态是 代码补全。那时 AI 像一支更聪明的笔，人仍然逐字逐句控制节奏。这个阶段看似简单，工程上却很难：补得太多，用户删得比写得多；补得太少，又像没帮上忙。速度、质量和打断感之间，需要反复取舍。

补全背后还有一类容易被忽略的能力：心流预判。用户不会声明下一步意图，工具只能从光标、上下文、代码结构和最近编辑轨迹里猜。IDE 侧的 LSP 解析、上下文抽取、本地小模型加速，本质上都是为了让 AI 更贴近人的当前思路。

后来 Solo、CLI 和 Agent 模式出现，控制粒度从“行级补全”上移到“任务级执行”。人不再逐行告诉 AI 写什么，而是把一个较完整的任务交出去，再检查文件级结果。AI 的角色也从笔变成了初级工程师，人的角色从写代码变成审代码。

指标也随之变了。只看 AI 代码占比并不可靠：删掉的算不算？重构的算不算？AI 写了 100 行，人改了 50 行又怎么算？

更硬的指标是商业价值：AI 的产出能不能变成可交付、可复用、可收费的结果。

虚拟员工产线：AI 执行，人卡住关键节点

一旦把 AI 视为初级工程师，下一步自然会想到 虚拟员工模型：一个人管理多个 AI 执行单元。它不是让 AI 完全自由发挥，而是把需求理解、方案评估、执行、自检、人工接管和验收串成一条产线。

图：从需求录入到交付反馈，AI 执行与人工关键节点形成闭环

这条链路里，harness、loop、computer use 不是概念装饰，而是良品率问题。没有任务编排，AI 很容易跑偏；没有循环验证，错误会堆到最后才爆；不能操作真实环境，很多任务只能停留在文本推演。

早期做这类商业化探索，很容易撞到现实墙。Agent 深度能力不够时，研发投入压不住交付成本；客户一多，沟通成本会指数级上升；离岸、建站、标准交付都能试，但 ROI 不一定算得过来。

这个失败本身有价值，它会逼着团队理解哪些热词确实解决工程问题，哪些只是听上去先进。

今天的变化是试错成本低了。一个过去需要小团队做两周的原型，现在可能一个人带着 AI 两天就能跑出来。AI 工具的形态很难在会议室里一次设计正确，更适合先做出能碰的东西，让真实用户把边界撞出来。

组织推行：问题常常不是意识，而是模式错配

从个人提效走向组织提效，最先遇到的往往不是模型能力，而是 任务分配方式。很多推广失败会被归因成“用户意识不够”，但实际情况更复杂。有些工作确实必须人主导，比如架构演进、安全审查、核心算法设计；有些工作则早就该交给 AI 主导，比如批量配置、模板化开发、规范化文档。

组织使用 AI，最好先做加法，而不是一上来谈减人。AI 的更大价值，是把低价值的重复投入压下去，让人的时间回到判断、创造和承担责任的地方。组织真正想要的不是少几个人，而是规模化能力和创造力同时往前走。

这里可以借用红旗法案的旧故事。1865 年英国要求机动车前面必须有人举红旗步行引导，出发点是安全，结果是把汽车限制成了马车时代的附属物。AI 工具推行时也会出现类似“旗手”：一些人力环节存在，只是因为旧流程还没更新。

图：旧流程会把 AI 降速，分级治理才能同时兼顾风险和效率

如果风险还不能承担，就不要硬上全自动；但也不要为了心理安全，把每个 AI 动作前面都塞一个人。更合理的做法是分级：L1 任务全自动，L2 任务 AI 主导人审核，L3 任务回到助手模式。

图：不同风险和复杂度的任务，需要进入不同的人机协作层级

幻觉责任边界：工具要锋利，用户要验刀口

AI 会犯错，会编造看起来合理的答案，这是现阶段绕不开的技术事实。工具开发者当然要降低幻觉率，也要给出风险提示、二次确认、代码变更检测和必要护栏。但如果要求工具替用户兜住所有风险，最后做出来的只会是一把钝刀。

责任主体	应该承担的部分	不该混淆的部分
工具开发者	降低幻觉率，提供风险提示，构建关键操作护栏，让工具在能力范围内稳定可靠	不可能保证 AI 永远不犯错，也不能替用户承担所有业务后果
使用者	判断 AI 产出，评估场景风险，决定是否采纳和上线	不能一边要求能力足够锋利，一边要求没有任何割伤可能

这不是推卸责任，而是工程边界。高级能力必然带来开放性，开放性必然伴随风险。真正成熟的工具，不是把所有能力锁死，而是在高风险节点给出明确的刹车。

AI 助手模式：让模型跟上人的心流

助手模式适合高认知复杂度任务。人在这里仍然是驾驶员，AI 负责拿地图、查资料、生成备选方案、快速验证想法。评价它的方式，不是写了多少代码，而是人的认知探索有没有变快。

这也是为什么大家会追 SOTA 模型。助手模式对推理、上下文理解和长程记忆要求很高。模型跟不上时，用户会花大量精力纠错，心流被打碎；模型跟得上时，它能把一个人的试错半径显著放大。

助手模式还有一个现实成本：AI 需要被“养”。它要理解个人习惯、项目上下文、团队规范和业务边界，这些都来自持续交互、Skill、知识库和文档沉淀。组织里的 AI 提效团队不能把这笔成本全丢给用户，否则很多人会在早期就放弃。

虚拟外包团队模式：把可验收任务做成吞吐系统

虚拟外包团队模式适合边界清楚、验收明确、风险可拆的任务。人不需要陪着 AI 写每一行代码，只需要定义输入、验收标准和异常处理规则。服务器越多，数字员工越多，吞吐就有机会线性扩展。

这种模式最怕两件事：

第一，任务其实是 L3，却被伪装成 L1，最后 AI 批量产出不可维护的东西。
第二，验收标准太虚，导致 AI 看似完成，实际上没人敢合并。

产线化的前提不是“相信 AI”，而是把任务切到 AI 可以稳定交付的颗粒度。

用一句话说，助手模式追求认知突破，外包团队模式追求交付吞吐。前者像开车探索新路线，后者像无人货车在已知路线跑批量运输。把无人货车开进未知山路，或者让驾驶员每天手推货车，都不合理。

图：一个模式服务判断和探索，另一个模式服务标准化交付

AI Native 组织：知识沉淀先于组织形态变化

如果把视角再拉远，AI Native 组织的第一层基础设施不是模型，而是知识沉淀。决策上下文、技术判断、讨论纪要、业务规则和失败经验，都要从人的脑子里变成 AI 可以利用的显性知识。

这件事对两种模式都重要。助手模式里，知识沉淀会让 AI 越来越懂个人和团队；外包团队模式里，上下文越完整，AI 自主执行的成功率越高，人介入的次数越少。

更远一点，组织可能会从“每个人有 AI 分身”，走向 AI 分身之间直接协作，也就是 AI Swarm。再激进一点，整个组织可以被看作一个 Agent：系统维护业务世界模型，人作为现实世界的端点提供感知、信任判断、伦理决策和文化语境。

Block 讨论过类似观点：传统层级制本质上是信息路由协议，因为一个管理者只能有效管理有限人数，组织才需要中间层层转发。AI 让这个约束开始松动，世界模型可以把上下文直接送到端点。Notion 也从技术革命角度谈过相近判断：工具变化最终会改变组织形态和工作的定义。

这不意味着任何组织都应该立刻重构。能做，不等于该做。AI Native 转型需要持续投入，每一步都要算清 ROI，即便是长期投入，也要有阶段性回收和风险边界。

落地判断：先找 L1，再养 L3

真正可执行的起点不复杂。

先把团队工作按 认知复杂度 分层。L1 是 AI 可以全自动跑的任务，L2 是 AI 主导、人审核的任务，L3 是人主导、AI 辅助的任务。不要从最复杂的 L3 开始证明 AI 很强，也不要把所有任务都压成 L1。

然后挑一个 L1 场景跑通最小闭环。输入、执行、验证、异常回收、人工确认、交付反馈，都要闭上。闭环比单次炫技更重要。

最后开始沉淀知识。AI 时代的组织能力，很大一部分会体现在知识是否能被机器稳定读取、复用和更新。没有这层基础设施，助手模式养不熟，产线模式跑不稳，所谓 AI Native 也只会停在口号里。

AI 不会用同一种方式改造所有研发工作。它在高认知任务里放大人的判断，在低认知任务里替组织扩展吞吐。

真正要问的不是 AI 会不会取代我，而是：这件事的认知复杂度是多少，它应该进入哪一种人机分工架构。

AI小老六