尧图网页设计 
原文链接AI 辅助编程实战从需求边界到可审查交付开发中最容易出现的误解是只要把需求丢给 AI它就能交付一个功能。实际上AI 擅长整理上下文、生成候选方案、补全局部实现、解释报错和发现可疑点需求边界、技术取舍、风险判断、测试验证与最终合并责任仍然必须由人承担。下面用一个基于常见内部系统改编的案例跑完整个闭环。它不是某个具体公司的真实项目复盘但保留了团队开发中常见的权限、历史数据、接口兼容、测试与代码审查约束。案例给任务系统增加“批量归档”团队已有一个任务系统。任务完成后不会立即删除而是保留在“已完成”列表中。运营同学提出新需求当前项目的项目管理员可以一次选择多条已完成任务并归档归档后默认任务列表不再展示但具备该项目归档查看权限的管理员可在归档列表中恢复。这句话还不能直接开始写代码因为它没有明确权限范围、状态转换、重复请求和返回结果。先把需求翻译成可交付的边界可以让 AI 先做“需求质检员”复述已知条件列出歧义和潜在风险但最终规则必须由产品、开发或负责人确认。本例最终确认如下项目确认结果操作对象仅允许归档状态为completed且尚未归档的任务操作权限只有当前项目的项目管理员可操作成员只能查看操作范围单次最多归档 100 条且任务必须属于当前项目数据策略不物理删除写入archivedAt、archivedBy幂等性已归档任务再次提交时不报错、不重复写入并返回可识别原因返回结果返回成功数、跳过数以及可安全披露的跳过原因非目标本期不做自动归档、跨项目批量操作和归档导出可验收标准是管理员能归档本项目中符合条件的任务无权限用户不能产生写入未完成、已删除、跨项目或不存在的任务不会被错误归档重复点击不会产生重复副作用归档后默认列表、归档列表、分页和筛选结果符合既有规则。**人机分工很明确**AI 可以帮助暴露问题人必须决定规则。规则没有定下来再漂亮的代码也只是把猜测固化进系统。第一步先拆“小变更”不要索要“一整个功能”本例可以拆成六个任务确认数据模型归档字段、恢复字段和必要索引。定义接口契约请求参数、响应、错误和幂等行为。实现权限、项目归属和状态校验。实现批量更新并记录操作者与时间。调整默认列表和归档列表查询。补齐测试、变更说明、风险点和验证结果。可以要求 AI 每次只处理一个任务并固定返回修改哪些文件、依赖哪些假设、尚未覆盖哪些场景、应执行哪些验证命令。这样得到的是一系列可追溯的候选变更而不是一大段难以审查的代码。第二步让 AI 比较方案而不是替你做架构决定批量归档至少有两种实现方式。方案 A逐条读取并更新读取任务、逐条校验、逐条更新并汇总结果。优点是失败原因细缺点是数据库往返次数多并且要明确部分成功时的事务语义。方案 B按条件批量更新再计算结果先验证当前用户是否为该项目管理员再用“项目 ID 任务 ID 集合 已完成 未归档”的条件批量更新随后根据影响行数和补充查询计算成功、跳过结果。优点是通常更高效缺点是要额外设计逐条原因的查询和并发语义。本例选择方案 B因为单次最多 100 条且只要求汇总级结果。需要注意仅凭updateMany的影响行数通常不能区分“不存在”“跨项目”“未完成”和“已归档”如果接口承诺逐条原因就必须补充受控查询或调整接口契约。AI 可以比较复杂度、失败模式和索引需求但事务边界、ORM 能力、并发规则以及是否值得提前抽象必须由开发者结合现有代码库决定。为了一个归档功能新增通用规则引擎、事件总线或多层策略类可能只是过度设计。Google 的代码审查实践也强调应优先解决已经明确存在的问题而不是为想象中的未来需求堆叠复杂度。第三步把接口写成可验证的契约POST /projects/:projectId/tasks/archive Content-Type: application/json { taskIds: [task_101, task_102, task_103] }成功响应示例{ archivedCount: 2, skipped: [ { taskId: task_103, reason: ALREADY_ARCHIVED } ] }还要提前规定空数组、重复 ID、超过 100 条、无权限、跨项目、未完成、已删除或不存在、数据库失败以及请求期间发生并发恢复或状态修改时的行为。常见错误是只按 ID 更新遗漏projectId条件。权限、归属和状态应当同时出现在服务端的查询或更新条件中而不能依赖前端传参或 AI 的口头保证。伪代码可以接近const result await taskRepository.updateMany({ where: { id: { in: uniqueTaskIds }, projectId, status: completed, archivedAt: null }, data: { archivedAt: now, archivedBy: currentUser.id } });这段代码仍不完整它没有展示管理员身份验证、参数校验、错误映射、审计日志、逐条跳过原因和事务边界。第四步让 AI 写局部代码同时暴露假设较好的顺序是先解释仓库中相似功能再草拟服务方法签名人工确认接口和错误码后实现最小更新逻辑最后生成测试骨架和审查建议。每一步都要求 AI 标出假设例如假设TaskRepository已有支持条件更新的updateMany方法权限中间件已保证登录态未覆盖并发恢复任务与归档请求同时发生的情形。假设清单能把隐蔽的模型幻觉变成可检查项目。GitHub 对 AI 编程助手的说明也提醒模型建议不一定最优或完整使用者仍需验证输出。第五步测试不是让 AI“补几个用例”测试应从验收标准反推。可以先建立矩阵再让 AI 补充测试骨架、测试数据和反例测试维度关键场景预期结果正常路径管理员归档 3 个已完成任务3 条被归档默认列表不再出现权限普通成员发起归档无权限且不产生写入归属提交其他项目任务 ID不更新并按契约返回跳过或拒绝状态提交进行中的任务不归档并返回原因幂等已归档任务再次提交不重复写入结果可解释输入校验空数组、重复 ID、超过 100 条返回参数错误并发归档期间任务被恢复符合既定事务或条件更新约定查询回归默认列表、归档列表、分页筛选旧功能不受影响失败处理数据库异常或超时返回统一错误不泄露内部细节还可以让 AI 扮演“反例生成器”如果删除projectId条件哪条测试会失败如果漏掉archivedAt: null重复请求会怎样如果权限判断放在批量更新之后数据会发生什么好的测试不只是“跑绿”还要确认错误实现确实会让测试失败。Google 的审查指南建议在同一变更中检查生产代码及相应测试并确认断言有效、不会产生假阳性。第六步用失败的生成结果练习审查async archiveTasks(taskIds: string[]) { return this.taskRepository.updateMany({ where: { id: { in: taskIds } }, data: { archivedAt: new Date() } }); }这段代码可能通过最简单的成功测试但不能直接合并至少存在以下问题没有权限校验、项目归属限制、状态限制、幂等约束、操作者审计字段和可解释结果。它说明了一个关键现实局部答案“看起来合理”不等于符合业务、工程和安全约束。第七步把 AI 放进代码审查但不要把审批权交给它提交 Pull Request 后可以让 AI 总结改动、标出可疑空值路径、检查重复逻辑、解释失败流水线并提出候选问题但作者和人工评审者仍需判断是否修复、是否符合仓库约定以及是否可以合并。GitHub 相关文档应以当前产品能力和团队权限配置为准不能把 AI 的评论当成人工批准。AI 辅助代码审查清单正确性验收标准、权限、项目归属、状态、幂等和并发是否完整。可维护性是否沿用既有分层、命名和错误处理是否引入不必要抽象。安全与隐私是否遗漏后端授权日志、提示词和测试数据中是否包含密钥、令牌、生产数据或个人信息代理是否采用最小权限高影响操作是否保留人工确认。性能与数据规模是否存在 N1 查询条件字段是否需要索引批量大小和返回体是否合理。异常处理参数错误、无权限、状态冲突和系统错误是否区分是否泄露内部细节部分成功能否安全重试。测试覆盖是否验证数据库最终状态移除权限或归属条件时测试是否会失败。项目一致性API、错误码、日志、审计、文档、接口定义和前端调用是否同步变更是否便于回滚。OWASP 关于具备代理能力的 LLM 应用建议采用最小功能、最小权限和人工确认原则下游系统仍应独立完成授权校验不能相信模型自行判断权限。一页式工作流每次让 AI 参与开发都留下这些产物阶段阶段产物AI 可以做什么人必须确认什么通过条件需求澄清边界、非目标、验收标准、待确认问题复述需求、发现歧义业务规则与优先级每条验收标准可验证任务拆解小任务清单、依赖关系、风险排序拆分技术任务、列遗漏项粒度与顺序每项可独立测试或审查方案设计接口契约、数据变化、方案对比比较路径、生成草图架构取舍与兼容性符合现有约定局部编码小范围 Diff、假设清单编写样板、重构局部逻辑业务条件、权限与异常静态检查和测试通过测试调试测试矩阵、复现步骤生成骨架、解释报错边界和修复有效性错误可复现且修复通过代码审查PR 描述、风险点、审查记录总结改动、提出问题是否修复、是否合并人工审批和流水线通过最后的边界AI 可以加速但不能替你交付AI 辅助编程的效率不是让开发者少思考而是把重复整理、候选生成、代码解释和初步检查交给工具让人把时间集中在理解业务、做取舍、验证结果和承担责任上。真正的交付物不只是一段批量更新代码而是一组可追溯证据明确的验收标准、受约束的接口、可解释的异常处理、覆盖风险的测试、可审查的 Pull Request以及人工确认后的合并决定。可以从一个原则开始每次让 AI 生成或修改代码都要求它说明上下文、假设、未覆盖场景与验证方式每次准备合并都由人用测试和审查把这些回答逐一验真。参考资料GitHub DocsUsing GitHub Copilot to explore pull requestsGitHub DocsUsing GitHub Copilot code reviewGitHub DocsResponsible use of GitHub Copilot ChatGoogle Engineering PracticesWhat to look for in a code reviewNISTSecure Software Development FrameworkOWASPExcessive Agency 把 AI 放进一次合并请求：一个批量归档功能的交付闭环
原文链接AI 辅助编程实战从需求边界到可审查交付开发中最容易出现的误解是只要把需求丢给 AI它就能交付一个功能。实际上AI 擅长整理上下文、生成候选方案、补全局部实现、解释报错和发现可疑点需求边界、技术取舍、风险判断、测试验证与最终合并责任仍然必须由人承担。下面用一个基于常见内部系统改编的案例跑完整个闭环。它不是某个具体公司的真实项目复盘但保留了团队开发中常见的权限、历史数据、接口兼容、测试与代码审查约束。案例给任务系统增加“批量归档”团队已有一个任务系统。任务完成后不会立即删除而是保留在“已完成”列表中。运营同学提出新需求当前项目的项目管理员可以一次选择多条已完成任务并归档归档后默认任务列表不再展示但具备该项目归档查看权限的管理员可在归档列表中恢复。这句话还不能直接开始写代码因为它没有明确权限范围、状态转换、重复请求和返回结果。先把需求翻译成可交付的边界可以让 AI 先做“需求质检员”复述已知条件列出歧义和潜在风险但最终规则必须由产品、开发或负责人确认。本例最终确认如下项目确认结果操作对象仅允许归档状态为completed且尚未归档的任务操作权限只有当前项目的项目管理员可操作成员只能查看操作范围单次最多归档 100 条且任务必须属于当前项目数据策略不物理删除写入archivedAt、archivedBy幂等性已归档任务再次提交时不报错、不重复写入并返回可识别原因返回结果返回成功数、跳过数以及可安全披露的跳过原因非目标本期不做自动归档、跨项目批量操作和归档导出可验收标准是管理员能归档本项目中符合条件的任务无权限用户不能产生写入未完成、已删除、跨项目或不存在的任务不会被错误归档重复点击不会产生重复副作用归档后默认列表、归档列表、分页和筛选结果符合既有规则。**人机分工很明确**AI 可以帮助暴露问题人必须决定规则。规则没有定下来再漂亮的代码也只是把猜测固化进系统。第一步先拆“小变更”不要索要“一整个功能”本例可以拆成六个任务确认数据模型归档字段、恢复字段和必要索引。定义接口契约请求参数、响应、错误和幂等行为。实现权限、项目归属和状态校验。实现批量更新并记录操作者与时间。调整默认列表和归档列表查询。补齐测试、变更说明、风险点和验证结果。可以要求 AI 每次只处理一个任务并固定返回修改哪些文件、依赖哪些假设、尚未覆盖哪些场景、应执行哪些验证命令。这样得到的是一系列可追溯的候选变更而不是一大段难以审查的代码。第二步让 AI 比较方案而不是替你做架构决定批量归档至少有两种实现方式。方案 A逐条读取并更新读取任务、逐条校验、逐条更新并汇总结果。优点是失败原因细缺点是数据库往返次数多并且要明确部分成功时的事务语义。方案 B按条件批量更新再计算结果先验证当前用户是否为该项目管理员再用“项目 ID 任务 ID 集合 已完成 未归档”的条件批量更新随后根据影响行数和补充查询计算成功、跳过结果。优点是通常更高效缺点是要额外设计逐条原因的查询和并发语义。本例选择方案 B因为单次最多 100 条且只要求汇总级结果。需要注意仅凭updateMany的影响行数通常不能区分“不存在”“跨项目”“未完成”和“已归档”如果接口承诺逐条原因就必须补充受控查询或调整接口契约。AI 可以比较复杂度、失败模式和索引需求但事务边界、ORM 能力、并发规则以及是否值得提前抽象必须由开发者结合现有代码库决定。为了一个归档功能新增通用规则引擎、事件总线或多层策略类可能只是过度设计。Google 的代码审查实践也强调应优先解决已经明确存在的问题而不是为想象中的未来需求堆叠复杂度。第三步把接口写成可验证的契约POST /projects/:projectId/tasks/archive Content-Type: application/json { taskIds: [task_101, task_102, task_103] }成功响应示例{ archivedCount: 2, skipped: [ { taskId: task_103, reason: ALREADY_ARCHIVED } ] }还要提前规定空数组、重复 ID、超过 100 条、无权限、跨项目、未完成、已删除或不存在、数据库失败以及请求期间发生并发恢复或状态修改时的行为。常见错误是只按 ID 更新遗漏projectId条件。权限、归属和状态应当同时出现在服务端的查询或更新条件中而不能依赖前端传参或 AI 的口头保证。伪代码可以接近const result await taskRepository.updateMany({ where: { id: { in: uniqueTaskIds }, projectId, status: completed, archivedAt: null }, data: { archivedAt: now, archivedBy: currentUser.id } });这段代码仍不完整它没有展示管理员身份验证、参数校验、错误映射、审计日志、逐条跳过原因和事务边界。第四步让 AI 写局部代码同时暴露假设较好的顺序是先解释仓库中相似功能再草拟服务方法签名人工确认接口和错误码后实现最小更新逻辑最后生成测试骨架和审查建议。每一步都要求 AI 标出假设例如假设TaskRepository已有支持条件更新的updateMany方法权限中间件已保证登录态未覆盖并发恢复任务与归档请求同时发生的情形。假设清单能把隐蔽的模型幻觉变成可检查项目。GitHub 对 AI 编程助手的说明也提醒模型建议不一定最优或完整使用者仍需验证输出。第五步测试不是让 AI“补几个用例”测试应从验收标准反推。可以先建立矩阵再让 AI 补充测试骨架、测试数据和反例测试维度关键场景预期结果正常路径管理员归档 3 个已完成任务3 条被归档默认列表不再出现权限普通成员发起归档无权限且不产生写入归属提交其他项目任务 ID不更新并按契约返回跳过或拒绝状态提交进行中的任务不归档并返回原因幂等已归档任务再次提交不重复写入结果可解释输入校验空数组、重复 ID、超过 100 条返回参数错误并发归档期间任务被恢复符合既定事务或条件更新约定查询回归默认列表、归档列表、分页筛选旧功能不受影响失败处理数据库异常或超时返回统一错误不泄露内部细节还可以让 AI 扮演“反例生成器”如果删除projectId条件哪条测试会失败如果漏掉archivedAt: null重复请求会怎样如果权限判断放在批量更新之后数据会发生什么好的测试不只是“跑绿”还要确认错误实现确实会让测试失败。Google 的审查指南建议在同一变更中检查生产代码及相应测试并确认断言有效、不会产生假阳性。第六步用失败的生成结果练习审查async archiveTasks(taskIds: string[]) { return this.taskRepository.updateMany({ where: { id: { in: taskIds } }, data: { archivedAt: new Date() } }); }这段代码可能通过最简单的成功测试但不能直接合并至少存在以下问题没有权限校验、项目归属限制、状态限制、幂等约束、操作者审计字段和可解释结果。它说明了一个关键现实局部答案“看起来合理”不等于符合业务、工程和安全约束。第七步把 AI 放进代码审查但不要把审批权交给它提交 Pull Request 后可以让 AI 总结改动、标出可疑空值路径、检查重复逻辑、解释失败流水线并提出候选问题但作者和人工评审者仍需判断是否修复、是否符合仓库约定以及是否可以合并。GitHub 相关文档应以当前产品能力和团队权限配置为准不能把 AI 的评论当成人工批准。AI 辅助代码审查清单正确性验收标准、权限、项目归属、状态、幂等和并发是否完整。可维护性是否沿用既有分层、命名和错误处理是否引入不必要抽象。安全与隐私是否遗漏后端授权日志、提示词和测试数据中是否包含密钥、令牌、生产数据或个人信息代理是否采用最小权限高影响操作是否保留人工确认。性能与数据规模是否存在 N1 查询条件字段是否需要索引批量大小和返回体是否合理。异常处理参数错误、无权限、状态冲突和系统错误是否区分是否泄露内部细节部分成功能否安全重试。测试覆盖是否验证数据库最终状态移除权限或归属条件时测试是否会失败。项目一致性API、错误码、日志、审计、文档、接口定义和前端调用是否同步变更是否便于回滚。OWASP 关于具备代理能力的 LLM 应用建议采用最小功能、最小权限和人工确认原则下游系统仍应独立完成授权校验不能相信模型自行判断权限。一页式工作流每次让 AI 参与开发都留下这些产物阶段阶段产物AI 可以做什么人必须确认什么通过条件需求澄清边界、非目标、验收标准、待确认问题复述需求、发现歧义业务规则与优先级每条验收标准可验证任务拆解小任务清单、依赖关系、风险排序拆分技术任务、列遗漏项粒度与顺序每项可独立测试或审查方案设计接口契约、数据变化、方案对比比较路径、生成草图架构取舍与兼容性符合现有约定局部编码小范围 Diff、假设清单编写样板、重构局部逻辑业务条件、权限与异常静态检查和测试通过测试调试测试矩阵、复现步骤生成骨架、解释报错边界和修复有效性错误可复现且修复通过代码审查PR 描述、风险点、审查记录总结改动、提出问题是否修复、是否合并人工审批和流水线通过最后的边界AI 可以加速但不能替你交付AI 辅助编程的效率不是让开发者少思考而是把重复整理、候选生成、代码解释和初步检查交给工具让人把时间集中在理解业务、做取舍、验证结果和承担责任上。真正的交付物不只是一段批量更新代码而是一组可追溯证据明确的验收标准、受约束的接口、可解释的异常处理、覆盖风险的测试、可审查的 Pull Request以及人工确认后的合并决定。可以从一个原则开始每次让 AI 生成或修改代码都要求它说明上下文、假设、未覆盖场景与验证方式每次准备合并都由人用测试和审查把这些回答逐一验真。参考资料GitHub DocsUsing GitHub Copilot to explore pull requestsGitHub DocsUsing GitHub Copilot code reviewGitHub DocsResponsible use of GitHub Copilot ChatGoogle Engineering PracticesWhat to look for in a code reviewNISTSecure Software Development FrameworkOWASPExcessive Agency