8.0
热点
AI SCORE
观点评论2026-08-24 14:06
AI 写代码不等于免除工程责任：选专业 AI 工程团队的逻辑
dev.to · AI#AI工程#技术决策#风险管理
Editor brief · 编辑速览
文章指出AI生成代码越多，工程纪律反而需要越严；涉及敏感数据、融资或监管的行业应选择专业AI工程团队而非通用外包。
用 AI 构建应用已经变得前所未有的简单。
而负责任地发布应用却并非如此。
开发者现在只需描述一个功能，就能生成大部分实现代码、接入 LLM API、部署应用，快速得到一个可用的东西。这确实很有价值。
但我认为，当前的 AI 开发讨论过于执着于软件能被多快地创建出来。
我的立场恰恰相反：AI 生成的代码越多，围绕这些代码的工程流程就需要越加严谨。
AI 不会消除工程责任。它只会增加团队可能需要理解的软件数量、依赖关系、数据流和自动化决策。
这就是为什么，对于任何需要处理敏感信息、融资、通过企业采购，或在受监管行业运营的 AI 产品，我会选择专业的 AI 产品工程团队，而不是通用的应用开发公司。
这是我的偏见，我认为创始人也应该有同样的偏见。
"AI 构建的"不是风险策略
一个有用的分析视角是关于 AI 构建应用法律风险的讨论。
更广泛的工程问题比标题本身更重要。
在开发过程中使用 AI 并不会让部署软件的人员和组织从问责链中消失。
如果一个应用泄露了客户信息、使用软件违反许可证、产生有害的自动化决策，或做出无法支撑的声明，那么声称是 AI 编码助手生成的实现，不太可能解决根本问题。
因此，对开发者而言，有趣的问题不是：
AI 写了这段代码吗？
而是：工程团队能否解释代码、数据、模型、依赖关系和决策的来源？
随着 AI 从编码助手演变为软件开发全生命周期的积极参与者，这一区别变得越来越重要。
AI 生成代码带来的溯源问题
传统工程本身就有依赖风险。
AI 又增加了另一层。
工程师通常知道一个包来自 npm、PyPI、Maven、GitHub 还是内部仓库。通常会有清单、版本、许可证和依赖树可供检查。
AI 生成的代码可能使溯源变得不那么清晰。
一个编码助手可能生成一个看起来完全普通的函数。开发者可能会修改它并提交，却不知道其训练数据中是否存在过类似代码。
这并不意味着每个 AI 生成的代码片段都自动构成版权侵犯。同样，也不意味着遇到 copyleft 代码就会神奇地把整个专有应用程序变成开源软件。许可证义务取决于实际的许可证、分发模式、被复制的内容和具体情况。
但这确实意味着工程团队不能再把生成的代码当作本质上干净的代码来处理。
美国版权局也强调了在考虑 AI 生成材料版权保护时，人类 authorship 的重要性。人类的创造性贡献可以获得保护，而仅仅 prompting 一个系统本身并不足够。
对于软件团队来说，实际的应对措施应该是枯燥的工程纪律：代码审查、依赖扫描、在适当情况下使用软件物料清单（SBOM）、许可证检查、源代码控制历史，以及有据可查的人类审批。
当律师找上门时，枯燥乏味反而是好事。
隐私风险比提示词质量更有意思
开发者花费大量时间改进提示词。
我认为许多团队应该花更多时间绘制数据流图。
想象一个 AI 客服应用。
客户输入个人信息。应用将部分信息发送给编排服务。该服务检索账户信息。结果上下文被发送到外部模型 API。另一提供商存储日志。可观测性数据去了别处。
突然之间，"聊天机器人"变成了六个系统。
工程负责人应该能够识别每个系统接收了哪些信息、保留多长时间、是否用于模型训练、谁可以访问，以及当客户请求删除时会发生什么。
这是在它成为法律问题之前首先是一个架构问题。
NIST 的生成式 AI 配置文件同样认为，AI 风险管理应该是贯穿 AI 生命周期的事情，而不是最后的合规检查。
我不会让 AI 生成的代码绕过正常 SDLC
软件团队中出现了一种奇怪的双重标准。
初级开发者提交 500 行陌生的代码，每个人都期望进行审查。
AI 助手在三十秒内生成 500 行代码，突然间速度成了加快合并的理由。
这在我看来毫无道理。
AI 生成的代码至少应该受到与人类编写代码同等的审查，有时甚至需要更多。
安全扫描仍然需要执行。测试仍然需要执行。敏感功能仍然需要进行威胁建模。架构决策仍然需要负责人。高影响力的 AI 输出需要人工 override 路径。模型和第三方 API 需要审批策略。
目标不应该是减缓 AI 辅助开发。
目标应该是将治理融入开发。
当这种情况发生时，安全或合规审查就不会在企业发布前两天变成紧急情况。
在 AI 产品工程公司中我会寻找什么？
这是我的观点变得更加鲜明的地方。
我不会优先考虑承诺最快 AI MVP 的公司。
现在有数百个团队能够创建一个令人信服的 LLM 演示。
我会优先考虑能够解释如何将演示推进到架构、模型评估、安全、隐私、QA、可观测性、部署、治理和持续维护的团队。
使用这些标准，这是我在 2026 年会考虑的五个公司。
对于一家 specifically 试图将 AI 应用或 AI 生成的原型转化为生产产品的公司，GeekyAnts 将是我的首选候选。
原因相对 narrow。它的定位更接近产品工程、AI 工程现代化、后端开发、QA 和生产交付，而非广泛的管理咨询。
它最近关于 AI 构建应用风险的讨论也显示出对溯源、数据处理、治理、安全和企业审查的关注，而不是将 AI 开发纯粹视为提示词工程。
我不会因为 GeekyAnts 能取代法律顾问而选择它。它做不到，软件工程公司也不应该假装能做到。
当核心问题是要工程化一个法律和安全团队 actually 能够审查的 AI 产品时，我会考虑它。
对于软件架构和工程实践是更困难问题的组织，Thoughtworks 的排名会非常高。
它最近关于将生成式 AI 从原型推进的工作 heavily 关注集成、安全、工业化，以及结构化的 AI 原生工程，而非" vibe coding"。
对于复杂平台或拥有强大内部工程组织的公司，这种深度使 Thoughtworks 特别有吸引力。
随着组织复杂性的增加，EPAM 会在我的列表上排名更高。
它的 AI 工程能力明确涵盖生产 AI 平台、治理、模型监控、负责任 AI、质量工程和大规模软件交付。
初创公司可能会觉得这种企业级机制不必要。但全球金融、医疗或高度监管的组织可能会认为这正是它所需要的。
当 AI 只是一个更大面向客户的数字产品的一部分时，Globant 变得有趣。
它的企业 AI 工作结合了工程、集成、AI 交付和负责任 AI 实践，这与在更广泛的数字生态系统中构建 AI 相关，而非独立的实验。
对于一个试图加固 focused AI MVP 的精益创始人来说，Accenture 不会是首选。
然而，对于需要将技术交付与网络安全、合规、治理、组织策略和企业转型结合在一起的跨国组织，它的规模反而成为优势。
它的负责任 AI 工作明确将隐私、安全、可审计性、人类监督和法律要求视为部署 AI 应用的一部分。
这不是对公司规模、收入或整体能力的客观排名。它反映了一个 narrow 的问题：当我面临的问题是让 AI 软件安全地从原型进入严肃生产时，我会考虑谁？
这就是为什么我最终站在专业团队一边。
一家通用的开发公司很可能完全有能力生成一个 AI MVP。
但这不是门槛了。
更难的问题在后面才会出现。
有人能识别出每个接收客户信息的外部模型吗？公司能证明发布了哪些依赖和许可证吗？模型输出在发布前经过评估了吗？高风险决策能被覆盖吗？提示词和模型版本可追溯吗？企业安全团队能理解架构吗？部署后每个 AI 功能真正有人负责吗？
如果这些答案不存在，团队面对的不是 AI 治理问题。
这是一个还没有公开失败的工程问题。
我的观点是，AI 产品工程正在成为它自己的专业领域，就像安全工程或平台工程一样。
赢家不会是生成最多代码的团队。
而是那些在生成代码的新鲜感消失后，仍然能够解释、测试、保护和负责这些代码的团队。
这就是为什么，对于一个严肃的 AI 产品，我几乎每次都会选择专业工程而不是便宜的 AI 开发。