工程师的新契约

把时钟拨回更早的那一年。在旧金山市场街南区的GitHub总部，年度《Octoverse报告》的内部审查会进行到第七会议室时，一张幻灯片让房间安静了三十秒。上面只有一条曲线：从2024年1月到2025年9月，新创建仓库中包含智能体配置文件的比例，从不到12%攀升至53.7%。在员工超过五百人的科技公司仓库中，这个数字是68.2%；在初创企业中是61.5%。报告用了一句克制的话总结："配置文件已成为项目脚手架中不可或缺的一环。"

在七个时区之外的班加罗尔，三十一岁的全栈工程师普莉扬卡在同一周打开了她的第一个自由职业订单——为一家新加坡电商公司重构支付模块，报价三千二百美元。她在新建仓库时做的第一件事，不是编写功能需求文档，而是创建了一个.cursorrules文件，写入了六行规则：指定使用Cursor的Claude后端；所有数据库操作必须显式声明事务边界；禁止自动生成任何涉及信用卡号处理的正则表达式；代码审查重点标记金额计算、时区转换和第三方API异常处理。然后她才开始写第一行功能描述。

她不是先锋，也不是早期采用者。在2025年秋天，这已经是标准操作流程。一张幻灯片和一份配置文件，把同一个问题推到了每一个软件工程师面前：当你在写入代码之前必须先写入约束AI的规则，你与代码的关系已经发生了某种不可逆的变化。

2025年春天，Stack Overflow发布了被收购后的第三次开发者调查。在那份问卷中，新增了一个问题：“在您日常工作中，以下哪项描述最接近您与AI编程工具的关系？”选项包括“AI是我遵从指令的下属”“AI是我协作的同事”“AI是我审查的承包商”“AI是我使用的工具，与编译器无异”。在超过六万份有效回答中，选择“承包商”的占41%，选择“同事”的占29%，选择“工具”的占22%，选择“下属”的不到8%。

这个分布本身并不令人意外。但将它和两年前同一调查中对AI工具使用频率的简单统计对比，就能看出结构性迁移。2023年，工程师们还在争论“AI辅助编程是否算真正的编程”——那是一种关于身份与技术纯洁性的辩论。到了2025年，辩论已经结束。新问题不是“是否使用”，而是“如何管理”。

管理这个词是核心。它意味着工程师不再只是代码的生产者，也是代码生产者的管理者。

LinkedIn的招聘数据从另一个角度佐证了这种迁移。2025年第三季度，在美国科技行业发布的软件工程师职位中，职位描述里出现“AI协作”或“提示工程”关键词的比例，从2023年同期的3.7%上升到了34.2%。传统的“精通某种语言”式的表述没有消失，但权重在下降。

一份来自西雅图某云基础设施公司的招聘启事可以作为典型样本。第一条要求写着：“能够与AI编程助手高效协作，包括编写清晰的分层提示、审查AI生成代码的安全性边界、识别AI输出中的架构不一致性。”第二条才提到“精通Go或Rust”。第三条是“在分布式系统中，能够判断哪些模块适合由AI生成、哪些必须手写”。第四条回到传统技能：“五年以上后端开发经验。”

这四条要求构成了一份新职业契约的碎片。第一条和第三条在五年前根本不存在。它们在2025年出现在招聘启事的最前列，说明雇主正在将AI协作能力视为独立于编码能力之外的核心技能。而第四条——五年经验——则暗示了更深层的结构：市场上仍然需要具有深厚技术判断力的人，但那种判断力的应用场景已经从“如何实现一个功能”转向了“如何判断AI是否正确地实现了这个功能，以及在哪些节点上应该阻止AI去实现”。

这个转型不是均匀发生的。它沿着不同路径抵达不同的人，在每个路径上留下的痕迹截然不同。

马库斯，三十七岁，在旧金山一家中型SaaS公司担任高级工程师已经五年。他的公司是2024年秋天全面接入Claude Code的那一批——不是试验，而是自上而下的命令。CTO在全员邮件中写道：“从第四季度开始，所有新功能开发必须在AI辅助下完成，代码审查的第一优先级是验证AI生成内容的正确性。”

邮件发送的那天晚上，马库斯在厨房岛台前坐了四十分钟，盯着笔记本电脑屏幕，什么都没做。他不是抗拒新技术。他早在2023年就开始用Copilot做代码补全，2024年尝试过Cursor。

