执行之后:我理解的 AI 协作新能力
AI 能做得更多,不等于人可以少懂一点。真正被放大的,是我们定义目标、设计流程、检查证据和承担结果的能力。
方向是对的,但“执行不重要了”说得太满
我越来越认同一个变化:在办公和开发中,AI Agent 已能承担检索、写作、改代码、运行命令和测试等大量执行工作。于是人的稀缺价值,开始更集中在选对问题、拆清任务、划定边界、验收结果和及时纠偏上。
但这不是“执行能力被淘汰”。没有领域知识,就很难写出可靠的任务说明,也很难看出一个看似正确的答案究竟漏掉了什么。更准确的说法是:执行仍是底座,工作流设计与判断力成为新的放大器。
把一句命令,变成一条可验证的工作流
“修复登录问题”只是愿望;“先复现错误,再补边界测试,修改最小范围的源码,运行相关测试,最后列出风险和改动摘要”才接近可执行的流程。 好的工作流会写清目标、输入、边界、检查点、失败时的处理方式,以及完成的证据。
对 Codex 来说,项目根目录里的AGENTS.md还能沉淀长期规则,例如测试命令、目录约束和交付标准。它不是万能说明书,却能减少每次从头解释的成本。
审查不是“看一眼”,而是主动寻找反例
验收 AI 的工作,不能只问“能不能跑”。还要追问:它有没有越过权限边界?有没有破坏原有功能?失败路径、并发、数据一致性和回滚是否考虑到了? 这是一种负向测试思维——既看它做了什么,也找它没有做什么。
纠偏也应尽量基于证据。与其说“错了,重做”,不如指出失败的测试、错误发生的位置、被违反的约束和期望结果。 AI 可以协助审查,但最终的业务取舍与交付责任仍然属于人。
固定的“30% 写指令、50% 审查、20% 决策”时间配比,不适用于所有岗位;“AI 工作流架构师”可以描述一种能力组合,却还不是普遍统一的职位;来源不明的漏洞率、恶意技能占比和夸张的倍数结论,也不应当作确定事实写入。
安全与运营,必须进入工作流
Agent 一旦能读取网页、调用工具、安装依赖或操作业务数据,风险就不只来自“写错答案”。网页和邮件里的提示注入、虚构的软件包名称、权限过大、凭据泄露和失控的自动操作,都可能把一次普通任务变成安全事件。
所以高风险动作需要人工确认;权限应遵循最小化原则;外部网络和依赖源要受控;部署之后还要持续观察质量、失败率、成本与异常行为。 应被审计的是可观察的工具调用、操作日志和结果,而不是要求系统暴露所谓“完整思考链”。
现实已经给出了一些信号
OpenAI 公布的内部实践显示,Codex 已被用于大多数代码审查;NTT DATA 的案例中,一项原本由五位资深工程师花三天完成的事件分析被缩短到约半小时;Australian Payments Plus 也报告复杂调查由约四小时缩短到约半小时。这些案例证明执行效率可以大幅提升,同时也更凸显流程、验证和治理的重要性。
我的结论是:未来真正有竞争力的,不只是“会让 AI 做事”的人,而是能把事情定义清楚、让过程可检查,并为最后结果负责的人。
核验来源
- OpenAI:Codex 现已正式发布
OpenAI 内部工程师使用情况、PR 产出与代码审查实践
- OpenAI:Codex 的产品升级
代码审查会阅读代码库、依赖关系,并运行代码和测试验证行为
- OpenAI:安全运行 Codex
沙箱、审批、网络控制、身份权限与可审计记录
- OpenAI:提示注入
连接网页和外部工具后,需要限制 Agent 能接触的数据与操作
- OpenAI × NTT DATA
约 9,000 名活跃用户;一次事件分析由多人三天缩短至约 30 分钟
- OpenAI × Australian Payments Plus
复杂调查由约 4 小时缩短至约 30 分钟,模拟原型也明显提速
- USENIX Security 2025:Package Hallucinations
代码生成模型虚构软件包名称所带来的供应链风险