提示词不是越复杂越好：我给 Codex 写前端任务时，只保留这 4 类信息

孙梦⁶⁶⁶₆₆₆666

177人浏览 · 2026-07-31 09:40:47

孙梦⁶⁶⁶₆₆₆666 · 2026-07-31 09:40:47 发布

上一篇我讲了怎样把一个完整的前端需求拆成可验收的小任务。

任务拆开以后，还有一个问题很容易被忽略：每个小任务到底该怎样交给 Codex？

不少人会继续在提示词上做加法。担心 AI 忘记项目规范，就把技术栈、目录结构、代码风格、组件规则、接口规则和测试命令全部复制进去；担心它理解不准确，再补几个示例；担心它擅自修改，又连续写几遍“不要改无关代码”。

最后，一次局部修改的提示词可能比需求文档还长。

我不否认长提示词有用。有些复杂任务确实需要大量背景和约束。但“信息很多”和“当前任务需要这些信息”不是一回事。提示词越来越复杂，往往没有消除不确定性，只是把真正重要的内容埋得更深。

我现在更在意的不是写了多少，而是 Codex 在动手前能不能准确回答四个问题：

这次只要完成什么结果？
判断和修改需要依据哪些事实？
哪些边界绝对不能越过？
最后拿什么证据证明完成？

如果这四件事是清楚的，提示词可以很短；如果这四件事不清楚，再加十段“请认真分析”也补不上。

复杂提示词最麻烦的，不只是占用上下文

我对复杂提示词的警惕，主要来自三个工程问题。

第一，所有信息看起来都同样重要

假设我给 Codex 这样一段任务：

请完善用户列表的重置功能。项目使用 Vue3、TypeScript 和 Element Plus，
请使用 Composition API，代码要优雅、健壮、可维护，符合最佳实践。
项目里有公共分页组件、请求封装、权限指令、弹窗组件和消息提示方法，
请尽量复用。不要修改无关文件，不要引入新依赖，不要影响已有功能，
注意 Loading、异常处理、空数据、权限、响应式布局和代码格式。
修改后请仔细检查，确保没有任何问题。

这段话看起来很稳妥，实际上最关键的信息仍然缺失：

“重置”之后页码要不要回到第一页？
是只清空筛选条件，还是清空后立即重新查询？
当前列表的查询状态由谁维护？
哪个现有页面才是正确参考？
“没有任何问题”具体怎样检查？

与此同时，Vue3、Element Plus、Composition API、公共组件、异常、权限、响应式等信息都挤在一起。Codex 看到了一堆要求，却未必知道哪一条直接决定本次重置行为。

复杂提示词的第一个风险，就是把优先级写平了。

第二，重复规则会制造冲突

成熟项目的规范通常已经存在于多个地方：

项目的 AGENTS.md。
目录内更具体的规则。
本地 Skill。
代码中已经形成的实现范式。
当前任务的临时要求。

如果我每次都把这些内容重新复制进提示词，迟早会出现不一致。

项目规则要求复用统一的 mess 方法，任务提示里却还保留着旧版的 ElMessage；现有页面已经统一使用某个弹窗封装，提示词示例却来自另一套写法；项目要求保存失败后保留用户输入，复制来的通用模板却写着失败后重置表单。

这时问题已经不是“提示词够不够详细”，而是 Codex 面前同时摆着几份不同版本的事实。

规则重复一次，就多一个漂移点。

第三，过程写得太细，反而掩盖结果

有些提示词会把实现步骤写到非常具体：

先定义一个 reactive 对象，再写 resetSearch 方法，然后把 pageNum 设为 1，
接着调用 getList，最后在按钮上绑定 click 事件……

如果这些步骤来自对现有代码的准确理解，当然可以直接指定。但更多时候，我们只是提前猜了一套实现。

也许当前项目用的不是 reactive；也许分页状态由组合式函数统一维护；也许重置按钮已经经过公共组件封装；也许查询方法不叫 getList。

前端任务里，人的职责应该是确定业务结果、风险边界和验收标准。至于具体在哪个函数改、是否需要新增辅助方法，应该先读现有代码再决定。

把未经验证的实现猜测写得越细，Codex 越可能认真执行一个错误方案。

我只在当前任务里保留四类信息

我现在会把一次性的任务提示控制在四个区块。不是每个区块都要写很多，但它们的职责不能互相替代。

