Harness 之后,我在写 Skill

·
AIagentengineering
Contents · 4

Damien · 2026 年 5 月

上一篇 Harness Engineering 是团队视角,这一篇换成我个人。

起因是看了 Karpathy 在 Sequoia Ascent 2026 的对谈。他在那场里反复拿 vibe coding 和 agentic engineering 这两个词举例。vibe coding 大概就是”把需求讲清楚,模型帮你出原型”这种用法,门槛接近零。agentic engineering 是另一回事——你要在一群会犯错的 agent 里仍然把产品做对、做安全、能维护。

我看完想接着说一段,因为这三个月在 nexad 上做的事差不多就在第二个范畴里。除了写 feature,我有相当一部分时间在 .claude/skills/ 和它驱动出来的 plan / contracts / governance 这些规则文档上反复迭代。

一、verify 命令必须能跑

nex-dev 是我们用得最多的 Skill,负责编排一整个开发循环。它在 Plan 阶段强制要求每一项 todo 带两个字段:Verify 写一行 shell 命令,Expect 写预期输出。

举几个真实的例子:

  • 后端模块: uv run pytest tests/unit/test_{module}.py::{test} -v,期望 N passed, 0 failed
  • 前端组件: pnpm --filter @nex-studio/web exec tsc --noEmit,期望 exit code 0
  • Migration: uv run alembic upgrade head,期望 Running upgrade

加这两行的原因很直接。后面 Stage 4 的 /nex-reviewer 和 Stage 5 的 /nex-tester 是另一个 agent,它要判断这一项 todo 做完没,只需要把这行命令跑一下,看输出对不对。整个流程不依赖 agent 的自我评估——Anthropic 在 Long-Running Agents 那篇讲过自评经常会错,我们上一篇 Harness 也提过。

Karpathy 那场里讲过类似的话:LLM 真正能加速的事情,大多有清晰的验证信号,代码进步快是因为编译、测试、lint 都能给出反馈。nex-dev 把这件事写进了 todo 模板。

二、git log 看下来,docs 比代码多

我前两天翻了过去三个月在 nexad 上的 git log,Damien 一作 249 个 commit。按一级目录看修改文件次数:

  • docs/: 2741
  • apps/: 681
  • packages/: 428
  • agent/: 381
  • tests/: 374
  • .claude/: 32

.claude/skills/ 我自己只动过 8 次,数量不多。但 docs/ 这 2741 次背后,有不小比例是 Skills 强制生成或维护的:docs/process/active/{feature-name}/plan.md 是 nex-dev 在 Plan 阶段生成的,docs/modules/{module}/contracts.md 是 nex-doc 触发更新的,docs/governance/ 装的是 Delivery Tier 那套治理。Skills 自己代码量不大,它们驱动出来的文档比业务代码更密集。

我每天大部分输出还是 feat、fix 这种代码工作。但围绕代码的 plan、todo、contracts、Verify,这些机器可读的规则文档正在变成主要产出。

Karpathy 那场里说工程师未来更像 director——负责调度、审定。我看自己 git log 时直观的感受就是这样。

三、agent 不能拍板的那部分

nex-dev 的 Plan 阶段还有一块东西叫 Open Decisions board。它是个列表,放 agent 不能自己拍板的事,比如:

  • 这个 feature 的 Delivery Tier 选 T0 还是 T2(决定后续审查强度)
  • 一个新模块的 IA 怎么切
  • frontend 用哪种交互范式
  • 某个抽象现在做还是先放着

这些事的共同点:没有 shell 命令能验证它”做对了”。对错要等几周甚至几个月后才看得出来。agent 默认会选最像训练数据的那一种,结果通常中庸。

Plan 阶段的处理是设一个停顿:看到 Open Decisions 上有未决项,就要求工程师手动选一次。这跟上一篇 Harness 讲的 Delivery Tier 治理是配套的:Tier 处理已经写成规则的事;还有一类没法写成规则、但每次都得有人定的事,就靠 Open Decisions 把它从默认流程里挑出来。

Karpathy 在那场里也说过,AI 写出来的代码经常 gross——能跑,但臃肿、脆弱、抽象错位。这部分要靠人。我们做 Open Decisions 是同一个意思,把”靠人”具体化成工作流里的一个步骤。

收尾

Harness 那篇主要讲已经能写成规则、用 lint 或 hook 卡住的部分。这一篇说的是 Open Decisions——还没写成规则的那一类。nex-dev 让它跟 Verify 命令并排放在 Plan 阶段,等工程师去填。

@青年王大米 · 2026 年 5 月 · damien.me