| 约束项 | 当前状态 |
|---|---|
| 基座模式 | ✅ BASELINE_ENGINEER_MODE |
| 主模式 | ➖（文本提炼任务） |
| 特殊规则 | ➖ |
| 补充规则 | ➖ |
| 推理语言 | 中文 |
| 切换边界 | 无切换 |
1. 说结果，别写操作手册------你只定义 done 的标准，实现路径让它自己选。
✅ 把这个函数重构成可单测的，跑通现有测试。
✅ 给这个接口加缓存，响应时间压到 100ms 以内，方案你定。
❌ 第一步读这个文件，第二步改第三行，第三步......
2. 给它"接口文档"，不给它"全家桶"------只贴会影响结果的代码和报错。
✅ 附上
auth.ts+ 报错堆栈，标注"问题应该出在 token 解析"。✅ 只贴相关的 30 行 + 上下游各一个调用点。
❌ 整个仓库打包丢过去，让它自己找。
3. 约束就是你的 CI 红线------写死不能碰的东西，一两条就够。
✅ 不许改 API 结构；修复控制在最小范围，补个回归测试。
✅ 数据库 schema 不动，只准改查询层。
❌ 你自己看着办，注意代码风格哦。
4. 复现步骤比一万句描述值钱------bug 报告按 issue 模板写。
✅ npm run dev → /settings → 开关 → 保存 → 刷新 → 开关被重置。
✅ 输入 X 时预期返回 200，实际返回 500，日志见附件。
❌ 保存功能有时候不好使，你帮我看看。
5. 图片是 UI 的需求文档，但看不见的部分要用文字补。
✅ 截图 + "用 React+Vite+Tailwind，TS 写，尽量还原间距和字体"。
✅ 截图 + "悬停态、表单校验、键盘交互图里没有，规则如下......"
❌ 发张截图：照这个做。
6. 验收标准写进提示词------让它自己跑完测试再交差，别信"应该好了"。
✅ 修完重跑上面的复现步骤 + lint + 最小测试集，把命令和结果贴出来。
✅ 结束前自查：每个改动文件都要过类型检查，不过的标出来。
❌ 改完告诉我就行。
7. 一次只改一个地方------UI 调参跟小步 commit 一个道理，别一把梭。
✅ 只动页头：字体更有编辑感、加留白、移动端别崩。
✅ 这轮只简化配色，布局一行不许碰。
❌ 整体重新设计一下这个页面。
8. 你改了代码要告诉它------不然它下一轮会把你的手动修改覆盖掉。
✅ 我回退了你对 header 的改动，保留其余的，接下来改配色。
✅ 我刚手动改了变量名，以工作区当前代码为准继续。
❌ （默默 git revert 了它的改动，继续提需求）
9. 大活先出方案再动手------等于让它先提 RFC，你 review 完再 merge。
✅ 先给重构计划：职责拆分、迁移步骤、回滚策略；我确认后再实现。
✅ 先只调查不改代码，列出受影响的文件和调用链，等我拍板。
❌ 直接开始重构认证模块。
10. 能定时化的提示词才是资产------好用就固化成模板/定时任务，别每次重造。
✅ 在对话里打磨到输出稳定 → 存为模板 → 挂定时任务每周自动跑。
✅ 把验证过的提示词抽成团队共享 snippet，变量留占位符。
❌ 每周一手动重打一遍同样的需求，错一个标点结果就变样。
《Prompting》使用经验逐条总结
om/docs/prompting>（ChatGPT 官方提示词指南）
共 29 条，按使用场景分组。
一、通用提示词原则（适用于所有场景）
- 先描述结果，再谈步骤 ------告诉 AI"要什么"，而不是"怎么做"；只有过程本身重要时才写过程，其余留给它自己搜索、比较、调整。
- 四要素框架按需取用------目标（Goal）、上下文（Context）、输出（Output）、边界（Boundaries），不是必填表，哪项影响结果就写哪项。
- 短提示词是默认起点------小事一句话；只有大任务、重要任务才展开写。
- 受众和用途决定产出 ------"给谁看、看完用来干什么"会直接改变篇幅、详略和组织方式，值得写明。
- 首条提示词不必完美 ------把"看结果 → 提具体修改"当作正常流程，"迭代修正"比一次写全更现实。
二、上下文投喂经验
- 只附会改变结果的资料 ，只附会改变结果的资料,并说明每份资料要提取什么------不是附件越多越好。
- 图片任务要指认关键区域 ，不能让 AI 自己猜图里哪部分重要。
- 依赖最新信息就明确要求联网搜索，需要核对时要求附来源
- 跨对话偏好进"自定义指令"，单次对话的细节留在提示词里------两层分开，互不污染。
- **已连接数据源（Drive/Slack 等） ==只需指明"去哪找、找什么不必替它设计每一步检索。 ==
三、边界设定经验
- 边界只设一两条最关键的 ------只设一两条最关键的边界 改错就报废的地方、影响他人之前要先过目的地方。
- 典型边界句式 ：已批准的数字 不许动 / 缺信息就标注 不许猜 / 只做草稿 不许发送。
- 要求最终自检------重要任务收尾时让 AI 自查（如"每个行动项是否都有负责人和截止日期"），但你自己仍需过目。
四、Chat 与 Work 模式分工
- Chat 管轻，Work 管重 ------快问快答、短改写用 Chat；跨资料、多步骤、要交付文件用 Work。
- Work 模式先收一个可审阅的小结果 ：小结果MVP优先，限定资料范围和日期、区分"必须完成"与"可选润色"。
- 涉及发送、发布、改动他人依赖的信息，必须写明"先经我批准"。
- 发现它在做你不再需要的工时，立即收窄或叫停------额度消耗要算账，省时间/提质量/帮决策才值。
- 重复性任务的成熟路径 ：重复任务 打磨提示词 变成成熟化路径普通对话里打磨提示词 → 输出稳定 → 转为定时任务。
五、Codex 编程场景经验
- 复现步骤的价值 > 高层次描述 ------修 bug 时给"启动命令 + 操作路径 + 现象"五步走，比一百句描述管用。
- 约束要写死：不许改 API 结构、最小化修复、可行就补回归测试。
- 验证必须闭环：修完重跑复现步骤、跑 lint + 最小测试集、报告命令和结果------不许"改完就完"。
- IDE 靠自动上下文 （打开的文件、选区），CLI 必须显式给路径（
@文件、/mention）------两个界面的上下文机制不同，投喂方式不同。 - 截图转原型：图给视觉，文字给约束 ------框架、路由、组件风格、悬停/校验/键盘交互这些图里看不出来的，必须文字补齐。
- UI 迭代要小步快跑 ：一次只改一个部位；喜欢的改动立刻 commit，回退后要告知 AI，防止它下轮覆盖你的修改。
- 大重构的正确姿势：本地出计划（含迁移步骤、回滚策略）→ 审计划 → 云端委派执行 → 审 diff → 提 PR。
- 代码审查两个入口 ：本地
/review（可带自定义重点）、GitHub 上@codex review（不用拉分支）。
27.== 多步骤任务先/plan后动手 ，长任务用/goal挂持续目标。== - 执行中的消息分两种 ：Steer 立即插入当前轮（改方向），Queue 排队到下一轮（不打扰）------CLI 里 Enter=引导、Tab=排队。
六、贯穿全文的一条主线
- "人审阅、AI 干活"的分工贯穿始终------文档每个场景都以"你审阅结果"收尾：计划要批准、草稿不直发、diff 要过目、发布前自查。提示词写得再好，最后一道质检始终是人。