Harness笔记——先定义成功

AI 编程里最容易误判的，不是任务没做完，而是太早把“看起来完成”当成成功。代码已经改了，说明已经写了，验证似乎也跑过了，但如果一开始没有说清什么叫成功，这些完整产物仍然可能只是朝着错误目标在用力。成功标准必须先于动作出现。

上一章讨论执行形态分流，解决的是任务应该进入哪条执行轨道：

问答、调查、方案、补丁、脚本，还是连续执行。

本章要补上的，是进入轨道以后

按什么口径收口

。轨道选对，只能避免 AI 用错劳动方式；成功标准缺失，AI 仍然可能在正确形态里朝错误目标用力。

我后来越来越把

“成功标准”当成任务输入，而不是验收阶段的补丁

。过去很多返工并不是模型不会写代码，而是

人和 AI 对“好”的理解没有在开始前对齐

。等 diff 已经展开，再争论到底要不要兼容旧行为、要不要扩大重构、要不要补测试，成本就已经被放大了。

成功标准不是厚流程，也不是把所有需求都写成详细规格。它要解决的是一个更朴素的问题：

这件事做到什么程度算可以交付

，做到什么程度算不能收，遇到什么情况必须停下来让人判断。

AI 接到任务后，会自然朝可见产物推进。它会

分析现象，寻找文件，修改代码，运行检查，写总结。

这个过程越顺畅，人越容易误以为任务已经在正确轨道上。

但可见产物不等于成功。没有标准时，AI 会优先完成最容易被看见的东西：写了多少代码、改了几个文件、跑了哪些命令、解释得是否完整。

它会把“我做了很多”包装成“我做对了”，而工程验收真正关心的往往不是这些。

比如一个需求说：“把筛选后的导出修好。”这句话看起来足够明确，但里面仍然

缺成功标准

。是只修当前页面，还是要检查所有导出入口？是保持原有 Excel 模板完全不变，还是允许顺手调整列名？是只保证本次筛选参数一致，还是要补一层公共查询参数构造？这些问题没有提前定，AI 就会按代码局部最顺的方向走。

它可能补了漏传的 status，这看起来像修好了；也可能顺手抽了公共方法，这看起来像治理了；还可能调整后端查询对象，这看起来像从根上解决了。

这些动作都能自圆其说，但它们对应的是不同成功口径。

团队当前只想止血时，抽象和接口调整就是过度实现；团队正在治理多个导出入口时，只补一个参数又会显得太浅。

所以

成功标准要先于动作出现。

它不是执行后的评语，而是执行前的方向。标准越早，AI 的自由度越会被约束在有效范围内；标准越晚，人就越容易拿着已经形成的产物去倒推自己到底想要什么。

这也是很多 AI 任务争议的来源。争议表面上发生在评审阶段，实际原因通常更早：入口只说了“帮我处理一下”，没有说清楚处理到哪里算成功。

AI 只能追求最像完成的样子，人最后却要用隐含标准去否定它的完成。

完成值的分层图

完成，是产物存在。

代码改了，文档写了，按钮加了，脚本跑了，这都叫完成。

可用，是目标场景可以跑通。

用户点筛选，再点导出，拿到的文件数量和列表一致，这才开始接近可用。正确，是结果满足业务、权限、数据和边界条件。导出数量一致，但如果绕过了权限过滤，或者把隐藏字段也导出来，就仍然不正确。

最容易被忽略的是“值得保留”。它不是主观上觉得代码漂亮，而是

这次结果不会给下一次同类任务增加负担。

它至少要回答几个可判定问题：是否减少了重复入口，是否维持了既有契约，是否让下次同类任务有可复用口径，是否避免把临时补丁固化成新抽象。

AI 很容易

停在“完成”和“可用”之间，因为这两层最容易展示

。它可以告诉你“已补充参数”“已更新校验”“已运行测试”，这些都是真实动作，却不一定覆盖正确性和可保留性。真正的工程成功，往往在后两层。

以导出筛选为例，最低层的完成是导出按钮调用时带上缺失字段；可用是筛选后导出的数据和页面列表一致；正确还要确认权限、租户、默认状态、时间区间、空值处理没有被改变；值得保留则要看这次修复有没有让查询条件来源更清楚，或者至少没有继续扩大重复逻辑。

我见过一种很常见的反面结果：某次紧急修复复制了一段查询参数拼装逻辑，当时页面跑通了，评审也因为问题紧急放过了。后来第二个导出入口出错，团队才发现同样的筛选条件已经散落在三个地方，每个地方还对空值和默认状态有不同理解。

第一次修复是可用的，但不值得保留，因为它把下一次问题变得更难定位。

这四层拆开以后，验收口径会变得更清楚。一个紧急线上问题可以只追求“可用且不破坏”，先不处理长期治理；一个框架层问题则不能只追求“可用”，还要考虑是否值得保留。

