凌晨一点十七分，生产环境的登录接口开始成片报 401，我盯着屏幕手有点抖。三小时前，我还在跟同事说“这个 OAuth2 改造不难，加个依赖、改下配置就行”。我是老李，一个在后端摸爬滚打十年的程序员。今天想跟你聊一件反直觉的事：AI 编程最大的坑，很多时候不是它不会写，而是它写得太快。

## 01、痛点
团队引入 AI 编程之后，交付速度确实上来了，但返工率也跟着上来了。最典型的场景就是登录系统改 OAuth2。很多同学接到需求，第一步就是打开 SecurityConfig，直接往里面加 oauth2Login，再补一个依赖。跑起来一看，登录页跳不过去、回调地址报错、Session 策略没跟着改、测试用例挂了一片。

问题出在哪？不是 AI 不会写 SecurityConfig。它能写出语法正确、甚至框架用法都对的代码。但它不知道这个仓库里还藏着自定义的认证过滤器，不知道前端有一个回调处理组件写死了原来的表单登录返回结构，更不知道那套 Session 并发控制跟新的登录态有冲突。它看到的是局部文件，不是整条认证链。

我们缺的不是更强的生成能力，而是生成之前对仓库的理解能力。过去老程序员动手前会先翻几处代码、画一下调用链。现在 AI 一上来就能输出几十行，把“翻代码”这一步直接跳过了。速度是快了，方向却常常偏了。

## 02、是什么
create-plan 的核心，是让 WorkBuddy 在真正修改代码之前，先理解仓库、影响面、依赖和测试路径。它不是生成一个漂亮的计划文档，而是先把“应该改哪里、先改哪里、改完怎么验证”想清楚，再动手。

仍以登录系统改 OAuth2 为例。创建计划时，WorkBuddy 不会一上来就改 SecurityConfig。它会先扫描认证相关代码，找到 SecurityFilterChain、自定义 Filter、UserDetailsService、Session 配置、前端回调所在目录，以及已有的登录测试。接着把这些信息拼成一张影响面清单：哪些文件必须改，哪些文件可能被间接影响，哪些测试需要补。

计划的输出通常包含几个部分：改动目标、前置依赖、影响面列表、执行顺序、风险点、验证方式。它更像一份施工前的放线图，而不是事后补的施工日志。有了这张图，哪怕 AI 生成得再快，也会被框在一个已经过验证的方向里。

## 03、为什么
AI 编程最大的问题往往不是不会写，而是写得太快。快本身不是坏事，但在没有理解上下文时，快会把错误放大。

你可以把生成过程想象成一辆没有刹车的高速车。模型看到一个文件，就根据局部上下文输出代码；它不会主动去查另一个模块里的 Session 管理器，也不会意识到前端还有回调处理。没有减速带，车就直接冲进了 SecurityConfig。

计划相当于给高速生成加一道减速带。它在“理解”和“修改”之间插入一个中间层，强迫先把影响面看全。这个过程不需要人肉去翻所有文件，WorkBuddy 可以自动完成大部分扫描，但关键结论要落在计划里，成为后续修改的约束。

另一个好处是，计划能提前暴露错误方向。很多错误不在代码语法上，而是在选错了改动起点。比如把 OAuth2 的 state 校验写进后端过滤器，却忽略了前端回调会丢失 state 参数。如果先做影响面分析，第一轮计划就会标记出“前端回调参数不完整”，而不是等到联调时才发现。

## 04、架构
create-plan 在 WorkBuddy 里不是单一功能，而是一条由多个环节组成的前置链路。整体上可以分成四层。

第一层是仓库感知。WorkBuddy 会先读取目录结构、构建文件、路由表、配置项，判断这是一个前后端分离项目还是单体应用，确认认证逻辑集中在哪些模块。它不直接读全部代码，而是先建立索引，减少无关文件的干扰。

第二层是依赖图谱。从入口如 SecurityConfig 出发，沿着注解、自动装配、过滤器链、拦截器、Cookie/Session 工具类，把相关类和方法串起来。这一步能发现那些藏在角落里的自定义组件，比如一个继承了 OncePerRequestFilter 的 Token 校验器，或者一个写了静态方法却在 12 个地方被调用的 SessionUtil。