但他清楚地意识到，这封邮件与他之前的所有工具升级都不同。之前是他使用工具。现在是公司要求他，在工具划定的框架内工作。

到2025年秋天，他的工作日变成了这样：早晨打开终端，从Jira拉取当天分配给自己的任务。每个任务不再是一张空白画布，而是一个包含自然语言描述的“意图文件”——产品经理在上游已经用AI辅助工具将需求转化为结构化的功能描述，有时甚至包含了推荐的实现路径。他的工作是把这些意图文件进一步细化，拆解成AI能够处理的步骤，然后输入Claude Code。

AI生成代码的速度远超他手写的速度，但审查的时间并不比手写短。他发现自己花在审查上的时间，比以前花在写代码上的时间更长。

原因不是AI生成的代码错误率更高——在标准CRUD和API实现这类任务上，AI的正确率已经接近95%。问题在于，剩下的5%的错误不是均匀分布的。它们集中在边界条件、异常处理、与旧模块的隐式耦合上——这些恰恰是审查中最容易忽略的地方。

以前他写代码时，会在写的过程中就意识到这些风险。现在，他必须在别人的代码中识别它们。

马库斯在2025年夏天开始记录自己的审查发现。三个月内，他标记了四十七次AI生成的代码在分布式事务边界上缺少回滚逻辑，二十三次在处理用户输入时没有充分消毒，还有十一次是AI在重构时误删了某个看似冗余但实际承担着向后兼容任务的字段。这些错误类型他以前也见过，但那时它们来自初级工程师，他会通过代码审查和一对一辅导来纠正。现在，错误的来源是同一个模型，它不会从单个项目的反馈中学习。每次审查都是一次全新的发现过程，而不是一个积累性的改进过程。他在一次技术分享会上说：“我变成了一个质量检查员，而不是一个建造者。这不是贬义，但它确实改变了这份工作给我的感受。”

第二个人是普莉扬卡，在班加罗尔。她的故事代表了这个职业转型的另一端——不是质量检查，而是速度与定价的重新平衡。2024年之前，她在一家印度IT外包公司做全栈开发，月薪约合两千美元。2024年春天，她开始用Cursor接私活，最初只是周末赚一点外快。到了2025年，私活收入超过了全职薪水，她辞了职，成为全职自由开发者。

她的核心竞争力不是编程技术——她自认编程水平在同行中属于中上，但远不是顶尖。她的竞争力在于，她比大多数自由开发者更早掌握了如何让AI配合她完成完整项目。

她建立了一套约定文件模板，针对不同类型的项目——电商、内容管理、数据分析——预置了不同的行为约束规则。她能在一小时内搭建好一个新的项目环境，包括配置文件、CI/CD模板和AI行为约束，然后让AI开始生成代码框架。

她发现，在AI辅助下，她能同时处理的项目数量增加了两倍，单个项目的完成时间缩短了约40%。但她的收入并没有等比增长。

她的项目完成数量增加了一倍，但单个项目的报价在下降。在Upwork和Toptal这样的平台上，越来越多标注“AI-assisted”的开发者进入市场，其中许多人来自生活成本比她更低的地区。他们也能在AI辅助下快速交付项目，质量足够满足大多数客户的需求。

2025年第二季度，她注意到，三年前一个需要三千美元的后端开发项目，现在的市场均价已经降到了两千二百美元左右。她的总收入确实在增长——从月入两千美元涨到了约四千五百美元——但时薪的增长远低于生产力提升的比例。她生产的代码更多了，但每行代码的价值更低了。

她在2025年秋天开始思考一个问题：如果AI让每个人都能生产更多代码，那么代码本身就会变得更便宜，而真正稀缺的将是那些AI不能替代的东西——客户沟通、需求理解、架构判断。她开始有意识地在自己的项目提案中，把“AI协作”从优势描述中移除，转而强调“十年全栈经验”和“复杂系统架构能力”。她写道：“AI帮我写代码，但客户付钱给我，是因为我知道让AI写什么。”

第三个人是陈家明，三十二岁，深圳一家智能硬件创业公司的联合创始人兼CTO。他的公司开发智能家居控制器的嵌入式软件，团队有十二名工程师，其中六人负责固件，六人负责云端后端。2025年初，他面临一个决策：是否让团队全面采用AI编程工具。

他的顾虑不是技术性的。他试过Claude Code和Cursor，知道它们能提高代码生成速度。但固件开发不像Web后端——固件运行在资源受限的硬件上，内存泄漏、中断冲突和实时性破坏的代价不是一个API返回错误，而是一个物理设备在用户家中失效。他说：“在云端，一个bug是500错误。在固件里，一个bug是一个灯泡半夜自己亮了。”

