别急着怪 Opus 5.5，长任务先写清什么叫完成

长任务跑不完，预算先见底。推文作者 beamnxw 把问题拆成 15 个 Claude Code 命令和一套 7 层 harness。核心不复杂：让每次 run 留下能打开的结果、能检查的证据、明天还能接着做的进度。

有网友 CooperCode 在回复里把很多“模型跑丢了”的抱怨归到 harness 从没定义 done。这句话比命令清单更值得记。模型能力当然重要，可长任务失败经常发生在流程层：目标没写成可验证条件，上下文没压缩，子任务没隔离，进度没落盘。预算常被一串没有 finish line 的 turn 磨掉，单个大错误反而少见。

15 个命令可以按用途看：

用途	命令	解决什么
目标	/goal	盯住可验证终点，评估器每轮检查
计划	/plan	改代码前先审计划
并行	/batch	把大改拆给并行 agent
委派	/subtask	用当前上下文开子任务
研究	/deep-research	带来源做研究
设计	/design	生成可编辑画板
指令	/memory	管理项目指令
上下文	/compact	围绕关键决策压缩上下文
分支	/branch	开独立对话分支
回滚	/rewind	恢复 tracked checkpoint
工具	/mcp	管理连接工具
循环	/loop	在运行会话里重复检查
定时	/schedule	自动化重复云任务
清理	/simplify	用并行 reviewer 清代码
远程	/remote-control	从手机接本地会话

命令只是入口。引用文章给了一个文档工作流示例：sources/ 放参考材料，drafts/ 放草稿，published/ 放批准文件。根 CLAUDE.md 只放跨任务有用的事实，比如输出位置、来源要求、写作约定。重复流程写进 skill，例如 /write-draft。外部资料用 MCP 接进来。权限和 hooks 放在执行层，禁止读 .env，禁止改 published/。reviewer 做成 subagent，只给读和搜索工具，要求返回 claim、verdict、source URL、correction 的表。effort 按任务分配。最后用 /goal 把完成条件写死。

/goal 的细节值得单独说。官方文档写得很清楚：evaluator 只看 Claude 在对话里展示出来的内容，不跑命令，不读文件。所以条件要写成输出能证明的东西。比如“test/auth 下所有测试通过，lint 干净”，或者更具体“npm test exits 0”。想限制跑多久，就在条件里加 or stop after 20 turns。网友 Mohabbat 也提到这句，还提醒要命名一个 Claude 能展示的检查。这个细节比“让模型更努力”有用。

有网友（小果果炖粥）在回复里问，如果模型需要 15 个命令和 7 层 harness 才能完成长任务，瓶颈在模型还是脚手架。这个问题值得留着。命令是表面，收尾机制才是里子。先挑一个长任务，把完成条件、证据格式、进度文件写进去，再跑。跑完检查 drafts/article.md 和 drafts/checks.md 是否存在，错误 claim 是否改了，未解决的 claim 是否标了。

原文和完整 harness 文章在 beamnxw 的推文和长文。