Agent 写完代码、测试全绿，我为什么还是拒绝上线？

Agent 很快完成了“用户收藏与历史记录”功能，自动测试全部通过，但发布按钮最终没有被按下。

问题出在一处权限判断：它复用了现有内容查询接口，却没有完整区分普通用户、编辑和管理员。更危险的是，原有测试根本没有覆盖这组角色差异。换句话说，代码通过了测试，但测试验证的是一个不完整的需求。

这正是 Agent 进入真实项目后最容易制造的错觉：它会写代码、会跑命令、会给出一份漂亮的总结，于是团队下意识地把“能够执行”误认为“可以负责”。

能否交给 Agent，不取决于它“会不会做”，而取决于任务是否可验证、可回滚，以及出错后的影响范围是否可控。

先说明案例边界：本文以“给已有内容网站增加用户收藏与历史记录”为贯穿项目，展示完整工作流。由于没有提供可公开核验的仓库、PR、日志、监控截图和统计周期，本文不会虚构生产数据或冒充真实上线复盘。其中项目结构用于流程演示，数据部分提供可直接套用的记录方法；正式发布真实案例时，应替换为经过脱敏的原始证据。

一、别急着让 Agent 写代码，先画责任边界

这个示例项目采用常见的 Web 技术栈：前端页面、服务端接口、关系型数据库和 Git 仓库。需求看起来并不复杂：

• 登录用户可以收藏和取消收藏文章；
• 用户只能查看自己的收藏与历史记录；
• 历史记录自动写入，允许用户清空；
• 旧用户无须重新注册；
• 功能关闭后，不影响原有文章阅读。

一次完整变更通常涉及：

• 收藏按钮和个人中心页面；
• 收藏、取消收藏、查询历史记录等接口；
• 用户、文章与行为记录之间的数据关系；
• 权限校验、中间件和日志；
• 单元测试、接口测试与发布配置。

过去的人工流程很熟悉：产品把需求写在文档里，补充信息散落在会议记录和聊天群；开发先搜索仓库，再逐个确认调用链；测试依赖个人经验；上线后发生异常，大家靠 Git 记录和聊天记录还原现场。

Agent 的价值不是把所有人移出流程，而是接管其中高频、重复、边界清楚的机械劳动。

判断任务能否交给 Agent，只问四个问题

1. 输入和输出是否明确？

2. 结果能否通过测试、规则或数据验证？

3. 失败后是否容易暂停和回滚？

4. 错误是否会直接影响用户、资金、安全或合规？

据此可以划分三档权限：

这套规则比“相信哪个模型”更重要。模型再强，如果拿到了模糊需求、无限目录权限和生产写入能力，也只是把风险执行得更快。

二、需求拆解：让 Agent 找问题，不让它替业务拍板

Agent 在需求阶段最有价值的能力，不是“创造功能”，而是把散落的信息压缩成结构化任务，并主动暴露冲突。

可以把原始需求、会议记录、用户反馈和现有系统说明一起交给它：

请根据以下原始需求输出：
1. 已确认目标
2. 尚未确认的问题
3. 用户故事
4. 可验证的验收标准
5. 可能受影响的模块
6. 风险与回滚思路

不要自行补全业务规则。
所有推测必须标记为“待确认”。

对于收藏功能，Agent 可能生成以下待确认问题：

• 未登录用户点击收藏时，是弹出登录提示，还是先保存在本地？
• 删除文章后，收藏记录是否保留？
• 编辑和管理员能否查看其他用户的收藏？
• 历史记录保存多久？
• 清空历史是逻辑删除还是物理删除？
• 收藏数量是否对外展示？

这比直接生成代码重要得多。因为这些问题中的任何一个没有确认，都可能让后续测试建立在错误前提上。

在示例工作流中，Agent 首版方案把“管理员可查看所有收藏”当成了现有权限的自然延伸。人工审核必须否决这一推断：后台内容管理权限，不等于用户行为数据查看权限。

修改后的任务卡应明确写成：

• 用户只能查询自己的收藏与历史记录；
• 管理员默认没有跨用户查询权限；
• 涉及行为数据导出时，必须另行审批；
• 所有未确认规则不得进入代码实现。

本阶段的责任划分