他做出了折中决定。在云端后端团队，他要求全面采用AI辅助，将所有AI行为约束写入.cursorrules和mcp.json，代码审查流程从“检查逻辑”转向“检查AI输出的边界条件”。在固件团队，他只允许AI用于生成单元测试和文档，禁止AI直接生成任何涉及中断处理、内存管理和电源管理的代码。

这个决定在团队内部引发了争议。固件工程师抱怨被剥夺了效率工具，后端工程师则抱怨变成了AI的“保姆”。

陈家明在2025年夏天的一次全员会议上说：“我理解你们的不满。但请理解我的逻辑：AI能做对的领域，我们用它；AI能做错但代价不大的领域，我们审查它；AI能做错且代价不可接受的领域，我们禁止它。这不是技术判断，这是风险管理。”

三个人，三个城市，三种处境。马库斯在旧金山，每天花六小时审查AI的代码，寻找那些隐藏在边界条件中的错误。普莉扬卡在班加罗尔，用AI完成了两倍的项目，但发现自己的时薪增长远远落后于生产力的提升。陈家明在深圳，为不同的技术栈定制了不同的AI使用规则，在效率与风险之间反复权衡。他们互不相识，但他们的处境描绘了同一个趋势：软件工程师的工作定义正在从一个以“生产代码”为中心的模式，转向一个以“管理AI的代码生产”为中心的模式。这三种切片的本质差异，不在于技术能力，而在于每个工程师在缰绳层中的位置——他们是在设计约束、执行约束，还是被约束所定义。

这种位置差异最清晰地体现在代码审查流程的变化上。代码审查是现代软件工程中最古老也最核心的制度之一。它的基本逻辑在二十年里几乎没有变过：一个人写代码，另一个人读代码，检查其中的逻辑错误、风格问题和安全隐患，然后决定是否批准合并。

2025年，这个制度的逻辑被逆转了。当大部分代码由AI生成时，审查者不是在检查一个人类同事的逻辑思维，而是在检查一个概率模型的输出是否在特定上下文中恰好正确。

2025年夏天，谷歌研究院发布了一份内部技术报告，分析了其内部使用AI辅助编程后代码审查数据的变化。报告指出，在AI生成的代码中，审查者标记出的问题类型分布与人类编写代码存在显著差异。人类代码中最常见的审查问题是“逻辑错误”和“风格不一致”，合计占全部标记的63%。AI代码中，最常见的审查问题变成了“上下文误解”和“边界条件缺失”，合计占59%。

这两类问题的本质不同：逻辑错误是一个工程师在思考中犯了错误，审查者可以通过推理来发现；上下文误解则是AI在生成代码时没有理解该系统特有的约束——比如某个API的调用顺序、某个数据库字段的隐式语义、某个遗留模块对输入格式的隐蔽要求——这些约束通常不在代码文件本身中，而是存在于系统的设计文档、团队的口头知识或者某个五年前写过但从未被更新的wiki页面里。

一位在谷歌工作了十年的资深工程师，在2025年秋天的一篇个人博客中描述了这种变化。他写道：“以前我做代码审查，是在找‘这个人哪里想错了’。现在我是在找‘AI哪里没理解’。这是两种完全不同的认知过程。前者基于逻辑——我可以从代码倒推写代码的人的思路，找到逻辑链条中哪一环断了。后者基于系统知识——我必须知道这个系统有哪些隐性约束，然后检查AI是否在每个约束点上做出了正确的判断。问题是，我自己的系统知识也不完整。有些隐性约束我可能都不知道，直到AI触发了它，然后生产环境出了问题。”

这篇博客还提到了一个更微妙的变化：在高频使用AI之后，审查者自己的代码审查能力也在退化。他写道：“当你的大部分代码不是你自己写的，你就失去了通过‘写’来深入理解系统的过程。以前我写一个模块，写的过程中就会发现很多边界条件——那些发现不是通过事后审查获得的，而是通过手指在键盘上敲击时大脑的并行思考获得的。现在这个‘写’的过程被跳过了，我直接从意图跳到审查。表面上看效率更高，但我开始注意到，我审查时能发现的深层问题在减少。不是因为AI写得更好了，而是因为我失去了那种通过亲手构建来获得系统直觉的机会。”