第三层是影响面分析。依赖图谱建好之后，就能回答三个问题：改 A 会不会影响 B；先改哪个文件最安全；哪些改动需要同步调整前端或测试。对于登录改 OAuth2，它会列出 SecurityConfig、自定义过滤器、回调控制器、前端回调页面、测试夹具等。

第四层是测试路径提取。WorkBuddy 会搜索现有测试目录，找到登录相关的单元测试、集成测试和端到端测试，标记出哪些会在改动后失败，哪些覆盖不到新逻辑。比如授权码模式下需要测试 state 参数校验失败的情况，但原测试里根本没有这条用例，计划里就会自动补上这条验证路径。

这四层并非顺序执行完才出计划，而是边扫边出中间结果，最终汇总成一份执行计划。

## 05、实战
为了看清“直接写”和“先计划再写”的差别，我在同一个需求上做了对比：把一个基于表单登录的 Spring Security 系统改成 OAuth2 授权码登录。

直接写的路径很典型。我先让 WorkBuddy 直接改 SecurityConfig，加入 oauth2Login 和 client 注册信息。第一次生成代码没有语法错误，依赖也加对了。但启动后登录页能跳转到 OAuth2 服务，回调回来却报 403。原因是项目里有一个自定义的 JwtAuthenticationFilter，它在 OAuth2 登录流程中仍然生效，把回调请求当成了未携带 JWT 的请求直接拦截了。

第二次修改，去掉那个过滤器对回调路径的拦截。登录终于通过，但前端页面没拿到用户信息。前端一直从 /api/me 接口取用户，而后端 /api/me 是根据 Session 中的老登录态来取。OAuth2 回调成功后，Session 里放的对象结构变了，前端解析直接抛异常。

第三次修改，统一 Session 对象结构。跑起来后，又发现测试环境有两条用例永远失败：一条是模拟表单登录的集成测试，一条是验证 Session 并发控制的测试。因为它们仍然依赖旧登录机制。为了改这两条用例，又顺手改了测试基类和两个工具方法。

整个过程下来，一共动了 9 个文件，返工 3 次，耗时将近一天。最麻烦的不是改代码，而是每次跑起来才发现漏了另一个环节。

再看“先计划再写”的路径。我先让 WorkBuddy 创建计划。它没有直接改 SecurityConfig，而是先列出认证链上的所有节点：SecurityFilterChain、自定义 JWT 过滤器、UserDetailsService、回调控制器、前端回调页面、/api/me 接口、Session 配置、登录相关测试。计划里标出三个关键风险：自定义过滤器会拦截回调；Session 对象结构不一致；测试用例覆盖不到新登录流程。

然后按照计划顺序执行：先调整过滤器放行规则，再统一 Session 结构，接着改前端回调参数处理，最后补两条 OAuth2 测试用例。执行过程没有出现“跑起来才知道漏了”的意外，一次通过，改动文件数也是 9 个，但返工次数为零。

同样的需求，同样的 9 个文件，差别不在代码生成质量，而在改代码之前的 20 分钟。

## 06、洞见
很多人以为计划的价值是留下一份文档，方便以后复盘。其实不是。计划真正的价值，是在你投入精力和算力之前，提前暴露错误方向。

我们回头看登录改 OAuth2 的例子。最贵的错误不是写错了一行代码，而是把整个改造的起点选在了 SecurityConfig。第一步一旦选错，后面的过滤器拦截、Session 结构、前端解析都会变成连环坑。计划的作用，就是在动手前问一句：第一步真的该改 SecurityConfig 吗？

计划的另一个隐藏价值是，它把 AI 的“局部最优”拉回到“全局可行”。模型擅长根据当前文件给一个看似合理的方案，但它不擅长主动跨越模块去核对影响。计划机制通过仓库扫描和依赖图谱，把跨模块的信息补了回来。这样 AI 生成的快，就变成在正确方向上的快，而不是在错误方向上的快。

所以，不要把计划当成额外负担。它不产出产品功能，但能避免那些半夜把你叫起来的返工。