• 资料归纳；
• 用户故事草案；
• 待确认问题清单；
• 验收标准草案；
• 模块影响与依赖梳理。

• 功能优先级；
• 目标用户定义；
• 数据口径；
• 权限和隐私边界；
• 风险接受与范围签字。

三、代码变更：把 Agent 关进“可验证沙箱”

需求确认后，也不应该直接说一句“帮我实现收藏功能”。

更安全的方式是先让 Agent 只读仓库，输出：

1. 相关目录和文件；

2. 现有接口与调用链；

3. 拟修改文件；

4. 测试计划；

5. 潜在兼容风险；

6. 需要人工确认的操作。

随后再通过任务配置限制它的活动范围：

task: add_favorite_feature
allowed_paths:
- src/features/favorite/**
- tests/favorite/**
forbidden_paths:
- config/production/**
- migrations/**
required_checks:
- npm run lint
- npm run typecheck
- npm test
human_approval:
- database_schema_change
- permission_change
- production_deploy

注意，migrations/ 被禁止修改，不代表功能永远不能改数据库，而是意味着：Agent 发现需要建表时必须停下来，由人确认数据结构、索引、备份与回滚方案。**

Agent 最容易犯的四类错误

• 为了完成一个按钮，顺手重构多个公共模块；
• 复用“看起来能用”的接口，却忽略权限语义；
• 只考虑新数据，不处理旧用户和空值；
• 测试只覆盖正常路径，没有覆盖越权、重复请求和服务异常。

因此，Review 不能只看最终页面是否能点。团队需要设置机械化门禁：

• 单元测试和接口测试；
• 类型检查与 Lint；
• 依赖和安全扫描；
• Diff 行数上限；
• 受保护目录规则；
• 数据库与权限变更检测；
• 禁止 Agent 直接合并主分支。

人工 Code Review 则集中判断机器难以确认的部分：架构是否合理、业务语义有没有被改写、异常时用户会看到什么、数据是否可能泄露。

四、测试与上线：测试全绿，不等于可以发布

Agent 很适合根据验收标准生成测试矩阵：

但有一个常被忽略的问题：测试用例通常继承需求理解。 如果需求阶段默认了错误的权限规则，Agent 可能同时生成错误代码和错误测试，最后得到一片“全绿”。

所以，Agent 可以扩大检查面，却不能自动获得发布权。

if tests_failed or security_scan_failed:
block_release()

if changes_permission or changes_database:
require_human_approval()

if rollback_plan is None:
block_release()

《AI 项目上线前人工审批清单》

• [ ] 变更文件、接口和数据表是否与任务卡一致？
• [ ] 是否修改登录、权限、支付或用户数据逻辑？
• [ ] 数据库变更是否完成备份和回滚演练？
• [ ] 是否覆盖未登录、越权、空数据和重复请求？
• [ ] 灰度范围和观察窗口是否明确？
• [ ] 哪些指标异常时必须暂停发布？
• [ ] 回滚由谁执行，预计恢复路径是什么？
• [ ] 日志和监控是否足以定位问题？
• [ ] 产品、开发和发布负责人是否显式确认？
• [ ] 是否确保 Agent 无法直接操作生产密钥？

自动化不必一步到位

• L0：Agent 只给建议；
• L1：Agent 生成内容，人类执行；
• L2：Agent 在测试环境执行，人类审批；
• L3：Agent 执行低风险操作，异常时自动暂停；
• L4：限定场景内闭环自动化。

对多数普通团队来说，先做到 L2—L3 更现实。全自动不是成熟的标志，出了问题能够自动停下来才是。

五、完整流程图：谁执行，谁审批，谁负责

flowchart LR
subgraph B["产品或业务负责人"]
B1["提交原始需求"]
B2["确认范围与业务规则"]
B3["批准灰度发布"]
B4["确定复盘优先级"]
end

subgraph A["Agent"]
A1["整理资料与待确认问题"]
A2["检索仓库与生成计划"]
A3["创建补丁并补充测试"]
A4["执行检查并汇总结果"]
A5["生成发布建议"]
A6["汇总日志与异常时间线"]
end

subgraph D["开发者"]
D1["审核任务卡"]
D2["审核架构、权限与兼容性"]
D3["检查 Diff 与 CI"]
D4["执行灰度和回滚"]
D5["判断根因并制定改进项"]
end

B1 --> A1 --> B2 --> D1
D1 --> A2 --> A3 --> A4
A4 --> D2 --> D3 --> A5
A5 --> B3 --> D4 --> A6
A6 --> D5 --> B4

classDef auto fill:#d9f7be,stroke:#389e0d,color:#000;
classDef approve fill:#fff1b8,stroke:#d48806,color:#000;
classDef manual fill:#ffccc7,stroke:#cf1322,color:#000;

class A1,A2,A3,A4,A5,A6 auto;
class D1,D2,D3,B2,B3 approve;
class D4,D5,B4 manual;

绿色代表 Agent 可执行，黄色代表必须人工审批，红色代表不应自主自动化。尤其是生产写入、权限修改和不可逆数据操作，不能由一句自然语言直接触发。

六、上线复盘：Agent 还原事实，人类解释原因

上线后，可以让 Agent 汇总：

• Git 提交与 PR；
• CI 和部署记录；
• 监控指标与错误日志；
• 灰度时间线；
• 客服反馈与问题工单；
• 回滚和修复操作。

它很擅长回答：

• 什么时间部署了哪个版本？
• 哪类请求最先出现异常？
• 异常是否集中在某个角色或接口？
• 发布前后有哪些配置发生变化？

但“发生了什么”不等于“为什么发生”。

根因可能来自需求表述、组织沟通、测试策略，也可能是负责人明知风险但接受了取舍。这些涉及责任、资源和业务判断的问题，不应该由 Agent 单独定性。

不要编“效率提升”，要保留原始记录

真实项目应按统一口径记录改造前后数据：

没有原始记录，就不要写“效率提升了多少”。更诚实的结论通常是：Agent 减少了检索、整理和重复检查，但团队增加了配置权限、补充测试、审核输出和维护上下文的成本。

发布时应补齐的六张证据截图

由于本文没有收到真实项目素材，不能伪造截图。正式案例建议补充：

1. 原始需求与 Agent 待确认问题；

2. Agent 输出的代码修改计划；

3. Git Diff 或 Pull Request；

4. 测试、类型检查与安全扫描；

5. 发布前人工审批界面；

6. 监控面板与复盘摘要。

截图必须遮挡 API Key、用户数据、内部域名、数据库连接信息和私有仓库内容。

七、《任务是否适合交给 Agent：四问判断表》

• [ ] 输入、输出和完成条件是否明确？
• [ ] 是否有测试、规则或数据可以验证？
• [ ] 失败后是否能够暂停和回滚？
• [ ] 错误影响是否局限在可控范围？

判断建议：

• 四项都满足：可进入绿色任务池；
• 前三项满足，但可能影响用户：Agent 执行，人工审批；
• 无法验证或无法回滚：先改造流程，不要自动化；
• 涉及资金、安全、权限与合规：人工决策，Agent 只读辅助。

八、可直接套用的 AI 工作流升级清单

如果你已经能在聊天窗口完成需求拆解，下一步可以把模板接入脚本、CI 或工作流工具。可前往 api.884819.xyz 查看接口和接入方式，先从“输入需求—返回结构化任务清单”这种只读场景开始。

8848AI 使用用户名和密码即可注册，无须邮箱验证；平台内置 AI 对话，注册后可直接使用。国产模型如 Deepseek、千问等完全免费，没有月租和订阅，其他服务按量付费。实践时仍建议使用测试项目、限制调用预算，并避免上传密钥、真实用户数据和未脱敏的私有代码。

真正成熟的 AI 工作流，不是让 Agent 获得无限权限，而是让每一次自动执行都有明确边界、验证方式、暂停条件和责任人。

这篇解决的是“哪些任务该交给 Agent”。但真正接入 Git 后，更难的问题会变成：它能读哪些目录、能执行哪些命令、什么时候必须停下来等人批准？

下一篇，我会继续拆解：《我把这份 AI 工作流清单真正接进了 Git：Agent 权限、提示词、CI 门禁和回滚配置全公开》，包括仓库白名单、任务模板、人工审批节点，以及一次完整的故障回滚演示。

#AIAgent #AI编程 #软件开发 #自动化测试 #DevOps #人工智能 #8848AI