DeepSeek Harness 桌面版更新后，最亮眼的是其“万物皆插件”的定制空间。本文从 AI 产品经理视角，拆解任务入口、插件体系与创造模式的设计逻辑，并通过反馈评审实测，展示如何将工作流程封装为可复用工具，以及定制背后需要付出的维护成本。

最近 DeepSeek Harness 桌面版更新了，最吸引我的，是它给用户留出的定制空间。

官网强调“万物皆插件”：用户可以安装插件，也能在创造模式里通过对话增加工具、技能和界面，按自己的工作需要扩展这个 Agent。

这次使用中，我把一份准备好的反馈评审流程和核验脚本交给创造模式，它生成并安装了本地插件。到了新会话，流程可以通过指令载入，脚本也成为能够直接调用的工具。这个过程里既有顺利完成的部分，也经历了路径纠正、依赖调整和重启生效。

这让我更想拆开看看：Harness 开放了哪些定制能力，用户又要付出什么，才能把它们用进日常工作。文章围绕 DeepSeek Harness 展开，结合插件定制、连续三阶段的反馈评审，以及标准模式与 PTC 的同题对照，从 AI 产品经理的视角分析它的入口、工作组织和扩展设计。

一、任务入口：先让用户开始工作，再解释配置

1.1 同一个入口，承接做任务和改工具

打开 Harness 的新会话，输入框周围可以选择工作区、任务模式、访问模式，以及模型和推理等级。

四种任务模式中，标准模式处理代码、文件和资料；PTC 强调批量调用工具，以及筛选、去重、统计和汇总；极简模式只使用终端，供基础表现测试与比较；创造模式用于编写插件、增加功能和界面。

创造模式被放在这里，是我最关注的一项入口设计。整理一批反馈与增加一项核验工具，可以在同一个应用中发起。用户发现某个步骤反复出现时，能够继续提出改造要求，不必先离开当前环境另找开发工具。

对于第一次提交材料的人，标准模式已经提供了一条可以直接开始的路径。检索、文件读写和终端工具被组织在预设中，任务不要求用户先逐项配置。等到需求变成改造工具，再进入创造模式，两种目标有各自的入口。

四个预设采用了不同的描述角度：标准与 PTC 主要涉及执行方式，极简涉及工具范围，创造涉及任务目标。这种打包方式把常用配置集中起来，菜单说明则需要帮助用户把当前任务对应到具体选项。

例如反馈评审既要处理资料，也要分类汇总，同时符合标准与 PTC 的用途描述。看到菜单时，我能理解两者大致做什么，却还缺少一个切换的理由。

1.2 标准与 PTC 的差别，要落到执行路径上

这次把相同的八条反馈、任务书和提示词分别交给标准模式与 PTC。两边使用同一模型 DeepSeek-V41-Flash、High 推理等级和工作区内修改权限，各在独立会话中运行一轮，要求交付反馈数据、评审建议、改进方案与验收，以及可操作的评审页面。

PTC 这轮通过代码调用工具、处理数据并生成文件，再使用本机已有的浏览器工具检查页面。标准模式选择直接启动 Chrome 无头浏览器，遇到权限错误后报告了这一步没有完成。我更关注这条执行路径的差异，它解释了额外的页面验证是怎样发生的，比快出的 9 秒更有参考价值。

两个模式都出现了同一处分类错误。一位用户反馈登录问题时，已经说明自己是从开发环境启动程序，并采用了替代账号的实现方式。两份报告都保留了这些细节，却仍把它归入官方桌面版的历史问题。执行模式不同，并没有让这条判断自动变得准确。

因此，我对入口的改进建议会落在任务示例和执行方式上：一类任务是围绕少量资料逐步处理，另一类需要批量调用工具并集中加工返回结果。菜单应帮助用户看清这种差别，而不是让两段用途说明都落在整理资料上。默认选项继续承担大多数首次任务，需要进一步控制执行方式的人再展开选择。

1.3 将工作方式与访问范围分开

Harness 的任务模式和访问模式是两个入口。仅可查看、工作区内修改和完全权限，描述的是操作范围；标准、PTC 等模式描述怎样执行。两轮对照都在工作区内修改权限下交付了文件，切换模式时可以沿用相同授权。

我在任务书里另外约定：原始材料和输出成果分别保存在两个目录中。完成后核对，输入文件保持不变。这是为本次评审设计的文件组织方式，Harness 按约定执行，审阅时可以直接对照原始证据与输出。

