AI 编程工具真正适合做什么？别让它直接接管架构决策
AI 编程工具现在很强，强到很多人第一次用 Codex、Claude Code 或 Cursor Agent 时，会有一种错觉：既然它能读仓库、改文件、跑测试、解释报错，那是不是可以直接把一个功能甚至一套架构交给它？
我的观点很明确：AI 很适合做有边界的执行工作，不适合在不了解业务约束时接管工程决策。
它可以帮你把代码读快，把重复劳动做掉，把测试补齐，把调用链查清楚，把小范围修改推进到可验证状态。但权限边界怎么定、数据模型怎么演进、发布策略怎么设计、哪些业务约束不能破，这些不是“代码补全”问题，而是责任问题。
AI 最擅长的是把上下文拉出来
真实项目里，很多时间不是花在写代码，而是花在找代码。
比如一个按钮点下去为什么没有权限，一个字段为什么前端拿不到，一个接口到底是新增还是替换，一个缓存为什么没有刷新。人当然也能查，但你要在路由、页面组件、service、controller、mapper、schema、测试之间来回跳。AI agent 的优势是它可以快速搜索、串文件、总结路径，再把关键证据摆出来。
这类任务非常适合交给 AI：
- 读一个陌生模块，画出入口、核心服务和数据读写路径。
- 查一个接口从前端按钮到后端 mapper 的完整调用链。
- 找某个字段在哪里被创建、转换、过滤、返回。
- 对比相似实现，确认当前代码应该沿用哪个本地模式。
- 根据测试失败和日志，缩小问题范围。
这些工作不是让 AI“拍脑袋”，而是让它当一个速度很快的代码检索和整理助手。它给出的结论仍然要能回到文件、函数和命令输出上。
小范围修改是 AI 的高性价比场景
AI 编程工具最舒服的场景，是目标明确、边界清楚、验收标准具体。
例如：
- 给已有 service 补一个缺失的空值处理。
- 按现有风格给某个 API 增加测试。
- 把一批组件从旧 UI 组件迁到新组件。
- 修一个表单重复提交的问题。
- 调整一个查询，避免明显的 N+1。
- 把散落的错误提示统一成项目已有格式。
这类任务有两个共同点：第一，它们能从现有代码里找到参照；第二，它们的正确性可以通过测试、构建、lint 或人工走查验证。
AI 在这里的价值不是“比资深工程师更懂系统”，而是它能不嫌烦地做细活。它会读相邻文件，模仿命名，批量改重复模式，跑检查，然后根据失败继续修。人要做的是设定边界、审 diff、确认行为符合业务。
一个好的任务描述应该像这样：
“只修改用户列表页的导出按钮权限判断。先查现有按钮权限工具怎么用，再改页面组件，补一个对应测试。不要改后端接口，不要重构权限模型。”
这比“帮我优化权限系统”有效得多。前者是可执行任务，后者很容易变成没有约束的架构幻想。
补测试、迁移样板、清理重复代码，很适合 AI
很多团队不爱写测试，不是因为测试没有价值，而是因为补测试经常很枯燥。AI 正好适合处理这类重复而需要细心的工作。
它可以根据已有测试风格，补几个核心路径：
- 成功路径是否返回正确数据。
- 权限不足是否拒绝。
- 重复提交是否被挡住。
- 空值、边界值、异常返回是否处理。
- 修改后是否保持旧行为不变。
迁移样板也是类似。比如把旧的表单组件换成新的设计系统，把旧的 API client 调用挪到统一 service，把一批页面的日期格式改成同一个 helper。人做这种事容易疲劳，AI 做起来很稳定，前提是你给它明确的迁移规则和验证命令。
但这里也有一个边界：AI 可以迁移样板，不应该顺手重新定义抽象。迁移过程中如果发现旧结构很乱，它可以提出建议，但不要让它在同一个任务里同时完成“批量迁移”和“重做架构”。这两件事的风险级别完全不同。
架构决策不能直接外包给 AI
架构不是把文件夹摆漂亮，也不是把代码拆成更多层。
架构决策背后有很多 AI 不天然知道的约束：团队规模、上线节奏、历史包袱、权限模型、数据库成本、审计要求、灰度能力、事故恢复方式、未来半年真正会做的业务。AI 如果只看到代码，很容易提出听起来正确但落地成本很高的方案。
比如它可能建议：
- 把单体拆成多个服务。
- 重写权限系统。
- 把当前数据库模型改成更“规范”的范式。
- 引入事件总线或 CQRS。
- 用一个新的状态机框架重做流程。
这些建议不一定错，但不能直接执行。因为真正的问题不是“这个方案是否高级”，而是“它是否值得、是否能迁移、是否能回滚、是否符合当前业务的失败成本”。
AI 可以参与架构讨论。更好的用法是让它列出现状、风险、替代方案和迁移步骤，而不是让它直接决定方向。你可以问：
“基于当前代码，权限判断现在分散在哪里？如果要收敛成统一授权层，最小迁移路径是什么？哪些接口风险最高？先不要改代码。”
这样 AI 是分析工具，不是架构负责人。
权限边界、数据模型、发布策略必须由人负责
有几类事情尤其不能交给 AI 直接拍板。
第一是权限边界。谁能看、谁能改、谁能导出、谁能审批、谁能给别人授权，这些决定一旦错了，不只是 bug，而可能是安全事故。AI 可以帮你查“现在有没有校验”，但不能替你决定“业务上应该允许谁做什么”。
第二是数据模型。表结构、唯一约束、软删除方式、状态字段、审计字段、幂等键，这些会长期影响系统演进。AI 很容易为了眼前功能生成一个看似够用的表，但没有考虑历史数据、并发写入、迁移脚本、回滚和报表需求。
第三是发布策略。什么时候灰度，怎么回滚，哪些配置要先发，数据迁移是否可重复执行，旧客户端是否兼容，这些是生产责任。AI 可以帮你写 checklist，但不能替你承担发布后果。
第四是业务不变量。比如订单金额不能被二次修改，提现审核不能绕过人工，管理员不能给自己提权，删除操作必须保留审计。这类规则必须由人明确写出来，再让 AI 围绕规则实现和验证。
更实际的协作方式
把 AI 当成一个执行力很强但没有组织记忆的队友，会更接近现实。
你应该给它：
- 明确目标：这次到底要修什么、加什么、验证什么。
- 明确边界：哪些文件能动，哪些模块不能碰。
- 明确参照：沿用哪个已有实现、哪个测试风格、哪个错误格式。
- 明确验收：要跑哪些命令，人工要看哪些页面或日志。
- 明确禁止项：不要重构、不要改接口语义、不要调整数据模型。
然后让它做它擅长的事情：读代码、找路径、改小块、补测试、跑检查、解释 diff。
如果任务本身需要架构判断，也可以让 AI 先做研究报告：当前实现是什么，痛点在哪里，有哪些方案，迁移成本多大，第一步怎么做。等人确认方向后，再把实施拆成小任务交给它。
结论
AI 编程工具真正的价值，不是替你成为架构师，而是把工程师从大量低价值的检索、搬运、样板和局部修补里释放出来。
它适合读代码、补测试、迁移样板、查调用链、做小范围修改。它不适合在不了解业务约束时直接接管架构、权限边界、数据模型和发布策略。
更成熟的用法不是“让 AI 负责系统”，而是“让 AI 加速可验证的执行，让人负责不可外包的判断”。