前面全部129项任务表达按用途归入12类，配套16种常用流程。选择符合当前目标的流程，用实际验证结果判断是否完成。

使用方式

任务词属于自然语言表达，英文、中文和完整句子都能使用。把对象、范围、约束和验收条件写清楚，例如“定位动画掉帧原因，保持现有交互，用相同场景比较修改前后的帧率”。参见 OpenAI 官方提示指南。

/plan、/review 是支持它们的客户端内置入口；本表中的 fix、debug、refactor 等是普通任务表达。CLI 审查通常围绕 Git 改动，也可用自然语言指定需要审查的文件和范围。入口以当前客户端菜单为准。

默认主流程：明确目标 → 阅读相关代码并按需规划 → 实现并运行相关检查 → review → 核实问题并按需修复 → 复测与必要复查 → 实际验收 → 交付。小改动可省略单独规划，测试层级按任务选择。参见 OpenAI 官方最佳实践。

分类总览

合计129项，每项在主词表中只归入一个类别。

完整任务词表

理解与规划

12项。

生成与实现

14项。

调试与修复

12项。

审查与验证

8项。

测试与检查

17项。

重构与整理

12项。

性能与效率

12项。

界面与交互

10项。

安全与权限

8项。

数据处理

6项。

运行与交付

12项。

文档与总结

6项。

常用流程总览

箭头表示默认顺序。修复以核实问题为前提，测试层级按任务选择，发布步骤只在任务包含相应交付范围时执行。

常用流程执行细则

01 接手项目和理解代码

适用场景：刚接触仓库，需要弄清入口、模块和运行方式。

顺序：inspect → trace → explain → document。

围绕一个入口或用户流程阅读，形成可核对的代码地图。

完成条件：能指出关键文件、调用关系和运行测试命令，疑问有记录。

可直接输入：

阅读项目，说明入口、核心模块、数据流、运行方式和测试命令。给出对应文件位置，列出尚不明确的地方。

02 开发新功能

适用场景：把已有方向的需求实现并交付。

顺序：clarify → /plan → implement → test → /review → verify。

小改动可省略单独规划。审查发现问题时使用审查修复流程，确认解决后再验收。

完成条件：约定的正常路径、关键边界和交互满足需求，相关检查实际通过。

可直接输入：

实现这个功能：先读相关代码并明确验收标准；复杂部分先规划，分步实现并运行相关测试。完成后审查、核实并修复问题，最后按真实使用流程验收。

03 制作快速原型

适用场景：先验证想法、布局或核心交互。

顺序：clarify → scaffold → prototype → preview → verify。

先明确原型要回答的问题，围绕主要流程做可操作版本。

完成条件：约定的核心交互可演示，原型范围和后续方向清楚。

可直接输入：

先做能操作的原型，覆盖最重要的用户流程。启动预览并检查核心交互，说明哪些已完成、哪些属于下一阶段。

04 定位并修复 bug

适用场景：出现报错、错误结果或不稳定行为。

顺序：reproduce → debug → regression test → fix → retest → /review → verify。

有意义且可执行的回归测试应在修复前暴露问题、修复后通过。先保留失败证据，再针对性修改。

完成条件：原复现步骤不再触发问题，相关正常行为通过检查。

可直接输入：

先复现问题并定位原因，保留失败证据。适合自动测试时先补能暴露问题的回归测试，再修复、复测并审查改动，验证原问题及相关正常流程。

05 代码审查后的核实与修复

适用场景：代码刚写完，或已拿到 review 结果。

顺序：/review → verify → fix → retest → /review。

fix 只处理确认存在的问题；没有代码变化和新证据时，不机械重复审查。

完成条件：接受处理的问题已核实和解决，必要复查完成，未执行的检查有记录。

可直接输入：

审查本次改动，按影响列出问题及证据。逐项核实，修复确实存在的问题，运行相关测试；对实际修复的内容再次审查，说明验证结果。

06 补齐测试与检查

适用场景：关键路径、边界或模块协作缺少检查。

顺序：test coverage → mock → test → /review。

按需求选择 unit test、integration test、e2e test 等层级；mock 只在需要隔离外部依赖时使用。

完成条件：关键场景有可解释的断言，测试实际运行，失败能反映有意义的问题。

可直接输入：

检查关键路径和测试缺口，选择合适的测试层级，补充必要的正常、异常和边界用例。运行相关测试，说明每组测试验证什么。

07 重构和整理代码

适用场景：重复实现、职责混杂或依赖关系影响维护。

顺序：inspect → test → refactor → test → /review → verify。

先运行现有相关检查作为基线；extract、split、modularize、decouple 按问题选择。

完成条件：约定的外部行为和接口一致，相关测试通过，结构符合重构目标。

可直接输入：

先理解代码并运行相关现有检查。按目标重构，保持约定的接口和外部行为；改完重跑检查，再审查是否引入回归。

08 优化性能

适用场景：加载慢、运行慢、内存高或卡顿。

顺序：measure → profile → optimize → benchmark → test → /review。

先记录基线并定位主要瓶颈；比较前后数据，说明测量限制。

完成条件：相同输入和可比较环境下达到约定指标，正确性检查通过。

可直接输入：

先记录性能基线并定位瓶颈，再针对性优化。用相同输入和可比较环境测量修改前后结果，运行正确性检查，报告收益和限制。

09 打磨页面和响应式体验