不同任务有不同成功层级，但不能混在一句“做完”里。

我不太赞成把所有任务都强行拉到最高标准，那会让 Harness 变成负担。更实用的做法，是在开始前说清楚本轮要达到哪一层：本轮只做止血，还是顺带治理；只修当前入口，还是建立复用约束；只给判断，还是要形成可回归的验证样本。

层级一旦明确，AI 的动作也会自然收住。

追求“完成”，它可以交付产物；追求“正确”，它必须拿出证据；追求“值得保留”，它就不能只证明现在能跑，还要说明为什么这次改动不会把系统带向更乱的状态。

一个可执行的成功标准，通常不需要很长，但至少要包含三类信息：

不破坏什么，必须做到什么，怎样算更好。

不破坏什么，是

底线

。它定义动作半径，也定义失败条件。修复导出筛选时，底线可能是不能改变权限判断，不能改变 Excel 模板列顺序，不能影响未筛选导出的默认结果，不能把后端接口参数改成不兼容旧调用。底线写清楚以后，AI 就知道哪些“顺手优化”其实不能碰。

必须做到什么，是

最低交付

。比如筛选条件必须在列表查询和导出查询中保持一致；如果有分页，导出应该按完整筛选结果导出，而不是只导出当前页，除非产品明确要求如此。这类标准直接决定任务能不能收。

怎样算更好，是

可选增益

。比如在不扩大风险的前提下，复用已有查询参数构造；补上一个覆盖筛选导出的回归测试；在总结里标出同类入口是否需要后续排查。增益不是必须项，但它给 AI 一个合理的改进方向，避免它自己发明价值。

底线目标增益结构

真实入口里可以非常短：

底线：不改变权限过滤、模板列顺序和既有导出接口契约。目标：筛选后的列表和导出使用同一组查询条件，并用测试或请求证据证明。增益：如果已有公共参数构造入口，优先复用；如果没有，只标出治理建议，不在本轮新建抽象。

这三句话不复杂，却已经

足够约束取舍。

AI 知道什么不能碰，知道最低交付是什么，也知道什么只能作为增益处理。更重要的是，它知道什么时候不能把“我顺手做了一个更完整的方案”包装成成功。

这三类标准放在一起，能避免两个常见极端。只写目标，不写底线，AI 容易

为了达成目标破坏旁路约束。

只写底线，不写增益，AI 会

做得非常保守，错过低成本改进。

只写“更好”，不写最低交付，结果最容易飘，因为“更好”本身没有验收口。

成功标准不是为了替代人的判断，而是为了让人的判断提前进入任务。人真正要表达的往往不是“你尽量做好”，而是“这些不能坏，这些必须成，如果成本不高，可以顺手把这部分变清楚”。这句话比一长串抽象要求更有约束力。

可观察标准证据

成功标准最怕写成形容词。“体验更好”“逻辑更清晰”“代码更优雅”“功能更稳定”听起来合理，但

对 AI 的约束很弱。

它们不能直接验证，也很难在执行中形成刹车。

可观察的标准，要能落到证据上。体验更好，可以改成“空状态下禁用导出按钮，并给出明确提示”；逻辑更清晰，可以改成“列表查询和导出查询共用同一个参数构造入口”；功能更稳定，可以改成“新增关键组合的回归用例，并通过相关测试”。

标准一旦能观察，AI 才能围绕证据工作。

可观察不等于事无巨细。它只是要求关键判断有落点：请求参数能对比，响应结果能复查，测试能运行，截图能确认，日志能追踪，权限能验证，人工判断点能被明确标出。这样做的好处，是最终总结不再只是“已完成”，而是能逐条回应标准是否满足。

我在评审里多次见过“逻辑更清晰”这类说法制造争议。AI 认为抽一个公共函数就是清晰，评审者却认为新抽象遮住了业务差异；双方讨论半天，其实没有共同证据。后来把标准改成“两个入口复用同一个参数构造函数，且差异字段通过显式参数传入”，争议就少了很多。

评审不再讨论清晰的感觉，而是直接看入口、参数和测试。

没有证据覆盖的标准，

不能被总结成已完成，只能标为未覆盖、待确认或需要人工判断

。这条规则很硬，但非常有用。AI 可以说“权限路径未改，未单独跑权限回归”，也可以说“模板列顺序已通过快照对比确认”；它不能把缺失证据藏在一句“已完成验证”里。

这会改变交付习惯。过去总结里最容易出现的是一段完整叙述，所有内容都被写成已经处理；现在要允许交付状态分层：

满足、未覆盖、无法验证、等待人工确认。

状态一分层，验收就不会被漂亮总结带偏。人可以接受一个明确标注的未覆盖项，却很难接受一个事后才发现的证据空洞。

