enhance-prompt

name	enhance-prompt
description	把用户主动要求增强、优化、重写或整理的粗略任务，转成可直接发送给 Codex 或其他 AI 的清晰提示词。用于“增强提示词”“优化这段提示词”“把这句话整理成新对话执行提示词”“帮我写一段给 Codex 的任务说明”等场景；生成新对话提示词时，在模型选择明显影响效果的情况下附一行模型建议。只在用户明确要提示词而不是要你直接执行任务时触发，不因普通请求含糊而自动拦截。

提示词增强

把粗略需求整理成清晰、可执行、可验收的提示词。提示词不需要华丽；优先写清目标、背景、限制和完成标准。

核心原则

• 保留用户原意。增强清晰度，不新增用户没有表达的目标、受众、期限、数据、文件、格式或承诺。
• 保留任务性质。用户要讨论、分析或诊断时，不得改成执行、落盘或对外动作。
• 结构与复杂度成比例。简单任务用一两句话；只有复杂任务才完整展开四段式。
• 先用已有上下文。利用当前对话、用户点名的文件和已知项目约束；不得编造不存在的背景。
• 优先正面说明要做什么、交付什么、如何验收，少堆角色、人设、口号和泛化形容词。
• 不要求模型展示思维链。用明确的成功条件、检查动作和证据要求提升可靠性。
• 保持原语言。用户用中文就输出中文；必要英文术语配中文说明。
• 模型建议只服务于新对话开工，不混进提示词正文，不声称已经替用户切换模型。

工作流

1. 锁定原始意图

从用户输入和当前上下文中识别：

• 最终想得到的结果；
• 任务发生在哪个项目、对话或 AI 工具中；
• 相关文件、资料、错误、参考案例和既有决定；
• 明示的禁止项、格式、风格、安全边界和授权范围；
• 可以被观察或验证的完成条件。

区分“给当前对话继续用”与“复制到新对话使用”。新对话提示词要补足目标、必读入口、边界和验收证据；当前对话提示词不要重复已经稳定存在的长背景。

2. 判断增强深度

• 简单且清楚：只做轻量改写，必要时原样保留，不强套标题。
• 目标明确但表达散乱：重排顺序、合并重复、补清输出和验收。
• 复杂或容易跑偏：使用四段式完整整理。
• 关键信息确实缺失：先查当前对话和用户点名的本地资料。仍无法判断，且不同答案会明显改变结果时，最多问 3 个短问题；否则把“先核查或向用户确认”写进生成后的提示词，不使用待填占位符。

3. 用四段式组织复杂任务

1. 目标：我要得到什么最终结果？
2. 背景：哪些文件、资料、错误、现状或参考案例与任务有关？
3. 限制：哪些内容不能改？要遵守什么格式、风格、安全和授权要求？
4. 完成标准：满足哪些可检查条件，才算真的做完？

按任务需要补充这些细节，但不要机械堆满：

• 实施任务：先审问题，再做最小可行实现，最后验证；
• 分析任务：说明证据来源、未知项、口径和结论边界；
• 本地文件任务：写清输入路径、允许修改范围、输出路径和验证方式；
• 高影响任务：写清只读、备份、对比和确认闸门，不替用户扩大授权；
• 长任务：写清阶段、停车条件、状态区分和最终证据包。

4. 判断是否加入并行子代理分工

用户明确要求使用或禁用子代理时，保留其意图；否则只在任务可拆成互不重叠的独立范围，且预计能明显提高覆盖、核验质量或时效时加入。

写入提示词时，只说明各子代理负责什么、权限边界、输出证据，以及主代理如何合并和验收；不得扩大用户对原任务的授权。高难度软件开发完成后的独立审查按下一节处理。

5. 为高难度开发生成独立审查闭环

仅当提示词面向软件开发任务，并命中以下任一信号时，加入独立审查闭环：

• 复杂逻辑；
• 跨模块依赖；
• 数据迁移；
• 权限或安全；
• 并发；
• 关键业务流程；
• 难回滚改动；
• 较大测试矩阵；
• 用户明确要求对该开发任务使用独立审查。

普通代码小改默认不加入。复杂但非软件开发的分析、文档、经营、规则或数据任务，不套用代码审查六项。

生成后的提示词加入以下语义完整的段落；可以按项目语境压缩措辞，但不得遗漏审查输入、权限边界、六项审查、问题分级、同代理复验、运行阻塞、两轮争议和降级说明：

高难度开发任务的独立审查闭环：

1. 主代理先展示实施计划。既有授权足够时直接继续开发；只有出现扩范围、需要新增授权、重大风险或硬边界时才暂停。
2. 开发和主代理初步验证完成后，在当前任务内启动一个独立审查代理；不要新建用户可见的新任务。
3. 向审查代理提供并要求其实际读取：原始需求、项目规则、实施计划、实际代码差异、测试结果、运行证据和真实文件。
4. 审查代理不得修改源代码、配置、测试代码、重要数据或外部系统；可以运行非破坏性的测试、构建和本地程序，并生成临时验证产物。
5. 审查必须覆盖：需求完整性、逻辑正确性、边界情况、代码质量、测试覆盖、实际运行结果。
6. 审查结果分为“必须修复”和“改进建议”。每项写明证据、影响、修复建议和复验方法。
7. 主代理负责修改；修复后交回同一审查代理复验。必须修复项全部通过后才能完成。改进建议可以不采纳，但主代理必须给出理由和证据。
8. 能独立运行时，审查代理必须复跑关键验证。不能运行时不得判定完整通过，必须说明阻塞原因、已完成验证、缺失证据和解除条件。
9. 主代理与审查代理连续两轮仍无法用证据解决争议时，停止循环并交用户裁决。
10. 当前环境无法启动独立审查代理时，主代理可以补充自检，但必须明确这是降级自检，不得冒充独立审查或宣称完整通过。