第一类：唯一目标

目标只回答“这次完成后，哪个可观察行为发生变化”。

例如：

修正用户列表的重置行为：
点击重置后清空姓名和状态筛选，将页码恢复为第一页，并用默认条件重新查询。

这比“完善重置功能”多了几个关键状态，也比一整段技术说明更容易验收。

目标里不放项目背景，不放通用规范，也不写“顺便优化”。如果一句话里出现“同时”“另外”“顺便”，我会先检查它是不是混进了第二个任务。

对前端开发来说，一个好目标通常能说清三个东西：

触发动作：用户做了什么。
状态变化：页面和请求发生了什么。
最终结果：用户看到什么。

目标明确以后，后面的信息才知道该围绕谁服务。

第二类：完成任务所必需的事实

这里不是“把项目介绍一遍”，而是只提供会影响本次判断的事实。

针对上面的重置任务，可能只需要：

相关文件：
- src/views/user/index.vue
- src/api/user.ts

正确参考：
- src/views/role/index.vue 中的搜索与重置流程

已知现状：
- 查询条件和分页保存在同一个 queryParams 对象中。
- 点击查询时，现有逻辑会先把页码设为 1。
- 列表请求必须继续使用当前模块的 getUserList。

这里有一个重要区别：事实不是要求。

“查询条件和分页目前放在同一个对象里”是现状；“本次不拆分这个对象”才是边界。把事实和要求分开，Codex 才知道哪些内容用于理解项目，哪些内容必须遵守。

我也不会在提示词里粘贴整份文件，除非当前环境无法直接读取。既然 Codex 可以查看工作区，告诉它正确的入口和参考实现，通常比复制大段代码更有效。复制出来的代码失去了路径、调用关系和周边约束，还可能在下一次修改后立刻过期。

第三类：硬边界

硬边界只保留违反后会扩大风险或改变需求的内容。

例如：

边界：
- 不修改公共分页组件和请求封装。
- 不改变现有接口字段。
- 不新增依赖。
- 不调整与重置无关的页面结构和样式。
- 如果参考页面与当前页面的行为冲突，先报告，不自行统一。

我不会在这里堆“代码要优雅”“注意可维护性”“尽量健壮”这类正确但不可判定的话。它们适合作为长期代码审查原则，却很难指导一次具体修改。

硬边界应该能回答一个简单问题：如果 Codex 违反了这一条，我能不能在代码差异或页面行为中明确指出？

如果不能，这条约束可能还需要改写。

例如：

模糊表达	可检查的边界
不要影响原功能	不改变查询、翻页和权限判断的现有行为
尽量少改代码	只修改用户列表模块；公共能力如需调整先报告
保持代码优雅	复用当前模块已有查询方法，不新增同类状态和请求封装
注意异常情况	请求失败后结束 Loading，保留当前筛选条件并使用既有错误提示

边界不是语气更严厉，而是结果更容易检查。

第四类：验收证据

最后一类信息经常被写成“完成后检查一下”。

我会改成明确证据：

完成后提供：
1. 修改文件及每处修改的原因。
2. 重置前后 queryParams 的状态变化。
3. 已执行的类型检查或项目现有检查命令及结果。
4. 页面验证路径：设置条件并查询 → 翻到第二页 → 点击重置
   → 确认条件清空、页码为 1、请求参数恢复默认。
5. 无法验证的部分和剩余风险。

“要求证据”和“要求 Codex 宣布完成”是两回事。

前者让我看到它依据什么判断，后者只会得到一句更肯定的结论。

尤其是页面任务，代码层证据不能替代交互证据。类型检查通过，只能说明某一类静态问题没有出现；它不能证明点击顺序正确，也不能证明 Loading、页码和请求参数在连续操作中保持一致。

长期规则不要反复塞进当前提示词

把当前任务压缩到四类信息之后，另一个问题自然出现：项目长期规范放哪里？

我的划分方式是：

信息类型	更适合的位置
这一次要完成的目标和特殊边界	当前任务提示
每次都要遵守的仓库规范、检查命令、审查要求	`AGENTS.md`
可跨任务重复执行的专项流程、参考资料和脚本	Skill
当前代码真实的数据流、调用关系和实现方式	让 Codex 读取工作区
是否完成以及完成到什么程度	检查结果和页面验收证据

