工程实践
一年 2 万 contributions 之后，我把 setup 公开了
读完 Matt writing-for-agents 和 Lauren/pstack：正面指令、结构先于规则；落到 harness 硬闸门和 stometa-mode。仓库可抄。
Stometa
过去一年我在 GitHub 账号 stone16 上攒了 20,189 次 contributions。这个数字包含 issue、PR 和 review 等日常活动，不等同于纯 commit 数量，但它确实反映了我每天都在跟 agent 一起写代码、改东西。我把这套日常在跑的公开 setup 整理到了 GitHub 仓库 harness-engineering-skills（和个人主页 stone16 的链接都放在文末），方便大家直接抄作业。里面汇总了我摸索出来的 best practices，也记录了我对照 Matt Pocock 和 Lauren（pstack）的原则对整套工作流做的更新。
这篇东西想顺着一条工程演进的脉络往下聊：先是从 Command 走到 Skill，接着发现单靠命令不够用了，开始拆解 Prompt、Harness 和 Loop 的分工，再到行业里掀起 Loop engineering 热潮，最后落回个人 agent 时代怎么把 Loop 跑明白，以及我最终收出来的 stometa-mode。
先当路标，不写流水账
聊主线之前先拿几个行业节点当引子。Opus 4.5 在 2025-11-24 发布，年底那会儿让不少人吃了一惊，接着 Opus 4.6 在 2026-02-05 出来。到了 2026 年 3 月，OpenClaw 龙虾热冲到顶峰，同一周前后 jackwener 在 2026-03-14 创建了 OpenCLI，我这边的 harness 公开仓也在 2026-03-11 挂了出来。这波密集的折腾说明大家都看清了一个事实：指望靠一句长 prompt 让 agent 长时间无人值守，在工程上根本撑不住。
Matt：正面指令，可核对的 done
为了解决长链路失控的问题，我先去读了 Matt Pocock 那套 writing-for-agents。他给出的原则非常直接：给 agent 下指令要写正面要求，少堆砌不要做什么的禁令；删掉那些不痛不痒的 no-op 条款；文档必须压短；完成标准必须能核对。这些话听着像常识，但你真打开自己的 AGENTS.md 对照一下，就会发现里头有一半条文都在写给人类自己做心理安慰。
Lauren：结构先于规则
接着我又去看了 Lauren（pstack）的做法。她的重心放在怎么用工程结构替代散文规则，而不是盲目多装几个 skill。踩过的坑应该沉淀进目录结构、playbook 和 verification 脚本里，避免每次出问题就往文档里追加一条文字禁令。每次跑完 reflect 都要紧接着做 correct，毕竟原则和 playbook 是写给下一轮 agent 干活用的，写得自己再感动也没用。
我怎么接到 stometa-mode
我吸收这两套思路的过程也有明确的先后顺序。最早是零散的单点 Command，后来不够用了，就先跑 automate-me，把手头高频重复的操作收成可编排的 Skill，再打包成 -mode；随后开始写 stometa-mode，把 Matt 的 grilling、to-spec 和 pstack 的 correct、verify 编排进同一张 skill 路由表里。
具体跑起来的时候，定方向阶段用 grilling 追问加压，需求收敛成 to-spec，写代码前后用 how/why 对齐意图，验证环节挂上 verification，跑完一轮复盘走 reflect 到 correct。
光有路由表还不够，底层的硬闸门全交给 Harness 托管。Plan、Generate、Evaluate、Retro 这四个阶段直接由引擎往前推，每个 checkpoint 都会拉起全新的 agent，必须通过跨厂商的 peer review 才能开 PR。模型在对话框里口头说自己 pass 一律不算数。
最终收出来的 stometa-mode 本质上是一张路由表加上一套清晰的 provenance 记录：里面标明了哪些机制改编自 poteto-mode，对应的 pinned commit 是哪个，以及本地环境怎么绑定 Linear 和 gh。现在公开仓已经把 review-loop 和 harness 放了出去，任何人都可以照着 README 装好插件，在自己机器上跑一遍这套引擎闸门。
今天就能抄走的两样
如果你今天看完只想先抄两样东西回去试，我建议直接拿走下面这两个可以直接粘贴的组件。
第一个是 /correct 运维清单：
-
先查目录结构与文件放置是否防呆
-
再查类型定义与编译检查能否直接拦住错误
-
接着看 lint 规则或 verification 脚本能不能自动化校验
-
前面三条都兜不住，最后才去改散文规则
（如果顺序反过来，correct 往往只会反复修改文档措辞，根本拦不住同一个问题下次换个姿势复发。）
第二个是短 AGENTS.md 骨架，可以直接粘进去再改占位符：
AGENTS.md
## Workflow
1. Read <path-to-brief>
2. Restate goal in one sentence
3. Run <cmd-or-skill>
4. Edit only <dir-or-files>
## Tools
- Checks: <lint-or-verify-script>
- PRs: gh
- Issues: Linear (or your tracker)
## Done when
- [ ] <command> exits 0
- [ ] <test-suite> green
- [ ] Evidence saved at <path>
不要写尽量注意。写完必须能核对。
链接
-
Matt writing-for-agents；Lauren / pstack
correct+ poteto-mode（provenance pinned）
首发于 X（2026-11-05）：原文