标准模式启动浏览器受阻的情况，也说明执行中需要更细的状态解释。文件已经生成，失败的是后续页面检查。用户接下来可以先查看成果，也可以处理浏览器运行条件。异常信息如果能对应到具体交付环节，就更容易决定怎样继续。

根据该版本的官方说明，桌面应用已经带有插件创建和安装所需的运行组件，用户不必另外准备这套环境。需要从终端启动时，再按需注册启动命令。

这里值得保留的产品思路，是让默认配置支撑完整的第一次使用。界面上可以保留高级选项，但解释应当跟着具体需求出现：需要写文件时理解访问范围，需要批量处理时理解 PTC，需要扩展功能时理解创造模式。对使用者而言，每次配置变化都应当对应一个明确的工作理由。

二、定制能力：从一份工作方法，到真正可调用的工具

2.1 开放的对象，决定用户能改到哪里

Harness 的定制可以分成三个层次：工作方法、工具与界面、运行组件。

保存一份评审流程，是把分类和验收要求留给下一次任务；把核验脚本封装成工具，是增加一种可调用操作；模型适配、工具调用和会话记录，则属于更底层的运行机制。不同需求可以停在不同层次，使用者没有必要一次把它们全部改完。

固定版本架构文档明确列出，模型适配器、工具注册、会话日志和推进任务的执行循环都采用插件组织，可通过配置替换。换句话说，插件体系覆盖了执行过程中的主要部件。

插件管理页把这种组织方式展示了出来。官方列表里有智能体团队、自动授权审查、自动化任务、语音输入，也有终端、Agent 循环、子智能体和网页搜索。有的可以启停，有的可以进入配置；自己安装的插件则出现在下方。

这种设计给用户保留了逐步深入的空间。限制命令时长可以进入终端配置，调整子智能体数量可以进入对应配置，新增反馈核验能力则交给创造模式。它也让插件管理承担了比扩展商店更多的责任：这里管理的既有新增功能，也有 Agent 本身的运行行为。

对 AI 产品经理来说，分析自由度时需要把对象说清楚。改一段流程说明，影响的是任务要求；换一个工具，涉及参数、权限和返回结果；调整运行部件，还会改变其他能力赖以工作的环境。入口可以统一，变更的解释却需要跟着影响范围区分。

2.2 把已有流程与脚本接入 Harness

本地插件试验的目标很具体：将准备好的反馈评审流程和核验脚本，做成能够跨会话调用的插件。流程约定怎样整理材料，脚本检查编号、来源、状态和逐字引文。创造模式负责把它们接入当前应用。

它生成了名为公开反馈评审的插件，完成安装并启用。插件里有一份由用户主动调用的 Skill，还有一个用于检查反馈报告的工具。新任务可以通过指令载入评审流程，生成报告后再调用工具运行核验脚本，获得实际检查结果。

这项试验中，核验脚本已经提前准备，核心需求也给得明确：输入哪些材料、检查哪个报告、结果写到哪里。创造模式完成的是连接和封装。它省下了逐项查接口、注册能力和接入调用的操作，但工具要遵守哪些业务规则，仍然需要在需求里讲清楚。

这里的产品价值，是把一次工作中反复使用的方法变成容易再次调用的能力。原先分别存在于文档和命令里的步骤，出现在同一个任务环境中。用户下一次需要这套方法时，有了固定的调用入口，也有了可以检查的工具返回值。

对需求还在频繁变化的阶段，这种方式尤其适合小范围试做。先接入一项核验，看看实际任务会怎样调用、会暴露什么问题，再调整约束。功能范围越具体，使用者越容易判断生成结果是否符合自己的要求。

2.3 从代码写好到运行生效，中间还有维护工作

这个插件经历了两次明确纠正。第一次限制文件的操作范围：输入目录、报告路径和输出位置都有明确要求，不能覆盖原始材料、脚本和其他成果。第二次补齐运行所需的组件：评审流程、核验工具和脚本运行服务必须同时可用。缺少其中一项就停止加载，避免工具已经能调用，配套流程却没有加载。

修改之后，Harness 在会话中提示：运行时仍保留旧版工具说明，需要重启才能加载新代码。源文件更新与当前使用的版本分开了，这个差别会直接影响下一轮任务实际使用哪套逻辑。

重启后，新会话通过指令载入了流程正文。随后做了两次工具调用：要求把结果写进核验脚本文件时被拒绝；改为允许的输出位置后，返回了三条合成记录的检查结果，四条引文全部匹配。

