一、先把需求说清楚，再让 Codex 动手

很多团队把 Codex 当成代码生成器使用，结果发现输出经常需要反复改。问题未必出在模型本身，而是需求输入太松散：一句“优化登录流程”、一张截图、几个口头补充，就希望它直接给出完整修改方案。工程任务不是猜谜，需求越模糊，模型越容易补全不存在的细节。

更实用的做法，是把 API 中转站接入和工单拆解流程放在一起设计。灵能API提供统一调用入口，CC Switch保存不同任务配置，工单模板则负责把需求**、目标、范围、约束和验收标准整理成 Codex 能理解的任务指令。

二、需求工单要拆成六个字段

给 Codex 的工单不要写成大段散文。更适合 AI 协作的方式，是把需求拆成固定字段，让它明确哪些是事实、哪些是目标、哪些是限制、哪些需要人工确认。

这六个字段能显著减少来回沟通。Codex 不需要从含糊描述里猜意图，开发者也能更快判断它给出的方案是否偏离需求。

• **：为什么要做这个需求，当前问题是什么。
• 目标：本次完成后希望达到什么效果。
• 范围：涉及哪些页面、接口、模块、配置或数据。
• 约束：哪些逻辑不能改，哪些兼容性必须保留。
• 验收：如何判断任务完成，测试和人工检查分别看什么。
• 风险：可能影响哪些用户路径、任务链路或上线流程。

三、先确认灵能API的调用入口

在正式配置前，先进入灵能API https://www.lnsns.com/，确认 API *ase、可用模型、账号状态和项目使用策略。需求拆解通常会产生比较长的上下文，因此接入入口和模型范围要稳定，不能一边写任务指令一边猜模型名称。

团队文档中可以把灵能API设置成可点击入口，方便成员回到统一页面确认信息。需要注意的是，工单模板里不要保存完整 Key；它只需要说明使用哪张 CC Switch 配置卡，以及这个任务是否需要更强上下文能力。

四、按工单阶段设置 CC Switch 配置卡

需求从提出到上线通常会经历多个阶段：澄清、拆解、开发、审阅、测试、发布。每个阶段对 Codex 的要求不同，所以不建议只用一张默认配置跑到底。

这种配置拆分看起来多一步，但会让输出更稳定。澄清阶段不需要急着写代码，审阅阶段也不应该继续扩写需求；配置卡按阶段划分后，任务边界自然更清楚。

• ticket-clarify：用于阅读需求，找出缺失信息和不明确表达。
• task-splitter：用于把需求拆成开发任务、影响范围和待确认问题。
• code-worker：用于局部实现、函数修改和测试补齐。
• review-checker：用于检查 diff、风险点和验收条件。

五、把模糊需求改成可执行指令

需求工单里最常见的问题是描述太笼统。比如“优化会员页”“修复支付失败”“增加导出功能”，这些句子都不足以让 Codex 直接行动。你需要先让它把需求改写成可执行指令，再进入代码阶段。

需求澄清提示词：
请阅读下面的需求描述，把它拆成可执行任务。
输出包含：业务**、用户路径、影响模块、需要修改的文件类型、缺失信息、验收标准。
如果需求不足以进入开发，请只列出必须补充的问题，不要直接写实现方案。

这个步骤适合放在开发前。它可以帮助产品、开发和测试提前对齐，而不是等代码写完后才发现需求范围理解不一致。

在需求评审会议前，可以先用这段提示词跑一遍工单。会议中只讨论 Codex 标出的缺失问题和风险点，而不是从头阅读整份需求。这样能把评审时间用在真正模糊的地方，比如权限边界、旧数据兼容、异常提示和是否需要灰度发布。

六、任务指令要写清楚“不要做什么”

很多提示词只写“请实现某功能”，却没有告诉 Codex 哪些东西不能动。真实项目里，不能动的边界往往比要做的功能更关键。

把“不要做什么”写清楚，可以显著降低回滚和返工风险。尤其是接入灵能API与 CC Switch 后，模型能力更强，越应该用边界限制它不要做过度修改。

• 不要改动公共鉴权逻辑，除非工单明确要求。
• 不要新增未确认的第三方依赖。
• 不要修改旧接口响应字段，除非有兼容方案。
• 不要把测试数据、账号、密钥写进代码或文档。

七、验收标准不要只写“功能正常”

“功能正常”不是验收标准，它只是愿望。真正可执行的验收标准，要能被测试、开发或业务同学逐条检查。Codex 处理工单时，也需要这些标准来判断输出是否完整。

验收标准示例：
1. 未登录用户进入页面时，展示登录引导，不报 500。
2. 已登录普通用户只能看到自己的数据。
3. ***可以按时间范围筛选并导出结果。
4. 导出失败时显示明确错误，不丢失筛选条件。
5. 新增逻辑需要补充单元测试和至少一个异常场景测试。

如果工单没有验收标准，建议先让 Codex 帮忙补一版，然后由人工确认。模型可以辅助整理，但最终验收标准必须由项目负责人确认。

验收标准还应该区分“机器能验证”和“人工要确认”。机器能验证的部分包括单元测试、接口返回、状态码、命令执行结果；人工要确认的部分包括交互体验、提示文案、业务口径和视觉细节。两类验收混在一起，会让 Codex 误以为所有标准都能靠代码自动完成。

