Responsible AI adoption needs developer workflow design

负责任的AI采用需要开发者工作流程设计 - Stack Overflow

2026年8月24日

负责任的AI采用需要开发者工作流程设计

组织无法通过一份员工仅阅读一次的文档解决影子AI问题。他们需要让负责任的使用比临时的使用更容易。

[

[编者注：如果你收听了我们的播客或阅读了我们的文章并想发表回应，请告诉我们。我们欢迎以评论区以外的形式展示社区观点，无论你是否同意我们的观点。请通过[email protected]与我们联系。]

创建影子AI最快的方式是发布一项政策并假设行为会随之改变。开发者在交付压力下工作，面对模糊的问题，会寻找能帮助他们推进工作的工具。当被批准的路径感觉缓慢、模糊或与实际工程工作脱节时，人们会为自己创造更快的路径。

这种矛盾正是负责任AI采用的核心。在Ryan Donovan最近与微软Sarah Bird在Stack Overflow播客上的对话中，责任聚焦于影响、问责和精心设计的人机协作流程。Stack Overflow关于开发者AI采用和信任的调查结果解释了为什么这种运营重点如此重要：84%的受访者正在使用或计划使用AI工具，而更多开发者不信任AI的准确性。主要的挫败感涉及那些看起来几乎正确但需要额外调试的输出。

组织无法通过一份员工仅阅读一次的文档解决这一差距。他们需要让负责任的使用比临时的使用更容易。

影子AI通常是工作流程的信号

领导者经常将未经批准的AI使用描述为合规问题。这种诊断为时已晚。当工程师将敏感材料粘贴到公共模型中或悄悄安装未经批准的代码助手时，组织已经未能提供可信的工作完成路径。

微软的《工作趋势指数》发现，通过自带工具的广泛使用，影子AI现象普遍存在，许多用户不愿承认他们将AI应用于重要任务。这种行为并不自动表明鲁莽，通常反映了实际考量：经批准的流程提供的价值不如未经批准的快捷方式。

正确的回应应始于好奇心。哪些任务促使开发者转向外部工具？什么摩擦阻碍了经批准的选项？团队需要哪些数据、上下文、集成或权限？Stack Overflow关于监控网关和经批准AI平台的讨论表明，通过支持可见性的基础设施引导实验的价值，而不是试图通过全面禁止来压制实验。

当领导者将每一次未经批准的使用都视为违规行为时，开发者会学会隐藏实验。当领导者将其视为诊断证据时，他们可以改进系统。

政策必须成为工程接口

良好的政策定义意图。良好的运营将这一意图转化为开发者在日常工作中可以做出的决策。

NIST框架围绕四个功能组织AI风险管理：治理、映射、衡量和管理。这些动词暗示了持续的工作。治理应告诉团队如何对用例进行分类，可以使用哪些模型和数据源，如何测试结果，谁负责批准，以及哪些证据应包含在开发记录中。

一个实用的政策应在不迫使工程师召开委员会会议的情况下回答这些问题：

哪些数据可以进入每个已批准的工具？该工具可以访问哪些仓库或系统？AI生成的代码需要多高水平的审查？哪些任务需要人类决策者介入？开发者在发现有害、不安全或不可靠的输出后应采取什么措施？何时将实验转变为生产系统？

根据Stack Overflow的技术采用调查结果，开发者将安全和隐私问题列为拒绝采用某项技术的首要原因。因此，明确的操作规则应促进技术采用，而非阻碍它。它们能减少对负责任使用方式的不确定性。

在已有工作的地方设置防护措施

存储在学习门户中的政策难以与嵌入IDE中的AI助手竞争。控制措施需要存在于仓库、拉取请求、构建流水线、访问系统和部署工作流程中。

NIST的AI安全开发指南将安全软件实践扩展到整个开发周期。企业AI使用也应遵循这一原则。团队可以将批准的模型配置纳入版本控制，按角色限制访问权限，扫描提示和输出中的敏感信息，为高风险使用场景保留日志，并在AI生成的更改合并前要求测试。

GitHub关于AI生成代码人工监督的指南建议采用功能检查、上下文验证、依赖项审查、协作审查以及适当自动化。这将抽象的“审查AI输出”指令转化为可重复的工程流程。

这些控制措施也应匹配AI特有的故障模式。OWASP对生成式AI应用的风险包括提示注入、敏感信息泄露、供应链弱点、输出处理不当和过度代理。使用AI工具解释代码的团队面临的风险与赋予代理写入生产系统的权限的团队截然不同。对两者施加相同的审批负担只会造成延误而不会提升安全性。

在工具行动前指定负责人

当人们将AI描述为协作者、助手或代理时，责任会变得模糊。这些词汇听起来有用，但软件无法承担组织责任。

每个用例都需要指定一个明确的人类负责人，该负责人了解预期结果并拥有足够的权限来停止或更改流程。此人无需检查每个标记。负责人必须定义可接受的性能标准，确定人类判断介入的位置，并确保系统失败时有人响应。

NIST可信部署生成式AI配置文件强调在设计、开发、使用和评估过程中贯穿风险管理。实际上，所有权应遵循这一生命周期。产品经理负责业务决策。工程负责人负责实现质量。安全和隐私专家定义相关控制措施。开发者负责提交的代码。审查者负责批准决策。运营人员负责生产监控和事件响应。

这种分工可防止常见的失败模式：每个人都接触AI系统，但没人承担其后果。

心理安全感可作为控制机制

团队无法管理他们认为无法安全报告的风险。当开发人员发现已批准的工具泄露上下文、伪造依赖项或鼓励不安全代码时，他们需要一种可信的方式提出问题，而不会被当作抗拒创新的人对待。

谷歌的Project Aristotle研究将心理安全确定为高效团队研究中最重要的动态因素。谷歌将其描述为一种人们可以承担人际风险、提问并暴露错误的氛围。这种氛围对AI至关重要，因为许多失败最初表现为微弱信号：一个奇怪的补全结果、一个可疑的包、一条未记录的数据路径，或一个看似合理但与领域知识冲突的结果。

DORA研究也发现，心理安全的软件交付文化与更强的绩效和韧性相关。当领导者在庆祝工具采用数量的同时惩罚质疑工具的人时，就会削弱这一优势。

管理者应询问团队哪里出了问题、工作流程如何鼓励了错误，以及下次可以采取哪些保障措施。他们应避免询问某个开发人员为何“信任AI”。这种表述将系统失败个人化，会教导其他人保持沉默。

为实际决策培训开发人员

泛泛的AI意识课程与开发人员在压力下做出的决策相距甚远。Stack Overflow的开发者信任分析将有效使用定义为一种技能，包括构建提示、评估输出以及将生成的代码集成到现有系统中。

企业团队的有效AI培训应类似于操作许可。它应涵盖批准的工具、允许的数据、常见故障模式、审查预期、升级路径，以及组织自身技术环境中的具体示例。

后端工程师需要练习检查生成的数据库迁移、认证逻辑和依赖项选择。数据工程师需要练习保护敏感记录和验证转换。工程经理需要知道何时需要安全、法律或架构审查。平台团队需要知道如何观察代理行为并限制权限。

Stack Overflow针对AI工具的开发者学习模式显示，开发人员通过多种资源主动构建AI技能，包括AI驱动的工具本身。组织应利用这种现有需求。为团队提供沙盒练习、有缺陷的输出供审查、可接受的提示示例以及可重复使用的内部模式。

培训应在工作流程中产生成果：仓库操作指南、审查检查表、可重复使用的测试套件、批准的提示模式和文档示例。证书证明参与。这些成果塑造行为。

衡量结果而非工具活动

领导者通常通过分配的许可证数量、提交的提示数量或每周活跃用户数来衡量AI采用情况。这些指标显示活动情况，但对工程价值或负责任的使用却知之甚少。

2024年DORA研究发现，AI采用率提高与文档质量、代码质量和审查速度的提升相关，同时也发现AI可能对软件交付性能产生负面影响。AI对开发绩效的这些混合影响支持采用更严谨的测量方法。

在引入人工智能前后，团队应评估定义的工作流程。有用的衡量指标可能包括周期时间、逃逸缺陷、回滚率、安全发现、审查负担、文档质量、事件数量、开发者满意度以及用于修正人工智能输出所花费的时间。相关指标取决于任务本身和所面临的风险。

Stack Overflow 的调查还发现，代理工具虽然能提升个人生产力，但并未促进团队协作。这种差异至关重要。工程师可能在本地任务上更快完成工作，但会将验证、集成或维护工作转移给同事。负责任的度量应追踪团队整体的工作流程，而非仅停留在表面的效率提升上。

让安全路径成为最快路径

当人工智能能帮助开发者解决实际问题时，他们才会使用它。治理机制的成功在于使这种使用方式变得可见、可测试且可支持。

组织应提供经过批准的工具，这些工具需包含有用上下文、便捷的访问方式、明确的限制条件以及快速的升级通道。应在代码仓库和自动化检查中对人员与代理的工作流程设计进行编码。随着数据敏感性、自主性、影响范围和可逆性增加，应要求更严格的审查。应保护报告失败的人员。应衡量团队成果而非统计点击次数。

工具供应商在其指导原则中也提出了相同观点。GitHub 告诉用户应将 Copilot 视为工具而非替代品，并要求审查和验证生成的响应。CISA 的安全设计原则同样要求组织将责任嵌入产品设计中，而非将全部责任转移给终端用户。

核心教训很简单。负责任的人工智能取决于组织的日常工作系统是否让负责任的行为变得切实可行，而非仅仅拥有政策。希望在工作中实现持久人工智能采用的领导者，应设计出经过批准的路径，使开发者能够快速推进工作，同时不放弃判断力、问责制或工程纪律。

Gleb Tsipursky 博士是一位行为科学家，被《纽约时报》称为“办公室密友”。他帮助技术导向的领导者在不支付过高费用的情况下提升员工参与度和创新能力。他担任人工智能咨询公司 Disaster Avoidance Experts 的首席执行官，并撰写了八本书籍，包括《工作中人工智能采用的心理学：从抵制到成果》（Georgetown University Press, 2026）。

这些文章采用知识共享署名-相同方式共享 4.0 国际许可协议授权。

creativecommons.org/licenses/by-sa/4.0/deed.en