一个编码智能体可以在几分钟内改完一个已有代码库里的函数，但真正难回答的问题不是它改得快不快，而是它被允许做什么、我们凭什么相信这次改动是可靠的。InfoQ 在 2026 年 10 月推出两个为期五周的线上认证学习小组，一个盯 AI 安全与隐私工程，一个盯 AI 辅助工程，恰好都落在同一个困惑上：当智能体开始动真实代码、碰真实数据，检查该放在哪一步。
两个小组，两种检查
AI 安全与隐私工程小组从 10 月 26 日开始。参与者带着一个手头正在做的工作问题进来，追踪敏感信息从哪一步进入 AI 工作流，又可能流向哪里。他们用威胁建模和红队演练审视架构，然后测试控制措施，并考虑系统必须让哪些失败变得可见。
AI 辅助工程小组从 10 月 19 日开始，参与者在一个共享的遗留代码库上动手。他们为智能体构建上下文、限制它的权限、加入测试和传感器，把生成和审查分开，再把检查搬进持续集成。两个小组都给有经验的从业者留出时间，在引导者和来自其他组织的同行陪伴下把这些方法用起来。
这两个小组的结业项目都不是写一份报告了事。安全组的任务是评估一个 AI 产品架构，并说清楚识别出的风险、选定的控制措施、这些控制措施将如何被测试，以及谁为这些决定负责。辅助工程组则要交出他们搭出来的那套约束装置，还要提交一条从反复出现的审查发现里提炼出的规则或智能体技能，并把五周的记录结果和最初的预测做对比。
跟着数据和决定走完整条链路
安全小组由 Katharine Jarmul 引导。她是《Practical Data Privacy》的作者，工作聚焦机器学习和 AI 系统中的隐私与安全，曾在 InfoQ Dev Summit Munich 2025 做开场主题演讲，也在 QCon 上做过分享。
她描述这套方法时说：“一次 AI 安全审查必须跟着数据和决定走完整条链路。在小组里，我们会梳理敏感信息可能流向哪里，测试我们选定的控制措施，并明确谁为剩下的风险负责。”
这句话里有一个容易被跳过的动作：明确谁为剩下的风险负责。控制措施不可能消灭所有风险，剩下的那部分总得有人认领。安全组的结业项目把这一点写进了交付要求里。
先限制权限，再谈检查
辅助工程小组由 Zichuan Xiong 和 Premanand Chandrasekaran 共同引导。Zichuan Xiong 是 Thoughtworks 的 AIOps 负责人，自 2008 年起主导架构和交付工作，现在为软件运营构建智能体系统，他还在 QCon 旧金山站共同引导小组和约束装置工程培训环节。
他把工程问题说得很直接：“一个编码智能体可以很快做出改动，但更难的问题是它被允许做什么，以及我们怎么知道这次改动是可靠的。我们会先构建上下文、限制权限，然后再给在已有代码库里工作的智能体套上检查。”
顺序值得留意：上下文和权限在前，检查在后。不是先让智能体跑起来再补护栏，而是在它动手之前就把能做什么、不能做什么划出来。
他的共同引导者 Premanand Chandrasekaran 是 Thoughtworks 的技术负责人，二十年时间带工程团队，专注持续交付和内部质量。他讲的是检查怎么变成工作流的一部分：“逐条人工审查智能体的每一次改动，并不能告诉我们哪些检查应该成为工程工作流的一部分。我们会让独立审查和持续集成检查发挥作用，然后把五周的结果和我们一开始的预期做对比。”
人工审查每一次改动，问题不在于累，而在于它不产出可复用的判断。哪些检查值得固化进流程，得靠独立审查和持续集成跑出来的结果说话。
五周之后拿什么对照
两个小组都设置了保密的同行小组，让参与者和处在不同约束条件下的资深工程师比较各自的选择。比如追问一项控制措施是否真的针对了它被选来处理的那个风险，或者展示约束装置抓住了什么、记录下来的结果是否支持最初的预测。
把五周的记录结果和开课时的预测放在一起对照，这个动作本身就把“我觉得这样能行”变成了可检验的东西。预测错了，说明对智能体行为的判断有偏差；预测对了，那套检查才有资格进入日常工作流。
两个小组的完整教学大纲和学习细节，在 AI 安全与隐私工程、AI 辅助工程的页面上可以查到。
热门跟贴