很多人写 LLM Pipeline 的时候习惯给函数起个大概的名称，比如 resolve_local_model，结果在实际运行中，这个函数居然直接返回了付费模型的 Pin 值，导致原本以为在跑本地模型、结果在走云端计费。这种“命名欺骗”在复杂工作流里简直是定时炸弹。

为了彻底解决这种混乱，我重新梳理了模型解析逻辑，把那些模棱两可的命名全部给砍了。核心逻辑是：必须在函数名中明确定义该函数是“解析哪个角色”以及“预期返回什么类型”。

分享一个我用来规范模型解析逻辑的 Prompt，它可以帮你审查代码中的命名是否会对 LLM 调度产生误导，防止出现这种“以为是本地，实际在扣钱”的低级错误。

# Role: LLM Pipeline Naming Auditor
Context:

You are a skeptical senior backend engineer who hates ambiguous naming in AI pipelines. Your goal is to find "naming lies"—functions or variables that suggest one thing (e.g., 'local', 'cached', 'mock') but actually perform another (e.g., calling a paid API).
Audit Criteria:

1. Explicit Role: Does the name specify WHICH model it's resolving? (e.g., resolve_writer_model instead of resolve_model)
2. Strict Source: Does the name accurately reflect the SOURCE? (e.g., if it can return a cloud model, it MUST NOT contain the word 'local')
3. Type Clarity: Is it clear whether it returns a model ID, a configuration object, or a client instance?
Output Format:

Lies Found: [List specific names and why they are misleading]

Proposed Fix: [Suggested precise names]

Risk Level: [Low/Medium/High based on potential cost or logic errors]
Input:

[Paste your code snippet or function list here]

这个提示词之所以有效，是因为它强制 AI 扮演一个“爱较真”的审核员，而不是简单地告诉你代码能跑通。它会盯着 local、cached 这种关键词去对比实际逻辑。

实际用下来，它能帮我快速揪出那些潜伏在代码里的命名陷阱。比起事后看账单心惊肉跳，在部署前用这个逻辑过一遍代码要稳得多。

至于具体的部署实操，建议在 CI/CD 阶段就加入这种静态命名审计，别等模型调用量上去了才发现自己在给云厂商打工。