本文所列举的提示词均适用于 GPT-5.5 及以上模型，对于比较愚笨的模型如 MiniMax 并不适用——它们往往需要更多的黑名单和白名单约束。
本文所有提示词均在 CNB 云开发 上使用 Codex 配合 GPT-6-Astra Max 下测试通过。
快速配置工作区
在 个人设置 > 云原生开发 设置个人环境变量，然后进环境，打开终端输入：
curl -fsSL 932.moe/agents | bash会使用 mise 自动配置 Codex 和 Pi 两个 Harness 框架，等待数秒即可使用
使用 mise 管理你的依赖
mise 是一个开发环境管理工具，可以统一管理 Node.js、Python、Go、pnpm 等工具的版本，也支持配置环境变量和定义项目任务。你可以把项目需要的工具、版本和常用命令写进 mise.toml，让开发环境的配置跟着代码一起维护。项目使用的第三方库，则继续由 pnpm、uv 等包管理器及各自的锁文件管理。
我觉得 mise 很适合 AI Agent 使用，因为它把环境准备变成了一套明确的配置和命令：Agent 可以先读取 mise.toml，了解项目需要什么，再通过 mise install 安装工具；执行命令时，使用 mise exec -- <命令> 就能加载项目配置的工具和环境，无需依赖交互式 Shell 的初始化过程 —— 对于经常通过独立终端进程执行命令的 Agent，这一点尤其方便。
如果再把测试、构建和检查定义成 mise 任务，Agent 就可以通过 mise run test、mise run build 等固定入口执行操作，减少大型多语言仓库中反复查找命令和手动拼接环境变量的过程
在团队协作中，我更推荐固定工具的具体版本。以使用 Node.js 和 pnpm 的项目为例，可以执行：
mise use --pin node@24 pnpm@12这里的 --pin 会把解析出的完整版本号写入配置。例如，node@24 用来选择版本范围，最终记录的是具体的 24.x.y，让后续安装有明确的版本依据。
将生成的 mise.toml 提交到仓库后，其他成员、Agent 和 CI 就可以根据同一份配置准备工具。这样，工具版本和项目依赖都有了可追踪的依据，能减少「我这里能跑，你那里报错」的排查成本。
向 AI Agent 许愿
进入 Plan mode (一般都是 /plan)，发送以下信息：
阅读一下工作区，我希望实现【这里许愿】，请你调研一下可行性一般这个时候 AI 就会开始研究项目环境，思考计划了。等 AI 给出了 Plan，就可以让他去实现。这样做出来的项目比没有规划的项目质量高出一个层级。
如果你不希望让 AI 在后面问你问题，可以挂个 Goal，内容为：
按计划完成项目构建，不要问我任何问题 —— 查看计划书或按最佳选项帮我选择让 AI Agent 推送通知
CNB 个人设置里支持 文件漫游，可以让 Agent 写一些推送脚本，放入 ~/.cnb 下，这样每次打开工作区都可以使用下面的提示词：
完成后，请先阅读 `/root/.cnb/push-ntfy.md`，再按说明调用 `/root/.cnb/push-ntfy.js` 推送本次任务结果。未完成时，使用 `date` 命令查询当前时间，每隔十分钟推送一次进展让 AI Agent 沉淀文档
如果你不希望你的要求被无视，就在提出要求后，在 /btw 模式下让 subagent 将你刚刚的要求固化到 AGENTS.md。由于 btw 模式的 subagent 会有历史记录，所以无需复杂操作即可固化文档。
将我刚刚的那些要求固化到 AGENTS.md我建议固定两个产物：
- 项目 README：决策与理由
- CHANGELOG：因为这些决策，所以我做了什么
并且每篇 CHANGELOG 文档尽量包含现象、原因、解决方案、验证方法，这就是给未来的其他 Agent 省时间。
让 AI Agent 生成 Git commit message
一般情况下用下面的提示词就够了：
查看工作区变更，按标准编写 commit message（需要 scope 和 body）输出到对话里。不提交，不推送如果你的 AGENTS.md 里有 Git 写入操作二次确认的话且不是特别蠢的 AI，就不需要后面的 输出到对话里。不提交，不推送。
让 AI Agent 在提交前审查代码
代码写完、测试通过之后，我会让 AI 再做一次代码审查，重点检查正常流程之外的问题，比如边界条件、异常处理，以及改动对其他调用方的影响。
请审查本次任务的全部代码改动，包括尚未提交的修改，结合相关实现、调用链和测试查找可能导致错误或行为回归的问题，按严重程度列出问题位置、触发条件、实际影响和修复建议，明确区分已确认的问题与待验证的推断，暂不修改代码。这里我比较在意的是「触发条件」和「实际影响」。一句 这里可能有问题 很难帮助我判断是否需要修改；如果 AI 能说明什么输入会触发问题、哪条调用路径会受到影响，审查结果就更容易验证，也方便后续补充回归测试。
加上「暂不修改代码」，则是为了先保留一份清晰的问题清单，等确认哪些问题需要处理之后再让 AI 逐项修复并验证，同时避免污染工作区既有改动。
AGENTS.md
AGENTS.md 是一个普通的 Markdown 文件，用来描述项目背景、开发约定、验证方式，以及 AI 应该如何与你协作。支持这个约定的 AI 编程工具，会按各自的加载规则读取它，并将内容纳入工作上下文。常见做法是在项目根目录放一份通用规则，再按需为子目录补充更具体的要求；自动加载的范围和规则优先级，需要以所用工具的实现为准。
我推荐使用它，是因为它能把反复口头提醒的要求变成可维护的文本：换会话时少重复交代；团队成员可以共同修改，放进 Git 后还能追踪规则为什么发生变化。我的做法是把长期稳定的协作要求写进文件，把本次任务的目标和临时条件留在对话里。
除了项目结构、启动命令、测试命令这些基础信息，我更推荐补充以下几类规则，它们决定了 AI 会如何推进任务：
-
先研究实际情况，再制定方案。 要求 AI 先阅读相关实现、接口和依赖，方案中写清交付范围、完整使用流程、关键约束、验证方式和完成条件
开发一个功能，要考虑它如何接入现有系统、用户如何使用、怎样确认做完，不能只有一份看起来很完整的排期，但实际上只是一个空架子
-
获得实施授权后，持续推进到交付。 我会明确要求：
用户已经要求实施时，继续完成实现、集成和必要验证，不停留在计划或局部示例需要反馈进展时，区分「已实现」「已验证」和「未完成」。这样能减少「代码写了，所以任务完成了」这类误判，也方便我判断接下来是否需要介入
-
把提交规范写到可执行的程度。 如果工作流涉及 Git 提交，就写清身份配置、提交标题和签名要求
我的约定是：执行已获授权的提交时，使用指定的本地身份与签名配置，提交后确认签名有效；签名失败就解决或报告。跨仓库任务还要保持主题 subject 一致（便于提 Issues 时对齐），同时在 body 准确描述每个仓库自己的改动
如果刚开始写，可以先放入几条最常用的协作要求，再逐步补充项目自己的命令和约束：
# 协作约定
- 制定方案前，先阅读相关实现、接口和依赖
- 方案需说明交付范围、关键约束、验证方式和完成条件
- 用户明确要求实施后，持续完成实现、集成和必要验证
- 及时反馈实际进展和阻塞，区分已实现、已验证与未完成
- 未执行的检查明确标注为未测试，不把推测写成验证结论
- 遵守约定的测试范围；需要扩大范围时，说明原因及所需条件
- 提交、发布和清理操作遵守已约定的授权范围与项目规范AGENTS.md 也需要持续整理，具体固化写法可以参考上方的单句提示词部分。