别再搭 Harness 了，先把你的痛点解决，用最笨的方式

公众号名称：三元同学

作者名称：三元同学

发布时间：2026-06-03 10:32

很多人一上来就想搞一个完美的 Harness 系统或者 AI 工作流，把一套现有的系统直接搬过来直接用，这个想法大部分情况都是一种妄念。

因为 Harness 的搭建从来不是先搭系统再解决问题，而是反过来的。

马斯克的第一性原理：五步法

马斯克在特斯拉工厂和 SpaceX 反复用一套方法论，他自己叫它 “The Algorithm”。Walter Isaacson 在他的传记里专门记录了这五步：

• 1. 质疑每一个需求（Question every requirement）。

• 2. 删掉所有能删的部分和流程（Delete any part or process you can）。

• 3. 简化和优化（Simplify and optimize）。

• 4. 加速迭代（Accelerate cycle time）。

• 5. 自动化（Automate）

自动化永远是最后一步。自动化一个不该存在的流程，就是一种最大的浪费。

你把这个框架套到搭 AI Agent 工作流上，会发现它完美适用。

套到 Agent 工作流上

第一步，质疑需求——你到底要解决什么问题？

不是「我想搭一个很厉害的 Agent 系统」，不是「我想把工作流自动化」，更不是「别人都在搞 Skills 我也要搞」。

而是：你日常工作中，哪个环节最痛？哪个操作你重复了无数次？

从这个最具体、最实在的痛点出发，用最小必要的方式，先把问题解决了。

你不需要一个精心设计的 Skill，不需要考虑通用性，不需要考虑代码优雅不优雅。你只需要一个能 work 的东西，哪怕它很丑、很土、只能解决一个场景。

先让它跑起来。

大部分人最容易犯的错误就是一上来就想搞一个系统化的、通用的、完善的解决方案。这是一种妄念。你根本不知道最终的系统应该长什么样，因为你还没有足够的实践经验来告诉你什么是真正重要的。

这就是马斯克说的「不要去优化一个根本不该存在的东西」，其实放到任何领域都适用。

我的实践：从痛点里长出来的 Skills

分享几个我自己的例子。

User Profile：从一次次对话里长出来的

作为一个 AI 产品的创业者，我需要了解核心用户——他们是怎么使用的、用了多久、情绪变化是什么样的、为什么付费、应不应该发邮件召回。

一开始我就是直接跟 Claude Code 聊：「帮我查一下这个用户的学习记录」，然后它帮我写 SQL、查数据、做分析。每次查一个用户我就跟它聊一轮，手动做的，你肯定会觉得很土。

但聊了十几个用户之后，我发现每次都在重复类似的流程——先查基本信息，再查学习会话，再看消息内容判断情绪，再看各个功能的点击/浏览情况，再看付费记录，最后给一个综合判断。

这个时候我才开始想：能不能把这套流程固化下来？

于是我把跟 Claude Code 聊了很多轮、反复打磨过的查询逻辑和分析框架，沉淀成了一个 Skill。现在我输入一个邮箱，它就能自动跑完整套流程，输出一份包含使用轨迹、付费动机、使用情绪、留存预期的完整用户画像。

下面截了一个案例的部分内容供参考：

这个 Skill 并非我提前「设计」出来的，是从几十次实际使用中「长」出来的。

Win-Back：从手动发邮件到自动化召回

用户流失是每个产品都会遇到的问题。一开始我就是手动去看数据库，找出那些用光了额度但没付费的用户，然后一个个写邮件。

你想想，这事有多烦——查 SQL、分析行为、判断值不值得召回、写个性化邮件、发送。一个用户搞下来半小时。

后来我把这个流程逐步自动化了。先是把 SQL 查询固化了，再是把分析逻辑固化了，最后把邮件模板和发送也串起来了。现在一个 Skill 就能搞定：扫描用户行为、识别高价值流失用户、生成个性化邮件、发送。

但你注意，这不是我一开始就想到要做一个「用户召回系统」。我一开始只是想解决一个很具体的问题：这个用户用了很多次了都没付费，我想把他拉回来。

Debug Session：从排查问题到一键诊断

