AI 项目的工期，为什么总是估不准

做 AI 功能最常见的翻车姿势，是工期估得太乐观。原因几乎总是同一个：把 AI 当成了一个普通的接口调用，以为「接个模型、跑个 prompt、出一段文字」两天就完了。

实际上，AI 功能的工期里，模型调用只占 10%，剩下 90% 是不确定性管理。

三个最常见的低估来源

「模型返回了正确结果」和「这个功能能交付给用户用」之间，隔着一整条链：

这些都不是"写代码"的时间，是试错的时间。真实项目里，AI 部分的 prompt 调优往往占掉整个项目周期的一半以上。

传统功能有明确的正确/错误。AI 功能没有——它有"这次对、下次可能不对"。

所以 AI 项目必须多出一件事：一套能跑的评测集。

没有评测集，AI 功能就变成"我觉得还行"，上线后用户说不好用，你也不知道该改什么。评测集不是可选项，它是 AI 功能的验收标准。

这些时间不在开发者的工时里，但真实存在于你的日历上。一个"2 周上线"的项目，如果里面要接支付 + 上小程序商店，实际日历可能是 4～5 周。

别用"功能点 × 天"，用这个：

`` 开发工期 = 核心链路（1 周，能跑通） + 打磨期（按不确定因素定） + 外部依赖等待（并行） ``

核心链路 1 周：选最小的、但真的贯通的链路——真实调用模型、真实存数据、真实在页面上跑一遍。哪怕丑。这一步的目的是尽早暴露最大的不确定性。

打磨期：这一段的长度，取决于三件事：

外部依赖等待：和开发并行，但要单独列出来给决策者看。

这是最反直觉的一点：AI 项目的预算不能按工时线性给。

因为打磨期的不确定性是乘性的——你没法用"多派一个人"来压缩 prompt 调优的轮次。数据准备、评测标注、效果对齐，这些环节加人也没用。

所以 AI 项目的报价应该是：

这样双方都不承担无限的不确定性。

第 5 个最容易被跳过，也最容易在项目末尾爆炸。

把需求贴进诊断台，它会先做一件事：指出你的需求内部哪些地方互相矛盾。

比如"1 月底上线 + 预算 5 万 + 需要接小程序支付 + 要求完整文档"，这四条单看都合理，凑一起就是一个排期风险。工具会把这类型冲突直接指出来，再给出分阶段建议与验收标准。

把需求原文贴进去，会得到：可行性判断 · 需求内部的矛盾点 · 方案要点与取舍 · 风险清单 · 阶段拆分与验收标准 · 工期与报价区间。

评估完还能一键生成分享链接，发给老板或同事确认需求——链接里的联系方式会自动隐去，30 天失效。

---

一句话总结：AI 项目的工期不该按功能估，该按不确定性估。核心链路跑通之后，剩下的时间是花在学习"什么算对"上面的——这部分压缩不了，只能诚实地写进计划。