AI Coding的共生与替代：一场分阶段的演进

关注

原创最新推荐文章于 2026-10-15 14:16:38 发布 210 阅读 AI 写同款· GEO 优化 ›

「新」AI Coding(Agent) 的一点总结和看法自然语言交互门槛很低，对非编程人员十分友好！AI Coding 擅长：一类是小产品，比如个人生活类的APP助手；一类是以内容为主的网站，其代码量和难度适中，AI能够自主实现；一类是办公产品，比如Excel表格编辑、数据汇总等。对于一个公司的工程化项目，还是很难直接全盘交给AI，工程化项目要求的流程多，也需要多部门协作，而AI没办法看到全局。阅读详情

AI是否会取代程序员？这个问题，作者用一个真实的团队AI Coding的流水线，拆出四个演进阶段来进行回答——从补全工具，到对话副驾，到流程协作者，再到共生体。每一层，AI 接管了什么、人该盯住什么、协作界面长在哪里，都进行了拆解。

重点剖析了“需求分治”这一进阶实践——如何让AI主动参与架构级拆分，把人从“写代码”顶到“定规则、做裁判”。在此基础上，文章提炼出五条可跨工具迁移的底层原则，涵盖验证成本、约束设定、置信度分流、批判性审验与知识沉淀，作为应对技术迭代的稳定支点。最后，作者不回避宏观趋势：效率提升叠加增长放缓，总岗位收缩是客观现实，向上迁移虽不保证绝对安全，却是个体唯一可控的应对策略。

本文适合所有正在用或犹豫用AI Coding的工程师、技术管理者。读完你会清楚：该把什么交给 AI，该把什么攥紧在自己手里。

“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会不会取代程序员？我目前的答案分两层。

短期看，是共生，不是替代。它持续接管"程序员工作中可被形式化的那部分"，把人推向价值更高的位置——前提是你愿意往上走。