故事点在与 LLM 的第一次接触中就会失效

在每一家拥有成熟敏捷实践并决定增加 LLM 功能的公司，都悄然发生着这样一种失败模式：团队用故事点评估工作，将其分配到为期两周的冲刺（sprint）中，然后连续三个冲刺都报告“完成了 70%”，而工程经理则盯着那张拒绝下降的燃尽图发愁。没人撒谎。功能确实很难完成 —— 因为让故事点成为有用规划工具的条件，在 AI 功能中并不存在，而大家直到投入其中才察觉到这一点。

问题不在于工程师不擅长估算。问题在于故事点编码了关于软件工作本质的假设 —— 而 LLM 功能在结构上（而非偶然地）违反了这些假设。

故事点依赖的三个假设

故事点在以下三个条件大致成立时才有效：

1. 任务是确定性的。 你可以在开始之前想象出完成的状态。实现路径可能有不确定性，但“完成”的定义没有。
2. 速率是稳定的。 过去的产出可以预测未来的产出，因此一个平均得分为 40 点的团队可以承诺在每个冲刺中承担 40 点的新工作。
3. 需求在完成时冻结。 一旦功能发布，它就保持“已完成”状态。你不会在下个季度针对新的验收阈值重新评估它。

标准的 CRUD 功能满足这三点。而 LLM 功能一个都不满足。

非确定性打破了“完成”的定义

基于规则引擎构建的文档分类器要么分类正确，要么错误 —— 你可以编写一个二进制的验收测试。而基于 LLM 构建的文档分类器在你的测试集上可能有 87% 的准确率，周二可能是 91%，在模型提供商更新基础模型后变成 84%，并且在不同长度的文档桶中呈现出完全不同的错误分布。这些状态中没有一个能被清晰地定义为“完成”或“未完成”。

结果是，团队最终对同一个冲刺任务卡片产生了两种不兼容的理解。工程团队认为“完成”意味着功能已部署且没有崩溃。产品团队认为“完成”意味着用户对输出质量感到满意。QA 团队认为“完成”意味着评估套件通过了。这三种想法都是合理的，但没有一个是同一回事。

在实践中行之有效的解决方案是，在开始估算前，将明确的评估阈值作为验收标准写进工单中 —— 例如“在预留验证集上 f1 ≥ 0.87，且每次部署都要经过回归评估” —— 这被显式地写入工单。这不只是锦上添花的润色；这是让“完成”具有一致含义的唯一方法。在拥有这个标准之前，根本不应该对工单进行估算，因为没有什么稳定的东西可供估算。

研究阶段没有速率

冲刺速率（Sprint velocity）是一个产出指标。它在工作主要是执行类任务时有效 —— 即应用已知技术来交付你本可以提前完全确定的东西。ML 和 LLM 功能包含一个研究阶段，其路径是未知的：选择方法、运行实验、评估哪种提示词结构、检索策略或微调技术能真正提高评估效果，并丢弃那些无效的方法。

你不能用衡量执行速率的单位来估算研究产出，因为在开始之前，你不知道需要多少次实验才能找到可行的方法。这种未知不同于“这张工单可能是 3 点或 5 点”的那种未知。这种未知类似于“我不知道在得到数据支持之前需要测试多少个假设”。这些是本质上不同的不确定性。

一个花费了三个冲刺却无法将召回率提升到 0.71 以上的团队并不是慢。他们是在做研究。将其称为“冲刺的 40%”并把它贴在燃尽图上，并不能让它变成冲刺工作。

需求随模型而漂移

标准的敏捷开发假设需求由产品经理设定，经利益相关者批准，然后在功能发布前保持冻结。对于 AI 功能，当底层模型发生变化时，需求也会随之改变 —— 而这种变化发生的时间并不受你控制。

一个针对 GPT-4 Turbo 调优了摘要提示词的团队会发现，在提供商静默更新底层权重后，同样的提示词表现会有所不同。一个针对某种嵌入模型进行评估的检索系统，如果嵌入模型重新训练，系统性能就会下降。一个欺诈检测分类器会随着新产品、新市场或监管变化导致的交易分布转移而产生静默漂移 —— 而这些都不会出现在任何冲刺待办列表（backlog）中。

这些不是边缘情况。它们是生产环境 AI 系统的正常运行状态。将 LLM 功能视为“一旦发布即完成”是一种规划错误，而不仅仅是维护上的疏忽。

加载中…