这不是一个孤立的现象。2025年秋天，在Hacker News上，一篇题为“我在AI辅助编程一年后失去了什么”的帖子引发了激烈讨论，获得了超过一千二百条评论。

帖子的作者是一位在两家大型科技公司工作过的高级工程师，他描述了自己在全面转向AI辅助后，编程能力在几个维度上的变化。他不再能记住常用API的精确签名——因为AI会帮他补全。他不再在大脑中维护完整的项目结构——因为AI会帮他导航。他不再在第一次写代码时考虑边界条件——因为AI会生成基础版本，他再审查补充。

他写道：“我的生产力确实提高了。但我有时会想，如果有一天AI工具突然消失，我还能不能像三年前那样，徒手写一个完整的后端服务。我觉得我会很慢，可能还会犯很多基础错误。我成了一个需要一个AI才能高效工作的人。”

这个帖子之所以引发如此大的共鸣，是因为它触及了2025年软件工程师的核心焦虑：不是“AI会不会取代我”，而是“AI会不会让我变成一个更差的工程师，同时让我更依赖AI”。这是一种新的职业脆弱性。过去的工具升级——从汇编到C、从C到Java、从手动部署到DevOps——都在提高抽象层次，但工程师仍然保留着对底层原理的理解，因为在任何抽象层出问题时，他们可以下沉一层去排查。

AI辅助编程的改变与此不同：它不是在提高抽象层次，而是在让工程师跳过理解过程本身。当工程师不再需要理解代码的每一行，他们可以更快地交付功能，但他们对系统的理解正在变浅。这种变浅在功能正常时不可见，在系统出问题时才会暴露——而那时候，故障排查的难度会成倍增加。

2025年秋天，工程效率平台LinearB发布了一份分析报告，基于对其平台上超过三千个团队的代码审查数据分析。报告发现，在使用AI辅助编程的团队中，代码审查通过率确实提高了——从72%上升到了84%。但后续的缺陷跟踪数据却显示，这些通过了审查的AI生成代码，在上线后三十天内发现的缺陷密度，比人类编写代码高出23.5%。

换句话说，审查者在审查AI代码时，遗漏了更多问题。LinearB的分析师在报告中写道：“这可能是因为AI生成的代码在表面上看起来更‘整洁’——风格一致、命名规范、结构清晰——这会让审查者产生一种虚假的安全感，从而降低审查的警惕性。”这个发现与谷歌内部报告中的观察一致：AI代码的错误类型更隐蔽，因为它们不是“错误”，而是“误解”——它们在不被触发的条件下看起来完全正确。

这些工作流层面的变化，最终必然反映在价格上。2025年，自由职业平台上的编程服务市场正在经历一场缓慢但持续的价格重分配。Upwork在2025年第三季度的平台数据报告显示，在过去两年中，标注“AI-assisted”的开发者完成的编程项目数量增长了317%，而同期传统编程项目的完成数量下降了9.4%。但更值得关注的是价格数据。在2023年，标注“AI-assisted”的开发者，其项目平均报价比传统开发者高出12%——那时的AI辅助还是一种稀缺技能，能够熟练使用Copilot或Cursor的开发者可以获得溢价。到了2025年第三季度，这个溢价消失了。不仅消失，还出现了反转：在Web开发、移动应用开发和API集成等常见项目中，标注“AI-assisted”的开发者，其平均报价比传统开发者低了8%。这个数据需要仔细解读。它并不意味着AI辅助降低了开发者的收入——普莉扬卡这样的自由职业者，其总收入在增长。它意味着AI辅助提高了生产力，而生产力提升的一部分收益，通过市场竞争机制转移给了客户。这是经济学中的标准现象：当一项技术使所有生产者的效率提高时，单位产品的价格就会下降，除非该产品有某种不可替代的独特性。对于大多数标准化编程任务——一个电商后端、一个内容管理系统、一个数据分析仪表盘——AI确实让生产效率大幅提升，但同时也降低了这些任务的稀缺性。当更多开发者能更快地完成这些任务时，客户就有更多选择，价格就会被压低。

