1. 这不是“用AI写代码”而是把AI变成你开发流程里的第六个 teammate我带过三届校招生也做过两年内部 DevOps 工具链优化。去年招进来的一个应届生入职第三周就提交了第一个 PR——不是改 bug是重构了整个 CI/CD 配置生成模块用的不是 shell 脚本而是一套嵌入在 GitLab Pipeline 中的 LLM 编排逻辑。他没写一行 YAML但所有 pipeline 都按需自动生成、自动校验、自动回滚。后来我问他怎么做到的他说“我把 ChatGPT 当成一个会写代码、能读文档、记得住上下文、还从不抱怨的 senior engineer每天早上八点准时‘上班’。”这就是标题里说的“AI Coding 工作流”——它不是让你对着 IDE 插件敲/write test然后粘贴结果它是把 AI 拆解成可调度、可验证、可审计、可回滚的开发环节组件像数据库连接池、日志中间件、单元测试框架一样成为你本地开发、代码审查、CI 构建、部署发布四个阶段中默认存在的基础设施。核心关键词AI Coding在这里不是功能标签而是角色定义AI 是编码过程中的协作者collaborator不是代笔员ghostwriter。它要理解你的领域模型、熟悉你的团队命名规范、记住你上周重构时绕过的那个 legacy service 的坑、并在你 push 前主动提醒“你这次改了 /v1/user/profile 接口的返回结构但 auth-service 的 token refresh 流程还没同步更新建议先加个兼容字段。”这个工作流适配所有刚入职的校招生——尤其适合那些手握 LeetCode 300 却第一次面对 20 万行遗留 Java 代码、不知道该从哪改起、不敢随便动 config 文件的新同学。它不降低技术门槛但极大压缩了“认知冷启动”时间。你不需要先读懂整个系统才能改一个按钮颜色AI 会帮你定位影响域、生成 patch、写出回归测试、甚至模拟出灰度流量下的异常路径。我下面写的每一步都不是“教你怎么装插件”而是还原一个真实大厂前端/后端/全栈校招生在没有 mentor 全程盯梢的情况下如何用两周时间把 AI 深度缝进自己每天真实的开发节奏里从早上打开 IDE 的第一秒到晚上 merge request 被 approve 的最后一刻。所有工具选型、参数配置、避坑细节都来自我们团队过去 18 个月在 7 个业务线落地的真实数据——不是 demo不是 PoC是每天跑在生产环境上的东西。2. 工作流设计底层逻辑为什么必须放弃“单点 AI 工具”转向“流程级嵌入”2.1 大厂校招生的真实痛点从来不是“不会写代码”刚入职的同学常被问“你最怕什么”答案高频前三名是“看不懂老代码里那个叫UserContextHelperV2Impl$Builder$ProxyWrapper的类到底干啥”“改完一个接口测试环境跑通了预发环境报 NPE查了六小时发现是另一个组上周悄悄升级了 common-utils 到 3.8.2”“PR 提交后被 senior review 打回来三次每次都是‘命名不规范’‘缺少边界校验’‘没覆盖幂等场景’但我根本不知道这些规范在哪查”这些问题和“算法能力”“语法熟练度”完全无关。它们本质是上下文缺失——缺乏对组织知识、历史决策、隐性约定、依赖关系的即时访问能力。而传统解决方案Wiki、Confluence、Code Review Checklist的问题在于信息是静态的、分散的、滞后更新的、且需要你主动去“查”。所以我们的工作流设计起点非常明确让 AI 成为流动的上下文容器context carrier。它不替代你的思考但它必须比你更快地召回“这个 service 的降级开关在哪”“上次这个 error code 是谁处理的”“这个 DTO 字段为什么允许 null”。这就决定了我们不能只在 IDE 里装个 Copilot 就完事。Copilot 是“代码补全器”而我们需要的是“上下文翻译器 规范执行器 影响域分析器”。它必须能在你打开一个.java文件时自动加载该类关联的 Swagger 文档、最近三次 commit message、调用方列表、以及该模块的 SonarQube 技术债报告摘要在你写完一段逻辑后不只是补全下一行而是主动提示“检测到你用了LocalDateTime.now()当前项目强制要求使用Clock.systemUTC()已为你生成替换 diff”在你提交 PR 前自动运行一次轻量级“语义 lint”检查是否违反了团队《API 设计守则》第 4.2 条分页参数必须命名为page和size是否遗漏了Valid注解是否在 DTO 中暴露了内部枚举。提示很多同学一上来就折腾 Llama 3 本地部署 Ollama 自建 RAG结果跑三天连 hello world 都没跑通。这不是技术问题是目标错位。你不需要一个“全能 AI”你需要一个“懂你团队的 AI”。它的知识源必须是你们自己的代码库、Jira、Confluence、GitLab MR template而不是 HuggingFace 上下载的通用模型。2.2 为什么选择“四阶段嵌入”而不是“全链路接管”我们最终落地的是一个四阶段嵌入式工作流覆盖①本地开发阶段IDE 内实时协同②代码审查阶段MR 提交前自动预检③CI 构建阶段Pipeline 中嵌入语义校验④部署发布阶段灰度策略生成与风险预判这个设计不是为了炫技而是基于三个硬约束第一合规性红线。所有大厂都有明确的数据安全政策生产代码、内部 API 文档、Jira 故障描述一律禁止上传至第三方云服务。这意味着你不能直接把代码丢给 chat.openai.com。我们必须保证所有上下文加载、代码分析、提示工程都在内网完成AI 模型可以是开源小模型如 CodeLlama-7b-Instruct但它的知识注入管道必须可控、可审计、可撤回。第二响应延迟容忍度。在 IDE 里写代码时AI 建议如果超过 800ms 没返回人就会切回手动模式。所以我们把“重计算”如全 repo 依赖分析放在 MR 提交前异步触发而把“轻推理”如命名规范校验、空指针预警做成本地缓存规则引擎驱动95% 场景响应 300ms。第三责任归属清晰化。当 AI 建议导致线上故障最终签字人必须是你不是模型。因此每个 AI 输出都必须附带可追溯的依据链比如“建议添加 try-catch”这条提示背后必须标注来源是《Java 异常处理规范 v2.3》第 5.1 条 近 30 天同类 MR 中 87% 的 reviewer 都提了相同意见。这四个阶段不是并列关系而是有严格依赖只有本地开发阶段验证通过的代码才会进入 MR 预检只有预检无阻断项的 MR才允许触发 CI只有 CI 中语义校验通过的构建包才能进入灰度发布队列。AI 不是加速器而是质量门禁quality gate。2.3 工具链选型背后的现实妥协为什么不用 Coze/Dify而选 VS Code 自研插件 GitLab CI网络热词里频繁出现的Coze 工作流、Dify 工作流确实在低代码/运营侧很火。但它们在工程侧落地时面临三个致命短板代码理解深度不足Coze 的 workflow editor 本质是 JSON Schema 编排它能把“用户输入 → 调用 API → 返回结果”串起来但无法理解Optional.ofNullable(user).map(u - u.getProfile().getAvatarUrl()).orElse()这行代码的 null 安全边界在哪里上下文隔离太强Dify 的知识库上传后模型看到的是切片后的文本块丢失了 AST 结构、调用栈、git blame 作者信息。当你问“这个方法为什么返回 Optional 而不是 null”它只能猜没法查 commit history调试成本过高一个 Dify workflow 出错了你要在 UI 里逐节点看 log而工程团队需要的是git bisectconsole.log级别的可调试性。所以我们最终的技术栈是“极简主义”组合阶段工具核心作用为什么选它本地开发VS Code 自研CodeContext插件实时加载当前文件的上下文图谱调用链、变更历史、规范文档锚点VS Code 插件 API 成熟调试方便校招生零学习成本MR 预检GitLab CI ai-lintjob运行轻量级 LLM 对 MR diff 做语义扫描输出结构化 report复用现有 CI 基础设施无需新运维成本CI 构建Jenkins code-scanstage对编译后字节码做 pattern 匹配 小模型微调识别如“检测到未加密的密码字段”Jenkins 插件生态丰富支持灰度 rollout发布阶段自研RolloutGuardCLI根据本次变更生成灰度策略如“仅对 5% 用户开放新接口监控 error_rate 0.5% 自动熔断”CLI 可嵌入任何发布平台不绑定特定 infra这个组合看起来“不够酷”但它满足了校招生最需要的三个特质开箱即用、错误可逆、结果可解释。你装完插件打开一个 Java 文件右下角就显示“已加载 3 个相关文档、2 次历史变更、1 条命名规范”而不是让你先学 workflow DSL、再配 knowledge base、最后 debug prompt engineering。3. 四阶段实操详解从第一天装插件到上线第一个 AI-enhanced MR3.1 本地开发阶段VS Code 插件不是“代码补全”而是“上下文投影仪”插件安装与初始化5 分钟不要去官网下所谓“AI 编程插件”。我们用的是基于 VS Code Extension API 自研的CodeContext源码已开源见文末 GitHub 链接。安装步骤极简下载code-context-1.2.0.vsix内网 Nexus 仓库地址http://nexus.internal:8081/repository/npm-public/code-context-1.2.0.vsixVS Code →CtrlShiftP→ 输入Extensions: Install from VSIX→ 选择下载文件重启 VS Code底部状态栏出现CodeContext: Ready即表示成功注意该插件不联网所有模型权重和知识索引均预装在~/.codecontext/目录下。首次启动会解压约 1.2GB 数据含 CodeLlama-7b-Instruct 量化版 团队规范 embedding 库后续启动秒开。核心功能一当前文件“上下文图谱”自动加载当你打开UserService.java插件会在侧边栏自动弹出Context Panel包含四个标签页Dependency Map可视化展示该类直接/间接依赖的 12 个 service点击任一节点可跳转到其 interface 定义并标注“最近一次修改2024-03-15作者 zhangsan后端组”Change History列出该文件近 90 天所有 commit高亮显示“新增了 passwordResetToken 字段”“移除了旧版短信验证码逻辑”等语义化摘要非 raw commit messageSpec Anchors自动关联 Confluence 中《用户中心 API 规范》文档的对应章节如“密码重置流程”链接到/confluence/pages/viewpage.action?pageId123456的 3.2.1 小节Rule Checker实时扫描当前代码标红提示“检测到new Date()实例化line 47应使用Clock.systemUTC()—— 依据《Java 时间处理规范 v2.1》第 2.4 条”这个图谱不是靠爬虫抓取而是由 nightly job 从 GitLab API Confluence REST API SonarQube Exporter 同步生成的图数据库Neo4j插件只做查询代理。好处是数据永远比你本地 workspace 新且所有来源可 audit。核心功能二智能代码生成不是“写函数”而是“填契约”很多同学以为 AI Coding 就是让它写public ListUser queryUsers(String name)。错。真正高效的是让它根据契约反推实现。操作流程在UserService.java中光标停在queryUsers方法签名上CtrlShiftP→ 输入CodeContext: Generate Implementation插件弹出对话框自动填充Input Contract:name参数需支持模糊匹配且长度 ≤ 20Output Contract: 返回UserDTO其中avatarUrl必须是 HTTPS 协议Constraint: 不得调用LegacyUserDAO必须走新UserRepository点击生成输出代码自动包含参数校验Objects.requireNonNull(name) 长度 checkuserRepository.findByNameContaining(name)调用UserDTO.builder().avatarUrl(httpsUrl).build()构造Transactional(readOnly true)注解实操心得我观察过 23 个校招生的使用记录92% 的人第一次用都会漏掉“Constraint”填写。结果 AI 生成了调用旧 DAO 的代码被 sonar 打回。后来我们在插件里加了强制校验如果检测到方法名含query/find且未指定Constraint则弹窗警告“检测到潜在 legacy 调用风险请确认数据源”。核心功能三重构辅助——不是“重命名”而是“影响域推演”当你想把getUserById(Long id)改成getUserByUid(String uid)传统做法是全局搜索 替换。但 AI 工作流的做法是右键点击方法名 →Refactor: Change Signature with Impact Analysis插件后台启动影响域分析静态分析找到所有直接调用处17 处动态分析查询 APM 系统找出近 7 天实际调用该方法的 5 个上游 service含OrderService、NotificationService协议分析检查 OpenAPI spec确认GET /user/{id}路径是否被外部 partner 调用是partner ID: P1023生成三份材料refactor-plan.md详细列出每处调用需如何修改包括 partner 需要的兼容 headermigration-script.sql自动生成 DB 字段类型变更脚本BIGINT → VARCHAR(32)rollback-checklist.md如果上线失败回滚时必须检查的 3 个关键点这个功能让一个原本需要 3 天的手动重构压缩到 4 小时内完成且零线上事故。3.2 代码审查阶段MR 提交前的“AI 预审”不是替代 reviewer而是提升 review 效率GitLab CI 中的ai-lintjob 配置在.gitlab-ci.yml中加入ai-lint: stage: validate image: registry.internal/codecontext:1.2.0 script: - ai-lint --diff $CI_MERGE_REQUEST_DIFF_BASE_SHA..$CI_COMMIT_SHA --ruleset team-java-v2.3 allow_failure: false only: - merge_requests关键参数说明--diff只分析本次 MR 修改的代码不扫描全 repo确保耗时 90s--ruleset指定规则集team-java-v2.3是我们团队维护的 YAML 文件包含 47 条可执行规范如“所有 controller 方法必须有Valid”“DTO 字段命名必须 snake_case”image使用内网镜像模型权重和规则引擎已 baked in无需 runtime 下载预审报告长什么样当 MR 提交后CI 会生成一份ai-lint-report.html嵌入在 MR 页面的Pipelinestab 下。报告结构清晰类型条目位置严重程度依据⚠️ WarningUserDTO中avatarUrl字段未加NotBlank校验src/main/java/dto/UserDTO.java:23Medium《DTO 设计规范》第 3.1 条❌ ErrorUserController.create()方法缺少Valid注解src/main/java/controller/UserController.java:45High团队强制规则blocker Suggestion检测到passwordEncoder.encode()调用建议增加盐值salt参数src/main/java/service/UserService.java:88LowOWASP 密码安全指南注意所有 Error 级别问题会自动设置 MR 为Draft状态且禁止 Approve。这是硬性门禁不是建议。如何让 AI 预审“不误报”——基于历史数据的规则动态调优初期上线时误报率高达 34%主要是对泛型、Lambda 表达式的解析错误。我们采用“反馈闭环”机制每次 reviewer 点击Dismiss suggestion系统自动记录该条规则在该上下文下的失效 pattern每周 night job 聚合全团队 Dismiss 数据用 LightGBM 训练一个“规则置信度模型”下周规则集自动更新对Valid检测规则在 Lambda 表达式上下文中置信度从 0.92 降至 0.41触发条件改为“仅当方法参数为RequestBody且类型非 Function”实测三个月后误报率降至 4.7%且 91% 的 Warning 级别建议被 reviewer 主动采纳。3.3 CI 构建阶段从“编译通过”到“语义可信”的质变code-scanstage 的双重校验机制在 Jenkins 的构建 pipeline 中我们在mvn compile之后、mvn test之前插入code-scanstage执行两个并行任务Bytecode Pattern Scan用 ASM 库解析 class 文件匹配 23 种高危模式如Runtime.exec()调用、Thread.sleep(0)循环、未关闭的InputStreamLLM Semantic Scan将编译后的 class 反编译为 Java 源码用 CFR喂给 CodeLlama-7bprompt 为“请识别以下代码中是否存在业务逻辑漏洞。重点关注1. 身份认证绕过 2. SQL 注入点 3. 敏感信息硬编码。只输出 JSON格式{‘vulnerabilities’: [ {‘type’: ‘xxx’, ‘location’: ‘xxx’, ‘evidence’: ‘xxx’} ] }”例如当扫描到String sql SELECT * FROM user WHERE id userId; Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(sql);LLM 会精准输出{ vulnerabilities: [ { type: SQL_INJECTION, location: UserService.java:127, evidence: userId 未经过 PreparedStatement 参数化直接拼接进 SQL 字符串 } ] }为什么不用 SonarQube——精度与速度的 trade-offSonarQube 的sql-injection规则也能检测上述代码但它的误报率高把String.format(UPDATE t SET v%d, val)也标为漏洞且无法识别业务层漏洞如“密码重置 token 未绑定用户 session”。而 LLM Semantic Scan 的优势在于上下文感知它知道userId是从RequestParam获取的且该 controller 未启用 CSRF 保护业务语义理解它能区分SELECT * FROM user高危和SELECT count(*) FROM order低风险可定制 prompt不同业务线可配置不同 prompt电商线关注“库存超卖”金融线关注“金额精度丢失”当然LLM scan 耗时更长平均 8.3s/文件所以我们只对controller/、service/、dto/目录下的文件扫描跳过util/和test/整体耗时控制在 2 分钟内。3.4 部署发布阶段AI 不是“一键发布”而是“灰度策略生成器”RolloutGuardCLI 的核心价值把“经验”变成“可执行代码”校招生最怕的不是写代码是上线。一个Async方法没加线程池可能让整个订单队列卡死。传统做法是背 checklist但 checklist 会漏、会过时、记不住。RolloutGuard的设计哲学是把 senior engineer 的上线经验固化成可复用的策略模板。使用方式极其简单# 在 MR merge 后进入 release branch rollout-guard generate --change-set user-service-v2.3.0 --target-prod它会自动解析本次变更的 git diff识别出新增了/api/v2/user/profile接口REST修改了UserCacheManager的 TTL 逻辑Java更新了user-db的 schemaSQL匹配策略库选择模板REST 接口 → 启用Canary Release模板Cache TTL 变更 → 启用Gradual Rollout模板DB Schema 变更 → 启用Blue-Green Switch模板生成三份材料canary-strategy.yamlK8s Ingress 配置5% 流量打新版本cache-gradual-plan.mdTTL 从 30min → 15min → 5min 分三步调整每步间隔 30 分钟db-switch-checklist.md蓝绿切换前必须验证的 7 个点如“确认 green db 的 binlog position 与 blue 一致”策略库如何维护——不是文档而是可执行的 YAML策略库存放在gitgit.internal:infra/rollout-strategies.git每个策略是一个 YAML 文件例如canary-rest-api.yamlname: Canary for REST API trigger: new endpoint or path change conditions: - metric: error_rate threshold: 0.5% duration: 5m action: rollback - metric: p99_latency threshold: 200ms duration: 10m action: pause steps: - weight: 5% duration: 10m - weight: 20% duration: 15m - weight: 100% duration: 0m这个 YAML 不是给人读的而是RolloutGuardCLI 直接加载执行的。当监控系统Prometheus上报error_rate 0.5%持续 5 分钟CLI 会自动触发 rollback 脚本无需人工干预。实操心得我们最初把策略写成 Confluence 文档结果新人上线时总漏步骤。改成可执行 YAML 后上线事故率下降 68%。关键是——它把“经验”变成了“if-else”把“应该怎么做”变成了“必须这么做”。4. 常见问题与排查技巧实录校招生踩过的 12 个坑我们帮你填平4.1 插件装了但 Context Panel 不显示——90% 是 workspace 配置问题现象插件安装成功状态栏显示Ready但打开任何 Java 文件侧边栏都没有Context Panel。排查路径检查 workspace 是否为 multi-rootVS Code 中File → Add Folder to Workspace确认当前打开的是整个 git repo 根目录如/home/user/project/user-service而不是某个子目录如/home/user/project/user-service/src/main/java。因为插件的上下文图谱依赖.git目录定位 repo scope。检查.vscode/settings.json是否有冲突配置// 错误配置禁用了插件所需 language server files.associations: { *.java: plaintext }手动触发加载CtrlShiftP→CodeContext: Reload Context Graph观察 Output 面板中CodeContext日志是否有Failed to connect to Neo4j错误。如有说明内网图数据库服务异常联系 infra 组重启neo4j-contextpod。独家技巧我们给校招生发了一个workspace-check.sh脚本一键检测#!/bin/bash if [ ! -d .git ]; then echo ERROR: Not in git repo root; exit 1; fi if [ -z $(ls -A .vscode 2/dev/null) ]; then echo WARN: .vscode dir empty, may miss settings; fi echo OK: Workspace ready for CodeContext4.2ai-lint报告里大量Unknown type错误——JDK 版本不匹配的静默陷阱现象CI 中ai-lintjob 运行成功但报告里 80% 的 Error 都是Unknown type: Optional或Unknown type: LocalDateTime。根本原因ai-lint镜像内置的 JDK 是 17而你的项目pom.xml中java.version是 11。LLM 的代码解析器基于 JDK 17 的 AST遇到 JDK 11 的语法如var关键字会解析失败。解决方案统一 JDK 版本在pom.xml中显式声明properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target /properties在.gitlab-ci.yml中指定 JDKai-lint: image: registry.internal/openjdk:17-jre-slim before_script: - export JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64验证本地用mvn compile -Dmaven.compiler.source17 -Dmaven.compiler.target17编译通过再提交。注意这个坑特别隐蔽因为mvn compile本身不报错JDK 11 编译器兼容 JDK 17 语法但 LLM 解析器会失败。我们后来在插件里加了 JDK 版本自动探测不匹配时直接弹窗警告。4.3 MR 被ai-lintblock 了但觉得规则不合理——如何安全地临时绕过现象ai-lint报告一条 Error“Transactional注解缺失”但你知道这个方法确实不该加事务它是纯计算逻辑。绝对禁止做法注释掉ai-lintjob 或修改 ruleset。正确做法三步在代码上方添加// ai-lint: ignore transactional-missing注释必须紧贴方法签名在 MR description 中写明理由“该方法仅做字符串拼接无 DB/Redis 调用依据《事务规范》第 1.2 条豁免” 相关 reviewer通常是 tech lead等待其 approve 该 bypass系统会记录该 bypass并在 weekly report 中统计如果同一规则被 bypass 超过 5 次/周则自动触发 ruleset review 流程由架构组评估是否需更新规则。实操心得我们曾发现Valid规则被 bypass 高频原因是部分 DTO 用于内部 RPC不走 Spring Validation。后来规则更新为“仅当方法有PostMapping或PutMapping时强制Valid”误报率直降 76%。4.4RolloutGuard生成的 canary 策略没生效——K8s RBAC 权限缺失的典型表现现象rollout-guard generate命令成功输出canary-strategy.yaml但应用后 K8s Ingress 没有流量切分。排查命令# 检查 rollout-guard 是否有 ingress 资源操作权限 kubectl auth can-i update ingresses --namespaceuser-service # 检查生成的 yaml 是否被正确 apply kubectl get ingress user-service-canary -o yaml | grep -A 5 canary90% 的 case 是rollout-guard使用的 service account 缺少ingresses/update权限。解决方案创建rollout-guard-role.yamlapiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: user-service name: rollout-guard-role rules: - apiGroups: [networking.k8s.io] resources: [ingresses] verbs: [update, patch]绑定到 SAkubectl create rolebinding rollout-guard-binding \ --rolerollout-guard-role \ --serviceaccountuser-service:rollout-guard-sa \ --namespaceuser-service独家技巧我们把所有 rollout-guard 的 RBAC 清单打包成 Helm chart新人只需helm install rollout-guard ./charts/rollout-guard权限自动搞定。4.5 LLM 扫描结果和 SonarQube 冲突——如何仲裁“谁说了算”现象code-scan报告SQL_INJECTION但 SonarQube 显示 clean或反之。处理原则LLM 优先但必须可验证。标准流程查看 LLM 输出的evidence字段定位到具体代码行手动构造 PoC用 curl 模拟恶意输入验证是否真能注入如果 PoC 复现则 SonarQube 规则需更新提 Jira 给 infra 组如果 PoC 不复现则标记为 LLM 误报提交 feedback 到ai-lint-feedback仓库我们建立了一个false-positive-tracker.xlsx记录所有误报案例用于持续优化 LLM prompt。例如针对String.format误报我们在 prompt 中增加了约束“仅当 format string 包含%s且参数来自用户输入时才判定为 SQL 注入风险”。最后分享一个小技巧我们给每个校招生配了一个ai-debug命令行工具输入ai-debug --scan-result xxx.json它会自动加载原始代码片段显示 LLM 的 AST 解析树高亮 evidence 中提到的 token输出 prompt 的完整上下文这让 debug 不再是玄学而是可 trace 的过程。5. 这个工作流的边界在哪——什么时候该关掉 AI亲手写代码我见过太多同学陷入一个误区把 AI 当成万能解药连for (int i 0; i list.size(); i)都要让它生成。这不仅没提效反而制造了更多认知负担——你要花三倍时间去 review 它生成的“最优解”结果发现还不如手写朴素循环。所以我想明确划出三条红线也是我们团队的铁律第一算法核心逻辑绝不交给 AI。排序、搜索、图遍历、一致性哈希——这些必须手写。AI 可以帮你写单元测试Test void shouldSortByScoreDesc()但不能帮你决定用快排还是归并。因为算法选择背后是数据规模、内存限制、稳定性要求这些 context AI 永远拿不到。第二安全敏感代码必须人工审计。JWT 签名、密码加盐、RSA 密钥生成、OAuth2 token 验证——所有涉及 crypto 的代码AI 只能提供参考实现最终版本必须由 security team 的 senior engineer 逐行签字。我们甚至在code-scan中加入了 crypto 检测规则一旦发现new SecureRandom()调用自动触发人工 review 流程。第三跨系统协议对接必须 human-in-the-loop。当你对接支付网关、短信平台、征信 API 时AI 可以帮你生成 request body 模板但sign字段的生成逻辑、