大模型能力边界：独立开发者实战中的「能做到」与「做不到」
一、模型能力的「示范效应」与实战落差
过去18个月，大模型的能力演示视频和 benchmark 分数，给独立开发者创造了一种「几乎什么都能做」的预期。你看到模型能写诗、能解数学题、能生成可运行的代码、能做复杂的推理。这些 demonstration 本身是真的——模型确实能这些事。
但当你把模型能力放进一个真实产品的场景中，你会发现一个系统性的落差：模型在「单次、独立任务」上表现很好的能力，在「需要多步推理、需要状态保持、需要对之前输出做精确修正」的产品场景中，表现会大幅下降。
这个落差不是模型的「缺陷」，而是两种不同的任务复杂度。理解这个落差，才能在使用大模型做产品时，做出合理的能力边界判断，而不是要么过度乐观（什么都想用 AI 做），要么过度悲观（觉得 AI 完全不可用）。
二、当前大模型「能做到」的四类任务
基于过去一年的实战经验，当前大模型在以下四类任务中，表现稳定到可以放进生产环境。
第一类：单轮明确指令的内容生成。你给模型一个明确的指令（如「为这款 Markdown 编辑器写一个产品描述，突出极简设计和实时预览功能，300 字以内」），模型能稳定地生成符合要求的内容。这类任务的特点是：指令明确、输出格式可预期、不需要模型「记住」之前的多轮对话内容。对于独立产品，这类任务最适合用 AI 做自动化——如自动生成产品描述的初稿、自动生成邮件回复的模板、自动做内容摘要。
第二类：基于明确标准的分类和提取任务。你给模型一段文本和明确的分类标准（如「这段用户反馈属于以下哪一类：bug 报告、功能请求、使用疑问、其他」），模型能稳定地做出分类。类似地，信息提取任务（如「从这段简历中提取姓名、邮箱、和工作年限」）也是模型稳定能做的。这类任务的关键是「标准明确」——如果分类标准本身模糊，模型的输出也会不稳定。
第三类：代码补全和局部重构建议。在给定足够上下文（当前文件、相关的一两个文件）的情况下，模型能稳定地补全函数、生成测试用例、或给出局部重构建议。这类任务已经成为很多独立开发者的日常——AI 编码助手在这类任务上的表现，已经到了「可以依赖」的程度。
第四类：基于结构化数据的自然语言问答。如果你给模型提供了结构化的数据（如一张数据表的内容、或一份 API 文档），然后问它基于这些数据的问题，模型的回答准确度是高的。这类任务的关键是「数据在上下文中」——模型不需要「记住」训练数据中的信息（那些信息可能过时或不准确），而是基于你提供的上下文来回答。
三、当前大模型「做不到」或「做不好」的三类场景
理解模型能做什么，同样重要的是理解模型「做不到」或「做不好」的场景。在这些场景中，把模型能力放进生产环境，可能会导致用户体验的不稳定。
第一类：需要精确执行多步逻辑链的任务。你让模型「先分析这段代码的性能瓶颈，然后给出重构方案，最后给出重构后的完整代码」。这个任务包含三个步骤，且后一步依赖前一步的输出。在实战中，模型可能在第二步就偏离了第一步的结论，导致最终输出的重构方案和最初的性能瓶颈分析不一致。这类任务不是「完全做不到」，而是「输出稳定性不够高」——有时能做对，有时做不对，且不容易提前预测哪次会对。
第二类：需要精确遵循复杂格式约束的长文本生成。你让模型生成一个包含特定 JSON 结构、特定 Markdown 格式、和特定长度限制的文档。对于短文本，模型能较好地遵循格式约束；但对于长文本（如 2000 字以上），模型在生成后半部分时，可能会「忘记」前半部分提到的格式约束，导致输出格式不一致。这类场景的应对策略是「把长文本拆成多个短文本分别生成，然后做后处理合并」。
第三类：需要最新知识或实时信息的任务。大模型的训练数据有时间截止点。如果你问它「昨天发布的 React 新版本有什么特性」，它无法给出准确答案——它的训练数据里没有这个信息。这类场景的解决方案是 RAG（检索增强生成）——在让模型回答之前，先从外部数据源（如官方文档、新闻 API、或实时搜索）检索最新信息，然后把检索到的信息作为上下文提供给模型。
四、独立开发者的能力边界判断框架
对于独立开发者，判断一个功能是否应该用大模型来实现，可以用一个简单的框架：「稳定性阈值」判断。
这个框架的核心是：先定义这个功能的「可接受的错误率」。有些功能，错误率 5% 是可接受的（如自动生成的产品描述草稿，用户会自己修改）；有些功能，错误率 1% 都不可接受（如自动执行退款操作的逻辑）。然后，用真实场景的测试用例去测模型在这个任务上的实际错误率。如果实际错误率低于可接受的错误率，这个任务适合用 AI 自动化；如果实际错误率高于可接受的错误率，这个任务应该保留人工处理，或设计「AI 做初稿 + 人工审核」的混合流程。
另一个判断维度是**「任务是否涉及关键决策」**。如果 AI 的输出会直接影响用户的资金（如自动定价、自动退款）、或直接影响用户的数据安全（如自动配置权限、自动删除数据），即使模型的错误率很低，也应该保留人工审核环节。AI 应该做「执行」，而不是「决策」——或者更准确地说，AI 可以做「建议性的决策」，但最终的决定权应该在用户或人工审核环节。
五、总结
大模型的能力边界，在「单次独立任务」和「真实产品场景」之间存在系统性落差。当前模型稳定能做的任务包括：单轮明确指令的内容生成、基于明确标准的分类提取、代码补全和局部重构建议、以及基于结构化数据的问答。
模型做不好或稳定性不够的场景包括：需要精确执行多步逻辑链的任务、需要精确遵循复杂格式约束的长文本生成、以及需要最新知识的任务。独立开发者在判断是否用 AI 实现某个功能时，应该用「稳定性阈值」框架——先定义可接受错误率，再用真实测试用例测模型的实际表现，然后做决策。
理解模型的能力边界，不是「不用 AI」，而是「在正确的地方用 AI」，让 AI 的能力真正转化为用户价值，而不是转化为用户投诉。
