跟 AI 搭档写前端之后，我才明白：所谓“管 AI”，其实是在管这 5 件事

前一篇文章里我写了一句话好代码不是“问”出来的是“管”出来的。这句话听起来有点像经验之谈但如果只停在这里其实没什么用。到底在管什么难道每次都要写一大段提示词盯着 AI 一行一行改代码不是。我说的“管”不是把 AI 当成一个只会听命令的代码录入员而是把它放进一套正常的工程流程里。我们平时带人做需求也不会只说一句“帮我写个用户管理页面”然后等着第二天直接上线。至少要讲清楚目标、范围、项目现状和验收标准。AI 也一样。只不过它写得太快了。快到我们很容易把“已经输出代码”误认为“已经完成任务”。第一件事管目标不让任务停留在一句功能描述上“写一个用户列表页”这不是一个合格的工程任务只能算一个方向。列表给谁使用解决什么问题需要哪些搜索条件数据量大不大操作列有哪些按钮删除之后页码怎么处理空数据和接口失败时页面显示什么这些问题不明确AI 仍然可以写出代码而且通常写得还挺像那么回事一个搜索表单、一张表格、一组模拟数据再配上分页。问题是它解决的很可能不是我们真正要解决的任务。所以我现在判断一个任务能不能交给 AI第一步不是看提示词写得够不够漂亮而是看目标能不能被验收。我会尽量把目标写成这种形式在现有用户管理模块中增加按姓名和状态查询的能力。查询、重置、切换页码时数据状态要一致接口失败时保留现有查询条件并给出错误提示。这里没有华丽的提示技巧但它至少回答了三件事改哪里、改什么、完成后应该是什么状态。第二件事管范围防止 AI 顺手把半个项目都“优化”了AI 在修改代码时有一个很容易让人放松警惕的特点它经常会顺手帮你做更多。有时是补几个它认为必要的工具函数有时是把现有写法换成另一种风格还有时会连相邻组件一起重构。单独看每一处好像都有理由合在一起改动范围却已经远远超过原任务。前端项目尤其容易遇到这种问题。一个页面通常会牵涉组件、状态、接口、路由、权限和样式。只要边界没有讲清楚局部需求很快就会变成多文件改造。我通常会把范围分成三栏类型要说清楚的内容必须修改本次任务明确要求变化的文件或行为可以修改为完成任务允许调整的辅助代码不允许修改公共组件、接口协议、全局样式等不能顺手改变的部分这张表的价值不是限制 AI 发挥而是限制无关风险。需求越小越要控制修改面。一个搜索按钮的改动不应该带来整套请求封装的重写。第三件事管上下文让 AI 先理解这个项目而不是写一个“它熟悉的项目”很多人说 AI 写的代码“味道不对”。我觉得这个描述挺准确。代码可能能运行但命名不对组件用法不对弹窗封装不对接口调用也绕开了项目已有的一层。原因往往不是 AI 不会 Vue3也不是它不认识 Element Plus而是它不知道这个项目已经形成了什么约定。同样是一个分页列表不同项目的实现方式可能完全不同有的把查询条件和分页放在同一个响应式对象里。有的把分页单独管理。有的统一封装请求状态。有的要求所有弹窗经过公共组件。有的已经在本地 Skill 中沉淀了固定规范。如果这些上下文没有提供AI 最自然的做法就是补出一套“通用写法”。而通用写法放进一个成熟项目里往往就是新的不一致。Codex 官方也把AGENTS.md定位为给项目提供额外说明和上下文的入口。对我来说这类文件最适合放长期不变的规则当前任务的特殊边界则应该在这一次任务中单独说明。长期规则和临时任务不能混在一起。前者解决“一直应该怎么做”后者解决“这一次具体要做什么”。第四件事管过程用小步修改代替一次性豪赌当一个任务会影响多个文件时我不太愿意让 AI 直接从头改到尾。不是因为它一定会写错而是因为一旦方向错了改得越多后面越难判断问题从哪里开始。我更习惯把过程拆成几个可停下来的节点先阅读项目规则和相关代码。列出准备修改的文件以及每个文件的改动目的。检查调用关系确认影响范围。按计划完成最小修改。查看代码差异清理无关改动。运行项目已有的检查再做页面验证。这套过程看起来比“一句话生成页面”慢但它减少的是返工不是速度。前端开发中最麻烦的错误常常不是语法报错而是状态在某个操作顺序下不一致。例如先搜索、再翻页、然后重置页面到底回到哪一页编辑弹窗关闭后再次打开是否还保留上一次的校验状态。这些问题很难靠一次生成解决只能靠过程中的检查逐步兜住。第五件事管验收AI 说“完成”不代表真的完成我现在越来越在意“完成”的定义。代码写完了是完成吗编译通过了是完成吗页面打开没报错是完成吗都只能算其中一步。一个前端任务至少有四层验收验收层次主要检查什么代码层改动是否聚焦是否符合项目写法有没有明显副作用工具层类型检查、Lint、单元测试或构建是否通过页面层页面是否能正常渲染交互和状态是否符合预期业务层正常、异常和边界路径是否满足真实需求AI 可以协助执行其中很多步骤但“哪些结果可以接受”仍然是人的判断。比如一个接口失败后弹出错误提示AI 可能认为已经处理完成。但当前筛选条件要不要保留表格旧数据要不要清空按钮什么时候恢复可点这些没有统一答案要结合具体业务决定。这也是我认为 AI 暂时不能替代工程责任的地方它可以给方案、写实现、跑检查却不能替我承担错误决策上线后的结果。“管 AI”并不是多写几百字提示词把前面五件事合起来其实是一条很普通的工程闭环明确目标 → 限定范围 → 补足上下文 → 控制过程 → 验收结果我们过去也是这样管理需求、代码和交付只是 AI 把实现速度突然拉高以后流程中的缺口也被一起放大了。所以我现在不太迷信所谓“万能提示词”。提示词当然重要但它只是任务入口。真正决定结果的是项目有没有规则、任务有没有边界、修改有没有检查、最后有没有人验收。如果只让我保留一个最小版本我会在每次任务开始前问自己五个问题我能不能用一句话说清这次要解决的问题哪些地方允许改哪些地方不能动AI 是否已经看过项目中正确的参考实现中间在哪些节点需要停下来检查我准备拿什么证据证明任务真的完成了这五个问题比“请帮我写得专业一点”有用得多。下一篇我会继续往下落不谈抽象原则直接整理一份我会在 Codex 动手前使用的“前端任务约束清单”。它不能替你写需求但能明显减少任务开始之后反复纠偏。本系列持续更新主线只有一条AI 写前端代码重点不是让它写得更快而是让结果更可控。