适用场景：修正布局、视觉细节、屏幕适配或无障碍体验。

顺序：inspect → polish → responsive → accessibility → preview → visual regression test → verify。

实际检查桌面和移动尺寸。已有视觉基线时做截图对比；没有基线时按参考图和验收项检查。无法运行的项目列出。

完成条件：目标尺寸下布局交互符合要求，关键状态可用，视觉变化有依据。

可直接输入：

打磨页面间距、对齐、遮挡、移动适配和交互反馈。启动预览，检查点击、键盘焦点、错误及空状态；已有视觉基线时截图对比，记录结果。

10 修正动画和交互同步

适用场景：动作不同步、暂停恢复异常、缩放漂移或控制失效。

顺序：reproduce → trace → synchronize → preview → playtest → verify → /review。

核对时间源、父子变换和控制状态；出现掉帧时再使用性能优化流程。

完成条件：动作与状态符合约定，暂停、恢复、重置和控制操作稳定，复现步骤通过。

可直接输入：

定位动画不同步、缩放漂移和控制失效的问题。核对时间源、父子变换和状态更新，修复后实际操作暂停、恢复、重置、拖动和缩放，按复现步骤验收。

11 接入接口和外部服务

适用场景：接入 API、整合前后端或对接服务。

顺序：specify → mock → integrate → integration test → security review → verify。

先明确请求响应契约，再按业务需要检查超时、错误、空数据和重试。

完成条件：接口契约与关键异常路径通过验证，认证权限符合要求。

可直接输入：

按接口契约接入，核对请求、响应和错误处理。验证正常、空数据、错误、超时及权限不足场景；涉及重试时检查重复提交，运行相关集成测试。

12 升级依赖和迁移实现

适用场景：升级依赖、替换接口或迁移技术方案。

顺序：inspect → plan → migrate → typecheck → test → /review → verify。

依赖升级可使用 upgrade；记录原版本、锁文件及受影响调用，逐步验证。

完成条件：目标版本和关键行为得到验证，相关构建测试通过，兼容变化和恢复方式清楚。

可直接输入：

核对当前版本、依赖和受影响调用，制定步骤并逐步升级或迁移。运行相关构建、类型及测试检查，审查兼容变化，记录恢复原状态所需信息。

13 安全检查和针对性修复

适用场景：检查认证、权限、输入、依赖或敏感信息泄露。

顺序：audit → verify → harden → regression test → /review → verify。

按问题选择 sanitize、escape、authenticate、authorize、redact 等动作；结论限定在实际审查范围。

完成条件：接受处理的风险有证据和验证，合法使用路径可用，覆盖范围与限制清楚。

可直接输入：

按指定范围检查安全问题，给出触发条件、代码位置和证据。核实后针对性修复，验证原问题与合法使用路径，说明覆盖范围和未完成的验证。

14 数据解析与转换

适用场景：处理文件、规范数据或转换结构。

顺序：specify → parse → normalize → transform → validate → test → verify。

先用保留样本及预期输出验证；按需加入 aggregate，检查缺失、重复、空值和类型。

完成条件：样本预期输出一致，关键规则通过，数量和异常记录可核对。

可直接输入：

明确输入、输出及规则，用保留样本验证解析、规范化和转换。检查缺失、重复、空值、类型和数量，核对预期输出，再按同样规则处理完整输入。

15 构建发布和运行验证

适用场景：完成开发后准备版本或部署。

顺序：test → build → /review → document → changelog → package → deploy → smoke test → monitor → verify。

部署以明确的环境、版本和发布权限为前提。保留确定的恢复版本，验证失败时按约定条件处理 rollback。

完成条件：构建与相关检查通过，目标环境关键路径及健康状态符合要求，交付信息可追溯。

可直接输入：

准备指定版本的交付：运行相关测试与构建，审查改动，更新文档和变更记录并打包。任务包含发布且环境、版本和权限明确时部署，随后检查主要流程与运行状态，记录结果和恢复版本。

16 补充文档和交付说明

适用场景：更新 README、示例、注释或版本说明。

顺序：inspect → document → write examples → verify → changelog → summarize。

按任务选择 write README、comment 或 changelog；环境允许时执行示例并检查链接。

完成条件：说明与当前实现一致，关键命令和示例已核验，未验证内容和范围清楚。

可直接输入：

以当前代码及已验证行为更新文档、README 和示例。核对运行命令、配置、链接和示例，实际执行能运行的部分，总结改动、验证结果和剩余限制。

复测与结束条件

1. 明确结果。写清功能行为、关键边界、运行环境和验收方法。

2. 用证据核实 review 发现，再决定是否修复；每次修改后运行相关检查。

3. 修复完成后，重跑原复现步骤或对应测试，并按修改范围复查。

4. 页面和动画包含实际预览操作，性能优化包含可比较的测量数据。

5. 需求满足、相关检查通过、接受处理的重要问题解决后结束。检查无法运行时，记录具体原因与影响。

6. 达到约定时间或预算、继续尝试不再带来新证据，或遇到无法自行解决的阻塞时，说明已完成内容、证据和下一步所需信息。

停止条件参照 OpenAI 的迭代修复工作流。词条释义、12类划分及16条流程是为日常使用整理的组合，具体步骤按项目需要选用。

容易混淆的任务表达

官方参考

• OpenAI 提示指南

• Codex 最佳实践

• 迭代审查修复与验证

• Codex CLI 内置斜杠命令