## 07、行动
计划很有用，但也不能无限扩大。一个修拼写的小改动、一条日志级别调整、一个常量重命名，如果也要先扫描仓库、建依赖图谱、列测试路径，那成本就大于收益了。

我的判断标准很简单：中大型需求默认先 Plan，小修复直接执行。

具体来说，满足下面任意一条，就值得先走 Plan：
第一，预计改动文件超过 3 个；第二，涉及认证、权限、支付、数据迁移等敏感逻辑；第三，需求跨前后端或跨模块；第四，现有测试覆盖不清晰；第五，你无法立刻说出谁是下一个受影响的人。

反过来，如果只是改一个文案、修一个空指针、加一条日志，直接让 WorkBuddy 执行即可。小修复走完整计划，就像给自行车螺丝上四轮定位，看似严谨，实则浪费。

中大型需求里，Plan 的时间控制在 15 到 30 分钟比较合适。如果计划本身超过这个时间，说明需求拆得不够小，或者对仓库的索引还不够成熟。这时候应该先缩小需求范围，而不是继续扩大计划。

## 08、小结
AI 编程的瓶颈已经从“能不能写出来”变成了“能不能改对地方”。写得太快而理解太少，是现在返工的主要来源。create-plan 用一道计划减速带，把仓库理解、影响面、依赖和测试路径放到修改之前，让高速生成不至于跑偏。

登录系统改 OAuth2 这个场景很典型：真正困难的不是加依赖、写回调，而是搞清楚原有认证链上的每个节点怎么配合。计划的价值不是文档，而是提前暴露错误方向。中大型需求默认先 Plan，小修复直接执行，这个尺度把握好，AI 编程的速度优势才能真正变成交付优势。

## 09、链接与概念说明
OAuth2 授权码模式：客户端先跳转到授权服务器，用户同意后带回授权码，客户端再用授权码交换访问令牌。改造时重点确认回调地址、state 参数和令牌存储。

Spring Security 的 SecurityFilterChain：过滤链是安全配置的核心。多个过滤器按顺序执行，自定义过滤器如果没有放行 OAuth2 回调路径，会直接拦截请求，这是最常见的坑。

Session 并发控制与固定攻击防护：表单登录改 OAuth2 时，Session 中用户对象的字段变化，可能导致前端解析失败，也可能让原有的并发 Session 策略失效。计划分析时需要把 Session 看作认证链的一部分。

测试路径：至少包含三条——认证成功、认证失败、state 校验失败。现有测试如果没有 state 校验失败的用例，就需要在计划中补齐。

参考建议：在实际改造前，先跑一遍项目的登录集成测试，把认证链相关的文件列表拉出来。这样即使不用任何自动化扫描，也能手动做一个最小版的影响面清单。

凌晨一点十七分，生产环境的登录接口开始成片报 401，我盯着屏幕手有点抖。三小时前，我还在跟同事说“这个 OAuth2 改造不难，加个依赖、改下配置就行”。我是老李，一个在后端摸爬滚打十年的程序员。今天想跟你聊一件反直觉的事：AI 编程最大的坑，很多时候不是它不会写，而是它写得太快。

《WorkBuddy Skills 实战》第5招 动手前先出计划

AI 编程的坑往往不是不会写，而是写太快。本文以登录改 OAuth2 为例，讲清计划先行如何减少返工与遗漏。

架构师

后端

编程语言

职业发展

AI编程返工率高源于生成过快，而非能力不足。以OAuth2登录改造为例，直接改SecurityConfig易致过滤器拦截、Session冲突等连环问题。create-plan通过仓库扫描、依赖图谱、影响面分析，在编码前预判风险并规划执行顺序，可大幅减少返工。中大型改动需先计划，小修复直接执行。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《WorkBuddy Skills 实战》第5招 动手前先出计划-腾讯云开发者社区-腾讯云

《WorkBuddy Skills 实战》第5招动手前先出计划

《WorkBuddy Skills 实战》第5招动手前先出计划

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《WorkBuddy Skills 实战》第5招 动手前先出计划

《WorkBuddy Skills 实战》第5招 动手前先出计划

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《WorkBuddy Skills 实战》第5招动手前先出计划

《WorkBuddy Skills 实战》第5招动手前先出计划