做过线上产品的都知道，用户反馈 bug 是家常便饭，尤其是在早期。一开始每次排查我都是手动操作——查 session 信息、看消息列表、检查掌握度数据、去 Langfuse 看 trace。

同样的流程，重复了二三十次之后，实在是觉得烦，我把它做成了一个 Skill。输入 session ID，自动跑完整套排查流程，直接告诉你问题出在哪。

就用这一行命令，我可以精准地拿到 agent 运行任何一步的所有 prompt，并且定位出 agent loop 可能出现问题的代码。

Article to Slide：从一个想法到一个完整工具

我经常写文章，有时候需要把文章内容做成演示。一开始就是手动搞——把文章拆成段落，一页一页做 slide。后来做多了，发现这事完全可以让 AI 来干，于是做了一个 Skill，输入一篇文章，自动生成 slide deck。

大家看我之前的文章，我文末附的 PPT 演示都是这么做出来的，比如研读几十个热门 Skills 之后，我总结出了这十个写好 Skill 的套路。

你看到规律了吗？

每一个 Skill 都不是我坐在那里「设计」出来的。都是先有一个痛点，先用最土的方式解决，反复用了很多次之后，发现固化的流程，然后才把它做成一个可以复用的工具。

做减法比做加法更难

这里面还有一个特别重要的点：做减法。

AI 天然就喜欢做加法。你让它帮你写一个 Skill，它恨不得把所有边界情况都考虑到，加一堆错误处理，搞一堆参数配置，最后弄出来一个又臃肿又复杂的东西。

但真正好用的工具都是简单的。

我搭 Skill 的一个核心原则就是：每次写完之后，问自己一个问题——这里面哪些东西是可以去掉的？

不是「哪些东西可以加」，是「哪些东西可以去掉」。

那些万一用到的功能，其实没有必要留下来，因为 AI 加起来也很快。

留下来的就是最核心、最常用的那 20% 的功能。这 20% 才是真正有价值的部分。

马斯克在 SpaceX 的工厂里说过一句话：「如果你最后没有加回至少 10% 被删掉的东西，说明你删得不够狠。」

这句话我觉得对搭 Agent 系统也完全适用。你应该删到有点心疼、删到开始犹豫，然后停下来看看还能不能用。

回到五步法：完整路径

前面讲了第一步（质疑需求）和第二步（删除）的实践，再把完整的五步串起来：

第一步，质疑需求——从痛点出发，先解决问题。

不管你的解决方式有多土，先把问题解决了再说。直接跟 AI 聊，让它帮你干活，不要搞什么花活。

这个阶段的目标就一个：能 work。

第二步，删除——从实践中提炼，砍掉多余的。

用了几次之后，你会发现重复出现的模式。把这些模式提取出来，就是你的 Skill 雏形。同时狠狠做减法——AI 生成的东西天然臃肿，把那些「万一用到」的功能全部砍掉。

第三步，简化优化——留下骨架和肌肉。

留下来的那 20% 核心功能，把它们打磨到顺手。把常用参数设成默认值，把操作路径缩到最短。

第四步，加速迭代——能通用的通用化。

多个场景共用的逻辑抽出来复用，让你从「想做一件事」到「做完这件事」之间的步骤尽可能少。

第五步，自动化——封装成能自己跑的东西。

到这一步你才应该去想自动化。把打磨好的流程封装成 Skill、Hook、或者定时任务，让它能自己跑起来。最后的效果可能是一行命令解决，可能是全自动化的，完全解放人工。

最大的坑

说到底，搭 Agent 系统最大的坑就一个：想太多，做太少。

一上来就想通用性，一上来就要搞一个「Harness 系统」。你看到别人的系统很厉害，就觉得自己也需要一个一样厉害的系统。

但你忽略了一个事实：别人的系统也不是一开始就那样的。它也是从一个很丑、很土、只解决一个具体问题的小工具开始，一步一步迭代出来的。

回到你自己的问题：你的痛点是什么？先解决它。用最笨的方式即可，然后再继续封装。

我是三元同学，希望这篇文章能给你带来一些启发。如果你也在搭自己的 Agent 工作流，不妨先想想：你到底要解决什么问题？欢迎在评论区聊聊你的实践经验 :)

---

内容效果不满意？点此反馈