文章目录本篇目标两份材料的结论受影响最大的人群第一关需求写成验收标准第二关用 Plan 模式先审计划第三关上线前把住高风险操作三道关一张表参考资料实用总结本篇目标“AI 已经能自己写业务代码了我是不是很快就没事可做”这个问题值得认真回答。10 月 12 日的 CSDN 热榜上也出现了 GPT-6 与前端岗位会不会消失的讨论。我更关心Agent 写完之后谁判断需求有没有理解错谁证明功能能用谁批准可能影响数据的操作本篇先看两份材料再按 Cursor 官方功能把需求、验收、上线三道关拆成能照做的动作。如果你碰到的是下面这些具体问题可以先看对应文章。你碰到的现象去看哪篇Agent 要操作网页不知道该用无头浏览器还是真 Chrome[企业AI落地] Agent 操作浏览器不只一种方式无头浏览器、Playwright 和真实 Chrome 怎么选Agent 控制网页时碰到要登录[实践经验] 龙虾或Hermes这样的Agent控制网页时需要登录怎么办先弹出可受控 Chrome再把登录态交给自动化脚本做完要交给同事用[Python实战] 自动化脚本交给同事用之前先这样检查一遍两份材料的结论第一份是中国经济网 2026 年 9 月 11 日的报道工信部发布《“人工智能软件”专项行动实施方案》提出“促进软件产业就业友好发展”。这说明就业影响已经进入政策关注范围。第二份是 NBER 工作论文《Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools》作者为 Mert Demirer、Leon Musolff、Liyuan Yang本篇依据的版本日期是 2026 年 9 月 6 日。研究样本包含 50 多万名 GitHub 开发者及其 AI 使用遥测数据。自动补全、交互式编码代理、自主编码代理三代工具都显著增加了提交量累计效应分别约为 30%、180%、240%。约 240% 的提交增幅到了项目数只剩约 80%到了真正发布的 releases 只剩约 30%。这些是不同产出指标的增幅。作者用“弱链假说”解释这种衰减AI 的生产率受到链条上人类瓶颈的制约AI 与人的投入是强互补关系。研究还指出应用市场中新应用数量大增但总使用量没有增加。我从中得到的提醒是写出来、发出去、有人用是不同的问题。它提示的是单独加速编码软件交付的提速幅度会小得多。受影响最大的人群如果一份工作的主要内容是把已经明确的需求翻译成代码那么从任务性质看它更直接面对 AI 编码工具的能力变化。这是基于材料的判断。“写业务代码”还包含边界判断需求里没有说清的边界、不同角色能看哪些数据、旧功能能不能继续用都需要有人判断。能力提升的重点可以放在三个问题上能否把含糊需求变成可检查的结果能否识别实现与需求之间的偏差能否说明上线失败后的影响和恢复办法。这对读代码的要求反而更高。如果读不懂关键改动就很难判断 Agent 是解决了问题还是绕过了问题。所谓更有价值是能拿出交付依据。第一关需求写成验收标准先写清“什么结果算完成”再让 Agent 决定怎么实现。只说“增加一个导出功能”Agent 仍然需要猜导出全部还是当前筛选结果没有数据怎么办权限是否沿用原规则下面是假设的“导出当前筛选记录”功能用于演示需求写法。Given 写前提When 写动作Then 写可观察结果。1. 正常导出 Given当前筛选结果非空用户具有导出权限。 When用户发起导出。 Then导出内容与当前筛选结果一致不包含筛选范围外的记录。 2. 空结果 Given当前筛选结果为空。 When用户发起导出。 Then明确提示没有可导出的记录不生成含无关数据的文件。 3. 无权限 Given用户不具有导出权限。 When用户尝试发起导出。 Then拒绝导出不返回记录内容。这些标准的作用是让“完成”有一个不依赖 Agent 自述的判断依据。你可以换实现方式但不能悄悄换掉预期结果。交给 Agent 前还要明确本次不做什么例如不修改现有权限规则、不顺带重构无关模块。实现中如果发现必须扩大范围应先说明原因。验收标准也需要人审。把含糊需求交给 Agent让它自己补规则、自己写测试、自己宣布通过并没有消除最初的含糊。第二关用 Plan 模式先审计划Cursor 官方文档给出的 Plan Mode 流程是Agent 先问澄清问题研究代码库再生成详细实施计划你可以在聊天或 markdown 文件里审改计划之后点击开始构建。按快捷键 ShiftTab 可以切到 Plan Mode复杂任务时 Cursor 也会自动建议使用。计划默认保存在用户主目录可以通过“Save to workspace”存进工作区。要把上一节的验收标准一起交给 Agent不要只让它“制定一个合理计划”。审计划时重点检查四项。范围计划是否覆盖验收标准有没有把本次不做的内容也加进来。文件准备改哪些文件各自为什么要改是否触及无关模块。测试每条验收标准怎样检查正常、空结果、无权限是否都有对应验证。回滚做偏后哪些改动需要撤回是否涉及不能只靠撤销代码恢复的数据变化。这四项是本篇的审查建议。官方建议把 Plan Mode 用在多种实现路径的复杂功能、多文件任务、需求不清或架构决策上小改动直接使用 Agent 即可。不必为了形式让每次细小修改都经过长篇计划。官方还给出一个建议如果做偏了不要继续靠追问修补而是回退改动把计划写得更具体再跑一次。计划审过之后还要单独验收。代码完成后要回到原来的标准逐条核对不能拿“按计划执行了”替代“结果符合要求”。第三关上线前把住高风险操作审需求解决“做什么”审计划解决“怎么做”上线前还要确认“哪些操作不能直接放行”。Cursor CLI 在 v2026.06.22 引入 Auto-review 运行模式定位介于白名单和全部运行之间可以在 permissions.json 中写 allow/block 指令引导分类器。v2026.10.08 的更新进一步收紧高风险删除审批递归、强制、通配符或镜像删除只要目标可能与写下的目标不一致例如变量未设置、路径里多了一个空格就会先要求批准。这说的是 Cursor CLI 的操作审查。应该把审批当作一次重新核对目标的机会不要习惯性确认。准备上线前可以先按下面的清单检查 diff再对照实际执行命令。1. 删除 是否删除了不在需求范围内的文件或数据 涉及递归、强制、通配符或镜像删除时实际目标是否明确 2. 覆盖 是否覆盖了已有配置或用户数据 被覆盖的内容是否保留了可恢复的副本 3. 权限 是否扩大了原有访问范围 是否为了让功能通过而绕过了权限判断 4. 密钥 是否把密钥、令牌或连接凭据写进了代码、配置或测试文件 准备提交的内容是否包含不应进入仓库的信息这是一份人工检查模板。diff 展示的是改动命令执行时还会受到实际路径和变量值影响两者都要看。对于具体审批入口或权限配置细节官方未写明以你租户/工程里的实际界面为准。三道关一张表我把前面的动作整理成下面这张交接表。它是建议的责任划分。关口人做什么Agent 做什么放过问题的代价需求关确认目标、边界与验收标准提问、整理需求、标出不明确之处更快地做出不需要的功能验收关审计划按标准核对结果研究代码、提出计划、实现并提供验证材料表面可用异常或权限场景出错上线关核对高风险操作、实际目标与恢复办法提供改动说明和待审操作误删、覆盖、越权或凭据泄露如果明天就开始用我建议从一个边界清楚的小功能入手先写验收标准再决定是否需要 Plan Mode最后核对结果与高风险改动。暂时没有证据支持通过的项目就保留为待确认不让 Agent 的“已完成”替你做决定。参考资料中国经济网工信部发布《“人工智能软件”专项行动实施方案》2026-09-11NBER 工作论文Writing Code vs. Shipping Code版本日期 2026-09-06Cursor 官方文档Plan Mode页面日期未注明Cursor 官方 CLI 更新日志v2026.06.22 与 v2026.10.08实用总结AI 增加了代码提交量可发布、有人用的软件增幅要小得多。先守住需求、验收、上线三道关把“看起来完成了”变成有依据的判断。面对岗位变化比猜测谁会消失更可操作的做法是练习写清标准、读懂改动、承担交付判断。本篇收入「Cursor / AI Agent 实战」专栏你可以沿着需求澄清、计划审查、结果验收这条线继续阅读。你用 Agent 时最不放心的是哪一步