把软件开发比作制造业并不完全贴切，但底层逻辑相通。机器改变的不只是单件产品的速度，还重塑了标准、流程和成本。软件业如今也走到了相似的变革节点。
过去几十年，编程语言、开发框架和云计算持续迭代，但软件开发依旧高度依赖人工，从需求拆解到处理故障，生产方式带有浓厚的手工作业色彩。
生成式人工智能改变了这个模式。它可以生成代码、补充测试、解释旧系统，也可以在工具授权下连续执行任务。当前行业已进入AI编程Agent（智能体）规模化落地阶段，超九成企业已引入AI编码工具，头部大厂近半数新增代码由AI辅助产出；工具能力也从简单代码补全迭代至自主拆解任务、多智能体协同开发。
现有实践还不足以证明软件开发一定会全面转向无人化生产，但值得追问的是：如果AI承担越来越多的开发工作，企业的软件生产、管理、安全和基础设施该做哪些准备？
批量生成无约束，滋生技术债务隐患
评价编程代理时，人们容易关注节省了多少时间，然而更深的变化其实在代码输入环节。
早期的编程代理主要帮助补函数、查错误，代码仍由人逐行修改。如今，许多开发者连文案或条件判断都不再直接改源码，而是说明改什么、哪些不能动，再由编程代理完成。问题不在于是否手工修改，而在于改动若没有写进测试和规则，下一次生成仍可能按旧信息把它覆盖。提示、约束和已有代码，正在共同决定软件下一步会生成什么。
过去，一个小需求常因成本过高而被搁置。代码生成成本下降后，面向一个部门或短期任务的软件也可能值得开发，软件的经济模型可能随之改变。问题也随之而来：生成便宜并不等于维护便宜。大量个性化软件如果缺少统一架构和退出机制，会变成新的技术债务。
这种风险在看似简单的改动中就会出现。以内部报销系统为例，某字段要改为“满足条件才必填”。编程代理很快改好页面和接口；随后整理其他模块时，它又可能按最初读到的旧规则重写这部分校验。原因是例外条件只留在前一轮对话里，没有进入测试或接口说明。对人而言，这是刚讨论过的事；对编程代理而言，它已不在眼前。
这类回退不能简单归咎于编程代理不够聪明。它每次能读到的代码和对话有限，长任务还会压缩上下文；缺少明确的规则和记录，它只能依据局部信息推断。模型的上下文不是工程师的长期记忆，会随任务切换而改变。一项修改若说不清依据，就很难在后续生成中稳定地保留。过去由资深工程师记在脑中的背景，AI参与后必须变成团队可调用的资料。
因此，新的生产方式不是把需求写成一句提示词，而是建立能被编程代理反复读取又能由人维护的约束体系，这些约束常常存储在编程代理的AGENTS.md或SKILL.md等文件里。近几年出现的LMQL、DSPy、SGLang等研究，已经尝试把模型调用、提示、约束和工作流程写成结构化程序。这些约束对程序质量至关重要，编程代理执行前应说明读到了哪些规则、准备改动什么。
编码效率提速，工程验证体系遇瓶颈
代码生成提速后，代码行数和开发工时已经很难用客观指标衡量产出。效率应从需求提出算到上线和运行，企业真正要衡量的是交付周期、返工与生产缺陷，而不是键盘敲得更少。几分钟生成一段代码，可能只是把时间推迟到后续验证和故障处理；瓶颈会从编写转向确认需求、验证与控制发布。
判断编程代理生成的程序是否正确，不能只看编译或一组测试是否通过。至少要核验四件事：需求和例外情形是否理解正确、功能和接口是否符合约定、改动是否越过边界、以及运行环境是否具备上线和回滚条件。
编程代理可以写测试，但同一编程代理若同时写代码和测试，可能把同一种误解一并写进去，形成“自测通过”的假象。换句话说，AI既当“开发”又当“测试”，会带着相同的认知偏差，造出一套自欺欺人的校验体系，测试通过只是假象，底层缺陷完全不会被暴露。
主流编程代理较成熟的流程是：先让编程代理说明任务边界和验证计划，再在隔离环境改动代码，按项目规定运行检查，最后提交改动及验证说明。人在审查中还要确认，编程代理没有用更大的改动换来表面上的通过。
测试的重点也要调整。新增规则应先写出“修复前失败、修复后通过”的用例；接口调整要核验契约，数据和权限变更还要看兼容性与越权情形。对关键业务，还要在接近生产的环境中使用脱敏数据进行测试，让不了解原始对话的审查者或独立编程代理寻找反例。
这一环节最容易被生成速度掩盖，却最考验既有的工程基础。最终放行仍由业务和技术负责人决定。2025年一项AIDev研究发现，编程代理的提交更快，但被接受的比例却低于人工提交。这说明代码供给增加后，审查、测试和环境容量往往先成为瓶颈。
AI自主操作扩权，安全权责漏洞凸显
不能指望AI编程天然更安全。它能套用成熟的鉴权和校验，也会把一条错误规则同时带入页面、接口和测试，并在多个任务中复制。风险的关键不只是模型会不会写错，更是错误可以被多快地复制。代码供给增加，使传统缺陷更容易成批进入系统。若治理方式不变，企业的总体暴露面通常会扩大。
新的风险还产生在让编程代理替人行动的过程。编程代理会读取代码和运维资料，其中的恶意或过时文字可能被误作指令，形成间接提示注入；一旦它拥有外部操作权限，就可能越权、泄露密钥，甚至把测试操作带入生产。
这些风险会把原本的代码质量问题，转化为生产环境的操作风险。传统编译器不会把一段README当作命令，也不会自行调用外部资源；然而当任务目标和范围不清时，编程代理会更容易越过操作边界，这正是编程代理带来的新增攻击面。
安全控制不应只在生成之后扫描，而要限制编程代理能读什么、能调什么和能在哪个环境行动。权限应由系统策略执行，不能交给模型自行判断。低风险辅助任务只给只读访问；编写和测试在隔离工作区进行；涉及敏感数据或发布，必须单独批准。安全检查应成为流程关口，而非上线前临时补课。
责任链也要延长。企业除记录最终代码由谁提交，还应留存任务依据、编程代理行为和验证结果，并能还原所用编程代理的配置。出现异常时，应能迅速停止编程代理、冻结发布并回滚。涉及资金、个人信息或生产控制的系统，最终放行权和事故责任仍须由明确的负责人承担。
只投入算力资源，企业整体能力脱节
编程代理进入开发流程后，企业基础设施的边界需要重画。过去，研发平台服务代码管理和交付；现在还要为编程代理提供受控的上下文和执行环境，并留下可追溯的记录。基础设施不再只承接代码的编译与运行，也要管理机器如何理解任务、能够做什么、做过什么。
许多企业通过多编程代理进行开发，实质上是把研发活动的并发度一下子拉高了。一项原本由一名开发者完成的改版，可能变成多个编程代理在数小时内并行发起变更；若验证链能力不变，生成得越快，积压就越早出现。
基础设施规划应从“供给多少算力”扩展为“能同时安全处理多少任务”，并把验证资源与审批时效纳入成本核算。云端和私有化模型还需通过统一接入层管理，避免业务系统被单一供应商绑定。
更值得重视的是知识基础设施。编程代理不会自然理解企业的业务口径和历史决策；若“客户状态”或“工作日”的定义散落在旧记录和个人聊天中，它很可能写出看似合理、实则违背现行规则的代码。企业应把需求规则、数据字典和复盘记录作为可引用的生产资料。
这要求知识管理从个人沉淀转为持续维护的流程，而非一次性整理项目文档。一份过时资料比没有资料更危险，因为编程代理会把它当成仍然有效的规则。
这也改变了开发平台的控制方式。成熟的云端编程代理通常在临时隔离环境中工作，GitHub为其编程代理配置临时、受防火墙保护的环境，并限制默认分支和关键工作流，就是一个代表性做法。企业可据此形成受控执行面：编程代理按任务领取短期凭据，只能调用允许的系统；每次运行保留所依据的规则、调用行为和验证结果。出现故障时，应能追溯代码的审查过程，并判断是知识、权限还是验证失效。这不是为了留下更多日志，而是让纠错能够落到具体环节。
总体看，编程代理会把企业研发平台推向人机协作的软件生产系统。短期内，企业未必急着自建大模型或购买更多GPU（AI训练的核心计算芯片），更要补齐可复用的知识、隔离的执行环境和弹性的验证能力。长期看，模型会更换，编程代理也会迭代，真正应沉淀在企业手中的是业务规则、工程资产和控制能力。
AI编程的价值，最终要由真实项目回答
与其等待技术成熟或马上重建体系，不如先弄清编程代理已经在哪里被使用。开发人员可能早已通过公共模型和编程代理处理代码或数据，管理制度却没有跟上。这种“影子使用”往往正是治理的起点。企业应盘点正在使用的编程代理及其场景，明确哪些信息不能进入外部模型，哪些操作必须在受控环境完成。
试点不妨从边界清楚、结果容易核验的工作开始，例如测试生成或常规缺陷修复。先约定成功标准，再记录原有周期和质量；评估时不能只看生成速度，只有在交付价值而非一时新鲜感上得分，试点才值得扩大。
当试点由个人辅助转向团队使用，企业首先要看是否具备扩容条件。旧系统缺少文档和测试的，应先补清依赖关系，建立接口约束和回滚机制，再允许编程代理大范围修改。否则，试点的成功很容易停留在少数熟悉系统的人身上。
在此基础上，授权可以按任务风险逐步提高：先让编程代理用于解释、文档和测试，再在隔离环境承担边界明确的开发；自动测试、运行监测和责任制度形成闭环后，才考虑让它持续参与核心系统维护。核心系统的授权速度应慢于验证能力，企业不必追求同一进度。
今天人们还不能确定编程代理最终会形成什么技术体系，也无法断言岗位和组织何时改变。不过，清楚的业务规则、可维护的架构、可靠的测试和受控的权限，在任何技术路线下都有价值。
企业近期不妨问清五件事：哪些软件适合由编程代理开发，它依据什么企业知识工作，谁来验证结果，出了问题怎样停止和回退，成本是否真的降低。只有在真实项目中持续回答这些问题，编程代理才会成为稳定的软件生产能力。
（作者为中信集团科技与数字化部副总经理 编辑：谢丽容）
216.73.217.130
