人工智能在生产中的应用效果尚无定论，而且前景并不乐观。
- 使用人工智能的团队完成的任务数量增加了 21%，但公司整体交付指标并未显示出任何改善（Index.dev，2025）。
- 经验丰富的开发人员在使用 AI 编码助手时速度降低了 19%，但他们却认为 AI 编码助手速度更快（METR，2025）。
- 48% 的人工智能生成代码包含安全漏洞（Apiiro，2024 年）
要理解个中缘由，我们需要仔细审视一下日常的软件开发过程。不妨看看r/ExperiencedDev 论坛上一段精彩讨论中提出的观点：
开发人员的工作是减少歧义。我们理解业务需求，并精确地勾勒出其逻辑，以便机器能够执行。编写代码本身反而是最简单的部分。即使有会议记录，你也未必能把完美的代码规范写进工单里，因为开发人员在实现过程中会遇到需要澄清的极端情况……
这条评论提出了两个关键点。首先，编码助手需要明确定义的需求才能有效运行。其次，边缘情况和产品缺陷通常会在实施过程中被发现。
在将编码助手应用于复杂代码库时，这两个事实会直接冲突。与人类程序员不同，人类程序员会在必要时将需求差距上报给产品团队，而编码助手却常常将这些需求差距隐藏在数百行代码中，导致破坏性变更和难以维护的代码。
因此，下游代码审查（Index.dev，2025）和紧急修补安全漏洞（Apiiro，2025）需要花费更多资源。
换句话说，在生产环境中使用人工智能往往会增加歧义并降低代码可靠性，这与开发人员的目标直接相悖。
前景并非一片黯淡。一些经验丰富的工程师报告了变革性的成果：谷歌的一位首席工程师声称，人工智能“在一个小时内就生成了我们去年开发的东西”；Claude Code 的创始人 Boris Cherny描述了一个月内他“完全没打开集成开发环境 (IDE)”，而该模型“编写了大约 200 个 PR，每一行代码都是他自己写的”。乐观的设想是，开发人员将从程序员转型为产品工程师，专注于架构和产品思维，而人工智能则负责实现。
但这反映了经验丰富的开发人员的经验，他们既具备批判性地审查 AI 输出的技术深度，又具备在组织内跨越产品和工程的自主权。
对于大多数软件工程师而言，尤其是银行、医疗机构和政府部门的初级和中级工程师，他们的回旋余地要小得多。他们既要面对人工智能输出的不可靠性，又要承受管理层日益增长的快速交付期望，这导致开发人员和产品负责人之间的理解鸿沟迅速扩大。
产品背景信息往往要经过多层传递（最终用户 -> 市场营销人员 -> 产品经理）才能最终到达产品经理手中，这是由于组织内部职责划分以及各行业的独特需求所致。有效利用编码代理可能需要团队高度协作，而这种协作带来的技术产出提升却可能得不偿失。
但是，如果我们只是从错误的角度看待问题呢？假设我们从根本上解决软件开发的痛点，我们能否找到能够自然而然地减少歧义并可靠地提高生产环境中工程速度的解决方案？
考虑一下开发人员如何支配他们的时间（IDC，2024）：
开发人员只有 16% 的时间用于编写代码。其余时间呢？安全和代码审查、监控、部署、需求澄清——这些运维工作维持着系统的正常运行，但并不负责发布新功能。
讽刺的是：人工智能编码助手每周大约能为开发人员节省 10 个小时，但开发生命周期其他环节效率低下带来的损失几乎完全抵消了这些收益（Atlassian，2025）。以下是前面提到的那位 Reddit 用户的评论。
他们编写的代码看起来合情合理，但如果没有人有过先仔细思考假设再将其转化为代码（并考虑各种极端情况）的经验，那么代码就会被勉强通过审核并发布。你把反馈环节的责任转移到了代码输出之后，这让我们处境更糟，因为代码的可读性远高于编写性。
业务意图与代码库实现不一致的情况被称为技术债务。如果编码代理的职责范围没有明确界定，那么使用编码代理可能会加速技术债务的积累。
简单地将AI代码生成器强加到现有代码库上并不能解决问题，因为与“技术债务”这个标签可能暗示的相反，大多数技术债务实际上并非产生于代码本身，而是产生于产品会议中。截止日期、范围缩减、“先发布，后优化”等等，这些决策塑造了系统，但其背后的逻辑却很少体现在代码中。
工程师有时能获得完整的数据；有时则只能依靠有限的信息。他们或许意识到证据存在不确定性，但通常情况下并非如此。相互冲突的社会、经济和战略优先事项会以意想不到的方式影响权衡取舍。—— Rios等人，2024
如何才能让这种上下文共享和决策过程更加顺畅？我们针对不同角色和团队规模的开发人员，就其产品工程交接流程进行了调查。结果令人震惊：大多数开发人员在确定产品方向和相应的架构实现之后，仍然每周都会发现意料之外的代码库限制。当被问及什么最有帮助时，以下两个主题最为突出：
- 减少上游的歧义，避免工程师在实施过程中因等待产品说明而受阻。
- 更清晰地了解受影响的服务和极端情况，以便更精确地确定功能范围和时间分配。
当被问及在产品讨论中提出哪些工程背景最有价值时，有三个类别脱颖而出：状态机差距（由用户交互序列引起的未处理状态）、数据流差距和下游服务影响。
在产品会议之后，工程方面最需要了解的是，功能更新如何影响现有架构和数据流。
这与数十年来软件开发生命周期 (SDLC) 的研究结果相符，这些研究表明，代价最高的缺陷源于需求和架构之间的不一致，而这种差距往往直到为时已晚才被发现。
幸运的是，LLM（大语言模型）的进步对我们有利。虽然通过自然语言提示生成功能齐全的代码容易因前述的上下文问题而出错，但利用最新的模型，反向过程——即梳理现有代码结构并推断其可能受到特定需求的影响——则要可行得多。
从这个角度来看，改进开发生命周期的可能性是无限的。有人建议在会议期间实时显示工程上下文，以帮助引导讨论；也有人要求开发一个代码审查机器人，用于检测代码实现与既定产品/业务需求之间的差异。
总而言之，开发者们渴望尝试能够增强现有工作方式的新工具，前提是这些工具的部署时间能够保持灵活性。他们也并不反对召开时间更长但更有成效的产品会议：真正令人沮丧的是难以有效地传达遇到的障碍。
在 Bicameral，我们致力于采取这种务实的方法来缓解软件开发的难题，并超越实验室基准测试，探索在实际环境中部署 AI 的最有效方法。
我们的论点是，LLM 对于行业和个人开发者来说都是一个巨大的福音——它能够引导人类在不确定性下运作和适应的无与伦比的能力——前提是这项技术在开发时要考虑到人类的需求。
bicameral-ai.com
参考
- Index.dev. (2025). AI 编码助手投资回报率：真实生产力数据。
- METR. (2025).衡量人工智能完成长时间任务的能力。
- Apiiro. (2024).速度提升 4 倍，漏洞增加 10 倍：AI 编码助手带来更多风险。
- IDC。（2024）。软件开发人员如何安排时间？
- Atlassian。（2025）。开发者体验状况报告。
- Rios, N. 等 (2024)。技术债务：系统文献综述。
- 实用工程师。(2025)。当人工智能编写几乎所有代码时。