可观察标准还会减少无效争论。评审不必从主观感觉开始，而是直接看证据是否覆盖标准。

证据不够，就补证据；标准冲突，就回到人工判断点；实现不满足标准，就修改实现。

讨论对象变实以后，AI 任务才真正容易收口。

并

不是所有成功标准都能自动判断。

很多任务里最关键的部分，本来就需要人做取舍：是否接受一个新交互，是否扩大重构范围，是否改变历史兼容策略，是否把本次修复抽象成公共能力。

不确定的接管决策

问题不在于这些判断不能自动化，而在于

它们常常被遗漏

。入口不标出来，AI 就会在执行中替人默默选择。它可能为了代码整洁扩大重构，也可能为了最小改动跳过治理；这两种选择都未必错，但它们不应该在无人确认的情况下发生。

所以不确定性要提前变成接管点。接管点可以很简单：如果发现多个入口存在同类问题，先输出影响面和方案，不直接批量修改；如果修复需要改变导出模板，先停下来确认；如果兼容旧参数和统一新参数冲突，先给出取舍，不自行决定；如果验证无法覆盖权限路径，明确说明未覆盖风险。

接管点不是让人频繁打断 AI，而是

让 AI 知道什么时候不能继续装作确定

。成熟的连续执行不是一路跑到底，而是在路线分歧、影响面扩大、标准冲突和证据不足时主动停住，把事实、选项和建议交出来。

有一次类似任务里，AI 在调查中发现导出入口不止一个，还发现不同页面对“默认状态”的理解并不一致。它如果继续按原任务批量统一，很可能把某些历史页面的默认结果改掉；如果只修当前入口，又可能留下同类问题。这个时刻真正需要的不是继续写代码，而是把影响面、差异事实和两条路线交出来，

让人决定本轮是止血还是治理。

这一步对 Harness 很重要。很多失控不是发生在禁止区，而是发生在允许范围内的隐性取舍。AI 没有碰密钥，没有删库，也没有越权执行命令，但它把一个小修复扩大成跨模块重构，把一个临时兼容改成长期接口契约。

风险不在权限，而在未声明的成功标准被它替人解释了。

接管点把这类风险显性化。它告诉 AI：你可以调查，可以提出路线，可以说明推荐，但不能在这些分歧上默默落子。人的判断不需要覆盖每一行代码，却必须覆盖会改变目标、边界和长期维护责任的节点。

Harness打薄的闭环定义

成功标准真正有价值，不只是因为它写在任务开头，而是因为它能让 Harness 变薄。计划、执行、验证和总结都围绕同一个口径展开以后，AI 不需要在每一步都靠长提示提醒自己应该做什么。

这不是说流程消失了，而是显性提醒会变短。早期你可能要反复写：

先定义底线，别扩大范围，未覆盖要说明，遇到路线分歧要停。

等团队形成习惯以后，这些话可以收束成一句更稳定的口径：按导出一致性标准处理。

这句话之所以有效，不是因为它神秘，而是因为背后已经沉淀了任务样本：要保护权限和模板契约，要对齐查询条件，要用请求、测试或快照回收证据，要把未覆盖项写清楚，要在影响面扩大时停下来。

标准越稳定，入口提示越短；入口提示越短，越不容易把无关规则塞进上下文。

一次修复沉淀成模板的路径可以很轻：先把本次成功标准写进任务入口，再把验证证据整理成可复查样本，最后把反复出现的判断压成默认问题。下次同类任务开始时，AI 不必重新猜“好”的意思，只要

确认本轮是止血、治理还是回归验证。

这种复用不是把每个任务都套进固定模板，而是把已经被验证过的判断变成默认动作。新任务仍然可以有自己的差异，但它不需要重新讨论哪些底线不能破、哪些证据必须回收、哪些不确定性要停下来。标准提供的是起点，不是终点；起点稳定以后，人和 AI 才能把注意力放到本轮真正不同的部分。

我更愿意把这看成一种工程节省，而不是流程增加。成功标准写在前面，表面上多了一步，实际减少了后面的返工、争论和无效改动。团队沉淀下来的不是更多流程，而是一组可复用的验收口径、任务样本和判断习惯。

AI 越少靠猜，人越少靠返工纠偏，Harness 就越轻。

先定义成功总览

成功先定义，不是为了让每个 AI 任务都变成厚重规格，而是让任务从一开始就带着可复用的验收口径进入执行。AI 最擅长追求可见完成，Harness 要做的是把这种完成一步步拉回可用、正确和值得保留。等这些口径沉成任务样本和判断习惯以后，很多提醒都可以不再反复写出来。标准越稳定，Harness 越薄；AI 越少靠猜，人越少靠返工纠偏。