harness

• 开场即点题："人人都在说'关键不在模型，而在 harness'。但你知道没人说什么吗？——harness 到底是什么？"本期她要现场写一个自己的 harness，并解释为什么定制 harness 可能比单独用 Claude Code 或 Codex 更好。 → 详细
• 她的定义刻意做到最简："harness 就是包在 AI agent 外面的一些代码，让它更好用。 这些代码里可以有 AI 吗？当然可以。必须有 AI 吗？不一定。harness 的目标是什么？让 AI 表现得更好。"她认为大家谈论这件事的方式把它搞得太神秘，其实"它就是在你的 AI 周围多写一些代码，让它在某个特定用例上更有用"。 → 详细
• 按这个定义，市面上的工具全都对号入座：Cursor 是一个非常复杂的 harness，Codex 和 Claude Code 是非常复杂的 coding harness——"归根结底，它们就是包裹在 AI agent 和 AI 调用外面的代码，让它们在完成某项特定工作时更高效。" → 详细

• harness 由三部分组成：特定的上下文（context）、能执行的特定动作（actions）、以特定结果（outcomes）为目标。就这么简单。 → 详细
• 判断标准："当同一个工作流需要同样的设置、同样的产出时，你就该建一个 harness。"这跟"什么时候该做 AI agent"类似（她说 harness 和 agent 两个概念有时可互换），真正的适用场景是：确定性和非确定性混合的工作流——有分步流程、有工具、有具体用例，且工作稍微复杂一些。这也解释了为什么 coding harness 最先流行：写代码就是一个"待完成的工作"（job to be done），需要特定工具、遵循标准流程。 → 详细
• 适用场景清单（不止写代码）：管理线上生产事故（要走特定流程）、把 PR 准备好发布、处理客服升级工单、管理数据迁移，甚至非技术用例——按特定方式做调研、按特定方式整合文档。 → 详细

• 她的选题问题模板值得抄：审视 ChatPRD 整个业务，问"有什么事是我在反复、持续地做，而且 AI 能干得不错的？如果我们对 AI 的用法更结构化一点，哪些事能做得更好？" → 详细
• 答案是修 bug："我天天发代码，所以我也天天发 bug。"她的假设：平时用 Claude Code/Codex 修 bug 已经能干，但如果构建自己的 harness，bug 分诊（triage，即快速判断问题严重度和归属）可以做得更好。 → 详细
• Sentry（错误监控平台）排障之所以是好的"第一个 harness"：它包含写代码、需要定制上下文、有明确要保证的产出——所有东西记录进 Linear（项目管理工具）、写好跟进文档给工程团队用。顺带一提"我们"指的是"我和 Codex"。 → 详细

• 理由一：意图预置。 通用工具的问题是"面对某个特定的工作，你有时就是想稍微'微观管理'一下，想对这件事怎么做规定得更明确"。用 Claude Code 她得每次写"亲爱的 agent，请修这个 bug，链接在此"；有了 harness，"我只要把链接粘贴进去，agent 就已经知道我的意图、知道要完成的工作是什么。" → 详细
• 理由二：工具权限的硬约束。 "你可以非常明确地规定它允许用哪些工具、允许执行什么、不允许执行什么。"例如造一个"只调查不动手"（investigate-only）的 harness，确保它永远不真正写代码，只探索、只解释根因。 → 详细
• 理由三：流程可重复 + 产出保证。 每修完一个 Sentry bug 都要记录进 Linear、出特定格式报告、甚至跟进受影响客户——"你当然可以把这些写进一个 skill，但那样你还得盯着它执行（babysit）。而当我们把它做进 harness 里，我们知道它每一次都会发生。"这是全片最锋利的一句对比。 → 详细
• 理由四：模型层自由度。 可以做多模型路由（multimodal routing，按任务把请求分给不同模型）等通用工具做不到的事。找准了工作流，harness 让你"更高效、更一致、拿到更好的结果"。 → 详细

• harness 不一定是 TUI（terminal UI，跑在终端里的文字界面），不一定是 CLI（命令行工具），甚至不一定要有文字——完全可以是 web 应用。她做成 TUI 的两个原因：好久没做过觉得好玩；以及想证明"构建你自己的定制 harness，意味着你也可以为这些 AI agent 构建你自己的定制界面"。 → 详细
• 关键观念："harness 是整个体验，包括让它更好用、更易用的'人的体验'这一层。"她用了一个叫 Ink 的库（React 写终端 UI）把界面做得"很可爱"。 → 详细
• 这个终端 UI 直接反映 harness 本身的结构：能看到历史所有 run（运行记录）、出过的错、修过的东西，以及三段式流程——收集证据 → 实时流式显示活动 → 生成产出物（artifacts）。 → 详细

