最近我越来越怕一种场面。
你让 Agent “做一个会员系统”，它一句问题都不问，转身就开始写。数据库表有了，支付接口接了，页面也挺漂亮。半小时后，它端出一套完整系统，唯一的问题是：这不是你想要的会员系统。
代码报错反而好办。错误需求被高质量实现，才是真的费钱。
Agent 太能干以后，含糊会变得更危险
以前需求没说清，开发会停下来问：按月订阅还是一次买断？谁能取消？退款怎么算？
现在模型补全能力越来越强。你没说的部分，它会根据“常见做法”自动补上。每一个选择单看都合理，拼起来却可能完全偏离业务。
这也是 Matt Pocock 那套工程 Skills 里，我最喜欢 grill-me 的原因。它不是让 Agent 更快开工，而是强迫它在开工前，把真正需要人拍板的决策问出来。
事实能查的，让 Agent 自己查。只有业务取舍、风险偏好和验收标准，才交给人决定。
先问清楚，再把共识钉住
一轮需求澄清不能只留下聊天记录。
对话很长，模型会遗忘；换一个 Agent，理解又会漂移。更稳妥的做法，是把确认后的内容沉淀成一份规格说明：解决什么问题，谁会使用，哪些行为算成功，哪些明确不做。
这里最重要的不是文档格式，而是“决策不可偷偷变化”。
比如会员系统至少要钉住这些问题：
- 商品是订阅、买断，还是两者都有；
- 权益在哪一刻生效，又在哪一刻失效；
- 退款、取消和续费失败如何处理；
- 管理员可以做什么，普通用户不能做什么；
- 哪几条流程必须用自动化测试证明。
需求一旦写成规格，后面的任务拆分、开发和评审才有共同的尺子。
不要横着铺功能，要竖着打通一条路
很多项目的任务清单看起来很专业：先建所有表，再写所有接口，再做所有页面。
这种拆法的问题是，做了两周仍然没有一条完整流程能跑通。到最后才发现支付状态、权限模型和前端交互根本对不上。
更实用的方式是“竖切”。先用最小范围打通一条真实路径：用户购买一个方案，支付成功，权益生效，后台能查到记录。跑通以后，再扩展退款、续费和多方案。
这样每一小步都有可见结果，也能更早暴露错误假设。
评审要分两条线
Agent 写完代码以后，评审不能只问“能不能运行”。
第一条线是工程标准：有没有明显安全问题，错误处理是否完整，测试是否可靠，代码是否可维护。
第二条线是需求符合度：它实现的是不是规格里约定的东西，有没有偷偷加戏，有没有漏掉边界。
这两条线必须分开。代码写得再漂亮，做错了需求也不能合并；功能看起来能用，安全和回滚没有着落，同样不能上线。
我现在会先给 Agent 一道刹车
以后遇到稍复杂的任务，我会先加一句：
在我确认需求之前，不要修改文件。先列出会影响方案的关键决策；能通过代码、文档或公开资料确认的事实请自行调查，只向我询问必须由业务方决定的问题。最后把确认结果整理成规格，并列出明确不做的范围。
这句话不会让模型变笨，恰恰相反，它把模型的能力放在了更值得用的地方。
AI 写代码越来越快，人的价值就更靠前了：定义问题、做取舍、设边界、验结果。
真正成熟的工作流，不是让 Agent 一收到命令就冲出去，而是让它知道什么时候必须先停下来。
