一、为什么要先做提示词模板库

很多团队接入 Codex API 中转站以后，会马上让成员各自尝试：有人让它写代码，有人让它看日志，有人让它改测试，也有人让它整理 PR 说明。短期看大家都能用，长期看输出质量会非常不稳定，因为每个人描述任务的方式不同。

提示词模板库的价值，是把“怎么向 Codex 交代任务”变成团队资产。灵能API负责统一 API 中转站入口，CC Switch 负责保存不同模型和配置卡，模板库则负责统一任务表达方式。三者结合，团队才能从个人灵感式使用，进入可复用、可训练、可复盘的使用方式。

二、模板库不是收藏夹，而是操作标准

很多人会把常用提示词随手放在文档里，这只能算收藏夹。真正有用的模板库，应该能回答四个问题：这个模板适合什么任务，输入需要哪些信息，输出应该长什么样，什么时候不能使用。

模板库越像操作标准，越能减少误用。它不是限制成员发挥，而是先给大家一条稳定基线。遇到特殊问题时，可以在模板基础上扩展，而不是每次从空白对话开始。

真正落地时，可以把模板分成“必填区”和“可选区”。必填区用于描述任务目标、输入材料和禁止事项；可选区用于补充**、历史原因或输出偏好。这样新人不会因为模板太长而放弃填写，熟练成员也能在复杂任务里补充更多上下文。

• 适用场景：明确模板用于需求分析、排错、审阅、测试还是文档整理。
• 必填输入：说明必须提供的文件、日志、现象、约束和目标。
• 输出格式：要求模型按固定结构返回，便于审阅和复制到任务系统。
• 禁用条件：说明哪些任务复杂度过高、信息不足或风险太大，不适合直接套模板。

三、先确认灵能API入口和模型范围

进入灵能API官网 https://www.lnsns.com/ 后，先确认 API *ase、模型名称、账号状态和可用说明。模板库里如果写了旧模型名、旧入口或旧参数，成员按模板执行时会批量遇到同样问题。

建议模板库只保留灵能API的统一入口链接，不保存完整 API Key。具体 Key 应由 CC Switch 配置卡、密码管理器或内部密钥流程承接。这样模板可以安全共享，敏感凭证不会跟着文档四处复制。

四、模板要和 CC Switch 配置卡绑定

同一段提示词，用不同模型和配置卡执行，结果可能差异很大。比如错误日志分析需要较强的推理和定位能力，PR 摘要更需要结构化表达，单文件解释则更看重速度。模板库最好明确推荐使用哪张 CC Switch 配置卡。

模板和配置卡绑定后，成员不会拿低成本短问答配置去做复杂跨文件分析，也不会为了简单说明任务动用高消耗模型。

绑定关系还应该写进模板标题或开头。比如“错误排查模板 / 推荐配置卡 failure-analysis”，成员复制模板时就能顺手确认当前 CC Switch 是否已经切到正确卡片。这个动作很小，但能避免很多“提示词没问题，配置用错了”的尴尬。

• 需求澄清模板：适合分析目标、边界和缺失信息。
• 错误排查模板：适合读取日志、复现步骤和相关代码。
• 代码审阅模板：适合检查 diff、风险和测试覆盖。
• 测试补齐模板：适合生成计划、用例和验证命令。

五、每个模板都要有任务卡头部

任务卡头部是模板里最重要的部分。它让 Codex 在回答前先知道任务目标、允许范围、输出格式和约束。没有任务卡头部，模型会根据上下文自由发挥，结果更难复核。

任务类型：代码审阅
目标：检查本次改动是否存在逻辑风险
允许读取：当前 diff、相关测试、变更文件
禁止操作：不要修改文件，不要执行命令
输出格式：结论、风险、建议、需要人工确认的问题

这个头部可以很短，但必须清楚。特别是“禁止操作”很有用，它能避免模型在你只想要审阅意见时顺手改文件。

任务卡头部还可以加入“成功标准”。例如本次只需要输出排查顺序，不需要生成补丁；本次只需要补两条防回归测试，不需要扩大测试范围；本次只需要整理 PR 说明，不需要评价代码好坏。成功标准越明确，结果越容易验收。

六、需求澄清模板：先问问题再动手

需求澄清是最适合模板化的场景之一。很多任务失败，不是模型不会写代码，而是它一开始就误解了需求。模板应该要求 Codex 先复述目标、列出未知信息、提出确认问题，然后再进入实现建议。

请先不要写代码。
请基于下面需求输出：
1. 你理解的目标
2. 可能影响的模块
3. 信息缺口
4. 需要我确认的问题
5. 如果信息足够，再给出下一步计划

这个模板适合新功能、需求变更、交互调整和接口改造。它能让团队在动手前发现歧义，减少后续返工。

七、错误排查模板：把现象、日志和环境拆开

错误排查不能只贴一段报错。模板应该引导成员同时提供现象、复现步骤、关键日志、运行环境和已尝试动作。这样 Codex 才能判断问题来自代码、配置、依赖、网络还是数据。

现象：
复现步骤：
关键日志：
运行环境：
最近变更：
已尝试动作：
请输出：最可能原因、证据、排查顺序、下一步验证方式

