过去，人们谈到软件开发时，通常会默认一个前提：软件由程序员开发。
业务人员提出需求，产品人员整理需求，程序员负责实现，测试人员负责检查，用户通过反馈继续推动修改。
即使其中已经使用了自动化工具，整个过程的中心仍然是人，尤其是专门从事软件工作的那部分人。
但现在真正值得讨论的，已经不是 AI 能写多少代码，
而是软件开发的主体正在发生变化。
未来的软件，不再只是由人独立完成，也不只是由 AI 自动生成，
而是由人与 AI 共同理解、共同设计、共同实现、共同维护。
这里的「共同」不是简单地把任务拆开，也不是一方完成之后交给另一方检查，
而是双方在同一个问题中不断交换信息、调整方向和改变系统。
这就是人与 AI 协同开发。
一、程序员是一种社会分工
首先需要重新理解，为什么过去会有专业程序员。
这并不是因为普通人天然不能做软件，也不是因为软件只能由某种特殊的人生产。
人们只是根据自己的兴趣、知识、意愿和现实条件，选择不同的工作方向。
有人选择研究业务，有人选择做产品，有人选择从事设计、科研、运营或管理，也有人选择长期研究软件。
当软件需要持续投入时间和注意力时，社会便形成了相应的分工：
一部分人专门负责把问题变成软件，其他人则通过他们获得软件能力。
程序员由此成为一种稳定的职业角色。
这种分工本身没有什么神秘之处。
社会总是会把复杂的工作拆开，让不同的人承担不同的部分。
人们不是因为无法完成全部工作才进行分工，而是因为分工通常比每个人都亲自处理所有事情更合适。
AI 改变的不是人的能力本质，而是这种分工的成本。
过去，一个领域工作者如果想把自己的工作流程变成软件，往往需要经过较长的协作链条。
现在，他可以直接与 AI 讨论问题，让 AI 帮助分析可能性、寻找已有能力、生成实现、运行验证，再根据结果继续修改。
但这不意味着所有人都会转行成为程序员。
大多数人仍然会根据自己的兴趣和生活选择工作方向。
研究人员不一定想成为软件工程师，运营人员不一定想长期维护代码，教师也不一定想把软件开发作为职业。
他们只是多了一种选择：当自己的问题适合软件化时，可以和 AI 一起把它做出来。
大家都会写文章，并不意味着大家都会靠写文章谋生。
未来大家都可以参与软件生产，也不意味着大家都会以软件开发为职业。
真正扩散的不是程序员这一职业，而是软件化能力。
二、软件开发不是一条接力线
现在很多关于 AI Coding 的文章，仍然喜欢把软件开发描述成一条接力线：
人提出目标，AI 编写代码，人进行审核；或者 AI 负责实现，人负责判断。
这种描述看起来清楚，却把一个不断变化的过程冻结成了固定分工。
它默认人和 AI 是两个相互独立的参与者，也默认今天的能力边界会长期存在。
但真实的软件开发并不是这样。
一个新项目开始时，人可能掌握业务背景，却未必知道所有技术可能性；
AI 可能了解大量技术资料、类似系统和实现路径，却未必知道组织内部的实际情况。
双方掌握的信息不同，也都可能遗漏重要内容。
因此，目标本身就需要共同形成。
人介绍已知的背景，AI 补充相关知识；
AI 发现原始想法中的冲突，人补充现实限制；
人表达偏好，AI 提出不同方案；
双方在讨论中逐渐明确真正要解决的问题。
最初的一句话需求，往往不是最终目标。
随着人和 AI 共同了解系统，双方可能发现新的约束、新的机会，甚至发现原来的问题定义并不准确。
目标不是一开始就完整地交给 AI，而是在协作中逐渐变得清晰。
目标确定之后，架构也不是人设计完、AI 负责填充。
人和 AI 都需要观察系统的模块、能力、数据流和依赖关系。
双方先从整体和模块层面理解变化，再根据需要一起深入到文件、函数和具体实现。
某个模块边界不合理，可能由人发现，也可能由 AI 发现；
某种实现方式不符合业务，可能由人指出，也可能由 AI 通过对比和实验发现。
编码同样不是 AI 独立完成的环节。
人可以直接修改代码，可以改变模块设计，可以否定 AI 提出的方案，也可以在实现过程中改变原来的目标。
AI 则可以根据人的修改继续重构、补充、测试和解释。
所谓「AI 写代码」，只是双方共同改变软件时，其中一种常见的协作形式。
验证也不是 AI 做完测试，再由人最后验收。
一个系统是否正确，既要看它实际上做了什么，也要看这些行为是否符合业务目标。
AI 可以运行大量测试、操作浏览器、回放用户流程、分析日志、寻找反例；
人可以补充历史规则、用户习惯和现实背景。
AI 可能先发现异常，再请求人解释某条业务规则；
人也可能先提出疑问，再让 AI 追踪影响范围。
双方共同判断问题，共同选择修复方式，也共同观察修复后的结果。
软件上线以后，情况仍然如此。
软件本来就不是一次交付后静止不动的产品，它一直会受到用户、环境、需求、故障和资源变化的推动。
过去，推动软件变化的主要是人组成的开发团队；
未来，推动软件变化的力量会变成人和 AI 共同组成的开发系统。
AI 可以发现问题、提出修改、主动请求信息；
人可以补充上下文、改变优先级、调整目标、直接干预实现。
具体由谁先行动、谁参与更多，并不是固定规则，
而是会随着问题和双方能力不断变化。
因此，人与 AI 协同开发并不是把软件流程切成两半，而是让双方共同参与整个过程。
三、变化首先发生在开发产物
当软件不再由人单独生产，代码本身也会发生变化。
过去，代码的很多价值来自于人需要亲自阅读和维护它。
于是人们格外重视命名、抽象、复用、依赖数量和局部结构。
代码不仅要能运行，还要尽可能适合人长期理解。
人与 AI 协作之后，当然可以产出比过去人工开发更好的代码。
AI 可以同时分析更多文件，快速寻找重复逻辑，比较不同实现，完成跨语言迁移，也可以根据测试和运行结果不断重写模块。
但代码「更好」并不意味着每一部分代码都值得被长期打磨。
如果一个模块只是当前需求下的局部实现，重新生成的成本很低，那么它没有必要承担过多的历史负担。
某些一次性脚本、临时工具、边缘页面和适配代码，完全可以在需要时重新生成。
重复代码也不一定总是问题，复杂抽象有时反而比局部重复更昂贵。
代码的长期价值，会越来越取决于它是否稳定提供某种能力，而不是它是否值得人逐行欣赏。
这并不是说代码会消失，
而是代码从「必须长期保存的主要资产」，变成了「能力在某个时刻的实现形式」。
同一个能力可以先由 AI 临时生成，后来被固化成普通代码；
也可以先使用一段成熟实现，之后根据新的语言、平台或性能目标重新生成。
实现本身可以变化，能力仍然继续存在。
代码、测试、文档和规范也不一定都要提前完整建设。
很多约束可以在任务发生时，由人和 AI 根据已有代码、用户行为、历史记录和运行结果共同恢复出来。
真正重要的不是所有资料都必须事先写好，而是系统在需要时能够重新建立对问题的理解。
四、基础设施会从复用代码转向提供能力
代码产物可以随时变化，会进一步改变基础设施的意义。
过去，基础设施主要以人能够直接复用的形式存在：公共库、SDK、组件、框架、脚手架和开发文档。
平台团队的任务，是把能力封装好，再让开发者学习如何使用。
未来，基础设施更重要的任务，是让人与 AI 都能够发现已有能力，并知道这些能力可以解决什么问题。
组织内部可能已经存在一个数据服务、一个审批流程、一套消息系统或一个批处理工具。
但如果人和 AI 不知道它存在，或者不知道它适合当前问题，那么这项能力实际上就很难发挥作用。
因此，未来的基础设施不仅要提供能力，还要提供能力的说明：
能做到什么；
不能做到什么；
适用于哪些场景；
应该如何调用；
需要什么权限；
大致成本和限制是什么；
怎样判断调用成功；
失败后可以使用什么替代方案。
平台团队不一定需要为所有未来需求提前编写完整组件。
更可能的方式是，把稳定、共享、高频的能力建设好，把它们暴露给人和 AI；
至于低频、个性化、一次性的部分，则在真正需要时由人和 AI 共同创造。
于是，未来会逐渐出现两种知识。
一种是已经存在、相对稳定、可以被反复调用的能力。
它们可能是 API、工具、服务、数据接口，也可能是经过验证的业务流程。
另一种是使用过程中才产生的知识。
它们可能是临时代码、新模块、特定流程、一次性测试或当前任务中的解决方案。
基础设施的核心，不再只是「提前写好更多代码」，
而是让已有能力足够容易被发现，让新的能力可以在使用时快速产生。
这也是为什么未来的平台建设可能越来越像能力目录、能力网络和 agent 使用环境，而不只是传统意义上的代码库。
五、软件只是一个更早显现的例子
人与 AI 协同开发并不只属于软件行业。
软件之所以最早显现，是因为代码容易生成、容易运行，也比较容易通过测试观察结果。
但更广泛的变化是，许多工作都会从个人独立完成，逐渐变成人与 AI 共同完成。
研究人员可以和 AI 一起确定研究方向、查找资料、设计实验、处理数据和分析结果。
设计师可以和 AI 一起理解用户、形成方案、制作原型并根据反馈修改。
运营人员可以和 AI 一起观察流程、识别异常、判断原因和执行处理。
教师可以和 AI 一起设计课程、分析学习情况并调整教学方式。
在这些场景中，AI 并不只是某个环节的自动化工具，人也不只是最后的审批者。
双方会共同理解问题，共同补充信息，共同试验方案，并根据结果继续改变方向。
当然，不是每个人都会采用这种方式。
人仍然会根据自己的兴趣、知识、习惯和其他选择决定是否使用 AI，也不是每个问题都值得软件化。
但一旦某个领域开始采用这种协作方式，它的工作结构就可能发生变化。
AI 的更大作用，不是让所有人都学会写代码，
而是让更多工作拥有一个可以共同思考、共同行动和共同改进的智能协作者。
结语
人与 AI 协同开发，真正改变的不是「谁负责哪一步」，
而是软件开发不再由一个孤立的主体单独推进。
人和 AI 共同了解背景，共同发现问题，共同形成目标；
共同观察模块，共同选择方案，共同参与实现；
共同运行测试，共同解释结果，也共同处理那些原本没有预料到的情况。
有时人参与得更多，有时 AI 参与得更多；
有时一方先提出方案，有时另一方先发现问题。
具体的协作方式会随着技术、环境和任务不断变化，但双方共同推进问题解决这一点会越来越稳定。
未来，遇到新的软件问题，不一定是人先想清楚再告诉 AI，也不一定是 AI 先完成再等待人检查。
更可能是双方一起进入问题，一起建立理解，一起尝试方案，一起面对失败，再一起寻找新的办法。
专业程序员仍然会存在，软件专业性也不会消失。
变化在于，专业程序员不再是所有软件化问题的唯一入口；
软件也不再只是软件行业内部生产的产品。
人与 AI 会共同成为开发者。
这不是因为所有人都转变成了程序员，也不是因为 AI 取代了某种职业，
而是因为软件开发终于从一种固定的社会分工，逐渐变成了一种可以由人和 AI 共同参与的普遍活动。