四节课上完了。
想再往前走一步?

判断标准:需要多步、还会变化的事,才用 Agent;一问一答能解决的,别用——普通调用更便宜、更稳。

目标——它要达成什么(说清楚,别含糊)。
工具——它能调用的本事:搜索、读文件、写文件、调别的接口。
记忆——它记得自己已经做过什么,不会原地打转。
停止条件——什么时候算做完、什么时候该停。

四件里最容易被忘的是停止条件。没有它,Agent 会一直转、一直烧钱。

harness 不是"更聪明的模型"。它是套在 Agent 外面的一层外壳,让 Agent 跑得可控。

一个最小的 harness 管这几件事:

· 任务清单——把大目标拆成一条条小任务,做一条勾一条。
· 状态记录——现在做到哪了,中途断了能接着来。
· 日志——每一步都记下来,出问题能回看。
· 人工确认——关键动作之前停下来问人。
· 失败重试——某一步挂了,自动再试,而不是整个崩掉。

模型决定"想做什么";harness 决定"能不能真去做、做错了怎么办"。

有些动作做错了收不回来:发邮件、删数据、花钱、对外发布内容。

规矩很简单:这类动作执行前必须停下来,让人点一下"确认"。Agent 可以把方案准备好,但不能自己按下最后那个按钮。

Agent 做错事时,你得能回看它的每一步——它当时怎么想的、调了什么工具、哪一步开始歪的。这套"全程录像"叫 tracing。

没有 tracing 的 Agent,出了问题你只能干瞪眼。让 Codex 帮你的 Agent 把每一步都打印 / 记录下来。

用户说"我想要一匹更快的马"——他真正要的是"更快到达",不是马。

访谈拿到的是原话,你要往下挖一层,找到他原话背后真正想达成的事。原话照着做,常常做错。

方法:每听到一个诉求,追问一句"你要它来帮你做成什么?"

大多数人只设计了"一切顺利"的那个场景。但真实用户会经历四种时刻:

· 第一次用——他什么都不懂,你得让他 30 秒内成功一次。
· 重复用——他熟了,嫌你啰嗦,想要快。
· 出错时——他卡住了,你得让他知道发生了什么、怎么办。
· 放弃时——他要走了,为什么?这里藏着你最该改的东西。

练习:把你第三课的工具,按这四种时刻各走一遍,看哪种时刻最难看。

你以为竞争对手是别的 App?不是。是用户现在凑合用的旧办法——微信群、Excel、备忘录、问学长学姐。

如果你的工具没有明显比"在群里问一句"更省事,用户就不会换。你要赢的不是某个产品,是那个旧习惯。

用户会提一大堆需求。用四个尺子量一量,排出先后:

· 高频——这事多久发生一次?天天发生的,优先。
· 高痛——不解决有多难受?越痛越优先。
· 低成本——你做起来费不费劲?
· 能验证——做完能不能很快看出有没有用?

高频 + 高痛 + 低成本 + 能验证——四个都占的,就是你下一个该做的。

想加一个新功能?先别让 Codex 写。先把这个功能的文案和操作流程画出来 / 写出来,拿给真人看一眼。

很多功能在"画出来"这一步就被毙了——这正是它的价值。改一张草图是免费的,改一堆代码很贵。

"有多少人点开过"几乎没用——点开就走的人不算数。真正要看的是:

· 完成率——点开的人里,有多少真的用完、拿到了结果?
· 复用率——用过一次的人里,有多少回来用第二次?

复用率是最诚实的一票。没人回来用,说明它没真的解决问题。

新手总想加东西。但每加一个功能,产品就更难懂一点、更容易让人在第一次使用时迷路。

好产品不是功能最多的,
是把那件最重要的事做到最顺的。