API Key 无效或缺失项目范围：使用前怎么判断是否适合

客户说“API key 报错，帮我修一下”，这句话本身不足以报价。它可能只是 .env 变量名写错，也可能涉及生产服务器、客户账号、付费额度、密钥泄露、团队权限和线上日志。新手接这种单，第一目标不是马上承诺修好，而是判断它是否属于自己能安全处理的小范围排错。

适合谁

适合已经能看懂基本报错、会运行项目、知道环境变量和部署平台配置位置的新手。你不需要成为安全专家，但必须知道真实密钥不能公开、不能随便截图、不能提交到仓库。

也适合准备把“排错报告”作为交付物的人。有些任务不一定能直接修复，因为账号权限和计费状态需要客户自己处理，但你可以交付清楚的原因分析、复现路径和下一步建议。

不适合客户要求你直接登录生产后台、保存完整密钥、访问账单信息、改动线上支付配置或处理真实用户数据的情况。这类需求超出普通新手排错范围，需要更严格的授权和安全流程。

也不适合客户拒绝提供错误原文、拒绝说明环境、拒绝创建测试密钥，却要求你直接保证结果的情况。没有复现条件的排错，很容易变成无边界售后。

第一步，向客户确认错误发生在哪里：本地、测试环境、线上部署，还是某个自动化平台。不同环境对应不同权限和风险。

第二步，要求客户提供脱敏信息：错误码、截图、触发步骤、相关代码片段、部署平台名称。不要要求完整密钥；如果客户主动发来，应提醒撤销并重新生成。

第三步，判断是否能用测试密钥复现。能用测试密钥复现，通常适合新手处理；必须接触生产密钥或真实数据的任务，应提高报价边界或直接不接。

第四步，把交付范围写清楚。可以包含：排查环境变量、检查服务端读取、确认部署变量、给出修复建议、提供测试记录。不包含：代管账号、保存密钥、处理账单、承诺客户业务结果。

第五步，约定验收方式。比如“客户在自己账号中更新密钥后，测试接口返回正常；我提供排查记录和修改说明”。这样责任边界比“我保证修好 API”更清楚。

报价时不要把密钥问题包装成普通小 bug。密钥可能关联费用、权限和客户数据，一旦处理不当，责任会明显高于页面样式或文案调整。新手宁愿先做诊断单，也不要在信息不足时承诺完整修复。

如果客户项目已经泄露密钥，优先建议客户撤销旧密钥、生成新密钥、检查使用记录。你可以说明排查路径，但不要替客户承担账号安全决策。

适合新手的范围通常包括：阅读脱敏错误信息、检查变量名是否一致、确认本地服务是否重启、确认部署平台是否有同名变量、说明服务端和前端的区别、提供测试记录和下一步建议。这些动作有边界、有证据，也不会要求你长期接管客户账号。

不建议承接的范围包括：保管客户真实密钥、接触生产用户数据、修改账单和付款设置、处理企业内部权限审批、对客户业务效果作出承诺。你可以把这些事项写进“不包含项”，让客户知道你是在保护双方，而不是能力不足。

信息不完整时，可以先报“诊断包”，不要直接报“修复包”。诊断包交付排查记录、原因判断和建议步骤；如果确认只是变量或部署配置问题，再追加修复范围。这样做能避免客户把账号权限、额度、模型开通、旧代码问题全部塞进一个小报价里。

回复客户时可以写：我先按一小时诊断排查，确认问题是否来自环境变量、部署配置或账号权限；如果需要改代码或重新部署，我会先说明影响范围再继续。这个表达比直接承诺结果更稳，也更符合新手当前能力边界。

本文仅供学习和项目流程参考，不构成安全、法律、财务或职业建议。不同平台的密钥规则、授权方式和日志保留策略不同，发布前需要人工复核。接客户任务时请遵守平台规则、最小权限原则和客户书面授权。

CTA：准备回复客户前，先在 /templates 下载需求确认表，再用 /tools/proposal-generator 写一版范围清楚的英文或中文回复，最后人工删掉任何过度承诺。