OpenAI 当前的 Codex 定制文档也把这些层次分开：AGENTS.md 用于持续生效的项目指引，Skills 用于可重复工作流和领域能力，并且明确建议让 AGENTS.md 保持精简，只沉淀真正重要、反复出现的规则。

这个划分对前端项目很有价值。

比如 Vue3 后台管理项目中，“统一使用哪个弹窗封装”“列表请求怎样处理 Loading”“提交按钮如何防重复点击”，如果已经是稳定且长期适用的规则，就不该靠每次复制提示词来维持。

当前任务只需要说明本次的特殊差异。

规则有固定归属以后，提示词自然会变短，而且不容易出现多个版本。

我怎样删掉一份过度复杂的提示词

拿到一段很长的任务说明时，我会按下面的顺序做减法。

第一步：删除没有验收含义的形容词

先找这些表达：

专业一点。
优雅一点。
尽量完善。
全面考虑。
确保没有任何问题。
使用最佳实践。

它们不是一定不能出现，但如果后面没有具体标准，保留也不会增加多少约束。

“优雅”可以改成“复用现有方法，不新增重复状态”；“完善异常处理”可以改成“请求失败后保留筛选条件并恢复按钮状态”。

能转成行为就转，不能转就删。

第二步：合并重复规则

“不要修改无关代码”“不要扩大范围”“只做必要修改”表达的是同一件事。

我会合并成一条：

只修改当前用户列表模块；如果完成任务必须调整公共能力，先说明原因和影响范围。

同一个要求只出现一次，位置固定，强度反而更高。

OpenAI 当前模型提示指导也建议使用更精简的提示、让每条指令只出现一次，并保留真正承载产品要求或已验证缺口的示例。当然，这不意味着“越短一定越好”，具体效果仍然应该放到代表性任务中验证。

第三步：把长期内容移出当前任务

技术栈、目录约定、检查命令、公共组件使用规则，如果每次都会用，就应该沉淀到项目指引或 Skill 中。

这里的“移出”不是删除，而是给信息找一个稳定位置。

如果一条规则只对当前目录有效，就放到更靠近该目录的位置；如果它是一套跨项目可复用的流程，再考虑 Skill。不要为了缩短提示词，把必要约束直接扔掉。

第四步：删掉未经读代码验证的实现步骤

像“必须新增一个组合式函数”“把所有状态改成 Pinia”“用某种最新写法重构”，如果没有先看当前实现，就先从任务里拿掉。

可以改成：

先读取相关页面和相近实现，说明准备复用的现有模式；不要为了局部功能引入新的状态管理方式。

这句话仍然有方向，但把实现判断推迟到了有代码证据之后。

第五步：补回真正缺失的验收条件

删到最后，提示词可能只剩十几行。此时再检查：

是否有唯一目标？
是否提供了正确入口和可信参考？
是否写清不可越过的边界？
是否能用具体步骤验收？
遇到冲突时是否知道该停下来？

如果这些都有，短不是问题。

一份我会实际使用的精简版本

把前面的用户列表重置任务整理后，可以变成这样：

## 目标

修正用户列表的重置行为：点击重置后清空姓名和状态筛选，
页码恢复为第一页，并用默认条件重新查询。

## 必要事实

- 相关文件：`src/views/user/index.vue`、`src/api/user.ts`
- 参考实现：`src/views/role/index.vue` 的搜索与重置流程
- 查询条件与分页当前保存在 `queryParams` 中
- 继续使用现有 `getUserList`，不要新增同类请求方法

## 边界

- 不修改公共分页组件、请求封装和接口字段
- 不调整与重置无关的结构和样式
- 如果参考实现与当前页面存在冲突，先报告再决定

## 验收

1. 设置筛选条件并查询
2. 切换到第二页
3. 点击重置
4. 确认筛选清空、页码为 1、请求参数恢复默认
5. 运行项目现有类型检查，并报告结果
6. 列出修改文件、未验证项和剩余风险

它不长，也没有“你是一名资深 Vue 工程师”这样的角色设定，但任务结果、依据、边界和证据都在。

真正缺失的信息，仍然不能靠这份模板自动补齐。例如参考页面是否可靠、重置后是否应该立即请求、失败后旧数据是否保留，都要根据项目实际情况决定。

模板只能帮助我暴露问题，不能替我做业务判断。