教程目标

本教程要帮助读者完成一套可落地的大模型辅助编程排障流程。目标不是单纯比较模型能力，而是围绕真实工程交付，解决三个问题：如何在有限年度预算内选择合适模型，如何让模型参与顽固缺陷修复，如何把修复结果验证到可交付状态。

通过本教程，读者应能够完成以下任务：

1. 建立以 Token 成本和工程排障交付率为核心的模型选型方法。
2. 将模糊缺陷描述转化为模型可执行的任务单。
3. 使用大模型完成缺陷复现、根因假设、代码修改、验证建议与回滚方案设计。
4. 在隔离环境中执行修复结果，并通过测试、日志和监控确认效果。
5. 将大模型应用于前端落地页生成、接口联调说明和页面验收。
6. 建立成本台账，记录输入、缓存命中、输出、重试次数和实际交付结果。

本教程适合独立开发者、运维人员、技术负责人、企业研发团队以及需要控制 AI 工具预算的团队阅读。尤其适合面对存量系统、跨模块调用、偶发缺陷、长时间未修复问题、前端页面快速搭建等场景的人员。

适用场景

这套方法适合以下典型场景：

• 存量项目中存在长期未解决、影响交付的顽固缺陷。
• 缺陷涉及多个文件、多个接口或多个配置项，人工阅读成本较高。
• 团队预算有限，需要在模型效果与调用成本之间取得平衡。
• 需要快速生成营销落地页、后台管理页面、表单页或数据展示页。
• 需要把自然语言需求转化为页面结构、接口调用逻辑和验收清单。
• 需要在不引入额外人力的情况下，提高代码审查、日志分析和回归验证效率。

不适合的场景包括：未脱敏的生产数据直接送入模型、强实时控制系统、缺少测试基线的关键业务链路、无法接受外部模型调用的高敏感数据场景。此类场景应先完成数据脱敏、权限隔离、审计留痕和内部合规评估。

前置准备

1. 明确任务边界与验收标准

在调用模型之前，必须先把问题定义清楚。大模型擅长在明确约束下给出修改建议，但不适合承接含糊目标，例如“帮我修好系统”“让页面更好看”“提升稳定性”。这些描述无法形成验收标准。

建议先建立一份缺陷单，至少包含：

• 缺陷标题：一句话说明问题。
• 现象描述：用户看到什么错误，系统表现什么异常。
• 复现步骤：最少操作步骤，最好能稳定复现。
• 期望结果：修复后应该达到什么状态。
• 实际结果：当前错误状态是什么。
• 日志摘要：错误堆栈、接口返回、异常码、关键字段。
• 影响范围：涉及哪些页面、接口、模块、配置或数据流。
• 不可变约束：不能修改数据库结构、不能引入新依赖、不能影响旧版本兼容。
• 验收标准：测试通过、日志消失、页面可正常打开、接口返回符合预期。

只有任务边界清楚，后续提示词才能稳定，成本才能可控。

2. 准备最小必要上下文

大模型虽然具备较强代码理解能力，但并不代表应该把全部代码一次性提交。过多上下文会带来三个问题：Token 费用上升、关键信息被噪声淹没、模型更容易生成不相关修改。

建议按以下优先级收集材料：

1. 错误日志和异常堆栈。
2. 直接报错的代码文件。
3. 与报错相关的接口定义和字段结构。
4. 最近一次变更说明或提交记录摘要。
5. 相关配置项，例如环境变量、路由规则、权限配置、缓存配置。
6. 单元测试、集成测试或接口测试用例。
7. 页面截图或用户操作路径说明。

如果代码量较大，可以先让模型生成摘要，再把摘要作为后续排障输入。摘要应包括模块职责、关键函数、依赖关系、异常路径和最近改动。

3. 建立预算模型

在年度预算约 1.7 万元的场景下，不能只关注模型效果，还要关注每次调用的费用结构。通用计费通常包括三类：

• 输入 Token：用户提交给模型的内容。
• 缓存命中 Token：重复上下文被缓存后，通常费用更低。
• 输出 Token：模型生成的代码、说明、测试结果或页面结构。