• 她挑了一个真实 Sentry 报错演示——"编辑操作有时会被 agent 弄丢"。按下 I（investigate 调查）而不是 F（fix 修复），harness 启动一次调查 run，拉起一个 Claude SDK 会话，开始收集证据、提出根因假设。 → 详细
• 关键在于：调查模式不应碰、不应改任何文件——这本来需要每次向 agent 专门提示"我只要你调查，不要你发布修复"，现在变成一个按键 + 粘贴 issue 链接的事。 → 详细

• 前端是终端 UI（或 CLI）；每次调用称为一个 run，跑一个任务；每个任务有特定输入（通常是一个 Sentry issue）。她还在 harness 上设了开关（flag）：只有她明确标记并批准，它才被允许编辑源码、修改输入、甚至给客户发消息——"这只是在 agent 的工作方式上多加了一层控制。" → 详细
• 核心跑在 Claude Agent SDK 上：所有 agent 规划都经它完成，它自带 Claude Code 的一些基础能力（primitives）——读文件、写文件等。模型选的是 Sonnet 4.6，"我觉得这是干这活最合适的模型"。 → 详细
• **artifact store（产出物仓库）**是她特别强调的一环（在 OpenClaw 等其他 harness 里也有类似设计）：harness 可以在自己的文件存储里创建产出物，把每次 run 收集到的所有证据都存进文件系统，供 agent 将来使用——相当于给 agent 建了一份跨次运行的"案卷库"。 → 详细
• 外接真实工具：Sentry、Vercel（部署平台，用来拿线上日志），加上推进任务用的 Linear 和 GitHub。 → 详细

• 提示词不再是泛泛的"你是 Claude Code，不要犯错，你是我们的天才模型"，而是极具体的锚定："你是在 ChatPRD 的工程 harness 里工作，这是 ChatPRD 专属的，不是一个开放式的编程系统；我们要把这些 artifacts 当作事实来源（source of truth）；这是攻克这个特定问题的计划；我要你返回的是 X、Y、Z。" → 详细
• 执行保证的原话："这些我都不用复制粘贴，甚至不用写进一个 skill 然后祈祷它被正确调用——我把它直接编码进了 harness 里一个非常具体的步骤，确保模型每一次都会遵循。" → 详细
• harness 内的三类"硬件"：好几处这样的定制提示词、会生成的 artifacts、以及 tool policies（工具策略，规定哪些工具能调用哪些不能）。 → 详细

• 她的造法：同时开 Claude Code 和 Codex 两个会话"对打"（dueling），说"帮我构建一个 harness，我想用 Claude Agent SDK，我希望它做这些事"，然后"闭上眼睛试着让它们把活干完"。 → 详细
• 踩坑实录：不是 one-shot。 用的是 GPT-5.5 和 Opus，"它们俩都特别想构建一个超级确定性的东西，非常抗拒往 harness 里放任何 AI，我不得不非常非常明确地反复提示，才拿到我想要的结果。"——AI 默认会把"harness"理解成纯脚本，得逼着它留出 agent 的位置。 → 详细
• 她给出的对策（可直接抄的提示纪律）：把工作流写得非常具体、把工具写得非常具体、把哪里该用定制提示词写得非常具体；主体建议用 agent SDK（Claude 或 OpenAI 的都行）来跑。 → 详细
• 最好笑的一幕："Codex 在构建这个 agent 上干得最好，但它实际实现 agent 用的是 Claude Agent SDK。 所以我们这是横跨多个模型、横跨多个编程 agent 在干活。" → 详细

