4浏览
广告时刻：我们来自政企前台研发团队，我们团队通过专注于探索、研发、打造采购解决方案，将前沿技术与多年经验深度融合，致力满足企业的多种需求。同时，整合顶尖专家资源，利用前沿科技探索采购领域新知识，产出领先的行业洞见，不断推动中国企业采购行业向前发展。欢迎大家一起交流。团队急需算法及研发人才加入，如果你感兴趣，或者有推荐的人才，欢迎加入我们，base 北京，邮箱：limengdong@jd.com。
引子：一个被问烂、却没答清楚的问题
"AI 会不会取代程序员？"——这个问题被问了三年，答案在两极之间反复横跳。乐观的人说"它只是个高级补全，离取代还远"，悲观的人翻出某条招聘缩减的新闻就开始焦虑。亦或者深度使用的人，兴奋与恐惧交织，希望与迷茫并存。两种声音，多种情绪都对了一半，也都错了一半。
问题出在"替代"和"共生"被当成了一道单选题。仿佛 AI Coding 要么是来抢饭碗的对手，要么是来打下手的助理，二选一。但如果你真正把 AI 编码工具用进日常工作流，会发现它根本不是单选题——替代与共生是同一个过程的两面：每当 AI 把一类工作"替代"掉，人的工作重心就会向上挪一层，而新的协作界面就在这一层重新长出来。能力在下沉，人在上移，两者同时发生。
不过，这种"两面一体"，描述的是个人工作方式的演变，不等于"总量上谁都不会被替代"。它和效率、增长、座位多少等等都有关系，文末会有我浅显的一些观点。在这之前，还是先把更有操作性的问题讲述一下：在能力演进的每个阶段，AI 替代掉了什么、人接管了什么、协作的界面长在哪里？ 这篇文章会沿着"工具 → 副驾 → 协作者 → 共生体"这条演进线，把每一阶段的此消彼长拆开。中间我会用我们团队现在是如何开展AI-Coding，以及如何让 AI 主动做需求分治作为案例，因为它恰好把替代与共生的分工暴露得很彻底。
先抛出本文的核心判断：AI Coding 替代的从来不是"编程"，而是编程中可被形式化、可被检索、可被流程化的那部分；它无法替代、反而越来越依赖的，是判断、取舍、约束和对错的裁定。 演进的每一步，都是把前者交出去、把后者攥得更紧的过程。
一、为什么"共生 vs 替代"是个伪命题
把编码工作想象成一个分层的结构。最底层是机械性的：语法、样板、API 调用方式、把一个想清楚的逻辑翻译成某种语言的语句。往上一层是局部构造：实现一个函数、写一个服务、补一段测试、定位一个明确的 bug。再往上是工程编排：把一个需求拆成若干模块、设计接口契约、协调系统间的依赖、保证整体一致性。最上层是意图与判断：这个需求到底要解决什么、几种方案如何取舍、什么风险可以接受、什么必须人来拍板。
AI Coding 的演进，本质上是这条"能力下沉线"从下往上推进的过程。补全工具吃掉了最底层；对话式和 inline 编辑吃掉了局部构造层；agentic 的工具开始啃工程编排层。每推进一层，"替代"就发生在那一层，而"共生"的界面就上移到紧邻的上一层。
关键在于：下沉是有上限的。越往上，工作越依赖那些无法被形式化的东西——对业务的理解、对历史包袱的记忆、对"够好了"的判断、对责任的承担。这些恰恰是当前的 AI 最薄弱、也最需要人补位的地方。所以每一次"替代"非但没有让人失业，反而把人逼到了价值密度更高的位置上。焦虑的人盯着脚下被抽走的那层地板，看不见自己其实是被顶高了。
这不是安慰话。它有一个很硬的推论：如果你的工作重心始终停留在被下沉的那一层，那么被替代的风险是真实的。 共生不是自动发生的福利，而是一种需要主动完成的迁移——把自己的注意力从"怎么写"挪到"写什么、为什么、对不对"。下面四个阶段，既是工具能力的演进史，也是这条迁移路线的地图。
二、阶段一：工具——补全与片段，替代"机械记忆"
最早进入主流视野的 AI Coding 形态，是以智能补全为代表的"工具"阶段。它的交互极其克制：你打字，它在光标后面给出灰色的建议，你按 Tab 接受或继续打字忽略。
它替代了什么。 这一阶段替代掉的是编程里最机械的部分：记不住的 API 签名、写过一百遍的样板代码、for 循环的骨架、错误处理的固定结构、一个数据结构转成另一个的样板转换。这些东西的共同特征是——它们不需要"思考"，只需要"想起来"。对它们的掌握程度，本质上是一种昂贵的肌肉记忆，而这种记忆恰恰是模型从海量代码里学得最扎实的部分。
共生界面在哪。 在这个阶段，人和 AI 的协作界面非常低——低到几乎是"逐 token"的。你心里已经想好了这一行要干什么，AI 只是帮你把它快速敲出来。判断权百分之百在人手里，AI 不参与"做什么"的决策，只加速"怎么敲"的执行。这种协作的妙处在于它几乎没有信任成本：建议错了，你一眼就能看出来，代价只是多打几个字。
人的角色变化。 表面上看，人的角色没怎么变，还是那个写代码的人。但有一个微妙的转移已经开始：当样板代码的书写成本趋近于零，人对"记住怎么写"的投入开始贬值，对"知道该写什么"的投入开始升值。一个只会快速敲样板、但说不清这段代码为什么这么写的人，第一次感到了隐隐的不安。这是下沉线推进的第一声。
边界与风险。 这一阶段的风险被低估了：补全的"顺手"会诱导你接受看似合理、实则微妙错误的代码。它在你最不设防的地方——那些"应该没问题"的样板里——埋下偏差。所以即便在最低阶的协作里，"人来裁定对错"的原则也已经成立了，只是代价低到容易被忽略。
三、阶段二：副驾——对话与局部自主，替代"局部实现"
当交互从"补全光标后的片段"升级为"对话"和"选中一段让它改写"，AI Coding 进入了副驾阶段。这一阶段的标志是：AI 开始能完成一个有边界的完整任务——实现一个函数、重构一个类、根据描述写一个组件、解释一段你看不懂的代码、定位并修一个你描述清楚的 bug。
它替代了什么。 替代的是"局部实现"这一层。你不再需要亲手把一个想清楚的逻辑逐行翻译出来，而是用自然语言描述意图，由 AI 产出一段可用的实现，你来审阅和调整。注意这里的关键词是"局部"和"有边界"——任务的范围越清晰、上下文越自包含，副驾干得越好；一旦需要跨越多个文件、理解大量隐含约定，它就开始力不从心。
共生界面在哪。 协作界面从"逐 token"上移到了"逐任务"。人负责定义任务、提供上下文、审阅产出；AI 负责在给定边界内生成实现。这里第一次出现了真正意义上的"信任成本"：AI 产出的一段代码，你要花时间读懂、验证、决定接受还是打回。当任务足够小，验证成本低于自己写的成本，协作就是划算的；当任务太大太模糊，验证成本飙升，甚至超过自己写，协作就开始亏本。这个"验证成本"的概念，会一路贯穿到后面所有阶段，是判断人机分工是否健康的核心标尺。
人的角色变化。 人开始从"实现者"向"描述者 + 审阅者"转变。这个转变比看上去更深刻：它要求你把脑子里模糊的意图，精确地表达成 AI 能执行的描述——这本身就是一种被低估的能力。同时它要求你具备快速审阅陌生代码、判断其正确性的能力。有意思的是，审阅别人（包括 AI）写的代码，比自己写代码需要更高的水平，因为你得在没有完整心智模型的情况下发现问题。副驾阶段悄悄抬高了对工程师判断力的要求。
边界与风险。 副驾最大的陷阱是"看起来对"。它产出的代码语法正确、风格地道、命名合理，极具说服力，但可能在边界条件、并发安全、与现有代码的契合上有微妙问题。一个被它说服、放松了审阅的工程师，会把这些问题直接放进代码库。所以副驾阶段对人的要求不是降低了，而是从"能写"变成了"能判断写得对不对"——后者是更难、更稀缺的能力。
四、阶段三：协作者——agentic 与skills，替代"流程编排"
第三阶段是当前正在发生、也最值得一线同学投入精力的阶段。AI 不再只是完成单个有边界的任务，而是能够自主执行多步骤的流程：理解一个较大的目标，自己决定调用哪些工具、按什么顺序、读哪些文件、跑哪些命令，并在过程中根据中间结果调整。配合上"技能/工作流"这类可复用的编排载体，它开始啃工程里最耗人的那层——流程编排。
它替代了什么。 替代的是"把一件复杂的事拆成步骤并逐步推进"这层劳动。以前需要你亲自跑通的'入口→服务→RPC→数据库'这条链路"，现在可以打包成一个流程交给 AI 自主跑。这里替代的不是某个具体技能，而是编排本身——那种"先查 A，根据结果再查 B，然后据此产出 C"的串联工作。
这里重点分享一下我们团队现在是如何开展这个流水线的，以及如何让 AI 主动做需求分治。过去一段时间，团队里陆续沉淀了十几个 skill：从工程知识库初始化、PRD 评审、PRD 转 TRD、任务拆解、快速编码、代码验证到安全推送。
它们各自都很好用，但散落着，新同学不知道先用哪个、后用哪个、它们怎么接起来。首先我们将团队所有成员拉到一个行云空间，通过 joycode Team 上传团队级别的 智能体、skill、rule、MCP，维护团队级别的知识库、业务知识。把 team 空间里沉淀的优质 skill 串成一条完整的工作流，配上"什么交给 AI、什么人来管"的原则，目标是让每个人——无论是否资深——都能照着上手 AI 编程。
环节 0：工程知识库冷启
这一阶段不针对某个具体需求，而是为整个工程打底——让 AI "读得懂"你的项目。它是一次性的投入，却决定了后面所有阶段的质量上限：AI 对工程理解得越准，后面生成的设计和代码越靠谱。
使用启明星智能体，该智能体编排了哪些 skill。
project-init-docs：为 Java 工程生成标准化文档（README / ARCHITECTURE / AGENTS / STRUCTURE），事实优先、不确定的标"待补充"。project-knowledge-init：工程知识库的初始化与深度梳理。generate-project-spec：基于一个"规范入口类"反推全工程的生码规约，产出.mdc规则文件，让后续 AI 生码对齐现有工程风格。call-chain-analysis：沉淀方法级调用链文档，供后续检索复用。
替代了什么。 替代了人工整理项目文档、手写编码规范、梳理调用链这些枯燥但必要的基础工作。
你要盯住什么。 事实优先原则要守住——AI 标"待补充"的地方，是它没把握、需要你确认的，别让它含糊带过。生码规约（.mdc）一旦定下，会影响后面所有生成代码的风格，值得你认真审一遍。
实操提示。 新接手一个项目，或要让团队的 AI 编码流程在某项目上跑起来，先把这一阶段做完。这是"磨刀"，别省。推荐使用 Claude 模型。
环节 1：人工拆分到单应用
接到一个需求，主流程的第一步由人来完成两件最依赖经验的事：判断这个需求会涉及哪几个系统，再把需求拆解到单个应用的粒度。
为什么这一步是人来做。 因为它依赖一张只在脑子里的全局地图——这个需求会牵动哪些系统、它们之间怎么依赖、改了 A 会不会波及 B。这张地图是资深同学的核心价值，也是新人最难快速建立的部分。拆错了系统归属，后面整条链都会偏。
怎么做（实操）。
- 通读需求，列出它直接触达的系统。
- 沿系统间的依赖关系往外想一跳：被这些系统调用、或调用这些系统的旁路系统，是否也要改。这一步最容易漏。
- 把需求按系统切开，明确每个系统各自要做什么——切出来的每一份，就是后续单应用流程的输入。
你要盯住什么。 旁路/下游系统有没有漏。一个常见的坑是只盯着需求"明面上"提到的系统，漏掉了被它们依赖、其实也得改的系统。拆完后，对照阶段 0 沉淀的调用链文档复核一遍依赖。
这一步目前是人工瓶颈，也最耗资深经验。文末"进阶"一节会讲我们正在用 AI 来替代这一步的演进——但在那条路成熟铺开前，主流程里它仍由人把关。
环节 2：单应用技术设计
需求拆到了单应用，这一阶段把每个应用要做的事细化成可开发的技术设计。
用哪些 skill。
prd-to-trd：结合存量项目代码，把 PRD 转成符合项目规范的技术设计文档（TRD）；会扫描存量代码识别技术栈、公共组件、已有接口/表结构，并对模糊点标"需人工确认"。prd-logic-knowledge-builder：把 PRD 需求点绑定到接口和方法逻辑，沉淀接口级/方法级的逻辑知识库，适合需要深挖核心逻辑的需求。
替代了什么。 替代了对照 PRD 和存量代码、手写技术方案的工作，包括识别"哪些已有接口能复用、哪些表结构要改"。
你要盯住什么。 prd-to-trd 标"需人工确认"的点，就是它没把握的边界——这些往往是需求里最容易出歧义、也最容易出 bug 的地方，逐条过。它对存量代码的识别可能不全，涉及复杂历史逻辑时尤其要复核。
环节 3：设计评审（把关口）
设计出来了，先别急着写。这一阶段用评审类 skill 给方案挑刺，把问题挡在编码之前。
用哪些 skill。
JoySpace PRD Reviewer：从研发视角深度评审 PRD，输出可直接带到评审会的问题清单。asset-loss-analyzer：资损故障分析与防控评估专家——基于四维风险源头定位资损本质，对照核心防控举措排查完备性，针对涉及资金的设计输出防控方案。涉及资金、交易、资产的需求必过这一关。
替代了什么。 替代了资深同学凭经验逐条挑设计漏洞、回忆资损防控清单的工作。
你要盯住什么。 评审 skill 给的是"问题清单"，不是"结论"。它列出的疑点要你结合业务判断哪些是真问题、哪些可接受。资损这条线尤其不能省——这是底线，不是可选项。
环节 4：任务拆解
设计评审通过，把它拆成可执行的开发任务。
用哪个 skill。 java-design-to-tasks：根据技术设计或需求文档，为 Java 后端项目生成实施计划和模块级任务拆解，支持 Spring Boot 单体、JSF 微服务、MQ/定时任务三种类型。
替代了什么。 替代了把一份设计文档手工翻译成"先做什么、再做什么、每块改哪些文件"的排期工作。
你要盯住什么。 任务拆解的颗粒度和顺序。AI 拆的任务有时会漏掉跨模块的依赖顺序，或把一个大任务拆得过粗。过一遍依赖关系，确认排期合理。
环节 5：编码准备 + 编码
开始写代码。这里有个容易被跳过、但很关键的前置动作。
用哪些 skill（注意顺序）。
- 先
component-finder：分析需求，在当前项目里搜已有的公共类、工具类、相似业务组件，防止重复造轮子。写任何工具类/公共组件之前都该先跑一遍。 - 再
java-fast-coding：根据需求描述或设计文档，自动分析项目结构、适配已有代码风格，生成各层 Java 代码。
替代了什么。 component-finder 替代了"凭印象判断有没有现成轮子"——人很容易忘记或不知道项目里已有某个工具类。java-fast-coding 替代了大量样板和模板化的编码劳动。
你要盯住什么。 顺序别反：先找复用再编码，否则容易写出和已有实现重复甚至冲突的代码。生成的代码要审——尤其是边界条件、异常处理、与现有代码的契合。AI 生成的代码"看起来对"是常态，看起来对不等于真的对。
环节 6：提交前验证
代码写完，提交之前，做需求符合性验证——确认 AI（和你）真的做了需求要求的事。
用哪个 skill。 ai-code-verify：面向 AI 辅助编程的提交前验证。七步工作流（获取变更→分析→提取要求→七维比对→分级→报告→提交辅助），七维度比对覆盖功能完整性、逻辑正确性、遗漏检查、约束遵守、安全风险、影响范围、性能影响，问题分四级（Critical 阻塞 / Major 建议修 / Minor 后续 / Info 提示），并含资损防控审查和过度设计检查。
替代了什么。 替代了人工逐条比对"需求要的，代码是不是都做了、有没有做多、有没有引入风险"。
你要盯住什么。 Critical 和 Major 级别的问题必须处理掉再提交。这个 skill 是 AI 编码流程里的"安全带"——AI 生成的代码尤其容易出现"遗漏"和"过度设计"，这一关专治这两类。
环节 7：安全推送
最后一步，把变更推到远程，但要安全地推。
用哪个 skill。 git-confirm-push：安全的 Git 暂存、提交、推送工作流。执行任何 git 操作前，先展示完整变更预览（diff stat、commit 列表），等你明确确认后才提交和推送，绝不默默操作。
替代了什么。 替代了手敲 git 命令，同时保留了人的最终确认权。
你要盯住什么。 这个 skill 的设计本身就体现了原则——越是有副作用的操作（推送到远程），越要把确认权留给人。看清 diff 再确认，别习惯性放行。
进阶：让 AI 主动做需求分治
上面的主流程里，阶段 1"判断涉及哪些系统 + 拆到单应用"是纯人工的，也是最耗资深经验的瓶颈。一个新人就算把后面的 skill 用得再熟，卡在这一步也动不了——因为他还没有那张系统依赖的全局地图。
我们正在演进的一步，是把这个瓶颈也交给 AI：用一个"需求分治"智能体（requirement-decomposition-trd），让 AI 主动来做架构级的思考和拆分。
它做什么。 输入一段原始需求描述（不需要你先拆系统），AI 基于团队维护的仓库路由表和架构分层图，自动完成：判断涉及哪些系统、沿依赖关系发现被波及的旁路系统、把需求分解到各系统、再逐个系统检索仓库 wiki 并生成一份 TRD。等于把主流程的阶段 1 + 阶段 2 一起接管了。
 仓库清单（路由表） |  需求分治 skill 部分 |
