第 21 章 · 反馈怎么不丢
老板先看这一句： 项目跑起来后，业务方一定会不停提新想法，最怕你「随口一说、技术随手就做」，一周的节拍瞬间被冲乱、老需求收不了尾。你要让团队把反馈和变更管成机制：所有新需求先进「变更池」，别插队；收了的反馈必须喂回下一周的任务，别成死档案。你作为老板要护住这条闭环——它决定项目是越跑越准，还是越跑越乱。
让节拍真正转起来
上一章给了阶段和节拍的框架，但框架不会自己转。让它转起来，靠三样具体的战术动作:开对会、拆对任务、管住变更。 这一章把这三件事讲透——它们是 Agent 落地工程师每周实操里花时间最多、也最容易做走样的部分。
一、开对会:少而准的几场会
很多团队一说「敏捷」就开一堆会,反而把节拍拖垮。Agent 落地工程师小队要的不是多开会,而是每场会都有明确的目的和产出。围绕一个周节拍,真正必要的会就这么几场:
| 会议 | 时机 | 目的 | 产出 |
|---|---|---|---|
| Kickoff | 项目启动 | 对齐场景卡、范围、指标 | 一致的目标认知 |
| 周目标会 | 每周一 | 定本周目标、拆任务 | 本周任务清单 |
| 周 Demo | 每周五 | 演示进展、收反馈 | 具体反馈 + 新失败样本 |
| 失败样本复盘 | 每周（可并入 Demo） | 把答错的 case 归档 | Golden Dataset 增量 |
| 门禁评审 | 上线前 | 逐条过上线清单 | 上线 / 不上线的决定 |
| 阶段复盘 | 每阶段末 | 检查出口门槛 | 是否进入下一阶段 |
注意几点:周会尽量短、聚焦;失败样本复盘可以直接并进周 Demo,不必单开;真正重的只有 Kickoff、门禁评审和阶段复盘这几场「关口会」。判断一场会该不该开,就看它有没有一个明确产出——没有产出的会,砍掉。
二、拆对任务:把模糊需求切成能干的活
一个场景需求(比如「差评聚类预警」)是没法直接开工的,它太大、太笼统。Agent 落地工程师的一项核心手艺,是把它拆成一类类具体、可分派、可完成的任务。
一个好用的拆法,是按「任务类型」切:
| 任务类型 | 例子 |
|---|---|
| 数据任务 | 把评论数据拉出来、清洗、去重 |
| 模型 / Prompt 任务 | 写分类提示词、定分类口径 |
| 工具 / 集成任务 | 接采集工具、接推送到企业 IM |
| 权限任务 | 确认数据访问权限、划人审边界 |
| 评估任务 | 准备 Golden Dataset、写跑分 |
| 用户培训任务 | 教业务方怎么看周报、怎么调阈值 |
按类型拆有两个好处:一是不漏——尤其权限任务和评估任务,是新手最容易忘、上线时最容易爆雷的;二是好分派——不同类型的活可以对应到小队里不同的帽子(第 4 章)。
拆完的每个任务,都应该小到「一两天能做完、且能验证做没做完」。太大的任务要继续拆,否则它会变成一个永远显示「进行中」的黑洞。
每个任务还要写清 Definition of Done。一个任务只有同时满足三条，才算完成：
- 有可查看的产物，比如配置、页面、脚本、样本表、评审记录。
- 有验证证据，比如跑分、截图、日志、AIBP 确认。
- 有明确 Owner，知道后续谁维护。
例如「完成评论分类提示词」不是一个好完成定义；「分类提示词 v0.3 已提交，Golden Dataset 回归准确率 82%，高风险样本 0 漏报，AIBP 确认分类口径」才是。
三、管住变更:一个「变更池」
项目一跑起来,业务方一定会不停提新想法:「能不能也加个 X」「这个能不能改成 Y」。这些想法本身是好事——说明他在用、在想。但如果随口一说就随手就做,一周的节拍分分钟被冲乱,你会永远在追着新需求跑,老需求却收不了尾。
解法是一个简单的机制:需求变更池。所有新提的东西,先进池子,不直接插队。然后给每一条分类:
| 类型 | 含义 | 处理 |
|---|---|---|
| 缺陷 | 本来就该对、现在错了 | 优先修 |
| 优化 | 现有功能做得更好 | 排优先级 |
| 新需求 | 全新的功能点 | 评估价值再排 |
| 范围扩大 | 超出本次 PoC 边界 | 多半推到下一阶段 |
| 指标变化 | 验收标准变了 | 要重新对齐、慎重 |
分类的意义在于:它把「情绪化的临时插单」变成「有依据的排期决策」。业务方提的时候,你不说「不行」,也不说「马上做」,而是说「记下了,归到优化类,我们评估后排进合适的一周」。这既保护了节拍,又让业务方感到被认真对待。
变更入池后，还要标注它影响六要素里的哪一项：目标、数据、工具、权限、指标、路径。影响「权限」和「指标」的变更最敏感，通常要重新对齐场景卡；只是影响「工具」或「路径」的变更，可以由 Agent 落地工程师在技术侧消化。
第 12 章那个「周报能不能按品类分开」的请求,走的就是这个流程——它被判为「优化」,评估后纳入当周。关键不是做不做,而是走没走流程。
四、让一切流转成闭环
会议、任务、变更,最终要拼成一个闭环,让信息能一圈圈转起来、项目能一轮轮变好:
用户反馈 / 失败样本
↓
归档、分类(变更池 + Golden Dataset)
↓
拆成本周任务
↓
做 → 周五 Demo
↓
收新反馈 / 新失败样本
↓
(回到起点,进入下一周)这个闭环转得越顺、越快,项目质量爬升越快。Agent 落地工程师在小队里最重要的作用之一,就是当好这个闭环的「传动轴」——保证反馈不丢、任务不漏、变更不乱,让每一周的产出都踩在上一周的反馈上。
📍 场景示例：客服 Agent 跑两周，老陈的「顺手加一个」差点拖垮节拍
客服 Agent 试点跑起来第二周，老陈看首次响应从 18–24h 压到 2h 很满意，顺口又提了三个：「差评能不能自动喂给选品周报」「广告图也用 AI 出」「Listing 也接进来」。FDE 以前会当场应下，结果本周 Demo 一个没做完、老需求也卡住。这次他全放进变更池：前两条标「新需求 / 范围扩大」推到下一阶段，只有「差评喂周报」被判为「优化」，评估后纳入当周。
| 维度 | 改造前 | 改造后 |
|---|---|---|
| 临时需求处理 | 随口就做、直接插队 | 全进变更池、按类排期 |
| 本周收尾 | 3 个新想法，0 个做完 | 1 个优化落地，2 个推后 |
| 老需求进度 | 被冲乱、收不了尾 | 按节拍正常收口 |
老板决策点： 你要护住这条闭环——凡影响权限或验收指标的变更，必须重新对齐场景卡，不许技术侧偷偷改。 ——对应 → 巩固 L4
常见坑
- 会开太多、太长。 把「敏捷」做成「天天开会」,节拍反被会议拖垮。每场会先问「产出是什么」。
- 任务拆得太粗。 一个写着「做分类功能」的任务挂一周,永远显示进行中。拆到一两天粒度。
- 忘了权限和评估任务。 只拆看得见的功能任务,上线时才发现没人管权限、没人准备评估集。
- 变更不入池,随口就做。 一周节拍被临时插单冲垮,老需求收不了尾。
- 闭环断在归档。 收了反馈、记了失败样本,却没喂回下一周的任务——信息成了死档案,不产生改进。
本章产出
老板行动点： 你要求团队用「变更池」管住所有临时需求、用闭环让反馈流转回下一周，并明确一条规矩：影响权限和验收指标的变更必须重新对齐场景卡，不许技术侧偷偷改。
往交付包里放两样东西:一张本周任务清单(按六类任务拆)和一个需求变更池(带五类标签)。
周清单与变更池模板见 附录 E。
成熟度自检
- [ ] 我能把一个场景需求按六类任务拆到「一两天可完成」的粒度(→ L4)
- [ ] 我能用变更池管住临时需求、用闭环让反馈流转回下一周(→ 巩固 L4)