但这种价格下降并不均匀。在自由职业平台的高端市场——需要架构设计、系统集成、安全审计或特定行业知识的项目——AI辅助带来的价格下降幅度要小得多，甚至不存在。因为这些项目的价值不在于能写多少代码，而在于能做出多少正确的判断。AI可以生成代码，但无法替代架构判断。在2025年秋天，一些经验丰富的自由开发者开始有意识地将自己的服务定位从“编程”转向“技术决策”。他们不再在项目描述中强调“全栈开发”，而是强调“系统设计”“技术选型顾问”和“AI协作策略”。一位在Toptal上排名前5%的自由架构师在2025年的一次采访中说：“我的客户现在不关心我写代码有多快。他们关心的是，我能不能告诉他们，哪些部分应该让AI写，哪些部分必须人写，以及如何确保AI写的部分不会在六个月后变成技术债务。这是我现在被付钱的理由。”

这个转向揭示了一个更深层的结构：在AI辅助编程普及之后，软件工程的价值链条正在分层。底层是代码生产——这个层次正在被AI快速商品化，其市场价值在下降。中层是代码质量管理——这个层次在短期内需求仍在增长，但因为AI输出质量的持续提升，其长期价值也不确定。顶层是系统判断——包括架构决策、技术风险识别、人机协作策略设计——这个层次的价值在上升，因为它要求的是AI无法替代的认知能力：在不确定条件下做出权衡，对复杂系统的长期演化做出判断，在业务目标与技术约束之间找到平衡。

在2025年，有多个机构试图为这种新的职业角色命名。Gartner在2025年的一份技术趋势报告中，使用了“AI编排工程师”这个术语，将其定义为“设计、实施和监控AI智能体在软件开发中行为模式的专业人员”。麦肯锡在同一年的报告中使用的是“技术决策架构师”，强调其核心能力是“在AI辅助环境中做出高风险技术选择”。但最贴切的命名，来自开源社区。在GitHub上一个有影响力的开源项目的技术文档中，项目维护者将自己在AI辅助下的角色描述为“意图管理者”。这个术语迅速在开发者社区中传播开来，比任何咨询公司的命名都更准确地捕捉到了工程师新角色的本质：不是编写代码，而是管理系统中的意图——哪些意图应该交给AI实现，哪些必须由人类保留，以及如何确保AI实现的意图与人类保留的意图保持一致。

从“代码生产者”到“意图管理者”的迁移，不是一夜之间发生的。它沿着缰绳层的成熟过程逐步推进。2023年，Copilot只是补全代码行，工程师的意图仍然通过手写代码的第一行来输入。2024年，Cursor和Claude Code开始根据自然语言描述生成整个函数，工程师的意图通过注释和提示来输入。2025年，智能体配置文件开始出现在每个新仓库的初始化阶段，工程师的意图在代码被生成之前，就已经通过约束规则被编码进了项目的基础设施。每一步都在将工程师的工作向上游推移——从具体的实现细节，到对实现结果的质量控制，再到对实现过程的行为约束。这不是一个“失业”或“解放”的简单故事。它是一个职业角色的重新定义，其中的赢家与输家，取决于个体在缰绳层中的位置。那些处于缰绳层上游的人——定义约束规则、设计架构边界、决定AI行为策略的人——他们的价值在上升。那些处于缰绳层下游的人——在既定约束下执行代码生产任务的人——他们的可替代性在增加，市场价值在下降。这不是一个技术能力问题，而是一个位置问题。2025年，一个拥有十年经验的高级工程师，如果他仍然将自己定位为“代码生产者”，他可能在市场上发现自己的薪资增长停滞，甚至面临来自三年经验但熟练使用AI的开发者的竞争。而如果他将自己定位为“意图管理者”，他可能会发现自己的价值不降反升——因为能够将复杂的业务需求转化为精确的AI指令、并在审查中识别出AI输出的隐蔽风险的人，在任何公司都是稀缺的。

然而，这种向“意图管理者”的迁移并非没有代价。第一个代价是认知上的。当工程师不再亲手构建系统时，他们对系统的深层理解正在退化。这种退化在短期内被AI的高效掩盖，在长期中的后果尚未可知。2025年秋天，一位在麻省理工学院从事软件工程研究的教授，在《ACM通讯》上发表了一篇评论文章，提出了一个令人不安的假说：如果两代工程师都在AI辅助下学习编程，他们将不再拥有那些通过痛苦调试、徒手重构和深夜排查内存泄漏而获得的系统直觉。当这些工程师成为高级工程师和架构师时，他们是否还能做出正确的技术判断？文章写道：“我们正在跑一个巨大的实验，实验对象是整整一代软件工程师的认知能力。这个实验没有对照组。”