八、输入资料要按优先级排列

给 Codex 提供资料时，不要把所有内容平铺。最好按优先级排列，让它先读最重要的信息：需求目标、当前问题、相关文件、接口约定、测试命令、补充截图。

这种排序能让 Codex 把注意力放在当前任务上。很多失败输出不是信息不足，而是重要信息被淹没在一堆**材料里。

• 第一优先级：需求目标、用户路径、验收标准。
• 第二优先级：相关文件、接口文档、目录说明。
• 第三优先级：历史讨论、截图、类似需求、边界说明。
• 最后补充：可选优化方向、后续迭代想法。

九、让 Codex 先输出计划，再动代码

在复杂工单里，不建议一上来就让 Codex 改代码。更稳的是先让它输出实施计划：涉及哪些文件、准备怎么改、可能有哪些风险、需要哪些验证。人工确认计划后，再进入代码阶段。

实施计划提示词：
请基于当前需求和项目上下文，先输出实施计划，不要直接修改代码。
计划必须包含：涉及文件、修改点、兼容风险、测试方式、需要人工确认的问题。
如果需求边界不清楚，请停止并列出问题。

这个步骤能保护项目边界。特别是多人协作时，先看计划再动手，可以避免 Codex 把一个小需求扩展成大范围重构。

️ 十、开发阶段要控制单次任务大小

一个工单可能包含多个子任务，但不代表要一次交给 Codex 全部完成。更可控的方式，是按最小**证单元拆分：先改接口，再改页面，再补测试，再写说明。每一步都有输入和输出。

这样做看似慢一点，实际更省时间。因为每一轮都能被人工快速确认，出现偏差也只影响一个小范围。灵能API和 CC Switch 保证接入稳定，任务拆分则保证执行稳定。

如果一个子任务超过半小时仍然需要反复解释，建议暂停继续生成，回到工单层面重新拆分。很多时候不是 Codex 不会做，而是任务颗粒太大，里面混合了接口、页面、权限、测试和文档。把它拆成更小的**证单元，输出会更稳定。

• 第一轮：只分析影响范围，不写代码。
• 第二轮：只改一个模块或一个文件组。
• 第三轮：根据变更补测试和边界用例。
• **轮：生成验收说明和发布提醒。

十一、工单流转中要保留决策记录

Codex 参与需求拆解后，很多判断会在对话中完成：为什么选择这个实现方式、为什么不改某个模块、为什么新增测试。建议把关键决策写回工单，而不是只留在本地对话里。

工单决策记录字段：
决策点：
选择方案：
不选择的方案：
原因：
影响范围：
是否需要后续复盘：
Codex 输出是否经过人工确认：是 / 否

保留决策记录可以减少后续争议。几周后如果有人问为什么这样实现，团队不需要重新翻对话，只要看工单里的关键记录即可。

上线完成后，也建议把 Codex 参与过的关键输出回填到工单里，例如最终实现范围、实际测试结果、未处理的后续事项。这样下一次类似需求出现时，团队可以直接复用这份工单经验，而不是重新组织一轮**说明。

十二、需求变更时不要让旧指令继续生效

需求中途变化很常见，但很多人会忽略同步更新 Codex 指令。旧指令继续生效，会导致模型按过期目标输出代码，尤其是验收标准、接口字段、页面交互变化时更危险。

每次需求变化，都建议在工单里写一条“指令已更新”。这能提醒后续参与者不要再引用旧上下文，也能让 Codex 的输入保持干净。

需求变化后，最好让 Codex 重新生成一份“变更影响摘要”。摘要只回答三件事：原计划哪些内容仍然有效，哪些内容需要废弃，哪些文件或测试需要重新检查。这个动作能避免旧方案残留在新实现里。

• 需求目标变化：重新生成任务拆解，不沿用旧计划。
• 接口字段变化：更新接口约定，再让 Codex 继续修改。
• 验收标准变化：先同步测试清单，再补代码。
• 优先级变化：重新确认本轮只做哪些内容。

十三、完整落地顺序

• 第一步：进入灵能API https://www.lnsns.com/，确认 API *ase、模型范围和账号状态。
• 第二步：在 CC Switch 中按澄清、拆解、开发、审阅建立配置卡。
• 第三步：把需求工单拆成**、目标、范围、约束、验收和风险六个字段。
• **步：让 Codex 先补充缺失问题，不要直接进入实现。
• 第五步：人工确认实施计划后，再按最小**证单元执行开发。
• 第六步：把关键决策、验收结果和变更记录写回工单。
• 第七步：需求变化时同步更新指令，避免旧上下文继续影响输出。

✅ 十四、结语：需求拆得越清楚，Codex 越像团队成员

Codex API 中转站接入的价值，不只是把模型调用跑通。灵能API提供统一入口，CC Switch管理不同任务配置，工单模板负责把需求变成可执行指令，这三者组合起来，才能真正降低沟通和返工成本。

当需求**、影响范围、边界约束和验收标准都清楚时，Codex 的输出会更贴近工程现场。它不再只是临时回答问题的工具，而可以参与需求澄清、任务拆解、实现计划、代码审阅和验收整理，让团队协作更顺。