可以用如下公式估算单次任务成本：

单次任务成本 = 输入 Token 数量 × 输入单价 + 缓存命中 Token 数量 × 缓存单价 + 输出 Token 数量 × 输出单价

实际使用时，还需要加上重试、追问、二次验证和多轮修复产生的额外成本。因此，建议设置单任务预算上限、单日预算上限和月度预算上限。

4. 准备隔离验证环境

模型生成的修复方案不能直接进入生产环境。必须先在隔离环境中验证。隔离环境可以是测试分支、测试容器、预发布环境或独立验证空间。最低要求是：可以执行构建、运行测试、查看日志，并且不会污染正式数据。

验证环境应具备：

• 可运行的测试套件。
• 可查看的日志输出。
• 可回滚的代码版本。
• 可模拟的输入数据。
• 可观察的接口返回或页面表现。
• 可记录的构建结果和错误信息。

5. 做好数据脱敏

如果项目涉及用户信息、账号信息、密钥、令牌、商业数据或内部配置，必须先脱敏。可以替换为示例值、占位符或模拟数据。提示词中应明确禁止模型输出真实密钥、真实账号、真实用户数据和内部地址。

实施步骤

步骤一：把模糊问题转成缺陷单

不要直接把“这个页面坏了”“这个接口偶尔报错”交给模型。应先整理成结构化缺陷单。这样有两个好处：一是模型可以基于事实推理，二是后续验证有标准。

缺陷单模板如下：

• 缺陷编号：例如 BUG-20261024-001。
• 缺陷标题：例如内容分发页面偶发空白。
• 现象描述：用户在特定条件下打开页面后出现空白。
• 复现步骤：进入页面、触发请求、等待加载、观察结果。
• 期望结果：页面正常渲染，接口返回成功。
• 实际结果：页面空白，控制台无明确错误或仅提示数据为空。
• 日志摘要：接口耗时、返回字段、异常码。
• 影响范围：内容分发页、列表接口、缓存配置。
• 约束条件：不修改数据库结构，不改变前端路由规则。
• 验收标准：连续刷新多次无空白，接口返回完整字段。

这一步是后续所有工作的基础。没有缺陷单，模型容易生成泛泛建议。

步骤二：采集最小必要上下文

根据缺陷单收集材料。目标是让模型理解“哪里出错、为什么出错、如何验证”。

采集时建议遵循四个原则：

1. 只提交与当前缺陷直接相关的文件。
2. 日志优先于源码，因为日志能定位实际执行路径。
3. 接口结构优先于页面细节，因为接口错误往往影响页面表现。
4. 配置项要谨慎提交，避免暴露敏感信息。

如果上下文较长，可以按模块拆分：

• 模块一：页面入口与渲染逻辑。
• 模块二：接口请求与返回处理。
• 模块三：缓存或数据读取逻辑。
• 模块四：异常处理与兜底逻辑。

每一部分都应有简要说明，避免模型误解。

步骤三：选择调用策略

不同任务适合不同调用策略。

场景一：单点缺陷。
例如某个函数空值判断错误、某个字段映射错误。此类问题适合单轮调用。输入一次，要求模型给出最小修复。

场景二：多文件缺陷。
例如接口返回结构变化导致页面异常。此类问题适合多轮调用。第一轮让模型分析可能根因，第二轮要求生成修复方案，第三轮根据测试结果修正。

场景三：需要执行验证的缺陷。
例如构建失败、测试失败、页面白屏。此类问题应采用“模型建议 + 人工执行 + 日志回填”的闭环。

在预算敏感场景下，优先使用单轮调用解决明确问题。只有在第一轮失败时，才进入多轮修复。这样可以减少重复 Token 消耗。

步骤四：设计排障提示词

提示词应包含角色、背景、目标、材料、约束和输出格式。不要只说“帮我修复代码”。

通用提示词模板如下：

你是一名资深软件维护工程师，擅长定位线上缺陷和偶发问题。请基于以下材料修复缺陷。

任务背景：
这里是缺陷单、日志摘要、相关代码片段和配置说明。

修复目标：
定位根因，并给出最小修改方案。