• 整个 harness "其实非常简单"：一个进 TUI 的高层入口索引 + 大概八个文件，每个负责一件具体的事。文件清单：对接数据源的 adapter 们、几个 workflow（特别是 bug hunter workflow，完整写清怎么排查 bug、怎么组织 bug 报告总结）、运行 TUI/CLI 的几个文件、加一个每次运行都更新的 artifacts 文件夹。 → 详细
• adapter（适配器）的设计哲学是全片最值钱的段落：Sentry adapter 以非常特定的方式调 Sentry API——"我没有泛泛地用 MCP，没有让 coding agent 在一堆 trace 里到处乱逛，而是非常精确地定义了：从 bug 报告的角度，你需要拉取什么、什么有用、什么没用，把这个 connector 做得非常有主见（opinionated）。"Linear、Vercel、GitHub 集成同理：不是"这些工具一般能怎么用"，而是"当你在排查一个 bug 的时候，具体该怎么用这些工具"。 → 详细
• 每次 bug 排查跑完，artifact 文件输出一个固定的产出物包（artifact bundle）：任务运行的全部消息、报告（Sentry issue 是什么 + 发现简报 + 相关日志）、Claude worker 最后做了什么、输出总结——外加一个"很漂亮的 HTML 文件"展示整个流程 + 一份 worker 报告。 → 详细
• 除了 TUI，还内置了命令行工具：想快速针对特定 issue、带特定工具使用 flag 跑一次，直接命令行走起。代码本身"很直白"，连 API key 放哪都写清楚了。 → 详细

• 演示的 run 跑完，产出编号 Bug Hunter C7 的调查简报（investigation brief）：确凿证据显示 Sentry 里确实有一条 warning，影响 150 个用户、每小时仍在发生，但它是 warning 不是真正的 error；Vercel 日志当时拿不到，所以那部分数据没用上——harness 如实报告了数据缺口。 → 详细
• 根因分析：识别出几个潜在根因（无效的原始 range、或重叠的原始 range），还发现了该函数里的一个盲区；精确指出问题在产品的哪个位置，并给出验证方法——拉取一条原始 Sentry 事件核对。 → 详细
• 行动建议分两层：要建 Linear issue（"我们绝对应该建一个 Linear issue 来修这个问题"，应指派给人）；但不建议开启 patch 模式直接修——agent 的原话是"不行，我觉得现在还修不了，我还需要更多信息"。这正是她预设的产出格式：摆证据 → 按优先级排根因 → 给验证建议 → 说要不要指派 → 说能不能直接修。agent 知道说"我还不能修"，正是约束设计的胜利。 → 详细

• 她复盘的造 harness 七步：① 确定一个具体工作流；② 想清楚一次 run 长什么样；③ 对工具/数据源做有主见的调用（做 adapter 而不是只说"用个 MCP"——虽然 MCP 也可以是 harness 的一部分）；④ 想清楚输出什么结构化 artifact；⑤ 决定给哪些规则和权限、不给哪些；⑥ 决定用 Claude Code、Codex 还是模型路由器来执行；⑦ 搭一个交互界面（TUI/CLI/web 都行）。 → 详细
• 给观众的极简行动版只有四步："确定一个工作流，认认真真把它写下来（纸、HTML 或 markdown 都行）；想清楚你需要哪些数据源；把这一切丢进 Claude Code 或 Codex，让它帮你搭出你自己的 harness；再拿真实数据去测试。" → 详细
• 真正的杠杆观：TUI 是为人设计的，但真正的玩法是"给一个全能的智能 agent 一个专门的 harness，让它带着里面的 agent 去解决一个特定问题——我认为这才是你从 Claude Code 这类 coding agent 身上榨出真正杠杆、拿到真正定制化结果的方式。"我们太习惯开放聊天框了；现在她意识到：约束工作范围让特定的活干得非常高效，再用通用 agent 做编排（orchestrate）。 → 详细
• 收尾的猜想："我开始有一个猜想：所谓的套壳应用（wrapper）其实就是一个 harness——这个认知会让我过去三年 vibe coding 出来的所有东西都升级一遍。"这是她第一次在节目里现场搭 harness，对她自己也是一次学习之旅。 → 详细

• 两段赞助：Bolt.new（AI 应用构建器，"一个想法 + 一个周末"就能上线） → 详细；Customer.io（AI 生成营销活动的受众/消息/时机，9000+ 品牌在用）。 → 详细

本期为 Claire 单人现场 build，无 lightning round。收尾要点：

• 这是她第一次在 How I AI 节目里现场搭 harness；如果想让她继续搭点别的、继续拆解 AI 术语（demystify），她邀请观众在评论区留言点题。 → 详细

• 节目官网：howiaipod.com（全部往期 + 节目信息）；播客上架 Apple Podcasts / Spotify。 → 详细

• Claire Vo 本人未在片中留个人联系方式；她是 ChatPRD 创始人/CEO。