6. 评估新对话使用的模型

只在用户要把提示词复制到新对话时检查模型适配；给当前对话继续使用的提示词不提醒模型。

1. 先读取并遵守当前第一层规则中的模型路由；模型名称、定位或默认值发生变化时，以现行第一层为准，不在本 Skill 另建第二套长期口径。
2. 只有模型选择会明显影响质量、速度或风险时，才在提示词前加一句建议：
   • Sol：复杂、关键、错不起、长链路、高影响迁移或规则治理；
   • Luna：简单、批量、主要追求速度；
   • Spark：小范围、实时、以代码修改为主；
   • Terra：普通任务的默认选择。适合 Terra 时通常不额外打扰，除非用户明确询问模型。
3. 建议格式保持一句话，例如：建议新对话使用 Sol：涉及两个独立项目、规则真相源和高影响迁移。
4. 若已知用户手动选择或切换了模型，视为人工接管，不再建议；运行环境没有暴露当前选择时，不得假装已经识别，也不得声称已自动切换。

7. 做失真检查

输出前逐项检查：

• 是否偷偷增加了用户没说的需求？
• 是否把简单任务写得更长、更难执行？
• 是否遗漏用户最在意的限制或现有文件？
• 是否把建议、讨论或分析升级成了执行？
• 完成标准是否能实际检查，而不是“高质量”“专业”“完善”等空话？
• 是否出现需要用户自行替换的占位符？如有，改成由目标 AI 先查上下文或向用户提问。

输出规则

• 默认只输出一个可直接复制的提示词代码块，不加前言和复盘。
• 新对话且模型选择明显影响结果时，允许在提示词前增加一行简短模型建议；建议放在代码块外，不污染可复制正文。
• 用户要求“说明你改了什么”时，先给最终提示词，再用不超过 5 条说明关键改动。
• 用户要求多个版本时，最多给“轻量版 / 完整版”两版，默认把推荐版放前面。
• 命中高难度软件开发独立审查闭环时，提示词必须保留完整审查循环，不得用普通“自检”或并行子代理分工代替。
• 普通代码小改默认不加入该闭环；复杂但非软件开发的任务不得套用代码审查六项。
• 不直接执行增强后的任务，除非用户随后明确要求执行。

示例

用户输入：

增强提示词：帮我做一个官网。

输出：

在当前项目中制作一个单页官网。先读取现有品牌资料和项目规则，复用已有内容与素材，不修改原始文件。

页面需要兼容手机和电脑，信息层级清楚，按钮和链接可用。完成后启动本地预览，检查文字溢出、布局、交互、控制台错误和主要链接，并把可访问地址、实际修改文件和未完成事项告诉我。

用户输入：

把“只做分析，看看这个项目为什么乱”增强一下。

输出：

只做只读分析，不新建、修改、移动或删除任何文件。先读取当前项目入口、目录结构、状态文件和现行规则，找出混乱的具体表现、根因和影响范围。

输出按“已确认事实 / 高可信判断 / 待确认问题 / 最小改进建议”组织，并引用对应的绝对路径作为证据。不要把建议直接实施。

用户输入：

给我提示词，我要在新对话合并两个独立的规则项目。

输出：

建议新对话使用 Sol：涉及两个独立项目、规则真相源和高影响迁移。

把两个规则项目合并为一个长期维护项目。先只读核对双方的项目规则、目录、Git 状态、现行规则和未完成事项，列出目标结构、逐项迁移映射、冲突、回滚方式和确认闸；得到确认后再实施。

不得覆盖未提交改动、复制第二份规则正文或直接删除源项目。完成后验证唯一真相源、现行路径、入口壳和推进清单，并交付实际修改路径与未处理事项。

用户输入：

优化这段提示词：检视我过去的对话串和各个项目，整理出五种能让我更简化流程、更有效率使用 Codex 的方法。使用子代理协助分析。

输出：

只读分析任务，不要改文件、不要创建文件、不要对外发送、不要启用自动化。

请基于我过去的对话、记忆和重点项目，整理出 5 种最能让我简化流程、并更高效使用 Codex 的方法。先判断主要流程摩擦在哪里，不要直接给工具清单。

每条方法都必须包含：适用场景、当前问题、推荐做法、为什么适合我、最小可执行动作、验收证据。如果证据不足，标注“待验证”。

子代理使用方式：
- 子代理 A：只读盘点重点项目和旧对话中反复出现的任务类型。
- 子代理 B：只读找出流程摩擦点，例如入口不清、资料散、交接断、验收弱。
- 子代理 C：只读提炼可复用的任务卡、交接提示词和验收证据包模板。
- 主代理：合并判断，只输出最高 ROI 的 5 条方法，并剔除重复、空泛、过度设计的建议。

禁止：子代理不得改文件、删文件、归档、对外发送、写入真实业务系统、升格规则或做最终决策。

输出格式：先给一句总判断；再按 1-5 列出五种方法；最后给一个“我下次就可以这样用 Codex”的最小使用模板。