|---|
 repo wiki |  知识图谱 wiki |
|---|
它的意义。 这是协作层级的一次跃迁：AI 从"在人划定的单应用边界内干活"，上升到"参与架构级的思考和需求拆分"。人的角色变化。 从"审阅者"进一步变成"流程设计者 + 裁判"。这一阶段对人的要求又抬高了一截：你得能把一个复杂任务的隐性知识（依赖关系、约束、判断标准）显式化、结构化地表达出来。这其实是一种"教"的能力——把你脑子里只可意会的经验，翻译成 AI 能执行的规则。会写代码的人很多，能把自己的判断逻辑讲清楚、教明白的人，少得多。
用的时候盯住什么。
- 分治结果：AI 会把中低置信的系统归属列出来让你确认。这是最该认真看的卡点——错一个归属，后面整条链白做。
- 方案抉择：遇到多个合理设计路径（新增接口还是改老接口、走 MQ 还是 RPC），它会列出选项、影响和推荐项，由你拍板。
- 信息缺口：wiki 里查不到、需要推测新增逻辑的地方，它会标出来问你。
前提条件。 这个 skill 的"燃料"是团队的仓库路由表和架构图——路由表越准、依赖关系越全，分治越靠谱。所以用它之前，先确认这两份基础资料维护到位。
怎么接回主流程。 它产出的逐系统 TRD，可以直接进入主流程的阶段 3（设计评审）继续往下走。换句话说，它替换掉的是主流程的阶段 1～2，后面的评审、拆任务、编码、验证、推送完全复用。
边界与风险。 协作者阶段的风险最隐蔽，因为 AI 的自主性让错误可以"无声地"累积。它可能基于一个错误的早期判断，自洽地推导出一整套看似合理实则错误的方案，而过程中没有任何一步看起来"出错了"。所以这一阶段的人，必须同时是个"怀疑论者"——不被流畅自洽的产出说服，盯着那些没有依据、靠推测填充的地方。
演进建议：在这条路完全成熟、路由表和架构图沉淀扎实之前，重要需求仍建议人工复核分治结果。把它当成"资深经验的放大器"，而不是"无人值守的黑盒"。
五、阶段四：共生体——展望，从"用 AI"到"和 AI 一起进化"
第四阶段还在地平线附近，但轮廓已经能看见。当 AI 能够记住团队的历史决策、沉淀可复用的判断规则、在多个工作流之间协同，它就从"被使用的工具"变成了"共同进化的伙伴"。
这一阶段的特征是记忆与沉淀。还是用前面那个需求分治的例子：我们当时讨论过一个设计点——AI 做出的判断和我做出的裁定，要不要留痕、要不要复用？最后定的策略很说明问题：事实型的结论可以跨需求沉淀复用（比如"某系统的某字段来源是 X"，这是客观事实，不会因需求而变），但方案型的抉择不能自动复用（比如"这次选了双写方案"，换个需求背景最优解可能完全不同，盲目复用反而埋雷）。
这个区分指向了共生体阶段的核心命题：哪些判断可以固化成 AI 的长期记忆，哪些必须每次都交回给人？ 能安全沉淀的，是客观、稳定、可验证的知识；必须保留人类裁量的，是依赖具体情境的权衡。一个健康的共生体，会持续地把前者积累成越来越厚的"组织记忆"，同时严格地把后者保留为人的责任。AI 的能力边界在扩张，但责任的边界始终由人把守。
在这个阶段，"替代"几乎不再是一个有意义的词——因为人和 AI 已经深度交织成一个协作系统，问"谁替代谁"就像问"左手替代右手"一样奇怪。真正的问题变成了：这个协作系统整体的产出质量、迭代速度、和犯错时的可追溯性，是不是比纯人或纯 AI 都更好？ 这才是共生的终极衡量标准。
六、把四个阶段串起来：一条清晰的迁移线
回头看这四个阶段，会发现一条非常清晰的规律。AI 替代的能力层在持续上移：片段 → 局部实现 → 流程编排 → 跨流程协同。与之同步，人机协作的界面也在上移：逐 token → 逐任务 → 流程设计与裁定 → 记忆沉淀与责任划分。而人的角色，则沿着"实现者 → 描述者/审阅者 → 流程设计者/裁判 → 规则沉淀者"一路向上迁移。
这条线不只发生在编码环节，它正在向研发的更上游蔓延。最近看 One 平台的分享就是个很好的佐证：在需求推演环节，他们把 AI 流程化——输入一个业务需求，AI 先帮你拆解出产品域和架构方案，确认之后再分配给各子域成员细化，最终产出完整的产品方案和系统架构设计。这和我们在编码侧做的"需求分治"是同一件事的不同切面：AI 正从下游的实现，反向渗透到上游的架构与需求设计。
所以，"替代还是共生"，从当前看来是：AI 持续替代着可形式化的劳动，人持续上浮到不可形式化的判断——这个同步发生的过程，本身就是共生。 替代是手段，上浮是结果，共生是这个过程的名字。
但越是身处这种快速演进，越要想清楚一个问题：什么是会变的，什么是不变的？ 平台会切换，模型会升级，skill 会迭代——这些都是会变的。不变的，是下面五条判断。它们不依赖任何具体工具，是你在流程之外、换任何平台都能自己用好 AI 的底层能力。学会它们，你才不会被某个工具绑架，也不会在工具更替时手足无措。
贯穿全程的五条原则
- 用"验证成本"决定分工。 任何环节，先问自己一句：交给 AI 后，我验证它产出的成本，比我自己做更低吗？只要验证成本低于自己做，协作就划算；反之就是亏本。这把尺子帮你判断该交出什么、该自己留什么。最常见的误区，是把验证成本极高的任务——比如一个边界极其模糊、错了代价极大的核心设计——硬塞给 AI，结果省下的执行时间，全赔在反复验证和返工上。记住：不要为了 AI 而 AI。
- 给 AI 划红线，不只给目标。 AI 倾向于不惜代价完成任务，包括用你不想要的方式（查不到资料就去猜、就去读不该读的东西）。所以"明确告诉它什么绝对不能做"和"告诉它做什么"同等重要。这就是我们常说的 Harness Engineering——与其期待模型自己变乖，不如为它搭好约束的"挽具"：把边界、红线、可用的工具和不可逾越的禁区，显式地嵌入进它的工作环境里。好的协作，约束和目标各占一半。
- 按置信度和"成稿阻断"分流确认。 不要让 AI 什么都问你（你会淹没在低价值确认里），也不要让它什么都自己定（它会带着错误假设一路跑下去）。规则是：能确证的自动做，查不到、要推测的标出来，有多个合理方案的让你拍板；其中会阻塞后续工作的当场问，不阻塞的攒起来批量问。这条原则背后是一个更深的判断——AI 擅长的，永远是那些能被规则、模式、检索覆盖的部分；而判断、取舍、对模糊情境的裁量、对成本的权衡、对责任的承担，这些无法被形式化的能力，才是人始终的立足点。 演进的每一步，都是把可形式化的部分交出去，逼着人把不可形式化的能力练得更深。
- 做 AI 产出的怀疑论者。 AI 最危险的不是明显报错，而是流畅、自信、自洽地给你一个错的东西。盯住那些没有依据、靠推测填充的地方，盯住边界条件，盯住它"想当然"的部分。流畅不等于正确，自洽不等于无误。
- 把判断沉淀成知识，让协作产生复利。 前四条都在管"这一次怎么做对"，但 AI 协作真正的杠杆，在于这一次的成果能不能喂养下一次。每一次需求分治画出的依赖、每一次评审踩过的坑、每一次方案抉择背后的理由，如果只留在某个人的脑子或某条聊天记录里，就白积累了。要把它们沉淀进可复用的载体——工程知识库（README/ARCHITECTURE/调用链）、仓库路由表、团队 skill、决策记录——让 AI 下次直接站在这些经验上工作。我们 team 空间里那十几个 skill，本质就是这种沉淀：把少数资深同学脑子里的判断，变成人人可调用的能力。
结语：被顶高的人，但地基在缩
回到开头那个被问烂的问题。AI 会不会取代程序员？我目前的答案分两层。
短期看，是共生，不是替代。 它持续接管"程序员工作中可被形式化的那部分"，把人推向价值更高的位置——前提是你愿意往上走。
不使用 AI 的人，将被通过 AI 自动化提高生产力的人取代。 ——英伟达 CEO 黄仁勋
黄仁勋这句话常被当成安慰：你看，被淘汰的是"不用 AI 的人"，只要我用上，就安全了。但它其实只说了上半句。下半句是冷的：当每个人的人效都被 AI 抬高，而业务的增长跟不上这个抬高的速度，同样的产出就只需要更少的人。那如果效率提升是确定的，增长放缓是大概率的，两者一夹，结果就是——终究会替代很大一批人。
而且要诚实地说：哪怕你是那个"和 AI 一起把边界往外推"的人，也未必能幸免。 往上走能显著提高你在缩减中留下的概率，但它改变的是你的相对位置，改变不了"总的座位在变少"这个宏观事实。把"我很强"当成免死金牌，是这个时代最危险的自我安慰。
那看清了这一层，还要不要往上走？要——而且更要。不是因为它保证安全，而是因为在一个座位持续减少的局里，往上走是你唯一能主动握住的变量。你没法决定这条下沉线推进得多快、最终停在哪里，但你能决定自己始终待在它的前沿：哪类判断刚被接管，就往上再挪一步。
AI 时代的职场将只剩两类人 —— 深耕领域的顶尖专家、主动善用 AI 的高能动性通才。 ——斯坦福HAI联合主任 李飞飞
地板确实在被一层层抽走，你也确实在被顶高——但要清醒：被顶高的同时，脚下的地基也有可能在变窄。焦虑的人只盯着脚下流失的那层，清醒的人既往上看、也往下看：往上看，是还能去够的更高价值；往下看，是这条线逼近的速度。
所以针对共生和替代，这篇文章的结论，不是一句"别担心，你会没事的"。而是：替代是真实的，共生是此刻的，而往上走，是在这场不确定里，我们唯一能掌控的事。 看清这条线，跑在它前面——不为安全感，只为不被它推着走。