这段过程说明，验收定制能力需要走到实际调用。文件存在、插件装上、工具可见、调用返回，各自对应不同环节。对产品设计来说，最容易让用户困惑的是其中不一致的时刻：界面显示插件启用，但新改动尚未加载；对话报告修改完成，工具仍按旧约束运行。

在这次试验中，追查版本差异依靠参数说明、对话记录和重启后的新会话。将来把这样的能力交给更多日常使用者，生效状态应当有更直接的位置。当前加载的版本、待生效的改动、下一步需要重载还是新建会话，都值得由应用给出明确说明。

试验结束后，插件保留安装并被关闭。启停入口让用户能够结束这次试用，源文件和任务产物则继续留在本地，便于回看。对于自行生成的扩展，这种可检查、可停用的使用方式，是持续尝试的重要条件。

2.4 核验通过，为什么仍然做错了任务范围

这项插件的一轮正式任务要求只处理首批九条反馈。Agent 却把同一目录里的第二批也合进来，生成十四条记录，又将两批材料一起传给核验工具。工具返回通过；按原任务指定的首批重新核对，记录范围超出了要求。

多出来的材料都是真实本地文件。检查器拿到两批输入，报告又对应两批内容，结构、编号和引文便可以通过检查。用户指定的任务范围与工具收到的核验范围，在调用之前就已经分开了。

问题落在这项自定义工具怎样确定核验基准。 它限制了目录和输出位置，却把具体输入文件的选择留给调用方。报告生成者扩大分析范围后，也能同时扩大核验依据。路径保护解决了文件能写到哪里，当前任务允许纳入哪些材料，则需要另一项约束。

这给定制设计提供了很具体的改法：任务开始时，根据已经指定的文件固定本轮输入清单，核验工具按清单检查。清单作为单独的任务配置保存，报告生成步骤不应随意改动它。

代价是 Agent 不能直接把新发现的相关资料顺手合并进来。出现额外材料时，需要先说明是否扩大任务范围，再重新生成结果。反馈评审重视批次清楚，适合采用这种约束；允许广泛搜集线索的研究任务，则可以另外定义纳入材料的规则。

这也是定制过程中产品经理需要介入的地方：把当前任务的约定转成具体规则，并决定哪些规则可以由 Agent 自行调整。工具已经能够运行，仍然有必要继续检查它在违反约定的情况下会怎样处理。

2.5 流程文件和插件，各自适合什么阶段

在另一组三阶段反馈任务中，方法被保存为普通流程文档，由新会话明确引用。相比之下，本地插件把流程注册为 Skill，又把确定性脚本接成工具。两种方式都有实际用途，选择取决于需要固定哪一部分工作。

我会先把容易变化的判断规则放在可阅读的文档里，把已经能明确写出的检查交给工具。分类依据还在反复纠正时，过早封装会让每次改动都牵涉更多配置；编号是否缺失、引文是否来自指定材料这类要求，则更适合稳定下来反复执行。

这次插件的创建依赖一份现成流程和脚本，也说明使用门槛没有完全消失。自然语言降低了连接能力的操作成本，需求定义仍需要有人承担。对于能把工作步骤说明白、愿意检查产物的产品经理，定制入口有实际价值；如果连要固定的规则都没确定，先完成几轮具体任务会更有效。

三、持续工作：让材料、判断和方法各有位置

3.1 一项反馈评审，经历了三种变化

连续任务选的是版本评审前的反馈整理。材料来自 Harness 社区公开讨论，先给八条帖子正文，再补入十二条后续评论与固定版本官方文档，最后换一批七条反馈。任务从首次交付，走到了证据更新和方法复用。

首次任务要求交付四份成果：结构化反馈数据、版本评审建议、改进方案与验收，以及可操作的评审页面。数据保留逐条记录，文档组织候选和方案，页面用于搜索、筛选与查看详情。它们由任务书指定，Harness 负责生成和保存。

几轮工作都放在同一个工作区，首批与新批次使用不同会话和输出目录。下一轮沿用流程文件，分析对象换成新的七条材料，上一批候选仍留在原来的成果中。这样既能找到过去的工作，也能看清当前讨论的是哪一批。

这里需要明确三种不同的变化。材料增加，需要重新检查判断；规则修订，需要更新工作方法；开始新批次，则需要重新划定输入与输出范围。它们可以发生在同一工作区，却不应该都被理解为继续上一段聊天。任务说明越清楚，后面的产物越容易对应到具体阶段。

