我前阵子想做一个基于 DeepSeek Harness 的 Agent 工作台。
它得有自己的界面，也得接住 Harness 原生的聊天。文件要能处理，Agent 干活的过程要能看见，本地数据得存下来，重新打开以后也不能全丢。听着像一堆功能，真正动手才发现，最麻烦的地方是先把边界划清楚。
如果你没接触过 Harness，把它理解成负责运行 Agent 的那一层就够了。动手前得先决定哪些东西该做，哪些东西暂时别碰。
我为什么要试这套东西
我自己的第一反应也很容易是先开干。找个模型，搭个壳子，几个小时后一个能点的东西就出来了。这个过程很爽，问题也往往从这里开始。
但再往后走两步，问题就来了。
Harness 到底管到哪，业务数据又放到哪。用户点了什么才需要确认。工作台里正在处理的业务，和底层的运行记录，怎么摆才不会让人看得一头雾水。
这些事如果一开始不聊，后面就会变成那种很熟悉的返工。页面都做了，才发现东西放错地方了。功能看着都有，拼起来却不像一个产品。
这次先把代码放在后面，把 Matt 的几组 Skills 串起来试了一遍。我这里说的 Matt Skills，是一组把产品开发拆成需求澄清、原型验证、开发说明、任务拆分和实现检查的 Codex Skills。
我平时常用的 Codex，已经把 Superpowers 那套复杂流程卸掉了。它当然有它的用处，但对我来说，维护一大套指令、一步一步盯着它微调，成本有点高。
业余时间本来就有限，没法一直坐在电脑前，一个指令接一个指令地陪着它做。Matt Skills 给我的好处很直接。如果它能把边界守住，稳定跑很久，过程中持续把测试跑过，我就可以把时间放在更该由人做的判断上。效率自然会高不少。
五个 Skills 怎么接力
01 把问题问清楚
先用 wayfinder 和 grill-with-docs 把问题问到没法再含糊。第一版给谁用，解决什么，哪些能力先不要碰，DeepSeek Harness 在这套东西里究竟是什么角色。
有个决定挺关键。Harness 就安心做运行容器，不去兼任业务资料库。工作台负责业务入口、内容组织和本地数据。
这个决定不酷，但它很值钱。后面每次遇到该把东西放哪里的犹豫，答案都已经在那里了。
02 做一个能点的原型
然后是 prototype。
我一直觉得，很多产品讨论在文档里能讲一下午，拉到一个可点击的界面上，五分钟就知道哪儿不对了。
用户从哪儿进来，主要操作顺不顺，原生聊天塞进工作台以后别不别扭，执行过程和运行记录怎么放才看得懂。先做一个原型，真点一遍，比继续对着文字猜靠谱得多。
原型不需要承担正式上线的任务。它先负责把流程里的问题暴露出来。
这一步还顺手把已有产品的视觉习惯捡了回来。正式开发时，不用一边写功能，一边临时决定每一页长什么样。
03 把讨论写成开发说明
界面和范围差不多落定后，to-spec 把前面聊清楚的东西整理成一份开发说明。
里面没有什么大词，写的都是很具体的事。这个产品为什么要做，用户怎么用，第一版必须有什么，哪些明确不做，最后拿什么判断它算不算完成。
这份东西的作用，是让人不用翻半天聊天记录，重新猜当时为什么这么决定。
04 把大问题拆成任务卡
接着 to-tickets 把大问题拆成了一张张任务卡。
跑通 DeepSeek Harness
保存工作台数据
接入文件处理
加入 Agent 执行能力
支持中断和恢复
接入原生对话
增加导出
完成整体验收
每张任务卡只管三件事，这次到底做什么，开做之前依赖什么，做完以后怎么检查。
没有什么玄学，就是把一坨大而模糊的事，拆成今天能动手、做坏了也知道从哪儿回去看的小块。
05 让实现和检查一起发生
真正开做以后，implement 接手。
每张任务卡会开一个独立会话，统一用 GPT-5.6 Terra / High。主会话不冲进去一起堆代码，它只管排顺序，守住边界，最后把结果再过一遍。
这块我觉得挺重要的。
AI 最容易给人的错觉，就是它说自己做完了。然后你一看，能跑，甚至还有截图。可你真把数据升级一遍，重启一下程序，再按用户的路径走一遍，事情往往才刚刚开始。
所以每张任务卡走的步骤很死板。先读清楚这次要做什么，再确认前面的依赖已经完成。先写测试，确认功能确实还不存在。用尽量少的代码把这一小块补上。跑相关测试，也跑全部测试。最后对着开发说明再看一遍，有没有做着做着跑偏。
做完以后，会留下代码、提交记录、测试结果和实际跑出来的样子。
这样做最朴素的好处，是后面接手的人不用靠猜。
接手的人能看到前面的人做了什么，为什么这么做，验证过没有。哪怕中途断了，也能沿着一张张任务卡和一条条提交记录继续往下走。
最后拿什么验收
最后这个 DeepSeek Harness Agent 工作台初版，走完了真实产品流程，跑了 50 项自动化测试，也做了代码检查和正式构建。数据升级后的恢复、程序重启后的恢复，以及依赖安全和隐私检查，都过了一遍。
回头看，Matt Skills 对我最有用的地方，是把开发里最容易被省掉的步骤，一项项变成了可以检查的记录。
- 01从一个模糊想法开始
- 02把产品问题和边界问清楚
- 03做一个能点的原型验证流程
- 04把已经确认的讨论写成开发说明
- 05拆成一张张有依赖关系的任务卡
- 06逐项实现、测试并留下记录
- 07放到真实产品流程里再走一遍
这套方法不会替人做判断。哪些需求值得做，哪些边界必须守住，结果到底能不能接受，还是得人自己拍板。
Matt Skills 会把这些判断记录在界面、开发说明、任务卡、测试和提交记录里。下一次再做类似的事，我可以沿着记录继续检查，不用从一段很长的 Prompt 里重新猜。
对业余时间有限的人，这就够有用了。下次再做类似的事，我至少知道从哪里开始，也知道做到什么程度才算结束。