第二个代价是心理上的。在2025年，一个反复出现在工程师社区讨论中的主题是“职业认同的丧失”。编程曾经是一种创造性的手艺——从零开始建造一个系统，每一个细节都经过自己的手，每一个决定都体现着自己的判断。当AI承担了大部分建造工作，工程师的角色变成了“让AI建造，然后检查质量”，那种来自创造的满足感在减弱。这不是一个可以量化的代价，但它在工程师的日常体验中非常真实。马库斯在那次技术分享会上说：“我选择这份工作，是因为我喜欢建造东西。现在我发现，我建造的东西越来越少了，我检查的东西越来越多了。这让我感觉，我离当初让我热爱编程的那个理由，越来越远了。”

第三个代价是结构性的。当AI辅助编程大幅提高了生产力，而市场通过价格机制将生产力提升的部分收益转移给客户时，工程师作为一个整体，其议价能力在下降。这不是一个“AI导致失业”的故事——2025年，软件工程师的失业率仍然极低，需求仍然旺盛。但需求的类型在变化。公司需要的工程师类型，正在从“能写代码的人”转向“能管理AI写代码的人”，而这两种能力并不完全重叠。一个经验丰富的代码生产者，不一定能自动成为一个好的意图管理者。那些无法完成这一转型的人，将发现自己被困在价值链条中正在缩水的层级。

2025年11月的第二个星期，陈家明在深圳的办公室里，收到了一份来自固件团队工程师的邮件。邮件标题是：“关于AI辅助固件开发的补充建议”。发件人是团队里最年轻的一位工程师，入职刚满一年。他在邮件中提出了一个折中方案：在固件开发中，AI可以用于生成“初稿”，但所有初稿必须经过一个额外的静态分析步骤——一种比传统lint更严格的自动化检查，专门针对嵌入式系统中常见的AI遗漏模式：中断嵌套、内存对齐、看门狗时序。他在邮件末尾写道：“我理解我们不信任AI直接写固件。但我认为，我们也不应该完全放弃它。我们可以让它起跑，但必须由我们在终点线前进行检查。”陈家明读了两遍这封邮件，然后转发给了整个技术团队，附上了一行字：“这个方向可以讨论。我们需要的是检查规则，不是信任规则。”

在班加罗尔，普莉扬卡打开了她刚完成的一个项目。客户是一家伦敦的初创公司，需要为他们的物联网平台构建一个数据分析后端。她用了十二天完成，比原计划提前了五天。她提交了代码，写了详细的文档，附上了一份她为这个项目新开发的AI行为约束模板——她打算把这套模板标准化，作为她未来接类似项目的起点。客户在评估中给了五星好评。但她在查看项目报酬时，注意到了一个细节：这个项目的总价是两千五百美元，比她在2023年接的同类项目低了28%。她关掉页面，打开了一个新项目，开始建立新的仓库。

在旧金山，马库斯坐在厨房岛台前，花了一个小时写完了一篇文章。这是他写给自己的——一份“AI时代编程能力自检清单”，包括二十个他认为每个工程师都应该能不用AI完成的任务：从徒手写一个TCP连接池，到手动实现一个无锁数据结构，到在没有AI提示的情况下排查一个分布式死锁。他在文章开头写道：“我写这个清单不是为了反对AI。我是为了防止自己在AI能完成所有事情的幻觉中，变成一个只会写提示的工程师。”他打开GitHub，把清单发布到了自己的个人仓库里。二十四小时后，它获得了三百颗星。

三个人，三个城市，三天之内各自做出的三个选择。它们之间没有因果联系，没有统一的叙事线索。但它们共同指向了同一个事实：在2025年，软件工程师正在各自摸索一种新的自我定义——在这种定义中，AI不再是工具，也不是对手，而是他们必须与之建立一种生产关系的合作者。这种关系的条款，没有人替他们写。他们必须在日常工作中，在每一次选择中，在每一个配置文件、每一次代码审查、每一个项目报价中，自己写出这项契约的具体内容。

当GitHub在那份年度报告中写下“配置文件已成为项目脚手架中不可或缺的一环”时，它所指的不仅仅是技术基础设施的变化。它无意中记录了一个职业在历史转折点上的自我重构。那个超过半数的比例——53.7%的新仓库包含智能体配置文件——不是一个工具普及率的统计数字。它是一个信号，表明一种新的契约已经在足够多的个体实践中被反复书写，以至于它开始凝结为一种默认的行业规范。而在这项契约的条款中，最核心的那一条从未被明确写出，却已经刻在了每一个配置文件的创建动作里：从今往后，代码不是工程的起点。约束代码的规则才是。