约束要求：

1. 只基于提供材料推理。
2. 信息不足时，列出最少需要补充的信息。
3. 不得引入未经验证的新依赖。
4. 不得修改与缺陷无关的代码。
5. 输出必须包含根因假设、修改位置、修改内容、验证步骤和回滚方案。

这个模板的关键是把“推理边界”和“输出结构”固定下来。这样模型不容易跑题，也方便后续自动解析结果。

步骤五：要求模型输出可验证方案

模型输出不能只是“修改这里”。应要求输出以下内容：

1. 根因假设：为什么会出现该缺陷。
2. 影响范围：修改可能影响哪些模块。
3. 最小修改：只改必要代码。
4. 验证步骤：如何确认修复成功。
5. 回滚方案：如果修复失败，如何恢复。
6. 风险说明：是否存在并发、缓存、权限、兼容性风险。

例如，对于偶发空白页问题，模型可能给出以下方向：请求返回数据结构变化、缓存读取为空、异步渲染未完成、异常兜底缺失、字段映射错误。每个方向都需要能被测试或日志验证。

步骤六：在隔离环境中执行修复

拿到模型建议后，不要直接合并。应先在测试环境中应用修改，然后执行验证。

验证顺序建议如下：

1. 格式检查：修改是否只涉及目标文件。
2. 构建检查：代码能否通过构建。
3. 单元测试：相关测试是否通过。
4. 集成测试：接口和页面是否联动正常。
5. 日志检查：原错误日志是否消失。
6. 页面检查：页面是否恢复预期表现。
7. 回归检查：其他相关功能是否受影响。

如果验证失败，进入下一步回环。

步骤七：失败回环

修复失败并不可怕，关键是把失败信息重新喂给模型。回环输入应包括：

• 原始缺陷单。
• 上一轮模型输出。
• 实际修改内容。
• 构建或测试失败信息。
• 日志差异。
• 页面表现截图说明。

提示词可以写成：

上一轮修改未通过验证。以下是失败日志和测试结果。请只基于新增信息修正方案，不要扩大修改范围。

通过回环，模型可以从“猜测式修复”转向“证据式修复”。这也是提高交付率的关键。

步骤八：人工复核

即使模型修复成功，也必须进行人工复核。重点检查：

• 是否引入新的依赖。
• 是否修改了数据库结构。
• 是否影响权限校验。
• 是否影响旧版本兼容。
• 是否产生性能问题。
• 是否存在安全风险。
• 是否有更简单的实现方式。
• 是否符合团队代码规范。

大模型可以提出方案，但最终交付责任仍在开发者。

步骤九：记录成本与交付结果

每次任务完成后，应记录：

• 缺陷编号。
• 使用模型数量。
• 输入 Token 数量。
• 缓存命中 Token 数量。
• 输出 Token 数量。
• 调用次数。
• 总耗时。
• 是否一次修复成功。
• 是否进入回环。
• 最终测试结果。
• 实际费用估算。

这些数据可以用于后续模型选型。选型不要只看跑分，而要看两笔账：Token 计费成本，以及真实工程排障的交付率。

配置说明

上下文长度配置

上下文长度决定了模型一次能读取多少代码、日志和文档。实际配置时，不应盲目追求超长上下文。建议根据任务拆分：

• 单文件缺陷：只提交目标文件和错误日志。
• 跨文件缺陷：提交入口文件、调用链文件和接口定义。
• 配置类问题：提交配置项说明和加载顺序。
• 页面类问题：提交页面结构、接口返回、字段映射和异常处理。

如果上下文过长，可采用摘要方式压缩。摘要应保留关键路径、关键变量和关键异常。

输出长度配置

输出长度影响费用，也影响可读性。建议要求模型输出结构化内容，而不是长篇解释。对于修复类任务，可以限制为：

• 根因假设不超过 3 条。
• 修改点不超过 5 处。
• 每处修改只给必要代码。
• 验证步骤不超过 6 步。
• 不输出无关重构建议。

这样可以减少输出 Token，也方便人工审查。

超时与重试配置

复杂缺陷可能需要较长时间推理。建议设置分级超时策略：