3.2 新依据进入后，候选应当能够被撤下

第二阶段补充材料后，Harness 更新了四份成果，并新增一份判断变化记录。评审页面也增加了后续回复筛选，便于查看新补入的依据。

一位用户反馈，在终端里找不到 Harness 的启动命令。最初的评审把它当成需要新增的能力。补入官方文档后才确认，桌面端已经提供了可选的命令注册入口。Harness 随后撤下这项候选，并调整了评审建议。

这个变化对产品工作很有用。讨论开始时，用户描述的现象容易被直接转成一个新增功能候选；补入文档后，判断需要回到现有能力、使用入口和实际障碍之间重新定位。保留变化记录，可以看到候选为什么被撤下，也方便检查相关文档和页面是否同步更新。

另一条安装问题的讨论暴露了人数统计错误。补入后续回复后，报告把新增的两名用户算成了三名，原因是同一个人发了多条回复。这个错误同时进入数据文件和页面：成果之间能保持一致，不代表统计本身就是对的。

因此，这份变化记录更适合作为审阅入口：把调整过的候选、新增的依据和修改理由列出来，用户优先检查这些位置。更新任务的价值，在于重新组织判断与依据的关系；单纯增加摘要篇幅，不足以帮助评审继续推进。

3.3 规则保存下来之前，也要放进样例里检验

两轮评审之后，任务要求 Harness 把处理方法整理为普通流程文件。第一版里出现了一处冲突：前文要求不要仅凭版本号判断产品形态，后面的裁决规则却又让版本证据优先。

一条反馈如果同时出现官方版本号和开发启动命令，执行者仍然会遇到两种方向。前一轮已经发现的分类问题，被写进流程之后，并没有自然变成一条清楚的规则。

经过一次明确纠正，流程改为根据实际安装和启动方式判断形态，将版本信息单独记录。按作者去重、工作量留待评估、当前状态核查与未来验收分开，也被写入修订要求。

第三阶段在新会话中引用修订后的流程，处理另一批七条反馈。这次，产品形态和版本信息被分开记录：一条来自第三方桌面客户端的反馈被正确归类，暂时无法确认归属的材料则保留待核实。方案也将当前问题的核查与未来功能的验收分开。

流程文件因此有两种用途：让 Agent 获得下一轮的明确要求，也让审阅者有一份可以对照的规则。维护它时，我更愿意保留能触发冲突的样例，例如同时包含版本号和开发启动方式的帖子。规则修改后，用这些材料检查会得到什么结论，比逐项确认条款是否齐全更有针对性。

这里固定下来的是评审方法，下一轮的具体判断仍然取决于新材料。把流程保存为文档，也方便使用者直接看到当前依据，发现规则不合适时可以继续修订，而不必从旧会话里寻找零散补充。

3.4 页面能帮助查阅，事实仍要对应到具体记录

Harness 在回复里给出文件链接，生成的 HTML 可以打开预览。评审台支持搜索编号、按形态筛选、查看来源和详情；搜索没有结果时，详情区域随之清空。页面的数据与结构化文件保持一致。

对产品经理来说，这种成果形式比只拿到一篇长报告更便于逐条检查。讨论一个候选时，可以定位支撑它的反馈，再打开来源。这里的分工是明确的：Harness 提供文件与预览环境，任务生成的评审台提供记录列表、筛选和详情。

新一批材料里，一条插件反馈的分析混入了另一条讨论中的兼容性信息。报告仍保留原来的反馈编号和主帖链接，页面与数据文件也完全一致，但其中一句话已经张冠李戴。

评审者回到原帖核对，会找不到报告引用的那段描述；如果据此合并需求，还会把不同材料中的问题接到一起。保留链接，只能说明来源入口还在。要定位这种错误，需要把报告中的判断与对应原文放在一起看。

这份评审台最值得补充的，是判断与来源片段的对应关系。审阅者选中一项候选，就能看到它引用了哪段材料，发现串项时也有具体位置可改。修改之后还要检查相关数据、页面和建议文档，避免不同成果保留不同口径。

这组任务安排过两次子智能体只读审阅，最终结果仍出现了事实串项。审阅意见同样需要落到具体记录和来源片段，才能检查问题是否已经处理。

3.5 从材料到验收条件，最容易悄悄扩大需求

