1. Side Chat 做安全试验
适合大改、重构、方案验证。

用法不是直接让我“试试”，而是：

请在 side chat / 临时 worktree 中验证这个方案：
1. 不影响主工作区
2. 完成后只汇报 diff、编译结果、风险
3. 我确认后再合入

价值：你可以让 Codex 同时试多个方案，主目录保持干净。

2. 先让 Codex 建“项目索引”
大型项目不要一上来就让它改。

高级指令：

先建立当前项目的工程索引：
- 入口文件
- 核心模块
- 数据模型
- 配置文件
- 构建方式
- 测试方式
- 关键风险点

只输出索引，不修改文件。

之后再说：

基于刚才的项目索引，修复 xxx。

这样比直接“帮我修 bug”稳定很多。

3. 权威源优先策略
尤其适合你做 KDBOSS3 这种设计文档。

可以这样下命令：

以 DDL.SQL 为数据库权威源，
以主设计文档为业务权威源，
交叉检查接口文档、ER文档、权限文档是否一致。
发现不一致先列清单，不要立即修改。

这个比“检查文档”高级很多，因为它给 Codex 指定了权威关系。

4. Codex 适合做“多阶段门禁”
不要一次让它从分析到提交全做完，可以设闸门。

按三阶段执行：
第一阶段：只读分析，列问题清单。
第二阶段：我确认后修改。
第三阶段：运行校验，通过后再提交 git。
每阶段结束必须停下来等我确认。

或者反过来，全自动：

全自动执行：
分析、修改、验证、提交 git。
但遇到破坏性操作、删除文件、跨模块重构时必须停下确认。

5. 用 AGENTS.md 做项目级人格和规矩
你现在 F:\AIcode\test\AGENTS.md 已经写了专家角色。更高级的写法是把工作规则也写进去，例如：

- 设计审查必须优先检查逻辑闭环、数据闭环、权限闭环、流程闭环。
- 修改文档后必须同步修订记录。
- 数据库设计以 DDL.SQL 为准。
- 不允许凭空新增表字段，必须说明业务来源。

这样以后进入这个项目，Codex 会自动遵守。

6. Skill 是“固定工艺流程”
普通提示词是一次性的，Skill 是可复用流程。

适合封装：

KDBOSS3设计文档一致性审查
DDL转数据库设计文档
微信文章转Markdown
Delphi项目编译诊断
BOSS系统数据模型审查

高级用法：

请把刚才这套检查流程封装成一个 skill：
包括触发词、输入文件、检查步骤、输出格式、校验命令。

你已经做过微信文章转 MD，下一步可以做一个 kdboss-design-review skill。

7. 用 MCP/插件当“外部器官”
你这台机器启用了不少插件能力，例如 browser、documents、spreadsheets、presentations、figma、codex-security。

高级指令应该明确工具链：

使用 browser 打开本地页面，截图验证 UI。
使用 documents 渲染 docx 为 PDF/PNG 后检查版式。
使用 spreadsheets 检查 xlsx 公式和格式。
使用 codex-security 对当前 diff 做安全扫描。

不要只说“检查一下”，要指定“用什么验证”。

8. 让 Codex 产出“可审计证据”
高级工程流不是“我改好了”，而是要证据。

修改完成后输出：
- 修改文件列表
- 每个文件修改原因
- 验证命令
- 验证结果摘要
- 剩余风险

用于代码、文档、数据库设计都很稳。

9. 长任务用 /compact 管上下文
大文档、大项目做久了，上下文会膨胀。高级做法：

先 /status 看上下文占用；
如果超过 70%，执行 /compact；
然后继续任务。

如果 slash 命令没有触发，就从输入框输入 / 后选菜单，不要直接发到聊天。

10. 高级提示模板
你可以直接保存这段当万能模板：

你现在是本项目的高级工程执行代理。

执行规则：
1. 先读取项目现状，不要凭经验假设。
2. 找到权威源，并说明权威源是什么。
3. 先列出影响范围和风险。
4. 修改时保持最小变更。
5. 修改后运行可用的验证命令。
6. 输出修改清单、验证结果、剩余风险。
7. 不要回滚我已有的改动。

更狠一点的：

请按生产级变更流程处理：
需求澄清 -> 影响分析 -> 修改方案 -> 实施 -> 验证 -> 回归风险 -> 交付说明。
如果信息不足，先从仓库里找证据；找不到再问我。

真正高级的核心就一句：
不要把 Codex 当聊天机器人，要把它当“带本地工具链、可执行、可验证、可沉淀规则的工程代理”。