• 简单代码解释：较短超时。
• 单点修复：中等超时。
• 多轮排障：较长超时。
• 批量代码分析：异步任务处理。

重试次数不宜过多。通常 1 到 3 次即可。超过重试次数仍失败，应转入人工分析，避免持续消耗预算。

缓存配置

缓存命中可以降低重复上下文成本。建议对以下内容进行缓存：

• 项目说明。
• 模块职责。
• 接口结构。
• 常见日志格式。
• 团队编码规范。
• 固定提示词模板。

注意：缓存内容不能包含敏感信息。配置中应明确缓存过期时间和访问权限。

日志与审计配置

调用日志应记录任务编号、提示词版本、模型名称、输入摘要、输出摘要、验证结果和费用估算。对于敏感内容，应脱敏后再记录。日志保存周期应根据合规要求设置。

预算告警配置

建议在云服务控制台或内部管理系统中设置预算告警。告警维度包括：

• 单任务费用超过阈值。
• 单日费用超过阈值。
• 月度费用达到预算的 70%、90% 和 100%。
• 单个缺陷修复超过预设调用次数。
• 输出 Token 异常增长。
• 缓存命中率异常下降。

告警的目的不是限制研发，而是帮助团队及时发现问题。

示例说明

缺陷单示例

缺陷标题：内容分发页面偶发空白。
现象描述：用户在快速刷新页面时，列表区域偶发空白。
复现步骤：打开页面，连续刷新 5 次，触发接口请求。
期望结果：页面正常显示列表。
实际结果：部分刷新后列表为空。
日志摘要：接口返回成功，但数据字段为空。
影响范围：内容分发页、列表组件、数据缓存逻辑。
约束条件：不修改接口返回结构，不引入新缓存组件。
验收标准：连续刷新 20 次无空白，接口数据完整。

提示词示例

你是一名资深软件维护工程师。请基于以下缺陷单和日志，定位页面偶发空白的根因。只基于提供材料分析。输出必须包括：根因假设、最小修改、验证步骤、回滚方案。不得引入未经验证的新依赖。

通用流程伪代码

输入 = 缺陷单 + 日志摘要 + 相关代码片段
上下文 = 整理并脱敏(输入)
响应 = 调用模型(上下文)
方案 = 解析结构化输出(响应)

如果 方案缺少验证步骤：
重新提示并要求补全验证步骤

如果 方案包含敏感信息：
拒绝输出并记录审计事件

修改 = 应用最小补丁(方案)
结果 = 执行隔离测试(修改)

如果 结果通过：
进入人工复核
否则：
将失败日志回填模型，进入下一轮

前端落地页生成示例

如果目标是生成一个前端落地页，应向模型提供以下信息：

• 页面目标：获取用户留言、展示产品卖点、引导访问。
• 目标用户：企业客户、个人开发者或行业用户。
• 核心卖点：3 到 5 条。
• 页面结构：首屏标题、卖点区、表单区、说明区、页脚。
• 表单字段：姓名、联系方式、需求描述、隐私确认。
• 接口约定：提交地址、字段名、成功提示、失败提示。
• 异常状态：加载中、提交成功、提交失败、网络异常。
• 验收标准：移动端可访问、表单可校验、异常有提示。

模型可以据此输出页面结构说明、组件划分、字段校验规则、接口调用流程和测试用例。开发人员再根据团队现有技术栈进行落地。

结果验证

功能验证

确认原缺陷是否消失。例如页面是否恢复显示、接口是否返回预期数据、任务是否成功执行。验证方式包括手动复现、自动化测试和日志检查。

回归验证

确认修复是否影响其他功能。重点检查：

• 相关页面是否正常。
• 相关接口是否兼容。
• 缓存逻辑是否一致。
• 权限校验是否仍然有效。
• 旧版本数据是否仍能读取。
• 异常场景是否仍有兜底。

日志验证

检查错误日志是否消失。不能只看页面是否显示，还要确认后台没有继续产生异常。日志中应能观察到请求成功、数据完整、错误码正常。

监控验证