第三阶段还要求 Harness 根据一条历史会话迁移反馈，生成改进方案。原帖讨论的是旧版命令行工具：迁移被拒绝时，要保持原始日志不变，也不能发布未完成的新文件。生成的验收表却把这项限制套到了迁移成功的情况，要求成功后也不能出现特定的新版本文件。

这会改变研发要实现的行为。成功迁移是否保存新格式文件，需要由方案决定；如果把合法的新产物提前禁止，验收条件就会与迁移目标发生冲突。

这里应当分别定义成功、失败和取消的结果。成功路径检查内容完整、能够打开、合法产物可验证；失败与取消路径检查源文件不受损、没有误发布的半成品。取消还需要有具体发生阶段，才能说明操作之后保留什么、用户看见什么。

同一轮也有数字抄写问题：报告者描述 321 份日志中有 282 份被拒，摘要却写成了 321/282；文档列九条验收，自查写八条。数字可以通过逐项比对发现，成功路径该允许什么产物，则要回到功能目标作判断。

这对流程定制有直接影响。验收模板如果只要求正常、异常、取消三类路径齐全，仍然可能生成互相冲突的条件。模板还应要求每个约束对应材料中的事实或明确的设计决定。新增限制需要解释理由，不能在整理过程中悄悄变成已经确定的需求。

四、竞品比较：从创建到停用，看定制怎样被管理

对话创建插件、保存工作方法，都已经有多种产品实现。Kimi Code Desktop 支持在会话里创建 Skill，Qwen Code 的扩展可以打包 Skills、工具和子代理。进一步比较时，值得追问的是：用户创建了什么，怎样调用，修改后在哪里生效，以及怎样停止使用。、

以给反馈评审增加来源核验为例，让 Agent 阅读一段规则、提供一个检查工具、要求特定操作必须先经过检查，是三种不同改动。它们对触发时机和控制范围的要求不同。沿着这些具体动作看 Harness、Claude Code Mods 和 Codex plugins，才能看清各自开放的接口怎样进入工作。

4.1 创建与调用：改动通过什么入口进入任务

Harness 将创造模式与日常任务预设并列，生成的能力进入插件体系。前面的本地试验，正是把一份流程与脚本接成由用户主动调用的 Skill 和工具；架构层还允许更换模型适配器、工具注册和 Agent 循环等部件。它的定制入口能够继续向运行组件深入。

Claude Code 也支持通过对话创建 mod。Mod 可以接入工具调用、提示、命令和回合等事件，并通过受支持的接口增加面板、改变界面呈现。这些能力覆盖终端及桌面 Code 页的相应部分。定制者可以围绕具体事件改造工作过程，例如在某类工具操作前后执行逻辑。

Codex 的插件可以把工作流程、外部工具连接，以及在指定运行环节触发的自动操作，组织成一个可安装的包。它们分别对应 Skills、MCP 和 Hooks。Plugin Creator 可以生成插件结构与本地安装入口；安装后，在新会话中描述任务或点名插件即可使用相应能力，外部服务按需完成连接与授权。这条路径把工作方法和工具组合打包，便于安装、分发与复用。

这些路径解决的改造需求存在交集，但定制的组织方式不同。Harness 将运行部件纳入插件组合；Claude Mods 把事件与界面作为直接的改造接口；Codex plugins 则把一组工作能力组织为可安装的单元。产品经理选用时，可以先拿一项实际改动走完整条路径，再评估后续维护需要投入多少。

4.2 修改与生效：同一次更新，影响哪些工作

Harness 会分别记录插件是否被设为启用，以及运行中是否已经加载。开启配置热更新时，配置修改可以立即应用；修改已安装插件的代码，则需要重启进程。管理操作作用于当前使用的一套运行配置，共用这套配置的会话都会受到影响。

Claude 为会话内生成的 mod 提供即时试改路径：用户批准热重载后，相关修改在回合结束时加载。它默认只在创建它的会话中使用；要在其他会话继续使用，需要保留目录并另外加载，或通过市场分发，插件列表也提供停用入口。这种安排把当前试用与长期保留分开了。

Codex 的官方本地插件开发文档，以 ChatGPT 桌面应用中的安装为例：修改市场条目指向的插件目录后，重启应用以取得新文件。项目配置可以停用插件并保留安装；包中的 Hooks 则需要用户审阅并信任，安装并不会自动完成这一步。版本更新、项目选用和运行许可，各自有对应的操作。

4.3 影响范围越大，越需要明确的维护入口