这个模板的重点是“证据”。要求 Codex 每个判断都说明依据，能防止它在日志不足时随便猜。

错误排查模板最好保留“已尝试动作”字段。没有这个字段时，模型经常会建议你做已经做过的事情，比如重启、清缓存、重新安装依赖。把已尝试动作写清楚，输出会更接近下一步，而不是回到起点。

八、测试模板：先计划，再生成，再解释价值

测试生成模板不要只写“帮我补测试”。更好的模板会要求 Codex 先输出测试计划，再生成用例，最后解释每条用例覆盖的路径和存在价值。

把测试模板写成流程后，团队就不容易得到一堆看似丰富但维护成本很高的测试。好测试要能解释为什么存在，而不只是让覆盖率数字更好看。

• 先说明核心路径、边界条件和异常分支。
• 再确认测试文件位置和项目已有风格。
• 再生成最小必要用例，不做无意义堆叠。
• 最后输出验证命令和失败时的排查方向。

‍ 九、代码审阅模板：意见必须分级

代码审阅模板里，最关键的是让 Codex 对意见分级。不要把阻断性 *ug、可读性建议和后续优化混成一堆。审阅者真正需要的是先处理必须改的问题，再决定是否接受建议。

请基于当前 diff 做代码审阅：
- 必须修改：会导致错误、安全风险、数据问题或测试失败
- 建议修改：可维护性、可读性或边界表达
- 后续任务：超出本次范围但值得记录
每条意见必须说明文件位置、原因和建议处理方式。

这类模板特别适合团队合并前自查。灵能API提供稳定调用入口，CC Switch 固定审阅配置，模板则把输出整理成审阅者真正能用的结构。

十、PR 说明模板：只**实发生的变更

PR 说明模板要强调准确。不要让 Codex 把一次小修复写成完整重构，也不要让它把未验证的结果说成已经通过。模板里应该要求它基于 diff 输出**、修改内容、验证方式、风险和未处理事项。

请基于当前 diff 生成 PR 说明：
**：
修改内容：
验证方式：
风险与回滚：
未处理事项：
要求：只写本次真实发生的变化，不补充没有证据的结论。

PR 模板稳定后，开发者可以快速得到一份清楚的提交说明，审阅者也能更快理解变更意图。

十一、模板版本要有变更记录

提示词模板不是写完就永远不变。随着模型、项目、团队习惯变化，模板也要迭代。建议给每个模板保留版本号、修改日期、修改原因和验证结果。

模板名称：error-log-analysis
版本：v1.3
修改日期：2026-09-02
修改原因：增加“已尝试动作”字段，减少重复建议
验证任务：订单状态日志排查
结果：输出更聚焦，减少无关依赖建议

有版本记录后，团队就能知道为什么改模板。如果新版本输出变差，也可以回退到旧版本，不需要凭记忆重写。

版本记录不必复杂，但要真实。不要只写“优化模板”，要写清楚优化了哪个字段、解决了什么问题、用哪个任务验证过。这样模板库会越来越像团队经验库，而不是越堆越多的文本片段。

十二、模板库要避免三类坏习惯

模板库本身也会变乱。最常见的问题有三类：模板过长、模板太泛、模板没有验证。过长会让成员不愿使用，太泛会让输出不稳定，没有验证会让模板只是看起来完整。

好的模板库应该轻、准、**证。它帮助成员把任务说清楚，而不是让大家先背一套复杂规则。

另外，不建议把模板写成过度命令式的长篇规则。模型需要清楚约束，但也需要足够空间根据代码和日志做判断。模板的目标是给出边界和结构，不是替代工程判断。真正好的模板，会让成员更快说清楚问题，也让 Codex 更快进入正确任务状态。

• 模板过长：保留必要字段，细节放到说明，不要让成员每次都填十几项。
• 模板太泛：每个模板只服务一类任务，不要一个模板覆盖所有场景。
• 模板未验证：上线前用真实小任务跑一次，检查输出是否符合团队需要。

十三、完整落地顺序

• 第一步：从灵能API官网 https://www.lnsns.com/ 确认 API *ase、模型和账号状态。
• 第二步：在 CC Switch 中为需求、排查、审阅、测试、PR 说明建立对应配置卡。
• 第三步：为每个高频任务写任务卡头部，明确目标、输入、输出和禁止事项。
• **步：用真实小任务验证模板是否能稳定输出。
• 第五步：给模板增加版本号、负责人和最近验证日期。
• 第六步：把有效模板写入团队文档，完整 Key 仍放在受控位置。
• 第七步：每月复盘一次模板使用效果，删掉低价值模板，保留真正高频的模板。

✅ 十四、结语：模板库让 Codex 使用方式稳定下来

Codex API 中转站接入成功，只是第一步。真正适合团队长期使用的方式，是把高频任务变成稳定模板，让成员按同一套任务卡输入信息、选择配置卡、得到可复核输出。

灵能API提供统一入口，CC Switch 管理调用配置，提示词模板库沉淀团队经验。三者连起来，Codex 就不再只是某个人用得顺手的工具，而是能在需求、排错、审阅、测试和交付说明中反复复用的工作流。