夜雨聆风Hi，你好，我是九思 summer。
上一篇我写为什么收藏了一堆 Skill，AI 还是不能按你的方式干活？的时候，最后留了一个坑。
我说，下一篇想继续写我自己具体是怎么做的：从一个很混乱的问题开始，讲我是怎么把它讲给 GPT，让它帮我深度调研、拆 Workflow、临时模拟，再一点点纠偏，最后固化成 Skill。
但真的动笔前，我发现中间还缺一层。
如果我直接讲我怎么拆 Workflow、怎么写 Skill，很容易变成一篇“内部流程复盘”。看起来很完整，但对小白不一定好用。
因为很多人现在卡住的地方，还不是 Skill 文件怎么写。
而是更前面的一步：
你到底要怎么让 AI 按你的方式干活？
前两天有朋友看完我的公众号，来问我：
“你最近发的公众号都挺好，我也在做一个公众号，想了解一下内容你是用 CC 做的吗？”
我说：
“我用 Codex 做的。”
他后面又补了一句：
“我用 Codex 做的，没人味。”
我当时回得很短：
“要写 Skill。”
这句话没错，但我后来又思考了下，它有点跳。
如果一个人刚开始用 AI 写文章，他真正的问题肯定不是先想到“怎么写 Skill”。他更关心的是：
为什么我也用了 Codex，写出来还是像 AI？为什么它不懂我的语气？为什么它一写就很顺，但顺得有点假？
同一时间，我在发表了上一篇关于diff的文章为什么 AI 改项目越改越错？小白验收代码的第一步：看 diff后，又看到群里有人聊 AI 改代码。
他说自己会给项目分几个角色：项目经理、方案专家、开发、测试、代码审计。所有代码修改除了提交到 git，还要有文档记录。
虽然一个是在问公众号怎么写。
一个是在讲代码项目怎么分工。
但再加上我前面那篇 diff 文章：AI 改完代码以后，小白不能只听它说“我完成了”，至少要看 diff、跑测试、打开页面点一遍。
这几件事放在一起，我突然觉得，它们其实在讲同一个问题。
当 AI 开始帮你做复杂任务时，你不能只给它一句 Prompt。
你要给它一套能工作的框架、有流程、有分工。
最近 AI agent 圈里有一个词，刚好可以解释这件事。
叫 Harness。
Harness 是什么？
Harness 这个词，直接翻译会有点别扭, 直译是“马具”, 也就是束缚住野马的那个器具。
在这里你可以先把它理解成：模型外面那层“工作框架”。
它不是模型本身，也不是一句 Prompt。
Prompt 更像你这次对 AI 说的话。
比如：
“帮我写一篇公众号文章。”
“帮我改一个按钮。”
“帮我剪一条视频。”
但 Harness 会继续管后面的事：
AI 开始前要看什么？
它可以用哪些工具？
它现在做到哪一步？
它做完以后要留下什么证据？
哪些动作可以自己做，哪些动作必须问我？
结果怎么检查？
我看了一圈海内外关于 agent harness、harness engineering 的文章。不同文章讲法不太一样，有的偏工程，有的偏概念，有的会讲到 agent loop、权限、状态、可观测性。
但如果翻译成小白能用的话，大概就是一句：
不要只让 AI 回答你，要让 AI 在一个可检查的流程里做事。
这也是我觉得 harness 对普通人最有用的地方。
它不是一个很玄的技术词。
它提醒我们：当任务开始变复杂，光改 Prompt 不够了。
为什么小白也需要 Harness？
很多人刚开始用 AI，第一反应都是优化 Prompt。
写公众号没人味，就加一句：
“请你写得更像真人一点。”
代码改乱了，就加一句：
“请你不要破坏原功能。”
生图不好看，就加一句：
“请你更高级、更有质感。”
这些话有用，但作用有限。因为它们大多只是在修“表达结果”，没有管中间过程。
拿公众号写作来说。
代码也是一样。
你让 AI “帮我改好”，它可能真的把功能写出来了。
但它有没有改无关文件？
有没有跑测试？
有没有看 diff？
有没有确认旧功能没坏？
这些都不是一句“请认真检查”就能稳定解决的。
所以我现在更愿意把问题拆开看。
如果任务只是一问一答，Prompt 很重要。
但只要任务变成多步骤，比如写一篇文章、改一个小功能、剪一条视频、做一组电商图，Prompt 就只能算入口。
真正影响结果的，是后面有没有一套流程帮 AI 收住。
这套流程，就是你自己的最小 harness。
外面那些 Harness 文章，都在讲什么？
我大概看了一圈，发现海内外讲 harness 的文章，虽然有的写得很工程化，但共性很明显。
第一个共性，是它们都不再把重点放在 Prompt 上。
很多文章都会提到一个类似判断：AI agent 的能力，不只来自模型，也来自模型外面的工具、状态、记忆、权限和检查。
这对小白很重要。
因为我们很容易把 AI 做不好，全归因到“我 Prompt 没写好”。
但有时候不是你那句话差了几个字，而是你没有告诉 AI：这件事应该分几步做，做完怎么验收，哪些地方不能自己决定。
第二个共性，是它们都在讲一个循环。
你可以不用记 agent loop 或 ReAct 这些词。
放到实际操作里，就是：
让它做一步。
看结果。 通过就继续。 不通过就纠偏。
这就是 harness 里最朴素的一层。
AI 不是一次性把所有结果吐出来，而是在“做一点、看一下、再继续”的过程里推进。
第三个共性，是不要一上来做太大。
有些生产级 harness 会讲很多东西：权限分级、日志、追踪、上下文压缩、持久化、评估系统。
这些当然重要，但小白一开始不需要做这么重。
如果你只是想让 AI 帮你写公众号、改代码、剪视频、生图，第一版 harness 可以非常简单。
先用一份普通文档，把任务、阶段、证据、暂停点写清楚。
它不高级，但能用。
小白怎么搭一个最小 Harness？
下面这套方法，是我觉得普通人最容易跟上的版本。
你不需要会写代码。
你也不用一上来写 Skill。
先拿一个你自己的重复任务，照着填一份文档就行。
第 1 步：只选一个重复任务
不要一上来就说：
“我要搭一个 AI 工作流系统。”
这个目标太大了。
你先选一个最近经常做、又总是会乱的任务。
写一篇公众号文章。
让 AI 改一个网页小功能。 剪一条短视频。 生成一组封面图。 做一个电商商品页。
标准很简单：这个任务你至少做过两三次，而且每次都要反复提醒 AI。
如果你总提醒它“别编”“别乱改”“先问我”“要有记录”，那这里就值得沉淀成一个最小 harness。
第 2 步：写清楚成功标准
很多人给 AI 任务时，会写得很模糊。
比如：
“帮我写好一点。”
“帮我改得更专业。”
“帮我做一个能用的版本。”
这类话的问题是，AI 不知道什么叫“好”。
所以你要先写三个东西：
最后要交付什么？
什么算通过？
什么绝对不能发生？
如果是公众号文章，可以这样写：
任务：写一篇公众号文章。 最终交付： - 一篇公众号长文初稿。 通过标准： - 开头能接住真实读者问题。 - 中间有可执行步骤。 - 观点和案例有素材来源。 - 读者看完知道下一步怎么做。 不能发生： - 不能编造实测。 - 不能把不确定说成确定。 - 不能暴露我的内部完整工作流。 - 不能写成空泛营销文。如果是代码验收，可以这样写：
任务：让 AI 给 Todo 页面加一个小功能。 最终交付： - 修改后的代码。 - 改动说明。 - diff 摘要。 - 测试结果。 - 页面验收清单。 通过标准： - 新功能可用。 - 旧功能没坏。 - 页面能打开。 - 移动端没有明显错位。 不能发生： - 不能乱改无关文件。 - 不能只说“已完成”但不给 diff。 - 不能测试没跑就说通过。这一步看起来很基础，但很管用。
因为你先把“什么叫完成”写清楚了，后面才知道怎么验收。
第 3 步：先拆阶段，不急着拆角色
上一篇我讲 Skill 的时候，一直在讲“岗位”和“职责”。
但这篇我想把顺序往前放一点。
小白刚开始搭 harness，不要急着写一堆角色。
先拆阶段。
一个最小 harness，可以先拆成五段：
准备：收集输入和边界。 计划：拆步骤，说明要怎么做。 执行：真正做任务。 检查：用证据验收。 交付：输出结果和缺口。公众号文章可以这样拆：
准备：读旧文、读读者反馈、确认不能公开的内容。选题:广泛搜索相关领域每日热点或深度文章,推荐选题 计划：确定文章主题、结构、素材缺口。 执行：写初稿。 检查：查 AI 味、查事实边界、查有没有泄露内部流程。 交付：给出待发布稿和待补素材清单。代码验收可以这样拆：
准备：确认需求和不能破坏的旧功能。 计划：说明预计修改哪些文件。 执行：改代码。 检查：看 diff、跑测试、打开页面点一遍。 交付：总结改动、测试结果、风险点。为什么先拆阶段？
因为阶段是你自己做事的顺序。
这个顺序清楚了，后面才知道哪些阶段值得变成 Skill，哪些阶段只是临时提示就够了。
第 4 步：每个阶段写输入、输出、禁止事项
这是小白最容易跳过的一步。
但它会直接影响 AI 稳不稳定。
每个阶段都问三句话：
开始前，AI 必须看到什么？
做完后，AI 必须交什么？
这个阶段，AI 不能做什么？
比如公众号文章的“准备阶段”：
阶段：准备 输入： - 上一篇文章正文。 - 读者提问截图。 - 这篇文章想解决的问题。 - 不能公开的内部信息。 输出： - 文章定位。 - 目标读者。 - 可用素材。 - 缺失素材。 不能做： - 不能直接写正文。 - 不能编造读者反馈。 - 不能默认所有内部流程都可以公开。比如代码项目的“检查阶段”：
阶段：检查 输入： - diff。 - 测试日志。 - 页面截图或人工点击结果。 输出： - 哪些功能通过。 - 哪些功能待确认。 - 是否有无关改动。 - 是否建议继续修改。 不能做： - 不能只看 AI 总结。 - 不能没跑测试就说测试通过。 - 不能没看 diff 就建议提交。写到这里，你的 harness 就已经有雏形了。
因为 AI 不再只是听你一句话自由发挥。
它每一步都有入口，也有出口。
第 5 步：加证据点
我现在越来越觉得，证据点是小白用 AI 的安全带。
不是为了显得专业, 是为了防止 AI 编造事实来骗你。
不同任务的证据不一样。
写公众号，证据可能是：
读者反馈截图。
参考资料链接。
实测截图。
工具输出。
旧文风格样本。
素材缺口清单。
改代码，证据可能是：
diff。
测试日志。
页面截图。
终端报错。
git commit。
人工点击记录。
剪视频，证据可能是素材清单、时间轴、成片片段、字幕文件。
生图，证据可能是参考图、Prompt、生成结果、修改记录和最终用途。
电商，证据可能是竞品截图、商品参数来源、卖点来源、详情页版本和客服问答记录。
你不用一开始做得很完整。
但至少要有一句规则：
没有证据的地方，不能写成确定结论。
比如公众号里，没截图就不要写“我实测成功”。
代码里，没跑测试就不要写“测试通过”。
电商里，没来源就不要写“这是用户最关心的卖点”。
第 6 步：设置暂停点
很多人理解 AI 自动化时，会默认“越自动越好”。
我现在反而觉得，小白更应该先学会设置暂停点。
因为不是所有事都该让 AI 自动往下跑。
常见暂停点可以先写这些：
发布前，必须停。
付款前，必须停。
使用隐私信息前，必须停。
修改核心文件前，必须停。
删除内容前，必须停。
素材不足却要写完整结论前，必须停。
AI 要替你做主观判断前，必须停。
如果是公众号文章，可以写：
以下情况必须问我： - 要公开我的内部工作流细节。 - 要引用私人聊天截图。 - 素材不足但想写完整成稿。 - 要把某个观点写成确定结论。 - 要发布或导入公众号草稿箱。如果是代码项目，可以写：
以下情况必须问我： - 要修改登录、支付、数据库、配置文件。 - 要新增依赖。 - 要删除文件。 - 测试失败但想继续大范围改代码。 - 要提交 git 或发布。暂停点不是拖慢效率。
它是在保护你不要让 AI 替你做不该做的决定。
第 7 步：跑一轮，把跑偏写成规则
第一次跑，不要追求完美。
让 AI 按你的最小 harness 做一遍。
然后观察它哪里跑偏。
公众号文章里，你可以看：
它是不是又开始写空话？
它是不是把素材缺口藏起来？
它是不是泄露了内部流程？
它是不是把别人的说法写成你的实测？
代码项目里，你可以看：
它是不是动了无关文件？
它是不是没跑测试就说完成？
它是不是只看页面没看 diff？
它是不是把环境问题当代码问题乱修？
每发现一个反复出现的问题，就把它写成规则。
不要只写：
“下次注意。”
要写成这种：
规则： 如果没有截图、日志或来源，只能写成“待验证”，不能写成“已实测”。或者：
规则： AI 修改代码后，必须先输出 diff 摘要，再进入测试和页面验收。这一步才是 harness 真正长出来的地方。
不是你一开始设计得多完美。而是每次 AI 跑偏以后，你都把经验沉淀回流程里。
你可以直接复制的最小 Harness 模板
如果你现在想跟着做，可以先复制下面这份。
不用写复杂。
先填一版，跑起来再改。
我的最小 Harness 任务名称： [写一个具体任务，比如：写一篇公众号文章 / 验收一次 AI 改代码] 一、成功标准 最终交付： - 通过标准： - - 不能发生： - - 二、阶段拆解 阶段 1：准备 输入： - 输出： - 不能做： - 阶段 2：计划 输入： - 输出： - 不能做： - 阶段 3：执行 输入： - 输出： - 不能做： - 阶段 4：检查 输入： - 输出： - 不能做： - 阶段 5：交付 输入： - 输出： - 不能做： - 三、证据要求 必须留下的证据： - - 没有证据时怎么处理： - 四、暂停点 遇到这些情况必须问我： - - 五、跑偏记录 本轮 AI 跑偏的地方： - 新增规则： -你可以先用它做一个很小的任务。
比如“写一篇公众号文章”。
也可以用它做“验收一次 AI 改代码”。
不要急着把它变成完整系统。
先跑一次，看它哪里不够用。
回到公众号写作这个例子
如果我要给“公众号文章”搭一个最小 harness，第一版可以很简单。
任务是：
写一篇公众号文章。
成功标准是：
能接住真实读者问题，有清楚步骤，有素材来源，不泄露内部完整工作流。
阶段可以是：
准备：读旧文、读读者反馈、确认保密边界。
计划：确定文章主线、读者问题、可用素材和缺口。
执行：写待补素材稿。
检查：查事实边界、AI 味、保密边界。
交付：输出初稿、素材缺口、发布前检查清单。
证据可以是：
读者提问截图。
前文正文。
公开资料链接。
用户确认的可公开素材。
暂停点可以是：
要公开内部流程时停。
要引用私人聊天截图时停。
素材不足还想写成确定结论时停。
发布前停。
你看，这里面没有什么复杂技术。
但它已经比一句“帮我写一篇像人写的公众号”稳定很多。
因为它把“人味”拆回了更具体的东西：真实读者、旧文语气、素材边界、事实检查。
代码验收也是同一个思路
如果换成 AI 改代码，最小 harness 也能套进去。
任务是：
验收 AI 改代码。
成功标准是：
知道 AI 改了哪些文件，新功能能用，旧功能没坏，有测试或人工验收记录。
阶段可以是：
准备：写清需求和不能破坏的旧功能。
计划：让 AI 先说预计影响范围。
执行：AI 修改代码。
检查：看 diff、跑测试、打开页面点一遍。
交付：输出通过项、风险点和是否建议提交。
证据可以是：
diff。
测试日志。
页面截图。
人工点击记录。
暂停点可以是：
修改核心文件前停。
新增依赖前停。
测试失败后想大范围重写时停。
提交或发布前停。
这就是为什么我说，公众号写作和代码验收表面不一样，底层其实很像。
它们都不是让 AI 一次性给你一个漂亮结果。
它们都需要阶段、证据、检查和人的判断。
最后
现在再回头看 Prompt、Workflow、Skill、Harness，我会这样理解。
所以，如果你现在也在折腾 AI 工作流，我不建议一上来就到处找 Skill，然后直接复制。
可以看，可以拆，可以借鉴。
但更稳的入口，是先搭一个你自己的最小 harness。
你只要先回答五个问题：
这件事最后要交付什么？
中间分几步？
每一步要看什么、交什么？
哪些地方必须留下证据？
哪些地方必须停下来问人？
当这五个问题慢慢稳定下来，你再从里面挑出反复出现的一段，把它固化成 Skill。
顺序别反了。
不是先找 Skill，再硬套自己的工作。
而是先把自己的任务跑顺，再让 Skill 从里面长出来。
以上，如果你最近也在折腾 Codex、Claude Code、Cursor，或者也想把自己的重复工作沉淀成 AI 工作流，觉得这篇对你有帮助，随手点个赞、在看、转发三连吧。
如果你还想看，我后面也可以继续把“怎么把一个最小 harness 变成 Skill”这件事，按真实过程拆开写给你看。
谢谢你看我的文章，我们，下次再见。
我建了一个群。
这个群更适合真正的初学者、纯小白。
如果你也是刚开始接触 AI、AI 编程、各种工具和工作流，
不想一个人到处乱撞， 可以进来一起慢慢学。
如果二维码过期了，去我的公众号后台回复 【群聊】，拿最新入口。