按会话试用，方便在当前任务里调整效果，代价是跨会话使用时还要完成保留与加载。按运行配置管理，可以让多个会话采用同一套能力，但一次修改也可能同时影响多项工作。按项目控制启停，则能让不同项目保留各自的选择，维护者还需要跟踪哪些项目正在使用这项能力。

对团队反馈规则来说，这些差别会落到很普通的一天：维护者改完分类标准，正在进行的评审是否马上受影响，明天的新任务又会采用哪个版本。使用者需要看到当前采用的规则，维护者需要知道更新作用于哪里，出了问题也要能停止使用。

五、产品投入：先分清责任，再决定优先级

5.1 通用管理放在应用层，业务规则留在定制内容

这些案例涉及不同位置的问题。插件修改后运行旧代码，关系到应用怎样管理扩展；核验工具接受了额外输入，关系到这项工具怎样定义参数约束；反馈被错误分类，则需要检查材料解释和评审规则。改进建议应落在能够实际承担它的层次。

这样的划分也影响投入规模。为反馈评审台增加来源片段，改的是一套具体字段和页面；让所有 Agent 成果都能追溯到原始材料，则要处理不同文件、内容结构和来源形式。前者有当前任务可以直接检验，后者需要更多场景来确定通用机制。

本次使用中出现的业务需求，适合先在定制层做完整。等到不同任务都需要相同支持，而且各自实现会造成明显重复时，再讨论由应用统一提供。这样，反馈分类规则可以继续变化，Harness 也能为其他业务保留不同的界面和数据组织方式。

5.2 优先让用户看懂改动是否已经生效

在应用层，我会优先改善插件的生效状态。它已经在这次定制中造成一次追查和重启，而且影响后续每次调用究竟采用什么逻辑。用户如果判断错了当前版本，再认真修改规则，也可能一直检查的是旧结果。

插件管理机制已经区分保存与应用状态，接下来值得改善的是这些反馈如何被用户看见。这次确认新约束是否生效，仍需要结合对话提示和新会话调用。可以把当前加载版本、待生效改动和下一步操作放在同一个位置：源文件已修改时，让用户知道运行时是否更新；需要重载、重启或新建会话时，直接指出对应操作。

这项投入可以用明确动作验收：修改一条工具参数约束，界面是否指出旧逻辑仍在运行；执行提示的操作后，新会话是否按新约束返回结果。验收对象是状态与实际行为能否对应，不需要先扩展成复杂的插件治理系统。

相比之下，模式入口可以先做轻量调整。保留标准模式的直接开始路径，在需要选择时补足有区别的任务例子。四种预设是否需要重新分类，应当继续看实际选择过程，尤其是用户是否选错、是否反复切换，以及切换是否真的影响任务完成。

5.3 把容易写错的规则，做成可以重复检查的样例

在定制内容层，输入清单的优先级高于继续增加核验项。它先确定检查哪一批材料，已有检查才会对准当前任务。随后完善规则样例，用来检查分类与验收要求在变化之后是否仍然自洽。

样例不必一次铺得很大。包含开发启动命令与版本号冲突的材料，用来检查形态判断；同一作者多次回复的材料，用来检查人数统计；成功与失败产生不同文件的迁移情形，用来检查验收约束。每条样例都有明确的检查对象，修改流程后可以再次使用。

来源片段展示则先落在评审台里，观察它能否缩短定位错误的过程，以及修正后是否仍遗漏关联文档。确定性规则可以交给工具核对，涉及功能取舍的判断保留给产品评审。两种检查在界面中分别呈现，也方便接手者知道还缺哪一步。

结尾

这次实测后，我对 Harness 的定位更清楚了：它适合让有明确工作方法的人，逐步搭出自己需要的工具。一份已有的评审流程和核验脚本，通过创造模式变成了可以在新会话里调用的插件。对需要反复处理同类任务的产品经理，这条路径有实际吸引力。

自由定制也意味着要持续维护。规则改了，要确认工具已经采用新版本；材料增加了，要重新检查原来的判断；结果出错了，要能找到依据并完成修正。用户获得的修改空间越大，应用就越需要把当前状态和影响范围解释清楚，帮助使用者接手这些工作。

因此，我会从一项范围明确、经常重复的任务开始使用它，让流程和工具随着实际问题逐步完善。到了下一批材料进来时，再看哪些规则被正确复用了，哪些地方仍需重新解释，错误是否更容易发现和修改。能否减少下一轮工作的重复交代和核对，才值得作为继续投入定制的依据。