如果系统接入监控告警，应观察指标变化，包括错误率、接口耗时、请求量、资源占用和异常分布。对于偶发问题，需要观察较长时间窗口。

成本验证

对比预估成本与实际成本。如果实际费用明显高于预期，应检查：

• 是否提交了过多无关代码。
• 是否多轮重试过多。
• 是否输出内容过长。
• 是否缓存命中率低。
• 是否提示词模板重复冗余。
• 是否没有限制单次任务预算。

常见问题与排查

1. 模型修复看起来合理，但实际无效

常见原因：上下文不足，模型没有拿到关键日志或真实调用链。
排查方式：补充错误堆栈、接口返回、配置加载顺序和实际运行路径。要求模型只基于材料推理，并指出不确定项。

2. Token 费用快速上升

常见原因：一次性提交全部代码、重复调用、输出过长、提示词冗余。
排查方式：拆分任务、使用摘要、启用缓存、限制输出长度、设置单任务预算上限。

3. 修复范围过大

常见原因：提示词没有强调最小修改，模型倾向于重构。
排查方式：在提示词中明确“只修复当前缺陷，不重构，不优化无关代码”。人工复核时检查修改文件数量。

4. 模型虚构接口或配置

常见原因：材料中缺少接口定义，模型根据经验猜测。
排查方式：要求模型标注假设，并列出需要补充的信息。禁止在代码中引入未确认的依赖或配置。

5. 前端页面生成后样式不符

常见原因：缺少组件规范、间距规则、颜色变量、响应式要求。
排查方式：提供页面结构说明、字段示例、交互状态和验收标准。让模型先输出结构，再输出样式建议，最后由开发人员落地。

6. 敏感信息被带入提示词

常见原因：日志、配置或代码中包含真实账号、密钥或用户数据。
排查方式：在提交前执行脱敏。使用占位符替换敏感字段。调用日志也需脱敏，并限制访问权限。

7. 偶发问题难以复现

常见原因：日志不足、触发条件复杂、环境差异。
排查方式：增加埋点、补充链路标识、记录请求上下文、使用自动化脚本模拟多次操作。对于偶发问题，应优先保证可观测性。

优化建议

建立缺陷知识库

把已经解决的缺陷整理成案例库，包括现象、根因、修复方式、验证方法和成本数据。后续遇到类似问题时，可以先检索知识库，减少重复调用。

优先建设测试基线

大模型排障的效率取决于验证能力。没有测试，模型修复很难闭环。建议逐步补充单元测试、接口测试、页面自动化检查和日志断言。

使用模型路由策略

并非所有任务都需要最强模型。可以按任务复杂度分流：

• 简单文本整理：使用轻量模型。
• 单文件修复：使用中等能力模型。
• 跨模块排障：使用强模型。
• 批量分析：使用异步批处理方式。

这样可以平衡效果与成本。

提示词版本化

提示词应纳入版本管理。每次修改提示词模板，都应记录变更原因、测试结果和费用变化。稳定版本可作为团队复用资产。

建立成本看板

建议将 Token 消耗、调用次数、修复成功率、平均耗时、预算使用率纳入看板。看板可以帮助技术负责人判断模型投入是否值得。

强化安全边界

模型调用链路应设置安全边界：输入脱敏、输出审查、权限最小化、日志审计、敏感内容拦截。对于生产环境，应采用渐进式发布。

从单点修复走向流程化

当模型修复稳定运行后，可以进一步把流程接入研发流程：缺陷单触发、上下文自动收集、模型建议生成、测试自动执行、人工复核、结果归档。这样可以把大模型从“辅助工具”变成“工程链路的一部分”。

总结

本教程围绕年度预算内的大模型编程排障展开，重点不是追逐模型排名，而是建立可执行的工程方法。读者可以按缺陷单定义、最小上下文采集、提示词设计、隔离验证、失败回环、人工复核、成本记录的流程，逐步完成顽固缺陷修复。

在实际操作中，应始终记住三个原则：第一，上下文越精确，修复越稳定；第二，验证越自动化，交付越可靠；第三，成本越可观测，预算越可控。通过这套方法，即使预算有限，也能让大模型成为真实工程交付中的有效生产力。