目标外壳和 5 条配套提示词
一个偏好写了三处还要说第四遍:一个目标外壳,加组件库、并行、互审、交互状态、纠正清单 5 条。
309 X 收藏,截至 发帖日期
任务:{你的任务}。先给自己写一个完整的端到端目标,然后一直做下去,直到架构和结果都达到标准。
拆分:把这个目标拆成相互独立的部分,只在工作确实允许的范围内并行。每个执行者的目标都写明自己的交付物、怎么验证、怎样算完成,以及可以改哪些文件。
每完成一个有意义的步骤:真正地测试真实的东西,完整端到端,加上 computer use、浏览器、按键,需要什么用什么。自动审查,然后 commit,然后把进度写到项目里合适的地方。
收尾:对所有内容做一次专门的审查。
完成 = 生产级别,真实用户可以直接上手使用。下一步 换上你的任务,在项目里发给 Claude Code 或 Codex。
别再跟 Claude Code 或 Codex 说「做这个」「写代码」「修这个 bug」了。
你把同一个偏好写进 CLAUDE.md,又写进一个 skill,下一个会话里还要再打一遍。写了三个地方,它还是要你说第四遍。这 6 条提示词越用越好用。
- 并行的端到端目标
把 {你的任务} 换掉就能跑。新功能、重构,都一样。不要写死进度文件的路径:让它写到合适的地方,它自己会找到位置。两个会写文件的执行者,各用一个 worktree。共用一个 checkout 会在文件和 git index 上冲突。只读的执行者可以共用。
这就是目标外壳。下面的每一条都通过它来跑。
- 先做设计系统,再在组件库里做无障碍
任务:把散落的 UI 组件、样式 token 和重复的交互收进一个组件库。手写的一次性组件全部替换,所有新 UI 都走组件库,不许绕过。这是一次重构,所以先在 worktree 里开始。
然后:在组件库这一层修好无障碍。对比度、字号缩放、键盘(Tab / Enter / Space / Esc)、焦点状态,以及图片、图标按钮、表单和状态的语义。
验证:从当前 commit 在本地启动应用,在桌面、平板和手机上走一遍核心路径。重叠、溢出、截断、横向滚动,逐个修好。
收尾:记录改了什么、还剩什么风险,然后写一个 review skill,下次动 UI 之前先跑它。
完成 = 低视力、只用键盘和使用不同设备的用户都能完成核心操作。把这条放进目标外壳里跑。在组件库里修一次,用到它的每个组件都会继承。页面层面还要单独过一遍:标题层级、路由切换后焦点落在哪里、live region、图片 alt。
- 在一台机器上跑多个 agent
安装:brew install herdr。终端里的 agent 多路复用器。worktree、窗格和 agent 状态集中在一个地方。
worktree:每个会写文件的 agent 一个,只读的 agent 可以共用。herdr worktree create --branch <name> --base <base ref> --json
启动:在一个窗格里启动它,模型家族自己选。herdr agent start <name> --kind claude --pane <pane id>,或者 --kind codex
运行:派发任务,然后等待状态。herdr agent prompt <target> "<its own full goal>" --wait --timeout 600000
完成 = 没有 agent 还在工作,每个 worktree 都已 commit。用目标外壳给每个 agent 写它自己的目标。不加 --timeout,就会无限期地等。写 --until done 会漏掉 blocked 状态,卡在权限提示上的 agent 就会一直等下去。默认值已经覆盖了 idle、done 和 blocked。
- 让两个模型家族互相审查
commit:谁写的代码谁 commit,并报告短 hash。git rev-parse --short HEAD
审查:把这个 hash 交给另一个家族。herdr agent prompt <the other one> "review commit <short hash> in <path>. run git show --stat <short hash> first and quote the hash back to me. then go item by item: what is wrong, what the evidence is, whether a test can prove it wrong. write the test when it can. judgement only, do not touch the code." --wait --timeout 600000
规则:不审自己的工作,不审同一家族的工作,不审没 commit 的工作。
完成 = 每个分歧都有结论。能测试的就写测试,测试结果高于双方意见。品味问题由你决定,并记录被否决的方案和原因。让它读 commit,别用 git log -1,那条命令报的是它自己 worktree 的 HEAD。commit 不可变,并且在各个 worktree 之间共享。你没 commit 的工作正是它看不到、也一直在变的部分。
「结合两者的优点」不是综合。这句话说明根本没有做比较。
- 一次排查所有交互状态
任务:把下面三张表当作检查清单,找出这个项目缺了哪些状态,按影响大小补上。不新增抽象,不改现有的视觉语言。不适用的标为 N/A,不要硬编一个出来。
每个视图五种状态:空白 / 加载中 / 部分数据 / 出错 / 有数据。搜索和筛选再加一个无结果状态,首次使用再加一个零状态。
每个控件七种状态:默认 / 悬停 / 焦点 / 按下 / 加载中 / 禁用 / 选中。焦点是键盘用户知道自己在哪里的唯一方式,也最常缺失。
每个异步操作四种状态:空闲 / 进行中 / 成功 / 出错。凡是立即更新 UI 的操作,都要有失败时的回滚路径。
验证:每修一处,先在真实设备上走一遍那条路径,再做下一处。
完成 = 每一格都有答案或 N/A。把这条放进目标外壳里跑。200ms 以内就能返回的操作,不要显示加载动画。一闪而过比短暂等待观感更差。
- 让它交回这一轮学到的东西
任务:结束时,列出这一轮里我纠正过你两次或以上的所有事项,每行一条。
每行包含三项:我两次纠正分别在哪里、什么时候应该触发、用一句话写出规则。
规则:只列清单。不建文件,不改配置。等我报出编号。
规则:只纠正过一次的不要列。一次是偶然,会变成噪音。
完成 = 清单已交出,没有动任何配置文件。在目标外壳的收尾步骤之后跑这条。这样做十次,你批准过的规则就积累起来了。到第十一次,它会在写目标之前先读这些规则,起点就比第一次高。
